Intent to implement: Permission Delegation

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

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.

Requesting approval to ship?

Yes. Approval to ship would be ideal since this is not a conventional web-facing change but we can circle back if necessary.

[L. David Baron]

On Monday 2018-01-15 06:04 +0000, Raymes Khoury wrote:
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?

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

I'm supportive of this idea (although I haven't talked to other
folks at Mozilla about this). However, I'm a bit skeptical of the
idea that this is entirely UA-specific and doesn't require
standardization or tests.

It seems pretty easy for sites to start relying on things like:

* a permission request from a cross-origin subframe (granted the
ability to do that via feature-policy) applying the permissions
to the toplevel document as well

* a permission request from the toplevel document automatically
applies to a cross-origin subframe to whom that permission has
been delegated by feature-policy

(This list isn't exhaustive.)


Although it doesn't seem to be explicitly stated, I'm assuming that
the idea behind this intent is that it would break any cases of
permission requests from cross-origin subframes where there isn't
delegation of the permission from the top-origin document.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Joe Medley]

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

Can DevRel get a tracking bug anyway?

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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20180116153517.pccfnakeznddv3gl%40pescadero.dbaron.org.

[Raymes Khoury]

Thanks for taking a look!

> However, I'm a bit skeptical of the
idea that this is entirely UA-specific and doesn't require
standardization or tests.

I'm not sure I agree. The way that permissions are scoped has explicitly been left up to user agents (see 5.1 and 5.2 in https://w3c.github.io/permissions/#permission-operations, +Jeffrey Yasskin can elaborate more). Deciding how permissions are scoped is complicated and there is no clear right answer for users which is why there is so much freedom in the spec. Browsers already do it differently. For example, Chrome will currently persist the location permissions to the combination of (top-level, iframe) origins, which means the same origin won't get access when embedded in a different top-level page. Firefox only persists to the requesting origin, which means the origin will get access no matter what top-level origin it is embedded in (if the "remember" checkbox is selected). This is just one aspect of scoping where browsers differ but there are others. For example, Chrome will always persist the decision whereas Safari and Firefox will store the decision temporarily by default. There are many other examples.

It's already possible that websites try to depend on browser-specific behaviors here. However it's difficult.  Remember that a user can revoke permission at any point in time, or a browser can choose for a grant to be temporary. Websites shouldn't (and can't really) make assumptions about whether they will have access in a particular context. Furthermore, the designs of APIs and documentation encourage websites to check for permission and request it if necessary prior to use of the feature and I haven't seen a case of a website making the kind of assumptions you mention.

> Although it doesn't seem to be explicitly stated, I'm assuming that
the idea behind this intent is that it would break any cases of
permission requests from cross-origin subframes where there isn't
delegation of the permission from the top-origin document.

We separated out the part of the proposal for requiring websites to explicitly allow subframes to have access to permissions. It's enforced using Feature Policy. That part of the proposal has already had the appropriate approvals and will ship in Chrome M64. See the intent here and further details here. This proposal builds on top of that (see the section in the doc on Relationship to Feature Policy). So this proposal won't cause any additional breakage over what has already been approved. I'm sorry that this wasn't clearer, I'll update the introduction in the document.

Thanks,

Raymes