- User Since
- Oct 9 2018, 11:25 (66 w, 4 d)
Nov 28 2019
Feb 13 2019
@jonas.smedegaard yes that does seem to be the case.
Jan 29 2019
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 email@example.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.
Jan 26 2019
thanks @sriram.ramkrishna! slight tweaks that make these more OS-agnostic and (hopefully) future-proof:
Jan 6 2019
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/
Dec 20 2018
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.
Dec 19 2018
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.
Dec 18 2018
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:
Dec 9 2018
When I first suggested this in the other issue, these addons were just suggestions, not a "must have" list.
Dec 6 2018
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 ?
Dec 5 2018
@jeremiah thanks for weighing in.
@jeremiah.foster adding you for your perspective on this.
Dec 2 2018
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.
Nov 19 2018
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.