1006836 - Warn Users if User Agent is not Default

Status: RESOLVED INCOMPLETE

(Firefox Health Report Graveyard :: Web: Health Report, defect, P5)

Description

[Tyler Downer [He/Him]]

There have been several cases in the past where Add-ons have mass corrupted User Agents, leaving users with a UA that says they are on one version of Firefox and yet they are 20 versions later.

We should detect if a User Agent is non-default, and if it is, present the user a warning that provides an option to either reset their UA, or ignore (for those few users who change their UA on purpose). 

It would be great to have stats on the % of users who have a non-default UA as well.

This provides benefit to users as websites will often not serve modern content if the UA is not a modern version.

Comment 1

[Benjamin Smedberg]

I believe the UI already has all the information necessary to do this and it seems like a simple win. espressive would you be willing to mentor somebody for this?

Comment 2

[Schalk Neethling [:espressive]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> I believe the UI already has all the information necessary to do this and it
> seems like a simple win. espressive would you be willing to mentor somebody
> for this?

I would be more than happy.

Comment 3

[Benjamin Smedberg]

Can you provide a link in the fhr-jelly repo where adding this warning would make the most sense? Are the in-tree docs at https://github.com/mozilla/fhr-jelly the best instructions for hacking this?

Comment 4

[Schalk Neethling [:espressive]]

So we would basically want to ensure that the version reported by navigator.userAgent (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0) matches the version number we have in the JSON payload of FHR (i.e "geckoAppInfo.version": "29.0") correct?

Comment 5

[Tyler Downer [He/Him]]

As an example, here is a bad UA. This user is actually using Firefox 29, but his UA says: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 FBSMTWB

Comment 6

[Schalk Neethling [:espressive]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> Can you provide a link in the fhr-jelly repo where adding this warning would
> make the most sense? Are the in-tree docs at
> https://github.com/mozilla/fhr-jelly the best instructions for hacking this?

I would suggest over here:
https://github.com/mozilla/fhr-jelly/blob/master/js/fhr.js#L151

This is where other notifications are already been shown, and the payload is passed to the function.

In terms of the making the project easier to approach, and thus contribute to, I will definitely put this on my to-do list as it is something I wanted to have done a long time ago.

Comment 7

[Schalk Neethling [:espressive]]

(In reply to Tyler Downer [:Tyler] from comment #5)
> As an example, here is a bad UA. This user is actually using Firefox 29, but
> his UA says: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
> Gecko/20120306 Firefox/3.6.28 FBSMTWB

Exactly, so if we get the version from the userAgent string (perhaps grabbing the version string between rv: and ) is safe :bsmedberg ?) and compare that with what is in payload.geckoAppInfo.version we should have a match.

If we do not, then something is a miss and we need to notify the user and provide the options for fixing it, as outlined in comment 1

Comment 8

[Benjamin Smedberg]

I expect that we want to programmatically compare the actual user agent to the default one we'd expect: maybe we should re-create the user agent from http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp#584 or just have a pattern (regex?) to check it.

Tyler, the client currently doesn't have an API to reset the user agent. Do you have a SUMO article we should be linking to from this warning?

Comment 9

[Tyler Downer [He/Him]]

We can point users to https://support.mozilla.org/kb/websites-say-firefox-outdated-or-incompatible Or write an article with that content but that applies to the message users will see.

Verdi, Do you want to write an article much like the above, but that applies to a FHR message warning users they have a non-default UA, rather than a website telling then this? Thanks!

Comment 10

[Schalk Neethling [:espressive]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> I expect that we want to programmatically compare the actual user agent to
> the default one we'd expect: maybe we should re-create the user agent from
> http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/
> nsHttpHandler.cpp#584 or just have a pattern (regex?) to check it.
> 
> Tyler, the client currently doesn't have an API to reset the user agent. Do
> you have a SUMO article we should be linking to from this warning?

So, you are saying we do not want to just use a regex to extract the version number from navigator.userAgent and compare that against geckoAppInfo.version, we want to actually compare the entire userAgent string?

Comment 11

[Benjamin Smedberg]

As I read the initial description, we didn't just want to check the version number, but the other elements of the UA (are we pretending to be Chrome or IE)?

Comment 12

[Schalk Neethling [:espressive]]

Aha, yes! So then we definitely need to check all the things.

Comment 13

[Verdi [:verdi] Best to slack me]

(In reply to Tyler Downer [:Tyler] from comment #9)
> We can point users to
> https://support.mozilla.org/kb/websites-say-firefox-outdated-or-incompatible
> Or write an article with that content but that applies to the message users
> will see.
> 
> Verdi, Do you want to write an article much like the above, but that applies
> to a FHR message warning users they have a non-default UA, rather than a
> website telling then this? Thanks!

CC'ing Joni. She should handle this.

Comment 14

[Verdi [:verdi] Best to slack me]

(In reply to Verdi [:verdi] from comment #13)
> > Verdi, Do you want to write an article much like the above, but that applies
> > to a FHR message warning users they have a non-default UA, rather than a
> > website telling then this? Thanks!
> 
> CC'ing Joni. She should handle this.

Joni - this article was written as the target of a FHR tip (so may be a good template) https://support.mozilla.org/en-US/kb/firefox-health-report-says-your-browser-is-slow - it was supposed to be in the "Navigation" category so it was only visible from FHR link but it's been moved. We should put it back.

Comment 15

[Robert Kaiser]

Well, me, I'd just warn the user if navigator.useragent.override is set at all (i.e. to any non-empty value) and offer a resetting it.

This is the mechanism that usually does set it to something "wrong" (I'm not sure if we offer any other mechanism still) and it's easier to check it an override is in place than to parse the actual value being sent out. ;-)

Comment 16

[Schalk Neethling [:espressive]]

(In reply to Robert Kaiser (:[e-mail]) from comment #15)
> Well, me, I'd just warn the user if navigator.useragent.override is set at
> all (i.e. to any non-empty value) and offer a resetting it.
> 
> This is the mechanism that usually does set it to something "wrong" (I'm not
> sure if we offer any other mechanism still) and it's easier to check it an
> override is in place than to parse the actual value being sent out. ;-)

Ooooh, that is a good one, thanks Kairo! :bsmedberg thoughts?

Comment 17

[Schalk Neethling [:espressive]]

(In reply to Robert Kaiser (:[e-mail]) from comment #15)
> Well, me, I'd just warn the user if navigator.useragent.override is set at
> all (i.e. to any non-empty value) and offer a resetting it.
> 
> This is the mechanism that usually does set it to something "wrong" (I'm not
> sure if we offer any other mechanism still) and it's easier to check it an
> override is in place than to parse the actual value being sent out. ;-)

Actually, looking at it again, that does not seem to be exposed to JS. I also do not see this in about:config

Perhaps that no longer exists?

Comment 18

[Masatoshi Kimura [:emk]]

How about just resetting the navigator.useragent.override pref for every startup? User Agent Switcher is already doing that to avoid a Java plug-in issue. (It will no longer be a FHR component, of course.)

Comment 19

[Benjamin Smedberg]

The goal is not to force users to reset their user agent. The goal is merely to warn them that they have a non-default UA.

Doing anything with checking or resetting  the override pref requires building the support API, which is not on my shortlist. So if we can just do the simple thing now, we can come back to the bigger thing later.

Comment 20

[Joni Chan]

Thanks, Verdi. I've moved the FHR article back to Admin.

Tyler and Benjamin, I'm still working on the article, but here's the slug: https://support.mozilla.org/kb/how-reset-default-user-agent-firefox. So from what I can tell, users won't be able to reset the UA directly in the warning message, so this SUMO article should include instructions on how to reset it. Is there other info we need to include?

Comment 21

[Robert Kaiser]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #19)
> The goal is not to force users to reset their user agent. The goal is merely
> to warn them that they have a non-default UA.

I'm against warning them when we do not offer an easy solution for actually correcting the error.

Comment 22

[Robert Kaiser]

(In reply to Schalk Neethling [:espressive] from comment #17)
> Actually, looking at it again, that does not seem to be exposed to JS. I
> also do not see this in about:config

It's only exposed to chrome, not content. That said, in about:config it only shows up when it's set, by default it doesn't exist (but in those cases where it is set, those are the ones we should warn about - and offer resetting).

Comment 23

[Nils M.]

Is this bug still relevant? Is there already final decision on the approach? Just pointing the user to website or offering the possibility to reset the UA?

Comment 24

[Georg Fritzsche [:gfritzsche]]

I think given the current pending state of Shield/SelfSupport plans, this is not actionable right now.
We should really have a consistent plan there.

Comment 25

[Firefox Bug Husbandry Bot]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1497137; component deprecated.