Hacker News new | ask | show | jobs
by AnkhMorporkian 4236 days ago
While a neat idea in theory, I have some qualms about this. User agent detection sounds great, until you have a user that spoofs their agent. I often do so for various reasons, and from time to time I forget to turn it off after I've finished what I was doing.

If this service becomes common, then I will be given broken webpages seemingly at random. The other option, a polyfill covering specific features and served to all clients, regardless of user agent, doesn't suffer from that.

9 comments

Users that spoof their user agent are likely to either be tech-savvy people who either know what they are doing or who are hiding who they are, like a bot.

I'm more worried about supporting older users on old machines who barely know the difference between Internet Explorer and the internet than in supporting someone who knows exactly what a UA is and how to spoof it.

Take a look at what Microsoft is doing with their newest mobile IE browser - http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...

Basically they're crafting the UA to appear like Chrome or Firefox.

But only because web developers buckled and added loads of workarounds for older versions of IE.
That's a good reminder to turn off your user-agent spoofing. ;-)
Why do you think browsers report user agents? I think it's perfectly reasonable to serve the browser that you say you are.

If a lot of the pages you view end up broken, you would just change the way you lie about your user agent so that it's more prominent to you so you don't forget.

Your complaint is like complaining that if you set your browser's "language preference"* to only contain Dutch, you will end up getting served pages in Dutch.

Why is that different? You ask for Dutch only because supposedly you can understand it, and you ask for a presentation against a particular browser/version because supposedly you're rendering in it. Seems fine to me!

Otherwise, we might as well only serve pages in Esperanto - you know, the universal language standard.

* "(or, more appropriately, that of its user) along with every HTTP request being made in the form of the Accept-Language header that is part of the HTTP/1.1 RFC"

>User agent detection sounds great, until you have a user that spoofs their agent.

Do a significant percentage of users spoof their agent?

Most mobile browsers have a "request desktop site" feature, which I assume would involve spoofing the user agent to look like the desktop version.
Most mobile web applications that would use this polyfill wouldn't have a separate mobile / desktop site and have just a good responsive design, so mobile users wouldn't feel a need to request the desktop site. That feature is usually used (I assume) because the mobile versions of websites often offer limited functionality.
It spoofs the platform, not the browser. Mobile Chrome/Safari should have feature parity with their computer cousins.
Most JavaScript polyfills first check if the native implementation exists, and only if it doesn't the polyfill is activated. This shouldn't break anything. However, the blog article states they use User-Agent detection over feature detection. I hope they combine these solutions.
You can't use feature detection with a simple script tag. It's calling in a script and the cdn chooses the file to send based on the user-agent. No Javascript is run that would allow it to feature detect before choosing to send the load. There may be feature detection afterwards of course.
I think we're saying that most modern polyfills do a feature check before installing the polyfill... thus if you use Chrome with an IE agent, the polyfill still checks before implementing -- it's just a little slower than not installing the polyfill to begin with. Anyway, given the percentage of people who do this, UA detection seems like an acceptable tradeoff.
Agreed, feature detecting afterwards makes sense. Others seem to be suggesting feature detecting before requesting the polyfill script.
While the roundabout trip would be a waste, it shouldn't be hard to just include a quick and simple feature detection before the polyfill is injected. I don't see any reason why one wouldn't do it.
Quick and simple meaning... are you checking for every feature back to ES3?

The point of this service is that its not requiring the user to know what feature to look for. They'll polyfill anything thats needed. To do feature detection to the level they're trying to serve you'd have to check EVERY API that needs polyfilled on an in-use browser. Full feature detection also involves looking for apis that exist but don't follow the spec. Checking every single API possible on every browser would not be quick and simple. User agents allow them to settle on a list of known needed polyfills without any code needed for the user beyond a simple script tag.

There are definitely tradeoffs to their approach but I can't say "I don't see any reason" why you wouldn't feature detect for this.

They have, apparently. Check it out:

https://cdn.polyfill.io/v1/polyfill.js?features=Array.protot...

Docs about this can be found here: https://cdn.polyfill.io/v1/docs/api

Polyfills won't break your page and random, worse case you get worse performance over native. However the point of a polyfill is to do exactly what the native method would have done if it existed
It will break your page if you aren't sent a polyfill when you should have been. Imagine running a browser without Object.observe, spoofing an agent of one that does have it, and you aren't sent it. Suddenly data-binding doesn't work at all.
Yes but the way mozilla has chosen to implement this is to send the code over the wire based on the clients UA. So if a method doesn't exist that should exist the client will never receive it.

It would be cool if they allowed you to disable this feature, and just use feature detection and always load the code for the requested item.

The polyfill service was created and is hosted by the Financial Times. Mozilla is not affiliated.

There are good reasons why you cannot make a good choice of polyfill prior to knowing the browser family and version, primarily due to polyfill variants (more details in the Hacks post).

It's not just about spoofing user agents. Take third party browsers for iOS for instance - they might be called Chrome or Opera but are really just UIWebViews. If they would add "Chrome" to their user agent string, this solution might break, serving incorrect polyfills. Today these browsers identify as "CriOS" and "OPiOS" to work around broken user agent detection. This can also be a problem with all web browsing happening in embedded webviews (feed readers, reddit apps, ...)
And if you forget to turn Javascript back on things will break too.
>User agent detection sounds great, until you have a user that spoofs their agent.

Yeah, properly serving that 0.01% demographic would be hard...

/s