Re: finalizing the UA string
Henri Sivonen
> Hey, everyone. We really need to finalize the UA string for Firefox 4. There have been some changes recently to remove useless information and to reduce the Fingerprinting surface area, and those have been good.
It seems to me that there have been two changes to the UA string: removal of the crypto strength token (saved 3 bytes but has no impact on fingerprinting, because the value was a constant) and removal of the UI language.
> But those changes have been piecemeal and breaking UA detection that people have been doing and they have had to make multiple changes over time.
>
> It's probably too late to ask to do this before Beta 3, because that freeze is basically now, but can we make sure that any UA changes are finalized by Beta 4?
It seems to me that some kind of product driver-level decision of what's actually wanted eventually and what part of the eventual goal can be done for Firefox 4 is needed.
Currently, the Gecko build date still keeps updating (taking the date away is probably too disruptive but it could safely be frozen), the Gecko and Firefox versions give more detail than "2.0" and "4.0", nightlies still say "Minefield" as opposed to "Firefox". Furthermore, the OS version (flavor of Windows or major version of Mac OS X) and CPU type (32-bit vs. 64-bit vs. Mac PPC) are still exposed. Thus, there are still a lot of variable bits in the UA string.
FWIW, since the last time this was discussed, I've been using the UA string Mozilla/5.0 (Linux; rv:1.9.3) Gecko/20110101 Firefox/4.0 on my work computer with *no* ill effects with the sites that I happen to use. First I tried getting rid of the Gecko date altogether, but that was too much for Google and Zimbra.
As I understand it, the top reasons not to just go ahead with a UA string like Mozilla/5.0 ($PLATFORM; rv:2.0) Gecko/20101231 Firefox/4.0 (where $PLATFORM is just "Windows", "Mac OS X" or "Linux" without further version or CPU data, 20101231 is a frozen date and 2.0 and 4.0 are version numbers without patch level) are AMO and SUMO.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
timeless
> FWIW, since the last time this was discussed, I've been using the UA string Mozilla/5.0 (Linux; rv:1.9.3) Gecko/20110101 Firefox/4.0 on my work computer with *no* ill effects with the sites that I happen to use. First I tried getting rid of the Gecko date altogether, but that was too much for Google and Zimbra.
>
> As I understand it, the top reasons not to just go ahead with a UA string like Mozilla/5.0 ($PLATFORM; rv:2.0) Gecko/20101231 Firefox/4.0 (where $PLATFORM is just "Windows", "Mac OS X" or "Linux" without further version or CPU data, 20101231 is a frozen date and 2.0 and 4.0 are version numbers without patch level) are AMO and SUMO.
At the very least we know that Flash and other plugin vendors like
knowing the platform so that they can give reasonably good binaries to
users.
Historically we got in trouble for sending versions of Firefox to
computers which didn't support them (the user experience is awful).
That's part of the reason that the OS version is available, to prevent
unhappy customers.
As for the 64bit exposure on Windows, it was added because people
asked for it....
OTOH, no one seems to appreciate that.
I've tried using the MicroB useragent on my mac in certain profiles,
and most things work, but occasionally things get weird. When things
are weird, it doesn't occur to me that this is because of my
useragent, and the sites generally do not provide reasonable alternate
link paths.
If we're willing to rely on some extension which users can use to work
around stupid sites, and a public list of stupid sites, then I'm much
less opposed to removing information from the useragent.
I'm pretty sure I've mentioned this before, but I'll say it again:
I'd like to provide a way for the user to be informed about the case
where a web page includes vary: user-agent, and let the user provide a
different one using e.g. Site properties.
Similarly, I wouldn't cry if site properties told me "This site is
customized based on your cookies" if the header included Vary: Cookie.
Please remember that users don't know what version of an OS they're
running. When I visit people here and ask them what their computer
has, I'm lucky if they can say "Windows". And I'm really lucky if my
family can say "Tiger" which of course is useless to me and vendors
because I don't remember if that's 10.2, 10.3, 10.4, or 10.5, and
generally the Vendors don't say "Tiger" or "Leopard", which means
there's no common language.
The nice thing about computers is that they can speak a common
language, or at least a language which can be deciphered, amongst
themselves.
Neil
>If we're willing to rely on some extension which users can use to work around stupid sites
>
Unfortunately it's not possible for an extension to consistently spoof
UA strings to content on a site-by-site basis yet. (But I'd appreciate
it if anyone did make it possible!)
--
Warning: May contain traces of nuts.
Axel Hecht
As a datapoint, django for example doesn't add the Vary: logic just
because you use a cookie or session, AFAICT.
This seems to be a mis-interpretation of cache-specific flags, to me.
Axel
Henri Sivonen
> Historically we got in trouble for sending versions of Firefox to
> computers which didn't support them (the user experience is awful).
> That's part of the reason that the OS version is available, to prevent
> unhappy customers.
Note that Firefox currently doesn't expose the point release of the OS, but in the past Mac OS X point releases have gotten backports of features so that apps have only worked on an old OS from a certain point release onwards. Likewise, so apps require a particular Service Pack for XP.
My point is that you can always come up with use cases to stuff more and more things in the UA string. It doesn't mean that everything should be there.
> As for the 64bit exposure on Windows, it was added because people
> asked for it....
*Everything* in the UA string is there because someone asked for it at some point. Also, it's possible to come up with at least one use case for everything in the UA string. Even if there's existence proof of a use case, it doesn't follow that the use case should be addressed by exposing data in every HTTP request.
The problem is that the harm from larger sniffing surface (which is a more concrete concern than fingerprinting) and fingerprinting needs to be balanced with the utility of the use cases.
Concrete examples, off the top of my head, of non-fingerprinting badness for large sniffing surface in the UA string:
* Sites that look for "Firefox" but not "Minefield" treating nightlies as "mobile" browsers (because they don't sniff as a known "desktop" browser)--making nightly behavior less representative of subsequent release build behavior for testing. (Could be fixed with absolutely no risk to release build behavior, since releases say "Firefox" anyway!)
* The string "pre" causing the same problem as above. (Could be fixed with absolutely no risk to release build behavior, since releases don't say "pre" anyway!)
* Irish Gaelic getting sniffed as Internet Explorer. (Fixed.)
* Romanch getting sniffed as the shell code payload of an attack. (Fixed.)
* Site sniffing for the current year in the Gecko build date and breaking when the year changes. (Could be fixed with absolutely no risk to release build behavior by freezing the date to any date from today to the end of the year!)
* Site serving broken ads to a particular version of Windows making the time to diagnose a problem longer (since the problem doesn't reproduce on other systems).
Exposing less system info would carry some risk for release builds. However, freezing the Gecko date, making nightlies say Firefox instead of Minefield in the UA string, getting rid of "pre" (and other pre-release designators) and getting rid of the patch level are all essentially zero-risk low hanging fruit as far as sites other than Mozilla's own support sites go: The sites would have to be able to deal with non-point releases of Firefox with *some* Gecko date *anyway*.
> I'd like to provide a way for the user to be informed about the case
> where a web page includes vary: user-agent, and let the user provide a
> different one using e.g. Site properties.
I don't believe that to be a particularly practical solution, since it relies on authors who are clueless enough to do bad sniffing to be clueful enough to declare that they are sniffing at all.
Robert Kaiser
> Exposing less system info would carry some risk for release builds.
It also will make those that UA string have been originally thought for,
i.e. web analyzers, find more brittle and intimidating ways of getting
their info. And I'm sure they'll find their ways, as they always have,
even if it means a few more KB of JS running on every web site we access.
> However, freezing the Gecko date, making nightlies say Firefox instead of Minefield in the UA string, getting rid of "pre" (and other pre-release designators) and getting rid of the patch level are all essentially zero-risk low hanging fruit as far as sites other than Mozilla's own support sites go
As long as we are offering a very simple way for users and support sites
(and even Bugzilla) to get a string that contains every bit of that
information to provide it to people providing support, those people
should be fine.
I for one tend to refuse support without that info in many cases even
now (but now the UA often helps), and will even more in the future.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Neil
> * Sites that look for "Firefox" but not "Minefield"
>
Well they shouldn't look for either of course. Maybe the app should not
appear in the UA string at all, except on certain sites, which would
trigger something I will call "Compatibility View". The list of sites
would automatically update from AMO as per the blocklist.
Christopher Blizzard
string, but I was more interested in the actual timing of the final
landings. I didn't hear anyone say that it would be difficult to make
these decisions by Beta 4, so let's say that all UA string changes need
to be done by the B4 freeze and take individual discussions of parts of
the UA to their respective bugs.
Thanks, everyone!
--Chris
Henri Sivonen
> Henri Sivonen wrote:
>
>> * Sites that look for "Firefox" but not "Minefield"
>>
> Well they shouldn't look for either of course.
As long as the opportunity to look for it is there, they will.
> Maybe the app should not appear in the UA string at all, except on certain sites, which would trigger something I will call "Compatibility View". The list of sites would automatically update from AMO as per the blocklist.
I'd be OK with either removing the app name from both official and unofficial builds or putting "Firefox" in both. Putting "Firefox" in both wouldn't cause trouble with sniffers. Taking it away would cause some.
However, I think we should really avoid going down the path of having to maintain compatibility lists the way Microsoft and Opera do. Mozilla has gotten away without one of those lists so far, and maintaining a list has non-zero cost (and no, it can't be crowd-sourced easily, because reviewing the list takes the kind of work it would take to maintain it in-house), it's really hard to get rid of the list once it exists and if sites know you have the option of special-casing them, the sites have less incentive to bear the cost of their brokenness themselves, so it would be harder to get sites to fix themselves when they could just go "well, put us on your list".
On Aug 3, 2010, at 18:23, Phillip Jones wrote:
> Wouldn't you have to have something to differentiate between FireFox and SeaMonkey. If you do this the SM Project will have to Follow at some point in time.
I suggest we keep this discussion focused on the UA string of Firefox and unbranded builds of the Firefox codebase. Discussing SeaMonkey is a distraction for this discussion, since SeaMonkey is free to choose whatever UA string works for SeaMonkey.
(Note that Camino already includes the string "Firefox" in its UA string. I am not suggesting that SeaMonkey should. I'm just pointing out that it's a possibility.)
Robert Kaiser
> However, I think we should really avoid going down the path of having to maintain compatibility lists the way Microsoft and Opera do.
Then we better revert any changes we made to the UA in an instant. Or
shut up about caring about users.
Still, we are even prohibiting the possibility of trying it out as an
extension right now, which sucks really hard.
> Mozilla has gotten away without one of those lists so far
Yes, we know we suck, What else is new?
> and maintaining a list has non-zero cost (and no, it can't be crowd-sourced easily, because reviewing the list takes the kind of work it would take to maintain it in-house)
So the add-on compatibility reporter that does *exactly* the same
crowd-sourcing that I'd like to see here is doomed anyhow as well
because that way of doing things can't work? Interesting!
> (Note that Camino already includes the string "Firefox" in its UA string. I am not suggesting that SeaMonkey should. I'm just pointing out that it's a possibility.)
Yes, increasing suckage is always an option. Not one a self-respecting
product goes lightheartedly, though.
L. David Baron
> Henri Sivonen schrieb:
> >Mozilla has gotten away without one of those lists so far
>
> Yes, we know we suck, What else is new?
Excuse me?
Having a compatibility list is bad for authors because they'll get
different behavior on a staging/testing site and on a real site, and
because the documentation they read will either be unnecessarily
complex or wrong.
Having a compatibility list is bad for us because it means we have
to test and maintain extra codepaths and have to deal with the
performance and memory use costs of checking the list. And if we
treat compatibility lists as a readily available solution for
problems and use them multiple times, we'll also have to deal with
the issue of testing or otherwise ensuring the correctness of an
exponential number of codepaths for the combinations of them.
Having a compatibility list is bad for the future of the Web because
it means anybody writing a new piece of software to handle Web
content has to write and test code for both branches as well as get
the branching right. This makes it less likely they'll successfully
write the software.
And what's with the bad attitude?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Shawn Wilsher
> So the add-on compatibility reporter that does *exactly* the same
> crowd-sourcing that I'd like to see here is doomed anyhow as well
> because that way of doing things can't work? Interesting!
crowd sourcing, the end result is completely different. The add-on
compatibility reporter sends its data to the add-on authors and they can
choose to use that data or not. Doing this for the user agent would
have to be reviewed by Mozilla before pushing it out to users since
crowd sourcing can be gamed. We could try to push the reviewing out to
a large portion of the community, but at what cost?
> Yes, increasing suckage is always an option. Not one a self-respecting
> product goes lightheartedly, though.
So what, Camino isn't a self-respecting product? Your attitude in this
thread is really quite unacceptable Robert.
/sdwilsh
Robert Kaiser
> Having a compatibility list is bad [...]
None of this is really true if we do it intelligently the way I've been
proposing for a long time, with user warnings, ability to actively
influence it, and things like that, but then, that would give
intelligence to users, which some don't seem to want, and then, it's my
proposal and therefor to be ignored from the beginning. I'm getting used
to that, but it's still frustrating.
> And what's with the bad attitude?
Well, actual arguments are being ignored anyhow, so this seems to be the
only way of getting any feedback at all.
Also, with us preventing even a try of an intelligent solution, I'm
getting so tired of all this.
And I miss the times when "we suck" was a generally accepted joke and
reasons for laughter. Today it's treated as a bad insult because most of
us have forgotten how to not take ourselves too seriously all the time.
Maybe that comes with having hundreds of millions of users, which could
explain that I still know how to do it. ;-)
Robert Kaiser
> On 8/4/2010 5:03 AM, Robert Kaiser wrote:
>> So the add-on compatibility reporter that does *exactly* the same
>> crowd-sourcing that I'd like to see here is doomed anyhow as well
>> because that way of doing things can't work? Interesting!
> Do you like comparing apples to oranges too? While both of these may be
> crowd sourcing, the end result is completely different. The add-on
> compatibility reporter sends its data to the add-on authors and they can
> choose to use that data or not. Doing this for the user agent would have
> to be reviewed by Mozilla before pushing it out to users since crowd
> sourcing can be gamed. We could try to push the reviewing out to a large
> portion of the community, but at what cost?
I'm pretty sure there's a reasonable amount of people who'd be more than
willing to help there, but we don't even enable someone who want to try
and build up such a system, so probably it's futile to care about real
improvement there anyhow.
>> Yes, increasing suckage is always an option. Not one a self-respecting
>> product goes lightheartedly, though.
> So what, Camino isn't a self-respecting product?
That's what I said all along since they did this IMHO ridiculous change.
And as it has been decided that I'm to be treated as an outcast, I have
mostly stopped caring about my attitude as it doesn't seem to help if I do.
Justin Wood (Callek)
> On Aug 3, 2010, at 19:52, Neil wrote:
>
> On Aug 3, 2010, at 18:23, Phillip Jones wrote:
>
>> Wouldn't you have to have something to differentiate between FireFox and SeaMonkey. If you do this the SM Project will have to Follow at some point in time.
>
>
> I suggest we keep this discussion focused on the UA string of Firefox and unbranded builds of the Firefox codebase. Discussing SeaMonkey is a distraction for this discussion, since SeaMonkey is free to choose whatever UA string works for SeaMonkey.
>
I wouldn't. Focused on Firefox for what Gecko exposes as a UA string
sounds quite flawed to me. What about Flock, what about any other GECKO
consumer.
Yes we can override it on a case-by-case basis, but do we as Mozilla
really wish to lay that burden of "make sure sites work" to random
XULRunner App that wants some site loading abilities. <browser> is
toolkit/ and thus exposed to any and all apps that want to use Gecko.
This is a problem not just for SeaMonkey but everyone.
FWIW the official Documents regarding UA strings have _always_ said NOT
TO override the default string, and just 'add' to it. [1]
> (Note that Camino already includes the string "Firefox" in its UA string. I am not suggesting that SeaMonkey should. I'm just pointing out that it's a possibility.)
And yes, if SeaMonkey did that, we would also be increasing the
"Firefox" reporting on websites, and decrease the SeaMonkey reporting...
I'm not sure that will help matters. (Other than to get more of the "You
have far less users than us, we're inherently better" comments I seem to
get as well)
--
~Justin Wood (Callek)
Justin Wood (Callek)
> On 8/4/2010 4:16 AM, Henri Sivonen wrote:
>> On Aug 3, 2010, at 19:52, Neil wrote:
>>
>> On Aug 3, 2010, at 18:23, Phillip Jones wrote:
>>
>>> Wouldn't you have to have something to differentiate between FireFox
>>> and SeaMonkey. If you do this the SM Project will have to Follow at
>>> some point in time.
>>
>>
>> I suggest we keep this discussion focused on the UA string of Firefox
>> and unbranded builds of the Firefox codebase. Discussing SeaMonkey is
>> a distraction for this discussion, since SeaMonkey is free to choose
>> whatever UA string works for SeaMonkey.
>>
>
> I wouldn't. Focused on Firefox for what Gecko exposes as a UA string
> sounds quite flawed to me. What about Flock, what about any other GECKO
> consumer.
>
/me was just informed over IRC that Flock switched to Chromium. so "What
about Songbird" instead, or "Komodo" though the latter is less
browser-heavy than the former.
--
~Justin Wood (Callek)
Neil
>Putting "Firefox" in both wouldn't cause trouble with sniffers.
>
No, it would make it even easier for them to get it wrong, and give them
less of an incentive, and make it harder to get sites to fix themselves...
Robert Kaiser
> What about Flock, what about any other GECKO
> consumer.
Flock, and probably more and more of those Gecko consumers, have or are
turning to alternatives that seem to fit them better anyhow. Some may be
of frustration with Gecko being seen as Firefox-centric and nothing
else, some because the alternatives are really better - at least for
their use cases.
Dao
> Having a compatibility list is bad for authors [...]
>
> Having a compatibility list is bad for us [...]
>
> Having a compatibility list is bad for the future of the Web [...]
I think Robert made several implicit assumptions, like:
* We want a short and clean UA string, e.g. Gecko/3.0 (Windows; Firefox)
or Gecko/3.0 (Windows NT 7.0).
* We won't be able to get there without a compatibility list, as it
would break too many sites.
* The compatibility list would be a temporary solution. Sites on the
list could be evangelized to fix their stuff. Because authors would get
the clean string by default (also on staging sites, which I'd argue is
good), they would be tempted to deal with it. So at some point the list
should shrink slowly -- worst case would be that it would be static --
but it shouldn't grow.
I haven't seen you, or anybody else really, agree or disagree on that
level, so judging whether a compatibility list would be a net win or
loss seems premature.
L. David Baron
> On 04.08.2010 17:38, L. David Baron wrote:
> > Having a compatibility list is bad for authors [...]
> >
> > Having a compatibility list is bad for us [...]
> >
> > Having a compatibility list is bad for the future of the Web [...]
>
> I think Robert made several implicit assumptions, like:
>
> * We want a short and clean UA string, e.g. Gecko/3.0 (Windows; Firefox)
> or Gecko/3.0 (Windows NT 7.0).
I didn't see that as a goal. I saw the goal more as removing what
isn't important for compatibility.
> * The compatibility list would be a temporary solution. Sites on the
> list could be evangelized to fix their stuff. Because authors would get
> the clean string by default (also on staging sites, which I'd argue is
> good), they would be tempted to deal with it. So at some point the list
> should shrink slowly -- worst case would be that it would be static --
> but it shouldn't grow.
I also think a compatibility list is bad for the Web because it
makes the assumption that the important part of the Web is the major
sites that very large numbers of people use. I think the less-used
sites with smaller audiences are a critical part of the Web, and it
shouldn't be ok to break them *disproportionately*, as a
compatibility list would.
Neil
>Having a compatibility list is bad for authors because they'll get different behavior on a staging/testing site and on a real site
>
Not if they use correct code. The compatibility list idea was supposed
to work around incorrect code only.
>Having a compatibility list is bad for the future of the Web because it means anybody writing a new piece of software to handle Web content has to write and test code for both branches as well as get the branching right.
>
I'm not sure what you mean here. Most browser developers will continue
to write code that assumes that websites follow standards.
Ben Bucksch
> * We want a short and clean UA string, e.g. ... Gecko/3.0 (Windows NT
> 7.0).
Agreed there.
> * We won't be able to get there without a compatibility list, as it
> would break too many sites.
I would like to question that. I claim that Firefox has sufficient
market share that it's being tested (by site authors or users), and the
sites actually fix things, shortly before or after the main Firefox release.
> * The compatibility list would be a temporary solution. Sites on the
> list could be evangelized to fix their stuff.
I think that actually hurts evanglism, because sites would say "just put
us on the list" or "it works in that compat thing, where's the problem?"
Temporary solutions tend to be permanent, esp. so if they include third
parties, even more so thousands of third parties.
Robert Kaiser
> I think Robert made several implicit assumptions, like:
I did, because I've been thinking about this system so long that I
forget that others don't know that well what I'm thinking about there -
but you nailed it anyhow. Thanks for that.
Robert Kaiser
> I think that actually hurts evanglism, because sites would say "just put
> us on the list" or "it works in that compat thing, where's the problem?"
Do you really think they want to be on a list of site where the user
gets a notification every time he visits them that the browser is lying
to the site because it can't get standards right? And my model is based
on that as a core component - let things work for users, but tell them.
Ben Bucksch
> Do you really think they want to be on a list of site where the user
> gets a notification every time he visits them
Ah, you've been running with that assumption, I see. I don't think we
(as a mainstream browser) want to harrass users with such technical
stuff. It's useless for them, there's nothing they can do about it (they
can't fix the site), and it works fine without notifying the user, so
why do so?
Dao
> On 05.08.2010 16:01, Robert Kaiser wrote:
>> Do you really think they want to be on a list of site where the user
>> gets a notification every time he visits them
>
> Ah, you've been running with that assumption, I see. I don't think we
> (as a mainstream browser) want to harrass users with such technical
> stuff.
Yep, we certainly wouldn't do that.
Robert Kaiser
> On 05.08.2010 16:01, Robert Kaiser wrote:
>> Do you really think they want to be on a list of site where the user
>> gets a notification every time he visits them
>
> Ah, you've been running with that assumption, I see. I don't think we
> (as a mainstream browser) want to harrass users with such technical
> stuff.
Is "we're lying to this website about what browser you're using" too
technical? (Or "Firefox is pretending to be something different to make
this website work", or "SeaMonkey is faking its identity to work with
this website" or something like that?)
Robert Kaiser
> Consider somebody working on a site redesign of a site we put on the
> compatibility list. They might find the site works fine on a
> staging site, and then when they push it live it could be broken
> *because* it's on the compatibility list.
That's fast to fix. And actually, if that happens, they also did the new
site wrong anyhow.
Robert Kaiser
> But if you want to write a browser that handles the Web as well as
> we do, you'll have to emulate our compatibility list along with both
> behaviors.
BTW, note that it's a trademark problem right now that anyone wanting to
do that needs to send OUR trademark "Firefox" in THEIR UA string.
L. David Baron
> L. David Baron schrieb:
> >Consider somebody working on a site redesign of a site we put on the
> >compatibility list. They might find the site works fine on a
> >staging site, and then when they push it live it could be broken
> >*because* it's on the compatibility list.
>
> That's fast to fix. And actually, if that happens, they also did the
> new site wrong anyhow.
It's fast to fix for a site where all the content was written by one
person. If it's a site that pulled in a JS toolkit that somebody
else wrote, they probably don't have any ideas where to start.
Ben Bucksch
> L. David Baron schrieb:
>> But if you want to write a browser that handles the Web as well as
>> we do, you'll have to emulate our compatibility list along with both
>> behaviors.
>
> BTW, note that it's a trademark problem right now that anyone wanting
> to do that needs to send OUR trademark "Firefox" in THEIR UA string.
Said several times before: trademarks don't apply to protocols. The law
is pretty clear that trademarks protect from misrepresenting products to
customers, but it's entirely irrelevant to how 2 computers communicate.
Neil
>Consider somebody working on a site redesign of a site we put on the compatibility list. They might find the site works fine on a staging site, and then when they push it live it could be broken *because* it's on the compatibility list.
>
>
Ah, so the code works on the staging site because a third-party JS
library fails to detect Firefox, and therefore follows the correct
codepath, but on the live site it stops working because the third-party
JS library is now following the wrong codepath?
Georg Maaß
Robert Kaiser wrote:
> Is "we're lying to this website about what browser you're using" too
> technical? (Or "Firefox is pretending to be something different to make
> this website work", or "SeaMonkey is faking its identity to work with
> this website" or something like that?)
In former days (end of last century) my Websit was ending JavaScript
test code to the browser to get a finger print of the browser. If the
finger print did not match with the UserAgent i.e. Mozilla/4.0, I did
not deliver the desired content but a web page telling the user that
his/her browser is lying. I stopped this, after Mozilla 5.0 has been
frozen, making all newer Mozilla based browsers to liars. Replacing
Mozilla/5.0 by Gecko/1.9.2 or Gecko/2.0b3 or what ever the engine is is
what should be there.
Georg Maaß
> person. If it's a site that pulled in a JS toolkit
Exactly that is the bug. Since IE 7 and Safari such toolkits are
obsolete. Just use W3C standards, which will reduce the amount of
useless stuff to learn dramatically.
Such toolkits increase the amount of time for maintenance dramatically.
When during my work I get such a site into my fingers to work on it, the
first thing I do is clean up removing the toolkits to shrink size of
code, speed up UI, kick off security holes.
There was a place for such toolkits in days before W3C DOM and days of
starting W3C DOM, when my own toolkit was the first supporting perfectly
all 3 object models MSIE, NN and W3C; but today all suche toolkits are
obsolete. I no longer provide my own toolkit, because it is obsolete and
all others are obsolete too.
Toolkits are fat bugs. Our cat likes catching bugs for eating them.
Philip Chee
> Ben Bucksch schrieb:
>> On 05.08.2010 16:01, Robert Kaiser wrote:
>>> Do you really think they want to be on a list of site where the user
>>> gets a notification every time he visits them
>>
>> Ah, you've been running with that assumption, I see. I don't think we
>> (as a mainstream browser) want to harrass users with such technical
>> stuff.
>
> Is "we're lying to this website about what browser you're using" too
> technical? (Or "Firefox is pretending to be something different to make
> this website work", or "SeaMonkey is faking its identity to work with
> this website" or something like that?)
Hrm. Doesn't IE8 have a "fix broken websites" toolbarbutton that uses a
compatibility list? We could have a similar UI.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Robert Kaiser
> Hrm. Doesn't IE8 have a "fix broken websites" toolbarbutton that uses a
> compatibility list? We could have a similar UI.
Sure, there _would_ be a few possibilities - if we would make it
possible to even implement such a thing in the first place.