Google Cloud Fraud Defence is just WEI repackaged

What Google claims

Google positions Google Cloud Fraud Defence as the next evolution of reCAPTCHA, a tool to protect websites from bot-driven fraud, automated scraping, and malicious automated traffic. The core user-facing mechanism is a QR code challenge: when a site using the service flags a request as potentially fraudulent, the user is prompted to scan a QR code with their mobile device. Google states this confirms human presence more reliably than traditional CAPTCHA challenges, which are increasingly bypassed by AI-powered solvers. The company frames the product as a privacy-preserving upgrade, noting that no personal data is collected from users during the challenge process.

Google’s May 2026 announcement of Cloud Fraud Defence describes it as “the next evolution of reCAPTCHA” built to address rising automated fraud.

What’s actually new

The underlying mechanism is not new at all. It is a direct repackaging of the Web Environment Integrity (WEI) proposal Google floated in 2023, which it withdrew after widespread backlash from standards bodies, privacy advocates, and browser competitors.

In June 2023, Google engineer Yoav Weiss submitted the Web Environment Integrity proposal to the Chromium project. The mechanism required browsers to request a cryptographic attestation from device hardware, proving the browser was unmodified and running on hardware certified by Google. Websites could then verify this attestation to decide whether to serve content without friction or trigger additional challenges. Google framed WEI as a way to protect web integrity against bots, but critics immediately identified structural risks.

Mozilla published a formal position on WEI within days of the proposal’s release, stating it “works against users’ interests” and “creates a gated internet controlled by OS and device vendors.” The Electronic Frontier Foundation (EFF) labeled the proposal “Chrome’s Plan to DRM the Web”, noting that only Chrome running on Google-certified Android hardware would easily pass attestation checks, steering traffic toward Google’s ecosystem as a core design outcome rather than a side effect. Google withdrew the WEI proposal three weeks after its publication, closing the Chromium GitHub thread and publicly shelving the idea.

Three years later, the same attestation infrastructure underpins Google Cloud Fraud Defence. The product’s requirements page specifies that eligible devices must be “modern Android device with Google Play Services installed, or modern iPhone/iPad.” The Google Play Services requirement is not incidental. Google Play Services is a closed-source software layer that provides access to the Play Integrity API, which generates the exact device attestations that WEI relied on. A device without Play Services cannot meet the MEETS_DEVICE_INTEGRITY level required by Fraud Defence, a deliberate design choice rather than a temporary technical limitation.

The key difference between the 2023 WEI proposal and the 2026 Fraud Defence launch is the lack of public review. WEI was subject to open standards body feedback, which forced Google to withdraw it. Fraud Defence launched as a commercial product with no public comment period, no standards body review, and no opportunity for external stakeholders to raise objections before release.

The QR code challenge is the user-facing wrapper for this attestation system. Here is how the flow works: a user encounters a Fraud Defence prompt on a website and is asked to scan a QR code with their phone’s camera. The phone, which must have Google Play Services (for Android) or be a modern iPhone, uses the Play Integrity API to generate a cryptographic attestation proving the device is unmodified and certified by Google. This attestation is sent back to the original website as proof of human presence, allowing the user to access the content.

Limitations and unresolved risks

Critics of the original WEI proposal raised three core objections: the system fails to stop sophisticated bots, it excludes legitimate users who rely on privacy-focused software, and it enables persistent cross-site tracking by Google. All three objections apply to Fraud Defence, with additional risks tied to the QR code mechanism.

Bot operators will bypass the system easily

The attestation check only confirms that a device is certified by Google, not that a human is operating it. Bot operators can purchase compliant Android devices in bulk for approximately $30 per unit, a negligible cost for commercial bot farms. For operations that do not need to spoof Play Integrity attestations, the QR code challenge can be bypassed with off-the-shelf hardware: pointing a camera at a screen to scan the code is a trivial automation task that requires no modification to the device’s software or hardware.

This means Fraud Defence will fail to stop the same automated traffic that traditional CAPTCHAs and reCAPTCHA already struggle with, while adding new costs for legitimate website operators who pay for Google Cloud services.

QR codes train users for phishing attacks

The QR code challenge normalizes scanning unknown QR codes to access websites, a behavior that phishing campaigns will exploit immediately. Security professionals have already raised concerns about non-technical users’ ability to distinguish legitimate Google CAPTCHA QR codes from malicious phishing codes. A user who is trained to scan a QR code when prompted by a website popup will not hesitate to scan a malicious code sent in a phishing email or posted on a public sign, which can redirect them to fake login pages or install malware.

This risk is unique to the QR code mechanism. Traditional CAPTCHAs do not train users to interact with external hardware or scan unknown codes, making Fraud Defence a net negative for user security even if it were effective at stopping bots.

Contrast with existing QR authentication systems

QR-based authentication is not a new concept, but existing implementations are scoped to bounded, consent-based ecosystems. Estonia’s Smart ID uses QR codes to verify users for specific high-trust services: banking portals, government services, health records. Users opt in to using Smart ID, the scope of the authentication is explicitly defined, and the user initiates the process voluntarily.

Google Cloud Fraud Defence applies this mechanism to the open web, where any website operator can gate access to any URL without user consent or awareness that their hardware identity is being used as an access credential. The open web was designed to be hardware-agnostic, with no requirement that users run software certified by a single private company to access public content. Fraud Defence breaks this core design principle, conditioning web access on Google’s certification decisions.

Apple’s iOS App Attestation is sometimes cited as a parallel system, but it governs apps within the iOS walled garden, an opt-in ecosystem that users choose when purchasing an iPhone. Extending device attestation to open web browsing is categorically different, as it applies private company certification requirements to public infrastructure that billions of people rely on to access information.

Privacy-focused users are excluded by design

The Play Integrity API requirement excludes large groups of legitimate users who rely on software that does not integrate with Google’s certification systems. GrapheneOS, the security-hardened Android fork recommended by the EFF for journalists, activists, and high-risk users, does not ship Google Play Services by default. While it supports a sandboxed compatibility layer for Play Services, this does not satisfy the MEETS_DEVICE_INTEGRITY level required by Fraud Defence. LineageOS for microG, a popular open-source Android distribution for users who want to avoid Google services, fails for the same reason.

Firefox for Android is also excluded from Fraud Defence support. Mozilla has explicitly opposed device attestation since 2023, and Firefox does not integrate the Play Integrity API by design. This means users of the most popular privacy-focused mobile browser cannot pass Fraud Defence checks, not because they are bots, but because they use software that refuses to participate in Google’s certification architecture.

These exclusions disproportionately affect users who need privacy most: people living under authoritarian regimes, journalists investigating sensitive topics, and activists organizing dissent. For these users, being locked out of websites that use Fraud Defence can have real-world consequences.

Persistent tracking and attribution

Every successful Fraud Defence challenge sends data to Google: the certified device’s hardware identifier, the URL accessed, and the time of the request. This creates a persistent identifier that tracks users across sessions, browsers, and private browsing modes. The company that defines which hardware is “legitimate” accumulates a comprehensive record of where that hardware accesses the web, a core architectural feature of tying verification to certified device identity rather than a side effect.

This tracking is not optional. Users cannot opt out of sending attestation data to Google, as the Play Integrity API requires communication with Google’s servers to verify device certification. Website operators using Fraud Defence also cannot avoid sharing this data with Google, as the attestation check is processed through Google’s infrastructure.

A technically credible alternative

Proof-of-work systems like Private Captcha offer a way to stop automated traffic without the governance and tracking risks of device attestation. These systems issue cryptographic challenges that require computational effort proportional to the volume of requests. A single human solving a challenge pays a negligible cost in compute time, while a bot farm running concurrent sessions faces exponential cost increases with each additional attempt. AI agents, which consume GPU cycles to operate, face identical penalties regardless of their reasoning sophistication.

No hardware identifiers are transmitted, no attestation is required, and no private company certifies which devices are allowed to access the web. User privacy is preserved by design, not as a marketing promise.

Final assessment

Google Cloud Fraud Defence is not a reCAPTCHA update. The QR code is a user-facing wrapper for the same device attestation infrastructure that standards bodies rejected in 2023. The product launches without public review, excludes privacy-focused users, enables persistent tracking, fails to stop bots, and trains users to fall for QR phishing attacks. The only evolution here is the packaging: a rejected public proposal is now a commercial product, generating revenue for Google while shifting the costs of its flaws to users and website operators.