Disable "Privacy" Sandbox in Chrome

[convent31]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

Why?

While people migrate to Browsers that treat them as a resource to mine, disabling the "privacy" sandbox can help protect them.

How?

chrome.privacy.websites.topicsEnabled.set({value: false});
chrome.privacy.websites.fledgeEnabled.set({value: false});
chrome.privacy.websites.adMeasurementEnabled.set({value: false});

From https://developer.chrome.com/docs/extensions/reference/privacy/

A specific URL where the issue occurs.

https://developer.chrome.com/docs/extensions/reference/privacy/

Steps to Reproduce

n/a

Expected behavior

n/a

Actual behavior

n/a

uBO version

1.51.0

Browser name and version

Google Chrome 116.0.5845.179

Operating System and version

macOS Version 13.5.2 (Build 22G91)

[iam-py-test]

uBlock Origin already disables those APIs, albeit through a different method: #2714 (comment)
I would be curious if disabling them via the browser APIs has any benefits over uBo's existing approach.
Once advantage of this would be that it could be controlled via a setting in the dashboard, if for some reason somebody wanted to be spied on. Currently, you would need to disable uBo's privacy list (not ideal), disable uBo on a specific site, or disable the specific filters (allows a lot of control but too advanced for most users). I do not think this is much of a concern, as very few people will have a legitimate reason to re-enable these tracking technologies.
The downside of this would be that these settings effect all websites, while uBo's existing approach can be configured (albeit via filters) on a per a page basis and does not effect pages uBo is disabled on. There are also other privacy-invasive APIs (ie idle detection) which can not be disabled via the chrome.privacy API.
Additionally
Thanks

[gorhill]

Maybe "Disable hyperlink auditing" setting could just become "Disable advertiser-friendly APIs", which would just disable everything which is primarily meant to serve advertisers, so hyperlink auditing, and all new Chromium APIs re. "privacy sandbox".

We had a case where disabling the topic API broke some site, it would be interesting to find out if that site would be broken as well when toggling these settings.

[jawz101]

Everything I have learned of it is that Chrome implements it via a setting within the browser. I would think those who would know that it is a choice would already make the decision within their browser's settings.
If they chose to enable blocking of it within uBlock and opt in via their browser settings, they may get confused why it is not working.

And finally, from everything I have learned on security podcasts, Google Topics (the new name for it) actually preserves privacy in several ways.

• The whole thing is opt-in, if you disable it, you're likely just going to get tracked all of the current, aggressive ways uBO already blocks.
• You browse sites, your browser interests are collected and stored within your browser and categorized into one of several buckets based on the taxonomy maintained by the IAB.
• An advertiser comes along and asks for Topics. They get 2 topics returned and one random one not associated with you.
• After something like 30 days, the whole process flushes. This actually makes sense for both a user and an advertiser. It isn't like I always want to be associated with an unending desire to buy USB charging cables.

The whole premise is that it doesn't track you. Instead, it's more akin to how ads used to be in the paper world. If I read Mens Health they probably just think I am a dude. That's it. I'm probably going to see ads for cologne, cars, and protein powder. I would rather have that than a 47 y.o. male from Boston who makes $80,000/yr and likes collecting flashlights and eating pizza.

It doesn't read to me to be tracking, per se. As I understand it, there is little value to store anything on their servers about me which is what I really don't want. Yeah, I hate ads as well, that is why I block them. But the tracking aspect is actually lessened by the concept. I just think a browser add-on developing its own implementation to disable the function could be overengineering and confusing if the user did choose to opt in w/in their browser's own settings.

Personally, I wish I had an addon that rethought some concepts. First, take out the features and rules which can be controlled within the browser itself. And try to address the root causes more rather than the symptoms. If all else fails, hide the symptom.

[bershanskiy]

I implemented the proposed change here, I can make adjustments to it in order to make it acceptable to merge upstream.

A few things need to be done still:

• I added "i" links to docs about these options, but, of course, there are no docs yet. Docs should be written and the links should be updated accordingly.
• Some sites might perform feature detection for these APIs incorrectly and then break when the API is disabled. I believe it is possible to create a scriptlet which would return a fixed list of topics or a randomly selected list. This bogus data would be useless to the site tracking, but it would let the front-end run as normal.

[gorhill]

I am going to pull these changes in next dev cycle, as I want the current dev to reach stable status as soon as possible and it's best to have that sort of changes made at the start of a dev cycle to ensure they are tested for as long as possible before released to stable.