Attestation holdback

[SergeyKaG]

Objectives

Discourage websites from discriminating against non-attested clients

In a world where most devices support attestations, some websites might refuse service to clients that lack attestation. This may include browsers that have not integrated with platform-specific attestation APIs and browsers running on platforms that don’t have attestation available.

Maximize attestation utility for security and anti-fraud use cases

We aim to offer high anti-abuse value with the Web Environment Integrity API.

Holding back attestation from a large fraction of users would reduce usefulness of attestation, especially for use cases like data theft/security that require real-time damage prevention (as opposed to post-facto cleanup). Some stakeholders believe that even a small hold-back would diminish security reliability of attestation, and they would have to resort to old methods like browser fingerprinting. We aspire to wean the anti-abuse ecosystem off of privacy-invasive detection methods like browser fingerprinting; but a hold-back would compel continued investment in these methods. Consequently, we’d like to minimize attestation hold-back to maximize attestation usefulness.

Risks

Managing tensions between web openness, privacy, and safety

The biggest risk is carefully navigating tradeoffs to maintain or improve goals we all want: we want to keep the web open and free to everyone regardless of income or wealth (and the type of device they can afford); we believe the web should be private by default; and these things are not possible if the web is not safe and usable. Web Environment Integrity seeks to improve all three, but the devil is in the detail.

Without a hold-back, can we maintain access to the web for users with older devices incapable of environment or device integrity attestations? Will sites slowly begin to exclude “outdated” devices or custom browsers?

With a hold-back, are we able to improve privacy and reduce the need to fingerprint, if organizations still need to build, train, and maintain bot detection models for all classes of devices? Does it make a difference if the hold-back is a small proportion of traffic?

Rather than attempt to solve for each or view them as a one-for-one tradeoff, we want to acknowledge the tensions exist, discuss them in the open, and importantly, adjust if we start to see adverse impacts to openness, privacy or safety.

Risks of doing hold-back

• Websites cannot rely on client attestation, because it may be missing.
• Websites might continue collecting rich browser data, aka fingerprints, to detect abuse. This reduces the privacy benefit of attestation. Devices with attestation will likely still get fingerprinted to define a baseline for abuse ML classifiers.
• Abusive traffic can blend in with traffic that has attestation held-back, potentially increasing friction to benign users in the holdback set.
• Some use cases won’t benefit from attestation with hold-back as much as they would have from reliable attestation: irreversible user actions need a high level of security.

Risks of not doing hold-back

• Websites can block or downgrade access for clients that have no attestation capability: some browsers, some platforms, rooted/jailbroken devices, etc. This may disproportionately impact certain users, for instance, lower wealth users that cannot afford to purchase newer devices.
• Websites might gradually increase the requirement to have attestation, phasing out access to “outdated” clients.

  Possible parts of a solution

  Attestation hold-back aims to create enough users without web environment integrity attestation that websites would frustrate and lose a significant fraction of their users if attestation is required.

Inclusive verdicts

We must acknowledge that device trust is not a boolean but a gradient. Some users have more secure devices than others. Moreover, device security is not always an indicator of goodness -- there are secure devices used by bad actors in an automated manner, and there are rooted devices used by well-intentioned humans.

We aim to create abstractions that allow relying parties to tackle this complexity. For example, the attestation should cover both device integrity (allowing a few integrity levels) and behavioral integrity (e.g. a hyperactivity counter, or a historical trust score). We will share more details and seek feedback in a later stage.

Opt-outs

While we hope that Web Environment Integrity will ultimately result in more user privacy by reducing the need to fingerprint, some users may understandably want to opt out of providing detailed information about their devices. During Chrome's experimentation, if a user has unchecked the “Auto-verify setting” (utilized as controls for anti-abuse signals for Chrome 114+), we’ll refuse attestation.

Incognito mode may or may not be opted out by default. It’s an open design decision at this point. A user might get better anonymity by not providing information about their browser and the platform it’s running on, but without WEI, fingerprinting may be more likely to occur.

Fixed probability

Attestation can be held back for a fixed percentage of users, randomly selected and persistent per user per top level site for a period of time.

Site-specific explicit permission

A website may request user permission to request attestation if it is deemed important for security stance. This permission request dialog is more transparent for a user and should(?) override the browser opt-in and hold-back flag. It also may sound intrusive enough so that many users will opt out of giving that permission and out of using the website if it absolutely insists on it. There is precedent for this type of user prompt, for example, a site requesting microphone or camera access is necessary for legitimate uses like web conferencing, but attracts enough user attention such that sites are incented to only request when needed.

However, the problem with this approach is that it may set a precedent of only allowing attestable devices to use certain features on websites (see risks section).

We do not propose a permission model now, but leave it here for discussion.

Making attestation ubiquitously available

If it gets easy enough to add attesters for new platforms and browsers, most platforms and browsers would have an attester available. In that case, hold-back may become unnecessary as a protection measure for users of devices that don’t support attestation.

[gourdcaptain]

" Will sites slowly begin to exclude “outdated” devices or custom browsers?" - that seems like how this is going to be used, yes

This is just going to be used to reject anything that isn't a signed Google Chrome or similar binary on an approved OS and device accepting ads from viewing YouTube ultimately, lol.

kinda gave the game away with Extension Manifest V3 already

[jfmcbrayer]

Yes, attestation holdback has a conflict of interest problem — the protocol is essentially a deal between the attester and the website. Unfortunately, both the attester and the website have an interest in eroding the attestation holdback mechanism over time; doubly so if the two have an existing business relationship. To leave Google out of the picture for the moment, consider the case where Microsoft provides attestation for Windows devices, and Office 365 wants to rely on attestation.

[gourdcaptain]

Yes, attestation holdback has a conflict of interest problem — the protocol is essentially a deal between the attester and the website. Unfortunately, both the attester and the website have an interest in eroding the attestation holdback mechanism over time; doubly so if the two have an existing business relationship. To leave Google out of the picture for the moment, consider the case where Microsoft provides attestation for Windows devices, and Office 365 wants to rely on attestation.

Anticompetitive behavior for everyone!

truly this proposal is bringing good into the world

[mokrates]

This makes no sense. "Discrimination" means, by definition of the word, to differentiate. The attestation is a means to differentiate between attested clients and non attested clients. If you don't want anyone to make that differentiation between attested and non attested, then this api has, by definition, no use at all.

Also: "Open Web" doesn't mean that it is ok that websites differentiate when Chrome has enough market share. Until yesterday, I could use curl and build my own whatever, and you kill that. That's just not ok.

[dhasenan]

In a world where most devices support attestations, some websites might refuse service to clients that lack attestation.

Yes, this is the point of the proposal.

An ad network may discriminate against websites that have a large percentage of users who use browsers that refuse attestation since the user might have an ad blocker. A content network like Google Play may refuse to service clients that refuse attestation, or only provide lower quality video, since the user might have an addon that will download the content so the user can view it later. A browser game might refuse to allow someone into the competitive leagues if their browser refuses attestation because the person might have an addon for cheating.

Is the concern that a site might offer no service instead of reduced service to these users?

Some stakeholders https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/5 that even a small hold-back would diminish security reliability of attestation, and they would have to resort to old methods like browser fingerprinting. We aspire to wean the anti-abuse ecosystem off of privacy-invasive detection methods like browser fingerprinting; but a hold-back would compel continued investment in these methods.

Fingerprinting is only a thing in the first place because some users use tracking protection that makes it impossible to just use a cookie. Tracking protection exists because users don't particularly like it when advertisers can track their activity across the web. In order for you to produce a viable alternative to fingerprinting, you need to provide an identifier that the user cannot mess with.

You're saying it's a privacy improvement because it means Amazon's tracking system won't care about what codecs my browser supports, my default fonts, what accessibility options I'm using, etc. But the potential outcome of those details getting out is...what, ads get displayed slightly better? I don't want Amazon's tracking system to see that I'm looking up domestic violence shelters and insert an ad for Lundy Bancroft's book on abusive partners where my spouse can see it.

That's missing the forest for a tiny piece of lichen on the sidewalk half a mile from the park.

[dmarti]

Attestations are a way for untrustworthy sites to make trustworthy claims.

Google chooses to monetize sites that are illegal or otherwise problematic -- https://www.propublica.org/article/google-display-ads-piracy-porn-fraud -- and would not be able to provide trustworthy reports on their users in the same way that a legit site with a third-party audit would be able to.

Although Google wants to be able to detect "good user/bad site" that's harmful to users, because giving Google the ability to do this will incentivize more people to build bad sites and drive web traffic to them in deceptive ways.