[roblabla]

It does two things:

1. Do a request to `chrome-extension://<extension_id>/<file>`. It's unclear to me why this is allowed.

2. Scan the DOM, look for nodes containing "chrome-extension://" within them (for instance because they link to an internal resource)

It's pretty obvious why the second one works, and that "feels alright" - if an extension modifies the DOM, then it's going to leave traces behind that the page might be able to pick up on.

The first one is super problematic to me though, as it means that even extensions that don't interact with the page at all can be detected. It's unclear to me whether an extension can protect itself against it.

[dlenski]

> 1. Do a request to `chrome-extension://<extension_id>/<file>`. It's unclear to me why this is allowed.

Big +1 to that.

The charitable interpretation is that this behavior is simply an oversight by Google, a pretty massive one at that, which they have been slow to correct.

The less-charitable interpretation is that it has served Google's interests to maintain this (mis)feature of its browser. Likely, Google or its partners use similar to techniques to what LinkedIn/Microsoft use.

This would be in the same vein as Google Chrome replacing ManifestV2 with ManifestV3, ostensibly for performance- and security-related purposes, when it just so happens that ManifestV3 limits the ability to block ads in Chrome… the major source of revenue for Google.

The more-fully-open-source Mozilla Firefox browser seems to have had no difficulty in recognizing the issues with static extension IDs and randomizing them since forever (https://harshityadav.in/posts/Linkedins-Fingerprinting), just as Firefox continues to support ManifestV2 and more effective ad-blocking, with no issues.

[warkdarrior]

> This would be in the same vein as Google Chrome replacing ManifestV2 with ManifestV3, ostensibly for performance- and security-related purposes, when it just so happens that ManifestV3 limits the ability to block ads in Chrome… the major source of revenue for Google.

uBlock Origin Lite (compatible w/ ManifestV3) works quite well for me, I do not see any ads wherever I browse.

[Valodim]

The mv3 problem was never about "does it work now". It was about "can it keep up". Ad blocking is a cat and mouse game, and the mouse is kneecapped now. You're being slow boiled.

[dlenski]

Well said. I'm glad that as blockers have managed to develop effective approaches under Mv3, but it took a tremendous amount of engineering effort that was only necessary because Google was trying to impose these very large costs on them.

[oefrha]

> chrome-extension://<extension_id>/<file>

These are web accessible resources, e.g. images and stylesheets you can reference in generated HTML. Since content scripts operate directly on the same DOM, it’s unclear how you can tell an <img> or <link> came from the modification of a content script or a first party script. You might argue it’s possible to block these in fetch(), but then you also need to consider leaks in say Image’s load event.

This behavior has been improved in MV3, with option to make the extension id dynamic to defeat detection:

> Note: In Chrome in Manifest V2, an extension's ID is fixed. When a resource is listed in web_accessible_resources, it is accessible as chrome-extension://<your-extension-id>/<path/to/resource>. In Manifest V3, Chrome can use a dynamic URL by setting use_dynamic_url to true.

This should really be the default though.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[frugalmail]

For widget style services: If you need the functionality of an extension to operate, then you can check if it's already installed so you don't ask to install it again.

This is better than forcing the extension to announce it's presences on every web site.