search

gildas-lormeau / SingleFile

Web Extension for saving a faithful copy of a complete web page in a single HTML file
GNU Affero General Public License v3.0
15.18k stars 995 forks source link

Firefox: prevent CSP error and fingerprinting when not using SingleFile #1030

Open 123quhiwiwk opened 2 years ago

123quhiwiwk commented 2 years ago

Is your feature request related to a problem? Please describe. If you installed SingleFile in Firefox (or Chrome) and visit sites with Content-Security-Policy which disallows the execution of inline scripts, the injected script from SingleFile causes CSP error reports, even when you don't use SingleFile.

Moreover because of the injection of script, a site could determine if a user has SingleFile installed and use this information for tracking/fingerprinting. A really simple check (working in Firefox), if SingleFile is installed: 

<html><script>try{ globalThis.FontFace("a",null); alert("SingleFile is installed") } catch { alert("no singlefile") } </script></html>

As you can see with https://inappbrowser.com/ there are other possibilities to detect if SingleFile is installed

Describe the solution you'd like At least, when you don't use SingleFile, there should be no injection of scripts, which prevents CSP errors and prevents fingerprinting. Is it possible that the injection of the inline script happens only when you use SingleFile? According to #885, the site would need a reload. In Chrome, you could use the "on click" permission. But in Firefox there is no such permission. So can you maybe add an option for Firefox?

Describe alternatives you've considered (optional) My current workflow is to disable SingleFile completely and activate it when I need it. But this needs multiple steps and is annoying, so a option would be perfect.

gildas-lormeau commented 2 years ago

This script must be injected as soon as possible. That's why it is always injected and it can't be disabled through an option. However, the Manifest V3 will solve this issue by breaking this feature (inline scripts can't run before the page) so maybe I'll add an option to disable this feature.

123quhiwiwk commented 2 years ago

My idea would be to implement an optional option so that SingleFile does not inject scripts by default. As soon as you want to use SingleFile and click it, you get a message to reload the website. Only then SingleFile injects the scripts and saves the page.

Okay, the manifest V3 sounds like the "on click" permission in Chrome (If I understand it correctly). If it then really introduced as announced, the issue has then solved.

gildas-lormeau commented 2 years ago

You suggestion might be possible from a technical point of view by using this API https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contentScripts. Unfortunately, it's only available in Firefox with the Manifest V2. It also requires some refactoring.

Today, I am not able to inject synchronously this script with the Manifest V3 in Chrome (cf. last feature here: https://github.com/gildas-lormeau/SingleFile-Lite). So, reading options asynchronously (to check if the script should be injected or not) won't be anymore a problem. That's why I was saying the Manifest V3 solves this problem.

123quhiwiwk commented 2 years ago

If Manifest V3 is coming by the end of the year anyway, then that's okay. Then I still stay with my workflow until then :)

MasterKia commented 1 year ago

@gildas-lormeau Please see: https://github.com/uBlockOrigin/uBlock-issues/issues/235#issuecomment-1344313926

garretwilson commented 11 months ago

I was overjoyed to find this extension, until I read https://news.ycombinator.com/item?id=30527999 and realized that if I install this extension on Firefox, it will inject a script into every page I load even if I don't intend to save the web page.

The author is to be commended for all the work they have put into this, and for the doubtless many technical issues they overcame with ingenuity.

Nevertheless this is a hidden security risk and privacy intrusion. It is 100% a dealbreaker for me, and likely many other users who would stop using the extension—if only they knew about this issue (which they don't because it isn't publicized; see #885).

If it is not technically possible for the plugin to refrain from injecting a script into the page until the user explicitly requesting saving, then forcing the page to be reloaded when the user requests saving, as was suggested, is a reasonable workaround.

I won't be touching this extension as long as it unconditionally mucks with every page I view.