Intent to Deprecate on-by-default Permissions in Cross-origin Iframes

[Raymes Khoury]

Contact emails

ray...@chromium.org, icle...@chromium.org

Spec

No specs have been changed yet, but this would impact the following specs:

• The Feature Policy specification which is in the process of being written. An explainer can be found here.

• The specifications for geolocation, midi, EME, media capture features

Summary

It’s proposed that by default the following permissions cannot be requested or used by content contained in cross-origin iframes:

• Geolocation

• Midi

• Encrypted media extensions

• Microphone and Camera

In order for a cross-origin frame to use these features, the embedding page must specify a Feature Policy which enables the feature for the frame. For example, to enable geolocation in an iframe, the embedder could specify the iframe tag as:

<iframe src="https://example.com" allow="geolocation"></iframe>

All of these features currently have failure modes that can occur as the result of the user agent denying permission to use the feature. The same failure mode can be used if the feature is disabled via feature policy (potentially with a different error code, depending on the specific API).

Motivation

Untrusted third-party content, such as ads, are frequently embedded in iframes on websites. Currently, permissions like geolocation, midi, etc. can be directly requested and used by this content.

UI for displaying permission prompts that are triggered by iframes can be very confusing. Often permission prompts appear to be coming from the top-level origin. As a result, users can be misled into granting permission to third-party content that they did not intend to. At the very least, third-party content has the ability to annoy users by displaying prompts even if they are undesired by the embedding page.

Furthermore, even if a user has previously granted persistent permission to an origin, they are unlikely to be aware when that origin is loaded in an iframe on a website on the drive-by-web. This may result in unexpected and unwanted access a user’s camera, location, etc.

The goal of this proposal is to protect users by disabling permissions by default in iframes. Embedding websites would have the ability to re-enable features for trusted content. This means that in order for a site to request permission, the embedding website must express trust in the origin, in addition to the user’s trust expressed through a permission grant.

It should also be noted that several new features being implemented (e.g. Payment request, WebVR) are adopting the model of disabling sensitive features in cross-origin iframes from the beginning. This change will bring older features into line with the direction the web is heading.

Interoperability and Compatibility Risk

This change will break some existing content on the web that uses these features from iframes. Embedded websites would have to be changed to specify a Feature Policy that enables those features in the iframes desired.

However usage of the given features is currently very low (with the exception of midi) so this should only impact a very small number of websites. Note that it has been identified that the reason midi usage is so high currently is that it is being abused to fingerprint users. This change would break that use-case in an intended way.

Permission	% Page loads using feature (overall)	% Page loads using permission from iframe
Geolocation	0.3647%	0.0002%
Midi	0.0377%	0.0187%
Mic+Camera	0.0179%	<0.0001%
Encrypted Media Extensions	0.0098%	TBD

Note that to minimize the impact on developers, we will give console warnings for 1-2 full releases of Chrome prior to shipping the disabled behavior. We are also coordinating with API owners of each of these features who have a better understanding of usage in the wild to help identify and reach out to sites that may break. Furthermore, we may want to experiment with disabling these features for a small portion of users on Dev/Beta in order to identify sites that will be broken.

Features would continue to work in iframes in older browsers which do not support feature policy.

Ongoing technical constraints

None.

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

All except possibly not Android WebView depending on whether we think this should be embedder-controlled.

OWP launch tracking bug

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

Link to entry on the feature dashboard

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

Requesting approval to ship?

No - we will implement behind a runtime flag and send an intent-to-ship after Feature Policy has been approved to ship.

[Harald Alvestrand]

Spec owner (W3C WG chair) LGTM for camera + microphone.

Looking forward to being able to have one stable story to tell users for "how to enable this if they need it" for the few legitimate use cases. For most cases, it's far better to have it off.

To my mind, the faster we can impose this, the better.

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

[Dimitri Glazkov]

LGTM1.

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

[Philip Jägenstedt]

Is the intention here to deprecate with no removal milestone mentioned in the deprecation message, or is the milestone TBD? If there is some chance that the removal won't work out due to compat fallout, I'm curious how to phrase this, as we haven't done a good job with this kind situation so far, making it hard to tell what is actually going to be removed and not.

[Raymes Khoury]

Good question foolip@. I actually wasn't planning on adding the deprecation messages right this minute. Originally I phrased this as an "intent to implement" - my initial plan is just to implement these restrictions in Chrome behind a flag. We rephrased it as an "intent to deprecate" to get it on people's radars as a deprecation that will be coming.

Along with the implementation we will nail down the various spec bits and reach out to large users that we're able to identify. Feature policy should also be more stable by then. I think at that point we'll be in a better position to set a milestone and add a deprecation message.

Does that sound like a reasonable approach to you? 

[Philip Jägenstedt]

Definitely, striving towards deprecation/removal here makes sense, so LGTM2 (only 1 needed) to that. As long as the deprecation message names a milestone when added I have no concerns. And if you find that you don't know exactly when removal can happen and still think that a deprecation could still help, that could be reasonable too. It's just the accidental deprecate-and-forgot-to-remove that I'm hoping to not repeat :)

[Raymes Khoury]

Looping back on this. We're getting close to finishing the implementation of this and so I'd like to add the deprecation messages to M61 which target M62 for removal - this would give a 1 milestone deprecation period (if this isn't long enough please let me know).

Spec bits still need to be updated.

Please let me know if this plan is still ok to move forward with.

Thanks,

Raymes

[Philip Jägenstedt]

Has there been any change in the metrics, and how about the TBD for EME?

The thing that stands out is that so much of the Web MIDI usage seems to be in iframes, do you have any idea why that is?

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

[Raymes Khoury]

Here are the updated numbers for geolocation, midi, mic/camera. They haven't varied significantly since the last post.

 

Permission	% Page loads using permission from iframe
Geolocation	0.0002%
Midi	0.0043%
Mic+Camera	0.0002%

Midi usage from iframes is known to by high because it's currently being abused for fingerprinting (among other things). Disabling default usage from iframes will help reduce this abuse.

I forgot to add the metrics for EME. I will do that now. We expect EME usage to be lower than geolocation (the number of permission prompts shown for EME is 1/100th of the number of geolocation prompts). If it sounds reasonable, we could add the deprecation warning but check back in with numbers for it prior to shipping.

Thanks,

Raymes

[Rick Byers]

I'm really excited to see this happen ASAP!  There's definitely some compat risk, but in general (like for Midi) that's going to be hard to tease apart from the security/privacy benefits this change aims to achieve.  My instinct is that the compat risk is low enough and security/privacy benefits are high enough that the change easily meets the bar.

To me the main outstanding questions are:

1) Getting this specified / tested properly.

At a minimum can you point to spec issues that track adding each of the new "allow" to each of the relevant specs?  Ideally we'd have those spec and web-platform-test changes landed before shipping.  But given the relatively good state of the feature policy spec and informal features catalog (which Ian says he'll add spec/bug links too) and the challenge of getting multiple different editors to update different specs, perhaps we don't want to block on getting each individual spec updated here?

2) What are we doing for developer outreach?

We may break some legitimate use cases, and due to the challenge of co-ordinating between embedders and embedded pages it may take some time for sites to update.  I'm guessing it's probably important that our chromestatus entry links to a blog post or something describing clearly how to fix the issue (get embedding pages to add "allow=foo").

By the way, is this intent still just about these 4 permissions?  Ian mentioned to me that he thought you had others in the works too (but maybe those will be covered by a future intent)?

Thanks!

   Rick

Raymes

LGTM1.

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

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

[Philip Jägenstedt]

On Thu, Jun 15, 2017 at 4:31 PM Rick Byers <rby...@google.com> wrote:

I'm really excited to see this happen ASAP!  There's definitely some compat risk, but in general (like for Midi) that's going to be hard to tease apart from the security/privacy benefits this change aims to achieve.  My instinct is that the compat risk is low enough and security/privacy benefits are high enough that the change easily meets the bar.

Agreed.

 

To me the main outstanding questions are:

1) Getting this specified / tested properly.

At a minimum can you point to spec issues that track adding each of the new "allow" to each of the relevant specs?  Ideally we'd have those spec and web-platform-test changes landed before shipping.  But given the relatively good state of the feature policy spec and informal features catalog (which Ian says he'll add spec/bug links too) and the challenge of getting multiple different editors to update different specs, perhaps we don't want to block on getting each individual spec updated here?

At minimum I think we should have open spec issues, and something (a Chromium issue?) that keeps them on the radar of the Feature Policy work.

Spec editor time is a scarce resource, so where at all practical, what I think "we" should actually do is to write the spec change PRs. Nobody in particular is on the hook to sort these things out after the fact.

Raymes

LGTM1.

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

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

[Raymes Khoury]

Thanks Philip and Rick!

> 1) Getting this specified / tested properly.

At a minimum can you point to spec issues that track adding each of the new "allow" to each of the relevant specs?  Ideally we'd have those spec and web-platform-test changes landed before shipping.  

Spec bugs are here:

Geolocation: https://github.com/w3c/geolocation-api/issues/10

EME: https://github.com/w3c/encrypted-media/issues/371

Midi: https://github.com/WebAudio/web-midi-api/issues/177

Mic/Camera: https://github.com/w3c/mediacapture-main/issues/434

I added these links to the comments of the chromestatus entry.

I agree that we would ideally have spec PRs and web platform tests before shipping and this is actually still my goal. I've already drafted some of the tests. I thought it would be best not to block adding the deprecation warnings on these though.

> 2) What are we doing for developer outreach?

I've drafted up a chromium.org post, similar to what we had for the https deprecation of powerful features: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes. Happy to iterate on this.

I included it in the chromestatus entry. We could decide to link directly to the sites page in the console warning if we think it will be better for developers (I think it may be).

I will also explore options with our dev-rel team and ask our API owners to ping any contacts they may be aware of that use these features. I would be happy to check-in on this prior to shipping the console warnings if that's preferable.

> By the way, is this intent still just about these 4 permissions?  

Yep, it's just these 4. If there is anything I happen to have missed we can do it in a separate deprecation, but these are certainly the main ones.

Cheers,

Raymes

[Philip Jägenstedt]

On Mon, Jun 19, 2017 at 7:57 AM Raymes Khoury <ray...@chromium.org> wrote:

Thanks Philip and Rick!

> 1) Getting this specified / tested properly.

At a minimum can you point to spec issues that track adding each of the new "allow" to each of the relevant specs?  Ideally we'd have those spec and web-platform-test changes landed before shipping.  

Spec bugs are here:

Geolocation: https://github.com/w3c/geolocation-api/issues/10

EME: https://github.com/w3c/encrypted-media/issues/371

Midi: https://github.com/WebAudio/web-midi-api/issues/177

Mic/Camera: https://github.com/w3c/mediacapture-main/issues/434

I added these links to the comments of the chromestatus entry.

I agree that we would ideally have spec PRs and web platform tests before shipping and this is actually still my goal. I've already drafted some of the tests. I thought it would be best not to block adding the deprecation warnings on these though.

That sounds good, thanks for filing the issues. The Media Capture one is old, and it looks like https://github.com/w3c/mediacapture-main/pull/440 could use some poking.

 

> 2) What are we doing for developer outreach?

I've drafted up a chromium.org post, similar to what we had for the https deprecation of powerful features: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes. Happy to iterate on this.

I included it in the chromestatus entry. We could decide to link directly to the sites page in the console warning if we think it will be better for developers (I think it may be).

If you think that's better, then go ahead. It was done for for some secure origin messages already.

 

I will also explore options with our dev-rel team and ask our API owners to ping any contacts they may be aware of that use these features. I would be happy to check-in on this prior to shipping the console warnings if that's preferable.

> By the way, is this intent still just about these 4 permissions?  

Yep, it's just these 4. If there is anything I happen to have missed we can do it in a separate deprecation, but these are certainly the main ones.

This was an Intent to Deprecate and doesn't appear in https://bit.ly/blinkintents because of the title. Changing the title so that it will show up and giving my LGTM1 to remove.

[Rick Byers]

Thanks!

LGTM2

[Chris Harrelson]

LGTM3 to remove.

--
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/CAFUtAY9wR7cEztwuLmD%3DcO1odjbjdqup2pEJ5sCwyAvmQE7hKw%40mail.gmail.com.

[agha...@google.com]

Hi all,

Could someone kindly clarify how inheritance of Feature Policy works with nested frames?

In the following scenario:

<iframe id="one" allow="geolocation">

  <iframe id="two" allow="microphone"><iframe>

</ifame>

Question 1) is frame 2 denied microphone  despite allow="microphone" being present since parent frame did not have `microphone` in the first place to give it away?

Question 2) does frame 2 implicitly inherit geolocation despite allow="geolocation" not being present since parent frame had it?

My expectation is: Q1) yes Q2) no . but I am not sure if that's the intended behaviour.

Thanks!

-Ali 

[Rick Byers]

Right, the way it's supposed to work is Q1) yes, Q2) no. Conceptually every frame in the chain (including the top document) has to approve delegating a permission it has downward.

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fa8717a-817c-424d-baa2-a61d2850dc7d%40chromium.org.

[Ali Ghassemi]

Great. Thanks for confirming.