PureBrowser incompatible with user-agent sniffing at Firefox add-on store
Open, NormalPublic

Description

When trying to install add-ons for Purebrowser, there is a message that these add-ons are available "Only with Firefox — Get Firefox Now!"

Users should be able to quickly add extensions of their choosing.

Affects e.g. extensions tracked at T644.

Related to T247: Enabling compatibility mode confirmed as workaround.
Should perhaps be fixed on the Mozilla end since PureBrowser identifies as Mozilla / Gecko / Firefox before it identifies as PureBrowser.

Related to T299: Please discuss solutions involving change of addons provider at that other issue.

This covers several issues, making it difficult to track.

The issue framed by the subject seems a duplicate of T202. Please clarify - e.g. by quoting the error message you experience.

The issue of "users should be able to quickly add other extensions of their choosing" is likely a wontfix because it conflicts with T299. Better file as a separate issue if you still find that relevant to track.

The issue of "make it easier to live in a world that's dominated by other platforms" is arguably a non-issue in itself: PureOS approach for that is to package relevant software in Debian and then include it in PureOS. Better file as a separate issue if you still find that relevant to track.

Please file as separate issues each addon you consider relevant to get packaged to and available as part of PureOS.

The issue of whether choice of user-agent string affects access to addons.mozilla.org is related to but not same as T247: Better file as a separate issue if you still find that relevant to track.

Creating a PureOS-controlled addons service is tracked at T210, and the reasons it is needed is tracked at T305. Better discuss practical/technical concerns at the former and political conerns (or lack thereof) at the latter of those issues.

Did I miss something? Do you find it relevant to continue this issue - e.g. to discuss overaching concerns getting lost in the details, or can we close this one and continue the other referenced places instead?

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.

I agree none of what you presented here _is_ T247 - only _related_ to it.

But please create new issues instead of adding more details here: This issue tracker makes it easy to merge issues but hard to split convoluted issues.

Oh, and please also (in those newly created issues, not here) add URL when you share screenshots of stuff that has a web page (yes I know above was not itself a web page but it links to one, that took me some time to locate from that screenshot alone).

Thanks a lot! All of these issues are quite relevant to track!

To clarify: You do _not_ need to search through and locate previous issues. Nice if you do, but perfectly fine if you don't have time for that. File new issues and leave it to us to correlate and maybe merge with existing ones. :-)

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

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.

If you'd like me to re-file the bugs Sean I'm happy to do that, it will make things easier for me to understand regarding our policy around plugins.

@jeremiah thanks for weighing in.

There are really two issues here, which I know was my bad for conflating when I started this issue.

  1. PureBrowser and policy around addons in general, licensing etc.
  2. PureBrowser and why Mozilla's addons store identifies it as "not firefox" and creates a huge headache for users who try to install Firefox addons.

I'm most interested in solving the second issue, esp. since we'll be moving to Gnome Web... in the meantime, PureBrowser will be actively replaced by users, who know how to do so, with Firefox proper. The users who don't know how will be confused and disappointed.

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?

For number #2 I feel we still need to unpack some things. The user agent string identifies PureBrowser as Firefox and PureBrowser at least on my machine. So I don't know how PureBrowser can affect the behavior of the Mozilla store -- do we know what is causing PureBrowser not to be recognized?

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.

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 ?

I think the best thing to do is open a conversation with Mozilla... we identify as Mozilla / Gecko / Firefox before PureBrowser in the UA string; that should be enough for them to allow users to install addons from them.

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

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

apologies for the confusing terms I used. The menu items do go *somewhere* (mozilla addons site) but that somewhere is a dead-end for our users because they can't install addons.

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

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

I disagree this issue should be closed now. Maybe (at most) makes sense to lower its severity.

The issue tracked here is that PureBrowser gets detected as incompatible with Mozilla's plugin "store".
Enabling compatibility mode is merely a workaround for that, not a proper solution, and it makes sense to me that we keep this issue open for as long as this issue is a potential nuissance for our users, so that it can easily be located by anyone wanting to provide more information about it.

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.

For reference, that related but different issue is now tracked as T644.

jonas.smedegaard triaged this task as "Normal" priority.Dec 9 2018, 2:24 PM

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.

sean.obrien added a comment.EditedDec 19 2018, 4:10 AM

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:

Mozilla/5.0 (X11; Linux x86_64; rv:60.0; PureBrowser) Gecko/20100101 Firefox/60.1.0

That replaces the format:

Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 PureBrowser/60.1.0

I've tested, and it works.

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

Mozilla/5.0 (X11; Linux x86_64; rv:60.0; PureBrowser/60.1.0) Gecko/20100101 Firefox/60.0.0

We need to put the closest Firefox version after rv: and also Firefox/ and just include the PureBrowser version where it is in the above example.

@sean.obrien Can you please elaborate what more exactly you tested when you wrote "I've tested, and it works".

Screenshot indicates that the change you made was to add a "general.useragent.override" entry in about:config - but previously you post a screenshot of the browser-internal "Add-ons Manager" showing warnings about incompatible add-ons.

When I now - using PureBrowser 60.3.0esr-1pureos1, but nevertheless setting the UA string to _exactly_ same as your latest post above (i.e. claiming to be PureBrowser/60.1.0) and visit "Add-ons Manager" internal page then I still get those warnings - but they seem bogus, in that I successfully changed theme by clicking on a theme.

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

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/

Is there a workaround until an update is sent out?

A known workaround is to configure PureBrowser to impersonate Firefox: https://tracker.pureos.net/w/troubleshooting/firefox_compat_mode/

Confusingly that page talks about "compatibility mode" which is *not* what it is about: Compatibility mode is already enabled.

Confusingly that page talks about "compatibility mode" which is *not* what it is about: Compatibility mode is already enabled.

It was created at the time when this was not the case.

@mladen.pejakovic My point is that "Compatibility mode" is something specific in the context of Firefox.

My remark about it being already applied relates to how it is confusing that the workaround changes a browser in compatibility mode to be... in compatibility mode, unrelated to when that clash of different meanings for same expression became confusing.

The documented workaround could more accurately be described as impersonation.

@sean.obrien Is the conversation with Mozilla, leading to their suggesting that particular string, public? If so, please provide URL.

In an attempt at avoiding/limiting confusion, I have now updated T247 and labeled the various styles of user-agent string. I have baptised the newly introduced one as "subtle" (suggestions for better wording welcome!).

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

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.

the recommendation was unofficial and I'd rather not push on it...

Reason I asked was for the chance of reading along and learn more details (didn't expect it to be official).

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.

I am not surprised: That site clearly does UA sniffing - and apparently has tweaked that in recent times (when you filed this T595 the previous T202 was closed as fixed).

jonas.smedegaard changed the title from "PureBrowser detected as incompatible with Firefox add-on store" to "PureBrowser incompatible with user-agent sniffing at Firefox add-on store".Aug 24 2019, 8:40 AM

Add Comment