Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UA Gotta Be Kidding

bkardell.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: UA Gotta Be Kidding

#51

Post by phkahler »

aib wrote: post #5

Is there something like a "capabilities declaration" in the works to actually solve the problem? You know, something like a "X-I-Support: images, frames, ecma6, vr, xss" header? I could even imagine an "assigned capability strings" database and x- prefixes and all, but it's probably an old fool's dream in these fast-m— thing-breaking times.

IMHO capability strings is also a bad idea. At best (and I'm still not a fan) they could spec HTTP 2.0 or HTTP 4.0. If there are odd features they're not compliant with then either get with the program and fix their browser, or don't claim that level of support.

Most of the problem here is failure to adhere to standards.

Re: UA Gotta Be Kidding

#52

Post by rollcat »

donatj wrote: post #46
mike_hearn wrote: post #19

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Saf…

You can’t even tell iPadOS from macOS anymore, which was a major problem for us. Our mobile website is full of essentially “Do this in the mobile app” buttons that only show up on mobile devices. Suddenly we had to rewrite it all to be done with JS rather than server side because there’s no way to detect iPads server side anymore. Even then our JS test for iPad is essentially “Is a Mac” && “Supports Multitouch” which…

The ARM Macs are pretty decent at running iPad apps. I think there's less and less valid reasons to distinguish the two.

Re: UA Gotta Be Kidding

#53

Post by zagrebian »

sysadm1n wrote: post #47

> Of course, a side effect of all of this is that ultimately all of those simple variants in the UA and work that goes into those giant databases mean that we could know an awful lot about you, by default. So that's not great. I encourage anyone who's using Firefox to turn the `privacy.Resistfingerprinting` setting to `true`. It gives you a generic Windows 10 useragent with an old version of Firefox. The Tor Browser…

> privacy.Resistfingerprinting

Does it have any negative side-effects?

Re: UA Gotta Be Kidding

#54

Post by dicethrowaway1 »

zagrebian wrote: post #53
sysadm1n wrote: post #47

> Of course, a side effect of all of this is that ultimately all of those simple variants in the UA and work that goes into those giant databases mean that we could know an awful lot about you, by default. So that's not great. I encourage anyone who's using Firefox to turn the `privacy.Resistfingerprinting` setting to `true`. It gives you a generic Windows 10 useragent with an old version of Firefox. The Tor Browser…

> privacy.Resistfingerprinting Does it have any negative side-effects?

Since the generic fingerprint is associated with Tor, you get a lot more captchas. And JS that shows event times based on your clock (say a schedule) will think your time zone is UTC.

Re: UA Gotta Be Kidding

#55

Post by sysadm1n »

zagrebian wrote: post #53
sysadm1n wrote: post #47

> Of course, a side effect of all of this is that ultimately all of those simple variants in the UA and work that goes into those giant databases mean that we could know an awful lot about you, by default. So that's not great. I encourage anyone who's using Firefox to turn the `privacy.Resistfingerprinting` setting to `true`. It gives you a generic Windows 10 useragent with an old version of Firefox. The Tor Browser…

> privacy.Resistfingerprinting Does it have any negative side-effects?

Yeah it breaks some sites and extensions. There's more info on browser fingerprinting here: https://restoreprivacy.com/browser-fingerprinting/

It doesn't just spoof the UA, it does some other things too. Not sure what they are. It's part of the Tor Uplift[0] initiative.

[0] https://wiki.mozilla.org/Security/Tor_Uplift

Re: UA Gotta Be Kidding

#56

Post by lupire »

mike_hearn wrote: post #19

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Saf…

There is the Accept header which isn't perfect but would be a better thing to abuse.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

Re: UA Gotta Be Kidding

#57

Post by lupire »

pjc50 wrote: post #24
mike_hearn wrote: post #19

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Saf…

> Really there's nothing wrong with having a UA header but it gets abused because HTTP never had any standardized way to communicate feature sets. It should have had both. A way to identify specific apps for bug workarounds etc, and a way to communicate what versions and parts of the specs are implemented. The problems with this is that it's an adversarial market. It's not quite as bad as it used to be, now that ther…

> incentive for browser to lie about capabilities

Such as?

Re: UA Gotta Be Kidding

#58

Post by lupire »

jstanley wrote: post #36
mike_hearn wrote: post #19

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Saf…

> you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Safari users (much slower downloads), or give up and ask the user which to pick. But the computer they download the application on isn't necessarily the computer they'll run it on anyway, so you still need to give the user the option to pick.

Fine, but 99% of the time the user does want the locally compatible version, and this is especially true for naive users who don't understand the differences and need more help to make a good choice. So they benefit from a well-chosen prominent default.

Re: UA Gotta Be Kidding

#59

Post by lupire »

wongarsu wrote: post #33
mike_hearn wrote: post #19

The whole privacy-through-UA thing maybe gone too far though. Safari on M1 Mac identifies itself as Intel Safari. A web server knowing whether you use an older or newer Mac is not going hurt anyone, but the lack of it does hurt the UX of distributing Mac apps. For download size reasons you really want to give the user a build for the right CPU architecture, but due to this lie you have to either ship a fat app to Saf…

> HTTP never had any standardized way to communicate feature sets Except for the "Accept", "Accept-Language", "Accept-Encoding" and "Accept-Charset" headers (the last is phased out because UTF-8 is now used universally). I don't think extending it much further than that is reasonable without introducing some binary encoding for a giant bitmap, and even that would eat more bandwidth than it's worth.

The alternative is shipping a packet of sketchy JS, which is much more bandwidth.

Re: UA Gotta Be Kidding

#60

Post by Aissen »

I feel like the 90% use case could be fixed with a clean js feature detection API from browsers. Basically caniuse.com, but programmatically accessible. Any new feature must have a name, and sub-names for granularity. Any difference of implementation between major UAs must be given names.

It does not need to be in headers, anyone wanting that could take the latency hit of a pre-detection js page. My 2cts.

Post reply on HN