Re: Intent to deprecate: persistent permissions over HTTP

[Martin Thomson]

On Tue, Mar 17, 2015 at 12:05 PM, Aryeh Gregor  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).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Mon, Mar 16, 2015 at 3:24 PM, Eric Rescorla  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.  :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Karl Dubost]

Aryeh,

Le 16 mars 2015 à 21:10, Aryeh Gregor  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Karl Dubost]

Aryeh,

Le 16 mars 2015 à 21:10, Aryeh Gregor  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Eric Rescorla]

On Mon, Mar 16, 2015 at 5:10 AM, Aryeh Gregor  wrote:

> On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky  wrote:
> > 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  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.
>
> 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  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

er
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-12 2:06 PM, Boris Zbarsky wrote:

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?


Yes, that sounds like a good idea to me.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky  wrote:
> 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  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.

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  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Eric Rescorla]

On Thu, Mar 12, 2015 at 12:31 PM, Aryeh Gregor  wrote:

> On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari 
> 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  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  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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari  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  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  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 2:56 PM, Adam Roach  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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-12 12:57 PM, Boris Zbarsky wrote:

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.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-12 11:24 AM, Boris Zbarsky wrote:

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.


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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

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



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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-12 9:45 AM, Boris Zbarsky wrote:

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


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky  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

Re: Intent to deprecate: persistent permissions over HTTP

[Anne van Kesteren]

On Tue, Mar 10, 2015 at 4:00 PM, Boris Zbarsky  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  to request certain permissions. Insofar we
haven't already.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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  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/
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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

On Tue, Mar 10, 2015 at 8:48 AM, Steve Fink  wrote:
> 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.
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla  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.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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  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
>  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/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
 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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Daniel Veditz]

On Fri, Mar 6, 2015 at 10:18 AM, Ehsan Akhgari 
wrote:

> On 2015-03-06 1:14 PM, andreas@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Eric Rescorla]

On Sat, Mar 7, 2015 at 11:48 AM, Aryeh Gregor  wrote:

> On Fri, Mar 6, 2015 at 7:27 PM, 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. 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.


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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Aryeh Gregor]

On Fri, Mar 6, 2015 at 7:27 PM, 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. 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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Jesper Kristensen]

Den 06-03-2015 kl. 19:04 skrev 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


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Justin Dolske]

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 
wrote:

> On 2015-03-06 1:23 PM, andreas@gmail.com wrote:
>
>>
>>  On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari 
>>> wrote:
>>>
>>> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>>>

  On Mar 6, 2015, at 5:52 PM, Anne van Kesteren 
> wrote:
>
> On Fri, Mar 6, 2015 at 6:33 PM,   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.
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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,   wrote:
>
>> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari  wrote:
>>
>> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>>>
 On Mar 6, 2015, at 5:52 PM, Anne van Kesteren  wrote:

 On Fri, Mar 6, 2015 at 6:33 PM,   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-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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  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 
> wrote:
>
>> On 2015-03-06 1:23 PM, andreas@gmail.com wrote:
>>
>>>
>>>  On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari 
 wrote:

 On 2015-03-06 1:14 PM, andreas@gmail.com wrote:

>
>  On Mar 6, 2015, at 5:52 PM, Anne van Kesteren 
>> wrote:
>>
>> On Fri, Mar 6, 2015 at 6:33 PM,   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.
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Bobby Holley]

On Fri, Mar 6, 2015 at 12:10 PM, Jonas Sicking  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Jonas Sicking]

On Fri, Mar 6, 2015 at 10:12 AM,   wrote:
>>
>> 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?

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-06 1:23 PM, andreas@gmail.com wrote:



On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari  wrote:

On 2015-03-06 1:14 PM, andreas@gmail.com wrote:



On Mar 6, 2015, at 5:52 PM, Anne van Kesteren  wrote:

On Fri, Mar 6, 2015 at 6:33 PM,   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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[andreas . gal]

> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari  wrote:
> 
> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>> 
>>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren  wrote:
>>> 
>>> On Fri, Mar 6, 2015 at 6:33 PM,   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-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Ehsan Akhgari]

On 2015-03-06 1:14 PM, andreas@gmail.com wrote:



On Mar 6, 2015, at 5:52 PM, Anne van Kesteren  wrote:

On Fri, Mar 6, 2015 at 6:33 PM,   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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[andreas . gal]

> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren  wrote:
> 
> On Fri, Mar 6, 2015 at 6:33 PM,   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/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[andreas . gal]

> 
> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Martin Thomson]

On Fri, Mar 6, 2015 at 9:27 AM, Anne van Kesteren  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,  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[Anne van Kesteren]

On Fri, Mar 6, 2015 at 6:33 PM,   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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: persistent permissions over HTTP

[andreas . gal]

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

> On Mar 6, 2015, at 5:27 PM, 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. 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/
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform