Hacker News Reader

Comment by devit | Hacker News Reader

How about doing this but also NOT providing the client hints API and NOT providing any way for JavaScript to explicitly ask for OS and browser product name and version?

While browser and JavaScript engines are likely to continue being detectable due to behavior and performance for the foreseeable future, it's probably possible to make the OS, browser frontend and exact engine version undetectable.

View on HN

Browser vendor/version is hugely important information for triaging issues and implementing progressive enhancement approaches on large scale websites.

Perhaps, but it invalidates most of their stated reasons for doing this. Which makes the post a confusing read.

IMO it’s explained better in the Client Hints specification.

Client hints are not any more useful than traditional UA for privacy or progressive enhancement. Its the same content, just split up. Any browser not sending everything will have atrocious permission UX, nagging websites or just get the broken IE5 version.

UA hints solve nothing, even after reading the spec

> it invalidates most of their stated reasons

The "main advantages" section for client hints all seem to apply there.

Triaging issues, sure. Progressive enhancement? If you’re parsing User-Agent to implement that, you’re doing it wrong. (Feature detection is the correct approach, when necessary.)

There are cases like IndexedDB bugs in certain versions of Safari that are very hard to feature detect...

Here's an official Google page telling you to sniff UAs or their new feature will break everything: https://www.chromium.org/updates/same-site/incompatible-clie...

Edit: OK, this isn't progressive enhancement. But it's still a major problem you have to sniff the User-Agent for. I don't want to sniff UAs either but when Chrome is wont to change how fundamental parts of the web work like cookies it's sometimes necessary. I know UA hints will still allow you to do this, but requiring a second request is going to make things like redirect pages difficult to implement.

SameSite=None isn’t progressive enhancement.

You're right, I should have replied elsewhere. By the way, if anyone knows what this _is_ called I would be interested to know. As far as I can see it's basically feature detection with no other way of detecting it besides the UA.

Can’t feature detect during SSR, so making an educated guess and falling back gracefully (when possible—many times it just isn’t, as with ES6 syntax) is important to get initial page load right by default.

Because so many people abused the user agent header for things that could gracefully fall back (or they just made invalid assumptions from it) it was made an unreliable indicator for times you actually want to send shimmed content on first load.

Seems to be the Firefox plan according to the text.

How do you propose, without some sort of browser and os detection and version to address specific bugs for those environments? Just leave a site/app broken for a few months until/if/when the browser fixes the bug?

Reply on news.ycombinator.com