6 ms·

> I don't really understand how this will result in any real difference in privacy or homogeneity of the web. It does a little: sites don't passively receive t

by untog 7y ago

> I don't really understand how this will result in any real difference in privacy or homogeneity of the web. It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies. In any case I'm not sure privacy is the ultimate goal here: it's intended to replace the awful user agent sniffing people currently have to do with a sensible system where you query for what you actually want, rather than infer it from what's available.

uk_programmer 7y ago
The problem is that without User Agent sniffing in some circumstances there is no other way of working round a browser bug e.g. There are cases where browsers will report that it supports such feature using one of the feature checks but the implementation is garbage. The only way is to have a work around based on user-agent sniffing. Sure a lot of developers abuse the feature but I fear this might create another set of problems.
- adrianN 7y ago
  The other way is not using that feature until all browsers you care about implement it correctly.
  - uk_programmer 7y ago
    It is rarely an options. Additionally defects are introduced into features that have been supported for quite a while.
  - DaiPlusPlus 7y ago
    That’s not a pragmatic solution.
manigandham 7y ago
That requires running Javascript instead of having a server-side call.
vxNsr 7y ago
> It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies. Lets run through that scenario: sites that don't need this info still aren't gonna ask for it or use it. sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting and as a way to fragment features to chrome only. So, what's changed?
- untog 7y ago
  > sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting To an extent, sure. But to follow the model of third party cookies, let's say client hints are used extensively instead of user agent and all cross-domain iframes are blocked from client hint sniffing. All the third party iframe is going to be able to detect is whether user has a client hint capable browser or not. That's a big difference from the whole user agent they get today. The idea is that this won't be a Chrome-specific API. It's been submitted to standards bodies, but Chrome is the first to implement. For example, Firefox have said they "look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility"[1] so they're not dismissing the idea, they're just saying "you first". https://mozilla.github.io/standards-positions/#ua-client-hints https://mozilla.github.io/standards-positions/#ua-client-hin...
  - jaggirs 7y ago
    You could also not give the useragent to the iframes.
    - untog 7y ago
      Who knows how many sites that would mess up, though. Backwards compatibility is both the web’s greatest strength and biggest pain point.
jefftk 7y ago
Switching it from passive to active means you can count it towards https://github.com/bslassey/privacy-budget https://github.com/bslassey/privacy-budget . Yes, sites can ask for all sorts of things, but if they ask for enough that they could plausibly be fingerprinting you then they start seeing their requests denied. (Disclosure: I work at Google, speaking only for myself)
- vxNsr 7y ago
  Is the "privacy budget" an actual feature of chrome or just an idea? I've never heard of it until now.
  - jefftk 7y ago
    It's a proposal for how to prevent fingerprinting: https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html https://blog.chromium.org/2019/08/potential-uses-for-privacy...
    - dirtydroog 7y ago
      It prevents others fingerprinting, not Google though. Isn't there that x-Client-Data header than chrome only sends to Google domains?
      - jefftk 7y ago
        The X-Client-Data header is documented in https://www.google.com/chrome/privacy/whitepaper.html#variations https://www.google.com/chrome/privacy/whitepaper.html#variat... and Chrome uses it to run experiments to make the browser better. It's not used for fingerprinting. (Still speaking only for myself)
- collinmanderson 7y ago
  So why not still send limitied information by default in the User-Agent header, and if they ask for it, send more information in User-Agent header? (keep everything in one spot?) Why are we creating redundant headers?
babypuncher 7y ago
If it's well designed, then the system will only be able to query for feature support rather than ask what browser is in use. I have a feeling Google won't do it that way, because they intentionally gimp most of their apps on non-Google browsers for no reason other than to be dicks.

by untog 7y ago

uk_programmer 7y ago

The problem is that without User Agent sniffing in some circumstances there is no other way of working round a browser bug e.g. There are cases where browsers will report that it supports such feature using one of the feature checks but the implementation is garbage. The only way is to have a work around based on user-agent sniffing. Sure a lot of developers abuse the feature but I fear this might create another set of problems.

adrianN 7y ago
The other way is not using that feature until all browsers you care about implement it correctly.
- uk_programmer 7y ago
  It is rarely an options. Additionally defects are introduced into features that have been supported for quite a while.
- DaiPlusPlus 7y ago
  That’s not a pragmatic solution.

manigandham 7y ago

That requires running Javascript instead of having a server-side call.

vxNsr 7y ago

> It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies. Lets run through that scenario: sites that don't need this info still aren't gonna ask for it or use it. sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting and as a way to fragment features to chrome only. So, what's changed?

untog 7y ago
> sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting To an extent, sure. But to follow the model of third party cookies, let's say client hints are used extensively instead of user agent and all cross-domain iframes are blocked from client hint sniffing. All the third party iframe is going to be able to detect is whether user has a client hint capable browser or not. That's a big difference from the whole user agent they get today. The idea is that this won't be a Chrome-specific API. It's been submitted to standards bodies, but Chrome is the first to implement. For example, Firefox have said they "look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility"[1] so they're not dismissing the idea, they're just saying "you first". https://mozilla.github.io/standards-positions/#ua-client-hints https://mozilla.github.io/standards-positions/#ua-client-hin...
- jaggirs 7y ago
  You could also not give the useragent to the iframes.
  - untog 7y ago
    Who knows how many sites that would mess up, though. Backwards compatibility is both the web’s greatest strength and biggest pain point.

jefftk 7y ago

Switching it from passive to active means you can count it towards https://github.com/bslassey/privacy-budget https://github.com/bslassey/privacy-budget . Yes, sites can ask for all sorts of things, but if they ask for enough that they could plausibly be fingerprinting you then they start seeing their requests denied. (Disclosure: I work at Google, speaking only for myself)

vxNsr 7y ago
Is the "privacy budget" an actual feature of chrome or just an idea? I've never heard of it until now.
- jefftk 7y ago
  It's a proposal for how to prevent fingerprinting: https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html https://blog.chromium.org/2019/08/potential-uses-for-privacy...
  - dirtydroog 7y ago
    It prevents others fingerprinting, not Google though. Isn't there that x-Client-Data header than chrome only sends to Google domains?
    - jefftk 7y ago
      The X-Client-Data header is documented in https://www.google.com/chrome/privacy/whitepaper.html#variations https://www.google.com/chrome/privacy/whitepaper.html#variat... and Chrome uses it to run experiments to make the browser better. It's not used for fingerprinting. (Still speaking only for myself)
collinmanderson 7y ago
So why not still send limitied information by default in the User-Agent header, and if they ask for it, send more information in User-Agent header? (keep everything in one spot?) Why are we creating redundant headers?

babypuncher 7y ago

If it's well designed, then the system will only be able to query for feature support rather than ask what browser is in use. I have a feeling Google won't do it that way, because they intentionally gimp most of their apps on non-Google browsers for no reason other than to be dicks.