Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Agent Client Hints #202

Closed
yoavweiss opened this issue Sep 5, 2019 · 4 comments
Closed

User Agent Client Hints #202

yoavweiss opened this issue Sep 5, 2019 · 4 comments
Labels

Comments

@yoavweiss
Copy link

@yoavweiss yoavweiss commented Sep 5, 2019

Request for Mozilla Position on an Emerging Web Specification

Other information

The User Agent header that is being sent today on every request provides an excellent source of entropy that can be used to passively fingerprint users. It would be great if browsers could stop sending that information by default to all servers, regardless of whether those servers need it or not.

The User Agent Client Hint proposal is destined to replace the User Agent header, to achieve the following:

  • Send significantly less information by default (only the browser brand and major version).
  • Split the current entropy-laden string into several separate hints/attributes, enabling servers to request some information (e.g. minor version number), without being exposed to other information (e.g. CPU architecture).
  • Enable 1P servers to opt-in to receive that information as HTTP request headers, as well as in a JS API, while giving 3P servers access to that information only if delegated from the 1P.

The above will enable browsers to keep track of servers that collect that information, and take actions to protect users' privacy in cases where that collection is likely abusing it.

Another interesting characteristic of reseting access to the UA string is that it can allow browsers to apply GREASE to the new values, in order to prevent the negative implications of UA sniffing seen on the web today.

@dbaron

This comment has been minimized.

Copy link
Member

@dbaron dbaron commented Oct 21, 2019

So it's worth noting explicitly that a bunch of the comments made in #79 apply here -- but at the same time this is a separate question from the one in #79 that we ought to discuss.

@yoavweiss

This comment has been minimized.

Copy link
Author

@yoavweiss yoavweiss commented Nov 4, 2019

/cc @miketaylr - who shown interest in the feature when we discussed it at ViewSource

@adamroach adamroach added the ietf label Nov 16, 2019
@miketaylr

This comment has been minimized.

Copy link
Member

@miketaylr miketaylr commented Nov 25, 2019

Hey @yoavweiss - sorry for the delay here. I've been having discussions with Tanvi and @martinthomson about the User Agents Hints proposal and here's some draft language that could maybe result in a position:


Description

The UA Hints proposal aims to solve the following problems associated with the User Agent (UA) string: UA sniffing, UA spoofing, and an entropy-rich target for fingerprinting. The proposal is to build on top of the Client Hints infrastructure and solve these problems over time.

(Draft) Mozilla's Position

Using Client Hints to deliver info derived from the User Agent header for servers who specifically request this information may reduce the number of parties that can use this information for passively fingerprinting users. However, we could reduce this even further by freezing the User Agent string and requiring resources to actively request this information via the proposed NavigatorUAData interface JS APIs. This would also allow us to audit the callers. At this time, freezing the User Agent string without any client hints—seems worth-prototyping. We look forward to learning from other vendors who implement the “GREASE-like UA Strings” proposal and its effects on site compatibility.


Less formal version:

We're very interested in the freezing UA string stuff and NavigatorUAData JS APIs, and think those are worth prototyping. Personally, the GREASE-like stuff is interesting but slightly scary. I'd love to see Chrome turn that on in Canary at some point and see what happens.

But I don't think the positive points change our position on Client HInts (which is currently "non-harmful"). @martinthomson could probably expound on that.

@adamroach

This comment has been minimized.

Copy link
Collaborator

@adamroach adamroach commented Nov 27, 2019

Thanks, @miketaylr -- after double-checking with Martin, and reading @dbaron's comment above as not varying from the related Client Hints position, I'm closing this and adding your proposed text to the spreadsheet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.