Closed Bug 414057 Opened 17 years ago Closed 14 years ago

Remove OS X system version from the user agent

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: stuart.morgan+bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

remove OS X version
1.44 KB, patch
mark
: review+
sayrer
: superreview-
Details | Diff | Splinter Review
I apologize for filing this as a new bug rather than weighing in at the time, but I only just noticed the change from bug 400089. I'd like to see the system version backed out. There was a lot of discussion about whether is was or was not a security problem, but I see almost no discussion of why we *should* have it, and "there's no reason not to" is the wrong way to make decisions about something that there is pretty much universal agreement is already overly bloated and messy. The purpose of the UA is to identify the browser, and the only argument *for* adding the system version that I see (bug 400089 comment 6) was entirely unrelated to that. I agree that the information is potentially interesting to people who write client-side software, but that's not what the UA is there for. I could make equivalent arguments about number of cores, processor speed, memory, graphics card, etc., but that doesn't mean they should go in the UA. If we believe there should be a way for authors to get that kind of information, then that should be explored as a new feature of some kind; we shouldn't solve the problem by re-purposing the UA as a software market research tool.
It's also very biased toward our own personal view of the world to favor client software developers in this way. A parallel argument to bug 400089 comment 6 exists for anyone selling memory, processor upgrades, laptop bags, external devices that require specific ports, and just about any other hardware that's designed for certain machines or types of machines. Why are we using the UA to solve a problem for the sites of software developers but not an equally valid problem for the sites of hardware vendors?
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #300603 - Flags: review?(mark)
Comment on attachment 300603 [details] [diff] [review] remove OS X version Technically correct without prejudice to policy issues, just like last time.
Attachment #300603 - Flags: review?(mark) → review+
CCing a bunch of folks from that other bug. Windows major versions are displayed by Opera, IE, and Gecko versions - why should mac be different? Is the specific concern here security?
The security argument sounds bogus to me. Security through obscurity? > If we believe there should be a way for authors to get that kind of > information, then that should be explored as a new feature of some kind; we > shouldn't solve the problem by re-purposing the UA as a software market > research tool. That sounds pretty dogmatic to me. I don't see anything wrong with re-purposing the UA that way. If there's a way for sites to help users by inspecting Safari UA versions, we should evaluate whether such inspection would help our users. Every bit counts, though, so I agree we should watch out for header bloat.
No version of OS X to see: Opera: Opera/9.50 (Macintosh; Intel Mac OS X; U; en) iCab: iCab/4.0 (Macintosh; U; Intel Mac OS X) Safari 3.04: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/523.10.6 (KHTML, like Gecko) Version/3.0.4 Safari/523.10.6 IE Mac: Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC) Omniweb: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/522+ (KHTML, like Gecko, Safari/522) OmniWeb/v614.0.94258
(In reply to comment #4) > Windows major versions are displayed by Opera, IE, and Gecko versions - why > should mac be different? OS X versions are not displayed by any other browser on OS X. Why should Gecko be different? We can play the "everyone else is doing it" game either way. > Is the specific concern here security? No, it's not; I tried to be clear about that, but apparently failed. I explicitly did not want to re-hash the discussion from the other bug. My objection is that there I don't believe there has been a compelling reason given to add it, and we shouldn't add unnecessary strings to the UA. The UA in question is exactly the same bits, whether it's running on 10.5 or 10.4. It's the same UA. (In reply to comment #5) > That sounds pretty dogmatic to me. Your negative characterization of my view that the UA string should be to identify the UA is noted, but I don't see that it helps advance the discussion in any meaningful way. > If there's a way for sites to help users by inspecting Safari > UA versions There isn't, as has been explained in the other bug. There is no longer a one-to-one correspondence between Safari version and OS version.
Also, if the philosophical argument that we shouldn't be adding unneeded cruft to the UA string isn't sufficient (which greatly surprises me, given that I and the other Camino developers were publicly raked over the coals forward and backward for the crime of wanting to add text to the UA string *to fix demonstrated problems with sites doing UA detection*), here's a technical argument (courtesy of David Baron, bug 384721 comment 16): "From a technical perspective, this is clearly the wrong solution. It adds yet more bytes to the user-agent header that all Gecko apps must ship; that has a real cost in bandwidth (especially at the point where the headers end up needing an extra packet)." And this time the comment about "all Gecko apps" is correct.
(In reply to comment #7) > (In reply to comment #5) > > That sounds pretty dogmatic to me. > > Your negative characterization of my view that the UA string should be to > identify the UA is noted, but I don't see that it helps advance the discussion > in any meaningful way. It's pretty simple. I want to know if there are practical or ethical problems with sending the OS version (or not). I'm not aware of common UA-string religion we all adhere to, so "philosophical" objections don't really rate. > > > If there's a way for sites to help users by inspecting Safari > > UA versions > > There isn't, as has been explained in the other bug. There is no longer a > one-to-one correspondence between Safari version and OS version. I see bug 400089 comment 36. That shows different UA strings for Safari. Can someone show Safari producing identical UA strings across OS versions? > if the philosophical argument that we shouldn't be adding unneeded cruft > to the UA string isn't sufficient It's not. > "that has a real cost in bandwidth" Yes! That's a practical concern. We don't want to send junk that isn't useful, but we also want to make sure we have all the facts right. I would like to know whether Safari does indeed produce identical UA strings across OS versions.
I stand corrected; it is currently not the case that the WebKit versions are identical across OS releases according to Apple's listing. However, I'm still not clear on why it matters for the purposes of making this decision whether it's possible to reverse-engineer similar information from Safari as a byproduct of Apple's build system. Those are builds of WebKit that are not, in fact, identical, and thus don't have identical versions. The same is not true of the same build of Gecko running on different OS versions. Also, it's possible to determine, within some range (that may or may not be greater than one, depending on WebKit release frequency, but has historically been very close to one) the bugfix version of the OS. Does that mean we must, by the "Safari does it" argument, expose the bugfix version? If not, why not? After all, it's already the case that a great deal of software is compatible with 10.3.9 but not 10.3.8 or earlier (and there's no guarantee that something similar won't happen again), so the value-add argument for the user still applies. > It's not. Okay, so what criteria do we use? I can, as I have said, give equally compelling arguments as the ones given for the OS version to expose a variety of non-security-sensitive hardware information in the UA, which would allow certain types of sites to make significant usability improvements for their users. Shall we toss them all in?
(In reply to comment #10) > > However, I'm still not clear on why it matters for the purposes of making this > decision whether it's possible to reverse-engineer similar information from > Safari as a byproduct of Apple's build system. This implies the difference is unintentional--you don't know that. > Those are builds of WebKit that > are not, in fact, identical, and thus don't have identical versions. The same > is not true of the same build of Gecko running on different OS versions. Gecko has runtime switches for different OS versions. This point also assumes some sort of versioning religion we do not share. > Also, it's possible to determine, within some range (that may or may not be > greater than one, depending on WebKit release frequency, but has historically > been very close to one) the bugfix version of the OS. Does that mean we must, > by the "Safari does it" argument, expose the bugfix version? No, the original aim was to allow sites to distinguish Leopard from Tiger. Seems reasonable to me. For example, I would really want that if I operated apple.com. YMMV. > > > It's not. > > Okay, so what criteria do we use? I can, as I have said, give equally > compelling arguments I don't think they were equally compelling. You mentioned laptop bags? Best way to deal with this is to figure out if header bloat is hurting us, or we are getting close to that situation. Without that kind of data, we're making decisions based on relatively unimportant disagreements.
(In reply to comment #11) > No, the original aim was to allow sites to distinguish Leopard from Tiger. That states the aim in terms of the current behavior, making the justification a tautology; let's discuss actual benefit. Why is it important for sites to be able to distinguish the major OS version but not the minor revision, when--as I explained in the part of my post that you chose not to quote--that information has historically been equally important for OS X software developers deciding about future support and offering correct downloads (which was the originally stated rationale for the addition of the major version)? > I don't think they were equally compelling. You mentioned laptop bags? I mentioned several things, and you deliberately chose the least interesting. Here's a longer list: - Software developers who have minimum processor (e.g., G4+), processor speed, graphics card (reasonably well correlated with model), screen size (correlated for everything but Mac Pros) and to some extent memory (roughly correlated) for their software--common in both professional software and games - Software developers who want to know the above for future planning - Anyone selling anything with USB2, Firewire 400, or Firewire 800 connections, only some of which are available on any given model. - Anyone selling RAM (users currently have to go through a series of menus that's much more complicated that picking the correct one of two links on a software download page) - Anyone selling anything that has different variants for desktop and laptop use (e.g., some external drives are self-powered, others need a power brick, and the difference is often very important to laptop users) - Anyone selling an audio input device, as the audio-in port varies from machine to machine - Anyone selling anything targeting laptops (or specific laptops): bags, stands, docking solutions You'll notice that the first two are exactly the same group, for exactly the same purpose, as the OS version. Certainly that need is less common, but it's by no means rare. And since the hardware argument covers a huge swath of the hardware market, taken together that's a lot of people benefiting from it--arguably more than the OS version.
Might I also point out that putting more information in the UA string will simply give ill-mannered Web designers -- of which bug 334967 demonstrates there are a tremendously large number -- many MORE improper reasons to exclude certain browsers from a Web site. The UA string needs *less* information in it, not more. See also bug 334967 comment 13, which I really don't feel like repeating here.
Comment on attachment 300603 [details] [diff] [review] remove OS X version Requesting sr, since I think the above discussion boils down to a difference in opinion and could go around indefinitely without getting anywhere, and it's ultimately not the opinion of sayrer and myself that matters.
Attachment #300603 - Flags: superreview?(cbiesinger)
(In reply to comment #13) > Might I also point out that putting more information in the UA string will > simply give ill-mannered Web designers -- of which bug 334967 demonstrates > there are a tremendously large number -- many MORE improper reasons to exclude > certain browsers from a Web site. Let's not try to make this about something it's not. Bug 334967 doesn't suggest that OS version would ever actually be used in that way, any more than "MachO" was.
(In reply to comment #11) > Best way to deal with this is to figure out if header bloat is hurting us, or > we are getting close to that situation. Without that kind of data, we're making > decisions based on relatively unimportant disagreements. I don't see how it's possible to get the data you want. The UA string varies in length due to things like browser name, Gecko revision number, and, more significantly, the arbitrary vendor tags that can be added (e.g., some of the Linux distros choose to badge the UA string IIRC). Then there are headers like accept-language, which have essentially arbitrary length that varies by individual user. How can we evaluate the boundary effect across all current Gecko products and distributions (and heck, future too, since as we well know once we put something in the UA string and sites use it, it's pretty much impossible to get it removed), and across all users? And without the ability to get that data, that question comes down to whether one believes that I should have to make the impossible proof that there is a cost, or you should have to make the impossible proof that there isn't, and it's just a difference of opinion again.
There's no data-based proof of header bloat hurting. Instead we have an eternal struggle to keep things out of headers including the UA, because it was not the last cookie I ate that made me fat. It could be that Mac OS X is different, and system version in UA pays for itself in some high-level, qualitative way that can't be traded off, apples to oranges, against the incremental header bloat. But I don't see it. /be
This bug is a royal waste of time.
I really should do other things, but I think I'll take a special detour to point out how terrible this argument is: (In reply to comment #12) > (In reply to comment #11) > > No, the original aim was to allow sites to distinguish Leopard from Tiger. > > That states the aim in terms of the current behavior, making the justification > a tautology; let's discuss actual benefit. Why is it important for sites to be > able to distinguish the major OS version but not the minor revision, when--as > I explained First, write less. Life is short. Maybe we want to distinguish minor versions as well. That's quite a bit different than turning it off. > > I don't think they were equally compelling. You mentioned laptop bags? > > I mentioned several things, and you deliberately chose the least interesting. You listed several things that are all uninteresting. I picked one. > Here's a longer list: > - Software developers who have minimum processor (e.g., G4+), processor speed, > graphics card (reasonably well correlated with model), screen size (correlated > for everything but Mac Pros) and to some extent memory (roughly correlated) for > their software--common in both professional software and games We can help them a little more with JS stuff, seems obvious we can't fit it all in the UA. > - Software developers who want to know the above for future planning Don't see the difference. > - Anyone selling anything with USB2, Firewire 400, or Firewire 800 connections, > only some of which are available on any given model. Now you're stretching... > - Anyone selling RAM (users currently have to go through a series of menus > that's much more complicated that picking the correct one of two links on a > software download page) ... more stretching... > - Anyone selling anything that has different variants for desktop and laptop > use (e.g., some external drives are self-powered, others need a power brick, > and the difference is often very important to laptop users) > - Anyone selling an audio input device, as the audio-in port varies from > machine to machine > - Anyone selling anything targeting laptops (or specific laptops): bags, > stands, docking solutions Look, we don't need to provide everything we know about the computer because we provide something. Don't waste people's time with a bogus argument.
(In reply to comment #14) > (From update of attachment 300603 [details] [diff] [review]) > Requesting sr, since I think the above discussion boils down to a difference in > opinion and could go around indefinitely without getting anywhere You think it boils down to a difference of opinion because you don't care enough to get data. I want data, because I actually do care what the best thing for our users is. Get out a protocol analyzer and get off the soapbox.
Flags: blocking1.9? → blocking1.9-
I explained why the data you want is impossible to get. If you disagree, feel free to explain a methodology for collecting it. As for the various personal attacks, I'm not interesting in turning this bug into a mud-slinging contest. I leave it to the module owner to make a decision to either sr+ or WONTFIX this.
(In reply to comment #21) > I explained why the data you want is impossible to get. If you disagree, feel > free to explain a methodology for collecting it. You didn't explain why a protocol analyzer would be impossible to use. You explained why it would be a little bit of work, and that any solution probably won't be perfect, because the headers can get long. I'm suggesting doing some work. Sorry about that.
(In reply to comment #22) > You didn't explain why a protocol analyzer would be impossible to use. You > explained why it would be a little bit of work, and that any solution probably > won't be perfect, because the headers can get long. Apparently I misunderstood the data you wanted. I thought the question was whether or not the extra characters would actually cause an extra packet to be sent, and thus have a real cost. Since the header is of variable length, no amount of protocol analyzing will give us that information for actual use. So what is the concrete information you want in order to make an entirely data-driven decision?
> So what is the concrete information you want in order to make an entirely > data-driven decision? - What other browsers send - What we send - The share of header data that would be squatted by our newly-added MacOS version stuff Possible courses of action that follow: - Others browsers way smaller: find out why - Makes no material difference - Are we sending enough data? - Can we send the same data and more in fewer bits? - Adding this information adds too many bits Camino/Fx3 headers because _______
That comes down to the cookie argument of comment 17. I don't think that's the right way to make decisions about the UA string, and I'm clearly not alone in that, so I'm not going to do an investigation at this point based solely on your opinion that it is. That's cbiesinger's call.
(In reply to comment #25) > That comes down to the cookie argument of comment 17. I don't think that's the > right way to make decisions about the UA string, and I'm clearly not alone in > that, so I'm not going to do an investigation at this point based solely on > your opinion that it is. That's cbiesinger's call. >
Comment on attachment 300603 [details] [diff] [review] remove OS X version passing sr request to brendan, because I can't get myself to care either way about this bug
Attachment #300603 - Flags: superreview?(cbiesinger) → superreview?(brendan)
(In reply to comment #25) > That comes down to the cookie argument of comment 17. I don't see how. > I don't think that's the > right way to make decisions about the UA string, and I'm clearly not alone in > that, so I'm not going to do an investigation at this point based solely on > your opinion that it is. Uh oh, work. Run away!
Apparently I need to be more blunt than I was in comment 21: Robert, if you find yourself unable to contribute to this bug without personally attacks, then un-CC yourself. I'm sure you know where to find the bugzilla etiquette guide, so I'll spare you the link.
(In reply to comment #29) > Apparently I need to be more blunt than I was in comment 21: Robert, if you > find yourself unable to contribute to this bug without personally attacks, then > un-CC yourself. Hi. Stop whining. There's nothing too rough in this bug. You typed too much on a small issue, you won't get data, and you're playing process games. Don't do those things.
(In reply to comment #30) > you won't get data Roughly 1-1.5% increase in header size. Is it worth it? Guess what, that's an opinion call.
He's not asking if it's worth it, he's asking if it matters. Are we taking up an additional packet because of it? If yes, that'd be a good reason to drop it. If not, it doesn't really matter. But, I'm pretty sure that point was already made in this bug...
(In reply to comment #32) > Are we taking up an additional packet because of it? See comments 16 and 23.
Comment on attachment 300603 [details] [diff] [review] remove OS X version Platform parity uber alles. Plus, I'm tired of this bug too. /be
Attachment #300603 - Flags: superreview?(brendan) → superreview+
I'm glad we've resolved this, so that Firefox users are no longer presented with software that works on their computers. The power of open source is amazing. Great job, everyone.
We specify windows versions in the UA, is there a different argument or use case in windows vs mac? Please feel free to point me to an explanation rather than starting a new discussion in the bug if it's not relevant.
Comment on attachment 300603 [details] [diff] [review] remove OS X version I somehow misread the comments reporting the fact that Windows UA has OS major version info. For better sr+ I'm delegating to sayrer. /be
Attachment #300603 - Flags: superreview+ → superreview?(sayrer)
Attachment #300603 - Flags: superreview?(sayrer) → superreview-
Comment on attachment 300603 [details] [diff] [review] remove OS X version No more thrashing the UA without good reason. I know we've done it in the past, but two wrongs don't make a right. We should patch the software in ways that solves problems for users. Colin's change did solve a problem, but perhaps at too high a cost. Prove it.
For what it's worth (and I'm guessing that's very little), Mozilla's Linux/Unix/BSD/etc. user-agents don't include a kernel version, or a window-toolkit version, or anything else that could reasonably be construed as an "OS version", as far as I can tell from reading bugs and lists of user-agent strings. (The Linux kernel version was removed in bug 57555 way back in 2001). There's simply an OS name and a CPU. The Mac user-agent string never included this information (from Mac OS 8 on up through Mac OS X until bug 400089 late last year), and as philippe noted in comment 6, no other Mac browser does it currently. If the aim here is platform consistency--and that seemed to be one of the major concerns here, especially for Brendan and Lucy, depending on what we mean by the "platform", of course--Windows seems the odd OS out. Either: a) To be consistent with the rest of the "Mac platform", Gecko apps shouldn't display the OS version. b) To be consistent with the "Gecko platform", either all the rest of the UNIX-like OSes need to start displaying a kernel/Gnome/BSD/etc. version, or Windows should stop displaying an OS version (and the Mac should revert to pre-400089 behavior). WRT to Windows, bug 57555 comment 29 appears to have included a proposal to genericize the Windows Oscpu to remove specific version numbers.
Flags: blocking1.9- → blocking1.9?
Bleh, I had a non-shift-reloaded page that still had the blocking? flag showing :/
Flags: blocking1.9?
(In reply to comment #38) > perhaps at too high a cost. Prove it. It's clearly impossible to "prove" that the cost is "too high" when you wont acknowledge that there is any opinion or value judgement involved in evaluating what "too high" means. So, ->WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
(In reply to comment #41) > (In reply to comment #38) > > perhaps at too high a cost. Prove it. > > It's clearly impossible to "prove" that the cost is "too high" when you wont > acknowledge that there is any opinion or value judgement involved in evaluating > what "too high" means. There is definitely a value judgement. I'm not asking for a mathematical proof here, but I think you know that. I agree this could be a real bug, and the inconsistency pointed out in comment 39 could be a real problem. Is the best course of action to back ou bug 400089? I don't see a rationale for that.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
No, I really have no idea what it is that you are asking for. You said you wanted data, but you ignored it when I provided it. When I said this bug came down to a matter of opinion (aka, value judgement) about whether it was worth the cost, you said that I was just lazy, but now you apparently agree. And now you want proof of a value judgement, and I can't imagine what that means. I don't know what will satisfy you, and I'm tired of being insulted while trying to figure it out. So congratulations, your strategy of being rude for no apparent reason paid off: you win. Do what you like with this bug.
Assignee: stuart.morgan → sayrer
Status: REOPENED → NEW
Assignee: sayrer → nobody
Windows is the odd one out, but it's also the majority of users. Linux is so fractioned and is very much build your own, that unless someone is using a major distro, it's not going to make much difference. Though maybe that's the appropriate course of action as well. From a support point of view, it's *great* having that info in the string.
(In reply to comment #43) > No, I really have no idea what it is that you are asking for. You said you > wanted data, but you ignored it when I provided it. percentages are really hard to deal with. Let me give you an example. Circumcising male babies was recommended my medical organizations for decades because it decreased a boy's chance of having recurrent UTIs by 10%. Sounds great right? Until you factor in that only 2% of boys would have recurrent UTIs, and recurrent isn't necessarily very often, and it was only during early childhood anyway. As a girl who had recurrent UTIs I'd definitely choose antibiotics over having something cut off at birth. Fortunately for me that was only an option for boys. How many people is this really a win for, how big of a win is it, and what are the benefits of leaving the UA intact?
(In reply to comment #39) > For what it's worth (and I'm guessing that's very little), Mozilla's > Linux/Unix/BSD/etc. user-agents don't include a kernel version, or a > window-toolkit version, or anything else that could reasonably be construed as > an "OS version" Well, that's a more complicated situation: most linux users run their distros' builds (not ours), and the diversity/modularity of the platform means that just the raw kernel version doesn't tell you much. In any case, the Firefox included with my Ubuntu install does include "Ubuntu/7.10 (gutsy)" in the user agent. [sorry for interrupting the drama. :-)]
RESOLVED: WTF?!
(In reply to comment #45) > How many people is this really a win for, how big of a win is it, and what are > the benefits of leaving the UA intact? I'm curious to know "how many" sites are doing sniffing for Safari (as noted in the other bug, in the past you could trivially coerce a Safari version to an OS version, since prior to Safari 3 new Safaris only ran on one major OS version); app vendors wanting to be able to sniff Gecko in addition to Safari to offer custom content seemed to be the major impetus for bug 400089. It's well past my bedtime, but I did a quick pass of a handful of indie Mac developers, Mac-only outfits, and indie-like Mac OSS projects, many of which currently are offering software only for 10.4 and up or 10.5 and up (er, I guess Acorn ended up running on 10.4 after all). http://www.omnigroup.com/applications/omniweb/ (10.4+) http://www.panic.com/coda/ (10.4+) http://www.flyingmeat.com/acorn/ (10.4.9+) http://www.red-sweater.com/marsedit/ (10.4+) http://colloquy.info/downloads.html (10.3.9+) http://adiumx.com/ (10.4+, 10.3.9, 10.2) In the first 5 cases, I navigated from the home page to the product/download page, checking to see what messages I might be shown. I got identical content in Camino, Safari 1.3.2 (10.3.9), and Camino-spoofing-as-Safari-2-(10.4). Only in the last case, Colin's Adium, did the content change; Safari 1.3.2 got offered a link to the last old Adium that runs on 10.3.9 and a note that if I was on 10.4, I should use the new version instead; Camino and Spoofing-as-Safari-2 just got the link to the latest version. (But note that the page *also* includes static content describing/linking the Adium you want for 10.2, 10.3.9, and 10.4+, slightly below the customized content.) This is neither complete nor representative, but 4 out of the 6 sites don't offer software that runs on the version of Mac OS X this Mac is running, and they didn't feel the need to display special content to me. Only 1 of the 6 sites took advantage of coercing Safari version to offer me an old (unsupported?) version of the project's app. (In reply to comment #46) > In any case, the Firefox included with my Ubuntu install does include > "Ubuntu/7.10 (gutsy)" in the user agent. In that case, though, it's a vendor comment added by a distro, rather than hard-wired by Gecko, which is not exactly the same as this discussion.
(In reply to comment #48) > Only in the last case, Colin's Adium, did the content change... > >...This is neither complete nor representative This assertion is both insulting and ridiculous. Ridiculous because of the obvious admission by Smokey that his "research" shows nothing and isn't even close to data, just handwaving to attempt to make his point, but moreover insulting because of the suggestion that I would somehow advocate a change to our user-agent for some sort of sinister ulterior motive ("Big Adium has control of the User Agent! Oh my!"), rather than the best interests of Gecko users. I filed the bug because a number of other people asked me to (not just the person who maintains the Adium website), *and* because I thought it would be useful and helpful to web developers everywhere. Keep your conspiracy theories to yourself, kindly. Apple has a document on their website talking about how to correlate version of Webkit to versions of Mac OS X. I don't see any reason why Apple would put that document up there if there wasn't at least some demand, perceived or otherwise. If that isn't argument enough that people are using the Webkit version to distinguish between OSes for Webkit based browsers, I don't know what is. I was going to remain quiet on this bug but when someone posts what I see as a personal attack against me in Bugzilla, I feel I need to at least respond somewhat. Can we just close this bug already?
(In reply to comment #49) > insulting because of the suggestion that I would somehow advocate a change to > our user-agent for some sort of sinister ulterior motive ("Big Adium has > control of the User Agent! Oh my!"), rather than the best interests of Gecko Colin, that was certainly not my intention, and I apologize to you and to everyone else that what I wrote was able to be construed that way. I only meant to indicate that you were very familiar with at least one site that does coerce the Safari version to display different content to users. As I mentioned in my comment, it was many hours after my usual bed-time, and I probably shouldn't have posted in Bugzilla at the time. > (In reply to comment #48) > >...This is neither complete nor representative > > This assertion is both insulting and ridiculous. Ridiculous because of the > obvious admission by Smokey that his "research" shows nothing and isn't even > close to data, just handwaving to attempt to make his point, Because of the unfortunate tendency in certain bugs to assume that anything posted is "complete and accurate" research, I was being clear from the start that I had, again due partly to the late hour, only looked at a few sites that sprang to mind and *was not* trying to portray this as complete or representative data. What I found on those sites was interesting (to me), but far from large enough of a sample size to draw any useful conclusions. Again, maybe I should have waited until I had more time to look at more sites and post more representative data, but, as I do when working with "bug" bugs, I like to get any preliminary data into the bug where others can work with it, instead of keeping it in my head/on my Mac, where only I can do anything with it.
(In reply to comment #50) > (In reply to comment #49) > > insulting because of the suggestion that I would somehow advocate a change to > > our user-agent for some sort of sinister ulterior motive ("Big Adium has > > control of the User Agent! Oh my!"), rather than the best interests of Gecko > > Colin, that was certainly not my intention, and I apologize to you and to > everyone else that what I wrote was able to be construed that way. I only meant > to indicate that you were very familiar with at least one site that does coerce > the Safari version to display different content to users. As I mentioned in my > comment, it was many hours after my usual bed-time, and I probably shouldn't > have posted in Bugzilla at the time. It's OK -- text is an imperfect medium. Thank you for your apology, I'm glad this was just a miscommunication. :)
I would like to add that as a Gecko user I want to see the version number removed. I also want to see the PPC/Intel distinction removed. In fact, I would be happy with just: "Firefox/3.0" as a UA string. One idea the original patch poster alluded to is that of including something like a User-System header that would contain "Macintosh/10.5.2" IMHO there's no need for RAM, screen size, disk space, or any other information.
(In reply to comment #9) > I see bug 400089 comment 36. That shows different UA strings for Safari. Can > someone show Safari producing identical UA strings across OS versions? http://bugs.webkit.org/show_bug.cgi?id=18295#c1 Here's my Safari UA: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13 My version is in there, and that's official. But, the reason they did it was to prevent the "4" bug, where apparently many servers sniff 4 and think that netscape 4 or ie 4 is loading the page, so they're using understrikes. I could understand if we used understrikes as well.
Its a shame any older sniffers were trying to look for specific product/version numbers. Its only got us into trouble with wanting Netscape or IE4-IE7 only browsers for their websites and the fact that quirks modes only made it worse.
If this patch has been decided, by the powers that be, to be unwanted (and I'm assuming sr- means it indeed has), then those powers should WONTFIX this bug. The patch was not given sr- for any valid technical reason that I can tell.
Agree with sayrer. This provides useful info, costs five bytes, and is not a significant source of entropy.
Status: NEW → RESOLVED
Closed: 17 years ago → 14 years ago
Resolution: --- → WONTFIX
Blocks: 586165
(In reply to comment #35) > I'm glad we've resolved this, so that Firefox users are no longer presented > with software that works on their computers. The power of open source is > amazing. Great job, everyone. I'm really glad you fought so hard to keep this in the UA so that bug 643872 never happened. It's heartwarming that Mozilla cares so much about this. The power of open source is indeed amazing.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: