Blocking webRequest usecase - Quick prototyping / deployment of defenses against new security threats (e.g. Leakuidator+)

[hackademix]

Rather than listing countless examples from NoScript's changelog, I'll point out a very recent instance which didn't involve NoScript (initially).

Leakuidator+ is a Chrome/Firefox extension meant to defend against a new quite practical and scary cache-based deanonymization attack presented at Usenix 2022 but already circulating as a preview in various media outlet, including Wired.

Said extension has been developed by the authors themselves in an academic setting, making massive use of blocking webRequest in order to detect and mitigate the attack at various stages, bu keeping track of the request identity across its lifecycle and interacting with the webNavigation API to correlate tabs. It's not clear how this would work with service workers, either: it would likely require fast volatile storage and a blocking suspend/resume mechanism which guarantees not to miss any listener.

Anyway, such a complex semi-stateful logic is utterly impossible with DNR, and testifies how MV3 breaks an important use case for browser extensions, i.e. quick prototyping and deployment / UX testing of experimental security countermeasures against emerging web-based threats.

Furthermore this specific example also highlights the superiority of Firefox's asynchronous blocking webRequest in this regard, already exemplified by the impossibility of porting NoScript's XSS filter to Chromium:

• In order to stay compatible with Chrome-based browsers, the Leakuidator+ had to implement an "after the fact" exception mechanism to clear out legitimate cases (such as online payments, single sign-on and 3rd party authentication system), but this approach, letting users to opt-out from the protection only after it has been applied, may break without recourse non-repeatable transactions.
• By targeting Firefox and the Tor Browser specifically and leveraging their asynchronous blocking webRequest API, NoScript's TabGuard could implements a similar protection whilst allowing users to create exceptions on the fly while the request is suspended, therefore reducing the chances of breaking legitimate user workflows.