Shared Workers

[Sorunome]

I am using Firefox, so I don't know how the following issue I'm trying to outline is in chrome or another browser:

I am using this shared worker and I find the way how to set them a bit confusing. Let's say I have a site example.com and a shared worker in that site.
Now, I allow scripts on example.com while in the top-left corner thing (That blue box) example.com is selected. However, the shared worker will not work. Instead I have to additionally allow scripts on example.com while in that top-left corner thing * is selected.

I am guessing that this is because the shared worker is running detached from domains, however it is IMO still a bit...weird to set. Perhaps putting workers into the "other" category or something would make it more clear?

[gorhill]

Did you look at the logger to find out in which context the network requests from the shared worker are fired?

[Sorunome]

That was trial and error, but as I wrote the JS program in question i know for sure that example.com creats it.

[gorhill]

i know for sure that example.com creats it.

I do not doubt this. Looking at the logger will tell you how uMatrix sees it.

[Sorunome]

Apparently it sees it as behind-the-scene. That still doesn't mean there's an easy way to set it, only a way to manually set it in the ruleset

[gorhill]

Apparently it sees it as behind-the-scene.

So there is nothing uMatrix can do -- the browser is not telling it from which tab the network request occurs.

The matrix UI can be brought up from the logger, and a behind-the-scene rule can be created from there.

[Sorunome]

Well, that is exactly whatshared workers are for: having a JS runtime that are not attached to a tab, so that you can have e.g. only one websocket connection open for multiple tabs to your server. Or do some other lifiting into that shared environment. (So I wouldn't say htat it's a browser bug, as, well, the browser can't report a tab its belonging to as there isn't ONE tab it's belonging to)

What may be an option is add to that blue drop-down thing the behind-the-scenes or something in addition to * or something?

[Okamoi]

It isn't assigned to a single tab but it is assigned to a single origin. The browser should communicate that origin to uMatrix one way or another, if it doesn't, I agree that it should be fixed. (So that it is a browser "bug")

[gorhill]

Without an actual repro case, it's unlikely I will care to look into this -- I can't be asked to go on a time-consuming hunt to merely find a test case which should have been provided in opening comment.

[Okamoi]

Is it not because of this lack of origin reported by the browser that uMatrix 1.2.0 has to use an exceptional block/allow approach for WebWorkers themselves, rather than for network requests made by WebWorkers ?

Essentially, why should WebWorkers receive a different treatment than regular JavaScript ? Both in terms of privacy, security or annoyance, they have the same potential.

Miners sure are one reason to block the entire feature. But then uMatrix should provide a feature-blocking switch for Canvas, WebGL, WebAudio and multiple JS APIs that are abused for fingerprinting as soon as JS is allowed... While I don't disagree with such an approach, it's probably best unified under privacy.resistFingerprinting.

Service workers are the special kind of workers that can arguably be handled separately, but WebWorkers I don't understand ? For me, it is up to the browser to tell an add-on which origin a WebWorker belongs to, and then the add-on can filter WebWorker requests as it would with regular JS requests. (= I don't treat WebWorkers differently than JS)

[uBlock-user]

uMatrix should provide a feature-blocking switch for Canvas, WebGL, WebAudio and multiple JS APIs that are abused for fingerprinting

What's the point ? The website will choke and break. These specific APIs are used, for example, by Twitter and Youtube and blocking one of those breaks their functionalities or breaks the entire website altogether. Blocking the JS itself renders all these APIs dead.

[gorhill]

why should WebWorkers receive a different treatment than regular JavaScript ?

Why do web workers have their own content security policy directive (worker-src)?

If you disagree with uMatrix treating web workers separately than plain javascript (script-src), you may want to also head to https://github.com/w3c/webappsec-csp/issues to express your disapproval.

There are already real concrete cases of how being able to block workers independently of 1st-party scripts is beneficial.

[AllanWegan]

An example for a webworker wich requests i do not see at all in the log:
https://thedisconnect.co/one/
Chromium 64.0.3282.186 on Gentoo.

[uBlock-user]

i do not see at all in the log:

I can see in the log and in the console and it's detected on the web workers switch too

[gorhill]

@AllanWegan Could be because you have another extension which modifies the CSP header, thus preventing uMatrix from successfully modifying the same CSP header (two extensions can't modify the same response header).

[gorhill]

Another possible explanation is that the worker was already allowed to run before you enabled uMatrix. Since the site uses a service worker, it could have been launched before uMatrix was running, and once the service worker is already running, the browser won't try to launch it -- hence can't be caught by uMatrix. Go to chrome://serviceworker-internals/ and shut it down then try again.

[AllanWegan]

Now that was unexpected: Chromium sometime keeps running the webworker for a minute or so after closing the tab. And they also seem to get cached, so it was already there when i came back to the site later and started poking around.
Would be nice to have a seperate column for web workers in uMatrix between XHR and frame.

[gorhill]

It is now possible with both Chromium (63+) and Firefox/webext to reclassify these behind-the-scene network requests so that they are properly filtered. Fixed in 31cc15c#diff-e89c0f548b51d6b02baea1e832b9d8ba. Side effect is that the logger may not properly report these "internally reclassified" network requests, this will be fixed with #951.