Hello,

Thank you for your feedback, however, such bahaviour is intended, see, for example, https://jshelter.org/farbling/. Long-term, there is a possibility to provide more believable values, see https://pagure.io/JShelter/webextension/issue/69. For more information, see also the links in that issue.

Hi there, Thanks for your reply. Perhaps I didn't explain myself very well. On the jshelter test page found on your link, https://polcak.github.io/jsrestrictor/test/test.html I get a very UNIQUE and RANDOM result for my web gl (GOOD). On browser leaks, and eff's cover your tracks... I get my very UNIQUE and REAL graphics card vendor (BAD) - but only on the first page load - subsequent page refreshes report the unique and random value as expected. So it seems that jshelter does not mask my vendor correctly. thanks again

Oh, OK, I misread than. Anyway, based on my bad undestanding of the issue, I crated https://jshelter.org/faq/#should-i-create-my-own-level-for-javascript-shield and https://jshelter.org/faq/#i-changed-my-configuration-what-should-i-expect-after-future-updates-of-the-extension-will-i-lose-the-settings.

I will reread your bug report and edit accordingly.

Reading "What wrappers were triggered by the page, list them below: None at first but upon subsequent refresh: ...", I interpret as this issue is actually about no protection applied after first load, alle the groups show 0?

I tried in Chromium 132 on Debian with developer mode on. I have reset my JShelter settings to the default. I go to https://coveryourtracks.eff.org/. I run the test without real tracking company. In the results I get randomized canvas, webgl, and audiocontext fingerprint (expected), randomized hardware concurrency (expected), real amount of system memory (unsure but possibly OK), and real WebGL vendor and renderer (NOT EXPECTED). It also looks like FPD does not detect fingeprinting attempt and all JS groups are reported as not called in the popup (in Firefox, there are many calls to many APIs in various groups so NOT EXPECTED).

When I rerun the same test, it looks like I get consistent results, I always see the real vendor and renderer.

Nevertheless, when I only reload the result page (i.e. not running the test again), the page suddenly displays modified WebGL renderer and vendor. Device memory also changed.

On our github page, I always saw modified WebGL vendor and renderer.

jShelter most likely need to update its NSCL dependencies and take advantage of the new facilities for service worker state persistence.

Unfortunately this can't be done easily because there's no drop-in replacement for the old patchWindows module ability to evaluate strings as code at runtime through the userScripts API (not needed by NoScript anymore). Therefore some work on NSCL itself for retro-compatibility is needed as well.

I'm gonna try giving this a shot over the weekend.

I am finally able to login to this red hat issue tracker again.

Anyway, upon further testing there are many protection functions that jshelter is failing at on the first page load. I'm now using browserleaks dot com to test the extension instead of eff's cover your tracks since it is much faster and more comprehensive.

So far I've noticed that on browserleaks, the following all fail on first page load:

1. Javascript - eg. hardware concurrency and battery status API
2. canvas fingerprint
3. web gl report
4. geo loacation API
5. features detection

So the issue is certainly more problematic than only the gl vendor. I'm only very amateur at extension dev, but service workers seems like a good lead.

@gioma1: Are there any news/expectations?

@gioma1: Are there any news/expectations?

Yes, I've been working on this last week and I expect to release an updated NSCL with retro-compatibility for patchWindow and push a fixed JShelter branch using it later this week, after releasing Tor Browser 14.0.5 (planned for tomorrow).

Should be fixed in https://pagure.io/JShelter/webextension/tree/nscl-update

Unfortunately trying to create a PR via this link results in a 500 server error for me, so I guess it will need to be merged manually?

Hello @gioma1 ,

Thank you.

All seems OK in Firefox. I am thinking about releasing a new JShleter with the updated NSCL as it likely provides benefits.

However, I see problems in Chromium. All works great in integration tests. I also tested on several computers in Chrome and Edge on Windows and all worked well (Chromium 133). But when I try to run JShelter in Chromium directly, the page load takes a long time, for example several seconds (about 10). I tested on thttps://polcak.github.io/jsrestrictor/test/test.html and https://coveryourtracks.eff.org/. It is puzzling to me why I do not see that in integration tests on the same OS. I tested Chromium 132 and 133.

Also, coveryourtracks shows unique fingerprint in Opera (Chromium 132) so JShelter likely does not work in Opera.

I will hold the release at least until Friday so that we are sure not to rush the update.

Hello @gioma1

I have been able to reliably replicate the issue on multiple computers in Chromium, Chrome, and Edge, see versions in the 2-days-old post.

Firstly, in the affected Chromium, I am using NoScript Security Suite. When I temporarily disable NSS, all pages like https://polcak.github.io/ loaded immediately. Also having just NSS means fast load time. So the problem is the combination of JShelter and NSS. Likely, the issue is in the NSCL and any two extensions using NSCL could mean a problem.

To double checked I went to other machine running Windows and Chrome and Edge and the scenario repeated. NSS+JShelter - slow loading time, just JShelter - fast loading time.

Can you have a look at the issue, please?

I also tested in Firefox and the issue does not appear there.

I will postpone public release, however, interested users that do not run both NSS and JShelter can install following instructions at https://jshelter.org/build/. Just make sure to use nscl-update branch.

So the problem is the combination of JShelter and NSS. Likely, the issue is in the NSCL and any two extensions using NSCL could mean a problem.

Yes, it seems some kind of race condition between extensions concurrently using the pure-MV3 (DNR-based) codepath of SyncMessage.

Investigating, thanks.

@polcak could you please check upgrading to latest NSCL?

AFAICT https://github.com/hackademix/nscl/commit/545b1016efd47ca3b149c2913c3ae8c278be2330 should fix our cross-extensions Chromium / MV3 / DNR race condition.

Thank you @gioma1 , now it works correctly. I am in the process of releasing 0.20 with the fixes.