- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 4 Oct 2014 11:55:05 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- CC: Chris Palmer <palmer@google.com>
Anne, is you proposal that gUM should only be possible for authenticated origins as defined in https://w3c.github.io/webappsec/specs/mixedcontent/#is-origin-authenticated? So far I think we've in this work only talked about http and https, and I know that some implementation(s) disallow gUM from file: URLs; but those seem to be authenticated according to the reference. We should probably get a better understanding about what the implications would be of allowing file URL access. Stefan On 01/10/14 18:07, Anne van Kesteren wrote: > Scenario: > > 1) User visits http://example.invalid/ which hosts a audio/video effects service > > 2) example.invalid requests access to camera and microphone > > 3) User grants access to example.invalid. > > Attack: As the code from example.invalid is not from an authenticated > origin an attacker could have inserted code that takes the output from > the camera and microphone and transmits it towards evil.invalid, > unbeknownst to the user. > > The user is probably not aware their privacy could be compromised in > this manner. > > > Arguments made in the previous thread plus counter arguments: > > A) Geolocation does it too. I think that geolocation set a bad > precedent that we should not follow. I raised this issue with the > geolocation WG and so far they seem to agree with my assessment. > They're looking into their options to improve the situation. > > B) <input type=file> does it too. I suspect that were we to invent > this feature today we would more strongly consider requiring an > authenticated origin. However, in comparison <input type=file> is far > less invasive than sharing everything that happens in your current > environment in real time. (The <input type=file> case mentioned was > uploading an avatar. I think anything with user accounts must use TLS > as users are likely to reuse passwords even though we all know that's > bad. Hosting something with user accounts while not using TLS is > irresponsible.) > > > Basically, new features should be hold to a higher bar than past > features. I also discovered that getUserMedia() is still prefixed in > Firefox Nightly, so there seems to be ample room for communicating > this change to developers and providing an upgrade path. Thanks to > Cloudflare it also seems easier than ever to get an authenticated > origin. > >
Received on Saturday, 4 October 2014 11:55:31 UTC