There is some feedback on the spec PR: https://github.com/w3c/webappsec-permissions-policy/pull/572. Could you take a look and address it? It would be nice to have the PR land.
-- Dan On Monday, March 2, 2026 at 11:27:29 AM UTC-8 Josh Karlin wrote: > Thanks Vincent and Sangwhan! > > On Sat, Feb 28, 2026 at 12:07 PM Sangwhan Moon <[email protected]> wrote: > >> Also supportive from media/capture, which are superpermissions (albeit >> less abused). >> >> Mildly worried about breaking innocent CDN library users though. >> > > Hosting via a CDN vs 1p is not a problem. Chrome's Ad Tracking > <https://source.chromium.org/chromium/chromium/src/+/main:docs/ad_tagging.md?q=ad%20tagging%20file:md&ss=chromium> > > works by tagging scripts as ad-related if they match Chrome's filterlist > <https://github.com/chromium/chromium-ads-detection>. It will also tag > scripts as ad-related if ad-related scripts are on the V8 stack when they > are loaded. So long as the script's URL doesn't match the filter list and > the script isn't loaded by an ad script, everything should work fine. > > Josh > > >> >> On Feb 27, 2026, at 13:02, Vincent Scheib <[email protected]> wrote: >> >> >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK-EfXnXO0%3DHHT4wgK80zAnH0GDyN5_d6Dfnf4-A6P_97xW6HA%40mail.gmail.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/d6b20cda-efc3-49fa-a0e8-67f62bde6e77n%40chromium.org.
