holdbacks diminish the value of the proposal and don't protect browser diversity

[michaelficarra]

As you've mentioned in the explainer (and as I have already expressed in the CG call), the holdback strategy for protecting browser diversity would significantly reduce the usefulness of this proposal for the use cases we care about, and we feel strongly that it should not be used.

For the use case of credential stuffing, for example, we have one opportunity to collect signal data before making a determination about whether to allow an authentication attempt. Assuming the holdback strategy is to artificially fail the integrity decision, we would still need to collect our typical signal data for every visitor, and only rely on the attestation as a new secondary signal. If instead the holdback strategy is for the attestation API to fail, we would still need to collect our typical signal data for the users affected by the holdback. Those users would be subjected to much more scrutiny than necessary. Neither of these strategies would allow for us to stop using fingerprinting strategies entirely, even on devices which support this API, which should be a goal of this proposal.

In addition to our belief that holdbacks limit the usefulness of this proposal, we feel that holdbacks don't meaningfully make a difference for the problems they're intended to address. It's our understanding that holdbacks are meant to allow for less-popular or less-featureful browsers to still be used across the parts of the web they support without artificial discrimination. But it is already the case that certain web applications, including the ones protected by F5, deem many (mostly older) browsers unfit for sensitive transactions. Typical reasons include maximum TLS version support, cipher suite support, or susceptibility to critical vulnerabilities which compromise their ability to maintain confidentiality. But even more simply, web applications can and do just discriminate against disfavoured browsers via User-Agent string. And finally, we don't feel that this API significantly increases implementation burden for new browsers relative to the already massive number of APIs and features that are considered a baseline for web compatibility today.

/cc @bakkot

[ghost]

There's a fundamental conflict between the goals of an open web that can be used on any hardware with any browser, and a system that aims to offer specific approved browsers for whatever reason. Even this holdbacks proposal is written to provide only a modest veneer of openness, and assumes no fingerprinting countermeasures so that it can couch additional DRM functionality as a privacy enhancement.

Browsers can and should be disallowing fingerprinting as much as possible, but this option would be a threat to the paychecks of this spec's authors.

[workingjubilee]

As I noted elsewhere, the assumption that giving out a bunch of bits of information because "anyone could fingerprint" ignores that with WEI, the cost of that fingerprinting, even if the data is reduced, now becomes effectively almost 0: make an API call and break your site if the call doesn't pass! It's that easy. It's true, holdbacks are worthless, but it's for a particular reason:

"The user could go elsewhere" doesn't matter if there is a significant power imbalance between a website's owner and the user who is visiting the website, such that the user can be forced to complete usage of the website first and if not have real-life consequences inflicted on them like loss of healthcare, government support, money, or even their housing. Granted, anyone capable of inflicting those harms already has a lever, but it now becomes effortless to gain even more information and thus power over them. Societies that have spent 200+ years trying to discourage stalking other people, or denying others their needs for petty or bigoted reasons, are not prepared to issue a barrage of even more protections against abuse of what would be significantly enhanced ability for effectively free universal stalking and redlining.