Any progress on this issue? Having to disable JShelter in Firefox because the Web Worker wrapper doesn't function is a bit of a hassle and less than ideal.

edited to add:

I see I can selectively disable the Web Worker wrapper; that's neat. However, the Medium setting doesn't help: I must turn it to Unprotected for MkDocs' search mechanism to function. Examples of MkDocs' search mechanism include:
- MkDocs' site: https://www.mkdocs.org/ (choose "Search" in the heading)
- this site: https://wiki.orc.gmu.edu/mkdocs/ (choose "Search" in the heading)

Unfortunately no progress.

https://pagure.io/JShelter/webextension/issue/86 marked as duplicate.

Examples of sites that brakes with the current Web Worker protection: https://github.com/polcak/jsrestrictor/issues/195

https://github.com/polcak/jsrestrictor/issues/199 marked as duplicate of this bug.

I need to update FAQ and probably should update levels in Chrome. I guess I should remove the wrapper altogether.

We discussed this issue on yesterday meeting. Proposed solutions:

• USE NSCL way to apply the wrappers, see #43

• Remove current worker wrappers. Add wrappers that disable Workers. We discussed that the extension should provide notifications about possible remedies decided by the user.

• We need to update docs and the paper accordingly.

#42 and #50 provides some examples of affected pages.

Giorgio, I think that the current injection method for Firefox uses strict mode for the eval at https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_58. Can we try if to force Firefox to use non-strict mode?

Alternatively, can we reimplement doEval https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_54 to use any of the shim mechanisms that injects code so that we do not need to call eval?

Worker polyfill is from https://github.com/IAIK/ChromeZero/blob/master/chromezero/policies/worker_polyfill.js and that is in turn from https://github.com/nolanlawson/pseudo-worker/blob/master/index.js.

What puzzles me is the unused parameter self.

https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_56 and https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_59 is supposed to create a new scope with this binded to window. Inside the call, the polyfill launches the code (https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_58) that is controlled by a possible attacker (https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_209 and https://pagure.io/JShelter/webextension/blob/main/f/common/wrappingS-HTML-LS.js#_215).

In our case, the eval is executed in strict mode but also in the privileged context. Searching for solutions that would enable such attacker-controlled script accessing global scope and window looks bad to me. I will remove this wrapper and replace it with Worker removal.

New branch with proposed changes https://pagure.io/JShelter/webextension/commits/issuepag80.

I changed the Strict level so that it inserts Worker with correct API but that does not perform the code expected by the page. I added Remove level that removes Worker altogether. Then pages like MkDocs' site: https://www.mkdocs.org/ can add their own polyfill.

I tested in Chromium and it works as expected. Even the Medium level works.

However, Firefox version of Medium level fails on "Permission denied to access object" in main.js on line 107 that is a call of postMessage. That accesses a privileged function created at https://pagure.io/JShelter/webextension/blob/issuepag80/f/common/wrappingS-HTML-LS.js#_60. Giorgio, can you have a look how we can make that function work?

0.12 contains the proposed changes. Once we have the fix for Firefox Medium (renamed to Low) policy, we will release that fix.

#130 is a kind of duplicate of this issue. https://lists.nongnu.org/archive/html/js-shield/2024-02/msg00012.html says that out of 50 most visited websites according to Wikipedia, excluding porn sites, blocked Workers break 9 like WhatsAppWeb, ChatGPT, Linkedin, Spotify, etc.

We talked about the issue at today meeting. Regarding the Firefox issue. We will wait for https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 which should make our lives easier. Otherwise the work invested to the "Permission denied to access object" would be wasted once that API comes in.

We also discussed https://github.com/w3c/webextensions/issues/538. The worker injection API was deemed useful, but difficult to implement. It will not be implemented soon. We should consider to implement a fix on our own. This can be done as a part of a future project, for example.