Chrome proposes developing a high-level document to capture use-cases and requirements for device attestation and other high-fidelity, low-entropy signals. This is a call for collaboration among interested members of the anti-fraud community group to identify important signals for Invalid Traffic (IVT) detection and other relevant security use cases.

Many modern platforms have built-in tools to help differentiate legitimate and emulated devices. Android provides applications with the Safety Net API and Apple’s App Attest offers some of the same protections.
By transmitting signals of legitimacy from the device’s platform, such as if the device is emulated or rooted, publishers and their technology partners could use this information in part to determine if traffic is invalid. They could then choose appropriate actions like flagging advertising actions as suspicious or requiring more information for sensitive actions like logins or financial transactions. These signals could be open for all websites to consume and could additionally facilitate a variety of other security use cases in a privacy compliant manner.

We would like to forward the most useful integrity signals on each platform, and provide a unified representation to web sites and applications.

There are many open questions in this area that we’d like to explore:

1. Would a platform signal attesting to the device’s legitimacy be a useful addition?
2. What integrity signals would be most useful? (For example, device booted from manufacturer-signed firmware, browser runtime integrity checks, etc.)
3. Would an ideal implementation reduce (not eliminate) the need for fingerprinting?
4. What remaining needs would require fingerprinting (for example, enforcing uniqueness / sign-up protections; cookie theft prevention)?
5. What other signals are derived from common fingerprinting surfaces that browsers could surface in a privacy safe manner? For - example, geo, time since last state clear, etc.?
6. What about longitudinal signals? Should the browser play a role here at all?
7. How do we experiment with new signals or a changing threat landscape?
8. What would be useful on platforms that do not have a comprehensive attestation framework?

Potential challenges

1. How do we maintain equitable access to the web for users with older devices or platforms, which may not provide this signal?
2. Should we introduce some noise, or hold back the signal on some fraction of devices to prevent over-reliance on these signals
3. Will threat actors shift to using valid devices that provide these signals, and will the additional cost of attacks cause only temporarily reduce fraud? How soon might these signals become stale over time?

We’d like to start an effort to explore this approach, starting with requirements gathering, in the Anti-Fraud Community Group, and would welcome collaboration.

Related work:

• User Confidence Score
• Trust Tokens API