Should UA string spoofing be treated as a trademark violation?

[Thomas 'PointedEars' Lahn]

I _have_ come up with an application design that works on half a dozen
current browsers by means of browser detection. My original question was
in response to a claim--often repeated in this news group--that one
should use object/feature detection instead of browser detection. And
indeed I would prefer to use object/feature detection if that were
possible. Judging from the replies so far, it is not possible.

However, trying to attempt to detect the browser to work around design
issues is not future-proof (reliable) at all. So you should definitely
choose one of the other two alternatives. Because your client, without
knowing about this, will hold /you/ responsible if it does not work
after a browser upgrade.


PointedEars

 

[Richard Cornford]

Thomas 'PointedEars' Lahn writes:

I _have_ come up with an application design that works on half
a dozen current browsers by means of browser detection.

That is a claim that is indicative of superficial testing. At best the
truth is probably that you have a system that works with the current
default configuration of half a dozen browsers. But you are talking
about user configurable software, and default configurations change
(particularly on IE where recent security updates have altered the
default set-ups quite considerably).

My original question was in response to a claim--often repeated
in this news group--that one should use object/feature detection
instead of browser detection. And indeed I would prefer to use
object/feature detection if that were possible. Judging from the
replies so far, it is not possible.

One of the main principles of feature detection is that you test
features with as close as a one-to-one relationship with the questions
you need answered as can be achieved. To do that you really need to pin
down what you need to know; to identify the real problem. When you say
that you need to know if onunlod is firing we can be fairly sure that
that is a question too far removed from the real problem for a sensible
test to be devised. There is something that you want to do (or not do)
in relation to the onunload event, and knowing precisely what that is
may suggest a suitable test for your situation.

Then again, it is clear that everyone thinks that what ever you are
doing is something inappropriate in an HTTP application context, and
should itself be designed out of the situation. You have not provided
enough information for that possibility to be known for certain or ruled
out. But you probably won't get better answers (or better explanations)
without the missing information.

However, on the subject of inset borders; you want the user to choose a
border color but have no idea how their browser will present the
alternatives available. Have you considered presenting your users with a
choice of border colors in the form of elements with colored
inset/outset borders and having them select the one they like. The user
will see the choices in the form their browser presents and choose the
one that best suites them, without your needing to know (or care) how
the actual color will be presented to them.

Richard.

 

[Richard Cornford]

I've not seen previous replies on the topic.

They were responses to a post of yours.

I'm not sure that is true.

As you wish.

I believe that is a false statement.

If you say so.

But that is a case where you are testing one feature and then
inferring another.

The principle that you test as close to the issue as possible stands,
even if it is not always possible to test a feature that has a genuine
one-to-one relationship with the issue. Still, I doublet that a viable
test would be found.

It cannot be assumed that there is no browser where using the
iframe would be a problem, but it would probably be a safe
assumption AFAIK.

I am certain that, for example, Opera 6 would have a problem with
positioned IFRAMES, but I doubt that Opera 6's limited dynamic
capabilities would pass testing for other required features. However,
the technique is better suited to Intranet and specific web applications
that the public Internet so I don't really see that as an issue.

True, but it seems to be the best, IMO.

It is the simplest (much less need to be interested in determining exact
positions and sizes), but it is the appeal of simplicity that encourages
me to use the IFRAME anyway as that makes the creation and positioning
code simpler as well.

I'm talking only about the cases which cannot be covered by the
more reliable alternative.

When considering alternatives I tend to consider how wrong an
alternative that has the potential to be wrong is capable of being.
Browser detection on the public Internet is capable of being utterly
wrong, even to the extent of being catastrophically wrong and making the
script itself the barrier to a site being useable to a visitor.

BrowserHawk, as mentioned in a recent thread is an excellent example; it
Identifiers my IE 6 as Opera running on an unknown operating system and
then spits out a series of script errors and grinds to a halt. It is the
direct result of its authors assuming the truth of a fundamentally false
premise and so not thinking about the consequences of being wrong, and
because of the script errors the failure of their code is never obvious
because it never gets to report back. (and of course VK was the only
person willing to admit to using it, as damming a condemnation of a
strategy as anyone would need.)

Richard.

 

[Matt Kruse]

As you wish.

Not as I wish, just reality

When considering alternatives I tend to consider how wrong an
alternative that has the potential to be wrong is capable of being.
Browser detection on the public Internet is capable of being utterly
wrong, even to the extent of being catastrophically wrong and making
the script itself the barrier to a site being useable to a visitor.

True. But it can also be used to fix small errors and quirks which will not
have a negative impact on any functionality for any mis-identified user, but
will make the style or functionality better for those who are correctly
identified.

BrowserHawk, as mentioned in a recent thread is an excellent example;

Something along the same lines that should be mentioned is ASP.NET from
Microsoft. I don't work with it, but my exposure to it leads me to believe
that it does extensive browser-capability "detection" based on the user
agent header and serves various levels of rich content as a result. I got
into an argument with a .NET developer when I said that this was surely a
flawed way to determine what content to serve. His response was along the
lines of "Microsoft is the software giant and surely employees more experts
in these fields than anyone you know. Don't you think they would know the
best way to do it? We've built .NET apps before and we've never had a single
complaint."

It's hard to argue against cases like this, where a huge software company
uses the "wrong approach" yet does it with overwhelming success for the vast
majority of users.

 

[Richard Cornford]

Not as I wish, just reality

So you are saying that form controls did not burn through on, for
example, Windows Netscape 4 and Opera <= 6? That the issue only ever
applied to versions of IE browsers and browsers that embed IE?

True. But it can also be used to fix small errors and quirks
which will not have a negative impact on any functionality for
any mis-identified user, but will make the style or functionality
better for those who are correctly identified.

No, the extent to which your 'small error or quirks' are problems is the
extent to which applying a 'fix' to a browser miss-identified as one
needing a fix is likely to case a problem.

Something along the same lines that should be mentioned is
ASP.NET from Microsoft. I don't work with it, but my exposure
to it leads me to believe that it does extensive browser-capability
"detection" based on the user agent header and serves various
levels of rich content as a result.

Yes, it seems perverse that the company that suffered from misguided
browser detection to the extent that they were forced to introduce UA
string spoofing in order to get a foothold in the market should then go
on to formalise that bad practice in their own framework. Especially as
the consequence of their actions was the change in the specification of
a UA header from HTTP 1.0 to 1.1, where the latter defines a UA header
as little more than any arbitrary sequence of ASCII characters of
indefinite length; so not a source of information at all.

I got into an argument with a .NET developer when I said
that this was surely a flawed way to determine what content
to serve. His response was along the lines of "Microsoft is
the software giant and surely employees more experts in these
fields than anyone you know. Don't you think they would know
the best way to do it?

..NET developers; charmingly naive ;-)

We've built .NET apps before and we've
never had a single complaint."

I like this "it must be OK because nobody ever complains" attitude. Jim
is right, web related QA is generally abysmal. One of my favourite
stories to date was an individual who vigorously protested that pop-up
blocking was not a real issue on the internet because he had never
received a single complaint about his site not working because of a
pop-up blocker, but when you looked at his site the feed-back form was
presented in a javascript dependent pop-up window.

But who is going to complain anyway; if a web site is so broken that you
cannot buy something on it you go to the next, and the same goes when
looking for information. As you know I sometimes purchase buy computer
parts, and in February a UK web-retailer of computer parts missed the
opportunity of taking a couple of thousand pounds off me because they
have a shopping cart that makes invalid assumptions about the IE browser
I was using (in this case that it would run ActiveX). Presumably they
think that their (I assume .NET because of the .aspx extensions) code
works, and I was not going to tell them otherwise, just move on to the
next site. It is much easier for a web developer to crate a site that
receives no complaints than to create a site that doesn't warrant any.

It's hard to argue against cases like this,

I don't know, you could point out that there is no formal basis for the
assumption that the UA header is a source of information, that in
practice many are completely indistinguishable, that even the
distinguishable ones are amenable to user modification, etc.

You could go on to point out that Microsoft clearly does not employ
competent web developers, else MSDN would not kick out so many
"parentElement.parentElement is null or not an object" errors on IE6
(Microsoft developers who cannot even cope with IE specific code running
on a default installation of IE6 are hardly to be regarded as
competent). And, of course that if Microsoft never made mistakes in
their web related development we would not have seen a procession of
security fixes and service packs for IE.

where a huge software company uses the "wrong approach"
yet does it with overwhelming success for the vast
majority of users.

But we both know that you cannot accurately quantify those numbers over
HTTP, that 'overwhelming' and 'vast' are convenient opinions that cannot
be substantiated (except to the extremely gullible). My question is who
is making these business decisions; did the business managers really say
that it was OK to design out the potential for 5-20% of the resulting
turnover because the web developers wanted to make decisions based on an
assumption that has no formal technical basis? I don't think that they
are being asked at all, and if they are I don't think they are being
given accurate representations of the statistics (the validity of the
statistics) or the alternatives, because business people don't turn
their noses up at money that easily.

Richard.

 

[Warren Sarle]

Warren Sarle wrote:


That is a claim that is indicative of superficial testing. At best the
truth is probably that you have a system that works with the current
default configuration of half a dozen browsers.

Your speculation is incorrect. The system works with a wide variety
of browser configurations. And I get feedback from almost all the
users.

But you are talking
about user configurable software, and default configurations change
(particularly on IE where recent security updates have altered the
default set-ups quite considerably).

If there are any browser-configuration settings that affect how
border colors are rendered, they sure are hard to find.

One of the main principles of feature detection is that you test
features with as close as a one-to-one relationship with the questions
you need answered as can be achieved. To do that you really need to pin
down what you need to know; to identify the real problem. When you say
that you need to know if onunlod is firing we can be fairly sure that
that is a question too far removed from the real problem for a sensible
test to be devised. There is something that you want to do (or not do)
in relation to the onunload event, and knowing precisely what that is
may suggest a suitable test for your situation.

I want to save the user's work if the user forgets to click on the
"Save" button before closing the browser window or otherwise losing
the browser state.

Then again, it is clear that everyone thinks that what ever you are
doing is something inappropriate in an HTTP application context, and
should itself be designed out of the situation.

Well, some people think that, but none of the users think that.

You have not provided
enough information for that possibility to be known for certain or ruled
out. But you probably won't get better answers (or better explanations)
without the missing information.

The details would be boring, but it's a service for photographers
related to but not affiliated with online photo galleries at
http://www.pbase.com

However, on the subject of inset borders; you want the user to choose a
border color but have no idea how their browser will present the
alternatives available. Have you considered presenting your users with a
choice of border colors in the form of elements with colored
inset/outset borders and having them select the one they like. The user
will see the choices in the form their browser presents and choose the
one that best suites them, without your needing to know (or care) how
the actual color will be presented to them.

Thank you for the constructive suggestion. But in Firefox, it is
impossible to specify border colors that are rendered acceptably
with a border-style of inset, outset, ridge, or groove; and Opera
is almost as bad. Therefore, if the browser is not known to render
border colors nicely, I put an extra div around elements that have
borders, use "border-style: solid", and specify different colors
for different sides.

 

[Randy Webb]

Warren Sarle said the following on 4/26/2006 5:46 PM:

Your speculation is incorrect. The system works with a wide variety
of browser configurations. And I get feedback from almost all the
users.

How many varieties does "a wide variety" cover? And, is it the same
browser in different configurations or is it many different versions of
browsers in many different configurations or is it many different
versions in default configurations?

There are more than 1,152,921,504,606,846,976 configurations of IE6 on
WinXP SP2 alone (almost that many squared in fact).

Thank you for the constructive suggestion. But in Firefox, it is
impossible to specify border colors that are rendered acceptably
with a border-style of inset, outset, ridge, or groove; and Opera
is almost as bad. Therefore, if the browser is not known to render
border colors nicely, I put an extra div around elements that have
borders, use "border-style: solid", and specify different colors
for different sides.

Then do that by default, leave the border-style of the input alone and
your problem is solved without knowing what browser it is.

 

[VK]

How many varieties does "a wide variety" cover?

And how many riders one horse can hold? I already asked this question
but no one seems willing to give an answer. Instead you are just
floating from "use the most generic script-independent layout" to
"every single UA used by at least one user must be checked against".
You realize though than both answers are not publicly acceptable: the
first one is a sure way to get a finger from any practical developer;
the second one is not humanly doable. So you are just turning like a
snake on the grill One minute you are talking about ajaxoids and
XML nodes updates, a minute later you're coming up with something like
"Opera 6.x doesn't support that!". Take a damn decision first and spell
it as clearly as I did. Then let's us argue if you want.

I repeat my position: there are two ways: W3C-based (at least
originally) by Gecko and Microsoft IE. Any other producer has either
join to one of them, or die, or come up with a third path (but it must
be a *third path*, not a third set of bugs and missing features).
Developers must help the users to migrate on more capable UA's by stop
caring of the underdone mutants. Netscape 4.x migration process went
quickly and smoothly as soon as developers stopped to produce separate
Netscape solutions, as you remember.

As I presume this is an awfully wrong point of view from your point of
view, I'd like to hear how many UA's and which ones do you suggest to
check against practically (by loading pages into them) as opposed to
theoretically (generic feature detection blocks).
Feel free to be generous
Just remember that Level 3 Developer (1-3 months crash course diploma)
gets $30/hr very min. With insurance and taxes one hour of him sitting
on the computer will cost the employer ~$55/hr. Imagine *you* are
pooling 55 bucks out of your pocket every hour while he's adjusting the
script for Safari 1.0 (and IE 4.0 is on hold for tomorrow).

So you may (only *may*) want to keep your list of some reasonable size
and of practical content.

 

[Warren Sarle]

There are more than 1,152,921,504,606,846,976 configurations of IE6 on
WinXP SP2 alone (almost that many squared in fact).

Fascinating. Do you test all of these configurations yourself?

Then do that by default, leave the border-style of the input alone and
your problem is solved without knowing what browser it is.

But the added complexity in the HTML and Javascript introduces
yet more browser incompatibilities.

 

[Randy Webb]

VK said the following on 4/27/2006 4:19 AM:

And how many riders one horse can hold? I already asked this question
but no one seems willing to give an answer.

What question and where? How many riders can one horse hold? As many as
can get on it before it falls down from the weight. Now, you have an
answer to that question.

Instead you are just floating from "use the most generic
script-independent layout" to "every single UA used by at
least one user must be checked against".

I am? Where do you get your impression of that? I have never
advocated either. I have always said you have to make a decision
somewhere and meet in the middle.

I was asking for a clarification of what was meant by "a wide variety".

You realize though than both answers are not publicly acceptable: the
first one is a sure way to get a finger from any practical developer;
the second one is not humanly doable.

And I never said different nor did I advocate either. With regards to
the first one, you have never ever seen me say that.

So you are just turning like a snake on the grill
One minute you are talking about ajaxoids and XML nodes
updates, a minute later you're coming up with something
like "Opera 6.x doesn't support that!". Take a damn decision
first and spell it as clearly as I did. Then let's us argue
if you want.

What in the name of Hades are you talking about?
Clarify it please as I am not even sure *you* know what you are
referring to.

I repeat my position: there are two ways: W3C-based (at least
originally) by Gecko and Microsoft IE. Any other producer has either
join to one of them, or die, or come up with a third path (but it must
be a *third path*, not a third set of bugs and missing features).

Since you mention it, there are already 3 paths, maybe 4.

Developers must help the users to migrate on more capable UA's by stop
caring of the underdone mutants. Netscape 4.x migration process went
quickly and smoothly as soon as developers stopped to produce separate
Netscape solutions, as you remember.

Yes, I remember it very well. And I have said that even now. And now the
problem is IE4 and it's document.all that people don't want to let go of
(and that is partly MS pushing it).

As I presume this is an awfully wrong point of view from your point of
view, I'd like to hear how many UA's and which ones do you suggest to
check against practically (by loading pages into them) as opposed to
theoretically (generic feature detection blocks).

"wrong" or "strong"? I don't think my point of view is either. But, if
you do proper feature detection blocks then testing becomes a lot easier.

But, to answer your question of how many browsers I test in? Right now
it stands at 9. And IE<6 is not one of them.

Feel free to be generous
Just remember that Level 3 Developer (1-3 months crash course diploma)
gets $30/hr very min. With insurance and taxes one hour of him sitting
on the computer will cost the employer ~$55/hr. Imagine *you* are
pooling 55 bucks out of your pocket every hour while he's adjusting the
script for Safari 1.0 (and IE 4.0 is on hold for tomorrow).

I have a meeting every Monday morning that last 2 hours. It is a
planning meeting. The dollar cost of that meeting every Monday exceeds 3
Thousand Dollars US. So rambling to me about spending 55 dollars to test
in a browser doesn't make the point, or have the impact, you wanted it
to. The purpose of that meeting? Planning for the week, covering
anything that went wrong last week, and code examination.

So you may (only *may*) want to keep your list of some reasonable size
and of practical content.

And when have I said different? URL please.

 

[Randy Webb]

Warren Sarle said the following on 4/27/2006 3:01 PM:

Fascinating. Do you test all of these configurations yourself?

Not even close, I have monkeys do it

I was just curious what you considered "many configurations" was all.

The number itself is 2^60 (If I did * right and counted right) and is
based on having 60 checkboxes in my Advanced Tab in IE6 that can either
be checked or unchecked.

But the added complexity in the HTML and Javascript introduces
yet more browser incompatibilities.

I have never bought into that "I want it exactly the same in all
browsers" as it is impossible and trying to achieve that leads down the
wrong road.

 

[RobG]

VK said on 27/04/2006 6:19 PM AEST:

And how many riders one horse can hold? I already asked this question
but no one seems willing to give an answer. Instead you are just
floating from "use the most generic script-independent layout" to
"every single UA used by at least one user must be checked against".

Not at all. The idea is to implement features however you like, but
ensure that a browser that doesn't support a particular feature (or
doesn't support any of them) is still functional. Following standards
and keeping things simple will ensure you maximise the UAs that can
implement your functions.

If you have a specific target audience, say a special purpose site or
intranet, you can write code that is more specific to certain browsers
or standards. But even then, the initial site entry should follow the
'always functional' guideline so at least visitors who stumble across it
understand what is expected of their browser if they proceed further.

[...]

[...] Imagine *you* are
pooling 55 bucks out of your pocket every hour while he's adjusting the
script for Safari 1.0 (and IE 4.0 is on hold for tomorrow).

Following the guideline above, there is no need for that, though they
should be tested against to ensure they function.

For the vast majority of e-commerce sites, simpler is better. The time
and effort expended on designing efficient workflows and ease of use
will often deliver a much bigger saving by reducing the need for
scripted logic and complex navigation paths - and time spent answering
users' questions on why the #*@! some function doesn't work.

 

[RobG]

Richard Cornford said on 27/04/2006 2:14 AM AEST:
[...]

It is much easier for a web developer to crate a site that
receives no complaints than to create a site that doesn't warrant any.

I'm going to add that to my list of quotable quotes.

 

[VK]

VK said the following on 4/27/2006 4:19 AM:

What in the name of Hades are you talking about?
Clarify it please as I am not even sure *you* know what you are
referring to.

I thought it was rather clear: to talk about new features handling
appeared in the last 2-3 years but pull out occasionally some
ancient/underdone UA issue just to say "Your solution is not reliable,
X (Y, Z) will fail on it". Maybe it is not *your* personal position and
I'm just reflecting the common atmosphere floating by some threads -
deeply sorry then.
Still you did not answer the question I posed earlier in this thread:
do you OK or not to serve XSLT to clients (pure XML with XSL
transformation attached). IE 6.0 and Firefox have no problem with it,
but say Opera 8.x will display a raw text dump. Only Opera 9.0b
*finally* learned to do it. So what is your position about it? Hold on
XSLT for 5 -10 more years, sniff UA string and send some consolations
to say Opera < 9, disregard said Opera and Co issue? Depending on your
decision I may dismiss the case against you

But, to answer your question of how many browsers I test in? Right now
it stands at 9. And IE<6 is not one of them.

Congratulations! You are first person in c.l.j. (after me) who
publically admitted that he's testing on a finit amount of UA's. Some
people are pretending either to test on all UA's in the world or do not
test at all but write universal work-or-degrade scripts right on the
paper.

Can you tell what UA's are you testing on? Not to discuss, but for
common consideration.

I have a meeting every Monday morning that last 2 hours. It is a
planning meeting. The dollar cost of that meeting every Monday exceeds 3
Thousand Dollars US.

I'm impressed. That must take hell of a lot of coffee and doughnuts

So rambling to me about spending 55 dollars to test
in a browser doesn't make the point, or have the impact, you wanted it

That was not the point at all. A bagger in a store gets $10/hr, but
across the whole store these are thusands of dollars. Expences add up
you know. And within a big project every additional platform/UA support
cost you *a lot*. And asking to jump on it for a 0.1% - 0.4% - 1% UA is
a bit *a lot*.

 

[Randy Webb]

VK said the following on 4/28/2006 4:04 AM:

I thought it was rather clear: to talk about new features handling
appeared in the last 2-3 years but pull out occasionally some
ancient/underdone UA issue just to say "Your solution is not reliable,
X (Y, Z) will fail on it". Maybe it is not *your* personal position and
I'm just reflecting the common atmosphere floating by some threads -
deeply sorry then.

The implication I got was that you were referring to me personally
displaying that behavior.

Still you did not answer the question I posed earlier in this thread:
do you OK or not to serve XSLT to clients (pure XML with XSL
transformation attached). IE 6.0 and Firefox have no problem with it,
but say Opera 8.x will display a raw text dump. Only Opera 9.0b
*finally* learned to do it. So what is your position about it? Hold on
XSLT for 5 -10 more years, sniff UA string and send some consolations
to say Opera < 9, disregard said Opera and Co issue? Depending on your
decision I may dismiss the case against you

My personal opinion with regards to Opera8 users? Screw'em. Opera9 is
the same cost as Opera8 and is ad free for the free version. The only
reason not to upgrade it is stupidity, laziness, or lack of sense.

Congratulations! You are first person in c.l.j. (after me) who
publically admitted that he's testing on a finit amount of UA's. Some
people are pretending either to test on all UA's in the world or do not
test at all but write universal work-or-degrade scripts right on the
paper.

Typically, code I post to c.l.j gets tested in 4 browsers - Opera9, IE6,
Firefox and my cell phone (for the simplicity of no script testing when
needed).

Can you tell what UA's are you testing on? Not to discuss, but for
common consideration.

IE6.0 WinXP SP2
Firefox 1.5.02
Opera 9
Mozilla 1.7.8 (That is solely to make sure there are no differences in
Mozilla and Firefox)
My cellphone.

MAC:
Safari
Camino
(Although I admittedly do not know the difference in the two, a friend
does the MAC testing for me when I ask for it.)
IE5.1

I'm impressed. That must take hell of a lot of coffee and doughnuts

The dough-nut man has his own chair and stops by every Monday.

That was not the point at all.

I hope not then.

A bagger in a store gets $10/hr, but across the whole store these are
thusands of dollars. Expences add up you know. And within a big project
every additional platform/UA support cost you *a lot*. And asking to
jump on it for a 0.1% - 0.4% - 1% UA is a bit *a lot*.

I am not so sure that every single additional costs a lot but adding a
work around for one browser is out of the question, totally. So I agree
with you on that one. And the irony is that the CEO I work for has a MAC
on his desk. It is the only one in the entire company and he knows good
and well not to call me and tell me something on the Intranet doesn't
work for him (It is totally, 100%, IE6 with that one exception).
Whenever something that is IE specific doesn't work, he turns around to
his PC, cusses me out loud, and starts up his PC to do what he wanted to
do. He has gotten too many "F**K you"s out of me in the past for it that
he doesn't call me about it anymore.