LGTM1 pending resolution to Dan's point about the spec PR. On Tuesday, March 3, 2026 at 11:20:35 AM UTC-8 [email protected] wrote:
> 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/974c36c9-74fd-49bc-97bc-c89a9ab8f2b5n%40chromium.org.
