Aren’t those extra installed via the webext-* packages or is it different in crimson?
1 Like
They consist of two folders within the /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ directory:
You need root permissions to remove them. My suggestion is to relocate them to the Profile Directory in the extensions folder instead so that root permissions are not required and that they can be uninstalled normally like any other extension.
1 Like
And that’s owned by the firefox-esr package or other packages?
1 Like
I do not know. What I do know is that I manually removed the two folders containing the globally installed extensions using the sudo rm -r command.
I don’t even want to use it “disabled”, I just don’t want to have uBlock on my system. That’s bloodware (3rd party apps that are preinstalled and even further that are hard to remove). A practice I usually just know from Microsoft Windows and similar.
2 Likes
Just to be pedantic, “bloodware” may refer to software made using torture, human sacrifice, killing of innocents or sucking someones neck to regain life energy (I assume to code through the night) 
“Bloatware” was coined to refer to software that was mostly unusable, unnecessary and unwanted - and sometimes unremovable. These can be thought of as the latter, but as these are more useable than what the MS, Android, Apple et al. add/ed, and because those do provide security and privacy features (which you apparently do not want), the term (either one) seems a bit of an exaggeration - though I agree, user should have easier option to de-select them 
But all kidding aside, more importantly, I am left to wonder, if you might be doing yourself a disservice by removing them, as that may differentiate you from other users and make your online fingerprint more specific (something that Tor-browser model is trying to avoid)…? It may not matter for your use-case, of course. See also: https://coveryourtracks.eff.org/
2 Likes
if it is as I suspect, installed from a package then:
- uninstalling the package(s) should solve this
- prevent the re-installation of the extensions if the package gets updated
dpkg -S /path/to/file/or/dir
should indicate which dpkg owns the files or dirs, and help figuring this out…
1 Like
That missing my point of view. It’s already an issue that we need such methods.
1 Like
My point is about discovery: is it REALLY a package installed by default or is it included in some other way? Trying to find some actual facts before making any other judgement call.
Further more my opinion does differ from yours if it is indeed just a simple package that’s installed by default: uninstall it, and it’s done. You as the owner of a device running PureOS (or Debian etc) have this power and ability.
2 Likes
And than more and more things are Preinstalled “that I just can uninstall”, but where I take 2 days work at some point. I also still don’t know how to remove keyring and GNOME web. I don’t want to search for every single thing what’s the specific uninstall behavior. It’s already an issue that apps got renamed and I have to search for the package name before I can apt remove.
1 Like
Oh well. Some day someone will dare run the command or answer if the extensions are indeed installed by some extra packages and then maybe we can make some progress on this (I don’t have pureOS or a computer capable of running Crimson at the moment, L5 could I suppose I’m not sure if it’s setup the same way).
1 Like
Doesn’t PureOS on the Librem 5 use a policies.json file to pre-configure the browser profiles and install the specified extensions on startup?
Personally, I use scripts to periodically delete everything in ~/.mozilla/firefox/ and recreate my profiles with my own custom configurations, including a user.js file and the extensions of my choice. I think my configurations override the policies.json file set by PureOS, and I’ve never noticed any issues.
Also, I’ve noticed that Privacy Badger has been recommended against for several years now in various privacy communities, since the heuristics feature can be used for tracking (ironic) and the blocking feature is better handled by uBlock Origin. Why install both? Redundancy in this case seems counter-productive.
1 Like
If I’m not mistaken, I think I’ve sometimes noticed trackers being caught by Privacy Badger that I didn’t see (or didn’t know how to see) in the uBO panel.
In my case, I want as much redundancy as possible: strict browser settings + NoScript + uBO + Privacy Badger + VPN w/DNS filtering and Network Lock (and/or Pi-hole). 
4 Likes
Here is the output:
dpkg -S /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
webext-ublock-origin-firefox, webext-privacy-badger, firefox-esr: /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
This is after I already deleted the folders within the directory.
both webext-ublock-origin-firefox and webext-privacy-badger are installed because of pureos-webext package.
2 Likes
Thank you for the hints, I successfully removed pureos-webext, fonts-open-sans, webext-privacy-badger and webext-ublock-origin-firefox. Here is the new output:
dpkg -S /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
firefox-esr: /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2 Likes
Great! So at least there’s a clear source to these extensions which is the packages, as is it is Byzantium and other Oses. and they can be removed. Thanks @FranklyFlawless foe checking it out and @Moon3 for the additional info.
And moreover there’s now a clear target if someone thinks those shouldn’t be installed by default, to send feedback to Purism.
1 Like
With the Purism philosophy of “the power of defaults”, it may be a difficult sell that these extensions should not be installed by default, particularly as it is now straightforward for the owner of the device to uninstall the packages.
There is however always going to be a diversity of opinions about the dividing line between “defaults” and “bloat”.
This is not the recommended approach. However if you frequently blow away your entire disk contents and reflash then it won’t really matter.
2 Likes
Agreed, however I was trying to bring the discussion beyond calls that that “purism should do something about it”, to at least understanding what is happening and empowering the user to handle their situation (though they appear overwhelmed at all that needs to be learned at this point in time… Have to take it step by step, @Ick 
)
Agreed, uninstalling the packages is the better approach in this case.
1 Like
Right, but I am more concerned about the message that Purism is sending to new PureOS users if this issue remains unaddressed.
3 Likes