WebExtensions section

[dmarti]

user story: As a person who has chosen to reduce privacy labor by delegating the micromanagement of advertising features to a trusted extension, I want to avoid adding an extra to-do item in addition to the extension selection process I have already made.

Add a WebExtensions section to this document, covering how a browser extension can manage this feature similarly to how other advertising-related site functionality is already covered.

(A browser that is a "gatekeeper" in some jurisdictions may require this in order to offer both content-blocking features in extensions and attribution tracking, without preferencing its own service.)

[martinthomson]

An extension always has the option of requesting the "scripting" extension, which gives them the ability to inject script into pages before page-provided script runs. That gives these tools the option of disabling the API invisibly, likely by disabling the saving of impressions.

Most extensions that seek to take on some amount of privacy labor will have this permission by virtue of the type of work that they generally undertake. There is the "browserSettings" API, which includes a few controls that could be expanded to make the disabling of the API more targeted, but I don't see some of the basic controls, like GPC, in the current set, so adding Attribution controls is probably a bit of a stretch.

The question is what additional control might be helpful. It might be reasonable for browsers to provide specialized controls for managing this API, such as inspecting or editing the state of the database that the browser maintains. That's a feature that probably won't make an early cut in deployment. Defining web extension APIs is not a quick process.

What is more likely in this case is that browsers will offer tools through their developer toolkits that give both users and web developers some ability to see what is going on with the API. That's not really up to this group though.

[AramZS]

I think it would be reasonable to bring this to the attention of the WebExtension working group as part of our work submitting this to horizontal review. When we send them that request for review, we'll highlight this issue specifically as something they should look at and give feedback on.

[lenacohen]

I'm a developer for EFF's Privacy Badger extension and we would want a web extension API that can disable the attribution API for our users. We disabled Privacy Sandbox's Attribution Reporting API and Private Aggregation API through the chrome.privacy.websites.adMeasurementEnabled setting (https://developer.chrome.com/docs/extensions/reference/api/privacy). We would prefer that a similar attribution API being built in to all browsers to be just as straightforward for extensions to disable. Ideally, disabling this browser setting would not require an additional script to be injected on each page a user visits. Script injection could be a temporary workaround, but requires host permissions for all sites and increases implementation and maintenance complexity.

[AramZS]

@lenacohen This is really useful, to see how it has been done in the past. We'll raise this with the WebExtension working group and make sure your comment is included so we can get feedback on best practice here. Thank you!

[Rob--W]

(adding some more context given mt's remark above)

Most extensions that seek to take on some amount of privacy labor will have this permission by virtue of the type of work that they generally undertake. There is the "browserSettings" API, which includes a few controls that could be expanded to make the disabling of the API more targeted, but I don't see some of the basic controls, like GPC, in the current set, so adding Attribution controls is probably a bit of a stretch.

FYI Firefox offers a read-only view into GPC: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/privacy/network#globalprivacycontrol
There is a feature request to make it writable: https://bugzilla.mozilla.org/show_bug.cgi?id=1914861
Other browsers do not have a separate API to control GPC, other than using declarativeNetRequest to modify the GPC header: w3c/webextensions#372

[AramZS]

Suggestions from the WebExtension group to review - w3c/webextensions#1040