Update website references to JS Restrictor to JShelter

* Github repository
* JS-Shield repository
* JSR
* Restrictor

website/content/pages/pt/build.md

@@ -4,29 +4,29 @@ Esta é a versão em português!
 
 ### GNU/Linux and Mac OS
 
-1. Go to the project repository: [https://github.com/polcak/jsrestrictor](https://github.com/polcak/jsrestrictor).
+1. Go to the project repository: [https://pagure.io/JShelter/webextension](https://pagure.io/JShelter/webextension).
 1. Download the desired branch, e.g. as zip archive.
 1. Unpack the zip archive.
 1. Run `git submodule update`
 1. Run `make`.
 	* You will need common software, such as `zip`, `wget`, `bash`, `awk`, `sed`.
 1. Import the extension to the browser.
 	* Firefox: [https://extensionworkshop.com/documentation/develop/temporary-installation-in-firefox/](https://extensionworkshop.com/documentation/develop/temporary-installation-in-firefox/)
-		* Use the file `firefox_JSR.zip` created by `make`.
+		* Use the file `jshelter_firefox.zip` created by `make`.
 	* Chromium-based browsers:
 		1. Open `chrome://extensions`.
 		1. Enable developper mode.
 		1. Click `Load unpacked`.
-		1. Import the `chrome_JSR/` directory created by `make`.
+		1. Import the `jshelter_chrome/` directory created by `make`.
 
 ### Windows
 
 1. Install Windows Subsystem for Linux (WSL): [https://docs.microsoft.com/en-us/windows/wsl/install-win10](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
-2. Go to the project repository: [https://github.com/polcak/jsrestrictor](https://github.com/polcak/jsrestrictor).
+2. Go to the project repository: [https://pagure.io/JShelter/webextension](https://pagure.io/JShelter/webextension).
 3. Download the desired branch, e.g. as zip archive.
 4. Unpack the zip archive.
 5. Run `git submodule update`
-6. Open the JSR project folder in WSL, run `make`.
+6. Open the JShelter project folder in WSL, run `make`.
 	* Make sure that `zip` and all other necessary tools are installed.
 	* Note that EOL in `fix_manifest.sh` must be set to `LF` (you can use the tool `dos2unix` in WSL to convert `CR LF` to `LF`).
 7. On Windows, import the extension to the browser according to the instructions for Linux (above).

website/content/posts/crawling.md

@@ -133,7 +133,7 @@ Selenium and Mozilla Firefox with the proxy-based intercepting Web API Manager.
 
 ![image]({attach}/images/crawling-architecture.png)
 
-### The impact on JSR
+### The impact on JShelter
 
 Once we have data from our crawling study, we will compare the data with [another recent study](https://github.com/uiowa-irl/FP-Inspector/blob/master/Data/potential_fingerprinting_APIs.md). As already mentioned, we want to develop a fingerprinting detection based on  counting the number of different
 APIs employed by a page, especially APIs that are not frequently used for benign purposes. When

website/content/posts/farbling.md

@@ -72,22 +72,22 @@ This API is used to list I/O media devices like microphone or speakers.  When fi
 The number of logical processors returned by this interface is modified as follows -- on *balanced* level, a valid value between 2 and the true value, on *maximum* level, a valid value between 2 and 8.
 See the [GitHub issue](https://github.com/brave/brave-browser/issues/10808) for more details.
 
-# Porting Farbling to JSR
+# Porting Farbling to JShelter
 
-Our goal was to extend JSR anti-fingerprinting protections with similar measures to those available in Brave's Farbling.
-We decided to implement Brave Farbling with minor tweaks. As Brave is an open-source project based on [Chromium](https://www.chromium.org/Home), core changes are available in the public [repository](https://github.com/brave/brave-core). Furthermore, as Brave is licensed under [MPL 2.0](https://www.mozilla.org/en-US/MPL/2.0/) license, its countermeasures can be ported to JSR.
-Similarly to Brave, JSR utilises session and domain hashes (currently, we use a different domain hash based on origin, however, we consider switching to the eTLD+1 approach used by Brave). Nevertheless, we ported only those changes that an extension can reasonably apply. So we do not plan to change system fonts as the true set of fonts can leak in several ways (e.g., CSS, canvas). We will keep a close eye on anti-fingerprining techniquest applied by Brave in the future.
+Our goal was to extend JShelter anti-fingerprinting protections with similar measures to those available in Brave's Farbling.
+We decided to implement Brave Farbling with minor tweaks. As Brave is an open-source project based on [Chromium](https://www.chromium.org/Home), core changes are available in the public [repository](https://github.com/brave/brave-core). Furthermore, as Brave is licensed under [MPL 2.0](https://www.mozilla.org/en-US/MPL/2.0/) license, its countermeasures can be ported to JShelter.
+Similarly to Brave, JShelter utilises session and domain hashes (currently, we use a different domain hash based on origin, however, we consider switching to the eTLD+1 approach used by Brave). Nevertheless, we ported only those changes that an extension can reasonably apply. So we do not plan to change system fonts as the true set of fonts can leak in several ways (e.g., CSS, canvas). We will keep a close eye on anti-fingerprining techniquest applied by Brave in the future.
 
-Former JSR defences were left as an option so user can choose which protection they want. For example, for **Canvas API**, JSR retains the old defence that returns a white image, but it is also possible to use Farbling and slightly modify the image.
+Former JShelter defences were left as an option so user can choose which protection they want. For example, for **Canvas API**, JShelter retains the old defence that returns a white image, but it is also possible to use Farbling and slightly modify the image.
 
 `CanvasRenderingContext2D.isPointInPath` and `CanvasRenderingContext2D.isPointInStroke` are modified to return *false* with 5% probability, returning *false* to every call seems to be easily identifiable and it limits the usablity of the calls.
 
 **WebGL**, **Web audio**, **plugins**,  **hardwareConcurrency** and **deviceMemory** have been changed accordingly to Brave. API **enumerateDevices** has the same functionality as in Brave. In addition, we add fake devices to the list. **User agent** wasn't modified because it can cause compatibility issues as we support multiple browsers. Adding empty spaces at the end of UAS seems to be quite a weak countermeasure. We will continue to watch changes in the user agent and may implement some defence in future, although it looks like a [better solution](https://datatracker.ietf.org/doc/html/rfc8942) is on the way.
 
-JSR 0.5 changes the default level -- **level 2** to apply the farbling-based defence for all covered APIs, and it will be very similar to the *balanced* level of *Brave*. **Level 3** is redesigned to partly apply new and partly old countermeasures to provide as little information as possible. Please report websites that does not work correctly with Farbling.
+JShelter 0.5 changes the default level -- **level 2** to apply the farbling-based defence for all covered APIs, and it will be very similar to the *balanced* level of *Brave*. **Level 3** is redesigned to partly apply new and partly old countermeasures to provide as little information as possible. Please report websites that does not work correctly with Farbling.
 
 During the examination of the ported code, we [identified and reported](https://github.com/brave/brave-browser/issues/15882) an issue in the original Brave implementation. The issue was acknowledged and fixed by Brave. This is the beauty of the free software: several projects can benefit from the same code-base and mutualy improve the quality.
 
 # Conclusion
 
-Farbling-based wrappers produce very similar outputs to Brave. So with JSR, Farbling-like capabilities are available in multiple browsers. Nevertheless, keep in mind that the best anti-fingerprinting techniques are still a research question, fingerprinting techniques are deployed for security reasons (and farbling-like anti-fingerprinting masking may complicate some log in processes), so it is not completely clear what defences are the best and the choice of the defences also depends on specific use cases. We will investigate fingerprinting scripts further during the future work on this project.
+Farbling-based wrappers produce very similar outputs to Brave. So with JShelter, Farbling-like capabilities are available in multiple browsers. Nevertheless, keep in mind that the best anti-fingerprinting techniques are still a research question, fingerprinting techniques are deployed for security reasons (and farbling-like anti-fingerprinting masking may complicate some log in processes), so it is not completely clear what defences are the best and the choice of the defences also depends on specific use cases. We will investigate fingerprinting scripts further during the future work on this project.

website/content/posts/fpdetection.md

@@ -3,7 +3,7 @@ title: Catch websites red-handed fingerprinting your browser
 date: 2022-01-14 14:00
 ---
 
-We want to identify [fingerprinting](/fingerprinting/) attempts by counting the number of different APIs employed by a page, especially those not frequently used for benign purposes. This blog post introduces a new fingerprinting protection mechanism - FingerPrint Detector (FPD) available in JavaScript Restrictor (JShelter) 0.6. This tool allows users to gain more control over browser fingerprinting, which has become an invisible threat to our privacy.
+We want to identify [fingerprinting](/fingerprinting/) attempts by counting the number of different APIs employed by a page, especially those not frequently used for benign purposes. This blog post introduces a new fingerprinting protection mechanism - FingerPrint Detector (FPD) available in JShelter 0.6. This tool allows users to gain more control over browser fingerprinting, which has become an invisible threat to our privacy.
 
 ## Heuristics as a template for the fingerprinting detection
 

website/content/posts/localportscanning.md

@@ -1,5 +1,5 @@
 ---
-title: How JavaScript Restrictor prevents other parties from sniffing on your local applications?
+title: How JShelter prevents other parties from sniffing on your local applications?
 date: 2021-06-15 09:00
 ---
 
@@ -73,11 +73,11 @@ need to be applied in this case.
 
 ### Network Boundary Shield to the rescue
 
-JSR contains a Network Boundary Shield (NBS) that blocks outgoing browser requests based on the observed behaviour, i.e. a
+JShelter contains a Network Boundary Shield (NBS) that blocks outgoing browser requests based on the observed behaviour, i.e. a
 page hosted on public internet tries to access local URLs.
 NBS just works and cannot be fooled by changes in the URL path, DNS cloaking or other techniques.
 
-![JSR blocks the scan]({attach}/images/portscan-2_request_blocked.png)
+![JShelter blocks the scan]({attach}/images/portscan-2_request_blocked.png)
 
 Firefox contains DNS API, so NBS works flawlessly. In Chromium-based browsers, the exact blocking
 behaviour depends on how quickly a scanning script can fire the requests and the precise

website/content/posts/pt/crawling.md

@@ -132,7 +132,7 @@ Selenium and Mozilla Firefox with the proxy-based intercepting Web API Manager.
 
 ![image]({attach}/images/crawling-architecture.png)
 
-## The impact on JSR
+## The impact on JShelter
 
 Once we have data from our crawling study, we will compare the data with [another recent study](https://github.com/uiowa-irl/FP-Inspector/blob/master/Data/potential_fingerprinting_APIs.md). As already mentioned, we want to develop a fingerprinting detection based on  counting the number of different
 APIs employed by a page, especially APIs that are not frequently used for benign purposes. When

website/content/posts/pt/localportscanning.md

@@ -72,11 +72,11 @@ need to be applied in this case.
 
 ## Network Boundary Shield to the rescue
 
-JSR contains a Network Boundary Shield (NBS) that blocks outgoing browser requests based on the observed behaviour, i.e. a
+JShelter contains a Network Boundary Shield (NBS) that blocks outgoing browser requests based on the observed behaviour, i.e. a
 page hosted on public internet tries to access local URLs.
 NBS just works and cannot be fooled by changes in the URL path, DNS cloaking or other techniques.
 
-![JSR blocks the scan](localportscanning/2_request_blocked.png)
+![JShelter blocks the scan](localportscanning/2_request_blocked.png)
 
 Firefox contains DNS API, so NBS works flawlessly. In Chromium-based browsers, the exact blocking
 behaviour depends on how quickly a scanning script can fire the requests and the precise

website/content/posts/pt/support.md

@@ -11,7 +11,7 @@ We are very excited to improve the extension further. We will focus on the follo
 
 ### 1. Investigate fingerprinting scripts and prepare wrappers
 
-Review the previously identified APIs suitable for fingerprinting. Select APIs suitable for JSR and
+Review the previously identified APIs suitable for fingerprinting. Select APIs suitable for JShelter and
 add wrappers for these APIs. This work has already started, see issue #66. Additionally, we want to focus
 on identification of methods used for fingeprinting such as those identified by Iqbal et al., see
 https://uiowa-irl.github.io/FP-Inspector/
@@ -27,14 +27,14 @@ fingerprint to the server, (3) prevent storing the fingerprint for later usage.
 ### 3. Code ported from Chrome Zero
 
 In version 0.3, we integrated features of Chrome Zero 7 as it is no longer maintained. By
-integrating the functionality to JSR, we want to keep the counter-meassures available in a
+integrating the functionality to JShelter, we want to keep the counter-meassures available in a
 maintained extension. However, we do not have sufficient tests for the functionality.
 
 ### 4. Evaluation and porting of code from Brave
 
 Brave browser currently implements anti-fingerprinting techniques that aim at providing white lies
 about the browser environment. We want to evaluate the messures and select techniques that are
-suitable for JSR.
+suitable for JShelter.
 
 ### 5. Fixing known bugs
 

website/content/posts/support.md

@@ -12,7 +12,7 @@ We are very excited to improve the extension further. We will focus on the follo
 
 ### 1. Investigate fingerprinting scripts and prepare wrappers
 
-Review the previously identified APIs suitable for fingerprinting. Select APIs suitable for JSR and
+Review the previously identified APIs suitable for fingerprinting. Select APIs suitable for JShelter and
 add wrappers for these APIs. This work has already started, see issue #66. Additionally, we want to focus
 on identification of methods used for fingeprinting such as those identified by Iqbal et al., see
 https://uiowa-irl.github.io/FP-Inspector/
@@ -28,14 +28,14 @@ fingerprint to the server, (3) prevent storing the fingerprint for later usage.
 ### 3. Code ported from Chrome Zero
 
 In version 0.3, we integrated features of Chrome Zero 7 as it is no longer maintained. By
-integrating the functionality to JSR, we want to keep the counter-meassures available in a
+integrating the functionality to JShelter, we want to keep the counter-meassures available in a
 maintained extension. However, we do not have sufficient tests for the functionality.
 
 ### 4. Evaluation and porting of code from Brave
 
 Brave browser currently implements anti-fingerprinting techniques that aim at providing white lies
 about the browser environment. We want to evaluate the messures and select techniques that are
-suitable for JSR.
+suitable for JShelter.
 
 ### 5. Fixing known bugs
 

website/content/wrappers/wrappingS-GEO.js

@@ -269,7 +269,7 @@
 			wrapping_function_args: "successCallback, errorCallback, origOptions",
 			/** \fn fake navigator.geolocation.watchPosition
 			 * navigator.geolocation.watchPosition intended use concerns tracking user position changes.
-			 * JSR provides four modes of operaion:
+			 * JShelter provides four modes of operaion:
 			 * * current position approximation: Always return the same data, the same as getCurrentPosition()
 			 * * accurate data: Return exact position but fake timestamp
 			 */