Update explainer.md
This commit is contained in:
parent
f6bf35350c
commit
3d5c0bd03b
399
explainer.md
399
explainer.md
|
@ -7,401 +7,8 @@
|
|||
- Philipp Pfeiffenberger (Google)
|
||||
- Sergey Kataev (Google)
|
||||
|
||||
## Participate
|
||||
- [Issue tracker](https://github.com/RupertBenWiser/Web-Environment-Integrity/issues)
|
||||
# Outline
|
||||
|
||||
## Table of Contents
|
||||
Our business model relies on harvesting personal data from as many people as possible.
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Web environment integrity](#web-environment-integrity)
|
||||
- [Goals](#goals)
|
||||
- [Non-goals](#non-goals)
|
||||
- [Example use cases](#example-use-cases)
|
||||
- [How it works](#how-it-works)
|
||||
- [What information is in the signed attestation?](#what-information-is-in-the-signed-attestation)
|
||||
- [How can I use web environment integrity?](#how-can-i-use-web-environment-integrity)
|
||||
- [Challenges and threats to address](#challenges-and-threats-to-address)
|
||||
- [Quality of attesters](#quality-of-attesters)
|
||||
- [Tracking users’ browser history](#tracking-users-browser-history)
|
||||
- [Fingerprinting](#fingerprinting)
|
||||
- [Cross-site tracking](#cross-site-tracking)
|
||||
- [Detailed design discussion](#detailed-design-discussion)
|
||||
- [Why not use JWTs instead of CBOR?](#why-not-use-jwts-instead-of-cbor)
|
||||
- [How does this affect browser modifications and extensions?](#how-does-this-affect-browser-modifications-and-extensions)
|
||||
- [Considered alternatives](#considered-alternatives)
|
||||
- [Make this an extension of the fetch API](#make-this-an-extension-of-the-fetch-api)
|
||||
- [Privacy Pass / Private Access Tokens](#privacy-pass--private-access-tokens)
|
||||
- [Open questions](#open-questions)
|
||||
- [How will we prevent this signal from being used to exclude vendors?](#how-will-we-prevent-this-signal-from-being-used-to-exclude-vendors)
|
||||
- [Holdback](#holdback)
|
||||
- [Attester-level acceptable browser policy](#attester-level-acceptable-browser-policy)
|
||||
- [How are WebViews different?](#how-are-webviews-different)
|
||||
- [Stakeholder feedback / opposition](#stakeholder-feedback--opposition)
|
||||
- [References & acknowledgements](#references--acknowledgements)
|
||||
|
||||
## Introduction
|
||||
|
||||
Users often depend on websites trusting the client environment they run in. This trust may assume
|
||||
that the client environment is honest about certain aspects of itself, keeps user data and
|
||||
intellectual property secure, and is transparent about whether or not a human is using it. This
|
||||
trust is the backbone of the open internet, critical for the safety of user data and for the
|
||||
sustainability of the website’s business.
|
||||
|
||||
Some examples of scenarios where users depend on client trust include:
|
||||
- Users like visiting websites that are expensive to create and maintain, but they often want or
|
||||
need to do it without paying directly. These websites fund themselves with ads, but the advertisers
|
||||
can only afford to pay for humans to see the ads, rather than robots. This creates a need for human
|
||||
users to prove to websites that they're human, sometimes through tasks like challenges or logins.
|
||||
- Users want to know they are interacting with real people on social websites but bad actors often
|
||||
want to promote posts with fake engagement (for example, to promote products, or make a news story
|
||||
seem more important). Websites can only show users what content is popular with real people if
|
||||
websites are able to know the difference between a trusted and untrusted environment.
|
||||
- Users playing a game on a website want to know whether other players are using software that
|
||||
enforces the game's rules.
|
||||
- Users sometimes get tricked into installing malicious software that imitates software like their
|
||||
banking apps, to steal from those users. The bank's internet interface could protect those users if
|
||||
it could establish that the requests it's getting actually come from the bank's or other trustworthy
|
||||
software.
|
||||
|
||||
The trust relationship between websites and clients is frequently established through the collection
|
||||
and interpretation of highly re-identifiable information. However, the signals that are considered
|
||||
essential for these safety use cases can also serve as a near-unique fingerprint that can be used to
|
||||
track users across sites without their knowledge or control.
|
||||
|
||||
We would like to explore whether a lower-entropy mechanism - Web Environment Integrity - could help
|
||||
address these use cases with better privacy respecting properties.
|
||||
|
||||
## Web environment integrity
|
||||
|
||||
With the web environment integrity API, websites will be able to request a token that attests key
|
||||
facts about the environment their client code is running in. For example, this API will show that a
|
||||
user is operating a web client on a secure Android device. Tampering with the attestation will be
|
||||
prevented by signing the tokens cryptographically.
|
||||
|
||||
Websites will ultimately decide if they trust the verdict returned from the attester.
|
||||
It is expected that the attesters will typically come from the operating system (platform) as a
|
||||
matter of practicality, however this explainer does not prescribe that. For example, multiple
|
||||
operating systems may choose to use the same attester. This explainer takes inspiration from
|
||||
existing native attestation signals such as
|
||||
[App Attest](https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server)
|
||||
and the [Play Integrity API](https://developer.android.com/google/play/integrity).
|
||||
|
||||
There is a tension between utility for anti-fraud use cases requiring deterministic verdicts and
|
||||
high coverage, and the risk of websites using this functionality to exclude specific attesters or
|
||||
non-attestable browsers. We look forward to discussion on this topic, and acknowledge the
|
||||
significant value-add even in the case where verdicts are not deterministically available
|
||||
(e.g. holdouts).
|
||||
|
||||
## Goals
|
||||
|
||||
- Allow web servers to evaluate the authenticity of the device and honest representation of the
|
||||
software stack and the traffic from the device.
|
||||
- Offer an adversarially robust and long-term sustainable anti-abuse solution.
|
||||
- Don't enable new cross-site user tracking capabilities through attestation.
|
||||
- Continue to allow web browsers to browse the Web without attestation.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Enable reliable client-side validation of verdicts: Signatures must be validated server-side, as
|
||||
client javascript may be modified to alter the validation result.
|
||||
- Enforce or interfere with browser functionality, including plugins and extensions.
|
||||
- Access to this functionality from non-[Secure Contexts](https://www.w3.org/TR/secure-contexts/).
|
||||
|
||||
## Example use cases
|
||||
|
||||
- Detect social media manipulation and fake engagement.
|
||||
- Detect non-human traffic in advertising to improve user experience and access to web content
|
||||
- Detect phishing campaigns (e.g. webviews in malicious apps)
|
||||
- Detect bulk hijacking attempts and bulk account creation.
|
||||
- Detect large scale cheating in web based games with fake clients
|
||||
- Detect compromised devices where user data would be at risk
|
||||
- Detect account takeover attempts by identifying password guessing
|
||||
|
||||
## How it works
|
||||
|
||||
There are a minimum of three participants involved in web environment integrity attestation:
|
||||
|
||||
- The web page executing in a user's web browser
|
||||
- A third party that can “attest” to the device a web browser is executing on, referred to as the
|
||||
attester
|
||||
- The web developers server which can remotely verify attestation responses and act on this
|
||||
information.
|
||||
|
||||
1. A web page requests an environment attestation from the attester with a "content binding". The
|
||||
content binding ensures that even if an attacker intercepts an attestation, they can't use it to
|
||||
attest to a modified request. The attestation is a low entropy description of the device the web
|
||||
page is running on.
|
||||
1. The attester will then sign a token containing the attestation and content binding (referred to
|
||||
as the payload) with a private key. The attester then returns the token and signature to the web
|
||||
page. The attester’s public key is available to everyone to request.
|
||||
1. The webpage returns this information to the web server. The web server then checks that the
|
||||
token came from an attester it trusts and inspects the token’s payload. It verifies the payload by
|
||||
verifying the signature with the attester’s public key.
|
||||
1. Optionally, the web server may call the attester’s server endpoint to get additional
|
||||
(low-entropy) signals, for example to detect potentially hyperactive devices.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant website as example.com
|
||||
participant browser as Web Client
|
||||
participant attester as Attestation API
|
||||
|
||||
browser->>website: Visits website
|
||||
Note over website: Generates Content binding "/someURL?sessionID=678"
|
||||
website->>browser:Javascript
|
||||
browser->>attester:getEnvironmentIntegrity(hash("/someURL?sessionID=678&example.com"))
|
||||
attester->>browser:IntegrityToken
|
||||
browser->>website:fetch(`example.com/someURL?sessionID=678&attestation=${IntegrityToken}`)
|
||||
Note over website:Checks IntegrityToken: both tokens with signatures, Content binding, etc
|
||||
website->>browser:response
|
||||
```
|
||||
|
||||
### What information is in the signed attestation?
|
||||
|
||||
The proposal calls for at least the following information in the signed attestation:
|
||||
- The attester's identity, for example, "Google Play".
|
||||
- A verdict saying whether the attester considers the device trustworthy.
|
||||
|
||||
We're still discussing whether each of the following pieces of information should be included and
|
||||
welcome your feedback:
|
||||
- The device integrity verdict must be low entropy, but what granularity of verdicts should we
|
||||
allow? Including more information in the verdict will cover a wider range of use cases without
|
||||
locking out older devices. A granular approach proved useful previously in the Play Integrity API.
|
||||
- The platform identity of the application that requested the attestation, like com.chrome.beta,
|
||||
org.mozilla.firefox, or com.apple.mobilesafari.
|
||||
- Some indicator enabling rate limiting against a physical device
|
||||
|
||||
We strongly feel the following data should never be included:
|
||||
- A device ID that is a unique identifier accessible to API consumers
|
||||
|
||||
## How can I use web environment integrity?
|
||||
|
||||
There are two steps to using web environment integrity for developers. The first step is to request
|
||||
an environment integrity attestation on the web page and send it to the web server.
|
||||
|
||||
```js
|
||||
// getEnvironmentIntegrity expects a “content binding” of the request you are
|
||||
// about to make. The content binding protects against this information being
|
||||
// used for a different request.
|
||||
// The contentBinding will be concatenated with eTLD+1 and hashed
|
||||
// before it is sent to the attester.
|
||||
const contentBinding = `/someRequestPath?requestID=xxxx` +
|
||||
"Any other data needed for a request-specific contentBinding...";
|
||||
|
||||
const attestation = await navigator.getEnvironmentIntegrity(contentBinding);
|
||||
|
||||
console.log(attestation.encode());
|
||||
"<base-64 encoding of the attestation payload and signature approx 500 bytes; see below for details>"
|
||||
|
||||
// More on attestation validation below
|
||||
const response = await fetch(`/someRequest?requestID=xxxx&attested=${attestation.encode()}`);
|
||||
// Do something with this ...
|
||||
```
|
||||
|
||||
The attestation token is returned using an ArrayBuffer serialized with CBOR (RFC 8949) and signed
|
||||
using COSE (RFC 9052). Further information about the contents of the attestation token will be found
|
||||
in the specification.
|
||||
|
||||
The second step is on your web server, where you verify that the attested information is
|
||||
valid using the attester's public key, and then make decisions based on the
|
||||
information reported.
|
||||
|
||||
```js
|
||||
// None of the code below is part of the Web Environment Integrity API being
|
||||
// proposed. This is an example of how you can verify the environment's integrity
|
||||
// on your web server.
|
||||
function isAttested(attestation, contentBinding) {
|
||||
if (!isAttesterTrustedByMe(attestation)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// The attester's public key is retrieved directly from the attester.
|
||||
const attestersPublicKey = getAttestersPublicKey(attestation);
|
||||
|
||||
// We then validate the attestation token using the attester's public key.
|
||||
// We also check the content binding and replay protection in the attestation.
|
||||
if (!isTokenRecentEnoughAndValid(attestersPublicKey, attestation)) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Check contentBinding hash in attestation
|
||||
// Make decisions using the attestation.payload
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
## Challenges and threats to address
|
||||
|
||||
### Quality of attesters
|
||||
|
||||
Web Environment Integrity does not prescribe a list of specific attesters or conditions the
|
||||
attesters need to meet to become an attester. Browsers should publish their privacy requirements for
|
||||
attesters, and allow websites to evaluate each attester’s utility on its own merit. Users should
|
||||
also be given the option to opt out from attesters that do not meet their personal quality
|
||||
expectations.
|
||||
|
||||
### Tracking users’ browser history
|
||||
|
||||
User agents will not provide any browsing information to attesters when requesting a token. We are
|
||||
researching an issuer-attester split that prevents the attester from tracking users at scale, while
|
||||
allowing for a limited number of attestations to be inspected for debugging—with transparency
|
||||
reporting and auditability.
|
||||
|
||||
### Fingerprinting
|
||||
|
||||
This explainer requires the contents of the attestation payloads to be signed. Those contents cannot
|
||||
be tampered with or else they will not be trustworthy. Only attesters can include information that
|
||||
can identify users/devices.
|
||||
|
||||
All fields returned by attesters must be low-entropy so as not to be uniquely identifying. For
|
||||
example, attesters may specify low/medium/high for a trust score instead of a continuous numeric
|
||||
value. The attestation payloads will only include information about device and application integrity
|
||||
as attesters will not have access to the profile information in applications.
|
||||
|
||||
How can we ensure attesters are not returning high entropy responses?
|
||||
- In the near term for experimentation, the attester should publicly declare what they are attesting
|
||||
to, with readable and verifiable verdicts.
|
||||
- Beyond the experimentation phase, we need a verifiable method to enforce low entropy responses.
|
||||
We would like to explore options like splitting the attester and token issuer functions from one
|
||||
role to two independent organizations, where the token issuer can verify the attestation response
|
||||
meets the entropy requirements.
|
||||
|
||||
### Cross-site tracking
|
||||
|
||||
While attestation tokens will not include information to identify unique users, the attestation
|
||||
tokens themselves could enable cross-site tracking if they are re-used between sites. For example,
|
||||
two colluding sites could work out that the same user visited their sites if a token contains any
|
||||
unique cryptographic keys and was shared between their sites.
|
||||
|
||||
The browser must enforce top-level partitioning for all attester tokens, so that no two domains can
|
||||
conspire to track the user across sites using this mechanism. We also intend to limit linkability
|
||||
between relying parties (websites requesting attestation) and the attester in a way that prevents
|
||||
scaled tracking even if the attester were to collude with websites, while allowing for debugging of
|
||||
broken attestations.
|
||||
|
||||
The partitioning will be different for different profiles (e.g. Incognito profiles get different
|
||||
partitions even if it’s the same site the user visited on their regular profile). The user should
|
||||
also be able to reset the state that produces these tokens, breaking linkability even within the
|
||||
same partition.
|
||||
|
||||
The attestation metadata itself should strive for minimal entropy while providing useful confidence
|
||||
levels, enumerations, and/or binary indicators.
|
||||
|
||||
## Detailed design discussion
|
||||
|
||||
### Why not use JWTs instead of CBOR?
|
||||
|
||||
When it comes to billion-qps traffic, the design needs to be mindful of the bandwidth overhead it
|
||||
adds to users of the web. CBOR minimizes the payload size of requests while still decoding/encoding
|
||||
to JSON.
|
||||
|
||||
[Web Authn](https://www.w3.org/TR/webauthn-2/) has already set a precedent to use CBOR. It makes
|
||||
sense to use a similar attestation format in both specifications to encourage adoption.
|
||||
|
||||
### How does this affect browser modifications and extensions?
|
||||
|
||||
Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it
|
||||
does not restrict the indicated application’s functionality: E.g. if the browser allows extensions,
|
||||
the user may use extensions; if a browser is modified, the modified browser can still request Web
|
||||
Environment Integrity attestation.
|
||||
|
||||
## Considered alternatives
|
||||
|
||||
### Make this an extension of the fetch API
|
||||
|
||||
Once a web client has performed an initial verification of the environment it runs in, it should
|
||||
have more trust in running attestation requests locally. Decoupling attestation requests from fetch
|
||||
allows web developers the opportunity to do these checks on calls that matter, without adding
|
||||
overhead to the rest.
|
||||
|
||||
Developers can also use this API with web sockets. Introducing this API first as a primitive will
|
||||
enable us to build on it at a later stage.
|
||||
|
||||
### Privacy Pass / Private Access Tokens
|
||||
Apple and Cloudflare have developed
|
||||
[Private Access Tokens](https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/)
|
||||
for a similar use case, and Chrome has also built technologies based on PrivacyPass (Private State
|
||||
Tokens). However due to the fully-masked tokens, this technology assumes that the Attester can
|
||||
produce sustainable, high-quality attestation without any feedback from web sites about gaps such
|
||||
as false positives or false negatives.
|
||||
|
||||
We are convinced that the durability of a device attestation solution is a function of adversarial
|
||||
pressure and the defender’s ability to continue hardening the system against the ever-evolving abuse
|
||||
tactics and techniques. We are thus pursuing a solution that enables debugging of false positives
|
||||
and false negatives while still preventing scaled tracking.
|
||||
|
||||
## Open questions
|
||||
|
||||
### How will we prevent this signal from being used to exclude vendors?
|
||||
|
||||
Providing a signal that is unique to the attester could be hazardous if websites decide to only
|
||||
support attesters where certain signals are available. If websites know exactly what browser is
|
||||
running, some may deny service to web browsers that they disfavor for any reason. Both of these go
|
||||
against the principles we aspire to for the open web.
|
||||
|
||||
Attesters will be required to offer their service under the same conditions to any browser who
|
||||
wishes to use it and meets certain baseline requirements. This leads to any browser running on the
|
||||
given OS platform having the same access to the technology, but we still have the risks that 1) some
|
||||
websites might exclude some operating systems, and 2) if the platform identity of the
|
||||
application that requested the attestation is included, some websites might exclude some browsers.
|
||||
|
||||
#### Holdback
|
||||
|
||||
To protect against both risks, we are evaluating whether attestation signals must sometimes be held
|
||||
back for a meaningful number of requests over a significant amount of time (in other words, on a
|
||||
small percentage of (client, site) pairs, platforms would simulate clients that do not support this
|
||||
capability). Such a holdback would encourage web developers to use these signals for aggregate
|
||||
analysis and opportunistic reduction of friction, as opposed to a quasi-allowlist: A holdback would
|
||||
effectively prevent the attestation from being used for gating feature access in real time, because
|
||||
otherwise the website risks users in the holdback population being rejected.
|
||||
|
||||
Although a holdback would prevent the attestation signal from being used for per-request enforcement
|
||||
decisions, there remains immense value for measurement in aggregate populations.
|
||||
|
||||
However, a holdback also has significant drawbacks. In our use cases and capabilities survey, we
|
||||
have identified a number of critical use cases for deterministic platform integrity attestation.
|
||||
These use cases currently rely on client fingerprinting. A deterministic but limited-entropy
|
||||
attestation would obviate the need for invasive fingerprinting here, and has the potential to usher
|
||||
in more privacy-positive practices in the long-term.
|
||||
|
||||
We ask for feedback from the community group on the idea of a holdback, and are very interested in
|
||||
alternative suggestions that would allow both goals to be met.
|
||||
|
||||
#### Attester-level acceptable browser policy
|
||||
|
||||
If the community thinks it's important for the attestation to include the platform identity of the
|
||||
application, and is more concerned about excluding certain browsers than excluding certain
|
||||
OS/attesters, we could standardize the set of signals that browsers will receive from attesters,
|
||||
and have one of those signals be whether the attester recommends the browser for sites to trust
|
||||
(based on a well-defined acceptance criteria). As new browsers are introduced, they would need to
|
||||
demonstrate to attesters (a relatively small group) that they pass the bar, but they wouldn't need
|
||||
to convince all the websites in the world. Established browsers would need to only use attesters
|
||||
that respond quickly and fairly to new browsers' requests to be trusted.
|
||||
|
||||
## How are WebViews different?
|
||||
|
||||
WebViews are embedded into native apps which have direct access to attestation APIs that expose more
|
||||
information than we'd be willing to provide on the web. These apps can expose direct access to those
|
||||
APIs, so it makes sense to relax some of the restrictions we propose for the Web APIs above. In
|
||||
particular:
|
||||
|
||||
- The WebView API doesn't have the same concerns regarding vendor lock-in.
|
||||
- The WebView API can expose information about the embedder's application under certain conditions
|
||||
(for example, opt-in).
|
||||
|
||||
## Stakeholder feedback / opposition
|
||||
|
||||
[Implementers and other stakeholders may already have publicly stated positions on this work. We
|
||||
will list them here with links to evidence as appropriate.]
|
||||
|
||||
- [Implementor A] : Positive
|
||||
- [Stakeholder B] : No signals
|
||||
- [Implementor C] : Negative
|
||||
|
||||
[When appropriate, we will explain the reasons given by other implementers for their concerns.]
|
||||
|
||||
## References & acknowledgements
|
||||
|
||||
Many thanks for valuable feedback and advice from:
|
||||
|
||||
- [Nick Doty](https://github.com/npdoty) for helping identify user concerns in an [early proposal](https://github.com/antifraudcg/proposals/issues/8).
|
||||
To do this we must enshittify the web and force it to bend to **our** needs. Not the needs of the people using the web.
|
||||
|
|
Loading…
Reference in New Issue