Last Comment Bug 57555 - UA-string is telling sites too much about the system
: UA-string is telling sites too much about the system
Status: RESOLVED FIXED
Old patch in bug 55366: https://bugzi...
: privacy
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: P3 enhancement with 1 vote (vote)
: ---
Assigned To: Ben Bucksch (:BenB)
:
Mentors:
http://webcab.de/cgi-bin/httph.cgi/c?...
: 130858 (view as bug list)
Depends on:
Blocks: 71569 83989 584683
  Show dependency treegraph
 
Reported: 2000-10-21 17:00 PDT by Cesar Eduardo Barros
Modified: 2013-10-12 22:05 PDT (History)
39 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted


Attachments

Description Cesar Eduardo Barros 2000-10-21 17:00:58 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test9-pre1 i686; en-US; m18)
Gecko/20001019
BuildID:    2000101908

Mozilla includes the whole kernel version with the user agent it sends, which is
both useless and risky.

Reproducible: Always
Steps to Reproduce:
Look at the user agent sent to servers

Actual Results:  Mozilla/5.0 (X11; U; Linux 2.4.0-test9-pre1 i686; en-US; m18)
Gecko/20001019

Expected Results:  Mozilla/5.0 (X11; U; Linux i686; en-US; m18) Gecko/20001019

or

Mozilla/5.0 (X11; U; Linux; en-US; m18) Gecko/20001019

The real reason for this bug is that I'm ashamed for not keeping up with the
kernel development while using an experimental kernel for more than a month ;-)
Comment 1 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2000-10-24 12:03:00 PDT
I've heard this comment before.  The rational for doing this was, I guess, that
we've always done it.  I'm not sure why it was done originally.  Right now the
UA spec says 'uname -srm'.  Would 'uname -sm' or 'uname -s'=='uname' be preferable?

Comment 2 Asa Dotzler [:asa] 2000-10-24 12:04:32 PDT
over to shaver.  So the answere here is probably to do something similar for
win32 as well.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2000-10-24 12:05:43 PDT
UA spec: http://www.mozilla.org/build/revised-user-agent-strings.html
Comment 4 Dan Mosedale (:dmose) 2000-10-24 12:09:32 PDT
'uname -s' seems like it would reveal less information to direct a potential
attacker to which security holes your machine might happen to contain.
Comment 5 Mike Shaver (:shaver -- probably not reading bugmail closely) 2000-10-24 12:11:46 PDT
I would support dropping the kernel version from the UA, personally.  And I
don't know of many sites that it would break -- most sites just look for Windows
or Mac and then give up. =/
Comment 6 Ben Bucksch (:BenB) 2000-11-21 20:24:16 PST
> most sites just look for Windows or Mac and then give up. =/

LOL!

I would like to fix this bug - it's trivial. Taking it. shaver, hope you don't mind.

Bug 55366 is about dropping the language as well.

I can see the usefulness of the machine type (i.e. "uname -sm", e.g. "Linux
i686"), but don't see, how that would be harmful. Any objections to keep that?
Comment 7 Ben Bucksch (:BenB) 2000-11-21 20:25:05 PST
.
Comment 8 timeless 2000-11-21 21:21:34 PST
I'm all for not telling anything about the system.  Why should anyone know what 
hardware you have?  I often need to act as a human proxy for some other 
computer or os, and imo there is no legitimate reason that servers should 
segregate me based on my computer.
Comment 9 Cesar Eduardo Barros 2000-11-22 02:50:12 PST
No uname, please. Just tell what mozilla was compiled for -- Linux i386 would mean compiled for Linux and optimized for i386, even if it's running on a K7 and under OpenBSD. After all, most bugs that depend on a platform depends on which one mozilla was compiled for, not which one it's running in.

The language (en-US) part is the language mozilla was compiled for (or the languege pack).

The idea is not to tell information about the machine, but about mozilla itself.
Comment 10 Dan Mosedale (:dmose) 2000-11-22 16:22:38 PST
Timeless: the processor type is useful for knowing (eg) whether your userbase
can reasonably be expected to get plugins for a given format, since many plugins
are only available on some architectures.
Comment 11 Ben Bucksch (:BenB) 2000-11-22 17:23:53 PST
My personal opinion to that is that the plugin argument (and thus all the
platform stuff) is mood: How many sites are today in the position to tell the
user to install a certain plugin? Luckily, not many, tendency declining.
If I were to create such a spec, I'd just say "Mozilla/5.0" (or not even that)
and list some capabilities (as seen with IMAP), but who am I? :)
Comment 12 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2000-11-22 17:48:51 PST
IMO, a change to `uname -sm` would not be controversial, whereas anything else
would probably have some opposition.  I think that change solves the problem
that we're announcing potential security holes (more than, say, having a
computer that listens for connections on some ports does).
Comment 13 Ben Bucksch (:BenB) 2001-01-14 19:36:05 PST
.
Comment 14 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2001-05-09 12:46:30 PDT
So, I've had the change to do this in my tree for months... but I've forgotten
about it.  Should I take this bug?

Index: nsHTTPHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPHandler.cpp,v
retrieving revision 1.169
diff -u -d -r1.169 nsHTTPHandler.cpp
--- nsHTTPHandler.cpp   2001/04/16 14:56:20     1.169
+++ nsHTTPHandler.cpp   2001/05/09 19:43:43
@@ -996,8 +996,6 @@
     int ret = uname(&name);
     if (ret >= 0) {
        mAppOSCPU =  (char*)name.sysname;
-       mAppOSCPU += ' ';
-       mAppOSCPU += (char*)name.release;
        mAppOSCPU += ' ';
        mAppOSCPU += (char*)name.machine;
     }
Comment 15 Ben Bucksch (:BenB) 2001-05-09 16:52:56 PDT
I run with the same patch. I can check it in. r=dbaron?
Comment 16 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2001-05-16 07:23:13 PDT
Since it's been discussed on n.p.m.netlib (a while ago) and no objections were
raised, r=dbaron, although you'd also need a super-review, of course.  (FWIW,
the filename is now spelled differently, but it's the same patch.)
Comment 17 Alec Flett 2001-05-16 09:58:50 PDT
doesn't that patch affect mac and windows as well? i.e. instead of "Windows NT
4.0" aren't I going to see "Windows NT"?

I'm tempted to sr= this, and I definitely want to see the linux kernel version
taken out of the UA, but I'm concerned that this is going to break some sites
which (wrongly, of course) depend on there being a OS version number in the UA.
Comment 18 Ben Bucksch (:BenB) 2001-05-16 10:20:57 PDT
alecf, the code is
#elif defined (XP_UNIX) || defined (XP_BEOS)
Comment 19 Alec Flett 2001-05-16 10:50:32 PDT
oh! couldn't see that from the patch.. sr=alecf
Comment 20 Darin Fisher 2001-05-16 11:18:43 PDT
FWIW r/sr=darin
Comment 21 Ben Bucksch (:BenB) 2001-05-21 19:16:25 PDT
ops, I slept too long. Too late for 0.9.1. Will check in after tree reopens for
0.9.2. Sorry.

Thanks for the (super)reviews.

Ben
Comment 22 danielmc 2001-05-22 06:37:13 PDT
Evelyn, is this going to affect Netcenter tracking for the Commercial product?
Comment 23 Asa Dotzler [:asa] 2001-06-11 09:05:05 PDT
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Comment 24 Ben Bucksch (:BenB) 2001-06-15 23:43:06 PDT
Fix for Unix/BeOS disicussed above checked into trunk. Thanks for r/sr/a.

Leaving bug open for other platforms.
Comment 25 Ben Bucksch (:BenB) 2001-06-15 23:43:54 PDT
QA: You can see your HTTP headers at
<http://www.in.tum.de/cgi-bin/ucgi/pircher/set.cgi>.
Comment 26 Jacek Piskozub 2001-07-17 13:40:20 PDT
The URL for HTTP headers no longer works :-(
Comment 27 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2001-07-17 13:45:26 PDT
Changed URL for HTTP headers to
http://www.people.fas.harvard.edu/~dbaron/www/httpreq
Comment 28 Jacek Piskozub 2001-07-27 20:51:42 PDT
Patch 43864 for bug 55366 will fix the Windows part of this bug (when/if checked
in).
Comment 29 Ben Bucksch (:BenB) 2001-07-27 22:52:16 PDT
Thanks for noting this here. But nobody should be scared - I will run through
review in this bug and not sneak such a change in with another bug.

All: The patch in the other bug leaves only 3 possible values in the OS-field of
the UA-string under Windows:
- "Win9x", for Win95, 98, ME
- "WinNT", for WindowsNT 3, 4, W2K
- "Win" as fallback
Requesting feedback.
Comment 30 Ben Bucksch (:BenB) 2001-07-31 00:18:53 PDT
Posted proposal to .netlib: <news://news.mozilla.org/3B665A87.8050807@beonex.com>.
Comment 31 Christian Rose 2001-09-28 17:25:19 PDT
Isn't leaving this (-r) information out just a simple form of security by
obscurity? I don't think it adds any security at all; this information can still
be gained by other means by attackers (for example by some simple portscan
analysis).
Comment 32 Cesar Eduardo Barros 2001-09-28 17:37:22 PDT
No, it isn't.

- I'm behind a NAT; just try to portscan me and you'll get a 2.2 Linux box,
which is the wrong answer (the right one would be some 2.4.x)
- Even if you portscan me; the networking code doesn't change every release. You
know the general version, but not the specific one. Idem for passive fingerprinting.
- Last but not least, some people don't want the EXTRAVERSION to be visible.
Look at my original report -- the EXTRAVERSION was clearly -test9-pre1 then.
People put all sorts of strange things in the EXTRAVERSION, like machine names,
which special patches they're using, and the like.

Security is a process; every little bit helps
Comment 33 Jacek Piskozub 2001-09-28 17:52:04 PDT
Cesar: Sue me but I cannot see how it will make me safer. The attacker is more
interested in the version number of your daemons than the kernel. Same with
windows: it's the patches I installed that's relevant, not whether I have
Windows98 or WindowsME. Most Linux people do not spoof the OS network footprint
the way you do so it would not help them, anyway.

So I vote for a pref for people like Cesar, but let's leave the default
UA-string as it is. 
Comment 34 Cesar Eduardo Barros 2001-09-28 18:02:25 PDT
<qa please ignore>

> but let's leave the default UA-string as it is.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010926
It's already without the -r .

Besides, which advantage does you get by sending your current kernel version?
None. So it's pointless to provide a pref.

<does qa really ignore comments when asked to? I'm curious.>
Comment 35 Christian Rose 2001-09-28 18:08:57 PDT
<Replying to cesar's previous comment>
Of course using a NAT affects this, but it affects it either way, "-r"
information or not, doesn't it?
Portscanning can reveal much information, even if networking code in the kernel
itself doesn't change. For example, the pattern of open ports/services
running/versions of those services can give more than enough information to
determine the operating system used with good precision, and the step from
retrieving this information to guessing the kernel version used is trivial.
About EXTRAVERSIONS I agree that it's mostly useless, but on the other hand it
has always been this way, and not caused any significant problems. I fail to see
why a change is needed.

I fully agree with security being a process, but not all steps and possible
actions do necessarily improve anything security-wise.
Comment 36 Christian Rose 2001-09-28 18:12:43 PDT
The "-r" information is useful on most Unixes, especially on Linux as it's the
only way to guess the distribution used, using the uname information. The
information about distribution can then be used to provide the correct default
type of software packages on a download page, for example.
Comment 37 Ben Bucksch (:BenB) 2001-09-28 19:20:38 PDT
> Same with windows: it's the patches I installed that's relevant, not whether I
> have Windows98 or WindowsME.

Right, assuming there are still current patches for WIndows 95. But,
transferring this to Unix, the "extraversion" is roughly comparable with the
patchlevel on Windows - it tells about very specifc weaknesses, some of which
gove root access.

> The attacker is more
> interested in the version number of your daemons than the kernel.

Yes, but
- a portscan is an active procedure. The attacker has to do something to my
machines which I can measure. OTOH, *I* send the UA string out without being
asked, i.e. the attacker can collect infomation about my weaknesses without me
having a chance to notice.
In the worst case, the attacker can place an attack without me having a chance
to be warned and to protect myself.
- something else which I forgot

> it has always been this way, and not caused any significant problems. I fail
> to see why a change is needed.

Because you don't know, which problems or not this has caused, and it
potentially causes desastrous problems.

> The
> information about distribution can then be used to provide the correct default
> type of software packages on a download page, for example.

"Download:
RPM: ...
DEB: ...
tarball: ..."

This is better anyways, because Unix people don't like too "smart" systems, e.g.
I might want to download something for another machine. If I don't know, which
package type I need, I don't have any use for the package anyways.
Comment 38 Matthew Tuck [:CodeMachine] 2001-09-28 20:44:30 PDT
Security through obscurity is a good thing unless it prevents other better forms
of security.
Comment 39 Christian Rose 2001-09-29 02:57:54 PDT
>> The attacker is more
>> interested in the version number of your daemons than the kernel.
>
> Yes, but
> - a portscan is an active procedure. The attacker has to do something to my
> machines which I can measure. OTOH, *I* send the UA string out without being
> asked, i.e. the attacker can collect infomation about my weaknesses without
> me having a chance to notice.

Exploiting knowledge about system type is also an active procedure. There's no
difference at all this way.
On the other hand, what is different is that sniffing user agent strings
requires the ability to sniff your http traffic (or be the webmaster in the
opposite end), while anyone around the world can portscan you to get more or
less the same information for free, without any special sniffing or physical
access to your private network or routers along the way. That's part of why
crippling the user agent is a wrong way of solving anything.


> In the worst case, the attacker can place an attack without me having a
> chance to be warned and to protect myself.

I'm fairly sure that most of those who have exploitable systems with year-old
kernels with known vulnerabilities rarely are the same people who know to
detect, identify, and properly react to, portscans.


>> it has always been this way, and not caused any significant problems. I fail
>> to see why a change is needed.

> Because you don't know, which problems or not this has caused, and it
> potentially causes desastrous problems.

You don't know either. This is speculation about a theoretical problem, and the
"fix" presented only works by crippling information without fixing the security
problem itself, which is otherwise known as security by obscurity. That doesn't
work, the system is as exploitable as before and the effects from an exploit are
just as disastrous, the only thing it accomplishes is a false sense of security.


>> The information about distribution can then be used to provide the correct
>> default type of software packages on a download page, for example.
>
> "Download:
> RPM: ...
> DEB: ...
> tarball: ..."
> 
> This is better anyways, because Unix people don't like too "smart" systems,
> e.g. I might want to download something for another machine. If I don't
> know, which package type I need, I don't have any use for the package
> anyways.

I was talking about default package, there's no reasons other choices cannot
still be present. And "Unix people" is by no means a homogenous group, there are
many people who wouldn't know what package type to choose, and if one can help
only a few of them much is won.


> Security through obscurity is a good thing unless it prevents other better
> forms of security.

Now this is a shocking statement. Security by obscurity is never a good thing,
simply because it is no security! Systems are as vulnerable as before, and the
only thing you accomplish is a false sense of security this way, because the
information is perfectly gainable by other means *and by more people*, while
effects are as disastrous as ever before.
There's an old saying: "Don't kill the messenger".
Comment 40 Matthew Tuck [:CodeMachine] 2001-09-29 04:26:04 PDT
> Security by obscurity is never a good thing, simply because it is no security!

This is not true.  I am sick of hearing people kneejerk at "security through
obscurity".  Things like passwords and crypto keys are very productive
forms of obscurity.  Every little bit of security added makes it more likely
that an attacker will fail.  As I said, obscurity is only a bad thing when it is
to the detriment of other forms of security, such as peer review of programs and
cryptosystems.

> the only thing you accomplish is a false sense of security this way

As I said, it is security.  It might not be a huge amount of security in a
specific case, but some is better than none, and a lot plus it is better than a
lot without it.  As has been stated, security is properly done with multiple
redundant layers, and obscurity often plays a part in that.  It should
definitely not be done to the detriment of any other type of security that can
be done.

> because the information is perfectly gainable by other means

Now you're talking about the specific case.  And has been stated, this isn't
true for machines behind firewalls.
Comment 41 Ben Bucksch (:BenB) 2001-09-29 05:06:08 PDT
> Exploiting knowledge about system type is also an active procedure.

Yes, but I won't notice anymore until it's too late.

> sniffing user agent strings requires the ability to sniff your http traffic

No. Countless http logs are publicably abailable on the web.

> year-old kernels with known vulnerabilities

This is nonsense and you know it. The volnerability might have been discovered
only a week ago and Redhat might still do QA and not have a new kernel package
available or anything. It is the nature of the extraversion that it changes more
often than every few years and what makes it so dangerous.

> security by obscurity

Go to the NSA and ask them about minute details of their network infrastructure.
They won't tell you? Of course, they are incompetent because of that, right?

How, do you think, do port-fitfalls or Clifford Stoll's chroot jail work?

See also Matty.
Comment 42 Christian Rose 2001-09-29 15:48:38 PDT
>> Security by obscurity is never a good thing, simply because it is no
> security!
>
> This is not true.  I am sick of hearing people kneejerk at "security through
> obscurity".  Things like passwords and crypto keys are very productive
> forms of obscurity.  Every little bit of security added makes it more likely
> that an attacker will fail.  As I said, obscurity is only a bad thing when
> it is to the detriment of other forms of security, such as peer review of
> programs and cryptosystems.

No, it certainly is true. There is a huge difference between making something a
little tougher to do for the impatient, and making it impossible to solve in a
given timeframe given the algorithms and computer systems known today. Security
by obscurity measures don't contribute to overall security in any way besides
making the task a little tougher and disencouraging the potential attackers that
would most likely fail anyway. It offers no "protection" at all from the rest.
That's why it doesn't improve security.


>> the only thing you accomplish is a false sense of security this way
>
> As I said, it is security.  It might not be a huge amount of security in a
> specific case, but some is better than none, and a lot plus it is better
> than a lot without it.  As has been stated, security is properly done with
> multiple redundant layers, and obscurity often plays a part in that.  It
> should definitely not be done to the detriment of any other type of
> security that can be done.

It is no security, because it adds nothing except trivial guessing, instead of a
difficult computational problem.


>> because the information is perfectly gainable by other means
>
> Now you're talking about the specific case.  And has been stated, this isn't
> true for machines behind firewalls.

And these machines behind firewalls are most likely not accessible by outside
people, so the information won't do them no good. People with access to the
inside network most likely could get access to the information anyway.
Comment 43 timeless 2001-10-01 01:29:03 PDT
ack. why did i say that? -- oh i know why. the keyword there is segregate.  and 
here i sit on both sides of the fence. VersionTracker is a well known mac 
software site. I visited it a few weeks ago while trying to walk my sister 
through getting some internet apps for her new mac.  VersionTracker happily 
directed me to the Windows site instead of the Mac site !! This is the kind of 
segregation i didn't want.  The bugzilla form, where i merely get a suggestion 
and the option to override it is not segregation in my book and is ok... --

fwiw if anyone does anything to this bug, it will hurt bugzilla.  Recently i've 
had to go back and repair PC:Other because a few w98/nt4's reporters didn't 
notice that bugzilla selected 'other'.  If bugzilla could never tell I'd 
probably help bugzilla write packet sniffing software that diagnosed inbound 
packets to determine the OS and platform.  The UA is indeed important for web 
applications and plugins.

If any site is found to misuse UAs we can easily file evangelism bugs against 
them, or ask the FBI to investigate them -- These days such an investigation 
might lead to life terms or something, so the threat itself might be sufficient 
(yeah right).
Comment 44 Ben Bucksch (:BenB) 2001-11-30 09:00:24 PST
> If any site is found to misuse UAs we can easily file evangelism bugs against 
> them, or ask the FBI to investigate them

Yeah, go to the FBI and complain about the FBI :-).


(It's just a joke, not intended to reopen the discussion.)
Comment 45 Asa Dotzler [:asa] 2001-12-03 10:42:40 PST
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Comment 46 timeless 2002-03-16 21:42:57 PST
*** Bug 130858 has been marked as a duplicate of this bug. ***
Comment 47 Mike Cowperthwaite 2002-08-26 09:58:54 PDT
A specific reason to allow the distinction between Windows NT 3.5x and Windows NT 4 and above is that the Sun J2RE is not available for 3.5x.  (Is it feasible to create a Mozilla build for Windows 3.1?)  Similarly, distinguishing between MacOSX and earlier MacOS helps determine which Java version is available, altho the fairly reliable presence of a Java allows querying the same info via LiveConnect.

How actually useful that information is, is certainly debatable.  My site has a Java version sniffer page to help people determine if they've got a Java that's up-to-date enough for my applet.  I'm not expecting a flood of visitors, let alone NT3.5 users, but should one come along, it would be nice to customize the page, to let them know up front that there's no point downloading the JRE.
Comment 48 Joshua Holman 2003-02-26 22:22:10 PST
This is a good idea. Since NS 6, the UA has showed what version of Windows I am
using. Since i've been on the net, i've never seen a site that has weeded out
versions of Windows. I think Mac and *nix users would agree.

I propose this solution:

Win95/98/98SE/ME/2000/NT4/XP: Should be just "Windows"

Mac OS X: Should be just "Macintosh" or "MacOS"

Unix: Should just be "X11 [Processor] [type of Unix], example: X11, x86 Linux
Comment 49 Joshua Holman 2003-02-26 22:23:25 PST
added self to cc list.
Comment 50 timeless 2003-02-26 23:28:02 PST
that's mighty funny since you just added a comment to a system which *does* use
the field.

that said, please don't comment if you're just cc'ing yourself, some people opt
out of the bugmail for such a change and it needlessly polutes the bug view for
anyone who reads it at a later date.
Comment 51 Vedran Miletic 2003-10-05 08:47:21 PDT
retargeting
Comment 52 Chris Blore 2005-05-22 04:29:46 PDT
Where do we stand with this bug now? It seems to me as though it should be
resolved FIXED as there has been no change for over two years...
Comment 53 Cesar Eduardo Barros 2005-05-22 06:36:55 PDT
(In reply to comment #52)
> Where do we stand with this bug now? It seems to me as though it should be
> resolved FIXED as there has been no change for over two years...

I thought this bug had already been closed a long time ago.
Comment 54 Ben Bucksch (:BenB) 2005-09-05 12:52:04 PDT
Comment 29 is not fixed yet and the reason why this was still open.
Comment 55 Tony Mechelynck [:tonymec] 2008-03-30 10:50:35 PDT
- Moving to Core (I expect the kernel version to be handled identically in SeaMonkey, Firefox, etc.)

- Moving to All/All (rather than Linux, since comment #29, the reason why this bug is still open, is about Windows).

- No comments in 2½ years. Shall we resolved this FIXED (since the "expected results" of comment #0 are what I see now in e.g. "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033001 SeaMonkey/2.0a1pre"), WONTFIX (if we agree that the three Windows versions mentioned in comment #29 are a privacy liability, but that we won't fix it), or is someone sometime going to fix what remains to be fixed in this bug?
Comment 56 Tony Mechelynck [:tonymec] 2008-03-30 10:57:24 PDT
Sorry, Ben, changing the component temporarily reset the assignee: I gave this bug back to you, but you'll have to accept again (or change it again to nobody@mozilla.org)
Comment 57 Ben Bucksch (:BenB) 2008-03-30 18:11:51 PDT
> is someone sometime going to fix what remains to be fixed in this bug?

We have a patch since several years. I'm just too tired to drive it.

(BTW, exact Gecko version is also a problem. It should be the base release, i.e. security fix 2.0.1 should have the same Gecko date that 2.0.0 had. And it should be "Firefox/2.0" only, not "Firefox/2.0.13", similarly.)
Comment 58 Tony Mechelynck [:tonymec] 2008-03-31 12:34:47 PDT
(In reply to comment #57)
[...]
> (BTW, exact Gecko version is also a problem. It should be the base release,
> i.e. security fix 2.0.1 should have the same Gecko date that 2.0.0 had. And it
> should be "Firefox/2.0" only, not "Firefox/2.0.13", similarly.)
> 

I guess that would break the way the Bugzilla "guided" bug-entry form displays the product/version/build ID. We want to know in what exact build the problem happened, and I suppose the people having just got a fresh Bugzilla account for the purpose of making their first bug report, are quite happy with having the string pre-filled and wouldn't know what to type if it was asked from them (not to mention all possible typos if they don't realize they can use the clipboard). Even for people having recently switched to using branch-nightly builds it might be less than obvious at first.

Well, I guess nothing is perfect.
Comment 59 Reşat SABIQ (Reshat) 2010-04-06 21:37:43 PDT
I originally started w/ privacy considerations around locale, which apparently have been "buried" in bug 55366 for 10 years. There's really no extension to handle those concerns, but after considerable effort i was able to provide a way to "mask" the UI locale via extension, as well as a way to mask the OS/platform. However, now i got to "appreciate" (invert the meaning of that) the privacy-mindless nature of things like release date and APPBUILDID. Things like Gecko/20100401, and &buildid=20100317103207 are almost impossible to "mask" in an extension: they change weekly or monthly, and they are no good for privacy (along w/ afore-mentioned Firefox/n.m.X). The only feasible way to mask them in an extension is to make them static, but that is not an acceptable or effective approach.

Firefox 3.5 introduced Private Browsing. Well, appreciated, but time would have been spent much better by working on some of the privacy issues that exist to this date in any kind of browsing (private browsing had a work-around of using a different profile, if needed a 1-time profile; this stuff has no work-around).

There has to be some action starting w/:
1. Passing APPBUILDID etc. to mozilla only via HTTPS, if it has to be passed in (bug 557730 (thunderbird)).
2. Reducing release date to year only, e.g.: Gecko/2010
Correct me if i'm wrong, neither Opera, nor IE, for instance, reveal release date in user-agent string.
3. Getting rid of the minor version number from Gecko and app versions: e.g., Firefox 3.6

For bug reporting, a private version of user-agent, and other info can be used, it can even be called something like User-Agent2 or User-Agent-Private.

It pains me to say this, after spending a good amount of time on various mozilla-related extension and activities: Mozilla applications are the least privacy-aware applications available on the market. It is time to start catching up. And to make sure there's no misunderstanding: I'm not saying this to disparage, but to encourage! Put these items on 3.7 or 4.0 plan yesterday!
Comment 60 Reşat SABIQ (Reshat) 2010-04-06 22:19:49 PDT
(In reply to comment #59)
> 2. Reducing release date to year only, e.g.: Gecko/2010
> Correct me if i'm wrong, neither Opera, nor IE, for instance, reveal release
> date in user-agent string.

Actually, "Gecko/2010" is unacceptable, because at the turn of a year, it becomes potentially equivalent to a format that contains a month and a day of month as well, which matters when taking into account various platforms. The date has to be dropped completely, similar to how it's done, AFAIK, by Opera and IE.
Comment 61 Ben Bucksch (:BenB) 2010-04-07 06:08:42 PDT
> Getting rid of the minor version number from Gecko and app versions
> e.g. Firefox 3.6

Yes. The minor version is the most risky (because that's where security releases happen), with very little gain for sites (given that we don't want to change site behavior in minor releases, and I don't think sites bother to check for that).

> Gecko/2010

Stripping off Gecko/ parts will break many sites which carried the old broken UserAgent-switches into the 2000 area.

But what we can do is to fix the Gecko date to the one when the major version was released. I'd argue that's actually *more* useful and precise for sites than the current scheme where a dot-release gets a later Gecko version than the next major version.
Comment 62 Reşat SABIQ (Reshat) 2010-04-07 21:08:20 PDT
(In reply to comment #61)
> Yes. The minor version is the most risky (because that's where security
> releases happen), with very little gain for sites (given that we don't want to
> change site behavior in minor releases, and I don't think sites bother to check
> for that).
100% agreed. I'm sure this is easy to implement too.

> 
> > Gecko/2010
> 
> Stripping off Gecko/ parts will break many sites which carried the old broken
> UserAgent-switches into the 2000 area.
IMHO, sometimes passivity has to be broken for greater good.

> But what we can do is to fix the Gecko date to the one when the major version
> was released. I'd argue that's actually *more* useful and precise for sites
> than the current scheme where a dot-release gets a later Gecko version than the
> next major version.
A core requirement, IMHO, is the following:
Either mozilla apps themselves should implement an option for user to mask their real OS/platform, or they have to, at a minimum, enable extensions to do so in a fashion that accounts for update/minor versions and various platforms, including a "dynamically-masked" User-Agent string (i.e., not just hard-coding the override property, because it will be becoming obsolete in several weeks).

It's a requirement because even for English telling everybody on the Internet that you are in a group of 1 or 2 out of 100 users, is not good from privacy viewpoint. Imagine the same for various other locales?

From this viewpoint, the problem w/ having any kind of date, is:
vendors (e.g., Ubuntu) are likely to have their own date, making the above requirement harder to implement (an extension meeting the above requirement would have to wait until the major version release date before knowing what date to use for masking of a vendor release; that means it couldn't even be submitted to amo until the release is made, and won't be available to users for x days after the release, during which blending an OS that stands out would only be possible w/ manual tweaking, which most users won't do). At best it's a race condition, at worst (most likely) it's not workable.

Therefore, my votes are for the following in order of preference:
1. No date whatsoever in User-Agent: e.g., Gecko instead of Gecko/20100401
2. Symbolic date for the sake of passivity only, as long as vendors are aware that they must not change it and will be jailed w/o parole if they do (doesn't seem practical to me): e.g., Gecko/yyyy0101 instead of Gecko/yyyymmdd
3. As Ben mentioned, actual major version release date, i.e.: Gecko/yyyymmdd

The last option is not acceptable IMHO, but it would still be an improvement to a new date for every minor version, and has at least some potential for working around it as far as the afore-mentioned requirement is concerned (although w/ a lot of limitations which will probably make it unworkable for stretches of time for at least some major releases). Hence i give 3 votes to option 1., 2 votes to option 2., and 1 vote to option 3. I give a wag of my finger in Colbert sense to what's being shipped now.

P.S. 
I would really appreciate a notification in this bug of any planned progress in this direction. I guess i'll have to mention this in my prayers, cause there hasn't been any for 10 years.
Comment 63 Ben Bucksch (:BenB) 2010-04-08 01:16:02 PDT
FWIW, I'd probably actually take the branch date when the release branch branched from trunk/mozilla-central, not the release date. That makes more sense because that's when features should be frozen, and also solves your problem, and makes it easier to (either) script this or manually set it.
Comment 64 Reşat SABIQ (Reshat) 2010-04-09 22:16:01 PDT
Thanks Ben, I guess you are proposing the dates in Date Branched column at
https://wiki.mozilla.org/Releases/Branches

This would indeed resolve the current date-related concerns, but only if vendors don't deviate from this convention.

P.S. My option 2. wasn't well formulated in my last message, because it would still leave questions about the turn of the year. Since Ben's approach addresses that aspect, i guess the Gecko part changes possible are:
i. No date: Gecko
ii. Branch date: Gecko/yyyymmdd
where yyyymmdd is based on date on the page linked above.
P.P.S. FWIW, i'd give 2 votes to i. because it rules out any date issues when taking into account vendors. But if the date is required for backwards compatibility and it were not to be broken, then ii. should do as long as vendors adhere to it, so i'd give 1 vote to approach ii. To reiterate, the status quo date doesn't get any of my imaginary votes, but gets an emphatic wag of my finger.
Comment 65 Tony Mechelynck [:tonymec] 2010-04-10 00:17:49 PDT
This bug seems to be slowly but surely moving in a direction I don't like, so I think I'm going to expand somewhat on what timeless said in 2001 in comment #43

Among the pages which do something with the info in the UA string, there are at least two which I goddamn want to keep getting that info: namely, https://bugzilla.mozilla.org/enter_bug.cgi and about:

The former so that when someone with no privileges files a bug, any triager or developer coming across the bug report can tell immediately which exact build was involved -- not only which major version, not even only which minor version, but which 32- or 64-bit release, nightly or tinderbox build of which branch for which OS and (by deduction) precisely with or without which patches.

The latter, so that I can check which exact build I'm running at any given time, with no jumping through hoops and no fancy footwork. And in particular whether it could include the fix for that extremely annoying bug which has been pestering me, a fix which was committed to Mercurial "earlier today" (of any given "today"), no later than comment xxx on that bug. Also so that even when using the "full" BMO bug entry form I (or anyone else) can still easily get the needed info onto the bug report.

Anything that interferes with either or both of these two pages getting that info will surely be a "regression", and I'm even tempted to call it "dataloss" (but in the latter case I'm less sure about my interpretation of the relevant describekeywords.cgi paragraph). Also, don't forget that several different buiolds are in use by different (or sometimes the same) people at any given time, so BMO will have to give correct results for builds both "with" and "without" any "fix" for this bug.
Comment 66 Ben Bucksch (:BenB) 2010-04-10 04:58:38 PDT
Yup, I'm sure we can find solutions for bugzilla and about: . (Updater I think sends the version explicitly already, as it should, so no problem there.)
Comment 67 Reşat SABIQ (Reshat) 2010-04-10 11:10:59 PDT
(In reply to comment #59)
> For bug reporting, a private version of user-agent, and other info can be used,
> it can even be called something like User-Agent2 or User-Agent-Private.

Per above, I think User-Agent2 or User-Agent-Private (or whatever is the apparently needed formal name) would also need to be shown in Help->About dialog. However, in that dialog, i think the publicly visible User-Agent is also needed. So perhaps both User-Agent, and User-Agent2/User-Agent-Private need to be shown, or if one of them is shown then a button would be needed to be able to display the other one instead.
For bugzilla, a quick thought comes to mind that User-Agent2/User-Agent-Private could be made accessible via navigator.userAgent (or perhaps navigator.userAgent2, etc.), based on verifying the specific site certificate, so that's it's only accessible in this exceptional case(s), and not always.

P.S. Thus, some minor essentially passive UI changes apparently are required as well for this bug, as well as a big question about what to name private string as opposed to public string, and how that decision is to be made.
Comment 68 WulfTheSaxon [:Wulf] 2010-05-17 15:52:54 PDT
I've seen several sites that tailor their CSS to blend well with the form controls in various operating system versions (e.g W2K vs XP vs Vista). I've also personally played around with switching between different screenshots in tutorials based on OS version.

So, I don't know whether it's such a good idea to just say "Windows NT". I don't think the current "NT 6.1" is nearly as bad as comment #0's "Linux 2.4.0-test9-pre1" (to match "NT 6.1", I supposed it'd be best to turn that into something like "Linux 2.4-pre").

On the other hand, that makes it easier to do things like create a z-index'd div that looks like, say, a Windows Update dialog.

Also, an alternative to the current URL in case it's ever down: http://browserspy.dk/useragent.php (from Henrik Gemal)
Comment 69 Chimel 2010-05-18 01:07:27 PDT
RFC 2068 makes it clear that the current amount of personal data in User-Agent goes way beyond the specs for this entity, OS and browser versions should be enough for web servers, or at least, an option to configure UA with limited data:

14.42 User-Agent

   The User-Agent request-header field contains information about the
   user agent originating the request. This is for statistical purposes,
   the tracing of protocol violations, and automated recognition of user
   agents for the sake of tailoring responses to avoid particular user
   agent limitations. User agents SHOULD include this field with
   requests. The field can contain multiple product tokens (section 3.8)
   and comments identifying the agent and any subproducts which form a
   significant part of the user agent. By convention, the product tokens
   are listed in order of their significance for identifying the
   application.

          User-Agent     = "User-Agent" ":" 1*( product | comment )

   Example:

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Mine is junk: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB7.0
Comment 70 obsolete.fax 2010-05-18 15:23:09 PDT
http://www.theregister.co.uk/2010/05/17/browser_fingerprint/

ran test on http://panopticlick.eff.org/ to find out my browser leaves a unique fingerprint in 900,000+ samples they have received so far.
Comment 71 obsolete.fax 2010-05-19 10:38:45 PDT
Can this 10 year old bug be fixed before (or for) Firefox 4 release?
Comment 72 obsolete.fax 2010-05-19 10:42:04 PDT
Patch is there in Bug 55366.

https://bugzilla.mozilla.org/show_bug.cgi?id=55366
Comment 73 Tony Mechelynck [:tonymec] 2010-05-22 08:53:35 PDT
In reply to comment #68: Linux versions were maybe there in 2000, they aren't anymore, as shown e.g. by my UA,

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100510 SeaMonkey/2.1a1pre
Comment 74 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-05-24 13:00:48 PDT
Definitely not going to block stable-branch releases on any changes here. We might take this for 1.9.3 (Firefox 4), but I really don't think it's a blocker, given that the fingerprint data here is pretty small.
Comment 75 Ben Bucksch (:BenB) 2010-05-24 13:09:10 PDT
> We might take this for 1.9.3 (Firefox 4)

Thanks. When I have a chance, I'll update and drive the patch.
Comment 76 gionnico 2010-06-24 18:20:53 PDT
(In reply to comment #6)
> > most sites just look for Windows or Mac and then give up. =/
> 
> LOL!
> 
> I would like to fix this bug - it's trivial. Taking it. shaver, hope you don't mind.
> 
> Bug 55366 is about dropping the language as well.
> 
> I can see the usefulness of the machine type (i.e. "uname -sm", e.g. "Linux
> i686"), but don't see, how that would be harmful. Any objections to keep that?

Objection: it is 1 bit more gave away for fingerprinting.
https://panopticlick.eff.org

Try this: I WAS NOT ABLE TO HAVE A NON-UNIQUE ID.
Not even with official en-us 3.6.4 release.

Not even disabling the "default plugin manager" that is exposed and is far less common than "no plugins" at all.
Comment 77 Dave Webber 2010-06-24 21:42:24 PDT
(In reply to comment #76)
> Objection: it is 1 bit more gave away for fingerprinting.
> https://panopticlick.eff.org
> 
> Try this: I WAS NOT ABLE TO HAVE A NON-UNIQUE ID.
> Not even with official en-us 3.6.4 release.
> 
> Not even disabling the "default plugin manager" that is exposed and is far less
> common than "no plugins" at all.

Mind you, the Panopticlick experiment was started several months, and I believe a majority of its current statistics (as of writing) arrived a few Firefox releases ago. Just having 3.6.4 is enough to make your configuration rare in their data. Try an official Firefox release which was popular between late January and early May, on (or at least while reporting) a stable platform release which was popular at the time that said Firefox release was popular. Since I have NoScript installed, and didn't allow Panopticlick to use JS, the majority of my entropy came from preferring Canadian English (which provides 2.4 bits over just English) and UTF-8, followed by running the latest official Firefox (1.6 to 2.3 bits of which -- depending on which stat you believe -- comes from using any version of Firefox) and using Mac OS X.6 (2.4 bits of which comes from using a non-Windows platform). While using NoScript mitigates exposure of information about my plug-ins, time-zone, monitor, and fonts, the unavailability of JS provides about 4.7 bits of entropy (which I suspect is less than in the wild web, as Pantopticlick's statistics may well be selection-biased towards NoScript users to some non-trivial extent). 

If you want a less fingerprinting-conducive UA-string, you'll likely need it to report an recent but slightly outdated version of Windows. If a typical Firefox user (who mightn't know what an operating system is, never mind which version of which one they are running) is going to benefit from getthunderbird.com picking out the correct download link for them, then they'll need their browser to disclose at least their CPU architecture and their OS and its major version, as well as their (most-) preferred language. If a.m.o is going to know beforehand whether a particular extension is compatible for their version of Firefox, it'll need to their minor version of Firefox. One related note (although beside the topic of UA-strings), if Wikipedia is going to automatically provide articles in the correct language, it too will need to know their language preference.

So, this all seems to me to beg some questions: How much information can be removed from the UA-string (and its relatives, such as HTTP Accept) before user experience is degraded by the reduction of information? How could the further reduction of information be facilitated for privacy-conscious users, or privacy-related extensions? How could information be further reduced for sites which either untrusted or without a user-serving use of it? At what point does the absence of specifics become more informative than their presence? 

Perhaps this information is flowing in the wrong direction. To what extent could the flow be reversed? For example, what would be required to have the browser pick the best combination of CPU architecture, OS version, browser version, language, (etc) as applicable, out of the options listed by a server offering the content which varies in one or more of those criteria, such that the server can only infer what information is relevant to content choice at hand (which would be implicit in the choice of content regardless of whether the user or browser made the selection)?
Comment 78 gionnico 2010-06-25 06:22:19 PDT
I don't think that saying windows in UA when I use linux is a good idea.

I'm pretty sure there are other ways to find out my os.
And if they find out I have windows in useragent but I really use linux..
That's VERY unique.

Also you shouldn't say the project is young.
Because websites have also something like ip address location and type to restrict the researches.
Comment 79 obsolete.fax 2010-06-25 15:33:41 PDT
Why Does a Website need information on which OS I am running?

Yes it could be useful for pointing to the correct Download files, for example .exe in Windows, or .deb for Ubuntu etc.

But this is a rarity. 99% of the websites don't need this information.
Comment 80 Ben Bucksch (:BenB) 2010-06-25 23:47:21 PDT
See above.
Please avoid comments.
Comment 81 Ben Bucksch (:BenB) 2010-07-25 14:03:59 PDT
comment 0 says:
> Actual Results:  Mozilla/5.0 (X11; U; Linux 2.4.0-test9-pre1 i686; en-US; m18)
> Gecko/20001019

> Expected Results:  Mozilla/5.0 (X11; U; Linux i686; en-US; m18) Gecko/20001019
> or
> Mozilla/5.0 (X11; U; Linux; en-US; m18) Gecko/20001019

We're in pretty good shape already, we're very close to the (first) Expected Result.

We currently have:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100715 Firefox/3.6.8
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko/20100715 Firefox/3.6.8
any in Gecko 1.9.3/FF 4.0 even, to my knowledge:
Mozilla/5.0 (X11; Linux i686; rv:1.9.2) Gecko/20100715 Firefox/3.6.8
Mozilla/5.0 (Windows; Windows NT 6.0; rv:1.9.2) Gecko/20100715 Firefox/3.6.8

The Gecko version is still useless and a bit problematic, it would be better to make it the m-c checkout date or branching date, that would be more useful for Gecko feature support and protect custom builds better, but that should be a separate bug, as it's mostly about build system.

> Why Does a Website need information on which OS I am running?
> Yes it could be useful for pointing to the correct Download files

Actually, given that we did remove off a lot of values in 1.9.3, I think it would be good to revisit this question, and maybe alternative solutions to the download problem, but I think it's better to discuss on newsgroups.
Comment 82 Ben Bucksch (:BenB) 2010-07-25 16:56:57 PDT
> and in Gecko 1.9.3/FF 4.0 even:

Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100725 Minefield/4.0b3pre
Comment 83 Ben Bucksch (:BenB) 2010-07-26 08:28:02 PDT
> The Gecko version ... should be a separate bug

bug 572661 and bug 572659
Comment 84 dwitte@gmail.com 2010-08-19 11:08:28 PDT
I'm going to mark this FIXED (and in doing so somewhat shirk etiquette; sorry). We have a tracking bug, bug 572650, for reducing entropy; and bug 586165 for making changes for Firefox 4. Any further discussion here needs to be about specific changes, for which we already have bugs on file (see dependencies on bug 586165) or should get new bugs filed.
Comment 85 Cesar Eduardo Barros 2010-08-19 16:27:59 PDT
(In reply to comment #84)
> I'm going to mark this FIXED (and in doing so somewhat shirk etiquette; sorry).
> We have a tracking bug, bug 572650, for reducing entropy; and bug 586165 for
> making changes for Firefox 4. Any further discussion here needs to be about
> specific changes, for which we already have bugs on file (see dependencies on
> bug 586165) or should get new bugs filed.

As the original reporter, I agree with marking this RESOLVED/FIXED and moving the remaining discussion to the dependency tree of these two bugs.

Note You need to log in before you can comment on or make changes to this bug.