Live data from Hacker News

Downgrade User Agent Client Hints to 'harmful'

github.com

31–40 of 116 posts

Re: Downgrade User Agent Client Hints to 'harmful'

#32
post #5

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.

Yes, I got that from your post. It's just that for Google, proposing it again with harmless content is very easy, but for anybody else to filter the bad content once the Google proposal gets accepted is almost impossible. (Although, if I was working on Firefox, I would just copy the most common data from Chrome, adjusting for those 2 fields that matter. That would create problems, but it's the less problematic choice.)

So, no, it should be rejected. Entirely and severely. It doesn't mean that contextual headers are a bad practice, it's just that this one proposal is bad.

Re: Downgrade User Agent Client Hints to 'harmful'

#34

> 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.

Because when you’re implementing a new spec that is still in “draft” status and constantly being updated, things could have changed drastically in 7 months and 4 major versions?

Re: Downgrade User Agent Client Hints to 'harmful'

#35

Earlier quoted context omitted.

> 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. No worries, that's why we have laws to make the website do in the content what the browser no longer wants to do in the viewer. ;D

Having the browser explicitly prompt for cookies is neither necessary nor sufficient to do what strong, consistently-enforced privacy laws can do, because the browser can't tell a tracking cookie (which needs a prompt) apart from a settings cookie (which does not).

That would be an extension or fork of Set-Cookie.

Re: Downgrade User Agent Client Hints to 'harmful'

#36
post #26

Earlier quoted context omitted.

Unless a big vendor (coff Microsoft coff) decides to enable it by default, them it becomes meaningless.

It was meaningless from the beginning: DNT was always nothing but an Evil Bit. You’re getting mad at Microsoft for pointing out that the emperor had no clothes.

It was an Evil Bit becaut it didn't have the force of law behind it. Now we have cookie laws.

Re: Downgrade User Agent Client Hints to 'harmful'

#37

I'm late to the ballgame, but what does "Sec-" mean as a HTTP header prefix anyway? I am failing at googling.

It means the browser is in control of the header, and not some script. From https://datatracker.ietf.org/doc/html/rfc8942 :

   Authors of new Client Hints are advised to carefully consider whether
   they need to be able to be added by client-side content (e.g.,
   scripts) or whether the Client Hints need to be exclusively set by
   the user agent.  In the latter case, the Sec- prefix on the header
   field name has the effect of preventing scripts and other application
   content from setting them in user agents.  Using the "Sec-" prefix
   signals to servers that the user agent -- and not application content
   -- generated the values.  See [FETCH] for more information.
As near as I can tell, the bit they're talking about in the Fetch standard is just this:

    These are forbidden so the user agent remains in full control over them. 
    Names starting with `Sec-` are reserved to allow new headers to be minted 
    that are safe from APIs using fetch that allow control over headers by 
    developers, such as XMLHttpRequest.

Re: Downgrade User Agent Client Hints to 'harmful'

#38
post #29
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…

Yes, I wish they would engage with how this fits into the rest of the Privacy Sandbox proposal ( https://www.chromium.org/Home/chromium-privacy/privacy-sandb... ). My understanding is it's: 1. Move entropy from "you get it by default" to "you have to ask for it". 2. Add new APIs that allow you to do things that previously exposed a lot of entropy in a more private way. 3. Add a budget for the total amount of entropy…

I think pretty much all browsers and a lot of web platforms made it clear in their response to FLoC that everyone except Google (and Twitter, I guess?) considers Privacy Sandbox to be harmful as a whole.

Re: Downgrade User Agent Client Hints to 'harmful'

#39
post #27
post #24

Earlier quoted context omitted.

It could, but as someone who has spoofed user-agents in the past (primarily to get Chrome-only websites to cooperate) I would prefer if it wouldn't. If the baddies can snoop my https traffic or directly copy the auth cookies from my machine then also copying my user-agent isn't that big of a step for them. One might argue that detecting changes in user agents could be part of some kind of defense in depth strategy, b…

That's the whole point of RBA, though. That two requests have the same user agent doesn't tell me much, but if you have two different user agents from two different IPs that may sound really risky (use case dependent, of course).

Unless someone is sitting at their desktop computer with their phone connection to 4G...

Privacy initiatives will probably make some risk-based authentication tricks break, but they probably weren't robust methods anyways.

Re: Downgrade User Agent Client Hints to 'harmful'

#40
post #7

> Sec-CH-UA-Model provides a lot of identifying bits on Android and leads... intentional?

Is there a typo or a pun or something I'm not seeing?

Knowing the exact make and model of an Android device is a lot higher entropy than knowing the exact make and model of an iPhone.

Post reply on HN