
User-agent string changes - anonymfus
http://msdn.microsoft.com/en-us/library/ie/hh869301(v=vs.85).aspx
======
UnoriginalGuy
UA strings need to die a horrible horrible death. "Everyone" should just agree
on a standard string and completely stop updating them with anything else (and
eventually remove the standard string, in theory).

Feature detection is a major step forward HOWEVER sometimes a feature is
"supported" but has different incompatible behaviour between browser A and
browser B. I feel like that is less common today than it was even four years
ago thanks in part to a better working relationship between browser vendors
but also due to more comprehensive test suites and people spending time
testing new functionality.

If they absolutely insist on keeping UA strings then let's wrap them in a
Javascript structure. Parsing them is insanely convoluted at this point (which
is why many just use .Contains() which has its own issues). Just have e.g.
UA.Agent (.Name, .Version, .OS) and UA.CompatibleWith[] (.Name, .Version,
.OS).

~~~
lambda
So, the one main use case that can't be handled by feature detection or a
JavaScript API is returning a mobile or desktop site without extra round-
trips.

If a server can detect that you have a mobile user-agent, it can directly
deliver you an optimized mobile site, that avoids sending lots of extra data
that is only relevant for the desktop version, and avoids extra slow round-
trips to fetch data later once JavaScript based detection has had a chance to
run.

UA strings are awful, but I haven't seen any other good solution for this
problem.

~~~
TazeTSchnitzel
Why are desktop and mobile sites so different? Why do they _need_ to be
different? Can't we just make responsive designs?

Having separate desktop and mobile sites is an anti-pattern.

~~~
dubcanada
I disagree, there are instances where having a completely different website
for a smaller form factor is beneficial to the user.

~~~
mcovey
It is! And I wish more sites would make it accessible like it used to be by
just going to m.domain.tld rather than user-agent sniffing, because I often
prefer the simpler mobile version I get when I spoof my user agent from the
desktop.

~~~
tracker1
Which is great.. until I do a google search for my closest movie theater on my
phone to pull up the listings... the link to that theater's page is right at
the top... "great" ... now I click the link and the site redirects me to
m.theater.com/ (no path after the slash) ... now I'm stuck slogging through
several pages to get to what I wanted.

This happens a lot.. there's a page on the desktop site that doesn't
correspond. Responsive design still shoves a lot of extra resources at a
client that the smaller devices especially don't need. Responsive rendering
then loading an adaptive client in the browser is a better option... browser
sniffing is the only way to do this.

------
molf

      Mozilla/5.0 (Windows NT 6.4; WOW64)
      AppleWebKit/537.36 (KHTML, like Gecko)
      Chrome/36.0.1985.143 Safari/537.36 Edge/12.0
    

This is getting ridiculous. Every browser is now pretending to be all browsers
at the same time, and a simple version change apparently warrants an entire
article.

Not sending the UA string would avoid this madness. But on the other hand a UA
string is great for analytics. Is it possible to come up with some method that
discloses information about the user agent which can be used for analytical
purposes but cannot be used to change the bahaviour of a web page?

~~~
pbhjpbhj
Isn't this a trademark infringement? They're using AppleWebKit, Chrome, Safari
to identify their product when those terms are protected from use via
trademark law.

I know this isn't a new thing _per se_ but this seems to be an especially
egregious misrepresentation.

~~~
lambda
No, because this is not in any way going to cause consumer confusion, but
instead is simply used for compatibility purposes.

~~~
pbhjpbhj
Confusion is the measure used when trademarks aren't registered and is much
harder to prove. When considering registered trademarks it's not necessary for
confusion to be actually present at all - 100% of customers can know that your
product isn't an iPad but if you advertise it as an iPad then you're
infringing: it doesn't say "AppleWebKit compatible" in that string and the
string is not required to make the browser function at all.

If, for example, people offer alternative services to people with an Apple UA
string (BBC iPlayer did this) then you're impersonating such tech use via the
trademark - it might be now for example that people need to turn off specific
iPad enhancements as they break IE11 - that's commercial interference using a
trademark. The trademark isn't needed in any technical way for IE to operate
as it should, so it's not a compatibility issue.

Website content owners can choose to cut out certain browsers if they wish,
impersonating another browser is fine .. but if you do that as a company
utilising someone else's trademark to do so .. it just has feeling for me of
not sitting quite right with what I know of TM law.

~~~
firepacket
I would think the courts would recognize a difference between advertising to
the end user for the purpose of purchase/consumption, and advertising to 3rd
parties as part of a compatibility protocol.

The UA string is not visible to the consumer, and wouldn't affect the number
of people who download and install the browser.

Its only purpose is to ensure compatibility with the server after the browser
has already been installed.

Also I wouldn't say the browser is actually _impersonating_ another browser.
If it was trying to impersonate, the UA string would need to match the other
browser exactly and it doesn't attempt to do that. The string is still
uniquely identifiable as an IE11 UA.

------
Strom
I think the more interesting bit is that the new UA value contains all the
alternative browser strings as well.

    
    
      Mozilla/5.0 (Windows NT 10.0; WOW64)
      AppleWebKit/537.36 (KHTML, like Gecko)
      Chrome/36.0.1985.143 Safari/537.36 Edge/12.0

~~~
JBiserkov
I also read like a history of web browsers: first there was _Mozilla_ , then
_Apple_ made _WebKit_ (actually _KHTML_ ), then Google created _Chrome_ and
... there will always be a bleading _Edge_ for you to cut yourself :-)

~~~
WorldWideWayne
Actually, _first_ there was NCSA Mosaic which came out almost a full two years
before Netscape Navigator. The first 6 versions of IE were also based on
Mosaic.

~~~
lclarkmichalek
But what UA did Mosaic use?

~~~
WorldWideWayne
Looks like they used something along the lines of "NCSA Mosaic V# (OS/Machine
info)".

I'm wondering if the last one listed on this page is correct though:

    
    
        NCSA Mosaic/1.0 (compatible; NCSA Mosaic; AmigaOS 5.9; FuckYou ver.0.9.3)
    

From [http://www.webuseragents.com/browser/ncsa-mosaic/ncsa-
mosaic...](http://www.webuseragents.com/browser/ncsa-mosaic/ncsa-mosaic-1-0)

~~~
TazeTSchnitzel
I think "FuckYou ver.0.9.3" is some obscure (possibly joke) browser claiming
NCSA Mosaic/1.0 compatibility, note the "compatible;", like IE pretends to be
Mozilla. That specific string is _only_ found on webuseragents.com:

[https://encrypted.google.com/search?hl=en&q=FuckYou%200.9.3#...](https://encrypted.google.com/search?hl=en&q=FuckYou%200.9.3#hl=en&q=%22FuckYou+ver.0.9.3%22)

------
nly
We'd all be better off if they just stopped sending the UA string altogether

~~~
kabdib
These strings make the parser guy in me just twitch. Do they expect many, many
web developers to reliably extract accurate meaning from them?

~~~
xg15
I think it's the other way around. This happens when a field that no-one ever
defined a syntax for suddenly gets important and everyone tries to extract
meaning from it using arbitrary contains() and substring() acrobatics...

~~~
kabdib
So it's organic and ill-defined . . . and people are parsing it. Lovely :-)

------
spdustin
I'll post here the same thing I posted on another HN post about user agent
strings [0], because it's still relevant. I'll also add that the MS article
link artfully dodges the whole "we suck at UA sniffing" issue their own
products have.

Asp.Net 2.0 (and up to 3.5, which is still framework 2.0) sites use UA
sniffing to determine which markup to emit for many built-in controls, like
Asp:Menu. When Yosemite / iOS 8 / Safari 8 was released, anyone with a
SharePoint 2007/2010 site had their navigation get all screwy. I know first
hand how infuriating someone's badly designed UA sniffing can be; it happened
to me, and I wrote up a fix for it [1].

Why did it happen in the first place? Where did the UA sniffing fall apart?

A poorly designed RegExp looking for "60" in Safari's UA without a word
boundary or EOL check. The new Safari UA includes "600" in the relevant
section, and suddenly SharePoint sites were sending markup intended for (now)
ancient browsers - browsers that weren't even on the compatibility list for
SharePoint in the first place.

UA sniffing does need to go away for determining what structure your markup
sends to the user agent.

Edit: linked to earlier comment mentioned at beginning of this one

[0]:
[https://news.ycombinator.com/item?id=8647749](https://news.ycombinator.com/item?id=8647749)

[1]: [http://blog.sharepointexperience.com/2014/10/did-safari-
or-i...](http://blog.sharepointexperience.com/2014/10/did-safari-or-
ios-8-break-your-sharepoint-2010-site/)

------
joshstrange
I alway like to link to this blog post when UA's come up:

History of the browser user-agent string - [http://webaim.org/blog/user-agent-
string-history/](http://webaim.org/blog/user-agent-string-history/)

------
TillE
I assume this also means the internal version will be 10.0? Although they're
deprecating that API anyway, and telling you to use a bunch of helper
functions instead, so maybe it's not too important.

------
slipstream-
This isn't just about the UA string.

The NT kernel version in the latest builds of Windows 10 has changed from 6.4
to 10.0 (as first revealed by Chinese leaks), and this article basically
confirms it.

Make of that what you will.

~~~
anonymfus
Before mods renamed title to "User-agent string changes" it was "...Windows NT
value in the UA string will change from 6.4 to 10.0..."

------
yuhong
Part of the reason for the change is that they removed X-UA-Compatible. I
would have suggested TridentEdgeOnly/x.x.

------
ArtDev
Microsoft. Your hubris is legendary!

Feature detection DOES NOT SOLVE THE PROBLEM!

The problem is poor, inconsistent, unreliable and incomplete adoption of
features. Moderizr is no help here.

Unless Internet Explorer magically can be treated at the same level as modern
browsers, we will have to find a way to target it. Without a clear way to do
that, we have to use hacks. I hate hacks and workarounds. I hate Internet
Explorer.

------
billpg
Will it be "Microsoft Internet Explorer/11.0"?

------
0x0
Do they support NaCl and WebRTC and WebGL and WineVine DRM like Chrome, now
that they stuff "Chrome" in their User-Agent? If not, what happens if a site
(poorly) detects these features from the user agent?

~~~
TazeTSchnitzel
Why on earth would you detect those things server-side, given you can do the
fallback client-side?

Also, no, they don't have those things, aside from WebGL and some form of DRM
(not sure if it's the same as Chrome's). The reason they put Chrome in is for
sites assuming only Chrome supports web standards (ugh).

~~~
0x0
It could easily happen client-side, with something like
/Chrome/.test(navigator.userAgent).

I mean, there's probably sites using code like this already, why else would IE
implement such a user-agent? But then they can't really know _which_ Chrome
feature the code is looking for.

I guess they are moving from being unfairly excluded from modern standards, to
possibly overshooting their target and getting served experimental features
they don't support.

