Contact emails [email protected]
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 (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, 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. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a0651c.050a0220.3c921b.0294.GAE%40google.com.
