Re: Intent to prototype: Delegate and restrict permission in third party context

[Johann Hofmann]

I think the main question that needs to be answered here is: "How does that
make the situation better?" There is an extensive document from the Chrome
team

on their motivation, but I'd like to add some things on the Firefox side.

Let's examine the current situation in Firefox, which, in my opinion (as
someone who's partly responsible and wants to fix it), is quite bad. We
have two big problems:

When an origin requests access to a permission (either as first or third
party) and the user wants to remember this decision, the Firefox permission
manager by default stores a key-value pair consisting of origin and
permission value[0]. It does not "double-key", so there's no
differentiation between first or third party access. This means an embedded
google.com iframe, having access to your geolocation through google.com/maps,
can track your geolocation around the web. Or someone deep-links into
google hangouts in an iframe and records you. Fun. In Firefox's defense,
unlike in Chrome, the permission is not stored permanently by default, it's
an optional choice that few users actually make.

This problem could be easily[1] solved by double-keying permissions. So
that would be good, if it wasn't for another problem:

As outlined in the Chrome document, there is strong evidence that most
users (except maybe you, me and everyone else on this thread) can not
reason about the concept of iframes, at all. So asking users to make a
reasonable choice if "google-hangouts-secure-connection.com" on google
hangouts should get camera access or not is *a lot* to ask (assuming they
even look at the origin). Then there's the UX that needs to be built for
managing the permissions users granted. To enable proper configuration, you
basically have to model the frame tree in all your UI and hope users
understand it.

Some time ago the Chrome team came up with an approach to solve this.
Permission delegation enabled by Feature Policy. It solves both issues
outlined above by taking some responsibility away from the end user and
putting more responsibility in web developers hands. I fully understand
that as a security researcher you've seen how that can go wrong and that as
an advanced user you feel secure with the current system. We agree to a
certain extent and we've taken a *long* time considering, standardizing and
implementing this approach.

The concept isn't perfect and of course it clashes with double-keying, so
we can't have both. As mentioned earlier, there are a few things we as
Mozilla have found too lax on the security side (like the "*" attribute)
and have thus modified in our implementation. You are right that this will
slightly increase the impact of HTML injection attacks under certain
conditions.

Nonetheless, after all consideration, we think this concept is the best
combined solution to both outlined problems that we've seen so far, which
is why we want to move ahead and ship it.

Cheers,

Johann

[0] it stores more than that of course, like expiry information, but not
the first party identifier by default
[1] conceptually easy. The implementation is messy, which we know since
we've recently built this as part of first-party isolation (for Tor) and
are still dealing with the fallout

On Tue, Dec 3, 2019 at 3:59 PM Thomas Nguyen  wrote:

> On Wednesday, November 27, 2019 at 7:50:46 PM UTC+1, s.h...@gmail.com
> wrote:
> > >Conversely, there would be another attack to link to
> > >attacker spaces on already-trusted sites (but no top-level) >and get
> silently access too.
> > That is not silent, because user would have already granted permission
> to that origin to access in previous model.
> >
> >
> > >Besides, if a user granted skype.com, the origin is
> > >vulnerable to HTML injection, then when an attacker
> > >requests a permission grant, the users may not have any
> > >context for or understanding of them, that is very
> > >confusing and users tend to accept that request because
> > >they are under a trusted context of the top-level origin.
> > So the way you are solving this problem is, instead of showing prompt
> with iframe’s origin, just delegate permission from top frame or request
> permission with the origin of top frame? How did that made the situation
> better? You are ultimately taking away origin indicator from people who
> understood what it means :(
> >
> > I’m really disappointed that Firefox is taking this path.
> The idea to change comes from a couple of reasons. One as I mentioned,
> there were attacks, deep linking to attacker spaces on already-trusted
> sites (not the top), and a couple of UI issues that could be resolved by
> this simplification.
> So sorry if it hurts your, anw, thanks for your idea, we will look into
> that to see if we have any mitigation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> 

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Wednesday, November 27, 2019 at 7:50:46 PM UTC+1, s.h...@gmail.com wrote:
> >Conversely, there would be another attack to link to
> >attacker spaces on already-trusted sites (but no top-level) >and get 
> >silently access too. 
> That is not silent, because user would have already granted permission to 
> that origin to access in previous model.
> 
> 
> >Besides, if a user granted skype.com, the origin is 
> >vulnerable to HTML injection, then when an attacker 
> >requests a permission grant, the users may not have any 
> >context for or understanding of them, that is very 
> >confusing and users tend to accept that request because 
> >they are under a trusted context of the top-level origin.
> So the way you are solving this problem is, instead of showing prompt with 
> iframe’s origin, just delegate permission from top frame or request 
> permission with the origin of top frame? How did that made the situation 
> better? You are ultimately taking away origin indicator from people who 
> understood what it means :(
> 
> I’m really disappointed that Firefox is taking this path.
The idea to change comes from a couple of reasons. One as I mentioned, there 
were attacks, deep linking to attacker spaces on already-trusted sites (not the 
top), and a couple of UI issues that could be resolved by this simplification. 
So sorry if it hurts your, anw, thanks for your idea, we will look into that to 
see if we have any mitigation 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

>Conversely, there would be another attack to link to
>attacker spaces on already-trusted sites (but no top-level) >and get silently 
>access too. 
That is not silent, because user would have already granted permission to that 
origin to access in previous model.


>Besides, if a user granted skype.com, the origin is 
>vulnerable to HTML injection, then when an attacker 
>requests a permission grant, the users may not have any 
>context for or understanding of them, that is very 
>confusing and users tend to accept that request because 
>they are under a trusted context of the top-level origin.
So the way you are solving this problem is, instead of showing prompt with 
iframe’s origin, just delegate permission from top frame or request permission 
with the origin of top frame? How did that made the situation better? You are 
ultimately taking away origin indicator from people who understood what it 
means :(

I’m really disappointed that Firefox is taking this path.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Monday, November 25, 2019 at 10:38:28 PM UTC+1, s.h...@gmail.com wrote:
> 1. If a user already gave permission to certain origin (e.g. skype.com), and 
> that origin had HTML injection, does that mean attacker can now silently 
> inherit permission from skype.com?
> 
> 2. If so, how can a website mitigate the risk of permission being silently 
> taken to third party website?
Yes, I agree it might be a thing we should consider because we grant permission 
access broader. However, if the origin is vulnerable, I don't think we could 
protect more. If you have granted access to the origin, the origin can expose 
data to other via postMessage (or other mechanisms).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

1. If a user already gave permission to certain origin (e.g. skype.com), and 
that origin had HTML injection, does that mean attacker can now silently 
inherit permission from skype.com?

2. If so, how can a website mitigate the risk of permission being silently 
taken to third party website?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Nils Ohlmeier]

Hi Thomas,

Thank you for pushing feature policy over the finish line and making the web a 
safer place!

Best
  Nils Ohlmeier

> On 25Nov, 2019, at 04:41, Thomas Nguyen  wrote:
> 
> Summary: People don’t have a good understanding of iframes, because
> generally, no UI indicates that iframes are visible on a page, or what
> their origin is. Permission requests from iframes cause significant
> confusion for users because it is hard to determine where the requests come
> from, as the address bar does not match the site in the permission prompt.
> 
> Currently, Firefox allows iframes on a site to make permission requests and
> show up a permission prompt using the origin of the iframes. A user making
> a decision based on the third party context presented in the notification
> prompt is complicated and confusing. This confusion is exacerbated when
> managing previously stored permission decisions.
> 
> To address this problem, we would like to impose a restriction on
> permissions coming from third party context. There would be two main
> changes proposed:
> 
>   -
> 
>   Give an ability to delegate permissions from first party to third party
>   embedded iframes, and impose a restriction to embedded iframes to request
>   permission only when the iframe’s embedder has explicitly delegated it. The
>   permission request will use the top level origin to show in the prompt,
>   then users are only required to make permission decisions about the first
>   party context.
>   -
> 
>  This change is dependent on the ability of Feature Policy to disable
>  permissions by default in cross-origin iframes. It will require a site to
>  explicitly allow permissions for cross-origin iframes (setting allow
>  attribute, e.g allow=”geolocation”) otherwise, the permission
> requests will
>  be denied on that iframes.
>  -
> 
>  The change will be applied to geolocation, camera, microphone and
>  screen-sharing permission, and fullscreen request.
> 
> 
>   -
> 
>   Completely deny permissions from third party context for vibration,
>   notification, and persistent-storage permission.
> 
> 
> The plan is:
> 
>   -
> 
>   Enable Feature Policy allow attribute.
>   -
> 
>   Make permission camera/microphone/geolocation/display-capture/fullscreen
>   disabled by default in third-party iframe.
>   -
> 
>   Delegate Permissions: only cross-origin iframes that have explicit
>   delegated permission from their parent through the allow attribute will
>   have the right to make permission requests.
>   -
> 
>   Reduce the number of supported features to geolocation, camera,
>   microphone screen-sharing, and fullscreen (the above features are supported
>   for permissions UI with notification prompts, except fullscreen). And we
>   will move all other features to experimental phrase under a user preference
>   which is disabled by default.
>   -
> 
>   Simplify prompts/dialogs to only contain the top-level origin.
>   -
> 
>   Deny vibration, persistent-storage permission from third party iframe
>   (notification permission was disabled in third party context,  just do some
>   minor refactors).
> 
> 
> 
> 
> Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> 
> Standard: Feature Policy
> https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> 
> Platform coverage: All.
> 
> Preference:
> 
> dom.security.featurePolicy.experimental.enabled: disabled by default, we
> will limit supported features in Feature Policy to geolocation, camera,
> microphone, fullscreen, display-capture and move others to experimental
> phase.
> 
> permissions.delegate.enabled: enabled by default
> 
> dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> but enabled by default in Nightly only
> 
> Other browsers: Chrome supports permission delegation from Chrome 71.
> 
> web-platform-tests: We only have web platform tests for feature policy but
> not permission delegation
> 
> Some of Feature Policy web-platform-tests that the permissions are disabled
> by default in cross origin iframe:
> 
> https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> 
> testing /web-platform
> /tests
> /
> permissions
> 
> /feature-policy-permissions-query.html
> 
> 
> testing /web-platform
> /tests
> /
> mediacapture-streams
> 

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Wednesday, November 27, 2019 at 4:55:35 PM UTC+1, s.h...@gmail.com wrote:
> How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m 
> saying the origin is vulnerable to HTML injection, and origin is not 
> malicious.
Thanks, yes, that is a consideration we should care about, of giving broader 
permission access and obviously, this is not ideal. I have not added any 
mitigation to the implementation yet. 
Conversely, there would be another attack to link to attacker spaces on 
already-trusted sites (but not top-level) and get silently access too. I think 
there would be a trade-off between them. Besides, if a user granted skype.com, 
the origin is vulnerable to HTML injection, then when an attacker requests a 
permission grant, the users may not have any context for or understanding of 
them, that is very confusing and users tend to accept that request because they 
are under a trusted context of the top-level origin.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[s . h . h . n . j . k]

How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m 
saying the origin is vulnerable to HTML injection, and origin is not malicious.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote:
> On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> > Summary: People don’t have a good understanding of iframes, because
> > generally, no UI indicates that iframes are visible on a page, or what
> > their origin is. Permission requests from iframes cause significant
> > confusion for users because it is hard to determine where the requests come
> > from, as the address bar does not match the site in the permission prompt.
> > 
> > Currently, Firefox allows iframes on a site to make permission requests and
> > show up a permission prompt using the origin of the iframes. A user making
> > a decision based on the third party context presented in the notification
> > prompt is complicated and confusing. This confusion is exacerbated when
> > managing previously stored permission decisions.
> > 
> > To address this problem, we would like to impose a restriction on
> > permissions coming from third party context. There would be two main
> > changes proposed:
> > 
> >-
> > 
> >Give an ability to delegate permissions from first party to third party
> >embedded iframes, and impose a restriction to embedded iframes to request
> >permission only when the iframe’s embedder has explicitly delegated it. 
> > The
> >permission request will use the top level origin to show in the prompt,
> >then users are only required to make permission decisions about the first
> >party context.
> >-
> > 
> >   This change is dependent on the ability of Feature Policy to disable
> >   permissions by default in cross-origin iframes. It will require a 
> > site to
> >   explicitly allow permissions for cross-origin iframes (setting allow
> >   attribute, e.g allow=”geolocation”) otherwise, the permission
> > requests will
> >   be denied on that iframes.
> >   -
> > 
> >   The change will be applied to geolocation, camera, microphone and
> >   screen-sharing permission, and fullscreen request.
> > 
> > 
> >-
> > 
> >Completely deny permissions from third party context for vibration,
> >notification, and persistent-storage permission.
> > 
> > 
> > The plan is:
> > 
> >-
> > 
> >Enable Feature Policy allow attribute.
> >-
> > 
> >Make permission camera/microphone/geolocation/display-capture/fullscreen
> >disabled by default in third-party iframe.
> >-
> > 
> >Delegate Permissions: only cross-origin iframes that have explicit
> >delegated permission from their parent through the allow attribute will
> >have the right to make permission requests.
> >-
> > 
> >Reduce the number of supported features to geolocation, camera,
> >microphone screen-sharing, and fullscreen (the above features are 
> > supported
> >for permissions UI with notification prompts, except fullscreen). And we
> >will move all other features to experimental phrase under a user 
> > preference
> >which is disabled by default.
> >-
> > 
> >Simplify prompts/dialogs to only contain the top-level origin.
> >-
> > 
> >Deny vibration, persistent-storage permission from third party iframe
> >(notification permission was disabled in third party context,  just do 
> > some
> >minor refactors).
> > 
> > 
> > 
> > 
> > Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> > 
> > Standard: Feature Policy
> > https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> > 
> > Platform coverage: All.
> > 
> > Preference:
> > 
> > dom.security.featurePolicy.experimental.enabled: disabled by default, we
> > will limit supported features in Feature Policy to geolocation, camera,
> > microphone, fullscreen, display-capture and move others to experimental
> > phase.
> > 
> > permissions.delegate.enabled: enabled by default
> > 
> > dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> > but enabled by default in Nightly only
> > 
> > Other browsers: Chrome supports permission delegation from Chrome 71.
> > 
> > web-platform-tests: We only have web platform tests for feature policy but
> > not permission delegation
> > 
> > Some of Feature Policy web-platform-tests that the permissions are disabled
> > by default in cross origin iframe:
> > 
> > https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> > 
> > testing /web-platform
> > /tests
> > /
> > permissions
> > 
> > /feature-policy-permissions-query.html
> > 
> > 
> > testing 

Re: Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

On Tuesday, November 26, 2019 at 1:03:01 AM UTC+1, kgil...@mozilla.com wrote:
> On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> > Summary: People don’t have a good understanding of iframes, because
> > generally, no UI indicates that iframes are visible on a page, or what
> > their origin is. Permission requests from iframes cause significant
> > confusion for users because it is hard to determine where the requests come
> > from, as the address bar does not match the site in the permission prompt.
> > 
> > Currently, Firefox allows iframes on a site to make permission requests and
> > show up a permission prompt using the origin of the iframes. A user making
> > a decision based on the third party context presented in the notification
> > prompt is complicated and confusing. This confusion is exacerbated when
> > managing previously stored permission decisions.
> > 
> > To address this problem, we would like to impose a restriction on
> > permissions coming from third party context. There would be two main
> > changes proposed:
> > 
> >-
> > 
> >Give an ability to delegate permissions from first party to third party
> >embedded iframes, and impose a restriction to embedded iframes to request
> >permission only when the iframe’s embedder has explicitly delegated it. 
> > The
> >permission request will use the top level origin to show in the prompt,
> >then users are only required to make permission decisions about the first
> >party context.
> >-
> > 
> >   This change is dependent on the ability of Feature Policy to disable
> >   permissions by default in cross-origin iframes. It will require a 
> > site to
> >   explicitly allow permissions for cross-origin iframes (setting allow
> >   attribute, e.g allow=”geolocation”) otherwise, the permission
> > requests will
> >   be denied on that iframes.
> >   -
> > 
> >   The change will be applied to geolocation, camera, microphone and
> >   screen-sharing permission, and fullscreen request.
> > 
> > 
> >-
> > 
> >Completely deny permissions from third party context for vibration,
> >notification, and persistent-storage permission.
> > 
> > 
> > The plan is:
> > 
> >-
> > 
> >Enable Feature Policy allow attribute.
> >-
> > 
> >Make permission camera/microphone/geolocation/display-capture/fullscreen
> >disabled by default in third-party iframe.
> >-
> > 
> >Delegate Permissions: only cross-origin iframes that have explicit
> >delegated permission from their parent through the allow attribute will
> >have the right to make permission requests.
> >-
> > 
> >Reduce the number of supported features to geolocation, camera,
> >microphone screen-sharing, and fullscreen (the above features are 
> > supported
> >for permissions UI with notification prompts, except fullscreen). And we
> >will move all other features to experimental phrase under a user 
> > preference
> >which is disabled by default.
> >-
> > 
> >Simplify prompts/dialogs to only contain the top-level origin.
> >-
> > 
> >Deny vibration, persistent-storage permission from third party iframe
> >(notification permission was disabled in third party context,  just do 
> > some
> >minor refactors).
> > 
> > 
> > 
> > 
> > Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> > 
> > Standard: Feature Policy
> > https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> > 
> > Platform coverage: All.
> > 
> > Preference:
> > 
> > dom.security.featurePolicy.experimental.enabled: disabled by default, we
> > will limit supported features in Feature Policy to geolocation, camera,
> > microphone, fullscreen, display-capture and move others to experimental
> > phase.
> > 
> > permissions.delegate.enabled: enabled by default
> > 
> > dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> > but enabled by default in Nightly only
> > 
> > Other browsers: Chrome supports permission delegation from Chrome 71.
> > 
> > web-platform-tests: We only have web platform tests for feature policy but
> > not permission delegation
> > 
> > Some of Feature Policy web-platform-tests that the permissions are disabled
> > by default in cross origin iframe:
> > 
> > https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> > 
> > testing /web-platform
> > /tests
> > /
> > permissions
> > 
> > /feature-policy-permissions-query.html
> > 
> > 
> > testing 

Re: Intent to prototype: Delegate and restrict permission in third party context

[kgilbert]

On Monday, November 25, 2019 at 9:29:10 AM UTC-8, Thomas Nguyen wrote:
> Summary: People don’t have a good understanding of iframes, because
> generally, no UI indicates that iframes are visible on a page, or what
> their origin is. Permission requests from iframes cause significant
> confusion for users because it is hard to determine where the requests come
> from, as the address bar does not match the site in the permission prompt.
> 
> Currently, Firefox allows iframes on a site to make permission requests and
> show up a permission prompt using the origin of the iframes. A user making
> a decision based on the third party context presented in the notification
> prompt is complicated and confusing. This confusion is exacerbated when
> managing previously stored permission decisions.
> 
> To address this problem, we would like to impose a restriction on
> permissions coming from third party context. There would be two main
> changes proposed:
> 
>-
> 
>Give an ability to delegate permissions from first party to third party
>embedded iframes, and impose a restriction to embedded iframes to request
>permission only when the iframe’s embedder has explicitly delegated it. The
>permission request will use the top level origin to show in the prompt,
>then users are only required to make permission decisions about the first
>party context.
>-
> 
>   This change is dependent on the ability of Feature Policy to disable
>   permissions by default in cross-origin iframes. It will require a site 
> to
>   explicitly allow permissions for cross-origin iframes (setting allow
>   attribute, e.g allow=”geolocation”) otherwise, the permission
> requests will
>   be denied on that iframes.
>   -
> 
>   The change will be applied to geolocation, camera, microphone and
>   screen-sharing permission, and fullscreen request.
> 
> 
>-
> 
>Completely deny permissions from third party context for vibration,
>notification, and persistent-storage permission.
> 
> 
> The plan is:
> 
>-
> 
>Enable Feature Policy allow attribute.
>-
> 
>Make permission camera/microphone/geolocation/display-capture/fullscreen
>disabled by default in third-party iframe.
>-
> 
>Delegate Permissions: only cross-origin iframes that have explicit
>delegated permission from their parent through the allow attribute will
>have the right to make permission requests.
>-
> 
>Reduce the number of supported features to geolocation, camera,
>microphone screen-sharing, and fullscreen (the above features are supported
>for permissions UI with notification prompts, except fullscreen). And we
>will move all other features to experimental phrase under a user preference
>which is disabled by default.
>-
> 
>Simplify prompts/dialogs to only contain the top-level origin.
>-
> 
>Deny vibration, persistent-storage permission from third party iframe
>(notification permission was disabled in third party context,  just do some
>minor refactors).
> 
> 
> 
> 
> Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461
> 
> Standard: Feature Policy
> https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute
> 
> Platform coverage: All.
> 
> Preference:
> 
> dom.security.featurePolicy.experimental.enabled: disabled by default, we
> will limit supported features in Feature Policy to geolocation, camera,
> microphone, fullscreen, display-capture and move others to experimental
> phase.
> 
> permissions.delegate.enabled: enabled by default
> 
> dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
> but enabled by default in Nightly only
> 
> Other browsers: Chrome supports permission delegation from Chrome 71.
> 
> web-platform-tests: We only have web platform tests for feature policy but
> not permission delegation
> 
> Some of Feature Policy web-platform-tests that the permissions are disabled
> by default in cross origin iframe:
> 
> https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy
> 
> testing /web-platform
> /tests
> /
> permissions
> 
> /feature-policy-permissions-query.html
> 
> 
> testing /web-platform
> /tests
> /
> mediacapture-streams
> 
> 

Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

Summary: People don’t have a good understanding of iframes, because
generally, no UI indicates that iframes are visible on a page, or what
their origin is. Permission requests from iframes cause significant
confusion for users because it is hard to determine where the requests come
from, as the address bar does not match the site in the permission prompt.

Currently, Firefox allows iframes on a site to make permission requests and
show up a permission prompt using the origin of the iframes. A user making
a decision based on the third party context presented in the notification
prompt is complicated and confusing. This confusion is exacerbated when
managing previously stored permission decisions.

To address this problem, we would like to impose a restriction on
permissions coming from third party context. There would be two main
changes proposed:

   -

   Give an ability to delegate permissions from first party to third party
   embedded iframes, and impose a restriction to embedded iframes to request
   permission only when the iframe’s embedder has explicitly delegated it. The
   permission request will use the top level origin to show in the prompt,
   then users are only required to make permission decisions about the first
   party context.
   -

  This change is dependent on the ability of Feature Policy to disable
  permissions by default in cross-origin iframes. It will require a site to
  explicitly allow permissions for cross-origin iframes (setting allow
  attribute, e.g allow=”geolocation”) otherwise, the permission
requests will
  be denied on that iframes.
  -

  The change will be applied to geolocation, camera, microphone and
  screen-sharing permission, and fullscreen request.


   -

   Completely deny permissions from third party context for vibration,
   notification, and persistent-storage permission.


The plan is:

   -

   Enable Feature Policy allow attribute.
   -

   Make permission camera/microphone/geolocation/display-capture/fullscreen
   disabled by default in third-party iframe.
   -

   Delegate Permissions: only cross-origin iframes that have explicit
   delegated permission from their parent through the allow attribute will
   have the right to make permission requests.
   -

   Reduce the number of supported features to geolocation, camera,
   microphone screen-sharing, and fullscreen (the above features are supported
   for permissions UI with notification prompts, except fullscreen). And we
   will move all other features to experimental phrase under a user preference
   which is disabled by default.
   -

   Simplify prompts/dialogs to only contain the top-level origin.
   -

   Deny vibration, persistent-storage permission from third party iframe
   (notification permission was disabled in third party context,  just do some
   minor refactors).




Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461

Standard: Feature Policy
https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute

Platform coverage: All.

Preference:

dom.security.featurePolicy.experimental.enabled: disabled by default, we
will limit supported features in Feature Policy to geolocation, camera,
microphone, fullscreen, display-capture and move others to experimental
phase.

permissions.delegate.enabled: enabled by default

dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
but enabled by default in Nightly only

Other browsers: Chrome supports permission delegation from Chrome 71.

web-platform-tests: We only have web platform tests for feature policy but
not permission delegation

Some of Feature Policy web-platform-tests that the permissions are disabled
by default in cross origin iframe:

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy

testing /web-platform
/tests
/
permissions

/feature-policy-permissions-query.html


testing /web-platform
/tests
/
mediacapture-streams

/MediaStream-default-feature-policy.https.html


testing/web-platform/tests/mediacapture-streams/MediaDevices-enumerateDevices-not-allowed-mic.https.html