@jonas.smedegaard yes that does seem to be the case.

In T688#12739, @sean.obrien wrote:

it's worth questioning our assumptions in cases like this, and luckily I had just been in a discussion about this very thing with a PureOS user, looked up the policy, and can't find anything restricting us from doing that. I will contact Mozilla on Friday trademark-permissions@mozilla.com if there are no objections, but it's best to let this sit for a while.

it's worth questioning our assumptions in cases like this, and luckily I had just been in a discussion about this very thing with a PureOS user, looked up the policy, and can't find anything restricting us from doing that. I will contact Mozilla on Friday trademark-permissions@mozilla.com if there are no objections, but it's best to let this sit for a while.

copypasta from my comments in a Matrix room, but TL;DR let's just rebrand it back to Firefox, I'm pretty sure Mozilla will give us its blessing to do so.

thanks @sriram.ramkrishna! slight tweaks that make these more OS-agnostic and (hopefully) future-proof:

DuckDuckGo is using jQuery functions that check canvas size. Are they actually tracking users? I would prefer not to jump to conclusions here. This makes me skeptical: https://www.reddit.com/r/privacy/comments/ad4h0u/duckduckgo_now_fingerprinting_visitors/

why enabling the compatibility mode, as it seems like we do for PureBrowser by default, doesn't fix the problem is a mystery to me.

@jonas.smedegaard the recommendation was unofficial and I'd rather not push on it... could end up with policy that isn't in our interest. Waterfox uses the same style of UA string, and they have compatibility with the addons store.

For reference, this is the JS library that the Mozilla addons team uses to figure out the UA: https://github.com/faisalman/ua-parser-js/

@jonas.smedegaard clarification - I visited addons.mozilla.org in a new browser tab after making that UA change, and was able to install addons that would fail with the previous UA string. I assume the UA override in about:config does *not* fix the problem for the browser as a whole, which is why browsing through the "addons manager" still barks at you for not running a compatible browser.

I did some more testing, and for the sake of accuracy, this is a slightly better UA string:

We need to change the PureBrowser user agent string format to be compatible with the Firefox addons site. After discussions with Mozilla, this is the format of the string we need to send:

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

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?

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 ?

@Jeremiah thanks for weighing in.

@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.

My recommendation for this would be only privacy-respecting choices:

It seems to me that the issue here is the question of the licensing status of JavaScript loaded by DuckDuckGo.

What's the status on this? The issue of LibreJS is coming up again in general, and I will also be requesting some other addons are either default or opt-in (perhaps with a slide in the first-boot setup wizard for PureOS).

In T594#11055, @guido wrote:

@sean.obrien (this might become a bit off topic): the flatpak side needs more work for the 3rd party apps.

@guido got it, thanks! The further we can think down the road the better, so if I can be of any help let me know. I'm not yet sure what else might be necessary / desired by devs for mobile app development.

Anything we can do to make developing apps for the Librem phone smoother is really important. Does it make sense at this point to author a strategy / procedures for packages like this? Maybe a separate repo for unstable packages that we want to make available on PureOS as quickly as possible to encourage Librem phone development? I'm still getting my feet wet, so perhaps some of this is worked out already.

Sure let's discuss more (edit: in another medium). I intend to solve the root problem identified by @thegoat above:

A thought - If the issue is PureOS/Purism governance, then maybe we just take the TB downloader package from Debian contrib and start maintaining it in-house, making sure we have someone tracking changes in upstream TB very closely so we don't lag behind, and building a good relationship with Tor Project where we give them a heads up that we're doing this. We should also build a relationship with the Debian package managers for that downloader script... it's quite possible they're happy for us to be the maintainers for Debian contrib as well. But maybe not.

In T347#11041, @jonas.smedegaard wrote:

Is it in your opinion more important to fix immediately (i.e. no time to wait for PureOS, we must hand over the keys to the castle to upstream) bugs in Tor Browser, or do you find it equally important that we (as they become available) enable mechanisms for the Linux developers and GNOME developers and any other upstreams to address 0-days in their code?

Let me rephrase: The Tor Browser launcher/downloader *has* been packaged for Debian. I believe it has lagged behind in updates, even in my past experience, but I would want more concrete information on that.

I do not recommend that PureOS bypass Debian and pull directly from upstream - either as PureOS-specific development effort (a package) or by our users (a script like torbrowser-bundle). The amount of work is less but we loose the security tracking and wider use (more eyeballs) from Debian.

In T347#11031, @jonas.smedegaard wrote:

In my opinion, this issue should be solved by packaging Tor Browser for Debian main.

The problem here is very nicely explained, and I agree that a reference document with a high-level design pattern we can refer to is the best solution. Let me know if there's anything I can do to move this along.

Suggestion - can we figure out a workflow with subtasks and/or parent tasks? That way there's no need to look outside of this issue tracker for solutions, and we can sort/clean up current tasks here that may be in the kind of limbo you describe.

What do we need to do to move this forward? We really need to have Tor Browser available in some form. @jonas.smedegaard I know we've had some discussions about software outside of PureOS repo in general. What's your suggested solution for shipping TBB (or do you suggest not shipping it)?

In T596#11020, @jonas.smedegaard wrote:

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

In T596#11018, @jonas.smedegaard wrote:

A bit of some history...
Last fall, soon after I was hired to Purism and my interest in nitpicking and policy making became clear, I was tasked with tracking "Freedom issues" - i.e. make sure PureOS would comply with FSF FSDG.
Instead of simply "obey the gospel of FSF", I tried make sense of their rules and find the logic that make sense to me that PureOS follows - which happens to fit FSF rules but makes sense on its own as well.
The rule I have followed - which FSF does not dictate but in my interpretation fits their concretely written rules - is that PureOS must be responsible towards our users in what we offer them.
My guess is that FSF has peculiarly odd phrases like "Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow" is that they don't trust other organisations (e.g. Debian) to stay on the rght path, but they do want other organisations to trust them (e.g. use their list of Mozilla-compatible addons).

Thanks @jonas.smedegaard ! Potentially this is a bad forum for this discussion but I appreciate the title change.

I'll add really quickly - if Debian main is still considered problematic, I understand, but I don't think that precludes making some of the Electron-based clients for E2EE messaging available through their repos (though not marked by default).

You're quite right that the GNU FSDG is very clear on this issue:

Seems to me that the best course of action is to talk to DuckDuckGo and see what the opportunities are here. We could of course use DuckDuckGo's search without any discussion, but a custom arrangement might be better for both parties.

Understood, I'll think about this and see if it makes sense to comment on these other issues or open new, separate ones. However - T247 doesn't quite fit with the UA issue. The User Agent behavior is identifying PureBrowser in the way that has been decided in past discussions/issues, but Mozilla is detecting PureBrowser as not Firefox. Users who click Tools > Add-ons are given choices that don't work, and diverted down channels that go nowhere. See for example the attached screenshot of what my PureBrowser is currently recommending to me on the "Get Add-ons" screen.

In T596#10989, @jonas.smedegaard wrote:

Such change(s) would be encouraging those resources.
Since those resources are external to us, we cannot ensure our users that they fit our constraints e.g. regarding software freedoms - and even if they happen to currently align with out constraints we have no way of intervening if that change later on, after our users have installed our system onto their systems.
PureOS is the subset of Debian which is "Free" both by Debian definitions and by Free Software Foundation definitions. Encouraging inclusion of Debian resources would - in the eyes of FSF - be encouraging non-free stuff, and we would loose the endorsement from FSF as being a Free system by their standards.

I had this issue on the OEM version of PureOS 8 Beta 1, Librem 15 v3. I ended up doing a full reinstall of PureOS.