Intent to Ship: Selective Permissions Intervention

[Chromestatus]

Contact emails

jka...@google.com

Explainer

https://github.com/explainers-by-googlers/selective-permissions-intervention

Specification

https://github.com/w3c/webappsec-permissions-policy/pull/572

Summary

When a user grants a website permission to access a powerful API (specifically Bluetooth, Camera, Clipboard, DisplayCapture, Geolocation, Microphone, Serial, and USB), their consent is intended for the site, not necessarily to every third-party script running on the page. In particular, embedded ad scripts running in the main frame or same-origin iframes can currently leverage the page's permission to opportunistically access this sensitive data. The user may not be aware that an advertisement is accessing their information. This intervention aims to better align a granted permission with user intent by preventing ad script in a context with API permission from using it, reinforcing user trust and control over their data.

Blink component

UI>Browser>AdFilter

Web Feature ID

3755

Motivation

No information provided

Initial public proposal

https://github.com/explainers-by-googlers/selective-permissions-intervention

TAG review

A TAG review is not applicable for this change as it does not introduce new web-exposed API surface or change existing API signatures. This is a User Agent intervention designed to better align permission grants with user intent. The change is internal to Chrome's permission-handling logic and follows the precedent set by previous interventions (like the Heavy Ad Intervention or blocking downloads in ad frames).

TAG review status

Not applicable

Risks

Interoperability and Compatibility

I am not aware of other browsers having the AdTracking capabilities to distinguish between ad and non-ad script in a single context as of yet, so I do not expect this to ship on other browsers in the near future. Further, such detection is heuristic driven, fast changing, and unspecified. Denying requests from ad scripts is intended and such scripts can already handle that as these APIs often deny already. Unintentional breakage would include sites in which the AdTracker incorrectly labels a script as ad-script and incorrectly denies their requests. Analysis shows that geolocation intervention occurs on .027% of page loads. I manually verified it is working as intended on the top 20 sites which represent 74% of those interventions. There is no breakage. Bluetooth impacts .372% of page loads. This is due to browser fingerprinting in ad scripts (calling bluetooth.getAvailability). I manually verified it is working as intended on the top 20 sites which represent 27% of the total blocked calls. There is no breakage. The other APIs are all < .00005%

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1357)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/616)

Web developers: No signals

Other signals:

Ergonomics

NA

Activation

NA

Security

None

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Not launching on webview

Debuggability

There is a console warning in M146 (an issue will be added in M147) as well as a reporting API report. These include the violating script, a stack trace, and why the script was considered an ad by Chrome.

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

No
All but webview as that doesn't support the AdTracker yet.

Is this feature fully tested by web-platform-tests?

No
This is an intervention using internal logic. We do have inspector protocol web tests but not external.

Flag name on about://flags

No information provided

Finch feature name

SelectivePermissionsIntervention

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

True

Tracking bug

https://g-issues.chromium.org/issues/435214052

Launch bug

https://launch.corp.google.com/launch/4438786

Measurement

There are custom use counters (to display per-permission data) that are not publicly available. There are public use counters that will be removed as they show all calls to the API from ad script and not just those that would be intervened upon.

Availability expectation

M146

Adoption expectation

NA

Adoption plan

NA

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

It depends on a filterlist of ad-related URLs to seed the ad tracker. Chrome's filterlist is open-source and available at: https://github.com/chromium/chromium-ads-detection/

Estimated milestones

Shipping on desktop	146
Shipping on Android	146

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

The spec change link is to allow the UA to deny permission policy requests for its own reasons. I expect that will merge after this intervention ships or remain a monkey patch.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5138246835240960?gate=6610701965721600

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Zsvf6obPWgQ/m/ifbcUVRpAwAJ

This intent message was generated by Chrome Platform Status.