Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

[Henri Sivonen]

On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>> Is current gUM restricted to authenticated origins? If it isn't, is it
>> realistic to restrict it to authenticated origins?
>
> That's a good idea but it's a separate issue.

Is it already being pursued or should I file a bug?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Robert O'Callahan]

On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi>
> wrote:
> >> Is current gUM restricted to authenticated origins? If it isn't, is it
> >> realistic to restrict it to authenticated origins?
> >
> > That's a good idea but it's a separate issue.
>
> Is it already being pursued or should I file a bug?
>

I don't know.

How about other site-specific sticky state? about:permissions suggests the
full list is
* Passwords
* Geolocation
* gUM
* Cookies
* Popup windows
* Offline storage
* Fullscreen
Cookies are segregated by http vs https, right? I hope other kinds of
offline storage, and passwords, are as well. Popup windows are just a
nuisance so not important here. That leaves gUM, geolocation and
fullscreen. Can we make them all require TLS?

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Henri Sivonen]

On Fri, Sep 5, 2014 at 1:47 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>>
>> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org>
>> wrote:
>> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi>
>> > wrote:
>> >> Is current gUM restricted to authenticated origins? If it isn't, is it
>> >> realistic to restrict it to authenticated origins?
>> >
>> > That's a good idea but it's a separate issue.
>>
>> Is it already being pursued or should I file a bug?
>
>
> I don't know.
>
> How about other site-specific sticky state? about:permissions suggests the
> full list is
> * Passwords

It's not really worthwhile not to remember passwords on http origins,
since the user will then type the password anyway, so we can't really
protect the user against an active MITM going after passwords on http
sites.

> * Geolocation

In principle, I think geolocation should be restricted to
authenticated origins. Unfortunately, it might be too late
compatibility-wise to do that at this point. Also, since the
geolocation responses are easily proxied over postMessage, I think the
potential for wind is less than with gUM, whose response is a special
kind of object that doesn't travel (I hope!) over postMessage.

> * gUM

Yes. I'm hoping that the non-demo uses of gUM are already often enough
on authenticated origins for it not to be too late to restrict gUM to
authenticated origins.

> * Cookies

Being able to limit cookies to authenticated origins only would be a
big win, but it would probably "break the Web "too much. :-(

> * Popup windows

As far as annoyances go, Web Notifications require a permission, right?

> * Offline storage

This one is tricky, since it is somewhere between cookies, which we
probably can't fix, and Service Workers, which we can. Probably by
now, it would "break the Web" too much to limit offline storage to
authenticated origins only.

> * Fullscreen

Unfortunately, this has use cases together with MSE and sites that use
MSE will probably have the hardest time migrating to authenticated
origins, because mixed-content XHR is blocked, MSE assumes the media
data to be fetched using XHR and migrating the media data to https is
a big deal. Assuming that all browsers together don't adopt some way
to do mixed-content XHR such that the response data can't be read by
JS but can be pushed to MSE. Since MSE is already out there in IE,
Chrome and test versions of Safari and we are under notable pressure
to ship MSE ASAP, it seems too late to introduce such a mixed-content
exception mechanism for XHR. :-(

> Cookies are segregated by http vs https, right?

Cookies marked secure and served over https are. Cookies not marked
secure infamously are not. (And the Same Origin violations of cookies
don't even stop at the scheme, since they aren't fully segregated by
host name, either. It's very sad.)

> I hope other kinds of
> offline storage, and passwords, are as well.

My understanding is that stuff other than cookies is Origin-based, so
the scheme matters.

> Popup windows are just a
> nuisance so not important here.

Yes.

> That leaves gUM, geolocation and fullscreen.
> Can we make them all require TLS?

For the reasons given above, I think we could require authenticated
origin for gUM but not fullscreen. Requiring an authenticated origin
for geolocation would break things, but we *might* be able to live
with the level of breakage. (Though likely not.)

[Eric Rescorla]

On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi>
> wrote:
> >> Is current gUM restricted to authenticated origins? If it isn't, is it
> >> realistic to restrict it to authenticated origins?
> >
> > That's a good idea but it's a separate issue.
>
> Is it already being pursued or should I file a bug?

It's not being pursued. It was considered in the WG and rejected.

-Ekr

[Chris Peterson]

On 9/5/14 4:39 AM, Henri Sivonen wrote:
>> >* Geolocation
> In principle, I think geolocation should be restricted to
> authenticated origins. Unfortunately, it might be too late
> compatibility-wise to do that at this point. Also, since the
> geolocation responses are easily proxied over postMessage, I think the
> potential for wind is less than with gUM, whose response is a special
> kind of object that doesn't travel (I hope!) over postMessage.

Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use
HTTP. Before we could restrict geolocation to authenticated origins, we
would need to convince Microsoft and MapQuest to use HTTPS (or whitelist
their sites).


chris

[Ehsan Akhgari]

Those are not the only websites using the API. There are many more. I
think we have probably lost our chance to make any changes here.

[Chris Peterson]

On 9/5/14 2:38 PM, Ehsan Akhgari wrote:
>> Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use
>> HTTP. Before we could restrict geolocation to authenticated origins, we
>> would need to convince Microsoft and MapQuest to use HTTPS (or whitelist
>> their sites).
>

> Those are not the only websites using the API. There are many more.
> I think we have probably lost our chance to make any changes here.

Yes. Sorry, I didn't make myself clear. I meant that, if major map
websites like Bing and MapQuest are using geolocation without HTTPS,
then the longtail of HTTP sites is probably too long to ever fix. :\

[Ehsan Akhgari]

On 2014-09-05, 5:46 PM, Chris Peterson wrote:
>
> On 9/5/14 2:38 PM, Ehsan Akhgari wrote:

>>> Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use
>>> HTTP. Before we could restrict geolocation to authenticated origins, we
>>> would need to convince Microsoft and MapQuest to use HTTPS (or whitelist
>>> their sites).
>>

>> Those are not the only websites using the API. There are many more. I
>> think we have probably lost our chance to make any changes here.
>
> Yes. Sorry, I didn't make myself clear. I meant that, if major map
> websites like Bing and MapQuest are using geolocation without HTTPS,
> then the longtail of HTTP sites is probably too long to ever fix. :\

Yep, unfortunately, agreed!

[Martin Thomson]

One idea that has been floated (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict persistent permissions to secure origins. The reasoning there being that a persistent grant can be trivially intercepted if you work in the clear. That's a real security concern. One that gUM requires.

We might like to consider extending that to geolocation too. But it's not clear that the security benefits are outweighed by the inconvenience. The real solution is for those sites to get their act together, but that's a tall order.

I agree with Henri and others who have said that we shouldn't be following Google's example regarding restricting feature access to secure origins though.

----- Original Message -----
From: "Ehsan Akhgari" <ehsan....@gmail.com>
To: "Chris Peterson" <cpet...@mozilla.com>, dev-pl...@lists.mozilla.org
Sent: Friday, September 5, 2014 2:53:21 PM
Subject: Re: Restricting gUM to authenticated origins only

On 2014-09-05, 5:46 PM, Chris Peterson wrote:
>
> On 9/5/14 2:38 PM, Ehsan Akhgari wrote:

>>> Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use
>>> HTTP. Before we could restrict geolocation to authenticated origins, we
>>> would need to convince Microsoft and MapQuest to use HTTPS (or whitelist
>>> their sites).
>>

>> Those are not the only websites using the API. There are many more. I
>> think we have probably lost our chance to make any changes here.
>
> Yes. Sorry, I didn't make myself clear. I meant that, if major map
> websites like Bing and MapQuest are using geolocation without HTTPS,
> then the longtail of HTTP sites is probably too long to ever fix. :\

Yep, unfortunately, agreed!

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

[Mounir Lamouri]

On Sat, 6 Sep 2014, at 14:49, Martin Thomson wrote:
> One idea that has been floated
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict
> persistent permissions to secure origins. The reasoning there being that
> a persistent grant can be trivially intercepted if you work in the clear.
> That's a real security concern. One that gUM requires.

That sounds interesting. I guess in this case you would want to mark the
permission as session-specific with an expire time of a few hours? If
there is a way to know whether a nsIPrincipal is associated with an
authenticated origin, it should be fairly simple to implement inside
nsPermissionManager. Though, it might require some UI, wouldn't it?

-- Mounir

[Martin Thomson]

It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist.

----- Original Message -----
From: "Mounir Lamouri" <mou...@lamouri.fr>
To: "Martin Thomson" <m...@mozilla.com>, "Ehsan Akhgari" <ehsan....@gmail.com>
Cc: "Chris Peterson" <cpet...@mozilla.com>, dev-pl...@lists.mozilla.org
Sent: Saturday, September 6, 2014 6:28:05 AM
Subject: Re: Restricting gUM to authenticated origins only

[Jesper Kristensen]

Den 05-09-2014 kl. 12:47 skrev Robert O'Callahan:
> Cookies are segregated by http vs https, right?

No, unfortunately they are not. Numerous attempts at fixing it has been
rejected by browser vendors. For example
http://tools.ietf.org/html/draft-abarth-cake-01

[Henri Sivonen]

Do *you* think the WG's stance on this was and continues to be the
right call for our users?

Do you have a pointer to the WG's rationale for the rejection? I tried
to search for it, but I failed to find either a decision or rationale.
The closest I could find was
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats
https origins as special and says that stored permissions should only
be available for them.

[Mounir Lamouri]

On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote:
> It's more the case that a persistent positive grant from permission
> manager would be ignored for non-secure origins and non-secure origins
> would not show any option to persist.

I don't know the specifics about the UI, but you don't want to have a
prompt showing up every time a call to an API is being made. It would be
terribly frustrating for users and developers.

-- Mounir

[Henri Sivonen]

Considering that the remedy would be migrating the app to an
authenticated origin, how useful is it to have gUM available (without
persistent permissions) for unauthenticated origins?

[Eric Rescorla]

On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla <e...@rtfm.com> wrote:
> >
> >
> >
> > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen <hsiv...@hsivonen.fi>
> wrote:
> >>
> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan <rob...@ocallahan.org
> >
> >> wrote:
> >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi>
> >> > wrote:
> >> >> Is current gUM restricted to authenticated origins? If it isn't, is
> it
> >> >> realistic to restrict it to authenticated origins?
> >> >
> >> > That's a good idea but it's a separate issue.
> >>
> >> Is it already being pursued or should I file a bug?
> >
> >
> > It's not being pursued. It was considered in the WG and rejected.
>
> Do *you* think the WG's stance on this was and continues to be the
> right call for our users
>

Eh.. Not sure. AFAIK, there's not much of a reason why arbitary
sites shouldn't be able to access your camera and microphone, provided
that you're not placing trust in the site to do anything in particular
with your data. With that said, I wouldn't be upset if HTTPS was required
here, and at one point I argued for that for PeerConnection on the grounds
that the apparent security properties weren't the real ones.

> Do you have a pointer to the WG's rationale for the rejection? I tried
> to search for it, but I failed to find either a decision or rationale.
> The closest I could find was
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats
> https origins as special and says that stored permissions should only
> be available for them.

It was less a rationale than a lack of people being convinced. I raised it
once
or twice and there were a lot of people strongly opposed, and since the
default
is that things work on HTTP, that's where it stayed.

-Ekr

[Martin Thomson]

On 07/09/14 07:09, Jesper Kristensen wrote:
>> Cookies are segregated by http vs https, right?
>
> No, unfortunately they are not. Numerous attempts at fixing it has been
> rejected by browser vendors. For example
> http://tools.ietf.org/html/draft-abarth-cake-01

They are, somewhat.

All cookies are available to an https origin, but some are restricted so
that http origins can't see them.

https://tools.ietf.org/html/rfc6265#section-5.4
* If the cookie's secure-only-flag is true, then the request-
uri's scheme must denote a "secure" protocol (as defined by
the user agent).

[Martin Thomson]

On 08/09/14 04:05, Henri Sivonen wrote:
> Considering that the remedy would be migrating the app to an
> authenticated origin, how useful is it to have gUM available (without
> persistent permissions) for unauthenticated origins?

That's been the question people have asked, and I think that the answer
was that we don't want to break test pages and that sort of thing
unnecessarily.

[Anne van Kesteren]

Whoa, that definitely seems like the wrong way to prioritize things.
Tests or demos should not influence design choices.

[Martin Thomson]

On 08/09/14 10:08, Anne van Kesteren wrote:
>> >That's been the question people have asked, and I think that the answer was
>> >that we don't want to break test pages and that sort of thing unnecessarily.
> Whoa, that definitely seems like the wrong way to prioritize things.
> Tests or demos should not influence design choices.

Don't look at me. My assessment is that this isn't superb, but it's not
a hill worth dying on. You are welcome to disagree, of course:
public-med...@w3.org

[Jesper Kristensen]

Yes, the abstract in the linked spec draft clearly states this: You can
establish cookie confidentiality using the Secure flag, but it is not
possible today to establish cookie integrity.

[Daniel Veditz]

On 9/8/2014 2:16 AM, Mounir Lamouri wrote:
> On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote:
>> It's more the case that a persistent positive grant from permission
>> manager would be ignored for non-secure origins and non-secure origins
>> would not show any option to persist.
>
> I don't know the specifics about the UI, but you don't want to have a
> prompt showing up every time a call to an API is being made. It would be
> terribly frustrating for users and developers.

It wouldn't be every API call, it'd be the first API call. Would it help
to have an option to remember for the session (rather than
per-document)? We have no guarantee that the foo.com you connect to
tomorrow is the same foo.com you trusted today, especially if you're
connecting to a new network (e.g. coffee shop, airport, hotel).

-Dan Veditz

[Martin Thomson]

On 08/09/14 17:10, Daniel Veditz wrote:
> It wouldn't be every API call, it'd be the first API call. Would it help
> to have an option to remember for the session (rather than
> per-document)? We have no guarantee that the foo.com you connect to
> tomorrow is the same foo.com you trusted today, especially if you're
> connecting to a new network (e.g. coffee shop, airport, hotel).

We do have a little leeway with how long a non-persistent grant lives,
but I'm not sure that there are many cases where you wouldn't want to
ask again.

For something like gUM, it's generally only the case that you want one
anyway. So persisting grant until navigate doesn't help much, and there
are definitely cases where it's harmful.

[Henri Sivonen]

On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla <e...@rtfm.com> wrote:
> On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
>> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla <e...@rtfm.com> wrote:
>> > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen <hsiv...@hsivonen.fi>
>> > wrote:
>> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan
>> >> <rob...@ocallahan.org>
>> >> wrote:
>> >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen <hsiv...@hsivonen.fi>
>> >> > wrote:
>> >> >> Is current gUM restricted to authenticated origins? If it isn't, is
>> >> >> it
>> >> >> realistic to restrict it to authenticated origins?
>> >> >
>> >> > That's a good idea but it's a separate issue.
>> >>
>> >> Is it already being pursued or should I file a bug?
>> >
>> > It's not being pursued. It was considered in the WG and rejected.
>>
>> Do *you* think the WG's stance on this was and continues to be the
>> right call for our users
>
>
> Eh.. Not sure. AFAIK, there's not much of a reason why arbitary
> sites shouldn't be able to access your camera and microphone, provided
> that you're not placing trust in the site to do anything in particular
> with your data.

I can see that being a valid abstract argument. I wonder, though, if
there are non-demo use cases where it's appropriate to ask the user to
assume lack of trust. Considering that camera and microphone are
particularly privacy-sensitive, I'm worried about not erring on the
side of privacy in the absence of non-test, non-demo use cases for
allowing gUM on http: origins.

> With that said, I wouldn't be upset if HTTPS was required
> here, and at one point I argued for that for PeerConnection on the grounds
> that the apparent security properties weren't the real ones.

OK.

>> Do you have a pointer to the WG's rationale for the rejection? I tried
>> to search for it, but I failed to find either a decision or rationale.
>> The closest I could find was
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats
>> https origins as special and says that stored permissions should only
>> be available for them.
>
> It was less a rationale than a lack of people being convinced. I raised it
> once
> or twice and there were a lot of people strongly opposed, and since the
> default
> is that things work on HTTP, that's where it stayed.

Do you recall when this happened and if Chrome representatives were
against restricting gUM to authenticated origins?

Except as a path dependency thing where you assume you never change
things you've already shipped, Chrome's situation of restricting Web
Crypto to authenticated origins but not restricting gUM to
authenticated origins seems to be the wrong way around and, therefore,
quite bizarre.

On Mon, Sep 8, 2014 at 8:10 PM, Martin Thomson <m...@mozilla.com> wrote:
> On 08/09/14 10:08, Anne van Kesteren wrote:
>>>
>>> >That's been the question people have asked, and I think that the answer
>>> > was
>>> >that we don't want to break test pages and that sort of thing
>>> > unnecessarily.
>>
>> Whoa, that definitely seems like the wrong way to prioritize things.
>> Tests or demos should not influence design choices.
>
> Don't look at me. My assessment is that this isn't superb, but it's not a
> hill worth dying on.

Is gUM already in a "hill worth dying on" stage? With Presto out of
the picture, the implementations are just Gecko and Blink, right? And
both Gecko and Blink still have gUM vendor prefixed. (Which, if you
believe how prefixing is supposed to work, which I don't believe but
am willing to pretend in this case, should mean that we can still
change stuff.) And at least now if not at the time of first shipping
gUM, there's will among Chrome folks to restrict stuff to
authenticated origins.

Also, DV certs are cheap enough that demo sites should be able to afford one.

> You are welcome to disagree, of course: public-med...@w3.org

Hmm. The W3C list search (which sometimes fails) indicates that
neither Ryan Sleevi nor Chris Palmer has ever posted to the list. I
wonder if there's a disconnect between the Googlers arguing for
restricting APIs to authenticated origins and the Googlers working on
media capture.

On Tue, Sep 9, 2014 at 3:10 AM, Daniel Veditz <dve...@mozilla.com> wrote:
> On 9/8/2014 2:16 AM, Mounir Lamouri wrote:
>> On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote:
>>> It's more the case that a persistent positive grant from permission
>>> manager would be ignored for non-secure origins and non-secure origins
>>> would not show any option to persist.
>>
>> I don't know the specifics about the UI, but you don't want to have a
>> prompt showing up every time a call to an API is being made. It would be
>> terribly frustrating for users and developers.
>

> It wouldn't be every API call, it'd be the first API call. Would it help
> to have an option to remember for the session (rather than
> per-document)? We have no guarantee that the foo.com you connect to
> tomorrow is the same foo.com you trusted today, especially if you're
> connecting to a new network (e.g. coffee shop, airport, hotel).

I should have tested this *before* starting this thread, of course,
but I tested now: We already distinguish between http: and https: so
that our UI don't allow persistent permission grants to http: but
allows them for https: in the gUM case. (Kudos to whoever implemented
this and didn't leave this as a dead letter of WG deliberations!) It
seems that Chrome doesn't offer have persistent grants in either case.
https://hsivonen.fi/gum-test/
http://hsivonen.com/test/moz/gum-test.html

[Mounir Lamouri]

On Tue, 9 Sep 2014, at 10:10, Daniel Veditz wrote:
> On 9/8/2014 2:16 AM, Mounir Lamouri wrote:
> > On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote:
> >> It's more the case that a persistent positive grant from permission
> >> manager would be ignored for non-secure origins and non-secure origins
> >> would not show any option to persist.
> >
> > I don't know the specifics about the UI, but you don't want to have a
> > prompt showing up every time a call to an API is being made. It would be
> > terribly frustrating for users and developers.
>
> It wouldn't be every API call, it'd be the first API call. Would it help
> to have an option to remember for the session (rather than
> per-document)? We have no guarantee that the foo.com you connect to
> tomorrow is the same foo.com you trusted today, especially if you're
> connecting to a new network (e.g. coffee shop, airport, hotel).

That's why I suggested a combination of time-based permission and
session-based.

-- Mounir

[Anne van Kesteren]

On Mon, Sep 8, 2014 at 7:10 PM, Martin Thomson <m...@mozilla.com> wrote:
> Don't look at me. My assessment is that this isn't superb, but it's not a

> hill worth dying on. You are welcome to disagree, of course:
> public-med...@w3.org

http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0013.html


--
http://annevankesteren.nl/

[Henri Sivonen]

Why would complexity like that be preferable over the simplicity of
requiring an authenticated origin?

[Eric Rescorla]

Sure, I think there are some reasonable cases. Say that a site asks to
take your picture for the purpose of displaying an avatar. So you give it
temporary access, it takes the picture, and then it relinquishes access.
Because there are UI indicators that show when the camera is being
accessed, and I control what's in front of the camera, and the site
is planning to publish the picture I don't really need to trust the site
much.

>> Do you have a pointer to the WG's rationale for the rejection? I tried
> >> to search for it, but I failed to find either a decision or rationale.
> >> The closest I could find was
> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats
> >> https origins as special and says that stored permissions should only
> >> be available for them.
> >
> > It was less a rationale than a lack of people being convinced. I raised
> it
> > once
> > or twice and there were a lot of people strongly opposed, and since the
> > default
> > is that things work on HTTP, that's where it stayed.
>
> Do you recall when this happened and if Chrome representatives were
> against restricting gUM to authenticated origins?
>

IIRC the main person speaking out against this was from MSFT, but
I don't think people from Google were in favor either.

> > Don't look at me. My assessment is that this isn't superb, but it's not
> a
> > hill worth dying on.
>

> Is gUM already in a "hill worth dying on" stage? With Presto out of
> the picture, the implementations are just Gecko and Blink, right? And
> both Gecko and Blink still have gUM vendor prefixed. (Which, if you
> believe how prefixing is supposed to work, which I don't believe but
> am willing to pretend in this case, should mean that we can still
> change stuff.) And at least now if not at the time of first shipping
> gUM, there's will among Chrome folks to restrict stuff to
> authenticated origins.
>

I'm not sure I understand the question. There certainly is fairly wide gUM
usage.
For instance, Hangouts is now WebRTC in Chrome and will be WebRTC in
Firefox soonish, hopefully. That obviously doesn't mean things can't be
changed, but I think you'd need WG consensus to do so, and I don't have
the sense we're going to get that.

> On Tue, Sep 9, 2014 at 3:10 AM, Daniel Veditz <dve...@mozilla.com> wrote:
> > On 9/8/2014 2:16 AM, Mounir Lamouri wrote:
> >> On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote:
> >>> It's more the case that a persistent positive grant from permission
> >>> manager would be ignored for non-secure origins and non-secure origins
> >>> would not show any option to persist.
> >>
> >> I don't know the specifics about the UI, but you don't want to have a
> >> prompt showing up every time a call to an API is being made. It would be
> >> terribly frustrating for users and developers.
> >
> > It wouldn't be every API call, it'd be the first API call. Would it help
> > to have an option to remember for the session (rather than
> > per-document)? We have no guarantee that the foo.com you connect to
> > tomorrow is the same foo.com you trusted today, especially if you're
> > connecting to a new network (e.g. coffee shop, airport, hotel).
>

> I should have tested this *before* starting this thread, of course,
> but I tested now: We already distinguish between http: and https: so
> that our UI don't allow persistent permission grants to http: but
> allows them for https: in the gUM case. (Kudos to whoever implemented
> this and didn't leave this as a dead letter of WG deliberations!)

I think Florian implemented it. Adam Roach deserves the credit for insisting
we do it right.

> seems that Chrome doesn't offer have persistent grants in either case.
> https://hsivonen.fi/gum-test/
> http://hsivonen.com/test/moz/gum-test.html

Chrome auto-decides whether the grant is persistent based on whether
the URL is http or https.

-Ekr

[Henri Sivonen]

Oh. I had thought that that use case was outside the scope of gUM and
in scope for http://www.w3.org/TR/html-media-capture/ (possibly to be
implemented on top of gUM + https://w3c.github.io/mediacapture-image/
by the Firefox OS browser chrome.)

(Of course, avatars imply login and login *should* imply https...)

>> >> Do you have a pointer to the WG's rationale for the rejection? I tried
>> >> to search for it, but I failed to find either a decision or rationale.
>> >> The closest I could find was
>> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats
>> >> https origins as special and says that stored permissions should only
>> >> be available for them.
>> >
>> > It was less a rationale than a lack of people being convinced. I raised
>> > it
>> > once
>> > or twice and there were a lot of people strongly opposed, and since the
>> > default
>> > is that things work on HTTP, that's where it stayed.
>>
>> Do you recall when this happened and if Chrome representatives were
>> against restricting gUM to authenticated origins?
>
> IIRC the main person speaking out against this was from MSFT,

Hmm. IIRC, Microsoft wanted a non-TLS variant of HTTP/2.

> but I don't think people from Google were in favor either.

I guess the Chrome folks aren't coordinated on this kind of thing, then.

>> > Don't look at me. My assessment is that this isn't superb, but it's not
>> > a
>> > hill worth dying on.
>>
>> Is gUM already in a "hill worth dying on" stage? With Presto out of
>> the picture, the implementations are just Gecko and Blink, right? And
>> both Gecko and Blink still have gUM vendor prefixed. (Which, if you
>> believe how prefixing is supposed to work, which I don't believe but
>> am willing to pretend in this case, should mean that we can still
>> change stuff.) And at least now if not at the time of first shipping
>> gUM, there's will among Chrome folks to restrict stuff to
>> authenticated origins.
>
>
> I'm not sure I understand the question. There certainly is fairly wide gUM
> usage.

I mean: Does gUM have high non-demo, non-test usage on http origins?

> For instance, Hangouts is now WebRTC in Chrome and will be WebRTC in
> Firefox soonish, hopefully.

As a Google service, Hangouts are going to be https, hopefully.

> That obviously doesn't mean things can't be
> changed, but I think you'd need WG consensus to do so, and I don't have
> the sense we're going to get that.

Per the reply Anne got,
http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0030.html
, it looks like the WG is deferring the decision to implementors as a
"MAY", so it seems to be more an issue of Gecko+Blink consensus than
WG consensus.

> I think Florian implemented it. Adam Roach deserves the credit for insisting
> we do it right.

Thanks to both!

>> seems that Chrome doesn't offer have persistent grants in either case.
>> https://hsivonen.fi/gum-test/
>> http://hsivonen.com/test/moz/gum-test.html
>
> Chrome auto-decides whether the grant is persistent based on whether
> the URL is http or https.

Whoa. That's non-obvious and creepy. As a user, I find it creepy for
an UI that looks like a one-time grant to actually do a persistent
grant. (Consider the non-http use case about taking a picture for a
random site you gave above, that use case happening on an https origin
and ending up leaving the origin with a persistent permission to turn
the camera on later.) As a site operator, I find that this makes me
appear creepier than I want to appear if I host (I currently don't but
I want to eventually) SimpleWebRTC app on my site for ad hoc video
conferencing without having to trust a third party to do the call
setup in a way that doesn't involve extra parties and I don't want to
ask the other party of the conversation to have to trust my site not
to turn on the camera later after the conversation.

[Eric Rescorla]

On Wed, Sep 10, 2014 at 2:09 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > Sure, I think there are some reasonable cases. Say that a site asks to
> > take your picture for the purpose of displaying an avatar. So you give it
> > temporary access, it takes the picture, and then it relinquishes access.
> > Because there are UI indicators that show when the camera is being
> > accessed, and I control what's in front of the camera, and the site
> > is planning to publish the picture I don't really need to trust the site
> > much.
>
> Oh. I had thought that that use case was outside the scope of gUM and
> in scope for http://www.w3.org/TR/html-media-capture/ (possibly to be
> implemented on top of gUM + https://w3c.github.io/mediacapture-image/
> by the Firefox OS browser chrome.)
>

My understanding is that html-media-capture is basically being abandoned
in favor of gUM.

> (Of course, avatars imply login and login *should* imply https...)

I don't disagree with this in principle, but I think we have to admit that
a huge number of sites which do some form of persistent identity/login
and don't use HTTPS. In any case, there are plenty of other legit
applications
such as photobooths, voice control APIs, etc.

> >> > Don't look at me. My assessment is that this isn't superb, but it's
> not
> >> > a
> >> > hill worth dying on.
> >>
> >> Is gUM already in a "hill worth dying on" stage? With Presto out of
> >> the picture, the implementations are just Gecko and Blink, right? And
> >> both Gecko and Blink still have gUM vendor prefixed. (Which, if you
> >> believe how prefixing is supposed to work, which I don't believe but
> >> am willing to pretend in this case, should mean that we can still
> >> change stuff.) And at least now if not at the time of first shipping
> >> gUM, there's will among Chrome folks to restrict stuff to
> >> authenticated origins.
> >
> >
> > I'm not sure I understand the question. There certainly is fairly wide
> gUM
> > usage.
>
> I mean: Does gUM have high non-demo, non-test usage on http origins?

I don't know. To some extent people are being driven to use HTTPS because
they want persistent permissions.

> > That obviously doesn't mean things can't be
> > changed, but I think you'd need WG consensus to do so, and I don't have
> > the sense we're going to get that.
>
> Per the reply Anne got,
> http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0030.html
> , it looks like the WG is deferring the decision to implementors as a
> "MAY", so it seems to be more an issue of Gecko+Blink consensus than
> WG consensus.

Sure. However, my sense is that the Chrome people aren't in favor of this
change.

> >> seems that Chrome doesn't offer have persistent grants in either case.
> >> https://hsivonen.fi/gum-test/
> >> http://hsivonen.com/test/moz/gum-test.html
> >
> > Chrome auto-decides whether the grant is persistent based on whether
> > the URL is http or https.
>
> Whoa. That's non-obvious and creepy. As a user, I find it creepy for
> an UI that looks like a one-time grant to actually do a persistent
> grant. (Consider the non-http use case about taking a picture for a
> random site you gave above, that use case happening on an https origin
> and ending up leaving the origin with a persistent permission to turn
> the camera on later.) As a site operator, I find that this makes me
> appear creepier than I want to appear if I host (I currently don't but
> I want to eventually) SimpleWebRTC app on my site for ad hoc video
> conferencing without having to trust a third party to do the call
> setup in a way that doesn't involve extra parties and I don't want to
> ask the other party of the conversation to have to trust my site not
> to turn on the camera later after the conversation.

I sympathise with this position, which is why Firefox doesn't do it this
way.

-Ekr

[Justin Dolske]

On 9/10/14 2:09 AM, Henri Sivonen wrote:

>> Chrome auto-decides whether the grant is persistent based on whether
>> the URL is http or https.
>
> Whoa. That's non-obvious and creepy. As a user, I find it creepy for
> an UI that looks like a one-time grant to actually do a persistent
> grant.

Indeed. I think it's fine for the protocol to influence if persistence
_can_ be set (i.e., only allowing persistence on secure connections),
but making it automatic is conflating permission (user choice) and security.

It's particularly egregious on Google Maps... The maps.google.com site
redirects to https://google.com/maps, which means using geolocation on
Google Maps in Chrome will automatically allow geolocation for all of
google.com. I wonder how many Maps users understand or expect that.

Justin

[Martin Thomson]

On 2014-09-10, at 16:38, Justin Dolske <dol...@mozilla.com> wrote:

> It's particularly egregious on Google Maps... The maps.google.com site redirects tohttps://google.com/maps, which means using geolocation on Google Maps in Chrome will automatically allow geolocation for all of google.com. I wonder how many Maps users understand or expect that.

That is devious. I suspect that there is a banal reason relating to the use of the Google Front End that motivates the change, but the side effect of having all Google properties have access to user permissions from all other properties is no doubt appealing to some product managers over there.

[Anne van Kesteren]

On Thu, Sep 11, 2014 at 1:50 AM, Martin Thomson <m...@mozilla.com> wrote:
> That is devious. I suspect that there is a banal reason relating to the use of the Google Front End that motivates the change, but the side effect of having all Google properties have access to user permissions from all other properties is no doubt appealing to some product managers over there.

Are we actually partitioning permissions per top-level browsing
context or could they already accomplish this through an <iframe>?


--
http://annevankesteren.nl/

[Martin Thomson]

On 2014-09-11, at 00:56, Anne van Kesteren <ann...@annevk.nl> wrote:

> Are we actually partitioning permissions per top-level browsing
> context or could they already accomplish this through an <iframe>?

As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that.

In the Google case, I doubt that there is anything meaningful we can do to scope permissions in a way that would both prevent Google from sharing a persistent grant. Not without breaking a great number of sites.

[Anne van Kesteren]

On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson <m...@mozilla.com> wrote:
> On 2014-09-11, at 00:56, Anne van Kesteren <ann...@annevk.nl> wrote:
>> Are we actually partitioning permissions per top-level browsing
>> context or could they already accomplish this through an <iframe>?
>
> As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that.

That seems somewhat bad.

> In the Google case, I doubt that there is anything meaningful we can do to scope permissions in a way that would both prevent Google from sharing a persistent grant. Not without breaking a great number of sites.

Well, if there's https://maps.example/ that I share my location with,
we could make it so that it if https://maps.example/ is embedded from
https://mercent.example/, it no longer has the permission. That's what
I meant with partitioning by top-level browsing context.


--
http://annevankesteren.nl/

[Martin Thomson]

On 2014-09-11, at 10:04, Anne van Kesteren <ann...@annevk.nl> wrote:

> Well, if there's https://maps.example/ that I share my location with,
> we could make it so that it if https://maps.example/ is embedded from
> https://mercent.example/, it no longer has the permission. That's what
> I meant with partitioning by top-level browsing context.

Oh, I don’t think that there are any iframes involved in the normal maps embedding process. So each mashup will have to acquire their own consent.

[Frederik Braun]

On 11.09.2014 19:04, Anne van Kesteren wrote:
> On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson <m...@mozilla.com> wrote:
>> On 2014-09-11, at 00:56, Anne van Kesteren <ann...@annevk.nl> wrote:
>>> Are we actually partitioning permissions per top-level browsing
>>> context or could they already accomplish this through an <iframe>?
>>
>> As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that.
>
> That seems somewhat bad.
>

Yes.

AFAIU (I might be terribly wrong), this is because all of those
permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using
the Permission manager we still have from the Popup Blocker/Cookie
Manager. This is domain based. Not origin :(
You can see this in about:permissions.

[Henri Sivonen]

This is shocking. Making the fundamental design bug of cookies affect
everything else is *really* bad. Is there a bug on file for fixing
this?

[Frederik Braun]

Yes and no. I identified this while working on a thesis on the Same
Origin Policy in 2012 and filed this only for Geolocation in bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=812147>.

But the general solution might be a permission manager rewrite, I suppose?

[Anne van Kesteren]

On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun <fbr...@mozilla.com> wrote:
> Yes and no. I identified this while working on a thesis on the Same
> Origin Policy in 2012 and filed this only for Geolocation in bug
> <https://bugzilla.mozilla.org/show_bug.cgi?id=812147>.
>
> But the general solution might be a permission manager rewrite, I suppose?

That seems like a good idea. TLS permissions leaking to non-TLS seems
really bad. Cross-port also does not seem ideal. I hope it's not as
bad as cookies in that it also depends on Public Suffix?

If we rewrite I think it would be good to take top-level browsing
context partitioning under consideration. That is, if I navigate to
https://example/ and grant it the ability to do X. And then navigate
to https://elsewhere.invalid/ which happens to embed https://example/,
the embedded https://example/ does not have the ability to do X.


--
http://annevankesteren.nl/

[Frederik Braun]

I filed bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1066517> for this.

[Ehsan Akhgari]

On 2014-09-12, 6:22 AM, Anne van Kesteren wrote:
> On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun <fbr...@mozilla.com> wrote:
>> Yes and no. I identified this while working on a thesis on the Same
>> Origin Policy in 2012 and filed this only for Geolocation in bug
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=812147>.
>>
>> But the general solution might be a permission manager rewrite, I suppose?
>
> That seems like a good idea. TLS permissions leaking to non-TLS seems
> really bad. Cross-port also does not seem ideal. I hope it's not as
> bad as cookies in that it also depends on Public Suffix?

The permission manager was originally used to store the permission of
websites who are allowed to set third-party cookies if you turn on that
pref, and it's not used for storing the cookies themselves. As such, it
is fortunately oblivious to the Public Suffix List.

> If we rewrite I think it would be good to take top-level browsing
> context partitioning under consideration. That is, if I navigate to
> https://example/ and grant it the ability to do X. And then navigate
> to https://elsewhere.invalid/ which happens to embed https://example/,
> the embedded https://example/ does not have the ability to do X.

The permission manager itself is unaware of browsing contexts, it is the
consumer which decides how to query it.

[Jonas Sicking]

On Fri, Sep 12, 2014 at 11:44 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> If we rewrite I think it would be good to take top-level browsing
>> context partitioning under consideration. That is, if I navigate to
>> https://example/ and grant it the ability to do X. And then navigate
>> to https://elsewhere.invalid/ which happens to embed https://example/,
>> the embedded https://example/ does not have the ability to do X.
>
> The permission manager itself is unaware of browsing contexts, it is the
> consumer which decides how to query it.

This is one of the bad things with the permission manager. It leads to
that we end up with different policies for different permissions.

It's actually even worse than that. Because it is the *reader* that
sets the policy, it means that a cookie policy written to the
permission manager could be interpreted in different ways depending on
which exact code is checking the permission manager.

What we really should do is to enable writing into the permission
manager "set this cookie policy for domain and subdomains" or "set
this cookie policy for this domain" or "set this cookie policy for
this origin".

And then make the reading side simply ask "can this principal send
cookies". Rather than the current "can this principal send cookies
assuming that the stored data should use policy X".

We can probably expand this pattern to also handle 3rd party iframes.

Note that there are use cases for both narrow and broad policies. At
the very least it seems useful to be able to say both "deny all of
*.adnetwork.com from using cookies" as well as "allow
https://google.com/ to use camera".

/ Jonas

[Anne van Kesteren]

On Fri, Sep 12, 2014 at 8:44 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> The permission manager itself is unaware of browsing contexts, it is the
> consumer which decides how to query it.

But shouldn't it be aware of this so you can adequately scope the
permission? E.g. I could grant https://amazingmaps.example/ when
embedded through https://okaystore.invalid/ permission to use my
location. But it would not be given out if it were embedded through
https://evil.invalid/ later on.

Or e.g. I could allow YouTube embedded through reddit to go
fullscreen, but not necessarily YouTube itself or when embedded
elsewhere.


--
http://annevankesteren.nl/

[Martin Thomson]

On 12/09/14 13:59, Anne van Kesteren wrote:
> But shouldn't it be aware of this so you can adequately scope the
> permission? E.g. I could granthttps://amazingmaps.example/ when

> embedded throughhttps://okaystore.invalid/ permission to use my

> location. But it would not be given out if it were embedded through
> https://evil.invalid/ later on.
>
> Or e.g. I could allow YouTube embedded through reddit to go
> fullscreen, but not necessarily YouTube itself or when embedded
> elsewhere.

In most cases (though here sicking's comment regarding what should
happen remains especially applicable), the actor is the only thing that
matters.

That is, it's the principal of the JS compartment, which is the origin
you see in the bar at the top. The location that script is loaded from
doesn't matter. An iframe embed is different, but in that context, the
framed site retains complete control over its content and is arguably
competent to ensure that it isn't abused; more importantly, the outer
site has no visibility other than what the framed site grants it.

[Anne van Kesteren]

On Sat, Sep 13, 2014 at 12:07 AM, Martin Thomson <m...@mozilla.com> wrote:
> On 12/09/14 13:59, Anne van Kesteren wrote:
>> But shouldn't it be aware of this so you can adequately scope the
>> permission? E.g. I could granthttps://amazingmaps.example/ when
>> embedded throughhttps://okaystore.invalid/ permission to use my
>> location. But it would not be given out if it were embedded through
>> https://evil.invalid/ later on.
>>
>> Or e.g. I could allow YouTube embedded through reddit to go
>> fullscreen, but not necessarily YouTube itself or when embedded
>> elsewhere.
>
> In most cases (though here sicking's comment regarding what should happen
> remains especially applicable), the actor is the only thing that matters.
>
> That is, it's the principal of the JS compartment, which is the origin you
> see in the bar at the top. The location that script is loaded from doesn't
> matter.

Yes, I know how the web works. I was talking about nested browsing contexts.

> An iframe embed is different, but in that context, the framed site
> retains complete control over its content and is arguably competent to
> ensure that it isn't abused; more importantly, the outer site has no
> visibility other than what the framed site grants it.

I just gave an example where it would matter. I could similarly
imagine that I'd be okay with skype.com to have persistant camera
access when I navigate to it, but not when skype.com is in an <iframe>
somewhere serving ads.


--
http://annevankesteren.nl/

[Eric Rescorla]

On Sat, Sep 13, 2014 at 12:38 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> On Sat, Sep 13, 2014 at 12:07 AM, Martin Thomson <m...@mozilla.com> wrote
>

> > An iframe embed is different, but in that context, the framed site
> > retains complete control over its content and is arguably competent to
> > ensure that it isn't abused; more importantly, the outer site has no
> > visibility other than what the framed site grants it.
>
> I just gave an example where it would matter. I could similarly
> imagine that I'd be okay with skype.com to have persistant camera
> access when I navigate to it, but not when skype.com is in an <iframe>
> somewhere serving ads.

I just tested this and it appears that at least for gUM, IFRAMEs do *not*
get persistent permissions even if they would have them if they were
in the top level window. Rather, you always get prompted. You can
test this yourself using:

https://mozilla.github.io/webrtc-landing/gum_test.html
and
https://mozilla.github.io/webrtc-landing/gum_iframe.html (note: contains
mixed content for
test purposes) or the HTTP variant.

-Ekr

[Anne van Kesteren]

On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla <e...@rtfm.com> wrote:
> I just tested this and it appears that at least for gUM, IFRAMEs do *not*
> get persistent permissions even if they would have them if they were
> in the top level window. Rather, you always get prompted. You can
> test this yourself using:
>
> https://mozilla.github.io/webrtc-landing/gum_test.html
> and
> https://mozilla.github.io/webrtc-landing/gum_iframe.html (note: contains
> mixed content for
> test purposes) or the HTTP variant.

That sounds good. However, given that apparently that's not something
the permission manager takes care of, it might be nice to cover it
there, so this becomes easier for all kinds of APIs that require
permission.


--
http://annevankesteren.nl/

[Ehsan Akhgari]

We could obviously do what you suggest, but it's not really obvious to
me whether the same behavior makes sense everywhere. I think what I
would expect as a user would be very different depending on the context.
For example, for the youtube use case that you mentioned, I don't see
why we might want to treat embedded youtube differently rather than
youtube.com in the top level browsing context. For a maps widget that
communicates my current location to the parent browsing context though,
my expectations are different because in that case, we'd be effectively
giving the permission to the "wrong" website as far as the user is
concerned.

Also, at least in the case of IndexedDB, we have gone with the more
restrictive, and initially disabled access to the database from nested
browsing contexts, but there seems to be legit use cases that would
benefit from that (such as MakeDrive
http://blog.humphd.org/introducing-makedrive/) and now people are
working on making it less restrictive (see bug 912202).

I think it would be very hard to come up with a one-size-fits-all answer
here, but perhaps we can.

[Jonas Sicking]

On Mon, Sep 15, 2014 at 11:15 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2014-09-14, 3:54 AM, Anne van Kesteren wrote:
>>
>> On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>> I just tested this and it appears that at least for gUM, IFRAMEs do *not*
>>> get persistent permissions even if they would have them if they were
>>> in the top level window. Rather, you always get prompted. You can
>>> test this yourself using:
>>>
>>> https://mozilla.github.io/webrtc-landing/gum_test.html
>>> and
>>> https://mozilla.github.io/webrtc-landing/gum_iframe.html (note: contains
>>> mixed content for
>>> test purposes) or the HTTP variant.
>>
>>
>> That sounds good. However, given that apparently that's not something
>> the permission manager takes care of, it might be nice to cover it
>> there, so this becomes easier for all kinds of APIs that require
>> permission.
>
> We could obviously do what you suggest, but it's not really obvious to me
> whether the same behavior makes sense everywhere.

The argument that I'm making, and I think Anne is too, is that we
should have the ability to store policies like this in the
nsIPermissionManager. That way we *can* use it in places where it
makes sense, or we can choose to simply store policies like "allow
youtube.com to use flash independent of parent frames" where that
makes sense.

/ Jonas

[Ehsan Akhgari]

Yes, of course, I agree that we should do that.

[Anne van Kesteren]

On Mon, Sep 15, 2014 at 10:40 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> The argument that I'm making, and I think Anne is too, is that we
> should have the ability to store policies like this in the
> nsIPermissionManager. That way we *can* use it in places where it
> makes sense, or we can choose to simply store policies like "allow
> youtube.com to use flash independent of parent frames" where that
> makes sense.

Agreed. And it puts all our permission policies within the permission
manager, rather than being local hacks that might accidentally vary
from feature to feature.


--
https://annevankesteren.nl/