Re: getUserMedia() and authenticated origins #2

On Wed, Oct 1, 2014 at 9:05 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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.

Purely passive surveillance is also bad, here.

(Not that I believe there is a more-than-marginal cost difference
between passive and active attack.)

> 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.

Right, "Geolocation quoque" is just as much a fallacy as tu quoque. :)

> 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.)

A big difference is that <input type=file> has traditionally been
implemented with a picker/chooser UX, which allows the user to decide
which file to expose to the origin (and, of course, possibly to expose
to anyone). They still need to know and understand whether or not the
origin is authenticated, but at least the potential leak is gated by a
real, honest user choice.

By contrast, Geolocation has traditionally been a boolean choice: GPS
or Nothing?

gUM is usually done with a chooser, but as you note it is more
"ambient" than a single file.

As for the other issue: "Is HTTPS the only 'authenticated' origin?" I
really want to (a) use the term "secure" because "authentication" is
precise enough to not obviously include http://localhost and
file:///...; and (b) to indeed allow powerful web platform features on
http://localhost and file:. I suspect that (b) will, along with other
changes I'd like to see happen, make it easier for people to develop
and test applications that will ultimately be deployed to the public
via HTTPS.

Received on Monday, 6 October 2014 18:27:55 UTC