1488005 - Firefox/57.0.1+ mobile on Android exposes minor-point-release digits in Revision, Gecko & Version portions of UA string & sends modified request headers for .ico & .png icon requests

Status: NEW

(GeckoView :: General, defect, P4)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180807170231
Firefox for Android

Steps to reproduce:

Observe requests to my server from Android mobile Firefox users.


Actual results:

Firefox/57.0.1+ mobile on Android exposes the minor point-release digits in Revision, Gecko & Version (e.g. rv:57.0.1 Gecko/57.0.1 Firefox/57.0.1) & sends modified Accept, Accept-Encoding, & Accept-Language headers for .ico & .png icon requests.
This behaviour continues through Firefox/61.0.2


Expected results:

I would expect the Firefox/57.0.1 browser in the example above to send "rv:57.0 Gecko/57.0 Firefox/57.0" in the UA string.
My understanding and observation was that Firefox policy changed circa 2010 to remove the minor-point-release digits from the user-agent string and to obfuscate the Gecko date. Since that time, the Gecko date string for desktop versions has always been "Gecko/20100101".
The desktop versions of Firefox do not send the minor point-release digits.
This behaviour is not service-affecting, but is inconsistent between browser platforms and possibly inconsistent with whatever the motivation was to hide the minor point-release digits in the first place.  Since I do not know why it was decided to do this, I do not know if there are any important user-security implications.

Comment 1

[Ioana Chiorean]

Not sure abut the decision here. Maybe Snorp can help?

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

Mike, is this expected?

Comment 3

[Jan Henning [:JanH]]

Probably because the network requests made from the Android app cannot use Gecko's user agent string and we never thought of this problem when constructing the string again in Java (most places are using MOZ_APP_VERSION for that).

It also doesn't help that we're defining the string
- in AppConstants.java.in (and some things use that directly, while others go through GeckoApplication.getDefaultUAString())
- in the GeckoView build config
- and some places around the code base use neither of the above and construct the String themselves again

Comment 4

[Mike Taylor [:miketaylr]]

As for the patch-level stuff in the version, we decided back in https://bugzilla.mozilla.org/show_bug.cgi?id=572659#c90 to not expose that. So that's a bug worth fixing to be consistent.

Dunno about accept stuff.

Comment 5

[Ioana Chiorean]

Snorp, Susheel, Andreas?

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

This is a Fennec thing, so someone on Susheel's team would need to address. I don't think it's a critical problem, though.

Comment 7

[Andreas Bovens [:abovens]]

I agree with Snorp. Let's try to aim to fix it in one of the upcoming releases though. We don't want to expose too much info in the UA string, after all.

Comment 8

[[e-mail]]

I'll be happy if you do fix this.  One of the knock-on effects of this UA-string inconsistency is that server "stats" programs such as Awstats report the hidden-minor-rev-UA "page" requests as a separate user-agent from the exposed-minor-rev-UA image/included-object requests.
So for example, I see Firefox/61.0.2 fetching nothing but images, and Firefox/61.0 fetching fewer images than expected (because its page totals are merged with/augmented by those of the Firefox/61.0.2 page-only requests which do not expose the minor rev digit in the UA and so appear to also be Firefox/61.0).  To only a cursory glance, it appears that the Firefox/61.0.2 agent is an image-downloader, not a browser.
There are other potential side-effects, particularly for browscap fans and anyone who bases anything server-side on user agent strings (e.g. css-file selection, security profiling, etc.).
Thank you all!  As a server admin and long-time Firefox/Netscape Navigator/Mozilla user, I appreciate your efforts.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.