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

Downgrade User Agent Client Hints to 'harmful'

github.com

Post reply on HN
Print view View original

11–20 of 116 posts

Re: Downgrade User Agent Client Hints to 'harmful'

#11

Post by ocdtrekkie »

Ajedi32 wrote: post #5
marcosdumay wrote: post #3

Earlier quoted context omitted.

Well, if the browsers can just deny those requests, then they can just drop the information entirely. (And they are dropping them from the UA.) From the two non-harmful pieces, one is of interest of all sites, and the other one has the implementation broken on Chrome, so sites will have to use an alternative mechanism anyway. If there's any value on the idea, Google can propose them with a set of information that bri…

I think the idea is that there are some legitimate uses for UA information that they don't want to eliminate entirely, otherwise yeah they could just deprecate the User-Agent header and be done with it.

I think most of the legitimate uses could be solved in a simple statement: Let users know whether the device is mobile or desktop, and then expect websites to send all of the logic to handle the rest client-side, so the server does not need to know.

I'd love to see browser metrics being absolutely devastated as an analytic source: It just is used today as an excuse to only support Chrome.

Re: Downgrade User Agent Client Hints to 'harmful'

#12

Post by Svip »

Ajedi32 wrote: post #2

> Moving stuff around (from User-Agent to Sec-CH-UA-*) doesn't really solve much. That is, having to request this information before getting it doesn't help if sites routinely request all of it. I think this is sort of ignoring the whole point of the proposal. By making sites request this information rather than simply always sending it like the User-Agent header currently does, browsers gain the ability to deny exce…

> browsers gain the ability to deny excessively intrusive requests when they occur

But Set-Cookie kind of proves what happen to that kind of feature. If at first sites gets used to be able to request it and get it, then the browsers that deny anything will simply be ignored. And then those browsers will start providing everything, because they don't want to be left out in the cold.

That's what happened to User-Agent, that's what happened to Set-Cookie, and I can't see why it won't happen to Sec-CH-UA-*. Which the post hints at several times. Set-Cookie was supposed to have the browser ask the user to confirm whether they wanted to set a cookie. Not many clients doing that today.

To be honest, I feel the proposal is a bit naïve if it thinks that websites and all browsers will suddenly be on their best behaviour.

Re: Downgrade User Agent Client Hints to 'harmful'

#13

Post by grishka »

Ajedi32 wrote: post #2

> Moving stuff around (from User-Agent to Sec-CH-UA-*) doesn't really solve much. That is, having to request this information before getting it doesn't help if sites routinely request all of it. I think this is sort of ignoring the whole point of the proposal. By making sites request this information rather than simply always sending it like the User-Agent header currently does, browsers gain the ability to deny exce…

Having to request it is a terrible idea to begin with. If I want to use different templates for mobile vs desktop, I need to know, on the backend, whether the device is a mobile device, and I need it on the very first request. Having to request these headers explicitly is an unnecessary complication that would slow down the first load.

However it is nice that there's now a separate header that gives a yes or no answer on whether it's a mobile device.

Re: Downgrade User Agent Client Hints to 'harmful'

#14

Post by esprehn »

theandrewbailey wrote: post #9

I would rather have all this information (along with whatever is being inferred from them) be exposed through a Javascript API instead of having browsers indiscriminately flood global networks with potential PII. Chrome came up with this? Figures. Stay evil, Google.

Can you explain the attack vector where encrypted HTTPS network traffic is vulnerable but a JS API isn't?

Re: Downgrade User Agent Client Hints to 'harmful'

#15

Post by csmpltn »

> "User Agents MUST return the empty string for model if mobileness is false. User Agents MUST return the empty string for model even if mobileness is true, except on platforms where the model is typically exposed." (quoted from https://wicg.github.io/ua-client-hints/#user-agent-model)

Honestly now - who drafts and approves these specs? Not only does it make no sense whatsoever to encode such information this way - it also results in unimaginable amounts of bandwidth going to complete waste, on a planetary scale.

This is just plain incompetence. How did we let the technology powering the web devolve into this burning pile of nonsense?

Re: Downgrade User Agent Client Hints to 'harmful'

#16

Post by kijin »

Svip wrote: post #12
Ajedi32 wrote: post #2

> Moving stuff around (from User-Agent to Sec-CH-UA-*) doesn't really solve much. That is, having to request this information before getting it doesn't help if sites routinely request all of it. I think this is sort of ignoring the whole point of the proposal. By making sites request this information rather than simply always sending it like the User-Agent header currently does, browsers gain the ability to deny exce…

> browsers gain the ability to deny excessively intrusive requests when they occur But Set-Cookie kind of proves what happen to that kind of feature. If at first sites gets used to be able to request it and get it, then the browsers that deny anything will simply be ignored. And then those browsers will start providing everything, because they don't want to be left out in the cold. That's what happened to User-Agent,…

Yes, this looks like DNT all over again. Just another header that quickly becomes meaningless, wasting terabytes of bandwidth all over the world for no good reason.

Re: Downgrade User Agent Client Hints to 'harmful'

#18

Post by dmitriid »

csmpltn wrote: post #15

> "User Agents MUST return the empty string for model if mobileness is false. User Agents MUST return the empty string for model even if mobileness is true, except on platforms where the model is typically exposed." (quoted from https://wicg.github.io/ua-client-hints/#user-agent-model ) Honestly now - who drafts and approves these specs? Not only does it make no sense whatsoever to encode such information this way -…

Drafts: Google

Approves: no one.

Chrome just releases them in stable versions with little to no discussion, and the actual specs remain in draft stages.

Edit: grammar

Re: Downgrade User Agent Client Hints to 'harmful'

#19

Post by theandrewbailey »

esprehn wrote: post #14
theandrewbailey wrote: post #9

I would rather have all this information (along with whatever is being inferred from them) be exposed through a Javascript API instead of having browsers indiscriminately flood global networks with potential PII. Chrome came up with this? Figures. Stay evil, Google.

Can you explain the attack vector where encrypted HTTPS network traffic is vulnerable but a JS API isn't?

Your browser opens an encrypted connection to somewhere you don't want it to (e.g. loads an image or iframe, JS not required). How many connections and resources does a normal web page load? 100? More? Almost nobody has time to audit all of them. Not technically inclined? You're screwed.

My secondary concern is that there would be more traffic going around the internet that isn't being used 99+% of the time.

Re: Downgrade User Agent Client Hints to 'harmful'

#20

Post by ThePadawan »

dmitriid wrote: post #17

> I'm not sure why you used such an old Chrome version to test this. That quote from the first comment on the issue is just a cherry on top. Chrome 88 was released in December 2020. 7 months ago.

I'm going to cut them some slack since December 2020 feels both 2 weeks and 4 years ago.
Post reply on HN