NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Yahoo will ignore Do Not Track for IE10 users
My dream is that this starts a tit for tat: Yahoo says it will treat IE10 differently, so Microsoft modifies IE10 to make it harder to identify (for Europe, they already have to force new users to pick a browser randomly from a list; why not pick a browser ID string randomly from a list?) Yahoo looks for other clues, and Microsoft keeps hiding them. Etc.
After all, HTML is *supposed to be* a standard. You shouldn't have to care what browser you're talking to. While people did do some browser-specific hack-arounds even very early on, it was IE6 that created the whole "this site only works in browser XYZ, not as a bug but by design" trend. The purpose has changed, but today we're seeing sites that work only on particular "mobile" browsers, or *not* on particular mobile browsers, or not on Google TV, etc. Wouldn't it be nice if such discrimination were rendered impossible - by the same Microsoft that ushered in this world? (Not that I think it's going to happen - but one can dream.)
Now, yes, since not all browsers support all HTML features, a site might want to know if certain features are present or not. We've been here before. Back in the late 1970's, DEC created a series of terminals; starting with the VT100, they all supported (some subset of) a published ANSI standard. You could request an ID string from a terminal, and programs would decide what features were supported based on the ID string. When a new terminal came out - e.g., when the VT102, a slight modification of the VT100 came out - programs that didn't know about the new ID string would treat the terminal as "unknown" and either refuse to run or support minimum capabilities on it. It could take a while for an update to be available; meanwhile, your shiny new terminal was much less useful than the dusty old one in the corner.
One of the achievements I look back at fondly from my time in the DEC terminals group was stopping this nonsense. I defined a "terminal capabilities" string which, rather than giving you an id, told you which of a defined set of capabilities were supported. And I convinced the application developers at DEC to look only at the capabilities, not the ID string. (Well, for older terminals they still had to fall back to the ID string.) New terminals - just worked.
This is the right way to deal with varying browser capabilities, too. Then browser ID strings can fade away, having outlived any useful purpose.
-- Jerry
_______________________________________________
nnsquad mailing list
http://lists.nnsquad.org/mailman/listinfo/nnsquad