I'm supportive of this change (as a browser developer supporting several of these high-power capabilities).
On Thu, Feb 26, 2026 at 7:22 AM Chromestatus < [email protected]> wrote: > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22UI%3EBrowser%3EAdFilter%22> > > *Web Feature ID* > 3755 <https://webstatus.dev/features/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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > > -- > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a0651c.050a0220.3c921b.0294.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- 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/CAK-EfXnXO0%3DHHT4wgK80zAnH0GDyN5_d6Dfnf4-A6P_97xW6HA%40mail.gmail.com.
