Why is the screenshot tool disabled in Abrowser?
Before I started using Trisquel I greatly enjoyed [the screenshot tool][1] in Firefox. It allowed me to easily get a picture of only a small area of the page without needing to crop it in GIMP, as well as allowing me to take a screenshot of entire pages without scrolling and manually stitching multiple screenshots together.
I notice that this feature is missing (disabled) in Abrowser. Specifically, it is disabled by setting a preference in [settings.js][2]. I am very curious as to why this is. I find the feature very useful, and don't see any downsides to keeping it enabled. To my knowledge it doesn't infringe on user freedoms.
Does anyone know why screenshots are disabled? This [other forum topic][3] asked the same, but never got any response.
In the meanwhile, I have manually enabled screenshots in the configuration.
[1]: https://support.mozilla.org/en-US/kb/take-screenshots-firefox
[2]: https://gitlab.trisquel.org/trisquel/package-helpers/-/blob/b39bb0765a29deaa4a6e2172fcdc8883e0079061/helpers/DATA/firefox/settings.js#L239
[3]: https://trisquel.info/en/forum/few-things-abrowser-should-be-fixed
Ignacio Agulló responded to this post via email, which unfortunately seems to have created a [separate forum topic][1]. I will respond to them here, in hopes that further discussion will occur in a single place.
> It is weird for Libre Software to enable this behaviour by default.
> My guess is that that default setting is inherited from Firefox.
I highly doubt this is the case, given that Firefox [promotes this feature on their website][2]. Digging further into the settings.js, I found that it was [disabled by Ruben Rodriguez in 2017][3].
Firefox [mentions data collection][4] on their page, so perhaps this was why it was removed? I can only speculate. I'm not sure if Ruben has the capacity to read all new posts in the forums, but I hope someone knowledgeable on the historical development of Trisquel can shed some light on this eventually.
> I don't really know the reason for this kind of restraint [...]. I can only guess. The legal concerns of taking screenshots could be:
>
> * Care for Privacy. When you access social networks with private content, you get access to photos that are not intended for public redistribution.
> * Care for Copyright. Media corporations have been for decades turning our electronic devices into media kiosks able to reproduce content but unable to keep a copy of it - streaming replaced video downloading, and surely they would be glad to prevent photo downloading too. If you access Instagram with Abrowser, you'll find that saving images is disabled.
>
> My bet is on the second one. [...]
I don't find either of these arguments compelling. Although I agree that corporations would like to prevent us from doing anything other than consuming media, they have not come as far as achieving a blanket block of screenshots. Desktop operating systems, especially Trisquel, are not locked down like mobile operating systems are. Blocking screenshots in Abrowser does nothing to prevent content sharing; the user can just take a screenshot using the OS!
A side note: Instagram tries to prevent saving image in all browsers, not just Abrowser/Firefox. They do this by placing an empty HTML element in front of the image, so that when you right click on where the image is the browser thinks you're clicking on an element that isn't an image. This is easily circumvented by inspecting the page source to see the code for the image element.
> I don't know it either, but I am familiar with this kind of restraint. The same happens with Privacy Browser for Android.
My only experience with something similar was in Firefox for Android. In private browsing tabs (and *only* those) screenshots were disabled. I assume the rationale was to avoid accidentally leaking what you were doing in private browsing, say if someone grabs your phone and takes a screenshot. Or if you simply take a screenshot and forget to delete it afterwards. Photo library syncing would also mean that these screenshots could leak to third parties even if your device isn't directly compromised.
But I don't think this rationale is why it's disabled in Trisquel, because Trisquel isn't billed as a privacy OS and Abrowser is its default browser (opposed to privacy-focused browsers such as Tor).
[1]: https://trisquel.info/en/forum/re-why-screenshot-tool-disabled-abrowser
[2]: https://support.mozilla.org/en-US/kb/take-screenshots-firefox
[3]: https://gitlab.trisquel.org/trisquel/package-helpers/-/commit/f759433dfc90187a9a295ae574415e49a0b1c116
[4]: https://support.mozilla.org/en-US/kb/take-screenshots-firefox#w_what-data-does-firefox-screenshots-collect
> But I don't think this rationale is why it's disabled in Trisquel, because Trisquel isn't billed as a privacy OS and Abrowser is its default browser (opposed to privacy-focused browsers such as Tor).
Telemetry, and other data gathering is disabled by default, as Trisquel doesn't manage nor sends it.
You are free to enable this and some other disabled features in about:config.
Telemetry, and other data gathering is disabled by default, as Trisquel doesn't manage nor sends it.
Does Firefox's screenshot feature send anything on the network?!
No, it just tells Mozilla when you sneeze. But you can opt out of the health report any time:
https://github.com/mozilla-services/screenshots/blob/master/docs/METRICS.md
Sneezing is a serious health concern. I hope Mozilla is sharing that sneezing information with the various global spy agencies, to keep us all safe from ourselves.
Sneezing has always been the enemy of privacy.
Thanks to your link I discovered Firefox's screenshot feature actually *used to* send screenshots on the network, clicking on the related button. It has not been the case since 2019. https://www.mozilla.org/en-US/firefox/67.0/releasenotes/#note-788001 (a release note for Firefox 67) points to the reason:
While some users made use of the save-to-server feature, downloading and copying shots to clipboard have become far more popular options for our users. We’ve decided to simplify the Screenshots service by focusing on these two options and sunsetting the Screenshots server in 2019.
https://blog.mozilla.org/futurereleases/2019/01/24/clarifying-the-future-of-firefox-screenshots/
That exemplifies a relevant use of telemetry: not spending resources on features almost nobody uses. On Abrowser, telemetry is disabled, as Ark74 has just remembered us, and we may have never see the screenshot feature activated. At the time quidam disabled it, it was justifiable (concern regarding sending private information by accident), but is it still now that the screenshot can only be locally saved or copied to clipboard?
Your statement contradicts Mozilla's own support page linked as reference [4] above, which is where I found the link that allegedly opened your eyes on that surprising data hoarding screenshot related telemetry. Telemetry which could not tell them how many users just never used that tool anyway, which exemplifies how useless it can get, at best.
I believe the reason for this apparent contradiction may be that you overestimated the scope of the 2019 change. Saving screenshots on the remote server is not an option any more, but I read nothing in those links or quotes which may let us infer that the data collection stopped altogether. Which exemplifies how misleading official statements can be for unsuspecting, distracted, naive or partisan users alike.
> Telemetry which could not tell them how many users just never used that tool anyway, which exemplifies how useless it can get, at best.
Sure it can. Mozilla get metrics about how many times the screenshot tool is used (since if you're not downloading, uploading, or copying then you're not saving the screenshot at all). They also know each time the browser is shut down. These both contain a client ID, which allows them to correlate "pings" (data submissions). Then they just need to add up all the client IDs which have never pinged for the screenshots tool. (I'm assuming shutdown contains the client ID, but even if it doesn't there are plenty of events which do.)
PS: Thanks for showing me that it's actually possible to link to things!
This assumes that the user has not opted out of telemetry, and perfectly illustrates the catch. :)
Is the rationale to disable screenshots (in 2017) that they send telemetry, or that they were able to be uploaded and this is considered "other data gathering"?
I read Firefox source code for the first time today, specifically code for screenshots, and [the file I looked at][1] uses Services.telemetry.recordEvent (defined [here][2]). I didn't trace this all the way to where data would be sent to Mozilla (got tired after an hour), but I assume that this is controlled by the "Abrowser Data Collection and Use" preference which cannot be enabled. In other words, telemetry gathered from screenshots wouldn't be sent anyways.
I am aware of my ability to enable this. But I believe that this change negatively affects Trisquel's usability, and I don't know the reason for it (yet). I only learned that I _could_ enable it from the other forum topic mentioned in the first post, which I discovered because I remembered using the feature previously in Firefox. The vast majority of users will be ignorant of this.
[1]: https://hg.mozilla.org/mozilla-central/file/f28defeeb4ece0ed49c44b31bc1f86482f6dc9a2/browser/components/screenshots/ScreenshotsUtils.sys.mjs
[2]: https://hg.mozilla.org/mozilla-central/file/11b3d438788a84aecc7e53efdda19bb0814e13be/toolkit/components/telemetry/core/Telemetry.cpp#l1603
A freshly installed Trisquel system does not make any connection attempt by default. This is why you need to explicitly give it permission to go and check for updates. This is also why telemetry cannot be enabled by default, and can only be opt-in.
The day Mozilla stops its opt-out screenshot telemetry policy, the situation will be different.
Abrowser telemetry is disabled by Trisquel. The entire browser would send telemetry data otherwise, not just the screenshot tool. Like I stated in the post you're replying to, I believe disabling telemetry (as is done in Trisquel) prevents screenshot telemetry from being sent.
That is my understanding too. If correct, enabling Abrowser's screenshot tool adds absolutely no message on the network.
Interesting points the ones on this thread, I believe that a bigger development team could have a more fine grained approach and try to be on top of every new change Mozilla will do to Thunderbird and Firefox sources.
Since we don't have such devel power in place yet is best to delegate this change to the user who can build awareness on the subject if interested, as it has happened here, and do what think is best, I mean the change has been there for more than 6 years now, that's 4 releases so far (8.0-11.0), so I don't think it's harming the common user at least that much for the time being.
I suppose we could bring this subject on the T12 development road and discuss it a bit more. I would love, for the magic of 2024, to see new faces that will help us keep anti-features in check.
Cheers!
> I don't think it's harming the common user at least that much for the time being.
Agreed. The common user certainly appreciates that Trisquel is keeping Mozilla's abusive opt-out telemetry practices in check, rather than day-dreaming that it stopped.
EDIT: if someone wants to help about the screenshot tool, they should feel free to update the Abrowser documentation page for further reference, with a link to the related Metrics page for full disclosure.
I am a member!
Isn't that something that can be done with GNU Icecat?
The slower release cycle of GNU Icecat (which is based to firefox-esr) compared to abrowser (which is based to firefox), gives more time to keep up with the changes and, maybe can take pressure from Trisquel developers.
Of course you, the devs, have the right to decide and that is totally acceptable. Personally I prefer GNU Icecat (for freedom reasons) but I can understand that there are valid concerns about upstream compatibility.
> I prefer GNU Icecat (for freedom reasons)
Could you tell us more about these reasons? I would have thought there was no difference between the two freedom-wise.
I am a member!
Sure.
These are the two that come on top of my mind:
Abrowser doesn't (by default) restricts non-free javascript where GNU Icecat does. For me this is a really close argument whith why Trisquel doesn't provide pip (which I agree).
GNU Icecat redirects users who try to access some non free services to free alternatives (like from Xitter to Nitter).
All these can be disabled of course by a user. But then it is the user's deliberate decision to use something that it is not free.
Good points.
I got used to visit the appropriate websites, and to use the appropriate plugins, so I tend to forget that Abrowser is not shipping with them by default.
I suppose we could bring this subject on the T12 development road and discuss it a bit more.
It indeed looks important to have quidam's opinion. He made the change in the first place. I guess that decision related to the now-nonexistent save-to-server feature, but that is only a guess. Toggling extensions.screenshots.disabled in about:config allows to test the screenshot tool (in the contextual menu, obtained right-clicking on a web page) and see that the screenshot can only be locally saved or copied to clipboard. If the screenshot tool is deemed useful, lucachi has already pointed out the commit to rollback: https://gitlab.trisquel.org/trisquel/package-helpers/-/commit/f759433dfc90187a9a295ae574415e49a0b1c116
> Thanks for showing me that it's actually possible to link to things!
You are welcome. You will probably not need it, but the secret cheat sheet is hidden here. We seem to have somewhat lost focus, probably because of telemetry, which shows just how evil it is.
I understand your point about telemetry being globally disabled in Abrowser currently, but the trade-off is about allowing it again "locally" for the comfort of some users who had admittedly (or presumably) quite forgotten about a tool and can easily enable it vs. taking the risk of it slipping back in future releases. This is only my take, though, I believe you should feel free to open a package-helpers issue with your suggestion so it can get properly reviewed.
I am a translator!
> the secret cheat sheet is hidden here
On all my computers, in abrowser, these links are nearly invisible.
When I know there should be a link on some text, by taking a look closer at the screen, I can see a very small difference in the font colour compared with the next word, but it is so small that, when looking at a complete paragraph, I tend to see that kind of small difference in several places where there is actually no link.
Sure, my eyes aren't very good but I have that problem only with Trisquel website. Is there an easy way to make links more visible on Trisquel's website, without affecting all websites?
I did not think about that.
We should probably use the full URL instead, so the syntax makes it clear that there is a link.
> Is there an easy way to make links more visible on Trisquel's website, without affecting all websites?
You should be able to override default colors in Settings > General > Language and Appearance > Color. You need to select the "Always" option for "Override the colors specified by the page with your selections above" in the "Manage color" dialogue box. Not sure how to apply it to specific websites only. It can be easily turned on and off, though.
You may want to try this:
https://addons.mozilla.org/en-US/firefox/addon/screenshot-capture-annotate
Prefer to screenshot web pages as images? No problem.
**Screen Capture**
- Capture a screenshot of the page you visit, full-page, selected area or visible part
EDIT: or maybe not: https://www.awesomescreenshot.com/privacy.