As of this comment, we are at 84.5%. However:

When I first suggested this in the other issue, these addons were just suggestions, not a "must have" list.

I think you're right Jonas. I'll set up a tracker per add-on.

@heather.ellsworth I took the liberty of retitling "your" issue here to describe the issue to be addressed.

Fixed upstream in Debian (see T599).

In T202#11747, @jeremiah.foster wrote:

I wonder if we want to have an acceptance criteria for this issue since while it is "closed" it is not "solved" perhaps.

This is T202 - merging into this newer one (instead of opposite) because this one had more details - except for the exact "error message" of the wording of the button when (mis)detected as not being _exactly_ Firefox.

I can suggest to create an issue for each addon, both to track their relationsips (e.g. if an addon like TOS;DR relates to _both_ privacy and freedom), and to track their resolution (i.e. packaging in Debian).

I suspect (but haven't looked closed) that some of the listed addons more appropriately belong in a new separate issue "PureOS is not freedom-governing enough by default".

I took the liberty of changing the title to describe the issue to be addressed here.

In T595#11754, @jeremiah.foster wrote:

Thank you @mladen.pejakovic. From what I can see, this essentially solves the issue no? I think we should close this issue.

Ah, thanks for the clarification. Makes sense to me now :-)

In T595#11789, @jonas.smedegaard wrote:

@sean.obrien you mention "menu items that go nowhere".
Which issue is that? Or can you please file as a (separate!) issue if not already tracked?

which menu are you talking about? Something inside the PureBrowser window, something part of the window containing PureBrowser, or something in some menu elsewhere (e.g. provided by your desktop environment)?

@sean.obrien you mention "menu items that go nowhere".

Thanks @Wayne, I'm sorry to hear you've given up on PureBrowser, still a vote for the add-ons you'd like to see might be the way to prioritize which add-ons are most important to users.

I think Privacy Badger is already there. (apt list webext-*)

thx @jeremiah.foster for opening this.

Thanks @mladen.pejakovic that does, sort of, solve the issue. However @jeremiah.foster , we're shipping a browser with menu items that go nowhere when users try to ad addons... how could they possibly know to go into the browser registry about:config ?

Thank you @mladen.pejakovic. From what I can see, this essentially solves the issue no? I think we should close this issue. If we need discussion Sean on the list of add-ons you specified (DuckDuckGo Privacy Essentials, Decentraleyes, Privacy Badger, Privacy Possum, Exodify, TOS;DR, Polisis), let's use a separate bug to track that issue.

The helper script has now been split out into a new dbus-activated daemon. It's not the quality thing that I want yet, as the code needs some refactoring to work properly in an async way and the interface is quite crude, but it's good enough for a start.
See https://source.puri.sm/pureos/core/pureos-init-disk-crypto

For #2 see the note here: https://tracker.pureos.net/w/troubleshooting/firefox_compat_mode/

Shouldn't #1 be in the form of a wiki page or other policy document? Then we can take whatever concrete issues or features that need to be worked on by engineering in atomic, bite-size peices?

So this issue still exists for me, namely I'm unable to install extensions. Here is the user agent that PureBrowser left in my logs;

Followed up in: https://bugs.debian.org/906609#90

Sure thing. Guilhem's Librem Key has arrived and is playing with it. :)

@Jeremiah thanks for weighing in.

I have two perspectives, one on the content and one on work flow. As far as content is concerned I think it is addressed by folks who know the issues better than I, so I'm not going to wade in on that. As far as work flow is concerned I defer to Jonas who has to use the tool to be efficient, so he gets to decide how the work is broken down.

It probably makes sense to keep this open until the package shows up in PureOS (having it in Debian is nice, but not sufficient). Once it makes its way into PureOS then sure, close the ticket.

@jeremiah.foster adding you for your perspective on this.

thanks @mladen.pejakovic that is helpful. I made some slight wording changes to the warning so we don't scare away users. I'll be working with Jeremiah on this to see if we can come up with a smoother solution, but this wiki entry is much needed in the meantime.

Wiki entry for TorBrowser: https://tracker.pureos.net/w/pureos/tips/torbrowser/

This just got fixed with yesterday's updates. Excellent!

Indeed - package has already entered landing so should migrate to green in few days: http://software.pureos.net/search_pkg?term=pyotherside

Looks like the package has got new maintainer and is progressing in Debian. I presume it will then end up at PureOS as well.

This was actually pushed back too many times, and I should address this sooner - especially since there is other pending work on this module.

That doesn't help, the journal also contains the changes.
The good thing is that you'll only ever be able to read the password if you have root access on a drive that has already been unlocked using that password.

In the mean time could you add a task that erases/truncates /var/log/auth.log after that script runs?

I am aware of this for a long time, it can only properly be fixed by making a proper service out of this tool, which I have not had the time to do yet due to piles upon piles of other critical tasks.
I might actually implement the service soon though, in the process of fixing swap-related boot issues.