Intent to ship: Permission Delegation in M71

[Raymes Khoury]

Contact emails

ray...@chromium.org

Explainer

Explainer/design doc

Design doc/Spec

See above. Note: no changes to any web-facing APIs are proposed and no spec changes are required. It is chiefly a Security UX change which changes aspects of permissions behavior which are left to User Agents to decide. At the same time these changes are still closely related to the behavior of certain APIs on the web (e.g. permissions and feature policy) and so we want to ensure that affected folks are aware of and in support of the change.

Summary

From the doc:

Currently, iframes on the web can make permission requests and users will be shown permission prompts that contain the origin of the iframe. Making permission decisions for iframes and managing previous decisions is complicated and confusing.

To address this problem, we propose that users only ever be required to make permission decisions about the top level origin of a website. It is then up to the top level website to delegate permission to the various iframes which it embeds, if it so chooses.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/irAY53rSXIE/p0oZ5j4mAgAJ

Link to Origin Trial feedback summary

NA

Motivation

Described in detail in the doc.

Risks

Described in detail in the doc.

Debuggability

NA

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Since this is a UA-specific feature, Android WebView will not be affected. All other platforms will.

Is this feature fully tested by web-platform-tests?

Since this is a UA-specific feature it should not have web-platform-test coverage.

Link to entry on the feature dashboard

Probably unnecessary given the nature of the feature. But I can create one if needed.

Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=818004

[rek...@gmail.com]

This seems like a major major rewire of the rules of the web. I'm very uncomfortable shipping this based on some random Google doc that got cooked up. This is core behavior and Google shooting off in one direction without trying to socialize it, discuss it, standardize the behavior with other browsers is web breakingly bad. This is very very uncomfortable to see & feels like it's just being sprung on the web out of nowhere. I'll try to research more of the backstory on how and when this evolved but this comes, right now, as a huge shock in that it's a radical change I wouldnt and didn't expect, and it's near to the heart of the web.

[ray...@chromium.org]

Hi Morgaine,

This change has been discussed widely in a variety of forums over the past 2 years and has evolved and been refined as a result of research and discussion. We certainly aren't trying to spring this on the web out of nowhere (see historical references below).

The aspects of this change that do impact web compatibility have already been standardized and shipped as a mechanism named Feature Policy. The changes proposed in this Intent to Ship do not introduce any further web incompatibilities. Instead this change is primarily related to security UI - the way in which Chrome displays and scopes permissions. This is an area where freedom is given to user agents to come up with the best possible experiences. That's why we're not trying to standardize this behavior or expecting other browser vendors to conform to it. 

Cheers,

Raymes

A selection of historical references:

Request for feedback on idea: https://groups.google.com/a/chromium.org/d/msg/blink-dev/qXKq-ZQC3Bw/m_u56DvsCAAJ

First proposal (unshipped): https://noncombatant.github.io/permission-delegation-api/ (Discussed at webappsec f2f a few years ago)

The web-breaking piece of this was broken off and standardized as "feature policy". This has shipped: https://groups.google.com/a/chromium.org/d/msg/blink-dev/uKO1CwiY3ts/62vV7xmaCQAJ

Intent to implement thread for this UI piece: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/irAY53rSXIE/p0oZ5j4mAgAJ

Twitter post by mkwst about the change: https://twitter.com/mikewest/status/952807134454009856

[Joe Medley]

This sounds like something we'll want to mention in the beta blog post, which means it should also get a Chrome Status entry. I suggest creating one.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aafa04be-adc0-4c1c-a237-418157b70a07%40chromium.org.

[Alex Russell]

Hey Raymes,

We discussed it at today's meeting. One open question: are granted, delegated permissions reflected through the Permissions API? And in cases when a permission is granted from a request by a delegated-to document (iframe), are Permission Status Events dispatched in all documents? 

Thanks

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-S%2BAvuUqiEGWpjFvAjuDv7F0UCkojZmDYyqM3Q6J%3DU0Q%40mail.gmail.com.

[Raymes Khoury]

Hey Alex,

> One open question: are granted, delegated permissions reflected through the Permissions API?

Yep.

> And in cases when a permission is granted from a request by a delegated-to document (iframe), are Permission Status Events dispatched in all documents? 

No, good catch, this is an oversight. It should be a simple fix though and I'll ensure that it's addressed before we launch.

Thanks,

Raymes

[Raymes Khoury]

Hi Joe,

Please see https://www.chromestatus.com/feature/5670617353289728

Thanks,

Raymes

[Yoav Weiss]

On Wed, Aug 29, 2018 at 12:49 AM Raymes Khoury <ray...@chromium.org> wrote:

Hey Alex,

> One open question: are granted, delegated permissions reflected through the Permissions API?

Yep.

> And in cases when a permission is granted from a request by a delegated-to document (iframe), are Permission Status Events dispatched in all documents? 

No, good catch, this is an oversight. It should be a simple fix though and I'll ensure that it's addressed before we launch.

So just to make sure - once this is addressed, would it be possible to know from one embedded iframe that another had previously asked for and received permissions? Or will each embedded iframe which needs certain permissions have to request for them on its own, even if other iframes already received said permissions?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYdGOXmKDc7UVukgkSVNQjmu-ehDYC7px7fZvM%3DauXh510hsg%40mail.gmail.com.

[Harald Alvestrand]

Since this doesn't seem to be settled yet.....

wouldn't the logical way to handle this be that given a tree of iframes, one should consider each delegated permission as defining a subtree consisting of all of the subframes that have been delegated this permission, and the first member of the subtree that asks for permission and receives it causes permission status events on all the frames within the subtree?

Yes, this is a cross-frame information leakage. But the alternative (not giving iframes an accurately updated view of what permissions they have) seems worse.

 

Thanks,

Raymes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aafa04be-adc0-4c1c-a237-418157b70a07%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-S%2BAvuUqiEGWpjFvAjuDv7F0UCkojZmDYyqM3Q6J%3DU0Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYdGOXmKDc7UVukgkSVNQjmu-ehDYC7px7fZvM%3DauXh510hsg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhXhsVgm7w0PLGGjtf4%3Dqzvcd-0foTyXc6kgZb54oS_tg%40mail.gmail.com.

[Yoav Weiss]

On Wed, Aug 29, 2018 at 3:27 PM Harald Alvestrand <h...@google.com> wrote:

Since this doesn't seem to be settled yet.....

wouldn't the logical way to handle this be that given a tree of iframes, one should consider each delegated permission as defining a subtree consisting of all of the subframes that have been delegated this permission, and the first member of the subtree that asks for permission and receives it causes permission status events on all the frames within the subtree?

Yes, this is a cross-frame information leakage. But the alternative (not giving iframes an accurately updated view of what permissions they have) seems worse.

One could argue that it's the top-level frame delegates the permissions only after the iframe requested them and not before, so the iframe's view of the permissions would be almost accurate - it's only "prompt" which may be a false positive, when the prompting was already done by another frame.

 

 

Thanks,

Raymes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aafa04be-adc0-4c1c-a237-418157b70a07%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-S%2BAvuUqiEGWpjFvAjuDv7F0UCkojZmDYyqM3Q6J%3DU0Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYdGOXmKDc7UVukgkSVNQjmu-ehDYC7px7fZvM%3DauXh510hsg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Joe Medley]

Not only do I thank you for that, but I congratulate you for writing a good summary. Web developers can tell how this affects them.

I have a question though. Is this really not in webview? 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Raymes Khoury]

Assuming that the top level frame has been granted permission AND chooses to delegate it to an iframe, that iframe will have access from the moment it is loaded. This is the same approach that's used if we have persisted a user's permission decision for a top-level frame, i.e. it will have access to that permission from the moment it loads. Events will get fired whenever the status of the permission for that frame changes.

[Raymes Khoury]

Thanks :)

> I have a question though. Is this really not in webview? 

Yes. WebViews decide on their own UI/models for scoping permissions (just as different user agents decide on their model for scoping permissions). WebView embedders could choose to take this approach or not. Many embedders have vastly different permission models they use anyway (such as auto-denying or auto-granting specific permissions to specific origins).

[Yoav Weiss]

On Thu, Aug 30, 2018 at 2:21 AM Raymes Khoury <ray...@chromium.org> wrote:

Assuming that the top level frame has been granted permission AND chooses to delegate it to an iframe, that iframe will have access from the moment it is loaded. This is the same approach that's used if we have persisted a user's permission decision for a top-level frame, i.e. it will have access to that permission from the moment it loads. Events will get fired whenever the status of the permission for that frame changes.

OK, found the relevant section in the doc, which indeed describes this as well as the risk in this change. As is, I don't think that the note "no changes to any web-facing APIs are proposed" is completely accurate, as iframes will now be able to observe top-level and iframe permissions they were not exposed to before.

Have you run this by other vendors to see if they'd be interested following a similar model?

From an interoperability perspective, this can create a situation where some iframes on the page expect to have permissions granted by virtue of other frames or the top-level frame requesting them. That would work in Chrome but not elsewhere.

A model where every iframe has to request the permission (even if the user is only prompted once) can avoid that risk.

[Raymes Khoury]

Thanks for the feedback Yoav. 

> From an interoperability perspective, this can create a situation where some iframes on the page expect to have permissions granted by virtue of other frames or the top-level frame requesting them. That would work in Chrome but not elsewhere.

It's certainly possible that websites depend on the properties of a particular browser's permission model. Websites could equally depend on aspects of Chrome's current behavior or on behaviors implemented in other browsers (they already differ). If such a thing did happen it's by virtue of the fact that we give freedom to user agents in how their permission model works, and is not related to our specific model. The reason for having freedom with the permissions model is that it allows different user agents to experiment with different approaches where we are far from a clear ideal. 

Having said that, the permissions APIs are designed in such a way that websites should never make assumptions about whether they are granted permission or not. This is not just because behaviors vary across different user agents, but also because generally a user can grant or deny a permission to a page at any point in time, and change their minds later. They can often do this even if the page never explicitly asks for permission (e.g. through the lock icon > Site Settings in Chrome). Furthermore, with feature policy shipping, the embedder website also has a say over whether an iframe can get access to a permission. So it's quite difficult in practice for websites to rely on permissions having a certain value - there are too many variables which are dependent on the trust decisions of various actors. 

> A model where every iframe has to request the permission (even if the user is only prompted once) can avoid that risk.

For almost all APIs usage of a permission and requesting the permission are already tied together and websites must request permission in order to use the feature. e.g. for geolocation a permission prompt happens as a part of calling the API to use the feature. Same with midi. My personal opinion is that all APIs that require permission should be designed like this (there are several other reasons why this is a good design). There are some cases where they aren't (e.g. notifications) but I don't believe there to be an interoperability risk based on the above argument.

Cheers,

Raymes

[Raymes Khoury]

Hi there,

Just checking if there has been any update on this? 

Thanks,

Raymes

[Mike West]

We've already done the hard work of paving the road to this mechanism by dropping the ability to request interesting permissions in cross-origin contexts without explicit delegation from an embedder (see https://groups.google.com/a/chromium.org/d/msg/blink-dev/mG6vL09JMOQ/VPVEH7P0BwAJ). We've seen positive feedback on the concept from unnamed Edge folks (https://github.com/w3ctag/design-reviews/issues/225#issuecomment-396599436) and folks at Mozilla (https://groups.google.com/a/chromium.org/d/msg/blink-dev/irAY53rSXIE/-qpB__iTAgAJ, https://twitter.com/johannh/status/952831005882306560).

I appreciate the discussion of the tradeoffs this approach requires ("least privilege" in particular), but I buy the countervailing claims around user behavior and user understanding. This seems like the right model going forward, and I think we should ship it.

LGTM1.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEYdGOUPozyUDfZx_yLBQ41biUiRwTkzU%3DY%3DdDjG8GGTFbOaGw%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfyBRqi5YK777Qdw79LHOb%3Dx74-RJ_ePGnCcPykV0tcxg%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdLW_i2H3v0AWHB9BFKMR%3D4SniDGJYjZZEA58XPwnrZ6A%40mail.gmail.com.

[Alex Russell]

Sorry for the delayed response, Raymes.

We've got 3 LGTMs now, but there was a spirited conversation around the observability and transitivity of this new mode. There was also agreement that it doesn't actually change anything in spec-land, but IIRC Chris was hoping we'd be able to characterize any increase in prompting and acceptance rates. Would it be possible for you to summarize those for this thread once the feature is live?

LGTM4

[Raymes Khoury]

Thanks all!

> but IIRC Chris was hoping we'd be able to characterize any increase in prompting and acceptance rates. Would it be possible for you to summarize those for this thread once the feature is live?

We can loop back with some metrics. I'll follow up separately to find out exactly what you're interested in.