- User Since
- Oct 9 2018, 6:25 PM (8 w, 5 d)
When I first suggested this in the other issue, these addons were just suggestions, not a "must have" list.
Fri, Dec 7
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 ?
Wed, Dec 5
@jeremiah thanks for weighing in.
@jeremiah.foster adding you for your perspective on this.
Sun, Dec 2
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.
Mon, Nov 19
My recommendation for this would be only privacy-respecting choices:
Oct 31 2018
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).
Oct 13 2018
@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.
Oct 12 2018
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.
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.
Oct 11 2018
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)?
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.
Oct 10 2018
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.