security-and-privacy/CanvasBlocker
security-and-privacy/CanvasBlocker
1
0
Fork 0
mirror of https://github.com/kkapsner/CanvasBlocker synced 2024-12-22 12:50:36 +01:00
Code Releases Activity

Text corrections/improvements.

Browse Source
This commit is contained in:
kkapsner 2020-03-22 14:25:15 +01:00
parent e7cef53bac
commit 7cfc43194a
3 changed files with 4 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.documentation/faq/permissions.md
View File

@ -4,7 +4,6 @@ Here is the list of permission that CanvasBlocker needs and the reason why it's
* <all_urls> and tabs: CanvasBlocker needs to be able to interact with all possible urls and tabs as fingerprinting attempts could be done everywhere.
* storage: to store the settings the storage.local API is used.
* activeTab: not needed - will be removed in the next release
* webRequest and webRequestBlocking: to insert the CSR headers in a request in order to protect the data-URLs. Once [this bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1475831) has been fixed I can completely remove the data-URI protection (see [here](https://github.com/kkapsner/CanvasBlocker/issues/208) for further information).
* contextualIdentities and cookies: for support of browser containers. I would like to make this optional for only people that use containers but I cannot (see [here](https://github.com/kkapsner/CanvasBlocker/issues/381) for further information).
* contextualIdentities and cookies: for support of browser containers. I would like to make this optional for only the people that use containers but I cannot (see [here](https://github.com/kkapsner/CanvasBlocker/issues/381) for further information).
* privacy: this permission is needed to read if the user has privacy.resistFingerprinting enabled. A notice about a slightly changed behaviour of CanvasBlocker is displayed in the settings page in that case.

4
.documentation/faq/reCAPTCHA.md
View File

@ -1,5 +1,5 @@
reCAPTCHA is not working!
-----
It's a known fact that the window API protection breaks reCAPTCHAs. The use the window.name API to store information about the captcha. The protection is designed to mitigate exactly such techniques of passing information from one domain to another. But in this case the information is shared with an embedded HTML page (an <iframe> tag). As the information gets lost when the top level page navigates somewhere the tracking potential is quite limited in such a scenario.
It's a known fact that the window API protection breaks reCAPTCHAs. They use the window.name API to store information about the captcha. The protection is designed to mitigate exactly such techniques of passing information from one domain to another. But in this case the information is shared with an embedded HTML page (an <iframe> tag). As the information gets lost when the top level page navigates somewhere the tracking potential is quite limited in such a scenario.
So in conclusion you can enable "Allow window.name in frames" to make reCAPTCHA work and still don't have to worry to much about tracking with window.name.
So in conclusion you can enable "Allow window.name in frames" to make reCAPTCHA work and still don't have to worry too much about tracking with window.name.

2
_locales/en/messages.json
View File

@ -1510,7 +1510,7 @@
"description": ""
},
"sanitation_error.disabledSomeFeatures": {
"message": "Some features of {api} are disabled. This should only be done in testing or if you really know what the features are doing.",
"message": "Some features of {api} are disabled. This should only be done for testing or if you really know what the features are doing.",
"description": ""
},
"sanitation_resolution.disableMainFlag": {