Thanks! In the spirit of your first point, Iâm going to split your three issues into somewhat more than three things to talk about. 
UA-Brand
and UA-Version
We could certainly split UA
into UA-Version
and UA-Brand
. That would be consistent with splitting the rest of the detail out into distinct headers. That said, I see âChrome 41â and âChrome 73â as being actually different browsers in a deep way. Itâs not clear to me that either the branding or version information would be meaningful on its own.
Yes to UA-Engine
Advertising the engine for browsers whose brand is otherwise ambiguous is probably a good idea. Iâm not sure I prefer it to advertising the variant as part of the branding (e.g. the status quoâs CriOS
as opposed to Chrome
). Do you have a reason for preferring the separate header?
One might be that every iOS browser will use the same engine for reasons, so advertising WKWebView
or something as the underlying engine might set expectations appropriately. One response to that is that Chromeâs WKWebView
has all sorts of things injected into it to enable APIs that WebKit doesnât (yet?) support, so that Chromeâs WebView is actually quite distinct from Edgeâs, which is yet again distinct from Firefoxâs. It seems reasonable to me to reflect that in the branding.
Copious lying.
-
I tend to believe the folks who have told me that itâs hopelessly naive to expect browser vendors not to lie about their nature if developers gate access to features based on user agent information advertised in the request. In my mind, the question is how to support these white lies without destroying the usefulness of the mechanism in the process.
-
Why is lying bad? In particular, the explainerâs GREASE-like suggestion to turn UA
into a set with intentional lies is pretty appealing. It forces developers to parse the whole UA
string, and gives smaller players the ability to talk about themselves in one part of the string, while advertising themselves as someone else for purposes of compatibility.
If there was a magic wand I could wave over the internet that made #1 above untrue, I would (perhaps developers will be overtaken by an aesthetic desire for clean UA string? And will start doing pure feature detection rather than relying on unique keys into a table of UA builds containing the genuine metadata?). I think itâs unlikely, given historical precedent.
because the idea that UA
is a client hint but somehow escapes the opt-in and gets sent anyway
A pedantic nit: it partially escapes the opt-in, insofar as the major version is exposed by default, and the minor version only after Accept-CH: UA
. But the point stands.
Thereâs no privacy benefit, thereâs no security/fingerprinting benefit [to the opt-in]
I disagree!
-
As the explainer notes, browsers can make decisions about when to respect the siteâs request. For example, browsers that categorize the world into âBoo!â and âYay!â via some heuristic or other can deny additional detail to the former and grant it to the latter.
-
As the explainer doesnât note, but ought to, the public nature of the opt-in makes data collection visible to researchers, regulators, and users who care. Rather than broadcasting entropy to every site indiscriminately, weâll get some collective insight into the entities who actually want to collect it, and the entities with whom they choose to share that detail.
new request headers like Sec-Metadata
have not followed this pattern
The guy who wrote that spec probably had good reasons for not following the pattern. He might, for instance, have thought that the requests which are interesting from a security perspective are all third-party (e.g. evil.com
poking at a CSRF vulnerability in bank.com
, or executing cross-site search attacks against bing.com
), and that attackers would be sincerely unlikely to delegate helpful metadata collection to their victims via Feature-Policy
.
Iâve previously suggested that this design encourages developers to start any user session with a redirect to capture full CH data before producing a page.
Thatâs a thing that could happen. It has minor perf impacts. But since weâd ideally redirect through the apex of a registrable domain anyway to set Strict-Transport-Security
headers with includeSubdomains
, itâs not clear that itâs actually not best practice?
Thanks again for your feedback!