Remove "Sec-" prefix from Browsing-Topics HTTP header

[dmarti]

Users can manage how they are tracked with third-party cookies using a variety of cookie management browser extensions.

For example, Cookie AutoDelete has more than 200,000 users on Google Chrome. Other extensions offer more advanced functionality and are common enough to be covered at Internet how-to sites. Example: The 5 Best Cookie Editor Extensions for Google Chrome

In the future, however, because the Sec-Browsing-Topics header has a Sec- prefix, extensions will not able to filter Topics API data in the same way that users have come to expect for third-party cookies. This would be a step backward in functionality. See discussion at #183.

In order to address concerns about possible future adfraud extensions (are there extensions that modify third-party cookies for adfraud today?) it might be more practical to replace Sec- with a new prefix such as Ad- so that browser extension reviewers could more easily check which extensions might be modifying ad-related data.

[jkarlin]

Hi Don. Thanks for the report. What use case do you have in mind for an extension? I'm failing to understand why simply disabling topics via the extension is insufficient?

[michaelkleber]

The Sec- prefix on the header is an indication that the contents of the header are chosen by the browser, rather than by arbitrary JS code that happens to make network requests. Topics are indeed an example of information chosen by the browser. So they should be delivered via a Sec- header.

As Josh says, extensions can already turn off Topics. If some extension wants a capability beyond that, then we're happy to have a conversation with them about their use case — and indeed they should open their own issue about it. But I don't think we should be designing something based on hypothetical use cases by unknown and absent parties.

[dmarti]

@jkarlin There are lots of reasons why users choose to manage cookies individually without turning the feature off entirely. See user reviews on the cookie management extensions at Chrome Web Store and elsewhere.

Just to give a few examples of how this existing usage pattern might translate to Topics API: If Topics API is widely adopted, users with Topics API disabled entirely will receive all the crap ads that you get now with third-party cookies turned off (ointment ads featuring the "before" picture, precious metals scams, you know the stuff). So, as a user, you want to be able to filter out topics that are situationally sensitive (I like the food and music associated with Country A but I live in Country B) but still send the topics that are relevant to getting you better ads (I work in web development, planning an ecotourism vacation, etc.)

Another use case might be an extension offered by a retail site that implements the commonly requested "stop showing me ads for stuff I've already bought" feature, by offering to filter out the topics that built up during your online product research session.

See comments https://github.com/patcg-individual-drafts/topics/issues/183#issuecomment-1603502795 and https://github.com/patcg-individual-drafts/topics/issues/183#issuecomment-1603715256

(@michaelkleber This is not a hypothetical use case. This would just be preserving an existing use case for third-party cookies that already, according to Chrome Web Store, has many users. Please re-open.)

[jkarlin]

Hey @dmarti . I just checked and I think you'll be happy to hear that while sec- does prevent js shenanigans with fetch/xhr, it doesn't prevent modification of the header in extensions. So leaving as closed as I believe that is the outcome you were looking for?