When evaluating media provenance, the single most critical requirement is having consistent and repeatable results.

Imagine evidence presented in a courtroom: the prosecution presents a validation report claiming an image is real, while the defense presents a different validator showing it is fake. What is the jury supposed to think? If a judge admits both reports under Frye, Daubert, or Kumho standards, then the jury isn't just judging the media. The jury is forced to decide which software implementation to trust, undermining the goal of automated digital provenance. (Disclaimer: I am not an attorney and this is not a legal interpretation.)

Not every provenance validation solution is intended for legal use. Setting legal standards aside, consider the business implications. Companies often rely on partially-vetted heuristics to make important decisions. As an organization making critical decisions, would you rely on a solution that is designed to return contradictory findings? The wrong decision can result in customer complaints and damage your corporate reputation.

We could even consider a lower standard: social media. It's common to have online arguments and flame wars around contradicting opinions. However, when each side is backed by their own validation approach, it ends up increasing the divide rather than enabling a consensus.

This is the reality that has been provided to us from the Coalition for Content Provenance and Authenticity (C2PA). They have released a provenance solution that enables contradicting results. Moreover, they have backed it with a massive media blitz and widespread tech adoption.

Required Validation

In my previous blog entry, I walked through how different provenance solutions handle their verification workflows. Transport Layer Security (TLS, used by HTTPS) uses a strict, deterministic validation process (with only a small variation based on trust lists). Secure Evidence Attribution Label (SEAL) is only slightly more complex and has less variation. As long as you implement either protocol correctly, every validator should reach the exact same conclusion every single time.

C2PA takes the opposite approach. Its specifications rely on a complex workflow with explicit "optional" steps. Because these checks are optional, two fully spec-compliant validators can evaluate the exact same file and arrive at conflicting results. Moreover, users may never know which options the validator used.

(Click to see larger.)


In this workflow diagram, every red decision box highlights a step where optional parameters allow validators to diverge and produce conflicting outputs. The main issues are around which trust list is used (workflow steps 2 and 6), whether revocation is checked (steps 3, 7, 9, and 10), and how the timestamp is validated (steps 6, 7, and 9). This ambiguity-by-design in C2PA's workflow leads to two specific problems:

1. The specifications permit differences in validation behavior. This cannot be blamed on coding errors. Two validators can function properly and be fully compliant, and still reach conflicting results based on which options they choose to implement.


2. These differences can cause materially misleading conclusions about a file's trustworthiness. Users cannot reliably determine whether a file is authentic, AI-generated, edited, or trustworthy based on a validator's assessment. Even if every validator you test reaches the same conclusion, there could always be another validator that comes up with a different result.

Showing a workflow and claiming that a specification enables contradictory results is one thing, but proving it with real-world data is another. Throughout this post, I will walk through actual image files to demonstrate how C2PA's validation workflow breaks down in practice at each step.

Testing Methodology

To keep the comparison fair and comprehensive, I evaluated test images across a range of C2PA validators:

• Adobe Content Authenticity Inspect (https://contentauthenticity.adobe.com/inspect) is a "conforming product", which means that the implementation's details have been reviewed by C2PA and vetted against the specs.


• Verifieddit (verifieddit.com) from SanMarcSoft LLC is another conforming validator.


• CAI Verify (verify.contentauthenticity.org) is built and maintained directly by Adobe's Content Authenticity Initiative (CAI) using their official open-source JavaScript SDK. Ironically, despite being widely cited across CAI and C2PA publications, sharing development teams with Adobe Inspect (a conforming product), and using versions of the same JavaScript SDK, CAI Verify is not listed as a conforming product.


• IPTC Origin Verify (originverify.iptc.org) is provided by the International Press Telecommunication Council.


• C2PA.sh is provided by SSL.com, a commercial Certificate Authority and C2PA Trusted CA.


• Proofmode Verify (formerly "ProofCheck", check.proofmode.org) is provided by Proofmode, an early adopter of C2PA. Today, they have conforming generators for Android and iOS, but they are not listed as a conforming validator.


• Sony has a signature self checker that recognizes Sony's own C2PA signatures.

Along with the validators, I also used a wide range of pictures. Each picture is included in this blog. At any time, you can click on the picture to see the full-size file, save the file to your computer, and then upload it to any of these validators. (Don't take my word for it! Verify my findings and claims!)

While each of these platforms implement C2PA's solution, their outputs frequently disagree. Here is how that plays out in practice.

Picture/Validator	Flying Pug	Glitter Milk	Whack-a-Mole	Sheep	Bike	Protest	Voting	Sunset
Adobe Inspect	Trusted with timestamp, legacy warning	Trusted, from Google camera	Trusted, from Google camera	Trusted, from GreenCheckmark camera	Unrecognized, from Sony	Trusted, AI, with lots of metadata	Trusted, legacy warning	Trusted, from OpenAI
Verifieddit	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Trusted, "Looks authentic"	Valid, not trusted	Invalid, untrusted signer, AI	Trusted, "Looks authentic"	Trusted, AI
CAI Verify	Trusted with timestamp, legacy warning	Trusted, from Google camera	Trusted, from Google camera	Trusted, from GreenCheckmark camera	Unrecognized issuer	Unrecognized issuer, AI, test certificate	Trusted, legacy warning	Trusted, from OpenAI
IPTC Verify	Trusted (on ITL), no timestamp	Verified by a trusted timestamp authority, Revoked by the issuing authority	Verified	Timestamp authority not on a trusted list, Revoked by the issuing authority	Not on a trusted list	Unknown signer, no timestamp, test certificate	Verified, IPTC and ITL	On C2PA trust list, Timestamp authority not on a trusted list
SSL.com's C2PA.sh	Untrusted (revoked)	Revoked	Verified, Trusted timestamp	Revoked, Unknown Timestamp Authority (but SSL.com is the timestamp authority!)	Untrusted (unknown signer and timestamp)	Untrusted (unknown signer, cannot validate timestamp)	Untrusted	Verified
Proofmode	Trusted with timestamp	Trusted with timestamp	Trusted with timestamp and GPS	Trusted, Uncertain camera (no make/model)	"Uncertain"	Valid, AI generated and from a camera	Trusted, from a camera	Trusted, AI, Edited, Uncertain camera
Sony	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Trusted, incompatible timestamp	Unsupported

Although the C2PA specifications recommend how the user interface should report results, few tools follow those recommendations. Also keep in mind, everything with C2PA is dynamic. I did this test on 2026-10-12. If I did this same test 3 months ago, the results would have included a few different inconsistencies. (I'm sure that these vendors will see these results, make more changes without any coordination, and cause more contradictions.)

Example: Nikon and The Flying Pug

Click on the image to see the full size picture and save it for uploading to the validators.



This picture has a well-known history. In September 2025 (over a year ago), Nikon released C2PA for their Z6 III camera. Within days, researcher Adam Horshack figured out how to use this to sign any picture as if it came from the Nikon Z6 III. DP Review published details about the vulnerability. Literally the next day Nikon disabled their C2PA signing service, and they revoked their signing cert two weeks later.

If the validator checks for revocation, then it will report that the cert has been revoked. For example, c2pa.sh says that the image is "UNTRUSTED" because the certificate was revoked.



Unfortunately, as seen in the workflow, checking for revocation is optional. Neither conforming product (Verifieddit and Adobe Inspect) checks for revocation, so they report that the content is "Trusted". In fact, Verifieddit even adds, "The signature checks out and the source is one we recognise, so this photo appears to be a real, unedited capture."



Adobe Inspect has no banners or warnings about the picture being untrusted. At best, it has a small note that this picture from 2025 uses a "legacy version" of C2PA.



IPTC provides the only validator that says it checks multiple trust lists. They have teeny tiny icons with teeny tiny alert icons and on-hover text to identify which trust lists match the signature. Ignoring the poor usability aspect, identifying which trust list matched is a cool feature.



With the flying pug picture, first and third icons have tiny orange "!" symbols, indicating that the signature is not on the IPTC or C2PA trust lists. The second icon (a black-and-white squiggle box) has no tiny orange "!", indicating that it matched the ITL. IPTC also reports that there is no timestamp, even though Adobe Inspect shows a timestamp.

The CAI-managed Interim Trust List (ITL) was created as a temporary solution before C2PA had an official trust list. The ITL was officially frozen in January 2026. However, in March 2026, it was updated and the Nikon cert was removed. Since IPTC says Nikon is in the ITL, it means they are using a version before March 2026. In any case, IPTC doesn't notice that the certificate was revoked.

Personally, I find it hard to argue which is worse: accepting a revoked cert, or removing the cert from the trust list so you don't know if it was ever trusted. In either case, IPTC is using an older version of the 'frozen' ITL.

With this one picture, we have contradictions about whether it is valid or revoked, and if it has a timestamp or not.

Example: Google Pixel and Glitter Milk

A few months ago, I blogged about using the Google Pixel phone (a C2PA conforming product) to sign any picture. As an example, I used a picture of a unicorn cow being milked.



To their credit, Google revoked the signing cert shortly after my glitter-milk blog came out. They backdated the revocation to cover the entire certificate issuance range. Validators that do not check for revocation, such as Adobe Inspect, CAI Verify, and Verifieddit, all claim that it is a trusted picture from a Google Pixel camera, while validators that check for revocation (e.g., c2pa.sh and IPTC) say it is revoked.

Unfortunately, Google only revoked the specific signing cert attached to this picture. Since the Google Pixel uses a unique signing cert per picture, nothing stops me from immediately generating a new signing cert and signing more forgeries. Google can only revoke certs that they know about, so this becomes a game of whack-a-mole that Google can never win.



To demonstrate this, I created another picture showing Google playing a losing game of whack-a-mole. It is also signed by a Google Pixel camera (using certs from the same Pixel camera as glitter-milk). At the time of this writing, the whack-a-mole picture has not been revoked. If Google revokes it, then I can generate another (and another and another) version that is signed. I can easily generate them faster than Google can revoke them. Of course, that assumes Google knows about the forgery (they have no official reporting method) and you use a validator that checks for revocation (most don't because it is optional).


(When all you have is a hammer, everything looks like a whack-a-mole.)

Example: GreenCheckmark and Rainbow Sheep

Along with the glitter-milk picture, I created a picture using rainbow sheep. This picture was signed using GreenCheckmark (a conforming product). Although GreenCheckmark was notified before the blog came out, they only revoked it after the blog went public. The revocation date is 2026-08-26 18:16:06 GMT, even though the trusted timestamp says the picture was created on 2026-08-07 15:38:08 GMT (over 19 days earlier).



This time inconsistency becomes problematic. According to the C2PA documentation, validators can ignore revocation if there is a trusted timestamp and it is valid. As noted in 6.2.1. Revocation information and time-stamps (my bold for emphasis):

Attaching a time-stamp and freshness information to the signature allows validators to conclude the C2PA Manifest is still valid a) even if the signing credential has since expired or was revoked after signing time and b) without the need of an online query.

This introduces another potential inconsistency between validators. For example:

• All of the validators that do not check revocation say that the rainbow-sheep picture came from an Android and was signed by GreenCheckmark. No issues are found with the media.


• c2pa.sh notes that "the signing certificate (GreenCheckmark - Android) was revoked on 2026-08-26, after this file's claimed signing time, which nothing trustworthy confirms. Don't rely on this signer; the content itself may be unchanged. Reason given: keyCompromise."
  
  
  
  Within the world of Public Key Infrastructure (PKI; the use of public and private keys for signing), if a private key is reported as keyCompromise, then any signature made with that key -- regardless of the timestamp -- is fundamentally suspect because an attacker could have backdated or forged the signature prior to revocation discovery. However, C2PA's section 6.2.1 grants a loophole that permits revoked certificates. By allowing timestamps to override revocation, C2PA creates an incentive for attackers to timestamp forged manifests immediately.
  
  With this example, I cannot tell if c2pa.sh omits the optional specs section 6.2.1, doesn't like the timestamp signer, or doesn't include it on their trust list. It's worth noting that c2pa.sh is operated by SSL.com and the trusted timestamp was issued by SSL.com and is it listed as trustworthy on the ITL.


• IPTC says that the signing certificate was revoked and "Timestamp authority not on a trusted list". The timestamp authority that I used is SSL.com from the ITL. So while IPTC lists the ITL as one of the lists they trust (workflow step 2), they don't appear to use the trusted timestamp list from the ITL (workflow step 6). This contradiction means that the user doesn't know which lists the validator uses, even if the validator claims to use a specific list.
  
  

If IPTC or c2pa.sh used the complete ITL and followed specs section 6.2.1, then this picture would appear to be completely valid because it was revoked after the signed timestamp.



Example: Sony

C2PA does not require any specific certificate trust list. As noted in workflow steps 2 and 6, every validator can use their own trusted list. Sony is an example of a vendor that has defined their own certificate list: sony.pem.

I used Sony's service to download a set of keys and signed my own forgery as if it came from a Sony camera.



The validators from Adobe, CAI, Verifieddit, IPTC, and c2pa.sh do not use Sony's trusted list, so none find it trustworthy. At best, IPTC and Verifieddit both say that the crypto is valid, but the signers are unknown.



However, other validators report that the file is valid. For example, Proofmode Verify finds no problems with the file. It is signed by Sony and the timestamp is valid (because both signatures really are valid).



Sony's own signature self checker reports that the signing signature is valid, but they marked the timestamp as being "Incompatible".





Example: Enabling Propaganda

User 'bdcry' left a comment on my blog with a forgery he created:



This is a light-hearted example of how a forgery can be used for propaganda. According to Adobe Inspect (a conforming validator), this picture of a protest at the White House is valid AI from a Nikon COOLPIX 100 camera. Proofmode says it is verified, AI-generated, and from a camera. In contrast, CAI Verify, IPTC Verify, Verifieddit, and c2pa.sh do not recognize the signer.

With this example, bdcry demonstrates a wide range of metadata fields that can be injected into the file. With very little effort, the same forgery technique could be used to make it appear as a real photo, or make a real photo appear to be AI-generated.

It seems that bdcry has discovered a test certificate that Adobe accepts as valid, while Sony and Proofmode may not check certificates against any trust lists. Who knows what other hidden certificates are acceptable to different validators? This is why transparency around the trusted list (workflow steps 2 and 6) is incredibly important. A malicious user could easily create a realistic forgery and verify it using an accepting validator.



Consistently Inconsistent

These inconsistencies do not even require someone to maliciously manufacture an image. This picture of people voting comes from CBC/Radio-Canada. However, the link in their news report to "Learn more about this image" returns a 404 error, so the original provenance explanation is no longer accessible. The validators disagree on its trustworthiness: Verifieddit and Sony report it as trusted, Adobe Inspect and CAI Verify flag it as legacy, IPTC recognizes it through its trust lists, and c2pa.sh reports it as untrusted.



Similarly, I don't know who uploaded this sunset picture to FotoForensics, but it is signed by OpenAI. The signing cert is on C2PA's own trusted list, but the timestamp certificate is not. (I didn't do that; that's how OpenAI does it.) Verifieddit and c2pa.sh says it is fully trusted. IPTC doesn't trust the timestamp authority. Proofmode says the media is both AI-generated and edited. (I don't know how they came up with 'edited' based on the C2PA information.) Adobe Inspect and CAI Verify say the signature is valid, and silently ignore the timestamp because that's how their implementation responds when they don't recognize the timestamp's signature. There is no consistency.



In this blog entry, I have provided links to all of the source pictures as well as over a half-dozen validators, including some that are on the conforming products list. Feel free to try all of these pictures with all of these validators. You will not get a consistent result. With any C2PA-signed file, you can cherry pick your validator to make an argument for it being legitimate or fake.

With each of these examples, the cryptography is valid. I have never questioned C2PA's used of cryptography. However, forging the signing device, signing altered media as if it came from a device, and providing inconsistent interpretations of the C2PA information are not about the cryptography. This is a problem with the attribution and provenance trail; it's the signer and content that are unreliable. (As I often say: putting strong crypto from an unverified source over unvetted data does not make the data more trustworthy.)

C2PA is inconsonant by design. With TLS and SEAL, it doesn't matter which validator you use: a missing, unknown, or revoked signer is a hard-reject. In contrast, C2PA treats security-critical controls (trust list selection, timestamp validation, revocation, etc.) as soft warnings or optional states. This changes the security model from fail-closed (secure) to fail-open or indeterminate.

C2PA's solution was originally created as a "project whose mission is to develop technical specifications that can establish content provenance and authenticity at scale to give publishers, creators, and consumers the ability to trace the origin of media." By providing no consistent results related to trustworthiness, they have failed at this mission. This isn't merely a case of growing pains from an up-and-coming standard. C2PA explicitly permits optional validation decisions that can cause compliant implementations to reach different conclusions about the same file. The resulting inconsistencies aren't implementation bugs; they are the foreseeable outcomes from a bad design.

Across all my posts about C2PA's flaws, there's one aspect that has been bothering me for years: you can upload the exact same picture to different C2PA validators and get conflicting results. It wasn't until I began flow-charting the validation process that I realized the scale of the problem.

In this blog entry, I'm going to compare the workflows used by TLS (required by HTTPS), Secure Evidence Attribution Label (SEAL), and C2PA. I'm specifically comparing TLS and SEAL to C2PA because (1) C2PA's proponents often compare C2PA's use of X.509 to TLS, and (2) C2PA's Chief Architect prompted me to come up with an alternative to C2PA, so I created SEAL.

TLS

Transport Layer Security (TLS) provides the framework for encrypting data over the internet. It uses a common container format called X.509, which holds the public keys and related meta information (issuer, subject, validity date range, etc.). Every web browser should handle the TLS information the same way, using the same logical flow.



TLS uses a very straightforward flowchart:

1. Is TLS present? If it isn't, then your connection is using plain old HTTP: unencrypted and untrusted. If it is present, then you're using HTTPS and can check the X.509 certificate information.


2. Is the TLS certificate expired? An expired certificate should not be used. At minimum, it will generate a browser warning because the certificate is untrusted.


3. Is the TLS certificate tied to the domain? Buried in the X.509 is a field that says "this certificate is associated with this domain name." For example, the certificate from my blog says that my certificate is associated with "hackerfactor.com" and "*.hackerfactor.com". If your browser sees my certificate associated with a different domain name, it will stop your access and inform you that the connection is insecure.
   
   


4. Is the certificate linked to the trusted list? Your computer (and browsers) have a list of known trusted certificates, and the X.509 certificate defines a trust chain. This chain should link back to the trusted list. If it doesn't, then the certificate is untrusted, even if it came from the correct domain name.


5. Is the certificate currently revoked? This doesn't just check the last certificate; it's designed to check every certificate in the chain. If any of them are revoked, then the certificate is explicitly invalid due to revocation. If it's not explicitly revoked, then it's valid, verified, authenticated to the domain, and chains to the trusted list. However, this has a soft-fail condition: if the revocation status cannot be determined, then it is treated as being "not revoked".
   
   This "Is it revoked?" check is actually a little more complicated. For example, the revocation may include a date. If the current time (for HTTPS) is before the revocation date, then the certificate is still valid. This may not make too much sense for real-time web requests because the current time should always be after the revocation date. However, this is required for checking digital signatures at a later time. If it was signed before the revocation date, then it's valid. If it's signed after, then it's revoked and invalid.

The precise order of these steps can vary. For example, you can check the domain name (Step 3) or trusted list (Step 4) before the expiration (Step 2) and it won't change the result. Regardless of the order, these rules are standardized.

There can be differences between implementations. Browsers mainly differ in trust stores (Step 4) and revocation policies (Step 5). Those differences are small, publicly documented, and seldom change:

• Browser differences: Mozilla, Apple, Microsoft, and Google each maintain their own trusted lists (aka root store or trust store), but they coordinate through the Common CA Database (CCADB). This way, trust stores overlap significantly. Operating systems often add a few roots of their own (such as Microsoft or Apple adding trusted roots for their own update services). Similarly, private enterprise and government networks may include custom internal CAs in the local trust stores. (The U.S. Department of Defense and federal networks are classic examples.)


• Revocation differences: Browsers can use different revocation methods, and these can change over time. For example, Chrome used to perform live revocation checking, but now uses downloaded lists (CRLSets). Firefox introduced its own downloaded-list mechanism, CRLite, in Firefox 137 (April 2025), and disabled OCSP for domain-validated certificates in Firefox 142 (August 2025).

Beyond these documented variations, validation remains consistent.

SEAL

While SEAL doesn't use X.509 certificates, it does use a similar flow chart. However, the flow is a little complicated because of the optional embedded public keys.

• Is SEAL present? If there is no SEAL record, then there is nothing to check.


• Is the public key in the SEAL record? This is an encoding option because post-quantum crypto keys can be too large for storing in DNS. Today's typical usage stores the public key in DNS. (If there is a public key then jump to 3b, otherwise continue to 3a.)

The typical use case today relies on DNS for storing the public key:

• Is the public key in DNS? Most of the time, you don't have the public key in the SEAL record, so you retrieve it from DNS. If DNS is unreachable or the record doesn't include the public key, then the data cannot be verified.


• Does it validate? You now have the public key from DNS. Does it validate the signature? If it doesn't, then the signature is invalid.

Following the alternative branch, when the public key is embedded in the SEAL record:

• Does it validate? Since you have the key, check if the signature validates. If it doesn't, then it's invalid. But if it does validate, then you haven't authenticated the signature yet.


• Is the public key's digest in the DNS? This check allows you to attribute the key to the signer. Without this, you have verification (the crypto worked) without authentication (you don't know who signed it).

Whether you check DNS and then validate (3a/4a) or validate and then check DNS (3b/4b), passing both tests still means checking for revocation:

• Is the key revoked? SEAL doesn't use a trust chain; there is only one revocation to check and it comes from the DNS record. As with TLS/X.509, there are actually a bunch of 'if'-conditions around date revocation and default revocation records, but the basic gist is "Is it revoked?" If it is revoked, then the signature is invalid due to revocation.
  
  And if it isn't revoked? Then it's valid, with a verified signature and authenticated to the domain that holds the public key.

Every SEAL validator should handle this workflow the same way, so they should all get the same results under the same conditions. You might have noticed that I included the caveat "under the same conditions". If one validator can access DNS and another validator cannot (e.g., it's offline), then you may get different results. But even with this difference, the user can immediately tell why there is a difference. (Seeing that they cannot reach DNS because they are offline probably won't be a surprise to the user. And as mentioned in the previous blog entry, SEAL trusts DNS.)

C2PA

Compared to the other validation flows, C2PA is a long and complicated mess. It has 10 steps, 6 with optional implementations, and a major flow decision based on an optional signed timestamp (see Step 5).

1. Are Content Credentials present? Simple and straightforward; you cannot validate it if it doesn't exist.


2. Is the certificate linked to the trusted list? The C2PA spec does not recommend any specific baseline root store. Instead, every instance (generator, signer, and validator) decides what root stores they want to include. There are currently many independent root stores, and most have no overlap:
   
   
   • C2PA's Official Trust List: https://github.com/c2pa-org/conformance-public/tree/main/trust-list. (We'll ignore that GitHub probably isn't the safest place to store their official trust list. Too much risk of a GitHub compromise permitting unauthorized edits to the list.) This list is only for conforming products. (I probably need to write a completely separate blog detailing the problems with their conformance program.)
   
   
   • C2PA Interim Trust List (ITL): https://github.com/contentauth/verify-site/tree/main/static/trust was officially frozen in January 2026, but has been updated a few times since then. (With the ITL, frozen doesn't really mean "no more changes". If you use the 'frozen' trust list from January 2026, then you can get different results compared to the 'frozen' list from March 2026.) The ITL is kept around for verifying signatures that were made before the official trust list was deployed.
   
   
   • International Press Telecommunications Council (IPTC): https://trust.iptc.org/end-entity-list.pem. The IPTC maintains its own list that has no overlap with other lists.
   
   
   • Sony: https://imagevalidation.authenticity.sony.net/trust/sony.pem is intended for Sony applications to validate Sony-signed documents. As far as I can tell, only Sony uses Sony's list.
   
   I'm sure these are not the only C2PA trust lists; these are just the ones I currently know about.
   
   The X.509 certificate contains details about the signer responsible for the cert. However, it does not specify which trust list should be used or where to get the trust list.
   
   Asking "Is the signing certificate linked to the trusted list?" sounds like a simple yes/no question. However, it isn't. This is because every organization can use a different list! A user trying to validate the media should know which trust lists are being used and when they were last updated. If the validator includes multiple trust lists, then you also need to know the validator's rules for combining them. Unfortunately, validators don't generally provide this information.
   
   While TLS does have a similar problem with trust list variations, the significant overlap between different platforms minimizes any differences. In contrast, different C2PA trust lists often have no overlap (e.g., the lists from IPTC, Sony, and C2PA are completely different), leading to very different results.
   
   According to the W3C minutes, C2PA's Chief Architect Leonard Rosenthol was asked why they were using a separate trust list. His reply: "We've been trying to use the same model, just has different trust anchors." No, this really is not the same model. TLS and the significant overlap between trust store entries on different platforms are about interoperability; C2PA's vastly different trust stores with no required commonality are about enabling isolated walled gardens.


3. Is the signing certificate revoked? X.509 supports two different revocation methods:
   
   
   • CRL: A Certificate Revocation List is a static list that you can download. It includes the cert serial number for every revoked certificate. In theory, the CRL can grow to be very large. In practice, they are typically tiny.
   
   
   • OCSP: The Online Certificate Status Protocol is newer than CRL, but the CA/Browser Forum has made OCSP optional and requires CRLs. Some CAs and browsers have moved away from OCSP entirely: Let's Encrypt and Google Trust Services have stopped issuing OCSP responses for most certificates, Firefox is disabling OCSP checks in favor of CRLite, and Chrome doesn't rely on live OCSP checks by default. In effect, OCSP is becoming obsolete.
   
   For CCADB-based lists, most of the certs have no defined revocation method. (On my Ubuntu system, 122 of the 146 certs had no defined revocation method.) This isn't a big problem for TLS since network connections are ephemeral. If you no longer trust a root, then the trust list managers will remove it from the list and your browser will stop trusting it after the next update.
   
   On the other hand, C2PA uses static signing certificates, not ephemeral network connections. This introduces a lot of problems. For example:
   
   
   • Revocation checking is optional and usually not implemented.
   
   
   • CRLs are explicitly not supported. C2PA only supports OCSP. (This is an ironic choice: C2PA is relatively new, yet it requires a deprecated technology. It's also ironic given that C2PA claims to care about privacy, while industry groups are rejecting OCSP due to privacy concerns.)
   
   
   • C2PA explicitly permits "OCSP Stapling", where the OCSP record is attached to the C2PA's manifest. But this is optional, typically not present, and has other problems (that really deserve a separate blog entry). OCSP Stapling is not a reliable solution.
   
   With C2PA, revocation checking is optional and different validators can return different results based on how they query for revocation. But it gets a little worse: C2PA supports an optional signed timestamp. This means that a revoked signing certificate could appear un-revoked based on the timestamp. (See Steps 5-9.)


4. Is the signing cert currently expired? If the cert is not revoked (including unchecked or unavailable), then it is valid and trusted. Otherwise, you need to check for a signed timestamp (Step 5).


5. Is there a signed timestamp? This is the point where C2PA's logic flow significantly deviates from TLS. If the signing certificate is expired or revoked, then a signed timestamp can still make it appear valid.


6. Is the timestamp cert in the trusted list? To reach this step, we have an expired or revoked signing cert, but a signed timestamp is present. Do we trust the signed timestamp? This is similar to the "inconsistent lists" problem seen in Step 2, except that the C2PA and ITL use separate trusted lists for timestamp certificates. This allows validators to potentially mix-and-match. For example, they might permit a signing certificate from the IPTC trust list but the timestamp certificate from the "C2PA TSA Trust List" (which is different from the "C2PA Trust List").


7. Is the timestamp certificate revoked before the timestamp date? As with Step 3, revocation checking is optional. Moreover, some validators seem to only check the last certificate in the chain for revocation, while others check the entire chain.


8. Is the signed timestamp within the timestamp certificate's validity period? Every cert has a "Not Before" and "Not After" range. This is a sanity check step to make sure the trusted timestamp authority (TSA) used a date during the TSA cert's validity period. (A malicious TSA can still backdate or postdate the signature, but it must be within the "Not Before" and "Not After" range.)


9. Is the signed timestamp within the signing cert's validity period and before any revocation? While Step 8 checked the signed time against the timestamp cert, this step checks the signed time against the signing cert. If the signed timestamp predates the signing cert's revocation date, then the cert is still valid. This permits the continued use of an expired or revoked signing cert (effectively un-expiring or un-revoking it). Unfortunately, I've seen some validators just check if the timestamp is valid, and not check if the revocation date predates the timestamp.


10. Was the signing cert revoked? This is the final failure condition and triggers when the signing cert is invalid. Was it invalid due to the optional revocation checking (invalid and revoked) or expiration (invalid and expired)?

As with the other workflows, the specific order of these steps can vary. For example, an implementation might check the certificate expiration (Step 4) before checking the trust list (Step 2), but that just makes the line diagram a little more complicated. Changing the step ordering shouldn't change the decision process or final outcome.

C2PA's validation flow includes six steps where validators can make their own choices (Steps 2, 3, 6, 7, 9, and 10). Since every validator can do this differently, every validator can generate different and conflicting responses to the exact same media.

• If a C2PA validator says you can trust the signature, there could always be another validator that says you cannot.


• If a validator says you cannot trust it, then you can probably shop around to find a validator that says it is trustworthy.

This is the main difference between TLS, SEAL, and C2PA. With TLS and SEAL, the validation process is consistent and reliable. With C2PA, it is inconsistent by design.

In this blog entry, I covered how the logic flows differ. So far, that's all theory. In the next blog entry, I'll use real-world examples to demonstrate how different C2PA validators generate different results for the exact same media.

Completed another Hack The Box machine: Hercules, an Insane difficulty Active Directory challenge.

This was one of the longer attack chains I have worked through, involving multiple stages across web exploitation, credential access, Active Directory enumeration, privilege escalation, AD CS, and Kerberos abuse.

The initial foothold started with LDAP username enumeration and the discovery of credentials stored in an account description. After gaining access to the Hercules Portal, a directory traversal vulnerability exposed the web.config file and its ASP.NET machineKey values. These values allowed a forged Forms Authentication cookie to impersonate web_admin.

From there, a malicious ODT upload triggered an outbound NTLM authentication attempt, allowing the NetNTLMv2 credentials for natalie.a to be captured and cracked. The recovered credentials opened the path to Shadow Credentials against bob.w and stephen.m, followed by OU permission abuse to gain control of the Auditor account.

The privilege escalation chain continued through the Forest Migration OU, where fernando.r was enabled and used to identify an ESC3 misconfiguration. An Enrollment Agent certificate was then obtained and abused to request a certificate for ashley.b, leading to further access within the domain.

The final stages involved controlling IIS_Administrator, taking control of the iis_webserver$ machine account, extracting the required Kerberos session key, and abusing S4U2self/S4U2proxy to impersonate Administrator. This ultimately provided access to the root flag under C:\Users\Admin\Desktop.

Hercules was a great exercise in chaining several seemingly separate weaknesses together rather than relying on a single vulnerability. Definitely a box that required careful enumeration and keeping track of the relationships between users, groups, OUs, certificates, and Kerberos tickets.

Documented as part of my continued HTB practice and learning in Active Directory and offensive security.

#HackTheBox #HTB #Hercules #CyberSecurity #ActiveDirectory #PenetrationTesting #RedTeam #OffensiveSecurity #BloodHound #Certipy #ADCS #ESC3 #Kerberos #ShadowCredentials #PrivilegeEscalation #InfoSec #CyberSecurityLearning …

Learn MoreHack The Box: Hercules Machine Walkthrough – Insane Diffucility

The post Hack The Box: Hercules Machine Walkthrough – Insane Diffucility appeared first on Threatninja.net.

In the late night and evenings (and between meetings), I've been working on projects related to SEAL (Secure Evidence Attribution Label) and C2PA.

C2PA is the Coalition for Content Provenance and Authenticity. Don't read too much into the name, because it does not provide any kind of content authenticity or reliable provenance. Readers of my blog have seen me repeatedly document design flaws, demonstrate how C2PA's approach is unreliable, and how it can be used to create signed forgeries that, under C2PA's solution, look identical to untampered media.

Back in 2023, I was posting a series that disclosed C2PA's vast array of critical problems. It culminated in a chat between representatives from C2PA and CAI (all Adobe employees) and myself with a coworker. C2PA's Chief Architect acknowledged the problems and asked if I knew of any alternatives. (This false dichotomy bothered me because lacking another alternative does not mean that C2PA works.) A few weeks later, SEAL was created. (It was initially called VIDA, but was renamed to SEAL a few months later.)

Today, SEAL has full specs, implementations in C and JavaScript, a free remote signing server (SignMyData) with web-based validator (that does not require uploading content off your computer), and more!

SEAL Updates

Behind the scenes, SEAL has had some big updates.

I'm happy to say that SEAL has survived a serious review by some folks at the University of Maryland, Baltimore County (UMBC). They have a Protocol Analysis Lab (PAL) and Cyber Defense Lab (CDL) that evaluated SEAL in depth. They didn't just review the specs and code, they used formal methods with CPSA (Cryptographic Protocol Shapes Analyzer) to model the solution. Their findings?

• Very positive: SEAL does what it claims. It provides a strong cryptographic signature over the file, identifies the signer, and prevents impersonation attacks. (These same goals have serious design and implementation weaknesses under C2PA. I can create authentic-looking forgeries with C2PA; with the fixes suggested by PAL/CDL, I cannot create authentic-looking forgeries with SEAL.)


• Exclusion range: They found two nasty exploits related to the exclusion range. Basically, the specs didn't explicitly say that the exclusion range for computing the signature must be minimal. A malicious user could exclude the SEAL record from the signature, permitting post-signing alterations.
  
  Fortunately, both of these bugs were easily addressed in the specs and in the code. (The C implementation, SEAL-C has the fix, while the JavaScript version, SEAL-JS is coming.) The fix is fully backwards compatible with previous signatures. (If you intentionally made a lax exclusion range, it will be flagged and either warned or rejected depending on whether it touches the SEAL record itself.)


• Security Documents: At the request of UMBC PAL/CDL, I've added a Security Considerations document. This describes many of the attacks, countermeasures, and mitigation options that they identified.


• Missed Revocation Condition: In the JavaScript implementation, PAL/CDL found a missed if-condition. The fix has been submitted and checked in.

The issues were the only SEAL-specific findings, and they have been addressed.

Along with the SEAL-specific problems, PAL/CDL found a few other issues that impact virtually every public/private key cryptographic solution. The issues? Revocation and DNS.

The Revocation Problem

When using public/private key cryptography (PKI), what do you do if the private key is compromised? That's the revocation problem. The folks at PAL/CDL found a nasty attack that impacts almost every PKI solution. It definitely impacts both SEAL and C2PA, even though we have very different PKI implementations. It also impacts DKIM (email), signed PDF documents, single-sign-on (SSO), and pretty much all other solutions that use a cryptographic signature.

The problem: when a key is compromised, you revoke it. You can even attach a date for when the revocation takes effect. An attacker with the stolen key can easily backdate new media to a time before the revocation date. (Ouch!)

C2PA currently has no solution to this problem. They simply rely on a trusted signing authority (TSA) and hope it will never be compromised. But that just kicks the problem down the road. If a TSA's private key is compromised, then it can indefinitely backdate material to a time before the revocation.

Even worse: C2PA requires an RFC3161-compliant timestamp server. According to RFC3161, every TSA certificate MUST support revocation. C2PA currently has 22 C2PA-approved TSA certificates, of which 16 do not have any kind of revocation enabled. (C2PA's own trusted list is not compliant with C2PA's specs.)

With SEAL, we have a clever workaround. If the media is signed using a revoked key, then check the key's date. If it was signed after the date, then it is clearly revoked. But if it's signed before the date? Then it can be 'suspect' (neither valid nor invalid). To confirm the validation, it must be compared against some kind of independent service to make sure it existed before the revocation date. (Huh?)

Basically, if the media is dated 2026-08-15 and the revocation date is 2026-08-30 (after it was signed), then see if you can find some other instance of the media before the revocation date. For example:

• Is it hosted on a news site, the Internet Archive, tagged by some kind of block-chain, etc.


• If it's legal evidence or a tracked file, was it received before the revocation date?

If it can be shown to have existed before the revocation date, then it's still valid.

But what if you can't find it anywhere else? Then the file is suspect. It could be valid, but you need to confirm it using some other means.

This same cross-validation approach works for other documents. However, as far as I can tell, only SEAL explicitly defines this pre-revocation validation approach.

The DNS Problem

The Domain Naming System (DNS) is what converts a hostname (like "hackerfactor.com") into a network address (e.g., 104.21.67.249). The entire Internet is based on DNS. Even if you don't think your PKI solution uses DNS, you're using DNS.

For SEAL, the DNS usage is explicit: the public key is stored in a DNS record. DNS is only required during validation. The DNS record attributes the public key (for verification) with the signer and includes any revocation information.

For C2PA, the DNS usage is implicit, optional (in a bad way), and needed for both signing and validating. How C2PA uses DNS:

• C2PA has different kinds of signatures. The minimum signature requires a signing cert. If you're part of C2PA's conformance program, then the signature is only good for 366 days (Assurance Level 1) or 90 days (Assurance Level 2). When the certificate expires, you can no longer validate the signature. You need DNS to access the conformance program listing, check if the signer is a conforming product, and retrieve the C2PA list of trusted certificates.


• To keep the signature valid for more than 366 days, C2PA requires the use of timestamp from a known Time Stamp Authority (TSA). This requires Internet access, which requires DNS. Keep in mind, using a TSA is optional according to the C2PA specs.


• The Google Pixel 10 tries to get around this network requirement by having a built-in TSA. That's good. However, their signing certificates all come from Google. The device pre-loads a handful of certs over the Internet (DNS!) and uses them for signing.


• C2PA explicitly makes revocation checking optional. (This is the point where every cryptographer wakes up and shouts "WTF!") C2PA explicitly forbids the use of a downloadable certificate revocation list (CRL). Instead, they suggest (not require) the use of the Online Certificate Status Protocol (OCSP). (Let's ignore the fact that all of industry is moving away from OCSP and requiring CRLs.) As noted in the C2PA specs (my bold for emphasis):
  

  14.5.2. Certificate Revocation
  
  X.509 certificates support revocation status queries. A claim generator should use the Online Certificate Status Protocol (OCSP, RFC 6960) and OCSP stapling (as originally conceptualized in RFC 6066, Section 8, but implemented as described in this clause) to implement revocation. The claim generator shall not use Certificate Revocation Lists (CRLs, RFC 5280).
  ...
  15.9. Validate the Credential Revocation Information
  
  For CA certificates, the validator should determine revocation status as indicated in the Authority Information Access (AIA) extension as described in RFC 5280, section 4.2.2.1. The validator should make use of relevant OCSP responses included in the C2PA Manifest if the AIA extension indicates that OCSP is available.

  In spec-speak, "should" is optional, while "shall not" is a requirement. With OCSP, the certificate says where to access the online validation service (via URL, which means using DNS to find the service). Then again, CRLs also require using a URL (DNS) to download the list.

Regardless of whether you are using SEAL, C2PA, or some other provenance solution, what can a malicious actor do if they can alter your DNS query or the DNS response?

• At best, they can block the reply and make a valid signature appear unverifiable.


• At worst, they can alter the reply and make a valid signature appear revoked or invalid.


• They can make a revoked signature appear valid or unverifiable.


• If they can send you fake media to evaluate, then they can combine their own fake signature with a hijacked DNS response to make the signed file appear valid.

C2PA only defines two OCSP states: revoked and valid. If it's not revoked, then it's valid. If the network request cannot be completed (or is never attempted because it's optional), then the certificate appears valid. This means that two different validators can reach conflicting conclusions about the same media, and both can be right! (One validator says the media is invalid due to revocation, and the other finds it valid because it never checked.)

In contrast, SEAL's revocation checking is mandatory and it distinguishes between valid, invalid, and unverifiable. If there is a network or DNS problem, then it becomes unverifiable. Because this check is required, every up-to-date SEAL validator will reach the same conclusion about the same media. There is no validator inconsistency.

Hardening DNS

PAL/CDL did have a few suggestions to secure DNS, but I don't think they are practical today:

• DNSSEC: DNS is normally unprotected. A malicious man-in-the-middle could easily change the query or the response. DNSSEC signs the DNS request and reply, ensuring that the results cannot be tampered with.
  
  However, at most domain registrars, DNSSEC is not enabled by default. User devices (Linux, Windows, MacOS, iOS, and Android) do not enable DNSSEC by default, and enabling it can be complicated (depending on the platform). This low adoption rate is why we cannot require DNSSEC right now.
  
  Moreover, DNSSEC breaks some technologies, which impacts adoption. For example:
  
  
  • Captive portals, where you must agree or login before connecting to the internet, work by hijacking the first DNS request. If you use DNSSEC, then the captive portal approach won't work and you'll see a browser error about a DNS problem.
  
  
  • DNSSEC isn't supported by most embedded devices because it is too resource-intensive for many small IoT systems.
  
  
  • Many companies run an internal DNS system that differs from the public DNS. (E.g., 'hackerfactor.com' from within my office network resolves to the direct server IP address, but the rest of the world uses a global DNS that directs to CloudFlare's address for DDoS-protection.) Enabling DNSSEC breaks this internal/external configuration. (After I enabled DNSSEC for hackerfactor.com, and before I could fix the problem, there was an hour where I couldn't access my own site from within my office!)
  
  Enabling DNSSEC can break many services, even if the DNS client allows downgrading from DNSSEC to DNS.


• DoH and DoT: DNS is designed to propagate requests between DNS servers, until it finds a response. The propagation is unencrypted and vulnerable to alteration. DNS-over-HTTPS and DNS-over-TLS are used to encrypt the first hop of the query, from you to your direct DNS resolver.
  
  In theory, if the entire end-to-end path -- from client making the request to the authoritative response -- is encrypted, then this is a great solution. The problem is, you only know if your first hop is encrypted, not if the rest of the relayed path is encrypted. Also, these protocols have a chicken-and-egg problem: you need DoT/DoH to do the DNS lookup, but you need DNS to get and validate the TLS certificate before you can use it. Between newness, lack of "out of the box" configurations, and the chicken-and-egg problem, both of these protocols have even less support than DNSSEC.

While an ideal solution would require both DNSSEC and DoT (or DoH), the practical response is that these are recommended, but cannot be required. (SEAL recommends using them when possible, while C2PA's documentation doesn't mention this problem at all.)

Fortunately, DNS is a pretty good solution as-is. (Not perfect, but good enough.) For example:

• The top level authoritative servers are hardened from decades of attacks.


• The hundreds of thousands of intermediate relays are widely distributed, making it virtually impossible for an attacker to hijack or poison all of them.


• The attacker doesn't know who, when, or from where the next DNS query will be generated. This makes it extremely difficult for them to attack a specific DNS lookup request.


• DNS caches results. Even if the attacker manages to poison the cache on one DNS server, they must constantly refresh the attack or bad data will expire. (I'm not saying that DNS spoofing isn't possible. I'm saying it's not trivial to do, must be constantly re-applied, and will likely be noticed.)

While the threat doesn't go away, it is certainly mitigated. This is not secure by design; this is secure by infeasibility: an attacker cannot realistically poison DNS for the entire world at the same time, nor can they do it indefinitely.

An Honest Opinion

While C2PA defines an entire ecosystem (with every part vulnerable to fraud), SEAL focuses on one part and implements it successfully. The exclusion-range bugs that UMBC's PAL/CDL found were SEAL-specific, narrow, and have been fixed! That's the kind of finding you want from a formal review. Revocation and DNS are a different story: they're not bugs in SEAL or C2PA, they're weaknesses in every known solution.

The honest takeaway is that neither SEAL nor C2PA "solves" revocation or DNS trust; nothing solves it completely. What differs is how each system fails. C2PA's answer to a compromised TSA is to hope it doesn't happen and make revocation checking optional when it does. SEAL's answer is to treat a signature that pre-dates a revocation as suspect and to seek out independent corroboration, rather than defaulting to valid or invalid. That's not a magical fix, but it's an honest one: it tells you when you don't actually know, instead of quietly defaulting to "trust it."

The DNS problem is even less solvable in the near term. DNSSEC and DoH/DoT are the "right" answers on paper, but neither is a realistic requirement today. Both SEAL and C2PA are stuck relying on DNS's de facto resilience (scale, caching, and distributed relay network), rather than any cryptographic guarantees. But only SEAL is explicit about the difference, which is essential for anyone using this kind of provenance data as legal or journalistic evidence.

None of this is a reason to abandon content provenance. It's a reason to be specific about what a "verified" label actually promises. SEAL's approach, to identify facts and not fake certainty, is a smaller claim than C2PA's, but it is a claim that SEAL can formally provide.

The news has been full of incredible reports recently. Like this one:

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:

• 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. 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. If we upload this glitter-milk picture to Adobe's Inspect service (a conforming product), it reports 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 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.)

Everything says that this is a legitimate photo from a Google Pixel camera.

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 for responsible disclosure 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) 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". Their bullet points (with their bold emphasis):

• 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-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.


• 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.

As Carl Sagan said, "Extraordinary claims require extraordinary evidence." So we began to take a closer look.

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:

1. Using ChatGPT, I generated the source picture of a unicorn cow being milked.


2. ChatGPT's picture was a PNG with an embedded C2PA manifest. I stripped out the manifest and re-encoded the picture as a JPEG.


3. 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".


4. I sent my forgery to retr0id.


5. 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 on GitHub and a technical write-up on his blog.)

The example demonstrates how someone with a Google Pixel device could sign any picture (real, fake, AI generated, etc.) as if it came from the Google Pixel's camera. Moreover, the forgery (excluding my intentional artifacts) is indistinguishable from a real photo. C2PA's metadata provides no reliable assurance of provenance or authenticity.

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'. 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 and Exploit #2.) 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 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 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:

1. 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 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 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.


2. 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.


3. 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 (VRP). He did.


4. 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.


5. Fast forward two months. Retr0id received an email from Google's VRP. (I am including it here with his permission.)
   

   jo...@google.com #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.

   They closed it out as a "Won't Fix (Infeasible)". Google defines "Won't Fix (Infeasible)" 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 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 Platform Firmware Resiliency Guidelines, NIST SP 800-57 Recommendation for Key Management, and NIST SP 800-53 Rev. 5 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".

It took a while, but retr0id did receive payment for reporting this bug to Google. VRP bounties are only for security issues. By paying the bounty, Google implicitly confirms that this bug is a security problem, even though it was classified as NSBC and kept out of the security bulletin. The NSBC classification also means no CVE was assigned, which keeps the issue out of regulatory tracking, enterprise compliance audits, and the National Vulnerability Database (NVD).

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:

1. Validators Don't Check Revocation
   The current C2PA specification does not require 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.


2. 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.
   
   
   • 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.

This signing approach, with unique signatures per picture, introduces serious problems:

• 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 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.

Since the core exploit impacts Android's StrongBox and TEE architecture, revoking individual certificates does not resolve this problem. Revoking a certificate, only to have an attacker compromise the replacement certificate 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 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 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?

It's hard enough to debunk one false picture. However, with a little effort, a malicious actor could add in fake camera metadata and have it authoritatively signed by a trusted device. That significantly increases the effort to debunk a picture since it has the backing of Google's cryptographic signature as an unbreakable "official truth". (Remember kids: Strong cryptography over untrusted data does not make the data more trustworthy.)

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 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, forcing Nikon to indefinitely suspend the service and revoke every certificate 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 from 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.

In effect, Google's C2PA-enabled devices provide no reliable protections or 'truth' about the media -- and Google knows it.

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 called "GreenCheckmark" (screenshot) 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)").

GreenCheckmark isn't the point of failure here; failures are inherited from Google and C2PA.



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 (a conforming validator) and CAI Verify, this is legitimate "captured media" from a camera, signed by GreenCheckmark, and it is a Level 2 conformant application (screenshot). Similarly, YouTube's description reports that this video clip from the CGI movie "Big Buck Bunny" is signed by Evergreen Labs and "Captured with a camera" (screenshot).

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 app; see forgeries at Adobe Inspect and CAI Verify). 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.

I have a secret way to tell what's on people's minds: they all write to me about a topic. This time, there's a news article about the EU AI Act. The big requirement is in Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems. This recently became enforceable and requires marking AI-generated content:

2. Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.

This is a problem for companies like OpenAI (ChatGPT), Anthropic (Claude), Google (Gemini), Microsoft, and Adobe. Each provides AI-generation services to people in the EU.

Article 50 does not mandate the use of watermarking. A company could use metadata, logging, fingerprints, or some other technique. However, watermarking is the approach that they all seem to be employing.

I previously documented how image-based watermarking is grossly inadequate. Through empirical testing:

• Google's Gemini has a 1 in 20 error rate, where it fails to detect its own watermarks. Moreover, the detection depends on how you ask the question. Uploading the same image twice with different prompts could generate different results.


• Adobe's TrustMark has a 10%-20% false-positive rate.


• Meta's Stable Signature has a collision rate of 1 in 4.

C2PA tries to resolve this by providing an authoritative claim from a known signer. However, I have repeatedly demonstrated ways to have false signatures applied to both real and fake pictures.

None of these image-based solutions are reliable. In some cases, you're better off flipping a coin. (Or for D&D players, rolling a die.) However, text-based content is special because there is no hidden metadata; you cannot store binary signatures between letters without being noticed. For this reason, many companies are focusing on AI-based text watermarking.

Use Your Words

The new panic? Anthropic and OpenAI will start marking text with an invisible watermark. A lot of people have asked me how this works.

Let's back up a moment. Watermarking is just another form of steganography. Over 30 years ago, there was a steganographic text system called 'texto'. This encoder works like Mad Libs. It has a list of sentences:

The _THING _ADVERB _VERBs to the _ADJECTIVE _PLACE.
I _VERB _ADJECTIVE _THINGs near the _ADJECTIVE _ADJECTIVE _PLACE.
Sometimes, _THINGs _VERB behind _ADJECTIVE _PLACEs, unless they're _ADJECTIVE.
Never _VERB _ADVERB while you're _VERBing through a _ADJECTIVE _THING.
We _ADVERB _VERB around _ADJECTIVE _ADJECTIVE _PLACEs.
While _THINGs _ADVERB _VERB, the _THINGs often _VERB on the _ADJECTIVE _THINGs.
Other _ADJECTIVE _ADJECTIVE _THINGs will _VERB _ADVERB with _THINGs.
Going below a _PLACE with a _THING is often _ADJECTIVE.
...

It also has a list of words. There are 256 'THING' words, 256 ADVERBs, 256 VERBs, 256 PLACEs, etc. It reads the file to encode, chooses a sentence pattern, and replaces the words accordingly. For example, if the first byte is 7, then it will choose the 7th THING word. The results look like gibberish, but it contains a hidden message:

The watch absolutely hugs to the messy moon. I lean cold caps near the sharp squishy planet. Sometimes, brushs love behind soft squares, unless they're lazy. Never move superbly while you're sitting through a yellow arrow. We surely keep around grey white deserts. While yogis deeply smell, the boats often keep on the unique dogs. Other squishy wet tyrants will count wistfully with shirts. ...

To decode it, texto identifies the words and maps them back to values.

Modern Words

The texto approach hides a binary message inside a text block. The AI approach to watermarking uses a similar concept, but the watermarking doesn't need to store a large binary message; it only needs to store a few bytes of data, a small semaphore, or a statistical bias. It can use the rest of the text to repeat the encoding over and over, making it easier to detect.

While texto was limited to 256 nouns, verbs, etc., AI can use a lot more than 256 words and a few fixed sentence patterns. In fact, they can build it into the entire decision tree!

The Kirchenbauer/KGW approach injects a detectable bias into the word selections. This has become the typical approach used today:

1. AI uses random numbers when making choices. This is why repeating the exact same prompt will generate completely different responses. However, for watermark encoding, it uses a secret key as a weighted random number seed.


2. The AI (LLM) approach generates text autoregressively, token by token (or word fragment by word fragment). At each step, it calculates a probability distribution over the entire vocabulary based on the preceding token.
   
   
   • Without watermarking: The AI model calculates a probability distribution over the vocabulary for the next word/token. It then chooses the next word/token based on some kind of sampling algorithm and a list of the most likely candidates.
   
   
   • With watermarking: The KGW solution uses the secret key to assign weights to the possible options. These are often called 'green' words and 'red' words. This biases the sampling algorithm so that it will prefer a green word over a red word. This doesn't exclude red words from being used; it just makes them less likely.

When decoding, the detector uses the secret information used by the generator to reconstruct the selection bias. It uses the preceding token(s) to re-generate the green list for the next token, then counts how many tokens fall into their respective green lists.

The detector usually has some kind of threshold function. For example, "80% green tokens" may be the minimum threshold for identifying the watermark. This is why more text is important to rule out false-positives; it is very possible for a few words in a sentence to have lots of green words, but very unlikely for an entire essay to be mostly green. In general, text from a human will fall far below the threshold for detection, while AI-generated watermarked text will have a detectable bias far above the threshold.

The Catch

Watermarked text has been demonstrated as feasible (at least more accurate than their image watermarking). However, it's far from perfect. The AI vendors have not disclosed their specific watermarking algorithms. While some variation of the Kirchenbauer/KGW approach is likely, it isn't the only option. But regardless of the option, they all have the same classes of weaknesses because they are all based on natural languages. This limits the set of words and available sentence structure choices. The fundamental problems include:

• Word Choice: The word selection can often be sub-optimal. If the AI starts sounding odd, then it's probably due to the weighted words.


• Repetition: The system cannot spot the watermark from one sentence. It needs a paragraph or more. This also means that it is more likely to be redundant, using the same sets of green words multiple times so that it can repeatedly spot the watermark and lower the likelihood of a false-positive.


• Coincidental: In a typical implementation, roughly half of the possible tokens are on the green list. However, it is very possible for a human to coincidentally write a few sentences or paragraphs that are more than 80% from the unknown green list.
  
  The root problem is that the detector must be probabilistic rather than absolute. A human-written passage can coincidentally produce a watermark-like statistical pattern. The detector must use a threshold that balances a trade-off between the false-positive rate and detection sensitivity.


• Translations: Not everyone is a native English speaker. (Or Spanish, Chinese, or whatever language you are writing in.) It is very common to see people use AI to translate text from their native language into the target language. However, the translations may end up watermarked. This can become a problem. For example, nearly every major academic publisher and scientific organization (including IEEE, ACM, Elsevier, Nature, and Springer) treats undisclosed AI-generated text as scientific misconduct. Many top-tier sci-fi and literary markets, like Clarkesworld and Asimov's Science Fiction, explicitly forbid AI-generated text. Wired and the Associated Press have similar blanket bans. If they use watermarking detection, then they may erroneously exclude participation from non-native English speakers.


• Training/Trained: AI learned how to write from humans, but humans learn how to write like those around them. With the younger generation (well, people younger than me) spending so much time interacting with AI systems, they will inevitably learn some of those odd wording styles. This will make real human text read more like AI, and could even appear weighted toward more green wordings.


• Versions: Today's AI uses today's watermarking approach. A newer AI system will need to use a revised approach. However, this can cause a problem when an old watermark is no longer detectable by a newer system. Moreover, many AI companies push out code changes without announcements. Text that tested positive for having a watermark yesterday may appear human-written tomorrow.
  
  In order to maintain backwards compatibility, the detector would need to know which model generated the text, which watermarking algorithm was used, which key/version, etc. This makes long-term detection much more complicated and unsustainable if there are rapid revisions.


• Paraphrasing and Removal Attacks: The original KGW algorithm was able to survive some paraphrasing attacks. (Is it called paraphrasing or plagiarism when you rewrite AI-generated text?) More advanced rewriting can remove the watermark. For example, passing the watermarked text through a lightweight local model, running it through a translator, or manually swapping a few synonyms may be enough to disrupt the green-token sequence and appear to be human-generated. As Google noted with their own SynthID-text system:
  

  [SynthID for text] performs well even under some transformations, such as cropping pieces of text, modifying a few words and mild paraphrasing. However, its confidence scores can be greatly reduced when an AI-generated text is thoroughly rewritten or translated to another language.



• The Editor Problem: Most professional writing organizations use human copyeditors to review the text, fix grammar, etc. Today, smaller organizations often rely on AI systems to act as proofreaders. The problem is that large text edits by AI systems can introduce watermarking into otherwise human-created text. (Full disclosure: Gemini and ChatGPT proofread this blog before my human editor received it. They each caught spelling errors and a few details that my human editor would have likely missed. However, there are no large AI-text edits in this blog.)


• Spoofing Attacks: Adversaries can reverse-engineer green lists or use watermarked text outputs to create false positives. This could be used to falsely accuse or frame human authors.


• Interoperability: Article 50 explicitly says that solutions "shall ensure their technical solutions are effective, interoperable, robust and reliable". However, every vendor is keeping their watermarking solutions private. That ensures that they are not interoperable. On the flip side, if they made the details public then it would assist competing detectors, simplify removal, and enable forgeries. (It's a no-win situation for the watermarking companies.)

While text-based watermarking is an interesting academic exercise, I question whether it is ready for widespread public dissemination.

The Compliance Paradox

The EU AI Act's Article 50 effectively writes a technological fantasy into law. It requires some way to mark, tag, or label synthetic text "in a machine-readable format and detectable as artificially generated or manipulated". These regulators have created a legal requirement for technology that simply does not exist in a reliable form today.

Ironically, the lawmakers added a caveat that solutions only need to be as "robust and reliable as far as this is technically feasible". This creates a bizarre paradox: companies are pressured to deploy flawed, easily bypassed schemes just to demonstrate legal compliance. We are left with regulatory compliance theater, where algorithms pretend to detect what cannot be reliably detected, and users are handed a false sense of security.

Credential stuffing tests stolen password lists against your login form until one matches. Here is how to spot the traffic pattern and layer defences that actually hold.

Credential Stuffing: A Defender’s Guide to Detecting Automated Login Attacks on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.

A brute force attack automates password guessing until one works. Here's why it still succeeds, real incidents it's caused, and a practical checklist to stop it.

What Is a Brute Force Attack? A Practical Defender’s Guide on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.

I'm wrapping up my investigation into invisible watermark algorithms and I am extremely disappointed. Not only do none of the modern AI-based algorithms work as they claim, it turns out that they are all making the same fundamental mistake.

I previously evaluated Google's SynthID and Adobe's TrustMark algorithms. Both of them claim to have incredibly accurate results.

• According to Google's peer-reviewed and published paper, they claim to have a true positive rate (TPR) above 99.97% -- meaning that they will miss their own watermarks no more than 3 in 10,000 times. However, my own empirical testing found that is it much closer to 1 in 20. Moreover, SynthID is proprietary and only accessible through Google's "Gemini" AI system. Gemini has been observed hallucinating results and providing contradictory conclusions depending on how the question is phrased.


• According to Adobe's Content Authenticity Initiative, their TrustMark "can exceed 96% bit accuracy at around 42-45dB PSNR quality under severe noise degradations". However, that statistic focuses on resilience and not accuracy. In my empirical tests, I found that TrustMark has a 10%-20% false positive rate, effectively making it useless. (If you see a TrustMark signature, then it is very likely random noise and not an actual signature.)

This time, I evaluated Meta's "Stable Signature" algorithm. (Their paper and code are in GitHub.) This system encodes a 48-bit sequence into the picture's visual content. The idea is that you can encode a unique 48-bit sequence as your watermark. If your decoder finds the same 48-bit sequence, then it can identify your own watermark.

WARNING: This blog entry leans heavily into math and statistics to prove that Stable Signature, TrustMark, and SynthID are nowhere near as reliable as their developers claim.

The Basic Algorithm

Traditional (non-AI) invisible watermarks typically hide in subtle locations, such as the least significant bits, changes in brightness (e.g., Digimarc) or the frequency spectrum (DCT or FFT). There is always the risk that image encoding could corrupt the hidden data, so these algorithms typically rely on repetition over the image to help identify the true signal. In addition, they may include error correction code (extra bits in the data) to fix any minor data errors.

However, there is a problem with the traditional approaches: injecting hidden data in the image could create visible distortions. The modern approach uses an AI system to better hide the data with less added distortion.

As with SynthID and TrustMark, Stable Signature encodes binary data and uses an AI-model to decide where to hide it in the image. The AI is tuned to minimize visible distortions when embedding the data. Later, an AI-based decoder looks at the image and identifies the likely location where bits are stored, then it extracts the data.

There is always the case that the data may be mixed with noise. Different AI-based watermarking systems rely on different techniques for reducing the noise. For example:

• Google's SynthID only stores a few bits of data (effectively a flag or version number). This allows them to use a lot of data as repetition and to increase the accuracy rate.


• Adobe's TrustMark uses the Bose-Chaudhuri-Hocquenghem (BCH) algorithm. This acts as a combination of checksum and error correcting code that should reduce the number of errors.

Meta's Stable Signature uses a simple Hamming distance.



The Hamming distance measures the number of bits that need to be swapped in order to correct the code. In effect, it defines a set of stable states (e.g., 10110 and 11000) and places a ring around each state that represents the single bit changes. If you change enough bits, then you will reach a different stable state.

According to Meta's Stable Signature research paper, the 48-bits should be uniformly distributed and cites a "false positive rate below 10^-6", or 1 in one million. This means you can choose a 48-bit sequence to use as your signature. Every picture will generate a 48-bit sequence, and the sequence can vary a little based on noise in the picture. However, if you find a code that is within a short Hamming distance of your code (e.g., within 6 bits difference), then you can determine that it is the same code with a high reliability.

At least, that's the theory.

Empirical Testing

I went into this experiment assuming that everything works like they claim. I want to be able to reliably identify invisible watermarks associated with Meta. What I don't know is what sequence they use, or whether they use multiple codes depending on whether it comes from Meta's AI system, Facebook, Instagram, WhatsApp, etc.

Fortunately, this is something I can test! I grabbed an uncurated sample of pictures from FotoForensics: the first 10,000 unique images uploaded last month (May 2026). If the bit sequences are uniformly distributed with a "1 in 1 million" collision rate, then I should see a huge number of unique bit sequences and a few small clusters around pictures from Meta (Meta AI, Facebook, Instagram, etc.). Those clusters will represent the invisible watermarks used by Meta.

The results from my empirical test were definitely not what I expected. I found:

• No clusters associated with any Meta images. This suggests that Meta does not use their own Stable Signature watermarking software found on GitHub.


• With a random distribution, there should be no clusters. However, I had 25 different pictures that had the exact same bit sequence: 110110100111111011101001111000100111011000011101. With a 1 in a million collision rate, this should not happen! These pictures came from very different sources. Here's four of the 25 pictures (ranging from planets to light bulbs to text with a transparent (black) background):
  
  
  
  All of these pictures have dark/black backgrounds and something bright in the middle. This suggests that Stable Signature operates more like a perceptual hash than an invisible watermark.


• Stable Signature uses a Hamming distance to identify a cluster. If I assume the 25 pictures are the center (centroid) of the cluster and use a 6-bit Hamming distance, then there are 356 pictures that are similar. And if I assume that the 25 pictures are not the center but part of a cluster, then a Hamming distance of 6 has a cluster of 450 pictures centered 3 bits away, at 110110000111111011101011111000100111001000011101. This cluster represents 4.5% of the uncurated image data set! Here are a few samples from this larger cluster:
  
  
  
  (I'm explicitly not sharing pictures with personal information, like invoices, recognizable people, and GPS information.)

It's not just one random cluster that is massively large (450 pictures out of 10,000). There's a cluster of 184 pictures at 110101001011001011001011111000100111001000011101, 58 pictures at 110100000011111010001001111000100111011000011101, etc. I found over 60 clusters with more than 10 pictures each at a Hamming distance of 6. That should not happen with a "1 in 1 million" collision rate.

Independent Analysis

I went back to Meta's research paper to see if I could find the discrepancy. And there it was, in section 3.1: They tested their system against the hypothesis that the 48-bits are each independent and uniformly distributed. The problem is, they use one neural network to generate the bits. That explicitly means that the bits are dependent, not independent.

Their paper assumes a binomial distribution. That is, given an arbitrary image, the 48-bits represent a random coin flip. The math becomes:
P(X ≤ T)=∑Tk=0(48k)(0.5)k(0.5)48−k

This computes the probability of 48 random bits being within a Hamming distance (T). The probabilities table becomes:

Hamming Distance Threshold (T)	Bit Error Rate (BER)	Probability of a Random Image Matching by Chance
14 bits or fewer	≤ 29.17%	1 in 362.63
13 bits or fewer	≤ 27.08%	1 in 957.81
12 bits or fewer	≤ 25.00%	1 in 2,788.35
11 bits or fewer	≤ 22.92%	1 in 8,999.08
10 bits or fewer	≤ 20.83%	1 in 32,416.80
9 bits or fewer	≤ 18.75%	1 in 131,390.28
8 bits or fewer	≤ 16.67%	1 in 605,094.89
7 bits or fewer	≤ 14.58%	1 in 3.20 Million
6 bits or fewer	≤ 12.50%	1 in 19.83 Million
5 bits or fewer	≤ 10.42%	1 in 146.19 Million
4 bits or fewer	≤ 8.33%	1 in 1.32 Billion
3 bits or fewer	≤ 6.25%	1 in 15.24 Billion
2 bits or fewer	≤ 4.17%	1 in 239.15 Billion
1 bit or fewer	≤ 2.08%	1 in 5.74 Trillion
0 bits (perfect match)	= 0.00%	1 in 281.47 Trillion

Meta's paper says that they use a Hamming distance of 7 bits (requiring 41 of 48 bits), which matches their claim of a "false positive rate below 10⁻⁶". However, I'm seeing problems at a Hamming distance of 6 (should be 1 in 20 million) and even collisions at 0 (1 in 281 trillion)!

The Core Problem

There is clearly a discrepancy between the theoretical probabilities and the empirical testing. When I looked back over Meta's research paper, I saw the problem:

According to Meta's paper, each of the 48-bits are independent. In a perfectly independent 48-bit hypercube, un-watermarked images should scatter uniformly across all 2⁴⁸ possible values. However, neural networks map a non-linear manifold (a multi-dimensional wavy surface) through this hypercube. This mathematical landscape is warped with its own peaks, ravines, and valleys. It has attractors that form clusters, and repulsers that form voids where stable values can never exist; this is a feature of a neural network. And most importantly, the output bits are explicitly not independent.



The left diagram illustrates an expected uniform distribution if all of the bits were independent. The right diagram are the types of theoretical clusters that form when the bits are dependent. There should be clusters around attractors and voids (areas with no dots) from the repelling regions.

Moving from theoretical to empirical, I graphed the data. The 48 bits can be represented as bytes. I took the first 24 bits and converted them into 8-bit red, green, and blue pixel colors. If the data is truly random, then the colored dots should be distributed across the RGB cube. However, if the bits are dependent, then there should be very clear clusters, structures, and voids. Here's the graph:



Yes, there are very clear structures that look like planes and lines. Within the planes are clusters, and outside the planes are very large voids -- areas where there are no dots at all. The data generated by Meta's Stable Signature implementation fails this basic test for independence.

The biggest cluster that I found represents a Zero Signal Bias (ZSB). When their neural network doesn't find a watermark, it moves the 48 bits toward a strong attractor, like a massive gravitational well. At 6 bits error, it should have a collision of around 1 in 20 Million. But in reality, my 10,000 pictures had a cluster of 450 images within 6 bits due to the ZSB. That's an error rate of around 1 in 22 with the ZSB alone. If we add in all of the other clusters that contain at least 10 pictures, then 2327 pictures are in various clusters; we're looking at an error rate around 1 in 4 -- and that's at a Hamming distance of 6, which is more conservative than their paper's Hamming distance of 7. (In AI terms, this is a representation collapse or structural bias that is typical for deep neural networks.)

(As an aside: Given their "1 in 1 million" claim, I could look for any clusters of 2 or more pictures. At clusters of 2 or larger, 5,237 of the 10,000 test images were in clusters, or 52%. If you show their algorithm 10,000 pictures, then there is a better-than 50% chance of a false positive match.)

Less Than Random

It's one thing for me to claim that there are visible clusters and to show pictures of clusters, but another to prove it mathematically. (Time to dust off my college textbooks from "Introduction to Statistics"...)

I fed Meta's code the first 10,000 images from May 2026. A few of the images were in unsupported formats (HEIC, WebP, and a few corrupted JPEG files), resulting in 9,847 viable pictures. I evaluated this data with elements from the NIST Statistical Test Suite (SP 800-22) for randomness, including a monobit test and Chi-Squared (χ²) test for independence.

The monobit test determines if the baseline frequency of adjacent bits seems independent.

• Total Bits Processed: 9,847 pictures × 48 bits per signature = 472,656 bits
• Observed Count of Ones ('1'): 266,419
• Observed Count of Zeros ('0'): 206,237
• Expected Count (E): 236,328 for each.

Running a simple standard Chi-Square Goodness-of-Fit test for this bit balance:
χ2=(266419 − 236328)2236328+(206237 − 236328)2236328= 3831.41 + 3831.41 = 7662.81

• In mathemat-ese: with 1 degree of freedom, a χ² statistic of 7,662.81 yields a p-value infinitely close to 0.0 (p ⋘ 10^-100). (As an aside, most Chi-square tables usually evaluate the 1 degree of freedom up to around χ²=10. This χ² value is so astronomically high that the probability p effectively becomes zero.)


• In English: That's definitely not random or independent.

The watermark extraction is strongly biased toward producing 1s over 0s across global arbitrary images (roughly 56% ones to 44% zeros). This immediately violates the uniform distribution assumption.

The second test is the Chi-Square (χ²) Test for Serial Independence. If the bits were independent, the transition probability between adjacent bits would just be the product of their individual probabilities. This table shows the occurrence rate of the transition pairs across all of the observed 10,000 (well, 9,847) pictures:

Transition Pair	Observed Count (O)	Expected Count under Independence (E)
0 to 0	106,750	90,051
0 to 1	95,296	116,186
1 to 0	95,302	116,186
1 to 1	165,461	149,976

χ2=∑(O − E)2Eχ2=16699290051+(−20890)2116186+(−20884)2116186+154852149976=3096.7 + 3756.2 + 3754.0 + 1599.0=12,205.9

• In mathemat-ese: With 1 degree of freedom for the transition contingency table (accounting for fixed margins), a χ² value of 12,205.9 gives a p-value of 0.0.


• In English: Ain't no way this is random or independent.

And as if this wasn't conclusive enough, there are other tests we could apply:

• Static Tail Patterns: Looking closely at the end of the 48-bit sequences, a massive cluster of strings end explicitly in ...111101 or ...00111101. Additionally, bit position 46 is nearly always "1" (228 zeros vs 9619 ones, or 97.7% of the time it is "1"), position 47 is "0" (8958 of 9847 images, or 90.97%), and position 48 is "1" (found with 9696 images, or 98.5%) across thousands of uncurated, real-world images.


• Structural Clustering: Certain bit columns share an extraordinarily high Mutual Information score (I(X;Y)). For example, knowing the output of bit position 12 gives you better than an 80% accuracy in predicting bit position 28.

The assumption of a "uniform distribution over arbitrary pictures" relies on the idealistic premise that random natural image features project uniformly across the decision boundaries of a network. However, because the extraction network maps inputs to a constrained, highly continuous hyper-dimensional manifold, the network's latent layers natively enforce structural smoothness.

For the TL;DR crowd:
Meta's researchers made a fundamental mistake when computing their accuracy rates. It's not a "1 in 1 million" chance of a false match, it's closer to 1 in 4 -- because the 48 bit values per signature are not independent.

As I re-read Meta's research paper, I realized that the statistical error wasn't an oversight; Meta's researchers explicitly acknowledged the problem. In their paper (Section 4.1), they wrote:

Second, we observed that W’s output bits for vanilla images are correlated and highly biased, which violates the assumptions of Sec. 3.1 [the section about independent statistical test methods].

In other words, they recognized that the extracted bits are not independent. Despite this, their published false-positive analysis still relies on the assumption that the bits are independent.

Widespread Problems

Knowing that Meta's accuracy rate is grossly inflated due to assuming bit-wise independence when there is none, I looked back over Google's and Adobe's papers for their own watermarks. Did Google's and Adobe's researchers make this same mistake?

• Google's SynthID research paper talks in terms of True Positive Rates (TPR). They do make this same "bit-wise independent" mistake, but it's obfuscated in the paper. You can see the error in their Equation 3 (PDF page 8), where they assume there is a uniform (independent) distribution. Their paper hyperfocuses on the true positive rate and never addresses the false positive distribution. (Either they didn't know to look, or they knew and decided to not report it because it would expose a serious weakness in their solution.)


• Adobe's TrustMark research paper also makes assumptions of independence. You can see this in their PDF with the binary cross-entropy loss in Section 3.1.4. This mathematically treats each bit position as an independent Bernoulli trial. (By definition, a Bernoulli process strictly requires independence.) In their experiments (Section 4.1), they wrote "At test time, every image is associated with a random watermark", but they never tested if the random watermarks were similar to each other.

This introduction-to-statistics mistake is found in all three of these invisible watermarking technologies. The detections produced by these systems are so unreliable that an analyst cannot determine whether a reported detection is real or a false positive, or whether a reported non-detection is genuine or a false negative.

It's also worth noting that, shortly after releasing Stable Signature, Meta developed another algorithm: Pixel Seal. (Not to be confused with my own Secure Evidence Attribution Label / SEAL technology.) Pixel Seal moves to a 256-bit payload to increase the capacity, and their related model, Chunky Seal, pushes up to 1024 bits. While Meta's approach focuses heavily on addressing the invisibility side using an adversarial-only discriminator, the underlying approach still uses a neural network mapping. Using more bits only exacerbates this flaw.

Potential Uses

Algorithms can have uses. For example, Meta, Google, and Adobe are training their own AI models on images that they encounter. To prevent poisoning their training sets, they want to exclude images generated by their own systems. In this regard, watermarking does help them. For example, if Meta excludes an extra 25% of images (from false positives), then they still have a lot of images that they can train on.

However, that same usage does not work with legal cases. For example, consider an insurance company. Most insurance claims today include photographic evidence. The company wants camera-original photos, but have to use whatever the customer submits. The problem is that there is a lot of insurance fraud. In theory, seeing a watermark from an AI system like Meta, Google, or Adobe, should be great for identifying and ruling out fraud. Unfortunately, Stable Signature, SynthID, and TrustMark are so inaccurate that none of them can be trusted; it's not even worth testing to see if customer photos contain these invisible watermarks.

For these watermarking systems, I'm talking about very high error rates: roughly 1-in-4 for Meta, 1-in-5 for Adobe, and 1-in-20 for Google. But let's pretend that they work much better, like a 1-in-20,000 false positive rate. An insurer processing 100,000 claims per month would expect to accuse around 5 completely honest customers of fraud each month. Falsely denying 5 out of 100,000 claims? That creates a toxic customer service nightmare, severe legal liability, and fines from regulatory bodies for bad-faith claim denials. This could even become a class-action lawsuit that they couldn't win.

As bad as it is for insurance and financial institutions, there are much higher stakes at play. The EU AI Act (Article 50(2)), China's GB 45438-2025, California SB 942, and similar legislation are moving toward mandating AI content watermarking.

The failure of these three leading systems, from three Fortune-500 companies, to meet their own claimed accuracy rates is not just an academic curiosity. Regulators and courts will employ these systems for attribution and fraud detection. Reliable AI-based watermarking technology is not ready.

Three companies. Three algorithms. Three different research teams. The same fundamental error. The false positives won't go on trial. People will.