Client-Hints exposes fingerprint values to additional parties and logging sensitive locations

[pes10k]

From PING:

We're concerned about the privacy implications of moving these attributes to header values, specifically since header values are more likely to wind up in passive / middle man / etc logs. Existing approaches require active techniques, and so (partially) reduce the fingerprinting risk.

The most on point issue I can find addressing this issue is #215, but this isn't quite on point (does not address increased risk from moving to passive collection).

I see the text added / modified in 2ba1998 that mentions that "implementors can do otherwise for privacy", but PING is uncomfortable with such text ( such text dissolve the point of the standard; a standard that says "its w/in this standard to vary arbitrarily", then all that is introduced is web compatibility problems for privacy oriented parties).

• What discussion has been had regarding increased information leak into logs?
• What measurements / data exists to suggest this is not a problem?

[mnot]

HI @snyderp. Be aware that people participate in the IETF as individuals, not organisations; if people in PING (aside for other readers: this is the W3C Privacy Interest Group) want to engage here, they'll need to do so individually.

My understanding is that the current thinking around CH considers the requirement for a site to request a specific CH (in the form of the Accept-CH) as effectively "converting" passive collection to active collection; a researcher, for example, can measure how many sites are collecting such metrics, and a browser can alert the user when such collection is taking place.

There was a substantial amount of discussion around this, including in #215, #372 and elsewhere.

Are you questioning that, or are you only focusing on information leakage into logs?

Regarding the latter, can you illustrate how that would happen, and what the impact would be?

[pes10k]

@mnot thank you for your reply.

My understanding is that the current thinking around CH considers the requirement for a site to request a specific CH (in the form of the Accept-CH) as effectively "converting" passive collection to active collection; a researcher, for example, can measure how many sites are collecting such metrics, and a browser can alert the user when such collection is taking place.

Researchers and clients already do exactly the things you mentioned. CH doesn't help make preventing / measuring / notifying of FP & tracking any easier. I'm similarly not familiar (and don't see any related comment in CH tagged issues) to deprecate / remove the existing methods for retrieving the same information, so the responsibility / burden on privacy focused parities is strictly increased.

There was a substantial amount of discussion around this, including in #215, #372 and elsewhere.

I am aware of this conversation, i referenced a commit in mentioned in #215 above for example :) . But in general, im not sure I understand the connection to the above issues to the concern here, which is "values in headers get treated categorically differently, and persisted longer, than variables in JS" :)

Are you questioning that, or are you only focusing on information leakage into logs?
Regarding the latter, can you illustrate how that would happen, and what the impact would be?

Neither issue addresses the concerns regarding logging (and more broadly, that putting FP sensitive values in headers increases the risk of long term privacy leaks / tracking).

1. middle parties (CDN, proxies, other HTTP terminators) get access to data they would previously would not have had access too
2. that data is more likely to be persisted in long term logs than if its collected "actively" in JS
3. HTTP logs, that may now include these values, are often shared with third parties, furthering privacy risk.

I can go on :) But i hope this helps explain / motivate the concern further

[yoavweiss]

We're concerned about the privacy implications of moving these attributes to header values, specifically since header values are more likely to wind up in passive / middle man / etc logs.

I wish you would have raised any of those concerns in the previous meetings we had with the PING (e.g. in the F2F breakout session).

Existing approaches require active techniques, and so (partially) reduce the fingerprinting risk.

The common alternative to CH is origins inspecting those values in JS, and injecting them into URL query parameters. That practice seems significantly more "loggable", making Client Hints a clear win on that front.

The most on point issue I can find addressing this issue is #215, but this isn't quite on point (does not address increased risk from moving to passive collection).

Client Hints are not "passive collection". Getting the hints requires an opt-in, which as @mnot said, is making leak and abuse of that hint data something that can be tracked, monitored and being acted against. (by researchers, extensions or user agents)

I see the text added / modified in 2ba1998 that mentions that "implementors can do otherwise for privacy", but PING is uncomfortable with such text ( such text dissolve the point of the standard; a standard that says "its w/in this standard to vary arbitrarily", then all that is introduced is web compatibility problems for privacy oriented parties).

We are in the process of defining third-party delegation in the Fetch and HTML specifications. Perhaps the PING should focus on reviewing that, rather than the IETF draft language, which at least originally was destined for a broader audience, and therefore tends to be more vague.

• What discussion has been had regarding increased information leak into logs?

Given that those concerns were not raised before in previous encounters with the PING or other privacy-minded folks, not a whole lot.

• What measurements / data exists to suggest this is not a problem?

Since you're the one claiming that this is a significant issue, do you have data to suggest it is a problem?

Researchers and clients already do exactly the things you mentioned.

I don't think they can see what different services do in their backends with information provided to them by default. For example, with User-Agent strings, currently most UAs leak a lot of information by default, which makes its collection passive. With Client Hints, we intend to change that information leak model to make it so origins would have to opt-into that data, making that opt-in observable, measurable and actionable.

CH doesn't help make preventing / measuring / notifying of FP & tracking any easier.

It does, by turning information (e.g. the UA string or the Accept-Language headers) from "sent by default" to "sent only after the server expressed interest".

I'm similarly not familiar (and don't see any related comment in CH tagged issues) to deprecate / remove the existing methods for retrieving the same information, so the responsibility / burden on privacy focused parities is strictly increased.

If you're not familiar with it, feel free to ask :) @mikewest and I have presented such plans at the F2F TPAC breakout session, which I believe you attended. This is not mentioned in the IETF draft, as it's a feature that will use the CH infrastructure, and as such, is defined elsewhere.

I am aware of this conversation, i referenced a commit in mentioned in #215 above for example :) . But in general, im not sure I understand the connection to the above issues to the concern here, which is "values in headers get treated categorically differently, and persisted longer, than variables in JS" :)

Trackers rarely inspect fingerprinting data using JS APIs and then keep it on the device's memory. They typically send it to their servers, often as URL query parameters, which are arguably an order of magnitude more likely to be persisted in logs than HTTP headers.

1. middle parties (CDN, proxies, other HTTP terminators) get access to data they would previously would not have had access too

Since Client-Hints are exposed only over secure connections, I suppose you meant "TLS terminators" above?

CDNs do get access to that data, which enables them to perform their duties and use it for content negotiation purposes. They also have full access to the content as TLS terminators, so arguably could also have access to that data by running arbitrary JS on their customers sites. As CDNs are fully trusted by their customers not to do that unless the customer asks them to, I don't think they are the threat model here.

Also, anecdotally, I've never heard of a CDN that keeps around the logs of all their customers request and response headers. If they would, cookies are likely to present a bigger concern than fingerprinting bit leakage. But if you have examples to the contrary, I'd love to hear them.

As for other TLS terminators (e.g. MITM proxies), they can similarly inject arbitrary JS and leak arbitrary data. I doubt CH increases that attack surface.

• that data is more likely to be persisted in long term logs than if its collected "actively" in JS

I'm not convinced that this is in fact the case. And again, acquiring the data in JS does not equate keeping that data in JS. It is leaked over the network, typically as URL params.

3. HTTP logs, that may now include these values, are often shared with third parties, furthering privacy risk.

Any specific examples of HTTP logs that contain all header values? I don't see Apache logs doing that, at least not by default. Similarly for Nginx, I don't see any headers there. I do see the URL though.

[yadij]

Squid proxy does have some logging options to record the HTTP headers in full or in part. At least some installations use those as their regular log format, or did so not long ago.

That said, having the CH values as opt-in instead of always present is a clear privacy improvement even for these installations. I do not agree with the argument that CH makes logging privacy/security issues worse.

[jumde]

@yoavweiss , @yadij: If I understand correctly, the client/user do not have any control over CH opt-in. If the server sends a Accept-CH header requesting DPR, ECT and DeviceMemory. The client has no way to emit all/specific values like DeviceMemory.

[yadij]

AIUI the opt-in has to be mutual. The server opts-in by indicating the CH and values it wants to see. The client opt-in is its choice whether to actually send that detail as requested.
The server should treat any absence of details the same as it would that detail being missing without CH.

For clients who literally cannot send a datum, there is no way they would have been able to send it regardless of whether CH is supported or not. So the server relying on its presence with a non-nil value is a server design bug.

[pes10k]

To respond to some of the issues mentioned above @yoavweiss @yadij :

Re: CH (does/does not) makes logging privacy issues worse

I'm having trouble understanding the claim here. I am going to see if I can repeat the thinking behind the argument that "CH aids FP prevention / detection" argument. If I am off base here, please kindly correct, I'm making an honest effort to get on the same page.

The arguments are:

1) Clients can say no easier

• Right now sites use a bunch of JS values to determine things like what images to send
• In a post-CH world, servers will expect clients to respond with headers, and so wont rely on JS values
• Clients can easy detect when these CH values are being requested, and can choose not to respond
• Therefor, CH allows clients to protect their privacy, since its easier to detect and say no, than the status quo

2) logging concerns are a push

• When sites use JS values to determine these kinds of things, they are often put in URLs, and so wind up in logs already
• Middle men can already inject JS

3) Depreciation of current JS end points

• CH is a net win because some JS end points will be deprecated

Assuming this is a correct understanding of the argument, my concerns are the following

• I am aware of the suggestion to deprecate UA access in JS (as you mentioned @yoavweiss we discussed it at the F2F), but I am not aware of any suggestion to depreciate the other related JS endpoints (and some of them, like viewport dimensions, seem impossible to hide in JS space). If there are suggestions to remove navigator.deviceMemory, DPR values, etc in some proposal somewhere, I would be very grateful for the link :)
• I understand the claim that clients can say no to a CH request easily, but the likely scenario is that servers ask for the info in CH, and then if the client says no, they extract it in JS. This is the pattern we see for all sorts of tracking libs; the server / party / JS tries to get as many signals as possible, not just the highest level one. Adding the info to the CH layer strictly makes the situation no better, and in some cases worse (since, unless the client says no 100% of the time, values are exposed to parties that otherwise wouldn't have them).
• Point taken that these values can already escape into some URLs. No question there. But there is just a world of difference between every website using its own, bespoke URL patterns, and a universal, well structured header field. There is no need for the client to be complicit and make things easier for the tracking party.
• I appreciate the point that CDN / TLS terminating parties (not HTTP terminating, thank you for the correction :) ) can inject JS. The concern here is how much tracking information a curious but honest party can see, not a malicious party (since in that case, all bets are off already…). Its not a matter of the server trusting the CDN, the focus is client information winding up in more, easily extractable places.

Also, fwiw, for examples of logs that collect all header data, the mod_log_forensic module, on the website you linked too, is one example. Systems like snort and bro, want full HTTP header logs, etc. More to the point though, the expectation is that as more track-able information winds up in these headers, more parties will become interested in them. Such is the way of the web ¯_(ツ)_/¯

[mnot]

@snyderp it seems like you're arguing that CH should be a net improvement of privacy, as opposed to current practice. While that's a goal that most everyone here shares, it isn't an explicit criteria that we've been applying to the spec; rather, the bar that I think we've held (perhaps implicitly) is that it's no worse than current practice, in any meaningful way.

Is that the case? If so, it'd probably be best to have a discussion explicitly about the goals, so we can determine consensus and then consequences.

[pes10k]

Howdy @mnot: I am not arguing that CH should be a net improvement of privacy. My position is that CH is would result in something worse than current practice, for multiple reasons:

1. Third parties gain access to finger-printable values that they currently don't have access too (finger-printable values would now be in well structured CH headers and seen by CDNs / TLS terminators, where before they were either absent or ay worse sometimes indirectly available in unstructured URLs)
2. Finger-printable values are show up in locations where they are likely to persist for longer (in HTTP logs for above)
3. Finger-printable values are shared to first parties (and delegated parties) in more ways. Previously browsers needed to defend against JS based determinations, now they need to defend against JS based determinations AND header-extractions.

[mnot]

Thanks for the clarification.

I think you need to qualify (1). As discussed, CH is currently only sent over TLS, and so from the perspective of the web, is communication between two parties. It's true that some sites contract out some of their server capabilities to others (CDNs, cloud hosts, data centres, etc.) but those are generally still considered first-party interactions, because the entity in question is acting on behalf of the owner of the server, and that relationship is typically overseen by a legal agreement, as well as various rights and responsibilities in different jurisdictions.

Also, "third party" generally is used to refer to off-site services with a different origin; e.g., ads., so it's a bit confusing to use it here.

Terminology aside, there is some precedent for the argument you're making in (2), but generally when the community has been concerned about sensitive data being logged, it's been because it appears in URLs, which were (originally) designed to be written down, logged, etc. Extending that argument to include headers in an encrypted connection is new. That's not a roadblock, but it would help immensely to establish and get agreement upon the underlying principle.

For (3), I think the basis of the decision is likely to be whether the added functionality -- including privacy improvements, as we're seeing discussed in Mike West's User-Agent replacement discussion -- balances out the increased complexity. More information on both sides would probably help, although I do note that browsers haven't been terribly shy of complexity to date...

Are you likely to be coming to the IETF meeting in Prague? That's probably where we're going to try to move this (and similar issues) forward.

[pes10k]

@mnot Thank you for the reply.

I'm not sure I follow what you're asking for by "qualifying" the concern in (1) though. I'm happy to change terminology if it eases the conversation, but the concern seems pretty straight forward. User X wants to visit website Y who sits behind CDN (or similar) Z. Currently, if Z wants to extract these fingerprinting-sensitive values from X's conversation with Y, it requires some out of band communication with Y (access to Y's DB, or something like that, assuming Y is storing them). In a CH-world, Z gets well-structured access to those values, in a way they don't currently have. Thats a loss of privacy to X that does not currently exist.

Re (2) again, happy to contribute anything I can to the conversation here, but not sure what else can be added beyond the original concern. Is it helpful frame it as:

"privacy on the web, and in the growth of web standards, has been a demonstrable catastrophe. The first principal when proposing new standards should be "do no harm", or failing that, "here is an extremely compelling goal (e.g. not moderate perf improvements) that justifies further harm to privacy". Adding finger-printable values to HTTP headers, in such a way that they can be easily collected, aggregated and shared en mass, is a significant privacy harm.

(3) The concern here is not about implementation complexity. Just to try and reach some point of agreement, so that we can discuss further from there:

Setting aside the UA aspect, and dealing only with viewport height/width, DPR, ECT and DeviceMemory, etc: can we agree that CH is strictly a harm for privacy? In the best case (user agent declines the server's request for the headers, site falls back to JS based value extraction) its a push, and in all other cases its a loss (fingerprinting values are in more locations than they were before, and accessible by more parties).

If we don't agree to the above, i would greatly appreciate it if you could clarify by way of the following: what is a scenario where a) the server / website wants to get access to finger-printable values, and b) the client doesn't want to yield them, that CH helps improve privacy? (keeping in mind that a site that currently gets them through JS, will ask for the in CH, and if they don't get them, continue to ask for the in JS).

If I could better understand a case that fit the above scenario, it might help me much better understand where ya'll are coming from, and where I may be misunderstanding things :)

Unfortunately, I will not be able to join ya'll in Prague this year

[yoavweiss]

I'm not sure I follow what you're asking for by "qualifying" the concern in (1) though. I'm happy to change terminology if it eases the conversation, but the concern seems pretty straight forward. User X wants to visit website Y who sits behind CDN (or similar) Z. Currently, if Z wants to extract these fingerprinting-sensitive values from X's conversation with Y, it requires some out of band communication with Y (access to Y's DB, or something like that, assuming Y is storing them). In a CH-world, Z gets well-structured access to those values, in a way they don't currently have. Thats a loss of privacy to X that does not currently exist.

CDNs are delegates of the origin and are not considered part of the threat model. A rogue CDN (similar to a compromised server) can do way more damage than read out fingerprintable information.

Setting aside the UA aspect, and dealing only with viewport height/width, DPR, ECT and DeviceMemory, etc: can we agree that CH is strictly a harm for privacy?

We certainly can not agree on that! (and repeating that multiple times will not suddenly make it true)

We went through great lengths to make sure the current mechanism does not allow passive fingerprinting, and its use can be treated by UAs similarly to the equivalent JS APIs. Even if we just discuss the viewport-width, DPR, ECT and DeviceMemory, the fact that the information is communicated in a convenient and standard way does not mean that it's easier to exploit it compared to the JS APIs. OTOH, it makes it easier to never keep it in or scrub it from server/CDN logs (e.g. compared to the same information hidden as URL parameter conventions).

If we don't agree to the above, i would greatly appreciate it if you could clarify by way of the following: what is a scenario where a) the server / website wants to get access to finger-printable values, and b) the client doesn't want to yield them, that CH helps improve privacy? (keeping in mind that a site that currently gets them through JS, will ask for the in CH, and if they don't get them, continue to ask for the in JS).

If I could better understand a case that fit the above scenario, it might help me much better understand where ya'll are coming from, and where I may be misunderstanding things :)

In your scenario above, how do Client Hints make things worse? If the information is exposed through JS, it is exposed. Making it available through another channel doesn't add any new fingerprintable data that attackers can abuse.

[mnot]

Unfortunately, I will not be able to join ya'll in Prague this year

Keep in mind, there is remote participation.

[pes10k]

@mnot I would be very happy to participate in this conversation remotely when its happening in Prague. Any information you could link to / share about how to participate would be greatly appreciated. I am new to the mysterious world of IETF :)