Disable Client-Hints in brave

[jumde]

Description

Client Hints pose a significant privacy risk. Disable by default.

httpwg/http-extensions#767

Test Plan

Specified here: brave/brave-core#2205

cc: @snyderp @tomlowenthal

[bsclifton]

@jumde do you have more information about this? (ex: what are Client-Hints? What impact would this have to users?) If you could update the original post to have more info, that would be awesome 😄

[jumde]

Here is the thread highlighting the privacy concerns with Client-Hints: httpwg/http-extensions#767

Not a lot of browsers have implemented this: https://caniuse.com/#search=client-hints so I think the impact on users will be minimal.

cc: @snyderp

[pes10k]

@bsclifton that thread's gotten pretty out of control, but the TL;DR of it is that client hints allows sites to request the client send finger-print sensitive values (viewport dimensions, device mem, pixel density, etc) as header values. We do our best to block these values in other locations, and we should make sure we block them at this layer too (at least with shields up)

[diracdeltas]

Noting this part from https://httpwg.org/http-extensions/client-hints.html: "Transmitted Client Hints header fields SHOULD NOT provide new information that is otherwise not available to the application via other means, such as using HTML, CSS, or JavaScript. "

This seems to clearly indicate that we SHOULD disable client hints if:

1. The user has disabled JS
2. Other ways of getting that same information is otherwise blocked (for instance through Fingerprinting Protection)

I am less convinced that we should disable it generally. The strongest argument I have for that is that it makes implementation easier.

[pes10k]

There are now conversations on CH in at least 3-4 different locations, each with a different group of people attached (the above, private and public channels on Slack, IETF GH issues, W3C PING GH issues, etc).

Maybe it would be good to centralize the conversation in one place while we work though this? Or even have a brief talk in person about it. Maybe this week's privacy confab?

[diracdeltas]

Here's what I think are some good reasons that C-H should be disabled in Brave:

• It increases fingerprinting surface by exposing information that was otherwise only available via JS
• It has low risk of breakage due to other browsers not implementing it
• Preventing C-H from sending info when the info is otherwise available has high implementation complexity. For instance, if the user has an extension installed that blocks viewport size reporting, that extension or Brave must ensure the corresponding client hint is disabled. Same thing with when JS is disabled via NoScript or natively in Brave.

[kjozwiak]

Verification PASSED on macOS 10.14.5 x64 using the following build:

Brave	0.66.87 Chromium: 75.0.3770.80 (Official Build) beta(64-bit)
Revision	9a9aa15057b6b2cc0909bdcf638c0b65ecd516f2-refs/branch-heads/3770@{#948}
OS	Mac OS X

Example of the issue occurring on 0.65.118 Chromium: 75.0.3770.80:

Example of the issue NOT occurring on 0.66.87 Chromium: 75.0.3770.80:

Verification passed on

Brave	0.66.87 Chromium: 75.0.3770.80 (Official Build) beta (64-bit)
Revision	9a9aa15057b6b2cc0909bdcf638c0b65ecd516f2-refs/branch-heads/3770@{#948}
OS	Windows 7 Service Pack 1 (Build 7601.24465)

Verified test plan from brave/brave-core#2205

Verification passed on

Brave	0.66.87 Chromium: 75.0.3770.80 (Official Build) beta (64-bit)
Revision	9a9aa15057b6b2cc0909bdcf638c0b65ecd516f2-refs/branch-heads/3770@{#948}
OS	Linux