chrome 74 is identified as safari on http

[fippo]

a variant of #764:
Chrome 74 makes getUserMedia securecontext, i.e. not available when using http and not https. This leads to chrome being detected as Safari (due to UA sniffing, bad!)
I expect Mozilla to follow here which means Firefox detection would be broken too

One potential solution might be to not run any shims on http and detect as unknown browser there. This isn't going to work great but there are just two legitimate use-cases on http:

1. recveive-only video
2. datachannel-only
   so the impact might be limited.

[dagingaa]

I think it's reasonable to not shim on http for adapter by default, and if it's needed either stay on old version, fork, or just use https.

Exception should be made for localhost perhaps (fairly common to consider localhost secure, but then again I guess feature detection isn't a problem in that case).

[guidou]

+1

[mazzomazzo]

Guys,

This proposal is absolutely unacceptable.

Your case 1: recveive-only video is one of the most common uses of WebRTC.

All the applications that just play live streams sent from servers, will be affected for no reason. We have thousands of users, doing video surveillance from IP cameras, and they don't run their webpages over https, they don't need to. They just use http.

Look at this, you are going to break it for no reason:
http://livecam.nmu.edu/1/
http://livecam.nmu.edu/2/
http://livecam.nmu.edu/3/

[fippo]

@mazzomazzo how is that going to break? This would be the equivalent of adapter not being there, not RTCPeerConnection disappearing.

(i can see how it would break if you try the legacy offerToReceive* stuff in safari though)

[mazzomazzo]

Chrome does not implement 100% of standard, so shims from adapter are used.
Talk about Edge. These pages will not work in Edge any more.
Same about other browsers.

Please correct me if I am wrong and explain how
http://livecam.nmu.edu/1/
can work without adapter.

[fippo]

FWIW: I wouldn't recommend pulling adapter from github pages as this might lead to regressions when this gets updated without you knowing about it.

if you have an alternative solution to #764 that does not require looking for prefixed names or UA sniffing i'd be happy to hear about it.

[mazzomazzo]

1. Why not look for prefixed names to identify browser? Everyone does that.
   Isn't there a reliable way to identify Chrome?
   Like navigator.userAgent.match(/Chrom(e|ium)/(\d+)./))?

2. I hope you are not proceeding with this approach of dropping support for insecure contexts.

3. If you are proceeding, then will there be a branch, or version on github that will still support insecure contexts, that we could rely on?

[fippo]

1. this is called UA sniffing. It doesn't work well and as you have seen misidentified Chrome 74 on http as safari. See Chrome will be identified as Safari if webkitGetUserMedia is removed #764 for more discussion.
2. I would prefer not to but wrongly identifying as Safari is as bad.
3. https://webrtc.github.io/adapter/adapter-7.2.1.js is the current version. Versioned releases don't get updated.

[mazzomazzo]

1. Is there really no reliable way to detect Chrome/Chromium? Why can't we all ask Chrome people to introduce some unique thing in Chrome for that purpose?

2. You decide just to amputate a leg because of ugly tattoo. Yes, detecting Chrome as Safari is bad, but solving it like this is cruel and leads to much worse consequences. And again, isn't there a reliable way to identify Safari? Amazing if this is so.

3. Just educate me - the adapter_factory.js and utils.js needed by adapter-7.2.1.js, what about these files?
   These don't change? Or are there specific versions for these too?

[dagingaa]

First, using an old version of adapter will work for some time. We can’t support everything, especially not with this project being largely a volunteer effort. There isn’t a reliable way to detect specific browsers, and feature detection is not always correct. http is going the way of the dinosaurs. Chrome and other browsers are dropping support for a lot of privileged APIs from insecure contexts. Adapter tries to shim but here I don’t see how we can avoid dropping support for http without a reliable way to detect browsers. If you have a solution, please submit a PR with your suggested solution. I certainly don’t have a better suggestion at this moment.

…

On Thu, 28 Mar 2019 at 17:35, mazzomazzo ***@***.***> wrote: Guys, This proposal is absolutely unacceptable. Your case 1: recveive-only video is one of the most common uses of WebRTC. All the applications that just play live streams sent from servers, will be affected for no reason. We have thousands of users, doing video surveillance from IP cameras, and they don't run their webpages over https, they don't need to. They just use http. Look at this, you are going to break it for no reason: http://livecam.nmu.edu/1/ http://livecam.nmu.edu/2/ http://livecam.nmu.edu/3/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#935 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARZRKVE9gymSInIU1k_6RGGGLgCDJWjks5vbNLegaJpZM4cOveX> .

[fippo]

the other alternative would be to check for webkitRTCPeerConnection iff webkitGetUserMedia is not there . We assumed I think that doesn't apply to safari (which does not have webkitRTCPeerConnection) and for Edge (which oddly exposes that) we can detect its edge-y ness by checking for RTCIceGatherer.

[fippo]

This should be fixed (without dropping http support) in v7.2.3 which just landed on npm as well as adapter-latest.js