gildas-lormeau
Release addon as bookmarklet
Is your feature request related to a problem? Please describe.
As far as I've experienced, SingleFile does a very good job at saving webpages locally.
The main issue is that SingleFile has access to all the pages I'm looking at, even when I'm not using it.
Describe the solution you'd like
As an end user, without looking at the source code of SingleFile, I would like to be sure that SingleFile cannot access any content unless I've executed it. And if I execute it, that it can only access the current of the page/tab I'm looking at.
I believe that the following could be a possible solution: create a bookmarklet containing the current functionality of SingleFile.
Bookmarklets are inactive unless the user executes them, and if executed, it has access only on the current page. Both restrictions are enforced by the browser, thus I do not need to trust the current implementation of SingleFile.
Describe alternatives you've considered (optional)
Keep the add-on disabled, enable it the moment I need it, and then disable it again. But it is easy to forget to disable the add-on again.
An alternative solution is to use a different Firefox profile, but it is impractical, especially if the webpage is ephemeral, and one might not be able to open it again in the second profile.
Additional context (optional)
Since bookmarklets cannot be configured/are stateless, a dialog should be shown when the bookmarklet is started, asking if the current configuration is fine for the current operation.
On paper, it should be possible to run SingleFile in a bookmarklet. The problem is that the quality of the result will vary greatly. These days, it's very common for resources (stylesheets, images, fonts, etc.) to be blocked for bookmarklets, due to the “Same Origin Policy” (SOP). As a result, the resulting page is likely to be severely degraded. In order to bypass the SOP, SingleFile can only work in the context of web extensions or from the command line interface, by injecting scripts into the browser.
At least on Firefox (but I believe other browsers too), bookmarklets bypasses CSP policies (https://bugzilla.mozilla.org/show_bug.cgi?id=1478037), so I'm not sure how big this issue is.
Otherwise a server that sets a website with csp that javascript is not allowed would not be able to execute any bookmarklet, even something simple like
javascript:(function(){location.href='https://jigsaw.w3.org/css-validator/validator?uri='+location.href;})();
In case I misunderstood you, do you have a minimal example I could test?
Thank you, I'll have to take a closer look, but I'd be very surprised to learn that the SOP isn't applied in the bookmarklet context.
I did a test and I confirm the Same Origin Policy cannot be bypassed when running a bookmarklet. This is the test I did:
- Create a bookmark with
javascript:fetch("https://www.example.com").then(r => r.text())as URL - Go to any site except https://www.example.com
- Execute the bookmarklet
- An error is displayed in the console
Thank you for the feedback.
Seems that not all csp policies are ignored.
Does SingleFile need to download files that the website itself does not download? If it does (would like to know why, I did not expect it), then it is surely an issue.
I also find it strange that an extension has more "power" than the developer console, as
fetch("https://www.example.com");
fails (for example), on the github website.
A bookmarklet would also be very interesting because company-managed web browsers usually do not allow the installation of add-ons.
But I‘m not surprised that security measures preclude the viability of a bookmarklet. Still, even limited functionality would be an advantage in an enterprise context.
