Closed Bug 57555 Opened 24 years ago Closed 15 years ago

UA-string is telling sites too much about the system

Categories

(Firefox Build System :: General, enhancement, P3)

Product:
Firefox Build System
Component:
General
Type:
enhancement

Tracking

(blocking2.0 -, status2.0 wanted)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: cesarb, Assigned: BenB)

References

(
URL
)

Details

(Keywords: privacy, Whiteboard: Old patch in bug 55366: https://bugzilla.mozilla.org/attachment.cgi?id=43864)

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 ;-)
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?
over to shaver. So the answere here is probably to do something similar for win32 as well.
Assignee: asa → shaver
Status: UNCONFIRMED → NEW
Ever confirmed: true
'uname -s' seems like it would reveal less information to direct a potential attacker to which security holes your machine might happen to contain.
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. =/
> 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?
.
Assignee: shaver → mozilla
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.
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.
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.
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? :)
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).
.
Assignee: mozilla → ben.bucksch
Summary: Mozilla is telling sites too much about my system → UA-string is telling sites too much about the system
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; }
Keywords: mozilla0.9.1
I run with the same patch. I can check it in. r=dbaron?
Target Milestone: --- → mozilla0.9.1
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.)
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.
alecf, the code is #elif defined (XP_UNIX) || defined (XP_BEOS)
oh! couldn't see that from the patch.. sr=alecf
FWIW r/sr=darin
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
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Evelyn, is this going to affect Netcenter tracking for the Commercial product?
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Fix for Unix/BeOS disicussed above checked into trunk. Thanks for r/sr/a. Leaving bug open for other platforms.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
The URL for HTTP headers no longer works :-(
Target Milestone: mozilla0.9.3 → mozilla1.0
Patch 43864 for bug 55366 will fix the Windows part of this bug (when/if checked in).
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.
Posted proposal to .netlib: <news://news.mozilla.org/3B665A87.8050807@beonex.com>.
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).
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
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.
<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.>
<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.
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.
> 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.
Security through obscurity is a good thing unless it prevents other better forms of security.
>> 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".
> 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.
> 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.
>> 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.
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).
> 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.)
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 130858 has been marked as a duplicate of this bug. ***
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.
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
added self to cc list.
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.
retargeting
Target Milestone: mozilla1.0.1 → Future
Product: Browser → Seamonkey
Keywords: qawanted
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...
(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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 29 is not fixed yet and the reason why this was still open.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
- 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?
Assignee: ben.bucksch → nobody
Status: REOPENED → NEW
Component: General → Build Config
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: doronr → build-config
Hardware: PC → All
Assignee: nobody → ben.bucksch
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)
> 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.)
Status: NEW → ASSIGNED
Whiteboard: Patch in bug 55366
(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.
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!
(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.
> 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.
(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.
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.
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.
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.
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.)
(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.
Blocks: 566423
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)
No longer blocks: 566423
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
Flags: blocking1.9.0.19?
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.
Can this 10 year old bug be fixed before (or for) Firefox 4 release?
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
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Flags: blocking1.9.0.19?
Keywords: checkin-needed, privacy
Target Milestone: Future → ---
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.
blocking1.9.1: ? → ---
blocking1.9.2: ? → ---
blocking2.0: ? → -
status2.0: --- → wanted
Keywords: checkin-needed
> We might take this for 1.9.3 (Firefox 4) Thanks. When I have a chance, I'll update and drive the patch.
(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.
(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)?
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.
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.
See above. Please avoid comments.
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.
Whiteboard: Patch in bug 55366 → Old patch in bug 55366: https://bugzilla.mozilla.org/attachment.cgi?id=43864
> and in Gecko 1.9.3/FF 4.0 even: Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100725 Minefield/4.0b3pre
> The Gecko version ... should be a separate bug bug 572661 and bug 572659
Blocks: 584683
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 15 years ago
Resolution: --- → FIXED
(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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.