400089 - [UA] Include major OS revision for Mac OS X.

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Colin Barrett [:cbarrett]]

It would be nice to include the major OS revision (10.4 vs. 10.5) in our UA. Marking as pp because the Windows UA includes this information, i.e. "Windows NT 6.0;" for Vista.

See bug 71568 (historical interest, some discussion might still be relevant)

Comment 1

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Had most of this code for a different bug anyway, I leave you guys to decide whether it's actually a good change to make to the UA or not.

Comment 2

[Dave Townsend [:mossop]]

Oh I should add this code will only work on OSX 10.4 and later, but apparently that's all we support. There is a marginally different way to do it that works on earlier systems but its a little more clunky.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I'm not the right reviewer for this code.  Someone familiar with the API in question should review....

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sam and I thought this was a dupe of another bug, maybe something mento worked on (I think it was WONTFIXed), but neither of us can find it.

Given the propensity of sites to sniff based on just about every part of the user-agent and deny entry for no solid reason, I'm concerned about exposing another variable they can use.  Is Gecko on 10.4 materially different from Gecko on 10.5 that sites need to know this? 

See also bug 57555, which is still open because (among others, AFAICT) Windows users want to remove the more detailed Windows versioning from the UA.  

Along those lines, I'm also concerned about what happens when 10.6 comes out and 10.4 ceases receiving security updates from Apple for security vulnerabilities it may still contain; anyone using a version of a Gecko browser with this UA change would be advertising to the world the user is running a version of Mac OS X that may be in a position to easily be exploited.

In my opinion, there seems to be a number of (potentially serious) downsides to this change, but no compelling reason in support of it.

Comment 5

[Colin Barrett [:cbarrett]]

Comment on attachment 285179 [details] [diff] [review]
patch rev 1

Gestalt looks good to me. Using PR_smprintf to apppend to an nsCString seems a little bleh.

Perhaps nsPrintfCString or some other other tool in our cornucopia of string functions is more apropos?

I defer to bisei on that though.

Comment 6

[Colin Barrett [:cbarrett]]

Some use cases for this:

I'm a software vendor:

 - My product doesn't support your OS. I put up a page warning you that my product won't start (of course I put a link anyway, in case you're downloading it for some other reason or whatever).
 - I want statistics about which version of Mac OS X folks are using to visit my site (to help gauge target markets, perhaps for discontinuing an older version).

You can already detect this for Safari users by looking at the version of WebCore they're using (ignoring the Safari 3 beta, a minor wrinkle and still gets you a minimum version). I know folks who have both of the above uses cases, and they'd definitely be useful for Mozilla on the Firefox website.

Also,
   17:43 <@Mossop> OS/2, WinCE, Win32 and AIX all get a version in the UA right now

It's also not just an issue of Gecko -- Firefox and other apps may behave or act differently with OS integration.

Comment 7

[Samuel Sidler (old account; do not CC)]

Please read the user-agent spec: http://www.mozilla.org/build/revised-user-agent-strings.html

"Values for Unix systems shall be the output of the command uname -sm (also accessible as the sysname and machine fields of the utsname structure.) (Previous versions of this document said they should be the output of uname -srm, but the release field of the utsname structure was considered to reveal too much information about the system, such as potential security holes.)"

On Mac OS X 10.5 (beta), uname -sm returns: Darwin i386
On Mac OS X 10.5 (beta), uname -srm returns: Darwin 9.0.0b5 i386

If we're clearly stating in the spec that adding "9.0.0b5" reveals too much information, then adding "10.5" reveals too much as well. Unless you're intending on changing the spec as well...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, you should be able to use an nsPrintfCString for that, I think.

Comment 9

[Colin Barrett [:cbarrett]]

(In reply to comment #4)
> Along those lines, I'm also concerned about what happens when 10.6 comes out
> and 10.4 ceases receiving security updates from Apple for security
> vulnerabilities it may still contain; anyone using a version of a Gecko browser
> with this UA change would be advertising to the world the user is running a
> version of Mac OS X that may be in a position to easily be exploited.

The same thing that happens to people who use an unsupported version of Firefox?

If we are supporting our product on an officially unsupported versions of Mac OS X, we shouldn't be, esp. since we're an attack vector. Apple, however ships security updates for older versions for much longer than we do (see the 10.3 security update shipped earlier this year, 2+ years after Tiger shipped).

A number of people have complained about the inability to do this to me, I think we should add it.

Comment 10

[Colin Barrett [:cbarrett]]

(In reply to comment #7)
> Please read the user-agent spec:
> http://www.mozilla.org/build/revised-user-agent-strings.html
> 
> "Values for Unix systems shall be the output of the command uname -sm (also
> accessible as the sysname and machine fields of the utsname structure.)
> (Previous versions of this document said they should be the output of uname
> -srm, but the release field of the utsname structure was considered to reveal
> too much information about the system, such as potential security holes.)"
> 
> On Mac OS X 10.5 (beta), uname -sm returns: Darwin i386
> On Mac OS X 10.5 (beta), uname -srm returns: Darwin 9.0.0b5 i386
> 
> If we're clearly stating in the spec that adding "9.0.0b5" reveals too much
> information, then adding "10.5" reveals too much as well. Unless you're
> intending on changing the spec as well...

That's BS. We are already non conformant to the spec on Mac OS X, then. I would like to update the spec to give us the same granularity as Windows has, yes. 

Is that even the master document anymore? If so, should it be moved over to devmo?

Comment 11

[Samuel Sidler (old account; do not CC)]

(In reply to comment #10)
> That's BS. We are already non conformant to the spec on Mac OS X, then. I would
> like to update the spec to give us the same granularity as Windows has, yes. 

Mentioned at the top of the document: "There is concern that giving the operating system version on Windows reveals too much information about a system (such as potential security holes)."

I'd also say that if we don't conform, that's a bug and we should fix it.

> Is that even the master document anymore? If so, should it be moved over to
> devmo?

It probably should move, yes. dbaron can decide that since he's the maintainer, afaict.

Comment 12

[Colin Barrett [:cbarrett]]

(In reply to comment #11)
> 
> I'd also say that if we don't conform, that's a bug and we should fix it.
> 

We cannot. Not including the phrase "Mac OS X" in the UA would almost certainly break sniffers.

According to the spec we would report either "Darwin {arch}" or simply "PPC" or "x86". That does not match with reality at all. On PPC we report "PPC Mac OS X Mach-O" (see the bug I linked in comment 0) and on intel "Intel Mac OS X" (we don't do CFM builds anymore).

We can't change our UA in the incompatible way you suggest (removing tokens people are matching on). Adding a string should be fine, however.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #6)
> Some use cases for this:
> 
> I'm a software vendor:
 

>  - I want statistics about which version of Mac OS X folks are using to visit
> my site (to help gauge target markets, perhaps for discontinuing an older
> version).

This sounds like something best obtained from your own software (e.g., in your 'software update' feature), not from you users' browsers, especially as I'm not aware of any Mac OS X browser that advertises this fact.

> You can already detect this for Safari users by looking at the version of
> WebCore they're using (ignoring the Safari 3 beta, a minor wrinkle and still
> gets you a minimum version).

Only because the current WebKits only ship on one major OS version; they're advertising the RE version just like we advertise a Gecko version, and it just happens you can coerce that into an OS version.

(In reply to comment #9)

> If we are supporting our product on an officially unsupported versions of Mac
> OS X, we shouldn't be, esp. since we're an attack vector. Apple, however ships
> security updates for older versions for much longer than we do (see the 10.3
> security update shipped earlier this year, 2+ years after Tiger shipped).

Firefox 2 currently supports Mac OS X 10.2, which stopped receiving security updates sometime in 2005 (iirc).  Mac OS X 10.3 will likely stop receiving security updates later this month (technically, whenever the first security update appears for 10.5 and 10.4 but not 10.3); Firefox 2 supports it, too.  You're saying we should prevent the next Firefox 2.0.0.x from running on 10.2 and 10.3?

(In reply to comment #10)

> Is that even the master document anymore? If so, should it be moved over to
> devmo?

Typically policy documents haven't been migrated to devmo (in order to prevent random edits and to give them more authority in the minds of the world), but as Sam says, that's dbaron's call.

Comment 14

[Colin Barrett [:cbarrett]]

> > You can already detect this for Safari users by looking at the version of
> > WebCore they're using (ignoring the Safari 3 beta, a minor wrinkle and still
> > gets you a minimum version).
> 
> Only because the current WebKits only ship on one major OS version; they're
> advertising the RE version just like we advertise a Gecko version, and it just
> happens you can coerce that into an OS version.

Actually they ship small updates with various micro version bumps occasionally, you can tell from those numbers the specific version of the OS you're on, usually.

http://developer.apple.com/internet/safari/uamatrix.html
 

> Firefox 2 currently supports Mac OS X 10.2, which stopped receiving security
> updates sometime in 2005 (iirc).  Mac OS X 10.3 will likely stop receiving
> security updates later this month (technically, whenever the first security
> update appears for 10.5 and 10.4 but not 10.3); Firefox 2 supports it, too. 
> You're saying we should prevent the next Firefox 2.0.0.x from running on 10.2
> and 10.3?

That's a totally invalid argument. This wouldn't affect branch or 10.2 users at all.

And it isn't even a valid hypothetical argument either. My answer is that we shouldn't put ourselves in a situation like that in the first place. We should stay more current with with OS releases in general, and shouldn't be shipping on an OS that's likely to be unsupported during the lifetime of that release of the browser.



Additionally, "Intel Mac OS X" tells you (currently) that someone is running on 10.4. and say, if 10.6 drops support for PPC, then seeing "PPC" in the UA string means you are on 10.5 or lower. We're already revealing information about the OS version through side channel attacks like that.

I really don't see see how this presents as serious of a security or privacy problem as you guys are making it out to be. It is definitely something that folks on the Mac would really like to see, and have been grumbling about (to me) ever since I started here. (I just got around to making the bug :\)

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #14)
> That's a totally invalid argument. This wouldn't affect branch or 10.2 users at
> all.

Er, sorry, that was meant to be hypothetical, or rather an analogy. I don't see how we can guarantee in the future we won't be in situations *like* we are with 10.3 and Gecko 1.8.1 right now, where we'll still be making security releases on a supported Gecko branch that run on an OS that's just been EOLed security-wise.  If we support security updates on 1.8.1 for 6 months after 1.9 apps ship, we'll be supporting 10.3 until what, June, 8 months after it stopped getting security releases?

So, for the analogy, in 2009 when 10.6 comes out and EOLs security updates for 10.4, it seems to me that there's a good chance we'll still be within the security updates timeframe for Gecko 2.0(?) apps--and likely for a non-trivial period of overlap with 10.4 being supported by Gecko and unsupported by Apple.  If we take this patch, those people will have their OS version out there.  There may well be no security holes that affect 10.4 after 2009, but do we want to chance it?

Major OS version can be useful info to websites and other software developers, yes, but I don't see the security/privacy trade-off as being worth it, personally.  (In fact, this info would have been useful for Camino for the past 2-3 years, so that we could more cleanly point 10.1 users to 0.8.5, 10.2 users to 1.0.x, and so on, but we've managed and neither Sam nor I have felt compelled to file this bug ;) )

Comment 16

[Brendan Eich [:brendan]]

From javascript:alert(navigator.userAgent) in Safari on my up-to-date MBP:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

Birds do it, bees do it, even sentimental trees do it...

Ok, there's no OS version but that can be deduced from what is in Safari's UA string (doesn't matter if "it just happens" or not).

I'm no Mac guru, but I have been around a long time, and I'm skeptical about the argument that we should not disclose essentially what Safari is disclosing on Mac OS X, or what IE7 is disclosing on Windows (someone on Windows please tell us what the above javascript: URL shows).

Cc'ing dveditz.

/be

Comment 17

[Daniel Veditz [:dveditz]]

Various windows user agents on WinXP:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Opera/9.23 (Windows NT 5.1; U; en)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en) AppleWebKit/522.15.5 (KHTML, like Gecko) Version/3.0.3 Safari/522.15.5

Re. comment 7: arguing from our UA spec is dubious since we've never fully followed it starting with the very first token. In particular, though, the "unix" rules were never meant to apply to the Mac, Darwin notwithstanding.

Including "10.5" vs "10.4" doesn't tell an attacker about the patch-level of the machine any more than "Windows NT 5.1" tells you whether a victim has a patched or unpatched version of Windows XP. An unsupported version wouldn't be great to advertise, but in practice on Windows we don't see attackers bothering to check, they just throw up a grab-bag of old exploits to see what sticks.

I'm equally dubious about the reasons given in comment 6, but it's probably marginally more useful to show the high-level version than not.

Note that the point is moot if you have Java enabled (and everyone does): http://www.java.com/en/download/help/testvm.xml


I'm envious of Opera's short, clean, UA. Can we start over?

Comment 18

[Dave Townsend [:mossop]]

Attachment: patch rev 2

Uses nsPrintfCString as suggested

Comment 19

[Dave Townsend [:mossop]]

Comment on attachment 285222 [details] [diff] [review]
patch rev 2

Carrying forward cbarrett's review

Comment 20

[Eric Shepherd [:sheppy]]

I can see several cases where this would be handy.

Comment 21

[Mark Mentovai]

Comment on attachment 285222 [details] [diff] [review]
patch rev 2

First, I'll review the patch.  I'm not saying anything about whether I think this should be done (and I may not) other than to point out that we crafted these strings after Safari so that there's some semblance of consistency on the platform, and that Safari doesn't report the OS X version, although you could also argue that it's in another boat because typically, a single Safari version is tied to a single OS X version.

Smokey, you may be thinking about bug 323657, where we were thinking about adding something identifying universalness to the User-Agent string.  We decided not to do it, but the bug is fixed instead of wontfixed because we did wind up needing to take some of the code I wrote to support that feature.

>Index: netwerk/protocol/http/src/nsHttpHandler.cpp

>+#if defined(XP_MACOSX)
>+#include <gestalt.h>
>+#endif

Use <Carbon/Carbon.h>.  There's no such thing as gestalt.h (lowercase g), so this will break things if the system SDK is on a case-sensitive filesystem.  The current recommended approach is to just bring in the top-level header for whatever programming framework you care about, in this case, Carbon.

>+    if ((Gestalt(gestaltSystemVersionMajor, &majorVersion) == noErr) &&
>+        (Gestalt(gestaltSystemVersionMinor, &minorVersion) == noErr)) {
>+        mOscpu += nsPrintfCString(" %ld.%ld", majorVersion, minorVersion);
>+    }

Use ::Gestalt to make it clear that you're calling some system C function.

On ppc, this results in "PPC Mac OS X Mach-O 10.4", which looks kind of ridiculous.

This code is 10.4-only.  That's OK for the trunk.

Comment 22

[Colin Barrett [:cbarrett]]

First off, thanks for the review, Mark.

(In reply to comment #21)
> On ppc, this results in "PPC Mac OS X Mach-O 10.4", which looks kind of
> ridiculous.

We can no longer produce CFM builds, so that's a little meaningless. From the earlier bug it seemed like it was really only of interest to track the uptake of the Mach-O (bug 71568), and because the two versions were quite different. That's no longer the case. If someone is using "Mach-O" to detect the presence of macs, they will fail with Intel macs. I highly doubt anyone would use that to determine architecture when we put the architecture /right there/.

Comment 23

[Dave Townsend [:mossop]]

Attachment: patch rev 3

Per comments, except for the PPC thing since there doesn't seem a better suggestion for what to do.

Out of interest why does including gestalt.h work if it doesn't exist?

Comment 24

[Dave Townsend [:mossop]]

(In reply to comment #23)
> Out of interest why does including gestalt.h work if it doesn't exist?

No, scratch that, why include Carbon.h in preference to Gestalt.h?

Comment 25

[Mark Mentovai]

(In reply to comment #24)
> No, scratch that, why include Carbon.h in preference to Gestalt.h?

Because we got tired of maintaining long lists of system headers, and Carbon/Carbon.h became the Apple-recommended approach (because it supports precompiled headers).

Comment 26

[Mark Mentovai]

Comment on attachment 285268 [details] [diff] [review]
patch rev 3

This is technically satisfactory to me.

Dave, I think you should still spend some time soliciting comments about what to do with the ugly Mach-O thing, as well as whether this reveals too much to sniffers.

My opinions: it's OK to drop Mach-O on the bleeding-edge trunk for the reasons Colin gave.  This doesn't reveal information to sniffers that I'm uncomfortable with, it's of a similar class to information we already reveal and we already do this on other platforms, and there are valid uses for it.  (I'm also open to more liberal UA sanitization on the trunk.)

Comment 27

[Dave Townsend [:mossop]]

(In reply to comment #26)
> Dave, I think you should still spend some time soliciting comments about what
> to do with the ugly Mach-O thing, as well as whether this reveals too much to
> sniffers.
> 
> My opinions: it's OK to drop Mach-O on the bleeding-edge trunk for the reasons
> Colin gave.  This doesn't reveal information to sniffers that I'm uncomfortable
> with, it's of a similar class to information we already reveal and we already
> do this on other platforms, and there are valid uses for it.  (I'm also open to
> more liberal UA sanitization on the trunk.)

I really have absolutely no educated opinion on this one way or another I leave it up to the far more better qualified people already cc'ed here to make a call on this. I'm happy to adjust the patch either way.

Comment 28

[Colin Barrett [:cbarrett]]

Comment on attachment 285268 [details] [diff] [review]
patch rev 3

This should go in for M9. We should give web developers the earliest possible opportunity to react to this change, and we want to get as much testing as possible in the unlikely possible it breaks someone.

As far as risk to Firefox itself, it's not a large patch, or changing code that is a critical security attack vector.

Comment 29

[Mark Mentovai]

Comment on attachment 285268 [details] [diff] [review]
patch rev 3

And as to Mach-O, any opinions?

Comment 30

[Colin Barrett [:cbarrett]]

(In reply to comment #29)
> (From update of attachment 285268 [details] [diff] [review])
> And as to Mach-O, any opinions?

I think we should remove it. It has no meaning anymore, there is no way to build a CFM version of Mozilla1.9, as far as I know. 

Is that in-scope for this bug?

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #29)
> And as to Mach-O, any opinions?

The advantage to keeping things like this in is that people don't have to rewrite (and complicate) any existing detection that works across multiple versions.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 285268 [details] [diff] [review]
patch rev 3

a=endgame drivers for M9

Comment 33

[Dave Townsend [:mossop]]

Checked in.

Checking in netwerk/protocol/http/src/nsHttpHandler.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v  <--  nsHttpHandler.cpp
new revision: 1.131; previous revision: 1.130
done

I'd suggest opening another bug for the Mach-O issue.

Comment 34

[Colin Barrett [:cbarrett]]

Bug 401718 opened for Mach-O removal. Let the CC'ing begin! ;)

Comment 35

[Samuel Sidler (old account; do not CC)]

Verified in a Camino nightly: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9a9pre) Gecko/2007110400 Camino/2.0a1pre (like Firefox/3.0a9pre)

Comment 36

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FWIW, as of Safari 3 and Mac OS X 10.5 and 10.4.11, it's no longer possible to discern OS version from Safari version or WebKit build number.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/523.12 (KHTML, like Gecko) Version/3.0.4 Safari/523.12

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10

Comment 37

[Jesse Ruderman]

Stuart Morgan has filed bug 414057 asking for this change to be reverted.

Comment 38

[Jesse Ruderman]

It might be good to take this on the 2.0.0.x branch as well, so www.mozilla.com can avoid offering Firefox 3 to Mac OS X 10.3 users.  dveditz, what do you think?

Comment 39

[Samuel Sidler (old account; do not CC)]

I don't think we should be changing the UA on stable branches, personally.

Comment 40

[Reed Loden [:reed]]

(In reply to comment #39)
> I don't think we should be changing the UA on stable branches, personally.

I agree, but we should make sure not to offer updates via AUS to OS X 10.3 and earlier users, just like what we're going to do with GTK+ versions in bug 418131.