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

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 <
noreply@ietf.org> 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."