The extension does a lot more, just have a look when creating a custom profile. Bluntly blocking XHR requests is stupid, generates to many false positives, probably another block is causing the test to hang (in Edge it just not responding). Could be poor programming in the extension, the test website or Firefox, who knows?
JShelter - JavaScript Restrictor
- Thread starter SpiderWeb
- Start date
- Feb 25, 2017
- 2,597
I know that the extension is doing a lot more, but I am using recommended profile that doesn't have the filtering of XMLHttpRequests enabled, so I can exclude that as an option for the website breakage... Considering that my first link only checks the Audio Fingerprint, it has to be somewhat connected to that setting in the extension.
@SecureKongo Could be but firefox crashes and Edge not with same extension, so more likely poor programming in Firefox is to blame
Last edited by a moderator:
- Feb 25, 2017
- 2,597
Version 0.6 released:
* New protection: Fingerprint detector, see the blogpost for explanation.
* Physical environment wrapper group added. It contains `Sensor`, `Magnetometer`, `Accelerometer`, `LinearAccelerationSensor`, `GravitySensor` wrappers. Some readings might be inconsistent. `Gyroscope` and `Orientation` sensors will be a part of a future release.
* It is possible to import/export configuration (Github issue #159).
* Improved accessibility of the pop up and option pages.
* Bugfix: Fix double injection of some wrappers. For example, this solves regression in Geolocation wrapper introduced in 0.5.
The new Fingerprint detector does this:
PS: After the new update the extension requires new permissions.
* New protection: Fingerprint detector, see the blogpost for explanation.
* Physical environment wrapper group added. It contains `Sensor`, `Magnetometer`, `Accelerometer`, `LinearAccelerationSensor`, `GravitySensor` wrappers. Some readings might be inconsistent. `Gyroscope` and `Orientation` sensors will be a part of a future release.
* It is possible to import/export configuration (Github issue #159).
* Improved accessibility of the pop up and option pages.
* Bugfix: Fix double injection of some wrappers. For example, this solves regression in Geolocation wrapper introduced in 0.5.
JS Restrictor was rebranded to JShelter
polcak.github.io
The new Fingerprint detector does this:
PS: After the new update the extension requires new permissions.
For me, when I set to Level 3 (using the latest v0.6) it prompts each time when I search something in the address bar. See below
So your without XHR in Level 4 is out of necessity or because of the constant annoyance? What's the reason for enabling XHR in Level 3 vs without XHR in Level 2..........a kind of security protection? Any issue without XHR?
Thanks
Last edited:
XMLHTTPrequest, XHR for short and its succesor a 'Fetch' were intended to get data and meta data in one go. XHR can be used for user tracking, but it is heavily used in Ajax (for normal usage, nothing suspicious). So I have really no idea why they included it, when they were not able to recognise 90% of the legit usage of XHR. To compare it with a real world scenario: when walking outside a pigeon can deposit the content of its intestines on you , so every time you walk outside a police offer stops you in your tracks and asks you "are you aware of the pigeons". Annoyance and 'there are bigger fish to catch in the ocean' are the reasons I excluded it from level 3
Last edited by a moderator:
- Jul 5, 2019
- 607
You wouldn't also block fetch? Blocking fetch is an option in NoScript, at default not activated.
XHR/fetch purpose is nearly the same, only fetch is a better and newer API (link) When I enable fetch in NoScript it also blocks XHR requests (so NoScript monitors both API's). I think that the developer of NoScript is telling "hey I am more up to date than other script blockers" (like ScriptSafe, ScriptNo, NotScript etc).
Last edited by a moderator:
@Jan Willy talking about NoScript, look who is involved also?
Maybe a new (Manifest V3) NoScript is in the making with added tracking protection?
Maybe a new (Manifest V3) NoScript is in the making with added tracking protection?
Hi, I have been working on JShelter project recently. If you have any questions, feel free to ask. For now, project is under development. We are currently working on a brand new GUI, rebranding (JSR to JShelter), and overall user experience. We already addressed many comments from this thread like annoying XHR alerts, confusing settings, random slowdowns and so on. These updates are on the way.
And don't be mistaken, this is not a script-blocking extension like uBlock. JShelter modifies default JS APIs to reduce coverage of possible threats (just like Brave does). It is recommended to use JShelter in conjunction with other ad/script blocking extension. It's just another layer of protection in cases when malicious scripts weren't blocked properly.
And don't be mistaken, this is not a script-blocking extension like uBlock. JShelter modifies default JS APIs to reduce coverage of possible threats (just like Brave does). It is recommended to use JShelter in conjunction with other ad/script blocking extension. It's just another layer of protection in cases when malicious scripts weren't blocked properly.
- Feb 25, 2017
- 2,597
Great having you here! It would also be much appreciated if you could update the protection level info page as it shows different descriptions than the actual custom settings within the extension. Can be quite confusing at times. Also, great to hear that you guys are working on a new UI. I think it's definitely needed.
The anti fingerprinting protection could also use some optimization as it literally blocks like 50% of all the pages I try to access. It even blocks all google search results...
Last edited:
- Mar 29, 2018
- 7,697
Welcome @Sunkar. Always great to have developers here. You have all of us testing junkies here to assist you with feedback!
You have all of us testing junkies here to assist you with feedback! 
- Aug 21, 2020
- 609
Time to revisit this extension since I switched from Chrome to Firefox. Might behave differently.
Update: Reinstalled. it's much faster than before. Recommended setting seems to be the best. High settings gives off too many pop ups and breaks too many sites. No discernible difference on Recommended (Level 2). I tested on browserleaks.org and it is giving me all of my true user agent data and a unique fingerprint lol. It doesn't seem to do anything on my end.
Update: Reinstalled. it's much faster than before. Recommended setting seems to be the best. High settings gives off too many pop ups and breaks too many sites. No discernible difference on Recommended (Level 2). I tested on browserleaks.org and it is giving me all of my true user agent data and a unique fingerprint lol. It doesn't seem to do anything on my end.
Last edited:
First of all good to see you are joining this forum. It is one of the best ways to get feedback on security/privacy, thanks for joining
In Dutch we have a saying based on 17th century sailing and trading history which says "the flag should represent the cargo". In branding this translates that the name of the product should represents its purpose/benefits (functional name) or relate to the user/life style group you are targeting (fantasy name).
I have a hard time discovering which assocations you used to come up with a name. When this extension modifies API's to prevent misuse, why did you call the extension "JAVASCRIPT SHELTER" in the first place?
FEATURE REQUEST 1
In stead of randomizing responses, which results in non-existing values making it very easy to fingerprint someone OVER DIFFERENT SESSION when combined with IP/address and/or GEO location, it is much better to hide in the herd.
Because data can be combined from different sources and some data categories are related, it is much better to hide in the herd using realistic most prevalent values than generating random return values. By reducing the precision of some API-results (e.g. time/geo) and providing most common or default values related to OS/rendering engine (chromium based/firefox/Safari)/browser language it is much harder to back track returning users.
FEATURE REQUEST 2
Allowing users to define which API's to block makes no sense, because most users don't know that plug-ins/accepts/navigator data can be combined from the user agent or are related to each other (e.g. geo location, time and language). In 9 out of 10 cases an average home user starts fiddling with these settings that user makes himself more unique and easier to track.
Presets should be based on functionality and risk of website breakage. A better approach would be to offer four levels of protection and allow a user to change this setting for a website: 0 = OFF for trusted websites, 1 = best for compatibility, 2 = balanced, 3 = best for protection
Regards Kees
Last edited by a moderator:
- Aug 21, 2020
- 609
Is there a site where you can actually test this working? Every site I have visited completely ignored JShelter and detected my browser, location, microphone, camera (both disabled by default), timezone, etc. What is this enforcing? Is it sandboxing? I don't understand...
@SpiderWeb
Modern browsers have a lot of predefined services and functions which a website can use. These functions are accessed through interfaces called API's short for Application Program Interface. These API's provide a website all sorts of useful data to provide you with the best web experience (e.g. screensize, language, night time dark or day time light background etc).
Over the years new and improved API's were standardized in browsers by the W3C, up to a point that a browser by default provides so much information that by combining this data you can be uniquely tracked. JShelter intercepts and changes the results when a website calls these API's (using javascript). For instance reducing the granularity of your time and geo-location. This makes it harder to pin-point you.
Problem with most of these extensions is that it requires a lot of knowledge to configure them correctly (only the Pro version of an expensive extension like Cydec has all data points covered*) and when blocking one API to your data, often another API provides similar data, so by combining stuff you are still fingerprinted.
The good thing about JShelter is that it is a subsidized project and related to a educational organization (so hopefully funds and knowledge are available for the long term). Many of the API-blurring extensions started with a first version, but stranded because it required to much manpower and knowledge. I am keeping an eye on JShelter because it may have a chance of actually succeeding in providing a version for the average user.
What may help them is that the browser developers also are working on ways to limit the use (retrieving info) using these API's. When I recall correctly Google has submitted an idea to the W3C (organization which defines the web standards) to give a website an API-budget. When a website exceeds its budgets, browsers will start to shield access to other API's. I thought that Microsoft supported the idea, but browsers which are a bit further on this field (Firefox, Brave and Apple) are opposed (because they would lose their advantage).
___
* As far as I know and I am retired so my knowledge is aging
Modern browsers have a lot of predefined services and functions which a website can use. These functions are accessed through interfaces called API's short for Application Program Interface. These API's provide a website all sorts of useful data to provide you with the best web experience (e.g. screensize, language, night time dark or day time light background etc).
Over the years new and improved API's were standardized in browsers by the W3C, up to a point that a browser by default provides so much information that by combining this data you can be uniquely tracked. JShelter intercepts and changes the results when a website calls these API's (using javascript). For instance reducing the granularity of your time and geo-location. This makes it harder to pin-point you.
Problem with most of these extensions is that it requires a lot of knowledge to configure them correctly (only the Pro version of an expensive extension like Cydec has all data points covered*) and when blocking one API to your data, often another API provides similar data, so by combining stuff you are still fingerprinted.
The good thing about JShelter is that it is a subsidized project and related to a educational organization (so hopefully funds and knowledge are available for the long term). Many of the API-blurring extensions started with a first version, but stranded because it required to much manpower and knowledge. I am keeping an eye on JShelter because it may have a chance of actually succeeding in providing a version for the average user.
What may help them is that the browser developers also are working on ways to limit the use (retrieving info) using these API's. When I recall correctly Google has submitted an idea to the W3C (organization which defines the web standards) to give a website an API-budget. When a website exceeds its budgets, browsers will start to shield access to other API's. I thought that Microsoft supported the idea, but browsers which are a bit further on this field (Firefox, Brave and Apple) are opposed (because they would lose their advantage).
___
* As far as I know and I am retired so my knowledge is aging
Last edited by a moderator:
Thank you all for welcoming .
Please, can you give me more information about your issues with fingerprinting detection? I'm directly responsible for this feature and would like to replicate the problem. For me and my colleagues it's working as intended. Can you share your Firefox version and OS via PM?
But if you will, you can compare output data of different JS APIs on our test page (with and without the extension). It won't simply hide or change your userAgent because it may introduce inconsistency of the fingerprint and make it more unique. What we want to achieve is to create separate consistent fingerprint for each visited domain, so trackers from different domains cannot link your online activity.
FEATURE REQUEST 1
Already doing this way and some more info about "hiding in the herd".
FEATURE REQUEST 2
Definition of a custom level is intended for advanced users. We recommend to use pre-built levels. I honestly don't understand the last paragraph, as we already using pre-built levels and users can change the setting for a website. By default, all websites have assigned recommended setting. If you change it, it will be saved for this website in the future.
Thanks again for your feedback. You can report any issue or feature request here.
.Thanks for feedback. In the near future, we will drop the old page that you have linked and be using a new one. I think, the clarification of description within the extension is planned for 0.7 GUI update.Great having you here! It would also be much appreciated if you could update the protection level info page as it shows different descriptions than the actual custom settings within the extension. Can be quite confusing at times. Also, great to hear that you guys are working on a new UI. I think it's definitely needed.
The anti fingerprinting protection could also use some optimization as it literally blocks like 50% of all the pages I try to access. It even blocks all google search results...
View attachment 263586
Please, can you give me more information about your issues with fingerprinting detection? I'm directly responsible for this feature and would like to replicate the problem. For me and my colleagues it's working as intended. Can you share your Firefox version and OS via PM?
You shouldn't be aware of the changes. If you can tell something has changed, potential attacker will do as well. I recommend to take a look at our blogs to get a better understanding how the extension works.
But if you will, you can compare output data of different JS APIs on our test page (with and without the extension). It won't simply hide or change your userAgent because it may introduce inconsistency of the fingerprint and make it more unique. What we want to achieve is to create separate consistent fingerprint for each visited domain, so trackers from different domains cannot link your online activity.
Thanks for feedback. Unfortunately, I wasn't involved in the naming process. From what I know, it was initially called JS-Shield, but we changed it to supposedly more original name (to match the logo). However, I don't think Privacy Badger or Ghostery are more self-explanatory in this regard.First of all good to see you are joining this forum. It is one of the best ways to get feedback on security/privacy, thanks for joining
In Dutch we have a saying based on 17th century sailing and trading history which says "the flag should represent the cargo". In branding this translates that the name of the product should represents its purpose/benefits (functional name) or relate to the user/life style group you are targeting (fantasy name).
I have a hard time discovering which assocations you used to come up with a name. When this extension modifies API's to prevent misuse, why did you call the extension "JAVASCRIPT SHELTER" in the first place?
FEATURE REQUEST 1
In stead of randomizing responses, which results in non-existing values making it very easy to fingerprint someone OVER DIFFERENT SESSION when combined with IP/address and/or GEO location, it is much better to hide in the herd.
Because data can be combined from different sources and some data categories are related, it is much better to hide in the herd using realistic most prevalent values than generating random return values. By reducing the precision of some API-results (e.g. time/geo) and providing most common or default values related to OS/rendering engine (chromium based/firefox/Safari)/browser language it is much harder to back track returning users.
FEATURE REQUEST 2
Allowing users to define which API's to block makes no sense, because most users don't know that plug-ins/accepts/navigator data can be combined from the user agent or are related to each other (e.g. geo location, time and language). In 9 out of 10 cases an average home user starts fiddling with these settings that user makes himself more unique and easier to track.
Presets should be based on functionality and risk of website breakage (hardware screen ration might affect display). A better approach would be to offer four levels of protection and allow a user to change this setting for a website: 0 = OFF for trusted websites 1 = best for compatibility, 2 = balanced, 3 = best for protection
Regards Kees
FEATURE REQUEST 1
Already doing this way and some more info about "hiding in the herd".
FEATURE REQUEST 2
Definition of a custom level is intended for advanced users. We recommend to use pre-built levels. I honestly don't understand the last paragraph, as we already using pre-built levels and users can change the setting for a website. By default, all websites have assigned recommended setting. If you change it, it will be saved for this website in the future.
Thanks again for your feedback. You can report any issue or feature request here.
Last edited:
At the moment the implementation of WebGL returns non-real world values
WebGL should pass valid GPU cards at Unmasked Vendor
Plugin fingerprinting should provide only default plugins for all Chromium based browsers (Chrome, Edge, Opera, etc), a default one for Firefox and Apple. Same for font-fingerprinting only return the defaults for the OS. Better than adding fake/wrong values for that OS/browser.
Ad Feature request 2
I de-installed JShelter to quickly (after a quicktest on browserleaks.com)
, thought that the setting applied to all websites, sorry for the confusion
Last edited by a moderator:
Good point. Unfortunately, I cannot comment on why this decision was made as I'm not an author. According to JShelter blog, it should behave like that only for the maximum protection level. Apparently, it is random on recommended level too, right? This should be considered a bug. Can you make an issue on this on our github page? Maybe you can get a definitive answer for this.At the moment the implementation of WebGL returns non-real world values
WebGL should pass valid GPU cards at Unmasked Vendor
View attachment 263592
Plugin fingerprinting should provide only default plugins for all Chromium based browsers (Chrome, Edge, Opera, etc), a default one for Firefox and Apple. Same for font-fingerprinting only return the defaults for the OS. Better than adding fake/wrong values for that OS/browser.
Ad Feature request 2
I de-installed JShelter to quickly (after a quicktest on browserleaks.com)
