I'm not sure if this is the right way to post this, but I can't find a dedicated place or tag for feature requests so this seems closest. Apologies if this ends up being in the wrong place and causes confusion.
While I understand the intention behind the use of the domain for spoofing fingerprinting status, namely in order to make it appear as though you have a persistent identity and thereby hide the fact that you're spoofing your fingerprint, that can cause issues for actually testing fingerprint prevention. For instance I was trying to test the fingerprint protection on creepjs to see how well it worked, but since I never left the website it never changed the information it was spoofing, so creepjs could always identify me. I understand that stopping single websites from identifying you is not what the fingerprinting blocks are trying to stop, however not being able to add some salt to the domain in order to change the spoofed values means it's impossible to test (at least as far as I'm aware) whether or not the fingerprint blocking is actually working.
Adding a configurable salt that would be used in combination with website domain names to spoof values would let you more eaisly test the fingerprinting protection using tools like creepjs. Additionally, while this isn't quite the same thing, I do think being able to randomly generate a new salt after a period of time would also be a feature worth adding. While that does compromise on having a persistent fingerprint for each site, it may still be something people want to do, and if the salt functionality is added it shouldn't be hard to randomly generate a new salt at set intervals. (agian though, I do understand that that's a completely different thing)
Pages affected: https://abrahamjuliot.github.io/creepjs/ (technically it affects every page, but creepjs is where the problem is most apparent) JShelter Version: 0.12.1
Popup information (open JShelter popup on affected pages:
Modify
Detail tweaks of JS shield for this site
[Optional:]
OS: Browser: Other extensions that might affect JShelter behaviour:
The expected result is what occurs, however the intended result would be a way to add a salt to the domain name to generate new spoofed details in order to more effectively test fingerprint blocking
It is not possible (as far as I'm aware) to add a configurable salt to the domain for testing.
This is intended behaviour so it should be reproducible on all platforms
If there is anyway to force Jshelter to add a salt to the domain name I don't know how and haven't figured it out.
I unfortunately do not posses the knowledge of extension programming to solve this issue on my own.
[Was there any progress?]
no
[Other additional notes]
Hello @glisteningglamgowder,
Yes, this is the correct place to suggest improvements. Thank you for doing so. I think that this is in essence a duplicate of #68. If you are interested in a workaround, see #68.
ATM, we do not see this feature as a priority and as we need to redo the storage of hashes for manifest v3, we do not plan any change before that switch.
Feel free to add future comments here, or better, to #68. I will close this one but if you think that this is not a duplicate of #68, please argue here.
Metadata Update from @polcak: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Additionally, while this isn't quite the same thing, I do think being able to randomly generate a new salt after a period of time would also be a feature worth adding.
I am thinking about testing more strategies to the white lies approach that, for example, would not depend on the hash at all. In essence equivalent to random hash for each spoofing.
Advantages:
Disadvantages:
Looking at it, this does appear to be close enough to a duplicate of #68. This is my first time ever even seeing this repo site and I still haven't figured out how to effectively search through the issue tracker and the title didn't jump out at me as being what I was thinking of when making this.
I do think though that it should probably be something directly user controlled rather than automated as #68 suggests however, since, for testing purposes, things like cookies or other actions that "the user expects to provide a fresh state" are distinct variables for tracking, with that said it's just said in passing in #68 so it's not a massive deal.
In either case though it's close enough that I do agree it's probably a duplicate, I mainly suggested adding an option to salt the domain (which I realize in hindsight I called hashing at some points which is probably super confusing. That one word mixup makes the title basically meaningless so, oops. If the word hash doesn't make sense in context, chances are I was sleep deprived and meant to say salt) because salting a string seemed like the easiest route to this functionality given my admittedly very minimal understanding of how this extension works. I figured that since the clear intention was to maintain a consistent hash on a per-domain basis, suggesting an entirely new system be implemented to do something that isn't even intended functionality seemed a bit inconsiderate of dev time.
In any case, I have restarted my browser a few times not even knowing it aparently reset the farbling (according to #68 at least) and it does screw with creep JS rather effectively. Not perfectly, but it definitely does mess with it.
Login to comment on this ticket.