Intent to deprecate: persistent permissions over HTTP

[Anne van Kesteren]

A large number of permissions we currently allow users to store
persistently for a given origin. I suggest we stop offering that
functionality when there's no lock in the address bar. This will make
it harder for a network attacker to abuse these permissions. This
would affect UX for:

* Geolocation
* Notification
* Fullscreen
* Pointer Lock
* Popups

If you are interested in demos of how these function today:

* http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html
* http://dontcallmedom.github.io/web-permissions-req/tests/notification.html
* http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html
* http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html
* http://dontcallmedom.github.io/web-permissions-req/tests/popup.html

Note that we have already implemented this for getUserMedia(). You can
contrast the UX for these two links:

* http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html
* https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html

This seems like a change we can make today that would be better for
our users and nudge those that require persistence to do the right
thing, without causing much harm.


--
https://annevankesteren.nl/

[andre...@gmail.com]

Is the threat model for all of these permissions significant enough to warrant the breakage? Popups for example are annoying, but a spoofed origin to take advantage of whitelisted popups seems not terribly dangerous.

Thanks,

Andreas

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

[Anne van Kesteren]

On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
> Is the threat model for all of these permissions significant enough to warrant the breakage?

What breakage do you envision?

Having said that:

* Geolocation allow for tracking the user
* Notifications allow for spamming the user
* Fullscreen allows for impersonating the OS
* Pointer Lock allows for spoofing
* Popups allow for spamming the user


--
https://annevankesteren.nl/

[Gijs Kruitbosch]

On 06/03/2015 17:27, Anne van Kesteren wrote:
> A large number of permissions we currently allow users to store
> persistently for a given origin. I suggest we stop offering that
> functionality when there's no lock in the address bar.

Can we make an exception for localhost and its IPv4 and IPv6 equivalents
to make things easier for web devs? Bonus points if we make a mechanism
that detects /etc/host overrides (to localhost) and allow it there, too.

~ Gijs

[Martin Thomson]

On Fri, Mar 6, 2015 at 9:27 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> I suggest we stop offering that
> functionality when there's no lock in the address bar.

Anne, thanks for doing this. +1 from me.

I've opened bugs on this in the past, but this is definitely a better
forum for having the discussion.

On Fri, Mar 6, 2015 at 9:33 AM, <andre...@gmail.com> wrote:
> Is the threat model for all of these permissions significant enough to warrant the breakage? Popups for example are annoying, but a spoofed origin to take advantage of whitelisted popups seems not terribly dangerous.

The important thing to note is that this doesn't break sites, it just
removes that avenue of attack.

You might say that having a local network attacker able to see what
your webcam is looking at is not scary, but I'm going to disagree.
Also c.f. RFC 7258.

It gets quite a lot more serious when an attacker is able to persist
their attack beyond their initial interaction. For instance, if the
attacker can persist scripts for an origin, they can add a bug that
persists beyond their initial attack, as long as the site is visited.

And of course, while an attacker is able to actively participate, any
unsecured site can be modified so that the attacker can harvest the
permission, as long as they can guess a site that has the permission
persisted.

On balance - though this is only my opinion - the risk of annoyance is
worth it. If you like to use a stick (I don't), you can consider this
incentive for sites to move to HTTPS.

[andre...@gmail.com]

>
> You might say that having a local network attacker able to see what
> your webcam is looking at is not scary, but I'm going to disagree.
> Also c.f. RFC 7258.

I asked for something very specific: popups. What is the threat model for the popup permission state?

Thanks,

Andreas

[andre...@gmail.com]

> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

>
> On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
>> Is the threat model for all of these permissions significant enough to warrant the breakage?
>

> What breakage do you envision?

I can no longer unblock popups on sites that use HTTP. The web is a big place. It will take a long time for everyone to move.

>
> Having said that:
>
> * Geolocation allow for tracking the user

> * Fullscreen allows for impersonating the OS
> * Pointer Lock allows for spoofing

The two seem fairly trivial problems. The user will simply stop going to the spamming site. I don’t think it makes sense to treat them in the same bucket as the above 3.

> * Popups allow for spamming the user

> * Notifications allow for spamming the user

Thanks,

Andreas

>
>
> --
> https://annevankesteren.nl/

[Ehsan Akhgari]

On 2015-03-06 1:14 PM, andre...@gmail.com wrote:
>
>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>>
>> On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
>>> Is the threat model for all of these permissions significant enough to warrant the breakage?
>>
>> What breakage do you envision?
>
> I can no longer unblock popups on sites that use HTTP. The web is a big place. It will take a long time for everyone to move.

I think Anne is not proposing that. He's proposing blocking persisting
those permissions. IOW you would be able to still show popups from
these websites, but you won't be able to ask Firefox to remember your
preference.

>> Having said that:
>>
>> * Geolocation allow for tracking the user
>> * Fullscreen allows for impersonating the OS
>> * Pointer Lock allows for spoofing
>
> The two seem fairly trivial problems. The user will simply stop going to the spamming site. I don’t think it makes sense to treat them in the same bucket as the above 3.

I agree that the above three are more important problems to address, FWIW.

[andre...@gmail.com]

> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>
> On 2015-03-06 1:14 PM, andre...@gmail.com wrote:
>>
>>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>>>
>>> On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
>>>> Is the threat model for all of these permissions significant enough to warrant the breakage?
>>>
>>> What breakage do you envision?
>>
>> I can no longer unblock popups on sites that use HTTP. The web is a big place. It will take a long time for everyone to move.
>
> I think Anne is not proposing that. He's proposing blocking persisting those permissions. IOW you would be able to still show popups from these websites, but you won't be able to ask Firefox to remember your preference.

I know but we will break the persisting. The user will be annoyed that popup unblocking doesn’t work as expected on HTTP sites.

I am all for securing dangerous permissions but popups and notifications seems more like we are wagging our finger at the user in unhelpful ways. Most users will simply think Firefox is broken.

Thanks,

Andreas

[Ehsan Akhgari]

On 2015-03-06 1:23 PM, andre...@gmail.com wrote:
>
>> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>
>> On 2015-03-06 1:14 PM, andre...@gmail.com wrote:
>>>
>>>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>>>>
>>>> On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
>>>>> Is the threat model for all of these permissions significant enough to warrant the breakage?
>>>>
>>>> What breakage do you envision?
>>>
>>> I can no longer unblock popups on sites that use HTTP. The web is a big place. It will take a long time for everyone to move.
>>
>> I think Anne is not proposing that. He's proposing blocking persisting those permissions. IOW you would be able to still show popups from these websites, but you won't be able to ask Firefox to remember your preference.
>
> I know but we will break the persisting. The user will be annoyed that popup unblocking doesn’t work as expected on HTTP sites.
>
> I am all for securing dangerous permissions but popups and notifications seems more like we are wagging our finger at the user in unhelpful ways. Most users will simply think Firefox is broken.

Notifications are a much newer feature than pop-ups and are not as
widely used yet, so hopefully with the case of notifications we can stop
persisting the permission right now without having too many people
wonder why they can't persist the permission. Perhaps it makes more
sense to start with geolocation, fullscreen and pointerlock first.

One thing to note is that there are still large Web properties which at
least use geolocation and fullscreen from HTTP (Bing Maps for example
for geolocation, and player.vimeo.com for embedded vimeo videos usin
fullscreen). We should probably start evangelizing this sooner than
later to those Web sites, and perhaps also to the general developer
community through a hacks blog post and similar venues.

[Jonas Sicking]

I have the same reaction. Not allowing the user to remember that
popups should be enabled on a http site is going to "break" a lot of
websites I bet. In that users will have to constantly re-enable
popups.

I don't think the added security benefit of possibly preventing a MITM
from opening popups is worth it.

I.e. I think we'll end up annoying far more users by having them
constantly re-enable popups, than we save users from annoyance by
preventing a MITM from opening a popup the user didn't want.

/ Jonas

[Bobby Holley]

On Fri, Mar 6, 2015 at 12:10 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> I have the same reaction. Not allowing the user to remember that
> popups should be enabled on a http site is going to "break" a lot of
> websites I bet. In that users will have to constantly re-enable
> popups.
>
> I don't think the added security benefit of possibly preventing a MITM
> from opening popups is worth it.
>

+1

[Dave Townsend]

I would also add that I've seen cases where attempting to allow a blocked
popup doesn't work, you have to allow the site then reload the page that
triggered the popup. Obviously that is a bug in our code that we should fix
but until we do removing the permission option would entirely break these
sites.

On Fri, Mar 6, 2015 at 12:06 PM, Justin Dolske <dol...@mozilla.com> wrote:

> It does seem to me that popup-blocking isn't a great fit for this list.
> AIUI this started from Chrome's intent to start moving "powerful" features
> to SSL-only (with this being a first step), and allowing popups doesn't
> seem like that kind of feature.
>
> It's also worth noting that our popup blocker is not perfect, and there
> are various ways around it. So if a MITM attacker wants to inject popups
> into a non-SSL page, they'd presumably just do it in a way that doesn't
> require exceptions in the first place.
>
> Justin
>
> On Fri, Mar 6, 2015 at 10:31 AM, Ehsan Akhgari <ehsan....@gmail.com>

[Justin Dolske]

[Gavin Sharp]

For popup blocking and notifications, I agree with Andreas - the
tradeoff from the user perspective is not right.

Gavin

On Fri, Mar 6, 2015 at 10:23 AM, <andre...@gmail.com> wrote:
>
>> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>
>> On 2015-03-06 1:14 PM, andre...@gmail.com wrote:
>>>
>>>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>>>>
>>>> On Fri, Mar 6, 2015 at 6:33 PM, <andre...@gmail.com> wrote:
>>>>> Is the threat model for all of these permissions significant enough to warrant the breakage?
>>>>
>>>> What breakage do you envision?
>>>
>>> I can no longer unblock popups on sites that use HTTP. The web is a big place. It will take a long time for everyone to move.
>>
>> I think Anne is not proposing that. He's proposing blocking persisting those permissions. IOW you would be able to still show popups from these websites, but you won't be able to ask Firefox to remember your preference.
>
> I know but we will break the persisting. The user will be annoyed that popup unblocking doesn’t work as expected on HTTP sites.
>
> I am all for securing dangerous permissions but popups and notifications seems more like we are wagging our finger at the user in unhelpful ways. Most users will simply think Firefox is broken.
>

> Thanks,
>
> Andreas
>
>>
>>>> Having said that:
>>>>
>>>> * Geolocation allow for tracking the user
>>>> * Fullscreen allows for impersonating the OS
>>>> * Pointer Lock allows for spoofing
>>>
>>> The two seem fairly trivial problems. The user will simply stop going to the spamming site. I don’t think it makes sense to treat them in the same bucket as the above 3.
>>
>> I agree that the above three are more important problems to address, FWIW.
>>
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Jesper Kristensen]

If there is such exception, please make it opt-in. It is annoying for
web devs when localhost behaves differently than any other site. It is
much harder and time consuming to debug something when it works locally
and then breaks when you deploy it. Web devs who deploy to https should
develop locally on https.

Jesper Kristensen

[Aryeh Gregor]

On Fri, Mar 6, 2015 at 7:27 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> A large number of permissions we currently allow users to store
> persistently for a given origin. I suggest we stop offering that

> functionality when there's no lock in the address bar. This will make
> it harder for a network attacker to abuse these permissions. This
> would affect UX for:
>
> * Geolocation
> * Notification
> * Fullscreen
> * Pointer Lock
> * Popups

What attack is this designed to mitigate? If the user allows an
unsecured site to use (for instance) geolocation, whether persisted or
not, an MITM will be able to get the geolocation info as long as
they're intercepting the traffic, right? And if they have some way to
persist their scripts via injecting modified resources with long cache
timeouts or such, they can still get the info as long as the user
keeps clicking "yes". And the user will definitely keep clicking yes,
because a) they clicked it the first time, and b) you have conditioned
them to click "yes" a million times on the same site. So how does not
persisting this info help at all? Probably I'm missing something
obvious.

[Eric Rescorla]

Let's consider a different example than the one you propose: access
to the camera and microphone via getUserMedia(). Say that a site
adds a feature which lets you take a picture of yourself for your
avatar (come to think of it, I wish github did this). If the permissions
are persistent, then the site (or if HTTPS isn't used, any network
attacker) can access my camera and see what's going on in my
room at any time [0] and largely without my knowledge.
By contrast, if I need to click OK in order to give a remote site access
to my camera (even if I generally do consent without much thought)
this makes the attack much more difficult to mount.

A similar set of argument seem to me to apply to geolocation.
It's one thing to give a temporary grant of access, and quite
another to let any network attacker track me whenever they
want.

-Ekr

P.S. Anne, thanks for raising this issue.


[0] This isn't a hypothetical kind of attack. See, for instance the
description
of ratters in Brocker and Checkoway. page 11.
https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/brocker

[Daniel Veditz]

On Fri, Mar 6, 2015 at 10:18 AM, Ehsan Akhgari <ehsan....@gmail.com>

wrote:

> On 2015-03-06 1:14 PM, andre...@gmail.com wrote:
>
>> I can no longer unblock popups on sites that use HTTP. The web is a big
>> place. It will take a long time for everyone to move.
>>
>
> I think Anne is not proposing that. He's proposing blocking persisting
> those permissions. IOW you would be able to still show popups from these
> websites, but you won't be able to ask Firefox to remember your preference.
>

​When we block a popup we put up an infobar with an "open" button. It
doesn't always work, in particular if the page was trying to get a
reference to the popup window so it can modify content​
​ in response to in-page actions. It won't have that reference because the
original window.open() call failed and the "open" button launches an
orphan window.

I'm all for restricting "powerful" features to HTTPS but popups are not
powerful, they are at worst an annoyance that can be turned back off if
they're abused.

-Dan Veditz

[Anne van Kesteren]

Thanks everyone for weighing in. It sounds like we don't want to touch
popups :-) And yes, negative persistence (never allow) should remain
available.

The Notifications API is a bit in flux and the most interesting
notifications require service workers so are already restricted. I
guess I'm okay with leaving them alone for now.

On Fri, Mar 6, 2015 at 7:04 PM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> Can we make an exception for localhost and its IPv4 and IPv6 equivalents to
> make things easier for web devs? Bonus points if we make a mechanism that
> detects /etc/host overrides (to localhost) and allow it there, too.

I think the exceptions of the "powerful features" document are
"localhost", equivalent hostnames (I can't think of any), and file
URLs. Developer tools should provide overrides. We need overrides for
service workers too.


--
https://annevankesteren.nl/

[Tantek Çelik]

FWIW I am for the original set of HTTPS only restrictions proposed by Anne.

I think doing so sends a strong security minded message, even if some
think "too strong".

Pop-ups:

I realize including pop-ups in this is a minority opinion (judging by
this thread), however, I have not seen a single concrete example by
those defending pop-ups of an HTTP-only site that depends on pop-ups
for functionality for which this change would inconvenience the user.

I am for including pop-ups in this set, at least up to Aurora to test
the hypothesis that others have offered that this would "annoy users",
because frankly, I don't believe it in practice.

Notifications:

For notifications, Anne's argument is correct. They're not widely
adopted yet, so now is a good time to place this restriction on them,
when there is very little of site-breakage risk. If there is
real-world author/developer demand for INSECURE access to web
notifications, we can re-evaluate accordingly.

Blog post:

In addition, as part of landing these restrictions, I think a blog
post by Anne (e.g. perhaps on hacks.mo) on these changes would show
and demonstrate Mozilla's user-security focus and technical
leadership.

Such a blog post could also explicitly note that we do see a spectrum
of differences between things as invasive/creepy as camera access vs.
"just annoying" pop-ups & notifications, and that based on user and
developer feedback we may adjust our implementation accordingly.

Better to secure more things, and then only back-off if/when necessary.

Thanks,

Tantek

On Mon, Mar 9, 2015 at 2:07 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> Thanks everyone for weighing in. It sounds like we don't want to touch
> popups :-) And yes, negative persistence (never allow) should remain
> available.
>
> The Notifications API is a bit in flux and the most interesting
> notifications require service workers so are already restricted. I
> guess I'm okay with leaving them alone for now.
>
> On Fri, Mar 6, 2015 at 7:04 PM, Gijs Kruitbosch
> <gijskru...@gmail.com> wrote:

>> Can we make an exception for localhost and its IPv4 and IPv6 equivalents to
>> make things easier for web devs? Bonus points if we make a mechanism that
>> detects /etc/host overrides (to localhost) and allow it there, too.
>

> I think the exceptions of the "powerful features" document are
> "localhost", equivalent hostnames (I can't think of any), and file
> URLs. Developer tools should provide overrides. We need overrides for
> service workers too.
>
>
> --
> https://annevankesteren.nl/

[Aryeh Gregor]

On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla <e...@rtfm.com> wrote:
> Let's consider a different example than the one you propose: access
> to the camera and microphone via getUserMedia(). Say that a site
> adds a feature which lets you take a picture of yourself for your
> avatar (come to think of it, I wish github did this). If the permissions
> are persistent, then the site (or if HTTPS isn't used, any network
> attacker) can access my camera and see what's going on in my
> room at any time [0] and largely without my knowledge.
> By contrast, if I need to click OK in order to give a remote site access
> to my camera (even if I generally do consent without much thought)
> this makes the attack much more difficult to mount.

So the mitigation applies when:

1) Some users have already persisted the permission for the site.

2) The site asks for the permission either predictably or infrequently
enough that the user is not conditioned to just click "yes" every time
anyway.

A limitation on the mitigation is that if the site asks for the
permission during regular use, the attacker could just make sure that
their permissions request appears at that time, and the user would
click "yes" because they expect the request at that time anyway.
However, this would require the attacker to do some more work, and
would only work some of the time (if the site is expected to ask for
the permission during the MITM'd session).

The disadvantage is that non-secured sites that depend heavily on any
of these permissions would get more annoying to use. "Switch to
HTTPS" is not a reasonable solution. This could be helped by allowing
the user to give permission for the session, but that would also
reduce the effectiveness of the mitigation.

Another point to make is that whenever the site actually requests the
info legitimately (takes a picture, gets geolocation info, etc.), even
a passive MITM could steal the info anyway. Also, if the major
real-world MITM we're talking about is someone intercepting a
non-secured wireless network, the attacker already has physical
proximity, so he a) knows approximate geolocation info and b) could
possibly take a picture by more conventional means.

If I understand correctly, I am not at all sure that the increased
user annoyance is worth the increased protection of user privacy.
These permissions can always get abused anyway by someone hacking the
site the user has given permission to, and in my experience that's
considerably more common than a MITM attack, so users can't really
depend on the permissions not being abused anyway. The incremental
reduction of attack surface doesn't seem to gain us a lot.

I definitely think that there is no basis at all for disabling pop-up
permissions or other things that only affect user convenience. Just
because there's an MITM doesn't mean it warrants being treated as a
security issue -- it's a tradeoff of user convenience vs. user
convenience, and it's obvious that user convenience is better served
by allowing the pop-up permission to be remembered. Privacy vs.
convenience is a less obvious tradeoff to make.

(By the way, I'm very alarmed by your implication that a site with
persisted camera permissions can take pictures whenever it wants. All
it would take is one reasonably large site getting hacked, and tens of
thousands of people could receive "Give me $100 or I'll post pictures
of you in your underwear all over the Internet" threats. I'm much
more worried about server-side hacking or abuse than MITM. I've had
sites I subscribe to hacked multiple times, and one time a site I ran.
I don't think I've even been subject to a real MITM attack.)

[Boris Zbarsky]

On 3/10/15 8:05 AM, Aryeh Gregor wrote:
> So the mitigation applies when:
>
> 1) Some users have already persisted the permission for the site.
>
> 2) The site asks for the permission either predictably or infrequently
> enough that the user is not conditioned to just click "yes" every time
> anyway.

The mitigation applies in this situation:

1) User connects to a MITMed network (e.g. wireless at the airport or
coffeeshop or whatever) which I will henceforth call "the attacker".
2) No matter what site the user loads, the attacker injects a hidden
iframe claiming to be from hostname X that the user has granted a
persistent permissions grant to.
3) The attacker now turns the camera/microphone/whatever.

> A limitation on the mitigation is that if the site asks for the
> permission during regular use, the attacker could just make sure that
> their permissions request appears at that time, and the user would
> click "yes" because they expect the request at that time anyway.
> However, this would require the attacker to do some more work, and
> would only work some of the time (if the site is expected to ask for
> the permission during the MITM'd session).

Right, and only work if the user loads such a site themselves on that
network. If I load cnn.com and get a popup asking whether Google
Hangouts can turn on my camera, I'd get a bit suspicious... (though I
bet a lot of people would just click through anyway).

> "Switch to HTTPS" is not a reasonable solution.

Why not?

> Another point to make is that whenever the site actually requests the
> info legitimately (takes a picture, gets geolocation info, etc.), even
> a passive MITM could steal the info anyway.

Yes, see my attack scenario above.

> I definitely think that there is no basis at all for disabling pop-up
> permissions or other things that only affect user convenience.

I agree.

-Boris

[Steve Fink]

Is there any place in the UI to improve this via messaging? For example,
https://site.com/ => "Would you like to share your camera with
site.com?", but http://site.com/ => "Would you like to permanently share
your camera with any site claiming to be site.com? *Note: Firefox cannot
verify this claim for an http:// URL."

Or something. I'm diverging a little from the question of persistence,
though partly because I was surprised that the permissions dialog in
Nightly doesn't distinguish between a session vs permanent persistence.
Shouldn't there be "For this session only" and "Always" options? (This
isn't purely academic for me. A relative of mine got completely freaked
out by a scam demanding IRS back taxes or something, and she
specifically believed it because the demand page included a snapshot of
her taken with her laptop camera. Her camera is now taped over. Getting
this stuff right matters.)

I also notice that when I grant a site permission to access my camera,
it doesn't show up in Page Info :: Permissions. Geolocation is there.
And I see a camera icon in the address bar.

[Gavin Sharp]

> Is there any place in the UI to improve this via messaging? For example,
> https://site.com/ => "Would you like to share your camera with site.com?",
> but http://site.com/ => "Would you like to permanently share your camera
> with any site claiming to be site.com? *Note: Firefox cannot verify this
> claim for an http:// URL."

To a first approximation, "no". It's incredibly difficult to explain
this threat model to users, and even if we could do that perfectly,
the cognitive burden on them of understanding it and then making
decisions based on that understanding is significant, and not
something we want to put on them. "Only allow the safe thing" is the
only really scalable solution, despite it causing some short-term
compatibility pain.

Gavin

[Patrick McManus]

I have a slight twist in thinking to offer on the topic of persistent
permissions.. part of this falls to the level of spitballing so forgive the
imprecision:

Restricting persistent permissions is essentially about cache poisoning
attacks. The assumptions seem to be that
a] https is not vulnerable
b] every http transaction is as vulnerable as the last

Those are imperfect (which, granted, is not necessarily a reason to not
proceed - but read on for fun!).

wrt A: We know that this assumption around https is a little sketchy due to
the way the root store is commonly ...ummm.. "localized". An enterprise
user allows a new trust anchor for use with their company proxy, during
which time they are by definition MITM'd by consent. I'm not especially
worried about that transaction - such is the nature of the consent. But
then they take that laptop home to a different context without that proxy.
The cached information, in this case a persistent permission, remains.
There is no reason to think the trust between those two environments should
overlap. The HTTP cache has fundamentally the same problem (think about a
ubiquitous resource like ga.js) as the persistent permission.

wrt B: If a user on a home broadband connection conducts a transaction over
plaintext she certainly is exposed to a MITM attack. But repeating that
operation from the same location only adds small marginal risk (i.e. the
risk of the path changing or the actors on that path changing - this can
happen but often does not). OTOH if she moves to her neighbor's wifi or
roams to 4g then its a whole new ballgame. The uri scheme isn't a good
indicator of risk for each click.

Daniel Stenberg has some code that tries to establish an internal
what-network-am-i-on ID. Think of a more fully implemented version of it as
a hash of your network interfaces and MACs, your router's MAC, etc.. Its
currently just used as part of link-change-detection.. but it could make a
pretty interesting part of a cache key for things we are worried about
being poisoned - the result here would be scoping of persistent permissions
to the topology that you accepted them on.

On Fri, Mar 6, 2015 at 12:27 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

> A large number of permissions we currently allow users to store
> persistently for a given origin. I suggest we stop offering that
> functionality when there's no lock in the address bar. This will make
> it harder for a network attacker to abuse these permissions. This
> would affect UX for:
>
> * Geolocation
> * Notification
> * Fullscreen
> * Pointer Lock
> * Popups
>

> If you are interested in demos of how these function today:
>
> * http://dontcallmedom.github.io/web-permissions-req/tests/geo-get.html
> *
> http://dontcallmedom.github.io/web-permissions-req/tests/notification.html
> * http://dontcallmedom.github.io/web-permissions-req/tests/fullscreen.html
> *
> http://dontcallmedom.github.io/web-permissions-req/tests/pointerlock.html
> * http://dontcallmedom.github.io/web-permissions-req/tests/popup.html
>
> Note that we have already implemented this for getUserMedia(). You can
> contrast the UX for these two links:
>
> *
> http://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html
> *
> https://dontcallmedom.github.io/web-permissions-req/tests/gum-audiovideo.html
>
> This seems like a change we can make today that would be better for
> our users and nudge those that require persistence to do the right
> thing, without causing much harm.
>
>
> --
> https://annevankesteren.nl/

[Anne van Kesteren]

On Tue, Mar 10, 2015 at 4:00 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Right, and only work if the user loads such a site themselves on that
> network. If I load cnn.com and get a popup asking whether Google Hangouts
> can turn on my camera, I'd get a bit suspicious... (though I bet a lot of
> people would just click through anyway).

It does seem like there are some improvements we could make here. E.g.
not allow an <iframe> to request certain permissions. Insofar we
haven't already.


--
https://annevankesteren.nl/

[Aryeh Gregor]

On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> The mitigation applies in this situation:
>
> 1) User connects to a MITMed network (e.g. wireless at the airport or
> coffeeshop or whatever) which I will henceforth call "the attacker".
> 2) No matter what site the user loads, the attacker injects a hidden
> iframe claiming to be from hostname X that the user has granted a
> persistent permissions grant to.
> 3) The attacker now turns the camera/microphone/whatever.

Aha, that makes a lot more sense. Thanks. Yes, that does seem like a
more realistic attack. A few points come to mind:

1) The page has no way to know whether it has persisted permissions
without just trying, right? If so, the user will notice something is
weird when he gets strange permissions requests, which makes the
attack less attractive.

2) If the only common real-world MITM threat is via a compromise
adjacent to the client (e.g., wireless), there's no reason to restrict
geolocation, because the attacker already knows the user's location
fairly precisely.

3) Is there any reason to not persist permissions for as long as the
user remains on the same network (assuming we can figure that out
reliably)? If not, the proposal would be much less annoying, because
in many common cases the permission would be persisted for a long time
anyway. Better yet, can we ask the OS whether the network is
classified as home/work/public and only restrict the persistence for
public networks?

4) Feasible though the attack may be, I'm not sure how likely
attackers are to try it. Is there some plausible profit motive here?
Script kiddies will set up websites and portscan with botnets just for
lulz, but a malicious wireless router requires physical presence,
which is much riskier for the attacker. If I compromised a public
wireless router, I would try passively sniffing for credit card info
in people's unencrypted webmail, or steal their login info. Why would
I blow my cover by trying to take pictures of them?

> Right, and only work if the user loads such a site themselves on that
> network. If I load cnn.com and get a popup asking whether Google Hangouts
> can turn on my camera, I'd get a bit suspicious... (though I bet a lot of
> people would just click through anyway).

Especially because it says Google Hangouts wants the permission. Why
wouldn't I give permission to Google Hangouts, if I use it regularly?
Maybe it's a bit puzzling that it's asking me right now, but computers
are weird, it probably has some reason. If it was some site I didn't
recognize I might say no, but not if it's a site I use all the time.

I'm not convinced that the proposal increases real-world security
enough to warrant any reduction at all in user convenience.

>> "Switch to HTTPS" is not a reasonable solution.
>
>
> Why not?

Because unless things have changed a lot in the last three years or
so, HTTPS is a pain for a few reasons:

1) It requires time and effort to set up. Network admins have better
things to do. Most of them either are volunteers, work part-time,
computers isn't their primary job responsibility, they're overworked,
etc.

2) It adds an additional point of failure. It's easy to misconfigure,
and you have to keep the certificate up-to-date. If you mess up,
browsers will helpfully go berserk and tell your users that your site
is trying to hack their computer (or that's what users will infer from
the terrifying bright-red warnings). This is not a simple problem to
solve -- for a long time, https://amazon.com would give a cert error,
and I'm pretty sure I once saw an error on a Google property too. I
think Microsoft too once.

3) Last I checked, if you want a cert that works in all browsers, you
need to pay money. This is a big psychological hurdle for some
people, and may be unreasonable for people who manage a lot of small
domains.

4) It adds round-trips, which is a big deal for people on high-latency
connections. I remember Google was trying to cut it down to one extra
round-trip on the first connection and none on subsequent connections,
but I don't know if that's actually made it into all the major
browsers yet.

These issues seem all basically fixable within a few years, if the
major stakeholders were on board. But until they're fixed, there are
good reasons for sysadmins to be reluctant to use SSL. Ideally,
setting up SSL would like something like this: the webserver
automatically generates a key pair, submits the public key to its
nameserver to be put into its domain's DNSSEC CERT record, queries the
resulting DNSSEC record, and serves it to browsers as its certificate;
and of course automatically re-queries the record periodically so it
doesn't expire. The nameserver can verify the server's IP address
matches the A record to to ensure that it's the right one, unless
someone has compromised the backbone or the nameserver's local
network. In theory you don't need DNSSEC, CACert or whatever would
work too. You would still need SNI in a lot of cases.

Then it would be reasonable to push people to use HTTPS, at least as
an option for people with newer browsers that support the new features
required. An HTTP header to upgrade to HTTPS if the browser supports
the new features might help here.

On Thu, Mar 12, 2015 at 12:28 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> It does seem like there are some improvements we could make here. E.g.
> not allow an <iframe> to request certain permissions. Insofar we
> haven't already.

Does that really help? The attacker could just insert a script to
open a new tab in the background that loads its contents in 5 ms (they
come from the local network, after all) and then closes itself.

[Boris Zbarsky]

On 3/12/15 6:28 AM, Anne van Kesteren wrote:
> It does seem like there are some improvements we could make here. E.g.
> not allow an <iframe> to request certain permissions. Insofar we
> haven't already.

That doesn't help much; the page can just navigate itself to the attack
site instead of loading it in a subframe. Combined with fullscreen
spoofing to make it look like it's still the old page...

-Boris

[Adam Roach]

On 3/12/15 12:26, Aryeh Gregor wrote:
> Because unless things have changed a lot in the last three years or
> so, HTTPS is a pain for a few reasons:
>
> 1) It requires time and effort to set up. Network admins have better
> things to do. Most of them either are volunteers, work part-time,
> computers isn't their primary job responsibility, they're overworked,
> etc.
>
> 2) It adds an additional point of failure. It's easy to misconfigure,
> and you have to keep the certificate up-to-date. If you mess up,
> browsers will helpfully go berserk and tell your users that your site
> is trying to hack their computer (or that's what users will infer from
> the terrifying bright-red warnings). This is not a simple problem to

> solve -- for a long time,https://amazon.com would give a cert error,

> and I'm pretty sure I once saw an error on a Google property too. I
> think Microsoft too once.
>
> 3) Last I checked, if you want a cert that works in all browsers, you
> need to pay money. This is a big psychological hurdle for some
> people, and may be unreasonable for people who manage a lot of small
> domains.
>
> 4) It adds round-trips, which is a big deal for people on high-latency
> connections. I remember Google was trying to cut it down to one extra
> round-trip on the first connection and none on subsequent connections,
> but I don't know if that's actually made it into all the major
> browsers yet.
>
> These issues seem all basically fixable within a few years

As an aside, the first three are not just fixable, but actually fixed
within the next few months: https://letsencrypt.org/


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[Ehsan Akhgari]

Well, top level navigation cancels the fullscreen mode, right?

[Ehsan Akhgari]

On 2015-03-12 8:26 AM, Aryeh Gregor wrote:
> Aha, that makes a lot more sense. Thanks. Yes, that does seem like a
> more realistic attack. A few points come to mind:
>
> 1) The page has no way to know whether it has persisted permissions
> without just trying, right? If so, the user will notice something is
> weird when he gets strange permissions requests, which makes the
> attack less attractive.

FWIW there are attempts to add features to the Web platform which would
let web pages query for the permissions that they have without asking
for the permission. See
<https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/edit#>.

> 2) If the only common real-world MITM threat is via a compromise
> adjacent to the client (e.g., wireless), there's no reason to restrict
> geolocation, because the attacker already knows the user's location
> fairly precisely.

I don't think that is the only common real-world attack. Other types
include your traffic being intercepted by your ISP, and/or your government.

> 3) Is there any reason to not persist permissions for as long as the
> user remains on the same network (assuming we can figure that out
> reliably)? If not, the proposal would be much less annoying, because
> in many common cases the permission would be persisted for a long time
> anyway. Better yet, can we ask the OS whether the network is
> classified as home/work/public and only restrict the persistence for
> public networks?

That would have been a good idea if wifi attacks were the only ones.

> 4) Feasible though the attack may be, I'm not sure how likely
> attackers are to try it. Is there some plausible profit motive here?
> Script kiddies will set up websites and portscan with botnets just for
> lulz, but a malicious wireless router requires physical presence,
> which is much riskier for the attacker. If I compromised a public
> wireless router, I would try passively sniffing for credit card info
> in people's unencrypted webmail, or steal their login info. Why would
> I blow my cover by trying to take pictures of them?

There have been documented cases of webcam spying victims committing
suicide. And I wouldn't be surprised if there are or will be businesses
based on selling people's webcam feeds. Protecting people's physical
privacy is just as important as protecting their digital privacy.

Cheers,
Ehsan

[Boris Zbarsky]

On 3/12/15 10:26 AM, Ehsan Akhgari wrote:
> Well, top level navigation cancels the fullscreen mode, right?

The attack scenario I'm thinking is:

1) User loads http://a.com
2) Attacker immediately sets location to http://b.com
3) Attacker's hacked-up b.com goes fullscreen, pretending to still be
a.com to the user by spoofing browser chrome, while also turning on the
camera because the user granted permission to b.com to do that at some
point.

That sort of thing.

-Boris

[Ehsan Akhgari]

Do you mean that after (2), the user somehow interacts with the site but
doesn't realize that the site has gone full screen? (Note that the
fullscreen API cannot be used outside of user generated event handlers.)

[Boris Zbarsky]

On 3/12/15 12:19 PM, Ehsan Akhgari wrote:
> (Note that the
> fullscreen API cannot be used outside of user generated event handlers.)

Oh, good point. That helps a lot, yes.

-Boris

[Ehsan Akhgari]

So do you think it makes sense to restrict iframes requesting certain
permissions?

The downside is that there are probably legit use cases for iframes
requesting some permissions too, for example it's very common for an
iframe to request fullscreen (e.g. the vimeo video embedding iframes.)
One could envision map widgets implemented as iframes which may want to
geolocate, or Google Hangout/Firefox Hello widgets that let you embed a
video chat service in your website.

Another concern with persisting permissions requested from iframes is
that it's possible to conceive of a TLS website (such as
https://geolocator.com) hosting a widget that for example geolocates you
and window.parent.postMessage()'s the info to the embedder. If
http://goodguy.com embeds this kind of widget in a real mapping app and
the user chooses to grant geolocator.com a persistent permission to
geolocate anywhere (presumably because they trust goodguy.com) and then
evil.com can come around and embed the same widget in a possibly
invisible iframe and profit. Although I'm not sure how realistic this
attack is...

[Boris Zbarsky]

On 3/12/15 1:28 PM, Ehsan Akhgari wrote:
> Another concern with persisting permissions requested from iframes

Can we persist them for the pair (origin of iframe, origin of toplevel
page) or something?

-Boris

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 2:56 PM, Adam Roach <a...@mozilla.com> wrote:
> As an aside, the first three are not just fixable, but actually fixed within
> the next few months: https://letsencrypt.org/

Indeed, and for performance concerns there's a good read here:
https://istlsfastyet.com/ It's no longer an issue, unless you have an
extremely specialized setup that's non-trivial to migrate from
(Netflix).


--
https://annevankesteren.nl/

[Aryeh Gregor]

On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> 2) If the only common real-world MITM threat is via a compromise
>> adjacent to the client (e.g., wireless), there's no reason to restrict
>> geolocation, because the attacker already knows the user's location
>> fairly precisely.
>
>
> I don't think that is the only common real-world attack. Other types
> include your traffic being intercepted by your ISP, and/or your government.

I guess it's hard to say how common those are in practice, or how much
of a concern they are. I agree that for an API that allows taking
pictures without the user's case-by-case permission, it would pay to
err far on the safe side.

I'm actually rather disturbed that such an API even exists. Even if
the site is HTTPS, it could be hacked, or it could be spoofed, or the
operators could just be abusive. Every site must be assumed possibly
malicious, no matter how many permissions dialogs the user clicks
through, and HTTPS can be assumed to be only modestly safer than HTTP.
Why isn't the user prompted before every picture is taken? Is there
really a use-case for allowing a site to take pictures without the
user's case-by-case permission that outweighs the privacy issues?

As for geolocation, I'm still not convinced that it's worth worrying
about here. The ISP and government probably have better ways of
tracking down the user's location. The ISP generally knows where the
Internet connection goes regardless, and the government can probably
get the info from the ISP (after all, it was able to install a MITM).

> There have been documented cases of webcam spying victims committing
> suicide. And I wouldn't be surprised if there are or will be businesses
> based on selling people's webcam feeds. Protecting people's physical
> privacy is just as important as protecting their digital privacy.

Then why only focus on attacks that are foiled by HTTPS? We should be
equally concerned with attacks that HTTPS doesn't prevent, which I
think are probably much more common.

On Thu, Mar 12, 2015 at 5:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> The attack scenario I'm thinking is:
>
> 1) User loads http://a.com
> 2) Attacker immediately sets location to http://b.com
> 3) Attacker's hacked-up b.com goes fullscreen, pretending to still be a.com
> to the user by spoofing browser chrome, while also turning on the camera
> because the user granted permission to b.com to do that at some point.

How about:

1) User loads http://a.com

2) Attacker opens a background tab and navigates it to http://b.com (I
can't think of a JavaScript way to do this, but if there isn't one,
making a big <a href="b.com" target=_blank> that covers the whole page
would work well enough)
3) http://b.com loads in 10 ms because it's really being served by the
MITM, uses the permission, and closes itself

[Boris Zbarsky]

On 3/12/15 3:31 PM, Aryeh Gregor wrote:
> 2) Attacker opens a background tab and navigates it to http://b.com (I
> can't think of a JavaScript way to do this, but if there isn't one,
> making a big <a href="b.com" target=_blank> that covers the whole page
> would work well enough)

This is presuming user interaction. I agree that attacks that rely on
user interaction are also a problem here, but I'm _really_ scared by the
potential of no-interaction needed attacks, which can happen when the
user is not even actively using the computer. Maybe it's just me.

-Boris

[Eric Rescorla]

On Thu, Mar 12, 2015 at 12:31 PM, Aryeh Gregor <a...@aryeh.name> wrote:

> On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
> >> 2) If the only common real-world MITM threat is via a compromise
> >> adjacent to the client (e.g., wireless), there's no reason to restrict
> >> geolocation, because the attacker already knows the user's location
> >> fairly precisely.
> >
> >
> > I don't think that is the only common real-world attack. Other types
> > include your traffic being intercepted by your ISP, and/or your
> government.
>
> I guess it's hard to say how common those are in practice, or how much
> of a concern they are. I agree that for an API that allows taking
> pictures without the user's case-by-case permission, it would pay to
> err far on the safe side.
>
> I'm actually rather disturbed that such an API even exists. Even if
> the site is HTTPS, it could be hacked, or it could be spoofed, or the
> operators could just be abusive. Every site must be assumed possibly
> malicious, no matter how many permissions dialogs the user clicks
> through, and HTTPS can be assumed to be only modestly safer than HTTP.
> Why isn't the user prompted before every picture is taken? Is there
> really a use-case for allowing a site to take pictures without the
> user's case-by-case permission that outweighs the privacy issues?
>

Yes. User consent failure represents a large fraction of failures on
video conferencing sites. Also, continually prompting users for
permissions weakens protections against users granting consent
to malicious sites.

See also Adam Barth's
"Prompting the User Is a Security Failure" at
http://rtc-web.alvestrand.com/home/papers

-Ekr

> As for geolocation, I'm still not convinced that it's worth worrying
> about here. The ISP and government probably have better ways of
> tracking down the user's location. The ISP generally knows where the
> Internet connection goes regardless, and the government can probably
> get the info from the ISP (after all, it was able to install a MITM).
>
> > There have been documented cases of webcam spying victims committing
> > suicide. And I wouldn't be surprised if there are or will be businesses
> > based on selling people's webcam feeds. Protecting people's physical
> > privacy is just as important as protecting their digital privacy.
>
> Then why only focus on attacks that are foiled by HTTPS? We should be
> equally concerned with attacks that HTTPS doesn't prevent, which I
> think are probably much more common.
>
> On Thu, Mar 12, 2015 at 5:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> > The attack scenario I'm thinking is:
> >
> > 1) User loads http://a.com
> > 2) Attacker immediately sets location to http://b.com
> > 3) Attacker's hacked-up b.com goes fullscreen, pretending to still be
> a.com
> > to the user by spoofing browser chrome, while also turning on the camera
> > because the user granted permission to b.com to do that at some point.
>
> How about:
>
> 1) User loads http://a.com

> 2) Attacker opens a background tab and navigates it to http://b.com (I
> can't think of a JavaScript way to do this, but if there isn't one,
> making a big <a href="b.com" target=_blank> that covers the whole page
> would work well enough)

> 3) http://b.com loads in 10 ms because it's really being served by the
> MITM, uses the permission, and closes itself

[Aryeh Gregor]

What's the use of taking a picture if the user isn't actively using
the computer? Also, the user will almost certainly return to the
computer at some point, and the attacker can probably wait till then.

On Thu, Mar 12, 2015 at 10:53 PM, Eric Rescorla <e...@rtfm.com> wrote:
> Yes. User consent failure represents a large fraction of failures on
> video conferencing sites.

Hmm. I guess I'm not qualified to say whether this is worth it, but
it still does scare me. Would these sites care if they have to be
HTTPS?

> Also, continually prompting users for
> permissions weakens protections against users granting consent
> to malicious sites.
>
> See also Adam Barth's
> "Prompting the User Is a Security Failure" at
> http://rtc-web.alvestrand.com/home/papers

Thoroughly agreed, and that is exactly what this proposal would do --
make users click through lots of extra permissions dialogs.

[Ehsan Akhgari]

Yes, that sounds like a good idea to me.

[Boris Zbarsky]

On 3/16/15 8:10 AM, Aryeh Gregor wrote:
> What's the use of taking a picture if the user isn't actively using
> the computer?

You get to see whatever the user _is_ doing at the time. You seriously
don't see the use of that, especially for nefarious ends?

> Also, the user will almost certainly return to the
> computer at some point, and the attacker can probably wait till then.

The point, from an attacker's point of view, is not to get a picture of
the user. The point is to get information, including pictures, that can
then be sold to the highest bidder. A photo of the user doing all sorts
of non-computer-related things is worth way more to a potential
blackmailer, say, than a photo of the user's face.

-Boris

[Eric Rescorla]

On Mon, Mar 16, 2015 at 5:10 AM, Aryeh Gregor <a...@aryeh.name> wrote:

> What's the use of taking a picture if the user isn't actively using

> the computer? Also, the user will almost certainly return to the

> computer at some point, and the attacker can probably wait till then.

Lots of people have the cameras in their rooms pointing at them even when
they are not using the computer, and so the camera can be used to spy on
them (Again, I refer you to Checkoway's description of "ratting" [1]). This
might be more obvious if you think about the microphone. I assume you can
see the value of my remotely accessing the microphone on your phone even
when you are not actively using it?

> On Thu, Mar 12, 2015 at 10:53 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > Yes. User consent failure represents a large fraction of failures on
> > video conferencing sites.
>
> Hmm. I guess I'm not qualified to say whether this is worth it, but
> it still does scare me. Would these sites care if they have to be
> HTTPS?

They already have to be HTTPS. The background for this discussion is that
getUserMedia() enforces the policy that Anne is proposing.

>
> > Also, continually prompting users for
> > permissions weakens protections against users granting consent
> > to malicious sites.
> >
> > See also Adam Barth's
> > "Prompting the User Is a Security Failure" at
> > http://rtc-web.alvestrand.com/home/papers
>
> Thoroughly agreed, and that is exactly what this proposal would do --
> make users click through lots of extra permissions dialogs.
>

I'm really confused by what you are arguing for, since the text that you
quote is a response to you writing

"Why isn't the user prompted before every picture is taken? Is there
really a use-case for allowing a site to take pictures without the
user's case-by-case permission that outweighs the privacy issues?"

So I took from this that you wanted a consent prompt every time.

What Anne is proposing (and I support) is that the browser be allowed to
persist consent only on HTTPS sites (the details of when it would do
so vary between APIs and between browsers, perhaps). This is the current
state of play for getUserMedia (camera and microphone) but not for other
APIs. How is it you believe that the browser should behave?

-Ekr




[1]
https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/brock
<https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/brocker>
er

[Karl Dubost]

Aryeh,

Le 16 mars 2015 à 21:10, Aryeh Gregor <a...@aryeh.name> a écrit :
> What's the use of taking a picture if the user isn't actively using
> the computer?

http://www.huffingtonpost.com/hemanshu-nigam/internet-hacking-protection_b_2641370.html

> Hacker-voyeurs easily access almost any computer and spy on victims through cameras. Within just a few minutes, they manipulate viruses sent via links or content downloads that create opportunities to hijack webcams. Unfortunately, many victims do not realize they are being watched. One such hacker, Luis Mijangos, spied on more than 200 women by disabling the LED on the webcam in order to avoid any suspicion. He then went on to blackmail his victims and threatened to post the images online, unless they continued to send him more racy and nude photos. He ultimately followed through on one threat, posting photos to one of his victim's MySpace page.


See also
http://www.wired.com/2014/03/webcams-mics/

Another one which is rarely mention and as invasive if not more is the computer mic.

I do have a sticker on my cam all the time except during videoconf, because hey you never know.

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Karl Dubost]

[Aryeh Gregor]

On Mon, Mar 16, 2015 at 3:24 PM, Eric Rescorla <e...@rtfm.com> wrote:
> Lots of people have the cameras in their rooms pointing at them even when
> they are not using the computer, and so the camera can be used to spy on
> them (Again, I refer you to Checkoway's description of "ratting" [1]). This
> might be more obvious if you think about the microphone. I assume you can
> see the value of my remotely accessing the microphone on your phone even
> when you are not actively using it?

Yes, that makes it perfectly clear. Thank you.

> They already have to be HTTPS. The background for this discussion is that
> getUserMedia() enforces the policy that Anne is proposing.

I was unaware of that. That sounds very reasonable.

> I'm really confused by what you are arguing for, since the text that you
> quote is a response to you writing
>

> "Why isn't the user prompted before every picture is taken? Is there
> really a use-case for allowing a site to take pictures without the
> user's case-by-case permission that outweighs the privacy issues?"
>

> So I took from this that you wanted a consent prompt every time.

I want that for getUserMedia, yes. It scares me that even HTTPS sites
are allowed to persist this permission, because server-side
compromises are common. But if we have to allow it at all, it makes
sense to limit the attack surface as much as possible, even if I'm not
sure about how effective this measure is in preventing attacks in
practice.

> What Anne is proposing (and I support) is that the browser be allowed to
> persist consent only on HTTPS sites (the details of when it would do
> so vary between APIs and between browsers, perhaps). This is the current
> state of play for getUserMedia (camera and microphone) but not for other
> APIs. How is it you believe that the browser should behave?

I think this makes sense for getUserMedia, at a minimum. I think
other APIs need to be considered on a case-by-case basis, because this
doesn't fully solve the security problem, annoys the user, and causes
permissions-prompt fatigue. I don't think a blanket policy of only
persisting any permissions over HTTPS is a good idea, e.g., for
pop-ups. So I think I actually more or less agree with most people
here after all. :)

[Aryeh Gregor]

On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach <a...@mozilla.com> wrote:
> As an aside, the first three are not just fixable, but actually fixed within
> the next few months: https://letsencrypt.org/

That seems like a huge step forward. But putting my ex-sysadmin hat
on -- assuming it works as advertised, there are still significant
remaining practical issues for at least some sites:

1) SNI is reportedly still not usable if you care about IE on XP.
This means HTTPS is not usable on shared hosting, which is most small
sites, unless you don't care that your site doesn't load in IE on XP.
This is also a problem for larger sites whose content is accessible
via multiple domains (even just www.foo.com vs. foo.com), unless they
want to get an IP address per domain. For instance, Wikipedia serves
a whole bunch of second-level domains (wikipedia.org, wikimedia.org,
wiktionary.org, etc.) from the same servers, and to support HTTPS,
they needed to reconfigure their site so that all of these were
different IP addresses.

2) If you want to support access via both HTTP and HTTPS for whatever
reason, you have to make sure your content uses protocol-relative URLs
exclusively, which means making modifying the software that runs on
your site. Otherwise users will click a link and get sent back to the
insecure site without noticing. This could include user-provided
URLs. You could just use HTTPS exclusively, but that's a somewhat
bigger step to take.

3) If you include third-party scripts that are not available over
HTTPS, at least Chrome will helpfully break your site until your users
click through a permissions dialog, if I remember correctly.

4) According to the O'Reilly book linked from istlsfastyet.com,
best-case TLS usage still adds a round-trip to every connection.
Common non-best-case scenarios are worse (e.g., IE < 10 apparently
doesn't support False Start). This is a nontrivial performance
penalty.

There are probably other practical issues that will crop up on
specific sites. It's still a change that requires nonzero effort to
test and deploy, and has downsides, so using HTTPS is not necessarily
a no-brainer for everyone. For instance, Wikimedia took a long time
to deploy HTTPS, even though setting up certificates was not an issue,
because of the various side issues that had to be handled (at least 1
and 2). So "use HTTPS" isn't an easy solution for everyone. But yes,
this project should remove one of the big issues for a lot of people.

[Martin Thomson]

On Tue, Mar 17, 2015 at 12:05 PM, Aryeh Gregor <a...@aryeh.name> wrote:
> 1) SNI is reportedly still not usable if you care about IE on XP.
> This means HTTPS is not usable on shared hosting, which is most small
> sites, unless you don't care that your site doesn't load in IE on XP.
> This is also a problem for larger sites whose content is accessible
> via multiple domains (even just www.foo.com vs. foo.com), unless they
> want to get an IP address per domain. For instance, Wikipedia serves
> a whole bunch of second-level domains (wikipedia.org, wikimedia.org,
> wiktionary.org, etc.) from the same servers, and to support HTTPS,
> they needed to reconfigure their site so that all of these were
> different IP addresses.

I'm not sure that IE on XP is worth caring about (also, IE7 is OK).

> 2) If you want to support access via both HTTP and HTTPS for whatever
> reason, you have to make sure your content uses protocol-relative URLs
> exclusively, which means making modifying the software that runs on
> your site. Otherwise users will click a link and get sent back to the
> insecure site without noticing. This could include user-provided
> URLs. You could just use HTTPS exclusively, but that's a somewhat
> bigger step to take.

HSTS.

> 3) If you include third-party scripts that are not available over
> HTTPS, at least Chrome will helpfully break your site until your users
> click through a permissions dialog, if I remember correctly.

Upgrade is coming (see webappsec).

> 4) According to the O'Reilly book linked from istlsfastyet.com,
> best-case TLS usage still adds a round-trip to every connection.
> Common non-best-case scenarios are worse (e.g., IE < 10 apparently
> doesn't support False Start). This is a nontrivial performance
> penalty.

TLS 1.3 can have data in the first flight sometimes. Or you could
avoid most of the connection setup issues and use HTTP/2, which for
the general case will improve performance (unless your site consists
of too few resources to benefit, that is).