Requesting Feedback: Simplifying <iframe> Permission Scoping in Chrome

[Raymes Khoury]

Hey chromium-dev and blink-dev,

We are working on a proposal to simplify the way permissions (such as geolocation) work for iframes. Currently, the way that permission requests from iframes are scoped is inconsistent, complicated and makes it hard to build understandable UI. Furthermore, we've found that users have a hard time understanding who they are granting access to when requests come from iframes.

In response to these problems, we propose always presenting permission decisions in terms of the top level origin. By default iframes will not be able to obtain any permissions unless the top level origin explicitly allows access (in a similar way to the iframe sandbox attribute). This means that the user only needs to make decisions about the top level origin, which is simpler for users to understand. It also simplifies permission management UI.

Please let us know if you have any feedback on our proposal:

https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit

Thanks,

Raymes

[PhistucK]

I think this is a bit hostile. Example -

The user does not trust Microsoft, but a website they do trust embeds a WebRTC based Microsoft experience for support calls.

Permitting the top level website access to the user media implies permitting Microsoft that same access automatically.

☆PhistucK

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

[PhistucK]

Perhaps a website should be able to declare domains as "permission partners" of some sort and when the permission request first shows up, all of the domains will be listed (and when the list changes, a new permission request would be shown).

This would be similar to the extension installation experience.

☆PhistucK

[Anton Vayvod]

Hi Raymes et al,

I have a few questions:

1. Are there any signals from other browser vendors about the proposal? What's the cross-browser compatibility path here?

2. What would be the best way for the developers of the embedded site to add a feature if it requires a new permission?

It seems like they can just provide an HTML snippet that would delegate all the permissions and even add them using the proposed JS API. Otherwise they might have to chase all the embedders to update their sites. Is there a better option? Do we envision these permissions go away with time like currently planned for fullscreen and mouse lock or do we think there will be more?

3. What about other per-frame features that might show the frame origin in similar contexts (notifications, EME, device pickers, etc)?

4. Do we know what's the usage patterns are and how the proposed changes will affect them? In other words are the worrying examples given (e.g. with Amex) common or not?

Thanks,
Anton.

[Anne van Kesteren]

On Wed, Feb 3, 2016 at 11:58 AM, Anton Vayvod <ava...@chromium.org> wrote:
> 1. Are there any signals from other browser vendors about the proposal?
> What's the cross-browser compatibility path here?

I have asked Mozillians here:
https://groups.google.com/d/msg/mozilla.dev.platform.ux/4u4hKQ5ANoc/VNN-BVvJAwAJ.
Personally I think this is quite exciting. The way we prompt on behalf
of <iframe>s today makes no sense. Another idea I had was that we'd
only do permissions for the top-level browsing context and any
same-origin nested browsing contexts, and require cross-origin nested
browsing contexts to create some kind of OAuth-dance, but the
deployment of that is way harder.


--
https://annevankesteren.nl/

[Benjamin Schwartz]

I think the "Allowing Background Access to Permissions" alternative is worthwhile and important, especially because many permissions are limited to "secure" origins, and Chromium continually tightens its rules on what an origin must do to be considered "secure" (as it should).  If insecure origins can load an iframe from a secure origin that has a cached permission, then I think it will be easier for us to continue to raise the bar on origin security.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Raymes Khoury]

Hey Anton, thanks for your comments! See replies inline.

Thanks!

Raymes

On Wed, 3 Feb 2016 at 21:59 Anton Vayvod <ava...@chromium.org> wrote:

Hi Raymes et al,

I have a few questions:

1. Are there any signals from other browser vendors about the proposal? What's the cross-browser compatibility path here?

 

No, but I'm glad it's being discussed now :) Note that even at present we don't have consistency of iframe permission behavior across browsers (this is outlined in the doc). It's not exactly clear what parts of the proposal we would want to put into a specification. The delegation API certainly requires a spec (which we are working on) but that can be treated orthogonally to the scoping behavior/UI. We will definitely be reaching out to discuss this more with other browsers.

 

2. What would be the best way for the developers of the embedded site to add a feature if it requires a new permission?

It seems like they can just provide an HTML snippet that would delegate all the permissions and even add them using the proposed JS API. Otherwise they might have to chase all the embedders to update their sites. Is there a better option? Do we envision these permissions go away with time like currently planned for fullscreen and mouse lock or do we think there will be more?

This is a good question. The trust decision for an iframe is transferred from the user to the top level website. So it is always the responsibility of the top level website to decide what permissions it is comfortable sharing to the iframe. If an iframe'd website changes what permissions it uses, it's not necessarily a bad thing that the embedder has to change. The website owner is making a decision about whether they trust the iframe'd origin with the new permission.

If an embedded website chooses to offer a snippet that delegates all permissions, it's up to the website owner pasting that snippet whether they are comfortable with that - they choose whether or not to trust the snippet. People can offer snippets to do all sorts of things on someone elses origin and there isn't much we can do about that.

In reality, I think trustworthy websites will be careful about what snippets they paste into their website and limit delegated permissions to those they are comfortable with. Untrustworthy websites may not be careful about this, but a user also isn't as likely to trust them when granting a permission. Similarly, trustworthy developers offering code snippets will be mindful of their embedders and not unnecessarily try to delegate permissions that they know they won't need. 

 

3. What about other per-frame features that might show the frame origin in similar contexts (notifications, EME, device pickers, etc)?

Hmm, I'm not sure exactly what you mean here? The proposal would apply to all features which require permission including device pickers. The proposal does not apply to permissions granted for use in the background, such as push notifications.

  

4. Do we know what's the usage patterns are and how the proposed changes will affect them? In other words are the worrying examples given (e.g. with Amex) common or not?

We aren't aware of many other examples of such behavior (at most one). We do know that usage of permissions in iframes is already very low and within the deprecation range (see the doc for details). Also, we will go through the regular deprecation process, including showing console warnings and instructions for how embedders can be updated for at least one milestone.

[Ben Wells]

On Wed, Feb 3, 2016 at 7:22 PM PhistucK <phis...@gmail.com> wrote:

I think this is a bit hostile. Example -

The user does not trust Microsoft, but a website they do trust embeds a WebRTC based Microsoft experience for support calls.

Permitting the top level website access to the user media implies permitting Microsoft that same access automatically.

Thanks for your feedback! The proposal does remove some control, and prevents this kind of informed, nuanced decision from being made. However we believe it is not the kind of decision that many users actually make, and our user study confirmed that there was a poor understanding of iframes among regular folk.

Having permission systems and UI that normal people find understandable, predictable, and under their control is our primary concern.

I imagine we could add advanced controls for sophisticated users, for example to block a particular origin from ever getting WebRTC. I can't see any conflict with adding that kind of control with this change, although I wouldn't want to do so unless it became clear that there were a significant number of people who would use it.

[Anton Vayvod]

Hi Raymes,

Thanks for the replies. Comments below:

On Thu, Feb 4, 2016 at 5:23 AM, Raymes Khoury <ray...@chromium.org> wrote:

Hey Anton, thanks for your comments! See replies inline.

Thanks!

Raymes

On Wed, 3 Feb 2016 at 21:59 Anton Vayvod <ava...@chromium.org> wrote:

Hi Raymes et al,

I have a few questions:

1. Are there any signals from other browser vendors about the proposal? What's the cross-browser compatibility path here?

 

No, but I'm glad it's being discussed now :) Note that even at present we don't have consistency of iframe permission behavior across browsers (this is outlined in the doc). It's not exactly clear what parts of the proposal we would want to put into a specification. The delegation API certainly requires a spec (which we are working on) but that can be treated orthogonally to the scoping behavior/UI. We will definitely be reaching out to discuss this more with other browsers.

I've seen the comparison. As I see it, all browsers listed but Chrome (and Chromium-based Opera), have very similar per-frame model with little deviations compared to the current and even more the proposed model in Chrome. The document even highlights it with "similar to Firefox".

 

2. What would be the best way for the developers of the embedded site to add a feature if it requires a new permission?

It seems like they can just provide an HTML snippet that would delegate all the permissions and even add them using the proposed JS API. Otherwise they might have to chase all the embedders to update their sites. Is there a better option? Do we envision these permissions go away with time like currently planned for fullscreen and mouse lock or do we think there will be more?

This is a good question. The trust decision for an iframe is transferred from the user to the top level website. So it is always the responsibility of the top level website to decide what permissions it is comfortable sharing to the iframe. If an iframe'd website changes what permissions it uses, it's not necessarily a bad thing that the embedder has to change. The website owner is making a decision about whether they trust the iframe'd origin with the new permission.

If an embedded website chooses to offer a snippet that delegates all permissions, it's up to the website owner pasting that snippet whether they are comfortable with that - they choose whether or not to trust the snippet. People can offer snippets to do all sorts of things on someone elses origin and there isn't much we can do about that.

In reality, I think trustworthy websites will be careful about what snippets they paste into their website and limit delegated permissions to those they are comfortable with. Untrustworthy websites may not be careful about this, but a user also isn't as likely to trust them when granting a permission. Similarly, trustworthy developers offering code snippets will be mindful of their embedders and not unnecessarily try to delegate permissions that they know they won't need. 

Do we know how much of useful content on the web is being actively maintained by web developers? Do we know how many of those websites and developers are trustworthy? I don't have the data and doubt it's easy to get but I have a feeling that a big chunk of the web is left out with this position.

 

3. What about other per-frame features that might show the frame origin in similar contexts (notifications, EME, device pickers, etc)?

Hmm, I'm not sure exactly what you mean here? The proposal would apply to all features which require permission including device pickers. The proposal does not apply to permissions granted for use in the background, such as push notifications.

The proposal only lists a few permissions it will apply to. There're other cases where the UA would show some kind of prompt or dialog saying "foo.com wants to do X" and user can dismiss the dialog or pick the action. If the proposal is going to apply to all of those, the usage and potential problems need to be assessed as iframes will be limited even more.

  

4. Do we know what's the usage patterns are and how the proposed changes will affect them? In other words are the worrying examples given (e.g. with Amex) common or not?

We aren't aware of many other examples of such behavior (at most one). We do know that usage of permissions in iframes is already very low and within the deprecation range (see the doc for details). Also, we will go through the regular deprecation process, including showing console warnings and instructions for how embedders can be updated for at least one milestone.

Relying only on usage counters can be dangerous (an example from the past where the usage was low but it broke many websites on one platform: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Bxe7DnDVRZ0/discussion). 

Have you reached out to at least big properties that are embedded often? I hope getting reasonable feedback from Web developers with a lot at stake will be part of the decision making.

[Raymes Khoury]

Thanks Anton! Replies inline.

On Fri, 5 Feb 2016 at 05:19 Anton Vayvod <ava...@chromium.org> wrote:

Hi Raymes,

Thanks for the replies. Comments below:

On Thu, Feb 4, 2016 at 5:23 AM, Raymes Khoury <ray...@chromium.org> wrote:

Hey Anton, thanks for your comments! See replies inline.

Thanks!

Raymes

On Wed, 3 Feb 2016 at 21:59 Anton Vayvod <ava...@chromium.org> wrote:

Hi Raymes et al,

I have a few questions:

1. Are there any signals from other browser vendors about the proposal? What's the cross-browser compatibility path here?

 

No, but I'm glad it's being discussed now :) Note that even at present we don't have consistency of iframe permission behavior across browsers (this is outlined in the doc). It's not exactly clear what parts of the proposal we would want to put into a specification. The delegation API certainly requires a spec (which we are working on) but that can be treated orthogonally to the scoping behavior/UI. We will definitely be reaching out to discuss this more with other browsers.

I've seen the comparison. As I see it, all browsers listed but Chrome (and Chromium-based Opera), have very similar per-frame model with little deviations compared to the current and even more the proposed model in Chrome. The document even highlights it with "similar to Firefox".

That's true. We're planning to reach out to other browser vendors.

 

 

2. What would be the best way for the developers of the embedded site to add a feature if it requires a new permission?

It seems like they can just provide an HTML snippet that would delegate all the permissions and even add them using the proposed JS API. Otherwise they might have to chase all the embedders to update their sites. Is there a better option? Do we envision these permissions go away with time like currently planned for fullscreen and mouse lock or do we think there will be more?

This is a good question. The trust decision for an iframe is transferred from the user to the top level website. So it is always the responsibility of the top level website to decide what permissions it is comfortable sharing to the iframe. If an iframe'd website changes what permissions it uses, it's not necessarily a bad thing that the embedder has to change. The website owner is making a decision about whether they trust the iframe'd origin with the new permission.

If an embedded website chooses to offer a snippet that delegates all permissions, it's up to the website owner pasting that snippet whether they are comfortable with that - they choose whether or not to trust the snippet. People can offer snippets to do all sorts of things on someone elses origin and there isn't much we can do about that.

In reality, I think trustworthy websites will be careful about what snippets they paste into their website and limit delegated permissions to those they are comfortable with. Untrustworthy websites may not be careful about this, but a user also isn't as likely to trust them when granting a permission. Similarly, trustworthy developers offering code snippets will be mindful of their embedders and not unnecessarily try to delegate permissions that they know they won't need. 

Do we know how much of useful content on the web is being actively maintained by web developers? Do we know how many of those websites and developers are trustworthy? I don't have the data and doubt it's easy to get but I have a feeling that a big chunk of the web is left out with this position.

That's true, and it is a risk that has been acknowledged in the proposal. But it's also not entirely a bad thing that embedders have to change. It needs to be weighed up with the advantages/disadvantages of the proposal as a whole. 

 

 

3. What about other per-frame features that might show the frame origin in similar contexts (notifications, EME, device pickers, etc)?

Hmm, I'm not sure exactly what you mean here? The proposal would apply to all features which require permission including device pickers. The proposal does not apply to permissions granted for use in the background, such as push notifications.

The proposal only lists a few permissions it will apply to. There're other cases where the UA would show some kind of prompt or dialog saying "foo.com wants to do X" and user can dismiss the dialog or pick the action. If the proposal is going to apply to all of those, the usage and potential problems need to be assessed as iframes will be limited even more.

We've tried to list all permissions that are in Chrome stable in the document. We've missed EME but I can add that. I'm not aware of any others.

 

  

4. Do we know what's the usage patterns are and how the proposed changes will affect them? In other words are the worrying examples given (e.g. with Amex) common or not?

We aren't aware of many other examples of such behavior (at most one). We do know that usage of permissions in iframes is already very low and within the deprecation range (see the doc for details). Also, we will go through the regular deprecation process, including showing console warnings and instructions for how embedders can be updated for at least one milestone.

Relying only on usage counters can be dangerous (an example from the past where the usage was low but it broke many websites on one platform: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Bxe7DnDVRZ0/discussion). 

Have you reached out to at least big properties that are embedded often? I hope getting reasonable feedback from Web developers with a lot at stake will be part of the decision making.

We haven't done that but I agree we should do anything reasonable (such as what you suggest) that would minimize the risk of unknown breakages.