# C2PA and Pixel Glitter Milk > Source: > Published: 2026-08-25 14:28:21+00:00 [C2PA and Pixel Glitter Milk](/blog/index.php?/archives/1102-C2PA-and-Pixel-Glitter-Milk.html) ## Tuesday, 25 August 2026 The news has been full of incredible reports recently. Like this one: As proof of this incredible story, we have a photo of a farmer milking a unicorn cow! According to There's just one problem: It's a forgery. The picture is AI generated and the news article is fiction, but Google's signatures are real. Industry Nearly a year ago (September 2025), Google made a big announcement about the Pixel 10 product line. They explained " Two months later (November 2025), PASAWG, one of my coworkers (Shawn), and I reported to representatives from Google and C2PA about a potential problem with Google's Pixel camera. In particular, we theorized that someone with root on the device could sign any picture as if it were from the camera. While the C2PA representative listened to the concerns, the Google representative was adamant that this type of attack was not possible. In particular, the signing keys are stored in a secure chip and cannot be extracted, and the Android architecture prevents unauthorized applications from accessing the keys. Three months ago (May 2026), a researcher named retr0id (David Buchanan) contacted me. He took the exploit from theoretical to implementation. He sent me two sample pictures that were signed using a Google Pixel device. To say I was impressed is an understatement. But I wanted hard proof that he had implemented it. I sent him a challenge: When I asked retr0id how he did it, he sent me back a wonderful picture that explains the process: The C2PA signing keys are in a subsystem called ' The exploit: This is the hardest part. The Android operating system is intentionally locked down, so it's hard to get root access. A common attack for Android devices replaces the bootloader. However, replacing the bootloader requires a factory reset, so you cannot access any secrets or protected data that existed prior to unlocking. To implement the exploit, retr0id needed root access without a reset. As a hardware specialist, retr0id used a well-known chip-based approach to get a root shell. His implementation was hardware-specific, but the underlying methodology has been around for at least a decade. Moreover, preventing this attack vector requires completely redesigning the hardware architecture. However, we are not limited to a hardware exploit. During the 90-day responsible disclosure waiting period, two other software-only exploits came out that also granted root access. ( Regardless of your method, you just need to get root on the device. Find the program that signs the C2PA metadata using the protected keys. Use the program to sign anything. This is a If you have root on the Pixel device (and you didn't change the bootloader), then you can sign any file as if it came from the Pixel camera. The signature will be legitimately signed by Google. As an aside: For most exploits, saying "start with root" means that additional exploits add nothing. If you have root, then you already control everything. I.e., creating more backdoors is trivial if you can already alter every file. However, with Google and C2PA, we're not using root to stay on the device; we're using it to create authoritative files. Those files will leave the device as the forgeries are disseminated. With this attack vector, gaining root is just the beginning. For this Pixel vulnerability, we recorded the reporting history: We have done our due diligence for reporting this problem. Google has decided to downplay the vulnerability, claiming that it isn't a noteworthy security issue. In contrast, C2PA did not respond at all. There are two major problems with relying on revocation to fix forged media: By choosing privacy through single-use certificates, and without addressing local key abuse, Google created a system where revoking a compromised image is nothing more than security theater. Image provenance is critical for determining whether the media represents something real or fake. Whether it's a political proof-of-life, images of war or strife, or even something less extreme, like an insurance claim, there are direct consequences from forged provenance. Google's If you still believe that C2PA works, then I have news for you: Scientists have created multi-colored sheep for dye-free yarn. According to The same class of vulnerability exists for Android and iOS (except that iOS is harder to root). Moreover, retr0id has additional working demonstrations from many other C2PA-enabled apps, including Proofmode (a We live in an era of deep skepticism, where public trust in visual media is at an all-time low. Proponents of C2PA argue that cryptographic signing solves this problem: if an official photo carries a valid, hardware-backed C2PA signature, the public can trust it. But the truth is that the C2PA signature carries no weight for providing any type of reliable authentication, validation, or provenance. Instead, it turns every device into a powerful tool for laundering disinformation as fact, which is worse than doing nothing. Special thanks to retr0id, Shawn, and PASAWG for their assistance. All vendors whose products are shown signing forgeries in this blog were notified of the problem. Claude and Gemini were used to help write portions of the code for these demonstrations. (At one point, we had to pause for a few hours after running out of free tokens.) Getting root is hard. Writing the code to implement the vulnerability is a very low bar and can be done with an AI assistant. BREAKING: Iowa Farmers Discover "Glitter Milk" from Unicorn Cows DES MOINES, IA - May 25, 2026 A handful of Iowa dairy farmers say they've started milking unicorn cows, and the results have local nutritionists scratching their heads. The milk sparkles. "It's real pretty in the morning sun," said Polk County dairy farmer Dale Hutchins. "First time I saw one with a horn, I figured I'd accidentally bought somebody else's livestock. Then it started making glitter milk." Researchers examining the milk say the shimmering particles appear to be naturally occurring protein crystals rather than actual glitter. Preliminary tests found the milk to be perfectly safe, with unusually high levels of vitamins and minerals. One eight-ounce serving reportedly contains an entire day's recommended vitamins A, C, D, E, B1, B2, B3, and B12. "The numbers keep coming back looking impossible," said one nutritional biochemist involved in the testing. "Either we've discovered something genuinely remarkable, or one of our graduate students has been replacing the samples with breakfast cereal." Children participating in a small nutrition study reportedly loved the milk, although several parents complained that the spilled cereal was "way harder to clean because the glitter goes everywhere." Federal regulators have not commented, and the Iowa Department of Agriculture says it's waiting for additional testing before making any official statements. If production continues, glitter milk could begin appearing in a few Midwestern co-ops later this year for about $8.99 a half-gallon. -Staff Reporter, Heartland Agricultural Digest As proof of this incredible story, we have a photo of a farmer milking a unicorn cow! According to [the metadata](https://hintfo.com/metadata.php?ffid=795662d70181afc3c17a9d50278788c14b714128.1189521):- The photo is from a Google Pixel 10 Pro. - The picture has cryptographically signed C2PA metadata. This data says it is "Created by Pixel Camera". The C2PA metadata even includes a 1024x768 preview image of the photo. Everything in the cryptographically signed manifest is consistent with a real photo from a Google Pixel camera. - In my blogs, I have repeatedly detailed ways to create "authenticated forgeries" using C2PA. However, the one thing I cannot forge is the cryptographic signature itself. This picture has a valid X.509 certificate chain that traces back to the C2PA-managed [trust list](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem). The certificate is issued by Google for the Pixel cameras. To my knowledge, nobody can forge this signature; this was really signed by a Google Pixel camera. - The cryptographic signature includes a signed timestamp. The timestamp is dated "2026-05-25 17:04:19 GMT" and the signer is Google. Again, I cannot forge this signed timestamp; this is real. - The C2PA organization has a list of [conforming products](https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/conforming-products/conforming-products-list.json). If we upload this glitter-milk picture to Adobe's Inspect service (a conforming product),[it reports](https://contentauthenticity.adobe.com/inspect?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3D795662d70181afc3c17a9d50278788c14b714128.1189521%26fmt%3Dorig%26search%3DAdobeCr)that this is a legitimate photo from a Pixel Camera, recorded on May 25, 2026. - The Adobe-run Content Authenticity Initiative (CAI) provides C2PA implementations. Their CAI Verify validator [reports](https://verify.contentauthenticity.org/?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3D795662d70181afc3c17a9d50278788c14b714128.1189521%26fmt%3Dorig%26search%3DContentCredentials)that the contents shows "captured media", came from Google LLC, issued by a Pixel Camera with a notation that it is "Conformant" (a conforming product), and includes a verified timestamp of "May 25, 2026 at 11:04 AM MDT". (They show the time relative to your own time zone, and I'm in MDT.) There's just one problem: It's a forgery. The picture is AI generated and the news article is fiction, but Google's signatures are real. Industry [best practices](https://www.cisa.gov/resources-tools/programs/coordinated-vulnerability-disclosure-program)for[responsible disclosure](https://projectzero.google/2025/07/reporting-transparency.html)suggest giving vendors 45-90 days to respond. Since we are 90 days past the vendor notification, I'm following industry best practices and making the details public.### Early Reporting History I've been working closely with a group of researchers at the University of Maryland, Baltimore County (UMBC). They have a Provenance and Authenticity Standards Assessment Working Group ([PASAWG](https://cisa.umbc.edu/pasawg/)) that has been formally evaluating solutions like C2PA. (While I'm a regular attendee, I'm there as a guest and resource, not a member.) One of the things I like about PASAWG is that they have a more formal way to report bugs than my typical "shouting into the blogosphere".Nearly a year ago (September 2025), Google made a big announcement about the Pixel 10 product line. They explained " [How Pixel and Android are bringing a new level of trust to your images with C2PA Content Credentials](https://security.googleblog.com/2025/09/pixel-android-trusted-images-c2pa-content-credentials.html)". Their bullet points (with their bold emphasis):As Carl Sagan said, "Extraordinary claims require extraordinary evidence." So we began to take a closer look. - The Pixel 10 lineup is the first to have Content Credentials built in across every photo created by Pixel Camera. - The Pixel Camera app achieved Assurance Level 2, the highest security rating currently defined by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currently only possible on the Android platform. A private-by-designapproach to C2PA certificate management, where no image or group of images can be related to one another or the person who created them. - Pixel 10 phones support on-device trusted time-stamps, which ensures images captured with your native camera app can be trusted after the certificate expires, even if they were captured when your device was offline. Two months later (November 2025), PASAWG, one of my coworkers (Shawn), and I reported to representatives from Google and C2PA about a potential problem with Google's Pixel camera. In particular, we theorized that someone with root on the device could sign any picture as if it were from the camera. While the C2PA representative listened to the concerns, the Google representative was adamant that this type of attack was not possible. In particular, the signing keys are stored in a secure chip and cannot be extracted, and the Android architecture prevents unauthorized applications from accessing the keys. ### More Researchers Unrelated to our research and reporting, I had been contacted by other researchers who thought that they found the same theoretical flaw. One in Canada, one in the US, and one in the UK; this shows that other people are thinking the same way. (And just because I didn't list any state-sponsored threat actors doesn't mean they are not also evaluating this vulnerability.)Three months ago (May 2026), a researcher named retr0id (David Buchanan) contacted me. He took the exploit from theoretical to implementation. He sent me two sample pictures that were signed using a Google Pixel device. To say I was impressed is an understatement. But I wanted hard proof that he had implemented it. I sent him a challenge: - Using ChatGPT, I generated the [source picture](https://fotoforensics.com/analysis.php?id=a07ff8efb86e7c0abbd6147638f2acfafabbdf0d.2844843)of a unicorn cow being milked. - ChatGPT's picture was a PNG with an embedded C2PA manifest. I stripped out the manifest and re-encoded the picture as a JPEG. - I found a different picture from a Pixel 10 and copied over the metadata. This way, the forgery had all of the correct metadata fields for that camera. I intentionally left the EXIF date wrong (dated 2025-08-29 02:10:17 GMT) and set the EXIF camera model name to "Pixel 10 Pro Totally Legit". - I sent my forgery to retr0id. - Two minutes later (not kidding), retr0id sent the signed forgery back to me. That two minutes includes receiving the image from me, transferring it to the Google Pixel for signing, signing it, and zipping it up to send back to me. Just the data transfers probably took him a minute and a half. This means that it's mostly an automated exploit. (He's released [some of his tools](https://github.com/DavidBuchanan314/keystork)on GitHub.) ### The Vulnerability I'm going to be intentionally vague here because I don't want to enable bad actors. However, the vulnerability isn't very deep and anyone who can get past the first step is almost certainly able to exploit it.When I asked retr0id how he did it, he sent me back a wonderful picture that explains the process: The C2PA signing keys are in a subsystem called ' [StrongBox](https://source.android.com/docs/security/best-practices/hardware)'. This is a secure storage area for handling the keys. The keys go in and never come out. You need a special program in the Trusted Execution Environment (TEE) to access the keys. This special program sends data to be signed by the keys and receives the signature.The exploit: **Step 1: Get root on the device.** This is the hardest part. The Android operating system is intentionally locked down, so it's hard to get root access. A common attack for Android devices replaces the bootloader. However, replacing the bootloader requires a factory reset, so you cannot access any secrets or protected data that existed prior to unlocking. To implement the exploit, retr0id needed root access without a reset. As a hardware specialist, retr0id used a well-known chip-based approach to get a root shell. His implementation was hardware-specific, but the underlying methodology has been around for at least a decade. Moreover, preventing this attack vector requires completely redesigning the hardware architecture. However, we are not limited to a hardware exploit. During the 90-day responsible disclosure waiting period, two other software-only exploits came out that also granted root access. ( [Exploit #1](https://cybersecuritynews.com/bad-epoll-0-day-vulnerability/amp/)and[Exploit #2](https://cyberpress.org/ionstack-attack-full-control-android/).) It doesn't matter that these software exploits have been patched; a malicious attacker won't patch their system and can gain root access on their own device. (As far as I can tell, you can still take signed photos, even if the device hasn't been patched recently.)Regardless of your method, you just need to get root on the device. **Step 2: Sign your data** Find the program that signs the C2PA metadata using the protected keys. Use the program to sign anything. This is a [Confused Deputy](https://en.wikipedia.org/wiki/Confused_deputy_problem)attack. When using Android's secured environment, only the TEE program can submit data to be signed, but the root user can provide any data to the signing program. Fixing this part of the problem requires redesigning the entire Android security model. In other words, there is no easy patch.If you have root on the Pixel device (and you didn't change the bootloader), then you can sign any file as if it came from the Pixel camera. The signature will be legitimately signed by Google. As an aside: For most exploits, saying "start with root" means that additional exploits add nothing. If you have root, then you already control everything. I.e., creating more backdoors is trivial if you can already alter every file. However, with Google and C2PA, we're not using root to stay on the device; we're using it to create authoritative files. Those files will leave the device as the forgeries are disseminated. With this attack vector, gaining root is just the beginning. ### Reporting Timeline I currently have over[40 blog entries](/blog/index.php?/categories/23-Authentication)about C2PA problems, and most of them disclose distinct vulnerabilities. While the public didn't know most of these problems until I made them public,*none*of the vulnerabilities have been new to C2PA members.For this Pixel vulnerability, we recorded the reporting history: - We reported it, via email and verbally, to both Google and C2PA representatives. The reporting included details and the demonstration picture. Following best practices for responsible disclosure, we gave them [90 days](https://projectzero.google/vulnerability-disclosure-policy.html)to respond. (Today, Aug 25, is 90 days from the initial vendor reporting, and about 9 months since the theoretical vulnerability was disclosed.) - We reported it to Google because the exploit is explicitly demonstrated against Google's flagship product, the Pixel series of Android devices. - We reported it to C2PA because the Pixel 10 was the first "Level 2" conforming product. [Assurance Level 2](https://github.com/c2pa-org/conformance-public/blob/main/docs/v0.2/C2PA%20Generator%20Product%20Security%20Requirements.md#level-2)means that it must protect the signing keys. However, while the keys are protected from extraction by the Android StrongBox, this exploit shows that the keys can still be used to sign anything. In effect, the keys are unprotected. So either Google is not Level 2 conforming (false advertising), or they are Level 2 on paper but not in the implementation (deceptive practices), or Level 2 is grossly insufficient for providing any kind of assurance (misleading). In any case, this is definitely a C2PA conformance program problem. - I made it clear that I planned to blog about this problem. But I also offered to work with them on the release cycle. For example, if they were about to provide a patch, then I would be willing to delay the blog and coordinate a release. Both Google and C2PA repeatedly acknowledged my offer during the 90-day period. However, I received no feedback from either organization. - Google has a bounty program that pays researchers for finding vulnerabilities. I never signed up because Google requires agreeing to legal terms. (Even if I conceptually agree to the reasons behind their terms, I cannot sign anything that could be construed as a legal agreement. I just want to report a bug.) However, retr0id doesn't have those same limitations. Since he implemented it, we (PASAWG, myself, and Google) asked him to submit it through Google's [Vulnerability Reward Program](https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules)(VRP). He did. - Google's VRP almost immediately sent retr0id two emails. The first said that the vulnerability was out of scope. The second said to ignore the first email and that it was in scope. They did end up logging it as a received report. - Fast forward two months. Retr0id received an email from Google's VRP. (I am [including it here](https://fotoforensics.com/analysis.php?id=6f310b7323573b5a9d5fb980420591abe08486b3.160594&fmt=orig)with his permission.) They closed it out as a "Won't Fix (Infeasible)". Google[[email protected]](/cdn-cgi/l/email-protection)#9 Jul 14, 2026 12:36AM *Status: Won't Fix (Infeasible).* Hello, The Android Security Team has conducted an initial severity assessment on this report. Based on our published severity assessment matrix (1) it was rated as not being a security vulnerability that would meet the severity bar for inclusion in an Android security bulletin. If you have additional information that you believe we should use to reassess this report, please let us know. Please note that notwithstanding our severity rating and the closure of this external bug, we may nonetheless pass this issue on to the feature team for remediation. Therefore, please know that we appreciate this submission and any future contributions. The Resolution Notes label has been set to NSBC (Not Security Bulletin Class) to reflect this assessment. Thank you, Android Security Team. (1) Severity Matrix: https://source.android.com/security/overview/updates-resources#severity How did we do? Please fill out a*short anonymous survey*.[defines "Won't Fix (Infeasible)"](https://source.android.com/docs/setup/contribute/report-bugs#no-action-issues)as "The changes that are needed to address the issue are not reasonably possible." More importantly, Google labeled it as "NSBC (Not Security Bulletin Class)". This[code](https://source.android.com/docs/security/overview/updates-resources)means that it either isn't a security vulnerability or isn't considered severe. In effect, Google explicitly said that a vulnerability in Google's flagship Pixel product line, which permits anyone to sign anything as if it legitimately came from the camera, is not a significant*security vulnerability*. I disagree with Google: verifiable history (provenance), reliable source attribution, and secure key management are explicitly security concerns. (See[NIST SP 800-193](https://csrc.nist.gov/pubs/sp/800/193/final)*Platform Firmware Resiliency Guidelines*,[NIST SP 800-57](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)*Recommendation for Key Management*, and[NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)*Security and Privacy Controls for Information Systems and Organizations*.) This demonstrates a fundamental disconnect between how Google views "OS platform boundaries" and "content provenance integrity". We have done our due diligence for reporting this problem. Google has decided to downplay the vulnerability, claiming that it isn't a noteworthy security issue. In contrast, C2PA did not respond at all. ### Revoking Certificates Within days of demonstrating the bug and sharing the sample image, Google revoked the X.509 signing certificate used for the glitter-milk picture. That sounds like responsible incident response on the surface, but in practice, it reveals a fundamental flaw in how Content Credentials interact with public key infrastructure (PKI). Keep in mind, they quickly revoked the certificate (a security response), despite Google's formal response weeks later saying that it was not significant enough for a security bulletin.There are two major problems with relying on revocation to fix forged media: **Validators Don't Check Revocation** The current C2PA specification[does not require](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_validate_the_credential_revocation_information)validators to perform revocation checks. As of this writing, I am unaware of any conforming validator products that check whether a manifest's certificate has been revoked. So even though Google revoked the certificate for the glitter-milk photo, most C2PA validation tools will still happily report the image as authentic.**The Privacy Paradox: Unique Signing Certificates** To prevent third parties from tracking users across photos, Google designed their C2PA implementation to issue an ephemeral, unique signing certificate for every single photo. The trust chain looks like this: **Root CA:** Google's root certificate sits on the C2PA-managed[trust list](https://github.com/c2pa-org/conformance-public/blob/main/trust-list/C2PA-TRUST-LIST.pem).**Intermediate Certificate:** Google's root issues an intermediate certificate. As far as I can tell, every Pixel device uses the same set of intermediate certificates.**Leaf Certificate:** The intermediate cert issues a brand-new, single-use leaf certificate that is used to sign an individual image capture. Because every picture gets its own unique signing certificate, revoking the glitter-milk certificate only invalidated that one specific photo. This does not prevent retr0id (or anyone else with this exploit) from generating millions of additional forged images on that exact same compromised Pixel. **Ineffective Revocation:** Google can only revoke certificates for forgeries that are actively discovered and reported to them. Unreported forgeries remain 100% valid.**Denial of Service:** An attacker running an automated batch script could sign millions of synthetic images. Reporting all of these intentional forgeries would likely swamp Google's certificate revocation infrastructure. (At the technical level: this is an attack against the ingest pipeline and OCSP signer; C2PA does[not support CRLs](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_certificate_revocation)for revocation. Google currently lacks a portal or documented process for users to submit individual forged photos for revocation. If Google were to build a portal without rate-limiting, it risks becoming a bandwidth/DoS problem on its own. If they add CAPTCHA or other throttling to protect the ingest pipeline, then known forgeries may not be submitted in a reasonable time, and humans could become discouraged. Moreover, bulk OCSP revocation could plausibly strain cryptographic signing throughput.)**Verification Problem:** When a user submits a picture to Google for revocation, how does Google know that it really is a forgery? With the glitter-milk example, we explicitly showed them how it was made. However, a malicious person could submit legitimate photos and claim they are forgeries. Google needs some way to identify whether a signed picture from a Pixel device is actually from the camera. This remains a hard problem. Depending on their implementation, Google could reject real forgery reports if the verification process is too strict*or*revoke legitimate photos if it's too lenient. - Without C2PA: Individual analysts must evaluate the media using whatever tools they have available. - With Google's C2PA signature: When someone submits a picture for revocation, the onus is on Google to provide the verification. (I suspect that nobody asked Google's legal department about whether the company wanted to be put in the position of validating all pictures.) Keep in mind: the entire premise of C2PA is that Google cannot otherwise verify whether a picture is authentic, so asking Google to verify whether a revocation request's media is real just restates the same unsolved problem. **Painted Into a Corner:** With the current architecture, Google cannot revoke the device's intermediate certificate without instantly invalidating every authentic, legitimate Pixel photo ever taken. Google's revocation approach effectively becomes*all or nothing*. In either case, they cannot stop one individual from creating signed forgeries. *in the exact same way*, is not an effective security solution.By choosing privacy through single-use certificates, and without addressing local key abuse, Google created a system where revoking a compromised image is nothing more than security theater. ### Real-World Problems It is easy to treat "Glitter Milk" as an amusing and harmless proof-of-concept. But the implications of a broken content provenance model are anything but funny.Image provenance is critical for determining whether the media represents something real or fake. Whether it's a political proof-of-life, images of war or strife, or even something less extreme, like an insurance claim, there are direct consequences from forged provenance. - This Mitch McConnell picture has no camera-original metadata, but does include an XMP record showing that it was altered with an Adobe application hours before being released to the public. If someone replaced the metadata with fake Google Pixel information, and then had it signed by a real Google Pixel device, would it be more trustworthy? - The second picture is from an artist who creates [AI-generated pictures](https://www.abc.net.au/news/2024-12-26/ai-generated-images-photography-trust/104721106)of life in Russia. If we removed the Facebook re-encoding artifacts and had it signed by a Google Pixel device, would you think it was authentic? - The third picture is part of a product defect claim. Unlike the first two, this one isn't hypothetical: it carries a cryptographically-valid [C2PA signature](https://contentauthenticity.adobe.com/inspect?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3Dae609b7be0cbb279125448f544a26400091ff8cb.5603249%26fmt%3Dorig%26search%3DAdobeCr)that genuinely came from a Google Pixel device. But now that we've shown that same "came from a camera" signature can be applied to non-camera media, should you trust it? ### Untrusted By Design This glitter-milk picture demonstrates how any image can be assigned false provenance and signed with a cryptographically valid Google signature. Moreover, this problem also works in reverse: genuine photos with signatures can be easily dismissed as "just another C2PA forgery." Regardless of the ground truth, an analyst cannot determine if a picture is real or fake based on Google's implementation of C2PA; the signature effectively means nothing.Google's [initial announcement](https://security.googleblog.com/2025/09/pixel-android-trusted-images-c2pa-content-credentials.html)made some extraordinary claims that have failed to stand up to scrutiny:**Claim:**"Pixel and Android are bringing a new level of trust to your images with C2PA Content Credentials". **Fact:** The devices can be used to sign any file, real or fake, with legitimate C2PA-signed claims identifying that the media came from the camera. This does not introduce a new level of trust; it enables a new way to commit fraud and disinformation.**Claim:**"The Pixel 10 lineup is the first to have Content Credentials built in across every photo created by Pixel Camera." **Fact:** This is false. Nikon shipped C2PA Content Credentials in Z6 III firmware in late August 2025, weeks before Google's announcement. Days later, researcher Adam Horshack showed the camera could be used to[sign arbitrary images](/blog/index.php?/archives/1078-Vulnerability-Reporting.html), forcing Nikon to[indefinitely](https://petapixel.com/2025/09/22/nikon-cant-fully-solve-the-z6-iiis-c2pa-problems-alone/)[suspend the service](https://petapixel.com/2025/09/05/nikon-suspends-c2pa-functionality-on-the-z6-iii-due-to-authentication-issue/)and[revoke every certificate](https://www.digitalcameraworld.com/photography/photojournalism/nikon-revokes-all-c2pa-image-authenticity-certificates-after-major-vulnerability-exposed)it had issued. Google isn't first; it's just the first to repeat Nikon's mistake with better marketing.**Claim:**"Pixel Camera app achieved Assurance Level 2 ... only possible on the Android platform." **Fact:** While they acquired Assurance Level 2 on paper, it appears to be absent in the implementation. Moreover, they stated that protecting the keys from signing arbitrary images is not possible ("Won't Fix (Infeasible)"), so whatever Assurance Level 2 is meant to guarantee, it clearly doesn't hold up in practice on the Android platform.**Claim:**"A private-by-design approach to C2PA certificate management, where no image or group of images can be related to one another or the person who created them." **Fact:** While true, this prevents them from revoking future pictures from a known-compromised device. A device that has been rooted and is generating signed forgeries can continue to operate unabated.**Claim:**"Pixel 10 phones support on-device trusted time-stamps, which ensures images captured with your native camera app can be trusted after the certificate expires, even if they were captured when your device was offline." **Fact:** While it is true that the Pixel 10 has a built-in trusted time-stamp service, that does not mean that it is only applied to "images captured with your native camera app". This claim is misleading. ### Flawed Foundations The problems detailed in this blog are not limited to the Google Pixel or its C2PA Assurance Level 2 rating. These problems are fundamental and impact other C2PA implementations. For example, Evergreen Labs has a C2PA[Assurance Level 2 application](https://spec.c2pa.org/conformance-explorer/)called "GreenCheckmark" ([screenshot](https://fotoforensics.com/analysis.php?id=79b3b1ba268d00c07debcb668684c4ad9df07953.175042&fmt=orig)) that can be used to sign any image or video as if it came from the device. However:- C2PA's Conformance Program only checks the paperwork for compliance, not the implementation. In this case, the Conformance Program states that the app has Level 2 assurance. - According to Evergreen Labs, the app received approval for Level 2, but only implemented Level 1. There is no C2PA-provided or user-identifiable information that identifies this discrepancy. - Even if the app was fully implemented, Assurance Level 2 requires using Android's StrongBox/TEE, and Google already stated that it knows the environment does not provide adequate protections ("Won't Fix (Infeasible)"). If you still believe that C2PA works, then I have news for you: Scientists have created multi-colored sheep for dye-free yarn. According to [Adobe Inspect](https://contentauthenticity.adobe.com/inspect?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3Dd7ec10248bb142641ddd95c7abea8727d5541db7.1031748%26fmt%3Dorig%26search%3DAdobeCr)(a conforming validator) and[CAI Verify](https://verify.contentauthenticity.org/?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3Dd7ec10248bb142641ddd95c7abea8727d5541db7.1031748%26fmt%3Dorig%26search%3DContentCredentials), this is legitimate "captured media" from a camera, signed by GreenCheckmark, and it is a Level 2 conformant application ([screenshot](https://fotoforensics.com/analysis.php?id=21f686667a0e8bee13f6988ec21082e8f33cdb61.484620&fmt=orig)). Similarly, YouTube's description reports that[this video clip](https://www.youtube.com/watch?v=x8tbP_C725Q)from the CGI movie "Big Buck Bunny" is signed by Evergreen Labs and "[Captured with a camera](https://support.google.com/youtube/answer/15446725?hl=en)" ([screenshot](https://fotoforensics.com/analysis.php?id=19ef264e6fa2c3a9e42dc34106e6e63c67a2903d.1641466&fmt=orig)).The same class of vulnerability exists for Android and iOS (except that iOS is harder to root). Moreover, retr0id has additional working demonstrations from many other C2PA-enabled apps, including Proofmode (a [Level 1 conformant](https://proofmode.org/blog/proofmode-android-conformant)app; see forgeries at[Adobe Inspect](https://contentauthenticity.adobe.com/inspect?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3D251765275f360bea2ee876c35e78dafdd56ebc6d.136315%26fmt%3Dorig%26search%3DAdobeCr)and[CAI Verify](https://verify.contentauthenticity.org/?source=https%3A%2F%2Ffotoforensics.com%2Fanalysis.php%3Fid%3D251765275f360bea2ee876c35e78dafdd56ebc6d.136315%26fmt%3Dorig%26search%3DContentCredentials)). To date,*no*C2PA implementations are immune to signing forged media.We live in an era of deep skepticism, where public trust in visual media is at an all-time low. Proponents of C2PA argue that cryptographic signing solves this problem: if an official photo carries a valid, hardware-backed C2PA signature, the public can trust it. But the truth is that the C2PA signature carries no weight for providing any type of reliable authentication, validation, or provenance. Instead, it turns every device into a powerful tool for laundering disinformation as fact, which is worse than doing nothing. Special thanks to retr0id, Shawn, and PASAWG for their assistance. All vendors whose products are shown signing forgeries in this blog were notified of the problem. Claude and Gemini were used to help write portions of the code for these demonstrations. (At one point, we had to pause for a few hours after running out of free tokens.) Getting root is hard. Writing the code to implement the vulnerability is a very low bar and can be done with an AI assistant. [Read more about] [Authentication](https://hackerfactor.com/blog/index.php?/categories/23-Authentication), [Forensics](https://hackerfactor.com/blog/index.php?/categories/14-Forensics), [Image Analysis](https://hackerfactor.com/blog/index.php?/categories/1-Image-Analysis), [Mass Media](https://hackerfactor.com/blog/index.php?/categories/6-Mass-Media), [Politics](https://hackerfactor.com/blog/index.php?/categories/13-Politics), [Privacy](https://hackerfactor.com/blog/index.php?/categories/9-Privacy), [Programming](https://hackerfactor.com/blog/index.php?/categories/5-Programming), [Security](https://hackerfactor.com/blog/index.php?/categories/4-Security)| [Comments (0)](/blog/index.php?/archives/1102-C2PA-and-Pixel-Glitter-Milk.html#comments)| [Direct Link](/blog/index.php?/archives/1102-C2PA-and-Pixel-Glitter-Milk.html)