14 ms·

Downgrade User Agent Client Hints to 'harmful'

150 points by ronancremin 5y ago

Ajedi32 5y ago
> 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 excessively intrusive requests when they occur. That is to say, "sites routinely request all of it" is precisely the problem this proposal is intended to solve. There are some good points in this post about things which can be improved with specific Sec-CH-UA headers, but the overall position seems to be based on a failed understanding of the purpose of client hints.
- marcosdumay 5y ago
  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 brings value, instead of just fingerprinting people.
  - Ajedi32 5y ago
    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.
    - ocdtrekkie 5y ago
      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.
      - blowski 5y ago
        Risk-based authentication can use a change in user agent as an increased risk factor.
        Thiez 5y ago
        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, but as a user I imagine I'm already so boned in that scenario that I doubt it would save me. So overall such a mechanism would bring me more inconvenience than security.
        blowski 5y ago
        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).
        ocdtrekkie 5y ago
        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.
    - marcosdumay 5y ago
      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.
- jsbdk 5y ago
  >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 excessively intrusive requests when they occur. Browsers can just not send a UA header
  - tremon 5y ago
    I tried this. It breaks a surprisingly large number of sites (or perhaps not-so-surprisingly), and good luck trying to beat Google's captcha without a User-Agent header.
    - avian 5y ago
      Good luck trying to beat ReCaptcha if you're doing anything that puts you outside of the normal web browser behavior as imagined by Google's Algorithm. If User Agent Client Hints become the new normal, I'm sure anyone excessively denying requests will be flagged in the same way.
- Svip 5y ago
  > 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.
  - kijin 5y ago
    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.
    - wolverine876 5y ago
      DNT does nothing technically, but it has political power and that's where privacy happens to a great degree. When 70% of users say 'do not track me', it is hard to claim that they don't care about privacy.
      - m45t3r 5y ago
        Unless a big vendor (coff Microsoft coff) decides to enable it by default, them it becomes meaningless.
        Analemma_ 5y ago
        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.
- grishka 5y ago
  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.
  - hypertele-Xii 5y ago
    Why would you need different templates for mobile/desktop? CSS is quite capable responding to any screen orientation.
    - jenscow 5y ago
      You're not wrong. However, there are times when CSS isn't enough. For example: - The Mobile vs Desktop design differences are too great. - The site was originally created without considering mobile, and retrofitting mobile support is unfeasible.
      - hypertele-Xii 5y ago
        Can you expand on the design differences?
    - grishka 5y ago
      Yes it is. Except you can't use the same markup for both because the input devices, and thus interaction paradigms, are so radically different. Mice are precise and capable of hovering over things, so it makes sense to pack everything densely and add various tooltips and popup menus. Touchscreens are imprecise and don't have anything resembling hovering, so UI elements must be large, with enough padding around them, and with menus appearing on click.
      - WorldMaker 5y ago
        Between CSS Flexbox and CSS Grid there shouldn't any reasons today that you can't handle 100% of those differences with the same markup and media stylesheets. (There's also obviously JS if you really must contort the HTML DOM to get what you want.)
- jefftk 5y ago
  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-sandbox 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 a site is allowed to get for a user, preventing identifying users across sites through fingerprinting. Client hints are part of step #1. Not especially useful on its own, but when later combined with #3 sites now have a strong incentive to reduce what they ask for to just what they need. (Disclosure: I work on ads at Google, speaking only for myself)
  - ocdtrekkie 5y ago
    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.
    - jefftk 5y ago
      Objections to FLoC are basically about what should be included in #2. I don't understand why people would be opposed to #1 or #3 though?
      - ocdtrekkie 5y ago
        It's a fundamental disagreement on the very idea: Google's position is that it's okay for a website to know X amount of data about a user, you know, as long as it doesn't, in total, cross the creepy line. Everyone else's position is that if the data isn't required to operate, you don't need it. If we accept that the User Agent, as it is going to be frozen, is going to be served anyways to avoid breaking the legacy web, very little of this proposal adds value, and much of it adds harm. It isn't practical to move to not serving the User Agent, so any replacement for the data in it is pointless at it's very best. The frozen UA provides enough to determine if someone is mobile, the only real need for UA strings. And when most browsers are looking at reducing the tools for websites to fingerprint, Google is introducing new ones. So Firefox's position on Privacy Sandbox as a whole is pretty logical: If it's optional enough to be requested, why offer it at all? The entire premise of Privacy Sandbox is that it wants sites to have access to some amount of information about the user, and the position of every non-Google-browser is that they want to give sites as close to no data at all as possible. This is the core of the problem with a single company being legally permitted to operate a web browser and an ad company. Every single browser developer that doesn't own an Ads and Analytics suite is opposed to Privacy Sandbox.
- 1vuio0pswjnm7 5y ago
  "By making sites request this information rather than simply sending it like the User-Agent header currently does..." This is also true with respect to SNI which leaks the domain name in clear text on the wire. The popular browsers send it even when it is not required. The forward proxy configuration I wrote distinguishes the sites (CDNs) that actually need SNI and the proxy only sends it when required. The majority of websites submitted to HN do not need it. I also require TLSv1.3 and strip out unecessary headers. It all works flawlessly with very few exceptions. We could argue that sending so much unecessary information as popular browsers do when technically it is not necessary for the user is user hostile. It is one-sided. "Tech" companies and others interested in online advertising have been using this data to their advantage for decades.
  - billyhoffman 5y ago
    How would this work? SNI is sent by the client in the initial part of the TLS handshake. If you don't send it, the server sends the wrong/bad cert. The client could retry the handshake using SNI to get the correct cert but: - This adds an extra RTT, on the critical path of getting the base HTML, hurting performance. - A MITM could send back an invalid cert, causing the browser to retry with SNI, leaking it anyway (since we aren't talking about TLS 1.3 and an encrypted SNI). I suppose the client could maintain a list of sites that don't need SNI, like the HSTS preload list, but that seems like a ton of overhead to avoid sending unneeded SNI, especially when most DNS is unencrypted and would leak the hostname just like SNI anyways.
    - 1vuio0pswjnm7 5y ago
      "I suppose the client could maintain a list of sites that don't need SNI." That list would be much larger than the list of sites that do require SNI. Generally, I can determine whether SNI is required by IP address, i.e., whether it belongs to a CDN that requires SNI. Popular CDNs like AWS publish lists of their public IPs. I use TLSv1.3 plus ESNI with Cloudflare but they are currently the only CDN that supports it. Experimental but works great, IME. The proxy maintains the list not the browser. The proxy is designed for this and can easily hold lists of 10s of 1000s of domains in memory. That's more domains than I visit in one day, week, month or year. Is it not a question of whether this is possible. "How would this work". I have already implemented it. It works. It is not difficult to set up. Why this works for me and would unlikely work for others. I am not a heavy user of popular browsers, I "live on the command line". Installing a custom root certificate with appropriate SANs to suppress browser warnings is a nusiance that would likely dissuade others since they are heavy users of those programs. However I generally do not use those browsers to retrieve content from the web.
fnord77 5y ago
> Sec-CH-UA-Model provides a lot of identifying bits on Android and leads... intentional?
- mort96 5y ago
  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.
deleted 5y ago
[deleted]
theandrewbailey 5y ago
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.
- esprehn 5y ago
  Can you explain the attack vector where encrypted HTTPS network traffic is vulnerable but a JS API isn't?
  - theandrewbailey 5y ago
    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.
- daveoc64 5y ago
  A JavaScript API has been considered as a replacement for the user agent string, but it has two big downsides: 1) JavaScript must be enabled. If it's not, then the server can't get any of the user agent data - at all. 2) The server won't get the user agent data until after it has already responded to the first request it receives from a client. That makes it a lot less useful overall. Having to load a page, then perhaps redirect the user using JS based on what the JS API says is a bit untidy.
- jedimastert 5y ago
  There is a JS companion to this proposal that splits up the information in a similar way https://wicg.github.io/ua-client-hints/#interface https://wicg.github.io/ua-client-hints/#interface
csmpltn 5y ago
> "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 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?
- dmitriid 5y ago
  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
- joshuamorton 5y ago
  Why/how does this waste bandwidth? These are opt-in, so they are only sent if requested. I mean sure http being plaintext is silly but that's not down to the authors of this particular rfc.
  - csmpltn 5y ago
    > "These are opt-in, so they are only sent if requested." Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds? > "Why/how does this waste bandwidth?" Based on the current proposal - non-mobile browsers or browsers that simply do not wish to expose the specific model are somehow required to return the following header in response: Sec-CH-UA-Model: "" Those are 19 absolutely useless bytes. Wouldn't it make more sense to simply omit the header from the response altogether? It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data.
dmitriid 5y ago
> 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.
- ThePadawan 5y ago
  I'm going to cut them some slack since December 2020 feels both 2 weeks and 4 years ago.
- oefrha 5y 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?
  - dmitriid 5y ago
    Chrome releases a new major version once every two months. It's not the job of Mozilla to reverse engineer Google's internal processes and figure out which version is "extremely old one". And no, 6-7 months do not a "very old version" make. It's also a very good thing that Mozilla picked version 88. It had all the described problems and Chrome still shipped this draft spec with known issues enabled by default in the very next version. v88 was the last version that had this behind a feature flag. Now that it's enabled by default, devs will rely on it and Chrome will refuse to change it because "once it's out we can't change it". Good on Mozilla to call bullshit on Google (and not for the first time).
admax88q 5y ago
Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.
- ocdtrekkie 5y ago
  This is unfortunately the world of web apps, where a URI just gets you to the app, and the content within is dynamic.
  - admax88q 5y ago
    Even with web apps, you can serve the same app from the same URI. URI doesn't imply static content. Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.
    - ocdtrekkie 5y ago
      I get that. I do think by and large, the user's agent (the browser) should be making display and format decisions based on itself, rather than the server serving different content. Though I think the exception is mobile, where we probably shouldn't serve the client endless garbage it doesn't need. I mostly think the replacement for user agent should be a boolean of mobile or not mobile. And everything else should be dynamically handled by the client.
      - admax88q 5y ago
        Honestly though, if its enough content for mobile, its enough content for desktop as well. The "garbage" we don't want to serve mobile, is often also garbage for desktop, autoplay videos, too many tracking scripts, etc. If we force people to optimize their site for mobile and desktop then maybe we'll actually get good desktop sites.
        ocdtrekkie 5y ago
jrochkind1 5y ago
I'm late to the ballgame, but what does "Sec-" mean as a HTTP header prefix anyway? I am failing at googling.
- banana_giraffe 5y ago
  It means the browser is in control of the header, and not some script. From https://datatracker.ietf.org/doc/html/rfc8942 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.
  - sdflhasjd 5y ago
    Does it stand for something? Why the letters 'Sec'?
    - banana_giraffe 5y ago
      I don't think I've ever seen it called out, but I always assumed it's "Secure" in the sense it hasn't been modified by a script. But that's 100% a guess on my part.
      - herpderperator 5y ago
        Great, so now we have the HttpOnly flag for cookies which differs from the Secure flag for cookies, while the Secure in the Sec headers has the same meaning as HttpOnly.
justshowpost 5y ago
> UA Client Hints proposes that information derived from the User Agent header field could only be sent to servers that specifically request that information, specifically to reduce the number of parties that can passively fingerprint users using that information. We find that the addition of new information about the UA, OS, and device to be harmful as it increases the information provided to sites for fingerprinting, without a commensurate improvements in functionality or accountability to justify that. In addition to not including this information, we would prefer freezing the User Agent string and only providing limited information via the proposed NavigatorUAData interface JS APIs. This would also allow us to audit the callers. At this time, freezing the User Agent string without any client hints (which is not this proposal) seems worth prototyping. We look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility. https://mozilla.github.io/standards-positions/#ua-client-hints https://mozilla.github.io/standards-positions/#ua-client-hin...
daveoc64 5y ago
I hope they avoid situations like the SameSite=None debacle[0] if they are going to freeze the User Agent header and not provide an alternative. The assertion of Mozilla seems to be: >At the time sites deploy a workaround, they can’t necessarily know what future browser version won’t have the need for the workaround. Can we guarantee only retrospective use? Do Web developers care enough about retrospective workarounds for evergreen browsers? When there are significant numbers of users on devices like iPads that don't get updated any more, you can't rely on "evergreen browsers". [0] - https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...

150 points by ronancremin 5y ago

> 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 excessively intrusive requests when they occur. That is to say, "sites routinely request all of it" is precisely the problem this proposal is intended to solve. There are some good points in this post about things which can be improved with specific Sec-CH-UA headers, but the overall position seems to be based on a failed understanding of the purpose of client hints.

marcosdumay 5y ago
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 brings value, instead of just fingerprinting people.
- Ajedi32 5y ago
  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.
  - ocdtrekkie 5y ago
    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.
    - blowski 5y ago
      Risk-based authentication can use a change in user agent as an increased risk factor.
      - Thiez 5y ago
        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, but as a user I imagine I'm already so boned in that scenario that I doubt it would save me. So overall such a mechanism would bring me more inconvenience than security.
        blowski 5y ago
        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).
        ocdtrekkie 5y ago
        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.
  - marcosdumay 5y ago
    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.
jsbdk 5y ago
>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 excessively intrusive requests when they occur. Browsers can just not send a UA header
- tremon 5y ago
  I tried this. It breaks a surprisingly large number of sites (or perhaps not-so-surprisingly), and good luck trying to beat Google's captcha without a User-Agent header.
  - avian 5y ago
    Good luck trying to beat ReCaptcha if you're doing anything that puts you outside of the normal web browser behavior as imagined by Google's Algorithm. If User Agent Client Hints become the new normal, I'm sure anyone excessively denying requests will be flagged in the same way.
Svip 5y ago
> 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.
- kijin 5y ago
  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.
  - wolverine876 5y ago
    DNT does nothing technically, but it has political power and that's where privacy happens to a great degree. When 70% of users say 'do not track me', it is hard to claim that they don't care about privacy.
    - m45t3r 5y ago
      Unless a big vendor (coff Microsoft coff) decides to enable it by default, them it becomes meaningless.
      - Analemma_ 5y ago
        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.
grishka 5y ago
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.
- hypertele-Xii 5y ago
  Why would you need different templates for mobile/desktop? CSS is quite capable responding to any screen orientation.
  - jenscow 5y ago
    You're not wrong. However, there are times when CSS isn't enough. For example: - The Mobile vs Desktop design differences are too great. - The site was originally created without considering mobile, and retrofitting mobile support is unfeasible.
    - hypertele-Xii 5y ago
      Can you expand on the design differences?
  - grishka 5y ago
    Yes it is. Except you can't use the same markup for both because the input devices, and thus interaction paradigms, are so radically different. Mice are precise and capable of hovering over things, so it makes sense to pack everything densely and add various tooltips and popup menus. Touchscreens are imprecise and don't have anything resembling hovering, so UI elements must be large, with enough padding around them, and with menus appearing on click.
    - WorldMaker 5y ago
      Between CSS Flexbox and CSS Grid there shouldn't any reasons today that you can't handle 100% of those differences with the same markup and media stylesheets. (There's also obviously JS if you really must contort the HTML DOM to get what you want.)
jefftk 5y ago
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-sandbox 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 a site is allowed to get for a user, preventing identifying users across sites through fingerprinting. Client hints are part of step #1. Not especially useful on its own, but when later combined with #3 sites now have a strong incentive to reduce what they ask for to just what they need. (Disclosure: I work on ads at Google, speaking only for myself)
- ocdtrekkie 5y ago
  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.
  - jefftk 5y ago
    Objections to FLoC are basically about what should be included in #2. I don't understand why people would be opposed to #1 or #3 though?
    - ocdtrekkie 5y ago
      It's a fundamental disagreement on the very idea: Google's position is that it's okay for a website to know X amount of data about a user, you know, as long as it doesn't, in total, cross the creepy line. Everyone else's position is that if the data isn't required to operate, you don't need it. If we accept that the User Agent, as it is going to be frozen, is going to be served anyways to avoid breaking the legacy web, very little of this proposal adds value, and much of it adds harm. It isn't practical to move to not serving the User Agent, so any replacement for the data in it is pointless at it's very best. The frozen UA provides enough to determine if someone is mobile, the only real need for UA strings. And when most browsers are looking at reducing the tools for websites to fingerprint, Google is introducing new ones. So Firefox's position on Privacy Sandbox as a whole is pretty logical: If it's optional enough to be requested, why offer it at all? The entire premise of Privacy Sandbox is that it wants sites to have access to some amount of information about the user, and the position of every non-Google-browser is that they want to give sites as close to no data at all as possible. This is the core of the problem with a single company being legally permitted to operate a web browser and an ad company. Every single browser developer that doesn't own an Ads and Analytics suite is opposed to Privacy Sandbox.
1vuio0pswjnm7 5y ago
"By making sites request this information rather than simply sending it like the User-Agent header currently does..." This is also true with respect to SNI which leaks the domain name in clear text on the wire. The popular browsers send it even when it is not required. The forward proxy configuration I wrote distinguishes the sites (CDNs) that actually need SNI and the proxy only sends it when required. The majority of websites submitted to HN do not need it. I also require TLSv1.3 and strip out unecessary headers. It all works flawlessly with very few exceptions. We could argue that sending so much unecessary information as popular browsers do when technically it is not necessary for the user is user hostile. It is one-sided. "Tech" companies and others interested in online advertising have been using this data to their advantage for decades.
- billyhoffman 5y ago
  How would this work? SNI is sent by the client in the initial part of the TLS handshake. If you don't send it, the server sends the wrong/bad cert. The client could retry the handshake using SNI to get the correct cert but: - This adds an extra RTT, on the critical path of getting the base HTML, hurting performance. - A MITM could send back an invalid cert, causing the browser to retry with SNI, leaking it anyway (since we aren't talking about TLS 1.3 and an encrypted SNI). I suppose the client could maintain a list of sites that don't need SNI, like the HSTS preload list, but that seems like a ton of overhead to avoid sending unneeded SNI, especially when most DNS is unencrypted and would leak the hostname just like SNI anyways.
  - 1vuio0pswjnm7 5y ago
    "I suppose the client could maintain a list of sites that don't need SNI." That list would be much larger than the list of sites that do require SNI. Generally, I can determine whether SNI is required by IP address, i.e., whether it belongs to a CDN that requires SNI. Popular CDNs like AWS publish lists of their public IPs. I use TLSv1.3 plus ESNI with Cloudflare but they are currently the only CDN that supports it. Experimental but works great, IME. The proxy maintains the list not the browser. The proxy is designed for this and can easily hold lists of 10s of 1000s of domains in memory. That's more domains than I visit in one day, week, month or year. Is it not a question of whether this is possible. "How would this work". I have already implemented it. It works. It is not difficult to set up. Why this works for me and would unlikely work for others. I am not a heavy user of popular browsers, I "live on the command line". Installing a custom root certificate with appropriate SANs to suppress browser warnings is a nusiance that would likely dissuade others since they are heavy users of those programs. However I generally do not use those browsers to retrieve content from the web.

fnord77 5y ago

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

mort96 5y ago
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.

deleted 5y ago

[deleted]

theandrewbailey 5y ago

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.

esprehn 5y ago
Can you explain the attack vector where encrypted HTTPS network traffic is vulnerable but a JS API isn't?
- theandrewbailey 5y ago
  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.
daveoc64 5y ago
A JavaScript API has been considered as a replacement for the user agent string, but it has two big downsides: 1) JavaScript must be enabled. If it's not, then the server can't get any of the user agent data - at all. 2) The server won't get the user agent data until after it has already responded to the first request it receives from a client. That makes it a lot less useful overall. Having to load a page, then perhaps redirect the user using JS based on what the JS API says is a bit untidy.
jedimastert 5y ago
There is a JS companion to this proposal that splits up the information in a similar way https://wicg.github.io/ua-client-hints/#interface https://wicg.github.io/ua-client-hints/#interface

csmpltn 5y ago

> "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 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?

dmitriid 5y ago
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
joshuamorton 5y ago
Why/how does this waste bandwidth? These are opt-in, so they are only sent if requested. I mean sure http being plaintext is silly but that's not down to the authors of this particular rfc.
- csmpltn 5y ago
  > "These are opt-in, so they are only sent if requested." Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds? > "Why/how does this waste bandwidth?" Based on the current proposal - non-mobile browsers or browsers that simply do not wish to expose the specific model are somehow required to return the following header in response: Sec-CH-UA-Model: "" Those are 19 absolutely useless bytes. Wouldn't it make more sense to simply omit the header from the response altogether? It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data.

dmitriid 5y ago

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

ThePadawan 5y ago
I'm going to cut them some slack since December 2020 feels both 2 weeks and 4 years ago.
oefrha 5y 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?
- dmitriid 5y ago
  Chrome releases a new major version once every two months. It's not the job of Mozilla to reverse engineer Google's internal processes and figure out which version is "extremely old one". And no, 6-7 months do not a "very old version" make. It's also a very good thing that Mozilla picked version 88. It had all the described problems and Chrome still shipped this draft spec with known issues enabled by default in the very next version. v88 was the last version that had this behind a feature flag. Now that it's enabled by default, devs will rely on it and Chrome will refuse to change it because "once it's out we can't change it". Good on Mozilla to call bullshit on Google (and not for the first time).

admax88q 5y ago

Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.

ocdtrekkie 5y ago
This is unfortunately the world of web apps, where a URI just gets you to the app, and the content within is dynamic.
- admax88q 5y ago
  Even with web apps, you can serve the same app from the same URI. URI doesn't imply static content. Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.
  - ocdtrekkie 5y ago
    I get that. I do think by and large, the user's agent (the browser) should be making display and format decisions based on itself, rather than the server serving different content. Though I think the exception is mobile, where we probably shouldn't serve the client endless garbage it doesn't need. I mostly think the replacement for user agent should be a boolean of mobile or not mobile. And everything else should be dynamically handled by the client.
    - admax88q 5y ago
      Honestly though, if its enough content for mobile, its enough content for desktop as well. The "garbage" we don't want to serve mobile, is often also garbage for desktop, autoplay videos, too many tracking scripts, etc. If we force people to optimize their site for mobile and desktop then maybe we'll actually get good desktop sites.
      - ocdtrekkie 5y ago

jrochkind1 5y ago

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

banana_giraffe 5y ago
It means the browser is in control of the header, and not some script. From https://datatracker.ietf.org/doc/html/rfc8942 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.
- sdflhasjd 5y ago
  Does it stand for something? Why the letters 'Sec'?
  - banana_giraffe 5y ago
    I don't think I've ever seen it called out, but I always assumed it's "Secure" in the sense it hasn't been modified by a script. But that's 100% a guess on my part.
    - herpderperator 5y ago
      Great, so now we have the HttpOnly flag for cookies which differs from the Secure flag for cookies, while the Secure in the Sec headers has the same meaning as HttpOnly.

justshowpost 5y ago

> UA Client Hints proposes that information derived from the User Agent header field could only be sent to servers that specifically request that information, specifically to reduce the number of parties that can passively fingerprint users using that information. We find that the addition of new information about the UA, OS, and device to be harmful as it increases the information provided to sites for fingerprinting, without a commensurate improvements in functionality or accountability to justify that. In addition to not including this information, we would prefer freezing the User Agent string and only providing limited information via the proposed NavigatorUAData interface JS APIs. This would also allow us to audit the callers. At this time, freezing the User Agent string without any client hints (which is not this proposal) seems worth prototyping. We look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility. https://mozilla.github.io/standards-positions/#ua-client-hints https://mozilla.github.io/standards-positions/#ua-client-hin...

daveoc64 5y ago

I hope they avoid situations like the SameSite=None debacle[0] if they are going to freeze the User Agent header and not provide an alternative. The assertion of Mozilla seems to be: >At the time sites deploy a workaround, they can’t necessarily know what future browser version won’t have the need for the workaround. Can we guarantee only retrospective use? Do Web developers care enough about retrospective workarounds for evergreen browsers? When there are significant numbers of users on devices like iPads that don't get updated any more, you can't rely on "evergreen browsers". [0] - https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...