Intent to Implement: Permission Delegation for Iframes

[Raymes Khoury]

Contact emails

ray...@chromium.org pal...@chromium.org  

Spec

Draft spec: https://noncombatant.github.io/permission-delegation-api/

We’re in the early stages of discussing the draft with other browser vendors. We'd like to experiment with an implementation to help inform the discussion.

Summary

There are two main changes proposed:

1. Give an embedding page the ability to delegate permissions (such as geolocation) to iframes that are embedded within it. We introduce 2 mechanisms to do this: a) an <iframe> attribute (e.g. <iframe permissions=”geolocation …”>; and b) a JS API to programmatically delegate permissions.

2. Impose a restriction which prevents iframes from acquiring a permission unless the iframe’s embedder has explicitly delegated it.

Motivation

People don’t have a good understanding of permission requests from iframes, or of the concept of composed web applications generally. There is often no UI in the browser indicating that iframes are present or what their origin is. iframes may even be invisible on a page. It is not easy to communicate the concept of composed applications to people using the web. The results of a user study showed that participants were generally confused about who they were granting access to when a permission request came from an iframe.

We want to simplify the model by requiring embedding applications to delegate permissions to iframes, and then have the UA present the permission request in the context of the embedding origin. This frees the person from the cognitive load of composed applications. In this way, people would only ever be required to make permission decisions about the top level origin of the page, which is easier to understand.

This change will also give embedding pages control over which permissions are delegated to iframes.

See https://noncombatant.github.io/permission-delegation-api/#background-and-motivations for more detail and other motivations.

Interoperability and Compatibility Risk

By preventing iframes from directly acquiring permissions, we will be breaking iframes that depend on permissions. Embedding pages will have to update their code to restore access.

The number of page loads that use permissions from iframes is very low. All usage is below 0.0006% of page loads, which is well within the deprecation range. We will go through the deprecation process (communicating with developers and giving notice) before releasing the feature.

Also see: https://noncombatant.github.io/permission-delegation-api/#compatibility

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=612954

Link to entry on the feature dashboard

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

Requesting approval to ship?

No.

[Rick Byers]

This is exciting, I'm glad to hear you're experimenting with an implementation!

One thing to keep in mind is that some of the other vendors (definitely Apple, perhaps also Microsoft) have a lower tolerance for breaking changes than we do.  If this design is necessarily inherently opt-in / breaking, we'll probably need to go beyond our own normal level of compat concerns to convince ourselves the interop risk is low enough to ship (for the interop risk to be low, the compat risk has to meet Apple's bar not just our own).  It may be worth trying to think a bit about potential compat mitigations and try to feel out the other vendors.  Also the more you can concretely show a user privacy/security benefit, the more risk tolerant the other vendors are likely to be (eg. Safari's recent change to block DeviceMotion from iframes).

Rick

[Joel Weinberger]

FWIW, we (most importantly, Chris and Raymes) met with Apple, Firefox, and Microsoft earlier this week at the W3C WebAppSec face-to-face and discussed permission delegation with them. While there were certainly questions and disagreements, there seemed to be general agreement that it's a "good thing."

--Joel

[Harald Alvestrand]

When discussing the same problem in the WebRTC WG, the WG landed on the same conclusion (that iframes should only be given permission for access to the feature if the containing frame explicitly grants it, and that it was better to break existing users now than to try to accomodate existing usage).

I applaud getting a consistent direction & mechanism on this - it's not a WEBRTC problem, WEBRTC shouldn't be maintaining point solutions for it.

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

[Chris Palmer]

On Thu, May 19, 2016 at 2:37 PM, Harald Alvestrand <h...@google.com> wrote:

When discussing the same problem in the WebRTC WG, the WG landed on the same conclusion (that iframes should only be given permission for access to the feature if the containing frame explicitly grants it, and that it was better to break existing users now than to try to accomodate existing usage).

That's good to know, thanks.

 

I applaud getting a consistent direction & mechanism on this - it's not a WEBRTC problem, WEBRTC shouldn't be maintaining point solutions for it.

I agree!