Proposal: RegisteredContentScript.workers property to inject WorkerScope(s)

[hackademix]

(As discussed in #103)

Main world scripts should be able to modify JavaScript-accessible object (e.g. DOM prototypes or built-in functions) in a way that is transparent and cannot be subverted by page scripts., e.g. to modify or intercept the behavior of built-in objects for additional security, privacy and/or anti-fingerprinting reasons.

This requires them to be injected and running before site scripts in any scope, including WorkerScope(s) (workers, shared workers and service workers), otherwise these scope can be use to circumvent the main browsing context modifications.

Therefore, in addition to the RegisteredContentScript properties already specified, we propose to add:

• workers Optional
  boolean, default false: if true, all the Worker, SharedWorker and ServiceWorker scopes which are associated to the browsing contexts matched this RegisteredContentScript filters will be injected as well.

[oliverdunk]

Thanks for opening this! We discussed it in yesterday's meeting (#742). Safari and Firefox are neutral, since this seems like a reasonable request but hasn't yet come up enough to be high priority to implement. I'm going to follow up from the Chrome side but expect our stance will be similar.

When we review a proposal for this, it would be great to see the use cases listed out in more detail. I think between us we can all think of some of these but they would be nice to have written down. It would also be great to describe further how matching would work. Matching based on the origin / URL the worker loaded from would be easier than matching based on the page it is running for, so that would be our preference unless there are strong use cases that this wouldn't address.

All of this said - usually our advice is that it isn't worth opening a proposal until there is at least one browser that would sponsor (help to move forward) the implementation. I don't think we have that yet so we would be unlikely to merge a proposal PR until we do.

[hackademix]

I truly regret not having been able to attend the 2024-12-19 meeting, which I was very interested into because of this and several other topics, but unfortunately at that time I was at the hospital assisting my mother passing - she was actually declared dead exactly 1 hour after the meeting, at 18 UTC.

it would be great to see the use cases listed out in more detail

Basically any JavaScript execution environment modification an extensions wants to perform to prevent fingerprinting / privacy violations / privilege escalation attempts through APIs which are not strictly tied to a DOM (e.g. grabbing a WebGL context through OffscreenCanvas, or performance measurements of CPU characteristic / memory observation and so on) is moot if cannot be cascaded to workers.

The most prominent concrete case where NoScript currently resorts to absurd hacks (involving the debugger API on Chromium - with its horrible warning notification bar - and the webRequest.filterResponseData one on Gecko) to patch workers is in facts to ensure the webgl capability is actually disabled wherever users decide it must.

Matching based on the origin / URL the worker loaded from would be easier than matching based on the page it is running for

That's correct. However, the "exclude tab" case which we've been encountering in several other places (most recently in #737), especially when the modifications operated by the extension may cause legitimate web content to break, must be taken somehow in account.

What has been done as a "compromise" so far in NoScript is that when a (service worker?) request is not associated to any tab (TAB_ID_NONE) and its initiator is from an origin that has been seen as a document origin in a tab which has been exempted from restrictions, that request is allowed as long as that exempted tab still exist and is exempted.

[oliverdunk]

I truly regret not having been able to attend the 2024-12-19 meeting, which I was very interested into because of this and several other topics

I'm really sorry to hear that. We'd be more than happy to discuss them again in a future meeting - please feel free to suggest them on #743 if you'd be able to attend.

Basically any JavaScript execution environment modification an extensions wants to perform to prevent fingerprinting / privacy violations / privilege escalation attempts

Thanks - that makes sense. We should make sure to include this in any proposal documents for the benefit of anyone who hasn't since this conversation.

That's correct.

To clarify, you would be comfortable with matching only based on the URL the worker was loaded from?

What has been done as a "compromise" so far in NoScript is that when a (service worker?) request is not associated to any tab (TAB_ID_NONE) and its initiator is from an origin that has been seen as a document origin in a tab which has been exempted from restrictions, that request is allowed as long as that exempted tab still exist and is exempted.

I think this workaround actually speaks to the problem browsers would have implementing a solution to #737 for service workers - it is not always possible to attribute a fetch invocation in a service worker to a single tab. I wonder if a better UI here is to ask users if they want to "allow all service workers for this origin" when excluding a tab. I know that isn't as intuitive, but it seems more honest about what is and isn't possible.