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/CAANMuaMhtv5VsFjGEFdtusdMie%3DfF8C%2BrqiGvXdFoyxhi7zFGA%40mail.gmail.com.

Reply via email to