Sony’s age-verification partner reportedly auto-reports users of the privacy-focused Android fork. The incident is raising serious questions about what age-verification systems are actually built to do.
TL;DR
A user attempting to complete Sony PlayStation’s age verification through Yoti – a British identity and age-check company received a support response claiming their device had been automatically flagged and the incident reported to both Yoti’s security team and law enforcement. The stated reason: the user was running GrapheneOS, a privacy-focused, open-source Android fork. Yoti cited what it called “past security concerns” associated with the operating system. GrapheneOS itself responded publicly, calling the customer support message likely fearmongering from a rogue agent trying to close a ticket. The story has since spread across privacy communities, developer forums, and YouTube, and it has shone a very uncomfortable light on what the age-verification industry actually looks like up close.
BACKGROUND: WHAT IS YOTI, AND WHY IS IT ON YOUR PHONE?
Yoti is not a household name, but its reach is surprisingly wide. The London-based company operates a digital identity and age-verification platform used across multiple sectors such as gaming, social media, retail, and government services. Its clients include Sony PlayStation, Instagram, Facebook Dating, Epic Games, the UK Post Office, and a growing list of retailers across the UK, United States, and European Union.
The company’s core pitch is straightforward: let platforms verify a user’s age or identity without storing sensitive personal documents on their own servers. Instead, Yoti acts as the intermediary. You submit your ID to Yoti; Yoti confirms you’re old enough; the platform gets a yes/no signal. The model is meant to be privacy-preserving by design.
Whether it works that way in practice is now very much in question.
WHAT ACTUALLY HAPPENED
The incident comes from a Reddit post in r/privacy (since archived, as the subreddit has a complicated relationship with GrapheneOS. More on that shortly). A user going by the handle PaiDuck described trying to complete Sony PlayStation’s age verification flow, which routes through Yoti. The verification failed. When the user contacted Yoti support, they received a response that – if accurate – is genuinely alarming.
The relevant portion of the support message, as shared in a screenshot on Imgur, reads:
“Yoti automatically flags […] any devices running GrapheneOS. These instances are automatically reported both to the authorities and our security team.”
Read that again. Not “your verification failed because we couldn’t confirm your identity.” Not “your device configuration is incompatible with our security checks.” Reported to the authorities. For running an operating system.
The screenshot spread quickly. Forum threads on GrapheneOS community boards lit up. The story got picked up by SomeOrdinaryGamers on YouTube, a channel with nearly four million subscribers. By the time most people had seen it, the framing had settled into something fairly blunt: a privacy phone gets you reported to the police.
GRAPHENEOS RESPONDS: PROBABLY FEARMONGERING, BUT THE UNDERLYING PROBLEM IS REAL
Critically, GrapheneOS itself stepped into the thread and pushed back on the most dramatic interpretation. Their comment, posted on the community forum, is worth reading carefully:
“This is fearmongering based on customer support making ridiculous claims to someone. There’s nothing illegal about using GrapheneOS and the customer support is nearly certainly making it all up to get the person to go away so the ticket can be considered closed. It’s unlikely the company has done anything to specifically detect GrapheneOS or ban using it. It’s far more likely they detect not using a Google Mobile Services operating system without modifications. This customer support person went on a power trip to scare someone and get the ticket closed.”
That is a measured and probably accurate read of this specific incident. A support agent with a tiny amount of power over a user’s account used it. That happens. What GrapheneOS is essentially saying is: don’t extrapolate a dystopian surveillance apparatus from one person’s bad day in a ticket queue.
But here’s where it gets more complicated. GrapheneOS is also technically correct that detecting their OS is not particularly difficult and that this is not unique to GrapheneOS. In a separate comment in the same thread, they explained the mechanics:
“Apps can easily detect the operating system they’re running on using many standard APIs or simply inspecting their own memory. Apps can directly use the hardware attestation API to check the operating system and device model. Apps can use the Play Integrity to check for Google-certified hardware running the Google-certified stock OS, which uses the hardware attestation API itself and will be making it mandatory.”
So, the detection is real. The automatic-reporting-to-authorities claim is probably not – at least not as a formal policy. The question is whether it matters.
HOW GRAPHENEOS IS DETECTED: THE TECHNICAL PICTURE
This is where the story gets genuinely interesting from a security and privacy engineering standpoint, and where most of the coverage has skimmed the surface.
Android’s ecosystem is built on a chain of trust that flows from hardware through firmware through the operating system through Google’s certification layer. At every step, there are mechanisms designed to let apps and services verify they’re running on unmodified, certified hardware and software. GrapheneOS, by its nature, sits outside that chain. Not because it’s insecure, but because it isn’t Google-certified stock Android.
There are several distinct technical pathways through which a service like Yoti could detect GrapheneOS:
Hardware Attestation API
Android’s hardware attestation system allows any app to request a cryptographically signed certificate from the device’s Trusted Execution Environment (TEE). This certificate includes the device’s verified boot key – a cryptographic fingerprint of the operating system that booted the device. GrapheneOS has its own boot keys, distinct from those used by stock Android on any given device model.
When an app submits an attestation request and checks the verifiedBootKey field against a known list of manufacturer boot keys, a GrapheneOS device fails the check immediately. The boot key simply doesn’t match anything on the approved list. No heuristics needed. No side channels. The cryptographic proof is right there in the attestation certificate.
This is deterministic detection, not probabilistic. There is no ambiguity. If the service is using hardware attestation, it knows exactly what OS booted the device.
Google Play Integrity API
The Play Integrity API is Google’s more recent evolution of the old SafetyNet attestation system. It works similarly but with a stronger enforcement posture. The API returns a verdict categorizing the device into one of three tiers:
– MEETS_DEVICE_INTEGRITY: The device is running a genuine Android OS on certified hardware, passing basic integrity checks.
– MEETS_STRONG_INTEGRITY: The device has passed hardware-backed attestation, confirming a Google-approved boot chain.
– NO_INTEGRITY: The device has failed integrity checks. This is where GrapheneOS ends up.
Google has been progressively tightening Play Integrity requirements and has signaled plans to make hardware-backed attestation mandatory for certain API calls. As that rollout continues, the number of apps that will functionally refuse to run on non-certified operating systems – including GrapheneOS will grow.
Yoti, as an age-verification platform, has strong incentives to use the strictest integrity checks available. Regulators expect age-verification systems to be tamper-resistant. An age-verification service that could be trivially bypassed by running an alternative OS would face regulatory blowback. The business logic for using Play Integrity here is not nefarious. It follows directly from what regulators are asking for.
Behavioral and Side-Channel Fingerprinting
Beyond formal attestation APIs, GrapheneOS has a secondary detection surface: its own security hardening. As one technically informed community member noted in the thread, GrapheneOS implements security mitigations that simply do not exist on stock Android or other Android variants. One example is secure exec spawning – a hardened process-spawning mechanism that leaves a measurably different behavioral footprint than the standard Android zygote-based app launch process.
An app with sufficient permissions and instrumentation can detect these behavioral differences through timing side channels or by observing anomalies in system call patterns. This is more complex than attestation-based detection and requires deliberate instrumentation, but it is feasible.
The net result is that GrapheneOS is, as one forum commenter put it bluntly, a “heatscore” which is a device configuration that flags immediately in any environment built around Google’s integrity infrastructure.
The Sandboxed Google Play Factor
GrapheneOS ships with an optional compatibility layer called Sandboxed Google Play. This allows users to run Google Play Services and Play Store in an isolated sandbox, without granting them the privileged system-level access they would have on stock Android. The goal is to let users run apps that require Google services while limiting those services’ reach into the rest of the system.
However, Sandboxed Google Play is still sandboxed. Attestation requests that require hardware-backed, system-level trust pass through the sandbox’s restricted environment. The attestation certificate still reflects GrapheneOS’s boot keys. Apps that check Play Integrity while running through Sandboxed Google Play still get a verdict that reflects the underlying OS. The sandbox buys privacy from Google services on the device; it does not buy a passing attestation grade.
THE COMPLICATING CONTEXT: WHO WAS THIS USER?
Before this story calcified into a clean narrative of surveillance vs. privacy, a Hacker News comment added a layer of context that muddied things considerably. The top-voted comment on the HN thread pointed out something that several people in the community had noticed and then stepped back from discussing:
“The OP of this Reddit post has a lot of other posts (now hidden) about age verification, bypassing it, and privacy. They even got called out about this in the Reddit thread and responded by hiding their profile, but you can see it on Google still if you Google for ‘reddit PaiDuck.’ Not saying what this company did is right, but it feels like this guy has been testing how far he can push these various age verification companies with bypass attempts, and as a result got banned. Additionally, the email response from the company could have been trivially edited before the screenshot was taken, so I’m not even convinced that the story is real.”
This is not nothing. A screenshot of a support email is not independently verifiable. The user’s prior post history suggests someone actively probing age-verification systems for weaknesses, not an ordinary PlayStation user who ran into an unexpected wall. It’s possible the screenshot was edited. It’s possible the support agent’s language was a response to prior suspicious behavior from this account. It’s possible this is exactly what it looks like and a support agent typed something genuinely indefensible.
The honest answer is: we don’t know. GrapheneOS’s read that a support agent was being a bully and making up policy is plausible. A bad-faith test of age-verification systems that got flagged for prior behavior is also plausible. These are not mutually exclusive.
What is not really in dispute is the underlying technical reality: age-verification systems built on Google’s integrity infrastructure will systematically fail users running non-certified operating systems. That happens regardless of why you’re running GrapheneOS or what you’ve done previously.
THE BROADER CONTEXT: AGE VERIFICATION IS EXPANDING FAST
This incident, whatever its exact details, lands in the middle of a significant and accelerating policy shift in the UK, EU, and US around mandatory age verification for online platforms.
In the UK, the Online Safety Act has placed Ofcom in the position of enforcing age verification requirements for platforms hosting pornography and for social media platforms accessible to children. The Act gives Ofcom the power to fine platforms up to 10% of global revenue for non-compliance. That is a very large incentive to implement strict, technically robust age-verification measures.
The practical effect is that platforms are racing to implement systems that can satisfy regulators. And regulators, understandably, are skeptical of age-verification systems that can be easily circumvented. The more robust the integrity checking, the harder it is to bypass using a different OS, a VPN, or a modified client.
The problem is that “harder to bypass” and “systematically excludes people using privacy-focused operating systems” are the same thing in the current technical architecture. The Play Integrity API does not distinguish between a 14-year-old trying to lie about their age and a 35-year-old who prefers not to run Google-certified stock Android for entirely legitimate privacy reasons. Both get the same verdict. Both face the same wall.
This is the structural tension that the Yoti incident has surfaced. The incident itself may be ambiguous. The structural problem is not.
THE R/PRIVACY DIMENSION: GRAPHENEOS AND THE MODERATION WARS
One detail in the community thread that deserves more attention than it usually gets: GrapheneOS’s comment about Reddit’s r/privacy subreddit.
The subreddit which is ostensibly a hub for privacy-conscious users have, according to GrapheneOS’s forum response, a standing policy against discussing GrapheneOS specifically. The team described it this way:
“The ban on discussing it exists because the moderators are hostile towards our team and actively participate in attacks on us including making vile personal attacks and libelous claims. Many of our users have been banned from /r/privacy for voicing support for GrapheneOS, countering false claims about it, or simply trying to discuss it.”
Whether or not you take GrapheneOS’s account of the mod team’s motivations at face value, the practical reality is documented: the PaiDuck thread survived in r/privacy only because it didn’t explicitly mention GrapheneOS in the title or body text. The moment it had the word “GrapheneOS,” it would have been removed under a rule supposedly about “alternative mobile operating systems” but enforced selectively.
A subreddit called r/privacy that actively moderates away discussion of one of the most technically rigorous privacy operating systems available is a strange thing. It is also, for anyone who spends time in online privacy communities, not entirely surprising. Community politics are frequently more about personalities and perceived alliances than about the actual topic at hand.
WHAT HAPPENS TO GRAPHENEOS USERS IF THIS SCALES?
Here is the scenario that the more technically minded people in this thread are actually worried about, and it is worth stating plainly.
Google has made no secret of the direction Play Integrity is heading. The API is being tightened, hardware attestation requirements are being strengthened, and the list of apps that check Play Integrity before launching is growing. As the UK, EU, and US mandate age verification across more platforms, and as those platforms integrate with the most available and technically defensible verification solutions which currently means systems built on Google’s integrity infrastructure – the number of services that functionally exclude non-certified operating systems will increase.
This is not a conspiracy. It is the predictable intersection of three independent trends: regulatory pressure for robust age verification, Google’s commercial interests in making Play Integrity the dominant app security standard, and the fact that alternative operating systems like GrapheneOS are categorically outside the certified boot chain.
The end state, if nothing changes, is a growing list of digital services that simply do not work on GrapheneOS or any other OS outside Google’s certification program. Age-verification gates for gaming platforms are just the most visible early example. Government services, financial apps, and healthcare platforms are likely to follow, driven by the same regulatory logic.
One community member suggested the practical workaround: maintain a separate cheap phone running stock Android with zero personal data, used exclusively for identity verification and government apps. Use GrapheneOS for everything else. This is technically sound advice. It is also a reasonable description of a two-tier mobile internet – one tier for people willing to run a privacy-respecting OS and another for interacting with an increasing number of gated services.
THE PLAY INTEGRITY PROBLEM IS BIGGER THAN GRAPHENEOS
It is worth being precise about what is actually happening here, because the framing of “GrapheneOS vs. Yoti” understates the scope of the issue.
Play Integrity, in its strictest implementation, does not just flag GrapheneOS. It flags any Android installation that is not Google-certified stock Android on Google-certified hardware. That includes:
– Custom ROMs of any kind (LineageOS, CalyxOS, DivestOS, and others)
– Rooted stock Android
– Android running in emulators or virtual machines
– Developer builds and unlocked bootloaders
The mechanism is designed to enforce a specific trust model: only devices running exactly what Google has certified, on hardware Google has approved, are considered trustworthy. Everything else is, in the API’s framing, untrusted.
This trust model has obvious benefits for detecting actually malicious modifications because rooted devices are used to bypass security controls, emulators used to fake device identity, modified clients used to manipulate app behavior. It also has an obvious blind spot: it treats all non-certified configurations identically, regardless of why they exist or how secure they actually are.
GrapheneOS is, by most objective technical measures, significantly more secure than stock Android for most threat models. It has a stronger hardened malloc implementation, more aggressive ASLR, better isolation between apps, and a smaller attack surface from Google services. An attestation system that concludes GrapheneOS is less trustworthy than stock Android is not wrong about what it is measuring – it is measuring a very specific definition of “trustworthy” that is essentially synonymous with “running what Google approved.” Those are not the same thing.
WHAT YOTI SHOULD DO, AND WHAT IT PROBABLY WON’T
Yoti has not issued a public statement about this incident. That’s worth noting.
A company in Yoti’s position which is operating a service that intersects with law enforcement referrals, regulatory compliance, and the digital rights of millions of users across multiple countries has an obligation to be transparent about what its systems actually do when a user’s verification fails. “Your device configuration is incompatible with our verification system” is a complete and accurate response. “We have reported you to the authorities for using a privacy-focused operating system” is not something a company should be saying through a customer support agent if it is true, and not something it should be saying if it is false.
If Yoti’s system genuinely reports device OS information to law enforcement as part of a standard failed-verification workflow, that policy needs to be disclosed in their privacy documentation, their terms of service, and their regulatory filings. If it doesn’t, and a support agent made it up, Yoti should say so publicly.
The absence of any statement, nearly a week after the story reached several million people through YouTube alone, is its own kind of answer.
COMMUNITY REACTION: WHAT THE THREADS ACTUALLY SAID
Across the GrapheneOS forum thread, Hacker News, and the archived Reddit discussion, the response split roughly along predictable lines but with some interesting nuance.
Most of the technically informed commenters landed where GrapheneOS did: the specific support message is probably a rogue agent making things up, but the underlying detection and exclusion are real and are going to get worse. A commenter on the GrapheneOS forum made the practical point succinctly: the user who tried to verify their identity through Yoti on their GrapheneOS device may have inadvertently compromised whatever anonymity they had on the Proton Mail account they were using, because Yoti now knows the connection between that account and a device running GrapheneOS.
The more philosophically inclined thread participants noted the obvious irony: a system sold as privacy-preserving age verification may be logging device OS information alongside identity documents, in a format apparently accessible to customer support agents, apparently triggerable as a law enforcement report. Whether or not that’s what actually happened, the possibility is uncomfortable.
A few commenters took the position that none of this is surprising and the correct response is to refuse to engage with these systems at all – don’t verify your age to use a gaming platform, don’t give Yoti your ID, switch to PC gaming and wait for cracks. This is coherent as a personal choice. It is also an increasingly difficult posture as more services make verification mandatory under regulatory pressure.
The most practical comment in the thread may have been the one recommending a dedicated verification device – stock Android, no personal data, used only for identity checks. Boring, inconvenient, and probably the right answer for people who care about this.
THE GAMING INDUSTRY AND VERIFICATION CREEP
There is a broader story here about where gaming is going that is worth spelling out, even though it’s uncomfortable for an industry that has been notoriously resistant to talking about it directly.
The combination of kernel-level anti-cheat (Vanguard being the most discussed example), always-online requirements for single-player games, platform-level identity verification, and now third-party age-verification systems that integrate with device integrity APIs represents a significant and cumulative narrowing of the conditions under which you are “allowed” to play a game you have paid for.
Twenty years ago, you bought a game on a disc. No one needed to know who you were, what device you were on, or how old you were. The transaction was complete at purchase.
Today, the transaction at purchase is increasingly just the beginning. You agree to platform terms of service. You agree to the game’s terms. You may need to verify your age. Your platform checks your device integrity. Your anti-cheat scans your kernel. And if any of these checks fail for any reason, including running a privacy-respecting OS, you may simply not play, with no clear recourse and no refund.
This is not an argument against any specific policy in isolation. Age verification exists because children are accessing age-inappropriate content, and that is a real problem worth addressing. Anti-cheat exists because cheating in multiplayer games genuinely degrades the experience for other players. Device integrity checks exist because fraud and fake accounts are real.
The argument is about the cumulative effect and the absence of any mechanism for users who have legitimate reasons to fall outside the expected configuration. There is currently no pathway in the Play Integrity system for “I am running a more secure operating system than stock Android and I should pass integrity checks for that reason.” The system does not accommodate that concept. Trustworthy means Google-certified, full stop.
Whether that’s intentional or an oversight or an inevitability of how attestation systems work is, at this point, somewhat academic. The practical effect is the same either way.
FREQUENTLY ASKED QUESTIONS
Q: Did Yoti actually report this user to the police?
Probably not in any meaningful sense. GrapheneOS’s assessment that a customer support agent was making things up to close a ticket is the most likely explanation. There is no confirmed report of any law enforcement contact arising from this incident. The screenshot, which is the only primary evidence, is also unverifiable and could have been edited.
Q: Can Yoti actually detect GrapheneOS?
Yes, through standard Android APIs. The Play Integrity API will return a failed verdict for any device not running Google-certified stock Android, which includes GrapheneOS. Hardware attestation will expose GrapheneOS’s distinct boot keys. Neither of these requires GrapheneOS-specific detection logic – GrapheneOS simply fails the checks that all non-certified Android installations fail.
Q: Is it illegal to use GrapheneOS?
No. GrapheneOS is legal open-source software. Using it is not a crime in any jurisdiction we are aware of. A support agent claiming otherwise is wrong, either through ignorance or deliberate misrepresentation.
Q: Does GrapheneOS’s Sandboxed Google Play fix this?
No. Sandboxed Google Play allows GrapheneOS users to run Google Play Services in a restricted sandbox, which enables many Google-dependent apps to function. However, attestation requests that require hardware-backed system-level trust still reflect the underlying GrapheneOS boot state. A Play Integrity check run on a GrapheneOS device with Sandboxed Google Play will still return a failed verdict.
Q: Should I use a separate device for age verification?
If you run GrapheneOS or any other non-certified Android OS and need to use services that require Play Integrity verification, a separate stock Android device with no personal data is the currently practical workaround. It is an imperfect solution to a structural problem.
Q: What is Yoti used for beyond PlayStation age verification?
Yoti provides identity and age verification for Instagram, Facebook Dating, Epic Games, the UK Post Office, and a range of UK and EU retailers. Its services sit at the intersection of social media, gaming, government services, and age-restricted retail which makes the question of how it handles non-standard device configurations more than a niche privacy concern.
Verdict
There is a temptation to tell this story as a clean binary: surveillance state vs. privacy advocates, Big Tech vs. open source, Yoti vs. GrapheneOS. The reality is messier.
The specific incident that started this thread is probably less dramatic than the screenshot suggests. A support agent abused their access to scare a user, or possibly a user who had been probing age-verification systems for bypass methods got flagged for suspicious behavior and then framed the outcome in maximally alarming terms. We don’t have enough verified information to be certain either way.
What is not ambiguous is the structural situation. Age-verification systems built on Google’s integrity infrastructure will exclude users running non-certified operating systems. Regulatory pressure is pushing more platforms toward mandatory, technically robust age verification. Google’s Play Integrity API is the dominant technical implementation of that pressure. GrapheneOS, and every other non-certified Android variant, fails Play Integrity by design. These facts are all independently confirmed and are not contingent on anything about this particular incident.
The question worth asking – and the one regulators, platform operators, and verification companies have not meaningfully engaged with is whether a definition of “trustworthy device” that is functionally synonymous with “running exactly what Google certifies” is the right foundation for an age-verification infrastructure that is being positioned as mandatory access control for the internet.
That is a policy question. The technical answer is already decided: if Play Integrity is the standard, GrapheneOS users are outside the perimeter. The policy question is whether that’s acceptable, and who gets to decide.
Nobody in a position to change it seems particularly interested in asking.
This post first appeared at - The CyberSec Guru