Thank you! LGTM2

On Tuesday, March 3, 2026 at 12:34:59 PM UTC-8 Josh Karlin wrote:

> On Tue, Mar 3, 2026 at 2:20 PM 'Dan Clark' via blink-dev <
> [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.
>
>
> Agree! Done.
>  
>
>>
>> -- 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
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d6b20cda-efc3-49fa-a0e8-67f62bde6e77n%40chromium.org?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/f2e49c83-3c9a-454d-b5fc-8ba03a81c548n%40chromium.org.

Reply via email to