Re: Manifest v3

Hi Libor,

* Background script -> service workers
* We will not have the possibility to keep any state, this will affect Network Boundary Shield (NBS), we cannot prepare code in advance, and there will be probably more breakage like updating badges when switching tabs.

The state can be kept in chrome.storage.local, and some in-memory cache may be used until the service worker is shut down and respawn (which may happen at any time), but surely there will be at least some performance hit from this, negligible or huge depending on what we used state for.

I wouldn't mind too much about NBS though, because IMHO is doomed anyway on Chromium (see below).

* We might need to revert 6b51fa8606c71b5057471e1a91fd7ffc410a019a which improved the reliability of the wrappings being applied before page scripts start executing.

This, I hope, is a minor concern because of the changes I'm about to introduce in script injection (taken from the NoScript Commons Library), which should shield the differences between Firefox and Chromium while addressing the CSP issue and others as well, like circumvention of the replaced properties / functions by reaching DOM prototypes from different windows and ways to single out replaced functions for fingerprinting purposes.

* Web Request API -> Declarative Net Requests
* Right now only NBS is affected (so far I think that NBS will need to be removed from chromium-based browsers),
* The blocking strategy based on heuristics that I explained on one of the calls will be affected and most likely impossible to im=plement.

Yes, the demise of the blocking webRequest API is the main pain point for anything security related in MV3, and there's no easy work-around other than stating your case in chromium developers court (for instance https://bugs.chromium.org/p/chromium/issues/detail?id=1128112 ) and hoping to be heard.

We can try to open an issue to allow DNT rules based on already resolved IPs (there's no way even an API like firefox's browser.dns is gonna help in a declarative world), or even better for rules based on a private/public host classification pre-computed by the browser itself, even though IIRC gorhill already raised the DNS lack of support issue for uBlock with little results.

But I'd also suggest to entirely drop NBS on Chromium already now in MV2, because the differences with the implementation on Firefox are such that it may provide Chromium users with a false sense of security.

In facts if the threat model, as I understand it, is the same of NoScript's late ABE module, i.e. preventing CSRF from the WAN to the LAN, then building the DNS cache from onResponseStarted is almost useless, because it happens too late (after the HTTP request has already been processed by the victim).

A one-shot request attack using any hostname resolving to the local network will always bypass the "protection"
If multiple passes are needed, the attacker just needs to use multiple subdomains (possibly nested to share cookies, if any, e.g. a.attacker.com, b.a.attacker.com, c.b.a.attacker.com...) in sequence for its requests to go through

The other issues you mention seem minor worries ATM:

communication with the service worker should work, and also reacting to tab changes: they would just reboot the SW in case it had been shut down.
yes, content scripts on document_start will still work as usual, provided that you've got the right host permissions, which will get scarier and more cumbersome for users on install

Anyway, MV3 APIs are still in progress and have lots of bugs yet. I'm experimenting with those on a daily basis while working on the NoScript Commons Library (which, as I said, I plan to use for this project as well), so I'll keep you posted of any interesting finding along the way, either good or bad.

Best

-- G

On 15/02/21 16:29, Libor Polčák wrote:

From:	Giorgio Maone
Subject:	Re: Manifest v3
Date:	Mon, 15 Feb 2021 18:50:40 +0100
User-agent:	None of Your Business 1.0