Subject: Re: Alissa Cooper's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)

From: Yoav Weiss <[email-masked]>
Date: Wed, 17 Jun 2020 10:51:41 +0200

Thanks for reviewing, apologies for the delay responding... :/

Comments addressed in https://github.com/httpwg/http-extensions/pull/1220
<https://github.com/httpwg/http-extensions/pull/1220/files#diff-6e79d9caec04bd66d25e88d370797f08L243>

Your review will be appreciated :)

On Thu, May 21, 2020 at 3:45 PM Alissa Cooper via Datatracker <
[email-masked]> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-httpbis-client-hints-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1: "passively providing such information allows servers to silently
> fingerprint the user" --> isn't pretty much all fingerprinting silent?
>

Active fingerprinting can be monitored and controlled by the user agent or
security researchers, so in that sense, it's not "silent".

>
> Moreover, I think it would be good to explain in Section 1 that Client
> Hints
> provides a way for servers to actively fingerprint clients rather than
> doing it
> passively.
>

Added "turning passive fingerprinting vectors into active ones".

> Section 2.1: "Without such an opt-in, user agents SHOULD NOT send
> high-entropy
> hints, but MAY send low-entropy ones [CLIENT-HINTS-INFRASTRUCTURE]." -->
> Given
> the use of normative language here, I think either this doc or the
> referenced
> doc needs to define what high-entropy hints are. Are all hints not defined
> as
> low-entropy considered to be high-entropy? If so, then I think a change
> along
> the lines of what Benjamin proposed is warranted. If not (as the text in
> Section 4.1 sort of indicates), then this doc needs to specify what
> high-entropy hints are.
>

I adopted Benjamin's proposal.

>
> Section 4.1: "user choice mechanisms that allow users to balance privacy
> concerns against bandwidth limitations" --> This is vague enough that I
> don't
> understand what it is talking about. What is an example of such a
> mechanism?
>

Theoretically, user agents can have permission prompts for sites that try
to access high-levels of entropy (either through a single high-entropy
vector, or through many lower entropy ones).
The sentence is trying to explain that doing so would be difficult, as
users are not likely to understand and take into consideration the
trade-offs involved.
I'd appreciate proposals to make that sentence clearer :)

> Section 4.1:
>
>    "The header-based opt-in means that we can remove passive
>    fingerprinting vectors, such as the User-Agent string (enabling
>    active access to that information through User-Agent Client Hints
>    [4]), or otherwise expose information already available through
>    script (e.g. the Save-Data Client Hint [5]), without increasing the
>    passive fingerprinting surface."
>
> How about changing that "we can" into a recommendation to do so? In other
> words, could this document recommend that if User-Agents are sending
> certain
> information in Client Hints that they stop sending it or similar
> information
> via other headers? Maybe this is too obvious, but given the breadth of HTTP
> clients in the wild, it may help to state the obvious.
>

Added "User agents supporting Client Hints features which send certain
information to opted-in servers SHOULD avoid sending the equivalent
information passively."

---

From: Yoav Weiss <[email-masked]>
Date: Wed, 17 Jun 2020 11:00:35 +0200

On Thu, May 21, 2020 at 6:33 PM Alissa Cooper <[email-masked]> wrote:

>
>
> On May 21, 2020, at 12:25 PM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Thu, May 21, 2020 at 6:48 AM Alissa Cooper via Datatracker <
> [email-masked]> wrote:
>
> I actually don't think this characterization is correct. Specifically:
>
> - When something that clients unilaterally send now is replaced by a
> client hint (e.g., User-Agent) then this changes fingerprinting from
> passive to active
> - When something that you currently have to call a JS API to get is
> replaced by a client hint, then this makes it *more* passive because the
> server only has to take one action to get the hint indefinitely.
>
>
> Maybe this could be explained in the draft? The second bit didn’t really
> come through.
>

I have to say that I don't necessarily agree with the second sentence.
I don't think that "passive" vs. "active" fingerprinting is a spectrum.
IMO, "passive" describes undetectable fingerprinting whereas "active"
describes one that's detectable. The fact that Client Hints get updated
over time doesn't make them less detectable.
AFAIK, we don't consider e.g. CSS Media Queries to be a "more passive"
fingerprinting vector then their equivalent JS APIs. Both are active, as
their use is detectable on the client (including when they update the
information they expose).

> Alissa
> -Ekr