- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 8 Oct 2014 05:50:31 +0000
- To: Eric Rescorla <ekr@rtfm.com>, Justin Uberti <juberti@google.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 07/10/14 18:10, Eric Rescorla wrote: > On Tue, Oct 7, 2014 at 8:59 AM, Justin Uberti <juberti@google.com > <mailto:juberti@google.com>> wrote: > > I am not OK with this, as described, for three reasons: > 1) there is already substantial incentive for apps to use > authenticated origins, e.g. persistent permissions in chrome, > browsers marking https origins favorably > > > Firefox also allows persistent permissions (I believe) FF 33 (due out > mid-month), > but only for HTTPS. > > 2) this breaks real, existing applications, e.g. http://webcamtoy.com/ > 3) makes trying/experimenting with webrtc difficult, e.g. > http://jsfiddle.net, or http://localhost > > We still want to encourage HTTPS, of course, so I think it would be > fine to have console warnings or similar methods of persuasion. > > > I agree with Justin's position. > > As Adam mentioned in another thread, it's hard to think of a clearer > case of informed > user consent, so this doesn't seem like it has special security benefit > aside from the > benefit of deprecating non-HTTPS everywhere. It is a very informed user consent, but I worry about http delivered sites that are legit, with returning users. Each time they approve the use of camera and microphone (because the app needs them for its purpose), but the app may be compromised by a MITM that uses the tracks generated for bad things in addition to the intended functionality. https is one way to stop this, subresource integrity may be another, a third could be the isolated tracks.
Received on Wednesday, 8 October 2014 05:50:55 UTC