Everyone with a new project or new technology wants rapid adoption. The bigger the customer base, the more successful the project can hope to be. However, in the race to be the first one out the door, these developers often overlook the customer needs. (Just because you can do it, does it mean the customer wants it? And does it solve a problem that the customer has?)

Many of my friends, colleagues, and clients work in security-related industries. That explicitly means that they are risk-averse and very slow to adopt new technologies. Even for existing technologies, some of my clients have multi-month release cycles. Between when I give them a code drop and when they deploy it for their own use, a few months might pass. During that time, the code is scanned for malware, tested in an isolated testing environment (regression testing), then tested in a second testing environment (more aggressive testing), maybe a third testing environment (real-world simulation), and then finally deployed to production. It's rare for large companies to just download the code drop and start using it in production.

There's a big reason for being risk-averse. If you work in the financial, medical, or insurance fields, then you have legal liability. You're not going to adopt something that puts you or your company at risk. If you can't trust that a tool's results will be consistent or trustworthy, then you're not going to use it.

In this blog, I explore whether C2PA-signed media, such as photos from the Google Pixel 10, should be accepted as reliable evidence in a court of law. My findings show serious inconsistencies in timestamps, metadata protection, and AI processing. These issues call its forensic reliability into question.

Legally Acceptable

Forensics effectively means "for use in a court of law". For any type of analysis tool, the biggest concern is whether the tool or the results are admissible in court. This means that it needs to comply with the Daubert or Frye standards and the Federal Rules of Evidence. These are the primary requirements needed to ensure that tools and their results can be admissible in a US courtroom.

Daubert and Frye refer to two different guidelines for accepting any tools in a court of law. As a non-attorney, my non-legal understanding is that they are mostly the same thing. Both require the tools, techniques, and methods to be relevant to the case, scientifically sound, and provide reliable interpretations. The main differences:

• Daubert is used in federal and some state courts. Frye is used in the states that don't rely on Daubert. However, you might hear arguments related to both the Daubert and Frye interpretations in a single courtroom.


• Frye is based on a "general acceptance" criteria: Is the underlying scientific principle or method "generally accepted" as reliable within the relevant scientific community?


• Daubert requires the judge to act as the final "gatekeeper". The judge uses specific criteria to evaluate the principles and methodology (not the conclusion generated) before determining if the approach is acceptable. Because Daubert considers multiple factors (such as the error rate and methods used), it is often considered to be a stricter standard.


• In both cases, judges often rely on precedence. If your tool is accepted in court one time, then it's more likely to be accepted the next time.

Along with Daubert and Frye, the Federal Rules of Evidence (FRE) define criteria for acceptability of both the evidence and anyone testifying about the evidence. These include guidance about relevancy (FRE Rules 401 and 403), expert testimony (FRE Rule 702), and scientific acceptability (FRE Rules 901 and 902). I'm not an attorney, and I'm sure that legal experts can identify additional requirements.

For my FotoForensics service:

• All analyzers are based on solid (logical) theory. The outputs are deterministic and repeatable. Moreover, other people have been able to implement variations of my analyzers and can generate similar results. (This goes toward reproducibility.)


• I explicitly avoid using any kind of deep learning AI. (I don't use AI to detect AI, which is the current fad.) This goes toward provability. In fact, every outcome on the commercial FotoForensics service is easily explainable -- it's a white box system, not a black box. When the expert gets up on the stand, they can explain how the software reached any results.


• FotoForensics has been peer reviewed and referenced in academic publications. The back-end analysis tools also passed a functional review by the Department of Defense Cyber Crime Center (DC3). (The DC3 only gives a pass/fail rating. It passed, with the note "steep learning curve". FotoForensics was created as a front-end to simplify the learning curve.)


• FotoForensics has been used in a court of law and deemed acceptable. (Technically, the tool itself was never questioned. The experts using the tool were found to be acceptable under FRE Rule 702.)

In contrast to FotoForensics, we have cameras adopting AI content creation and integrating with C2PA. With the Google Pixel 10, we have them combined. Each poses a problem and when combined, they make the problems worse.

Vetting the Pixel 10

Let's say you have a picture from Google's new Pixel 10 smartphone and you want to use it as evidence in a court of law. Is the picture reliable? Can the C2PA signature be used to authenticate the content?

Keep in mind, if you are law enforcement then you are a trained observer and sworn to uphold the law. In that case, saying "Yes, that picture represents the situation that I observed" is good enough. But if you're anyone else, then we need to do a deep analysis of the image -- in case you are trying to submit false media as evidence. This is where we run into problems.

To illustrate these issues, I'm going to use three pictures that "named router" (that's what he calls himself) captured. He literally walked in to a store, asked to test a Pixel 10 camera, and took three photos in succession. Click click click. (He gave me permission to use them in this blog.) Here are the pictures with links to the analyzers at FotoForensics, Hintfo, and C2PA's official Content Credentials website, as well as the EXIF timestamp and the trusted timestamp (TsT) from the notary that are found in the picture's metadata:

Image	Analyzers	EXIF vs TsT Difference	Metadata Consistency
	FotoForensics Hintfo Content Credentials	EXIF: 2025-10-14 17:19:25 +02:00 Notarized: 2025-10-14 15:19:26 GMT Difference: +1 second	Consistent metadata and expected behavior.
	FotoForensics Hintfo Content Credentials	EXIF: 2025-10-14 17:19:32 +02:00 Notarized: 2025-10-14 15:19:32 GMT Difference: 0 seconds	Includes a video; an unexplained variation.
	FotoForensics Hintfo Content Credentials	EXIF: 2025-10-14 17:19:36 +02:00 Notarized: 2025-10-14 15:19:35 GMT Difference: -1 seconds	Metadata is consistent with the first image. However, the timestamps are inconsistent: the notary predates the EXIF.

If we accept the EXIF and XMP metadata at face value, then:

• The pictures were taken seconds apart. (Three pictures in 11 seconds.)


• The EXIF metadata identifies each picture as coming from a Google Pixel 10 camera. Each includes lens settings and device information that seem rational. The EXIF data matches the expectations.


• There is one problem in the EXIF metadata: Every picture created by the Pixel 10 has EXIF metadata saying that it is a composite image: Composite Image Captured While Shooting. (Technically, this is EXIF tag 0xa460 with value 3. "3" means it is a composite image that was captured while shooting.) This tag means that every picture was adjusted by the camera. Moreover, it was more than the usual auto-exposure and auto-focus that other cameras provide. We do not know if the alterations significantly altered the meaning of the picture. Given that every picture from a Pixel 10 includes this label, it's expected but problematic.


• Comparing the files, there is a bigger problem. These files were taken in rapid succession. That means the user didn't have time to intentionally change any camera settings. (I confirmed this with the photographer.) The first and third pictures have the same metadata fields in the same order, and both include a Gain Map. (Consistency is good.) However, the second picture includes an additional video attachment. Inconsistency is bad because it can appear to be tampering. (Talking with the photographer, there was nothing special done. We have no idea why the camera decided to randomly attach a video to the JPEG image.)

Many cameras change metadata based on orientation, zoom, or other settings. However, I don't know of any other cameras that arbitrarily change metadata for no reason.

Metadata, by itself, can be maliciously altered, but that usually isn't the default assumption. Instead, the typical heuristic is: trust the metadata until you seen an indication of alteration. At the first sign of any inconsistency, stop trusting the metadata. The same goes for the content: trust the content until you notice one inconsistency. The instant you notice something wrong, you need to call everything into question.

Add in C2PA

Given that every Pixel 10 picture natively includes AI and can randomly change the metadata, this can be very problematic for an examiner. However, it gets worse, because the Pixel 10 includes C2PA metadata.

As mentioned in my earlier blog entry, the Pixel 10's C2PA metadata (manifest) explicitly excludes the EXIF and XMP metadata from the cryptographic signature. Those values can be easily changed without invalidating the cryptographic signature. Again, this doesn't mean that the metadata was altered, but it does mean that the metadata could be altered without detection.

The C2PA metadata includes a timestamp from a trusted source. This is not when the picture was generated. This is when the picture was notarized. It says that the trusted source saw that the data existed at the time it was signed.

What I didn't know at the time I wrote my previous blog entry was that the Pixel 10's Trusted Timestamp Authority (TSA) is built into the camera! They appear to maintain two separate clocks in the Pixel 10. One clock is for the untrusted EXIF timestamps (when the file was created), while the other is for the trusted timestamp (when the notary signed the file). This is where the problem comes in: if both clocks exist on the same device, then I'd expect drift between the clocks to be negligible and times to be consistent.

• In the first sample picture, the notary's timestamp is one second after the EXIF timestamp. This doesn't bother me since the actual difference could be a fraction of a second. For example, the EXIF data says the picture was captured at 17:19:25.659 seconds (in GMT+02:00). If the signing took 0.35 seconds, then the trusted timestamp would be at 26.xxx seconds -- with integer rounding, this would be 15:19:26 GMT, which matches the timestamp from the trusted notary.


• The second picture was captured at 17:19:32 +02:00 and notarized within the same second: 15:19:32 GMT. This is consistent.


• The third picture was captured at 17:19:36 +02:00 and notarized one second earlier! At 15:19:35 GMT. This is a significant inconsistency. Since it's all on the same device, the notary should be at or after the EXIF is generated; never before. Moreover, since the trusted timestamp shows that the file was notarized before the EXIF data was generated, we don't know what information was actually notarized.

Without C2PA, I would have had no reason to distrust the EXIF timestamps. But with C2PA, I now have a strong reason to suspect that a timestamp was altered. Moreover, we have two inconsistencies among these three pictures: one with different metadata and one with the notary generating a signed timestamp before the data was created.

As an analyst with no information about the ground truth, it's not just that I wouldn't trust the third picture; I wouldn't trust the entire set! It looks no different than if someone modified the EXIF timestamps on the third picture, and likely altered the first two pictures since the alteration would be undetectable. Moreover, the metadata difference in the second picture could be from someone inserting a different image into the sequence. (That's common with forgeries.)

Unfortunately, knowing the ground truth doesn't make this any better.

With other Google Pixel 10 images, I've seen the unaltered EXIF times and trusted timestamp differ by almost 10 seconds. For example, this haystack image came from DP Review:



The metadata says that the photo was captured on 2025-08-27 01:02:43 GMT and notarized a few seconds later, at 2025-08-27 01:02:46 GMT. The problem is, there's also a depth map attached to the image, and it also contains EXIF metadata. The main image's EXIF data is part of the C2PA exclusion list, but the depth map (and its EXIF data) is protected by a C2PA's cryptographic signature. The depth map's EXIF says it was created at "2025-08-27 01:02:47 GMT", which is one second after the picture was notarized.

• The entire picture took four seconds to be created.
• The notary signed the trusted timestamp before the camera finished creating the file.

This doesn't just call into question the trusted timestamp in the initial three pictures or the haystack photo. This calls into question every trusted timestamp from every C2PA-enabled application and device.

Time's Up

Back in 2024, I gave a presentation for the IPTC organization titled "C2PA from the Attacker's Perspective". During the talk, I demonstrated some of the problems that I had previously (privately) reported to the C2PA. Specifically, I showed how anyone could alter the trusted timestamp without detection. (Some of C2PA's steering committee members had previously heard me say it was possible, but they had not seen a working demonstration of the exploit.) There were two core problems that made this alteration possible:

1. The C2PA implementation by Adobe/CAI was never checking if the trusted timestamp was altered. This meant that I could alter it without detection. (It was pretty entertaining when I demonstrated this live, and people were commenting in the real-time chat with remarks like "I just confirmed it.")


2. As far as I could tell, the trusted timestamp was not protecting anything else. The trusted timestamp is supposed to be cryptographically encompassing some other data:
   
   
   1. You generate a hash of the data you want to sign.
   2. You send the hash to the Trusted Timestamp Authority (TSA).
   3. The TSA returns a certificate with a signed timestamp.
   
   Although my IPTC presentation criticized an earlier version of the C2PA specification, the most recent version (C2PA v2.2) retains the same problem. Unfortunately, C2PA's implementation doesn't appear to signing anything of importance. This appears to be a problem that stems from the C2PA specifications. Specifically, section 10.3.2.5 mentions signing a minor portion of the manifest: (my bold for emphasis)
   

   10.3.2.5.2. Choosing the Payload
   
   A previous version of this specification used the same value for the payload field in the time-stamp as was used in the Sig_signature as described in Section 10.3.2.4, “Signing a Claim”. This payload is henceforth referred to as a "v1 payload" in a "v1 time-stamp" and is considered deprecated. A claim generator shall not create one, but a validator shall process one if present.
   
   The "v2 payload", of the "v2 time-stamp", is the value of the signature field of the COSE_Sign1_Tagged structure created as part of Section 10.3.2.4, “Signing a Claim”. A "v2 payload" shall be used by claim generators performing a time-stamping operation.
   
   
   10.3.2.4. Signing a Claim
   
   Producing the signature is specified in Section 13.2, “Digital Signatures”.
   
   For both types of manifests, standard and update, the payload field of Sig_structure shall be the serialized CBOR of the claim document, and shall use detached content mode.
   
   The serialized COSE_Sign1_Tagged structure resulting from the digital signature procedure is written into the C2PA Claim Signature box.
   
   ...
   14.2.2. Use of COSE
   
   Payloads can either be present inside a COSE signature, or transported separately ("detached content" as described in RFC 8152 section 4.1). In "detached content" mode, the signed data is stored externally to the COSE_Sign1_Tagged structure, and the payload field of the COSE_Sign1_Tagged structure is always nil.

   It appears that other parts of the manifest (outside of the "v2 payload") can be altered after generating the trusted timestamp's signature. This gives the appearance of claiming that the timestamp authenticates the content or manifest, even though it permits the manifest to be changed after generating the trusted timestamp information.

After my live demo, the Adobe/CAI developers fixed the first bug. You can no longer manually alter the trusted timestamp without it being flagged. If you use the command-line c2patool, any attempt to alter the trusted timestamp returns a "timeStamp.mismatch", like:

"informational": [

  {

    "code": "timeStamp.mismatch",

    "url": "self#jumbf=/c2pa/urn:c2pa:2c33ba25-6343-d662-8a8c-4c638f4a3e68",

    "explanation": "timestamp did not match signed data"

  }

However, as far as I can tell, they never fixed the second problem: the trusted timestamp isn't protecting anything important. (Well, other than itself.). The manifest can be changed after the trusted timestamp is generated, as long as the change doesn't touch the few bytes that the C2PA specifications says to use with the trusted timestamp.

With C2PA, the trusted timestamp is supposed to work as a notary. However, as a notary, this is effectively signing a blank piece of paper and letting someone fill in everything around it. The trusted timestamp appears to be generated before the file is fully created and the exclusion list permits the EXIF and XMP metadata to be altered without detection. In any legal context, these fatal flaws would immediately void the notary's certification.

This isn't just a problem with every Google Pixel photo. This seems to be a problem with every signed C2PA image that includes a TSA's trusted timestamp. Since the Google Pixel 10 is on C2PA's conforming product list, this is a problem with the C2PA specification and not the individual implementations.

Core Arguments

At this point, we have a photo from a Pixel 10 with a C2PA signature. What can we trust from it?

• The Pixel 10 uses AI to alter the image prior to the initial saving. As demonstrated in the previous blog entry, the alterations are extreme enough to be confused with AI-generated images. There appears to be no way to disable these alterations. As a result of the AI manipulation, it becomes questionable whether the alterations change the media's meaning and intent.


• The Pixel 10 does not protect the EXIF or XMP metadata from tampering. (Those metadata blocks are in the C2PA manifest's exclusion list.) An analyst should completely ignore the C2PA metadata and evaluate the EXIF and XMP independently.


• The trusted timestamp appears to be mostly independent of the picture's creation time. (I say "mostly" because the camera app appears to call the TSA "sometime" around when the picture's C2PA manifest was being created.)

If the C2PA cryptographic signatures are valid, it only means that the file (the parts that were not excluded from the signature) was not altered after signing; it says nothing about the validity of the content or accuracy of the metadata. A valid C2PA manifest can be trusted to mean that parts of the file are cryptographically unaltered since the camera signed it. However, it does not mean that the visual content is a truthful representation of reality (due to AI) or that the metadata is pristine (due to exclusions).

But what if the C2PA signatures are invalid, or says that the media was altered? Does that mean you can still trust it? Unfortunately, the answer is "no". Just consider the case of the Holocaust deniers. (I blogged about them back in 2016.) Some Holocaust deniers were manufacturing fake Holocaust pictures and getting them inserted into otherwise-legitimate photo collections. Later, they would point out their forgeries (without admitting that they created them) in order to call the entire collection into question.

By the same means, if someone attaches an invalid C2PA manifest to an otherwise-legitimate picture, it will appear to be tampered with. If people believe that C2PA works, then they will assume that the visual content was altered even through the alteration involved the manifest. (This is the "Liar's Dividend" effect.)

Regardless of whether the C2PA's cryptographic signatures are valid or invalid, the results from the C2PA manifest cannot be trusted.

Summary Judgment

All of this takes us back to whether pictures from a Google Pixel 10, and C2PA in general, should be accepted for use in a court of law. (To reiterate, I'm not a legal scholar and this reflects my non-attorney understanding of how evidence and forensic tools are supposed to be presented in court.)

• FRE Rule 901(b)(9) covers "Evidence About a Process or System". The proponent must show the "process or system produces an accurate result." In this blog entry, I have shown that the "Pixel 10/C2PA system" fails this on several counts:
  
  
  • Lack of "Accurate Result": The AI/Computational Photography from the Pixel 10 means the image is not a simple, accurate record of light, but an interpretation.
  
  
  • System Inconsistency: The random inclusion of a video attachment and the random, unexplained time shifts demonstrate that the "system" (the camera software) is not operating consistently or predictably, thus failing to show that it "produces an accurate result" in a reliably repeatable manner.
  
  
  • Lack of Relevancy: The trusted timestamp does not appear to protect anything of importance. The manifest and contents can be written after the Trusted Timestamp Authority generates a signed timestamp.


• FRE Rule 902 goes toward self-authentication. It is my understanding that this rule exists to reduce the burden of authentication for certain reliable records (like certified business records or electronic process results). By failing to cryptographically protect the foundational metadata (EXIF/XMP), the C2PA system prevents the record from even being considered for self-authentication under modern amendments like FRE Rule 902(13) or 902(14) (certified electronic records and data copies), forcing it back to the more difficult FRE Rule 901 requirements.


• FRE Rule 702 (Expert Testimony) and black boxes. FRE Rule 702 requires an expert's testimony to be based on "reliable principles and methods" which the expert has "reliably applied to the facts of the case." With AI-driven "computational capture", the expert cannot explain why the image looks the way it does, because the specific AI algorithm used to generate the final image is a proprietary black box. This is a significant Daubert and FRE Rule 702 hurdle that the Pixel 10 creates for any expert trying to authenticate the image.


• The Kuhmo Tire, Joiner and Rule 702 Precedent. Even if the C2PA specification is found to be generally valid (Daubert/Frye), the Google Pixel 10's specific implementation may fail the Kuhmo Tire test because of its unreliable application (the timestamp reversal, the random video attachment, and the exclusion list). An attorney could argue that the manufacturer's implementation is a sloppy or unpredictable application of the C2PA method.

These failures mean that any evidence created by this system raises fundamental challenges. It fails the reliability, reproducibility, and scientific soundness of any media created by the Pixel 10 and of C2PA in general. Based on these inconsistencies, I believe it would likely fail the Daubert, Frye, and Rule 901 standards for admissibility.

The flaws that I've shown, including inconsistent timestamps and partial signing, are not edge cases or vendor oversights. They are baked into the specification's logic. Even a flawless implementation of C2PA version 2.2 would still produce unverifiable provenance because the standard itself allows essential data to remain outside the trusted boundaries.

Good intent doesn't make a flawed protocol trustworthy. In forensic work, evidence is either verifiable or it isn't. If a standard cannot guarantee integrity, then it doesn't matter how many companies endorse it since it fails to be trustworthy.

On Tuesday Oct 21 (tomorrow), the C2PA/CAI is holding a talk titled, "Beyond a Reasonable Doubt: Authenticity in Courtroom Evidence". (Here's the announcement link that includes the invite.) I've tried to reach out to both the speaker and Adobe about this, but nobody responded to me. I certainly hope people go and ask the hard questions about whether C2PA, in its current form, should be admissible in a court of law. (It would be great if some knowledgeable attorneys showed up and asked questions related to Daubert, Frye, Kuhmo Tire, Joiner, Rule 901, Rule 902, Rule 702, etc.) My concern is that having an Assistant District Attorney present in this forum may give false credibility toward C2PA. While I have no reason to doubt that the Assistant District Attorney is a credible source, I believe that the technology being reviewed and endorsed by association is not credible.

Last month, one of my PTSD (People Tech Support Duties) requests led me down a deep path related to AI-alterations inside images. It began with a plea to help photograph a minor skin irritation. But this merged with another request concerning automated AI alterations, provenance, and detection. Honestly, it looks like this rush to embrace "AI in everything" is resulting in some really bad manufacturer decisions.

What started with a request to photograph a minor skin rash ended up spiraling into a month-long investigation into how AI quietly rewrites what we see.

Cameras Causing Minor Irritations

The initial query came from a friend. Her kid had a recurring rash on one arm. These days, doctor visits are cheaper and significantly faster when done online or even asynchronously over email. In this case, the doctor sent a private message over the hospital's online system. He wanted a photo of the rash.

This sounds simple enough. Take out the camera, hold out the arm, take a photo, and then upload it to the doctor. Right?

Here's the problem: Her camera kept automatically applying filters to make the picture look better. Visually, the arm clearly had a rash. But through the camera, the picture just showed regular skin. It was like one of those haunted house scenes where the mirror shows something different. The camera wasn't capturing reality.



These days, smart cameras often automatically soften wrinkles and remove skin blemishes -- because who wants a picture of a smiling face with wrinkles and acne? But in this case, she really did want a photo showing the skin blemishes. No matter what she did, her camera wouldn't capture the rash. Keep in mind, to a human seeing it in real life, it was obvious: a red and pink spotted rash over light skin tone. We tried a couple of things:

• Turn off all filters. (There are some hidden menus on both Android and iOS devices that can enable filters.) On the Android, we selected the "Original" filter option. (Some Androids call this "None".) Nope, it was still smoothing the skin and automatically removing the rash.


• Try different orientations. On some devices (both Android and iOS), landscape and portrait modes apply different filters. Nope, the problem was still present.


• Try different lighting. While bright daylight bulbs (4500K) helped a little, the camera was still mitigating most of it.


• Try a different camera. My friend had both an Android phone and an Apple tablet; neither was more than 3 years old. Both were doing similar filterings.

We finally did find a few ways to get good pictures of the rash:

• Use a really old digital camera. We had a 10+ year old Sony camera (not a phone; a real standalone camera). With new batteries, we could photograph the rash.


• On my older iPhone 12 mini, I was able to increase the exposure to force the rash's red tint to stand out. I also needed bright lighting to make this work. While the colors were far from natural, they did allow the doctor to see the rash's pattern and color differential.


• My laptop has a built-in camera that has almost no intelligence. (After peeling off the tape that I used to cover the camera...) We tried a picture and it worked well. Almost any desktop computer's standalone webcam, where all enhancements are expected to be performed by the application, should be able to take an unaltered image.

I'm glad my friend's kid found this entire experimentation process fascinating. But if this had been a more time-sensitive issue, I honestly don't know what a typical user with a newer device could have done.

This irritating experience was just a scratch of a much larger issue that kept recurring over the month. Specifically, how modern cameras' AI processing is quietly rewriting reality.

AI Photos

Since the start of digital photography, nearly all cameras have included some form of algorithmic automation. Normally it is something minor, like auto-focus or auto-contrast. We usually don't think of these as being "AI", but they are definitely a type of AI. However, it wasn't until 2021 when the first camera-enabled devices with smart-erase became available. (The Google Pixel 6, Samsung Galaxy S21, and a few others. Apple didn't introduce its "Clean Up" smart erase feature until 2024.)

Following the rash problem, I had multiple customer requests asking whether their pictures were real or AI. Each case concerned the same camera: The new Google Pixel 10. This is the problem that I predicted at the beginning of last month. Specifically, every picture from the new Google Pixel 10 is tagged by Google as being processed by AI. This is not something that can be turned off. Even if you do nothing more than bring up the camera app and take a photo, the picture is tagged with the label:

Digital Source Type: http://cv.iptc.org/newscodes/digitalsourcetype/computationalCapture

According to IPTC, this means:

The media is the result of capturing multiple frames from a real-life source using a digital camera or digital recording device, then automatically merging them into a single frame using digital signal processing techniques and/or non-generative AI. Includes High Dynamic Range (HDR) processing common in smartphone camera apps.

In other words, this is a composite image. And while it may not be created using a generative AI system ("and/or"), it was definitely combined using some kind of AI-based system.

In industries that are sensitive to fraud, including banking, insurance, know-your-customer (KYC), fact checking, legal evidence, and photojournalism, seeing any kind of media that is explicitly labeled as using AI is an immediate red flag. What's worse is that analysis tools that are designed to detect AI alterations, including my tools and products from other developers, are flagging Pixel 10 photos as being AI. Keep in mind: Google isn't lying -- every image is modified using AI and is properly labeled. The problem is that you can't turn it off.

One picture (that I'm not allowed to share) was part of an insurance claim. If taken at face value, it looked like the person's car had gone from 60-to-zero in 0.5 seconds (but the tree only sustained minor injuries). However, the backstory was suspicious and the photos, from a Google Pixel 10, had inconsistencies. Adding to these problems, the pictures were being flagged as being partially or entirely AI-generated.

We can see this same problem with a sample "original" Pixel 10 image that I previously used.



At FotoForensics, the Error Level Analysis (ELA) permits visualizing compression artifacts. All edges should look similar to other edges, surfaces should look like surfaces, and similar textures should look similar. With this image, we can see a horizontal split in the background, where the upper third of the picture is mostly black, while the lower two thirds shows a dark bluish tinge. The blue is due to a chrominance separation, which is usually associated with alterations. Visually, the background looks the same above and below (it's the same colors above and below), so there should not be a compression difference. The unexpected compression difference denotes an alteration.



The public FotoForensics service has limited analyzers. The commercial version also detects:

• A halo around the light fixture, indicating that either the background was softened or the chandelier was added or altered. (Or all of the above.)


• The chevrons in the stained glass were digitally altered. (The Pixel 10 boosted the colors.)


• The chandelier has very strong artifacts that are associated with content from deep-learning AI systems.

None of these were intentional alterations. (Jeff just opened the camera app and took a picture. Nothing fancy by the human.) These are all AI-alterations by the Google Pixel 10 and they cannot be disabled.

In my previous blog entry, I showed that Google labels all photos as AI and that the metadata can be altered without detection. But with these automatic alterations baked into the image, we can no longer distinguish reality from revision.

Were the pictures real? With the car photos (that I cannot include here), my professional opinion was that, ignoring the AI and visual content, the photos were being misrepresented. (But doesn't the Pixel 10 use C2PA and sign every photo? Yes it does, but it doesn't help here because the C2PA signatures don't protect the metadata.) If I ignored the metadata, I'd see the alterations and AI fingerprints, and I'd be hard-pressed to determine if the detected artifacts were human initiated (intentional) or automated (unintentional). This isn't the desired AI promise, where AI generates content that looks like it came from a human. This is the opposite: AI forcing content from a human to look like AI.

Other Tools

After examining how these AI-enabled systems alter photos, the next question becomes: how well can our current tools even recognize these changes?

My analysis tools rely on deterministic algorithms. (That's why I call the service "FotoForensics" -- "Forensics" as in, evidence suitable for a court of law.) However, there are other online services that use AI to detect AI. Keep in mind, we don't know how well these AI systems were trained, what they actually learned, what biases they have, etc. This evaluation is not a recommendation to use any of these tools.

This inconsistency between different AI-based detection tools is one of the big reasons I don't view any of them as serious analyzers. For the Pixel 10 images, my clients had tried some of these systems and saw conflicting results. For example, using the same "original" Pixel 10 baseline image:

• Hive Moderation trained their system to detect a wide range of specific AI systems. They claim a 0% chance that this Pixel 10 photo contains AI, because it doesn't look like any of the systems they had trained on. Since the Pixel 10 uses a different AI system, they didn't detect it.
  
  


• Undetectable AI gives no information about what they detect. They claim this picture is "99% REAL". (Does that mean it's 1% fake?)
  
  


• SightEngine decided that it was "3%" AI, with a little generative AI detected.
  
  


• Illuminarty determined that it was "14.9%" AI-generated. I don't know if that refers to 14.9% of the image, or if that is the overall confidence level.
  
  


• At the other extreme, Was It AI determined that this Google Pixel 10 picture was definitely AI. It concluded: "We are quite confident that this image, or significant part of it, was created by AI."
  
  

The ground truth is that the Pixel 10 always uses AI to auto-enhance the picture. If you work in a field that forbids any AI enhancement, then the Pixel 10 is a serious problem. (You can't just tell your client that they need to go back to the site of the accident and take pictures with a different camera.)

Fear the Future

Once upon a time, "taking a picture" meant pressing a button and capturing something that looked like reality. Today, it's more like negotiating with an algorithm about what version of reality it's willing to show you. The irony is that the more "intelligent" cameras become, the less their output can be trusted. When even a simple snapshot passes through layers of algorithmic enhancement, metadata rewriting, and AI tagging, the concept of an "original" photo starts to vanish.

People use AI for lots of tasks these days. This includes helping with research, editing text, or even assisting with diagnostics. However, each of these uses still leaves the human with the final decision about what to accept, reject, or cross-validate. In contrast, the human photographer has no option to reject the AI's alterations to these digital photos.

From medical photos and insurance claims to legal evidence, the line between "photo" and "AI-enhanced composite" has blurred. For fields that rely on authenticity, that's not a minor inconvenience; it's a systemic problem. Until manufacturers return real control to the photographer, sometimes the most reliable camera is the old one in the junk drawer -- like a decade-old Sony camera with no Wi-Fi, no filters, and no agenda.

P.S. Brain Dead Frogs turned this blog entry in a song for an upcoming album. Enjoy!

What do you do when you find a flaw in a piece of computer software or hardware? Depending on the bug, a legitimate researcher might:

• Report it to the vendor. This is the most desirable solution. It should be easy to find a contact point and report the problem.


• Publicly tell others. Full disclosure and public disclosure, especially with a history showing that you already tried to contact the vendor, helps everyone. Even if there is no patch currently available, it still helps other people know about the problem and work on mitigation options. (Even if you can't patch the system, you may be able to restrict how the vulnerable part is accessed.)


• Privately tell contacts. This keeps a new vulnerability from being exploited publicly. Often, a vendor may not have a direct method of reporting, but you might know a friend of a friend who can report it to the vendor through other means.


• Privately sell it. Keeping vulnerabilities quiet also permits making money by selling bugs privately to other interested parties. Of course, you don't know how the others are going to use the new exploit... But that's why you should try to report it to the vendor first. If the vendor isn't interested, then all bets are off. (You can get a premium if you can demonstrate a working exploit and show that the vendor is not interested in fixing it.)


• Keep it to yourself. While there is a risk of someone else finding the same problem, sometimes it's better to keep the bug handy in case you need it in the future. (This is especially true if compromising systems is part of your job description, such as professional penetration testers or hired guns.)


• Do nothing. This option is unfortunately common when the reporting method is unidentified or overly complicated. (I'm trying to report a bug, not build a desk from Ikea. I don't want pages of instructions and an Allen wrench.)

Reporting to the vendor, or at least trying to report to the vendor before resorting to some other option, falls under the well-known best practices of responsible disclosure and full disclosure.

Incentives

Some vendors offer incentives in order to receive bugs. These bug bounty programs often include financial rewards in exchange for informing the vendor and working with them to resolve the issue.

In the old days, bug bounties worked pretty well. (I've even made some money that way.) However, over the years, some companies have perverted the incentives. Rather than paying for the information so they can fix it, they pay for the information and require an agreement to legal terms. For example, some companies have attached stipulations to the payments, such as "by agreeing to this transaction, you will not make it public without coordinating the disclosure with us." (And every time you ask, they will say that they have prioritized it or are still working on it, even years later.) More than a few vendors use bug bounties as a way to bury the vulnerability by paying for silence.

I have personally had too many bad experiences with bug bounties and vendors paying for the privilege of being non-responsive. I don't think bounty programs are worth the effort anymore. Additionally, I won't do bug bounty programs if they require enrolling into any service or are associated with some kind of legal agreement. (If they want me to agree to legal terms, then they need to pay for my attorney to review the terms before I sign it.)

In contrast to bounties, some companies send very nice "thank you" response to people who took the effort to report a bug. Often, these are swag and not financial. I've received t-shirts, hats, mugs, stickers, and very nice thank-you letters. Unlike bounties, I've found that each time a vendor sends me an unsolicited "thank you" (even if it's just a nice personalized email), they are responsive and actively fix the bug.

While some people report bugs for the money or swag, I have a different incentive. If I found a bug and it impacts me or my clients, then I want it fixed. The best place to fix it is with the vendor, so I try to report the problem. This is very much a self-serving purpose: I want their code to work better for my needs. Then again, many vendors are incredibly responsive because they want to provide the best solution to their customers. My bug reports help them and me.

Jump Through Hoops

When it comes to bug reporting, the one thing I don't want to do is jump through hoops. The most common hoops include closed lists, scavenger hunts, strict reporting requirements, and forced legal terms.

• Hoop #1: Closed Lists
  Many open source projects want bugs reported to their mailing list, discord channel, IRC server, private forum, or some other service that requires signing up before reporting. For example, Gentoo Linux wants to you sign up with their Bugzilla service in order to submit a bug, and to keep any discussions in their "forums, IRC or mailing lists". Their various discussion lists also require signing up.
  
  For me, this is the same as a vendor who is unreachable. When I want to report a bug, I don't want to join any lists or forums; I just want to report a bug.


• Hoop #2: Scavenger Hunts
  Some organizations have turned "where to report" into a scavenger hunt. The Tor Project used to be a good example of this. Prior to 2019, they wanted you to search through all of their lists and try to find the correct contact point. If you contacted the wrong person, or gave up because you couldn't find the right person, then that's your fault.
  
  However, after years of complaining, the Tor Project finally simplified the reporting process. Now you can easily find multiple ways to report issues to them. (I still think they usually don't do anything when you report to them, but it's a step in the right direction.)


• Hoop #3: Strict Requirements
  Some companies and organizations have strict requirements for reporting. While I'm fine with providing my name and contact information (in case they have questions or need more details), some forms require you to provide the device's serial number, software version, and other information that the reporter may not have.
  
  For example, many years ago I found a problem with a standalone kiosk. (I'm not naming names here.) The vendor only had one way to report problems: use their online form. Unfortunately, the reporting form absolutely would not let me report the problem without providing a valid serial number and software version for the device. The problem is, it's not my kiosk. I don't know the serial number, software version, or even the alphanumeric location code. Moreover, the exploit appeared to work on all of their kiosks. But due to their strict requirements, I was unable to report the problem. (I ended up finding a friend of a friend who had a contact in the company.)
  
  Some software providers only want reports via their Bugzilla service. Bugzilla often has fields for additional information. (Other bug tracking services have similar features.) Unfortunately, I've had some software groups (again, not naming names) eagerly close out the bug report because I didn't have all of their required information. (It's not that I intentionally didn't supply it; I just didn't have that information.) Beyond an automated message telling me that the bug was closed, they never contacted me. As far as I can tell, they never even looked at the bug because the form wasn't complete enough for them. Keep in mind: my bug reports include detailed step-by-step instructions showing how to do the exploit. (In a few of these cases, I ended up selling the exploits privately to interested parties since the vendors were non-responsive.)


• Hoop #4: Mandatory Terms
  Some companies, like Google, don't have a means to report vulnerabilities without agreeing to their terms. Years ago, Google would accept vulnerability reports with no strings attached. But today, they direct everything to their "Bug Hunters" page. Before reporting a bug, you must agree to their terms.
  
  For me, any kind of non-negotiable mandatory agreement is a showstopper. Even though their terms seem simple enough, I cannot agree to them. For example, they expect "ethical conduct". I expect to act ethically, but since it's their terms, they get to determine what is and is not ethical conduct.

I can understand signing up if you want to be paid a bounty. (Google promises some very large payouts for rare conditions.) But often, I'm not looking for a bounty -- I just want to report a bug.

Interestingly, language barriers have never been a problem in my experience. Most companies auto-translate or accept reports in English. This makes the remaining hoops (legal terms, closed lists, etc.) stand out, because they are entirely self-imposed.

The Bug Bounty Scam

As a service provider, I also receive a lot of inquiries from people posing as potential bug reporters. Here's a sample email:

From: EMX Access Control Sensors <no-reply@[redacted]>
To: [redacted]@[redacted].com
Subject: Paid Bug Bounty Program Inquiry enquiry

Name:
Email: yaseen17money@hotmail.com
Message: Hi Team, I’m Ghulam Yaseen, a security researcher. I wanted to ask if you offer a paid bug bounty program or any rewards for responsibly disclosed vulnerabilities. If so, could you please share the details.

Yaseen writes to me often. Each time, from a different (compromised) domain. (I'm not worried about redacting his email since dozens of forums list this entire email in its entirety.) This isn't a real inquiry/enquiry. A legitimate query would come from their own mail server and use their own name as the sender. I think this is nothing more than testing the mail server to see if it's vulnerable.

In contrast, here's another query I received, and it seems to be from real people (names redacted):

Date: Thu, 21 Aug 2025 05:47:47 +0530
From: [Redacted1] <[redated1]@gmail.com>
Cc: [redacted2]@gmail.com, [Redacted1] <redacted1@gmail.com>
Subject: Inquiry Regarding Responsible Disclosure / Bug Bounty Program

Hello Team,

We are [Redacted1] and [Redacted2], independent security researchers specializing in vulnerability discovery and organizational security assessments.

- [Redacted2] – Microsoft MSRC MVR 2023, with prior vulnerability reports to Microsoft, SAP, BBC, and government entities in India and the UK.
- [Redacted1] – Experienced in bug bounty programs, penetration testing, and large-scale reconnaissance, with findings reported to multiple high-profile organizations.

We came across your organization’s security program information and are interested in contributing by identifying and reporting potential vulnerabilities in a responsible manner.Given our combined expertise in deep reconnaissance, application security, and infrastructure assessments, we believe we could contribute to uncovering critical security issues, including hidden or overlooked vulnerabilities.

Before conducting any form of testing, we would like to confirm the following:

1. Does your organization have an active responsible disclosure or bug bounty program?
2. Could you please define the exact scope of assets that are permitted for testing?
3. Are vulnerabilities discovered on assets outside the listed scopes but still belonging to your organization eligible for rewards?
4. Any rules of engagement, limitations, or legal requirements we should be aware of?
5. Bounty reward structure (if applicable).

We follow strict ethical guidelines and ensure all reports include clear technical detail, reproduction steps, and remediation recommendations.

Looking forward to your guidance and confirmation before initiating any further testing.

Best regards,
[Redacted1] & [Redacted2]

There's no way I'm going to respond to them.

• If I'm going to have someone audit my servers, it will be someone I contact and not who contacts me out of the blue. As covered by Krebs's 3 Basic Rules for Online Safety, "If you didn’t go looking for it, don’t install it!" The same applies to unsolicited offers for help. I didn't go looking for this, so I'm certainly not going to allow them to audit my services.


• Responding positively to any of their questions effectively gives them permission to attack your site.

These are not the only examples. I receive this kind of query at least weekly.

• Some of these inquires mention that my server has a known vulnerability. However, they don't want to tell me what it is until after they confirm that I have a bug bounty program. If I don't respond, or respond by saying that I don't offer any bounties, then they never tell me the bug. Assuming they actually found something, then this feels like extortion. (Pay them or they won't tell me.)


• A few people do point out my vulnerabilities. So far, every single case has either been from one of my honeypots or due to my fake /etc/passwd file. (They asked for a password file, so I gave them one. What's the problem?)

The best thing to do if you receive an unsolicited contact like this? Don't respond. Of course, if they do list a vulnerability, then definitely investigate it. Real vulnerabilities should receive real replies.

Sample Pre-reporting Requirements: Google

In my previous blog entry, I wrote about some significant failures in the Google Pixel 10's C2PA implementation. Before writing about it publicly, I tried multiple ways to report the issue:

1. Direct contact: I repeatedly disclosed my concerns about C2PA to a Google representative. Unfortunately, I believe my concerns were disregarded. Eventually the Google contact directed me to report issues through Google's Bug Hunters system. (That's right: the direct contact didn't want to hear about bugs in his own system unless it came through Google's Bug Bounty service.)


2. Google Bug Hunters: Google's Bug Hunters system requires agreeing to Google's vulnerability reporting terms before I could even submit the bug. I wasn't looking for a bounty; I simply wanted to report a serious problem. For me, being forced to accept legal terms before reporting is a showstopper.


3. Private outreach: After I confirmed the flaws in Pixel 10's C2PA functionality, I reached out to my trusted security contacts. In the past, this network has connected me directly to security teams at Amazon, Facebook, and other major vendors. Since Google's C2PA team was non-responsive, I wanted to contact someone in Google's Android security team or legal department; I suspected that they had not independently reviewed the C2PA implementation for its security, trust, and liability implications. (If they had, I doubt this would have shipped in its current form.) Unfortunately, no one had a contact who could receive a report outside of Google's Bug Hunters. (It's really weird how Google directs everything through Bug Hunters.)

At that point, I had exhausted my options. For me, a reporting process that requires accepting legal terms just to submit a vulnerability -- especially when I am already in direct contact with the team responsible -- is a hoop too many. This is why I posted my blog about Pixel 10's C2PA flaws. (Don't be surprised if I eventually post about more Pixel 10's problems without telling Google first. And if someone inside Google reaches out to me, I'd be happy to discuss this directly, without agreeing to any terms.)

Sample Reporting Hoops: Nikon

Around the same time the Pixel 10 was released, Nikon rolled out C2PA support for the Nikon Z6 III camera. Within days, researcher Horshack discovered that he could get any file signed by the camera, which is a serious flaw in the authenticity system. He even released a signed forgery as a demonstration:



If you upload this picture to Adobe's Content Credentials service, it reports that it is a genuine picture from a "Nikon Z6 3" camera, with no indication that it was altered or forged.

To Nikon's credit, the day after DP Review published an article about this, Nikon temporarily suspended their C2PA signing service, saying they had "identified an issue" and would "work diligently" to resolve it. That's a strong response.



Two weeks after disabling the signing service, Nikon announced that they were revoking their signing certificate. (As of this writing, 2025-09-19, the C2PA and CAI have not revoked Nikon's certificate from their list of trusted certificates. Right now, Every Content Credentials service still says the pictures that are signed using a revoked certificate are still valid and trusted.)

It's unclear if Horshack ever tried to report directly to Nikon. When I searched for a security contact point, Nikon only listed HackerOne as their reporting mechanism. HackerOne is a bug bounty system that requires enrollment, personal information, and banking details. If you aren’t seeking a bounty, then this is a major hoop that discourages reporting.

The community response to Horshack's public disclosure was mostly positive, with many people alarmed and grateful that the issue came to light. However, a few commenters criticized the public release, suggesting it might hurt Nikon's reputation. While lawsuits are always a theoretical risk, I would argue that a vendor that only accepts reports through gated programs effectively pushes researchers toward public disclosure as the only viable reporting path.

In this case, Nikon acted quickly once the problem went public. This demonstrates that they can respond, but the process could have been much smoother if they provided a simple, open reporting channel.

When one problem is reported, it's not unusual to see other people identify related problems. In the comments to the original reporting, other people detailed additional issues. For example:

• patrol_taking_9j noted that "NX Studio is completely unable to export JPEG's at all for any RAW or RAW+JPEG NEF files shot with C2PA enabled."


• Horshack replied to his own posting, noting that pictures appear to be signed hours after capture.


• Pierre Lagarde remarked that "The only thing I can say is C2PA still looks like a problem by itself, not that much like a solution to anything. At least, I think the inclusion of this feature at this stage seems premature." (I fully agree.)


• To further demonstrate the problem, Horshack created a second signed forgery:
  
  
  
  As with his first forgery, the Content Credentials service reports that it is a photo from a "Nikon Z6 3" camera.

These additional problems show the power of public disclosure. Had Horshack not made the initial problem public, other people may have not looked as closely and these related concerns may not have been brought to light.

Lower Barriers, Better Security

Bug reporting should not feel like running an obstacle course. Every extra hurdle, whether it's mandatory legal terms, scavenger hunts, closed lists, or bounty-program enrollment, increases the likelihood that a researcher will give up, go public, or sell the exploit privately.

The Google and Nikon cases highlight the same lesson: if you make responsible reporting difficult, then you drive researchers toward public disclosure. That might still result in a fix, but it also increases the window of exposure for everyone who uses the product.

The vendors who handle vulnerability reporting the best are the ones who make it simple: a plain-text email address, a short web form, or even a contact page that doesn't require more than a description and a way to follow up. Many of these vendors don't pay bounties, yet they respond quickly and even say "thank you", which is often enough to keep security researchers engaged.

The industry doesn't need more hurdles. It needs frictionless reporting, fast acknowledgment, and a clear path from discovery to resolution. Good security starts with being willing to listen: make it as easy as possible for the next person who finds a flaw to tell you about it.

Google recently released their latest-greatest Android phone: the Google Pixel 10. The device has been met with mostly-positive reviews, with the main criticisms around the over-abundance of AI in the device.

However, I've been more interested in one specific feature: the built-in support for C2PA's Content Credentials. For the folks who are new to my blog, I've spent years pointing out problem after problem with C2PA's architecture and implementation. Moreover, I've included working demonstrations of these issues; these problems are not theoretical. C2PA is supposed to provide "provenance" and "authenticity" (the P and A in C2PA), but it's really just snake oil. Having a cryptographically verifiable signature doesn't prove anything about whether the file is trustworthy or how it was created.

A Flawed Premise

A great movie script usually results in a great movie, regardless of how bad the actors are. (In my opinion, The Matrix is an incredible movie despite Keanu Reeves' lackluster performance.) In contrast, a bad script will result in a bad movie, regardless of how many exceptional actors appear in the film, like Cloud Atlas or Movie 43. The same observation applies to computer software: a great architecture usually results in a great implementation, regardless of who implements it, while a bad design will result in a bad implementation despite the best developers.

C2PA starts from a bad architecture design: it makes assumptions based on vaporware, depends on hardware that doesn't exist today, and uses the wrong signing technology.

Google Pixel 10

I first heard that the Google Pixel 10 was going to have built-in C2PA support from Google's C2PA Product Lead, Sherif Hanna. As he posted on LinkedIn:

It's official — the Google Pixel 10 is the first smartphone to integrate C2PA Content Credentials in the native Pixel Camera app. This is not just for AI: *every photo* will get Content Credentials at capture, and so will every edit in Google Photos—with or without AI.

Best of all, both Pixel Camera and Google Photos are *conformant Generator Products*, having passed through the C2PA Conformance Program.

If you didn't know better, this sounds like a great announcement! However, when I heard this, I knew it would be bad. But honestly, I didn't expect it to be this bad.

Sample Original Photo

One of my associates (Jeff) received the Google Pixel 10 shortly after it became available. He took a sample photo with C2PA enabled (the default configuration) and sent it to me. Here's the unaltered original picture (click to view it at FotoForensics):



If we evaluate the file:

• Adobe (a C2PA steering committee member) provides the official "Content Credentials" web service for validating C2PA metadata. According to them, all digital signatures are valid. The site reports that this came from the "Google C2PA SDK for Android" and the signature was issued by "Google LLC" on "Aug 28, 2025 at 8:10 PM MDT" (they show the time relative to your own time zone). According to them, the image is legitimate.


• Truepic (another C2PA steering committee member) runs a different "Content Credentials" web service. According to them, "Content credentials are invalid because this file was signed by an untrusted source."
  
  
  
  If we ignore that Truepic haven't updated their trusted certificate list in quite some time, then they claim that the manifest was signed by this signer and that it indicates no AI:
  

  detected_attributes: {
  
      is_ai_generated: false,
  
      is_ai_edited: false,
  
      contains_ai: false,
  
      is_camera_captured: false,
  
      is_visual_edit: false
  
  }

  Both authoritative sites should authenticate the same content the same way. This contradiction will definitely lead to user confusion.


• My FotoForensics and Hintfo services display the metadata inside the file. This picture includes a rich set of EXIF, XMP, and MPF metadata, which is typical for a camera-original photo. The EXIF identifies the make and model (Google Pixel 10 Pro), capture timestamp (2025-08-28 22:10:17), and more. (Jeff didn't include GPS information or anything personal.)


• There's also a C2PA manifest for the "Content Credentials". (It's in the JUMBF metadata block.) FotoForensics shows the basic JUMBF contents, but it's not easy to read. (FotoForensics doesn't try to format the data into something readable because all C2PA information is unreliable. Displaying it will confuse users by giving the C2PA information false credibility.) My Hintfo service shows the parsed data structure:
  
  
  • The manifest says it was created using "Google C2PA SDK for Android" and "Created by Pixel Camera".
  
  
  • There is a cryptographically signed timestamp that says "2025-08-29T02:10:21+00:00". This is not when the picture was created; this is when the file was notarized by Google's online timestamp service. This timestamp is four seconds after the EXIF data says the picture was captured. This is because it required a network request to Google in order to sign the media.
  
  
  • The manifest includes a chain of X.509 certificates for the signing. The signer's name is "Google LLC" and "Pixel Camera". If you trust the name in this certificate, then you can trust the certificate. However, it's just a name. End-users cannot validate that the certificate actually belongs to Google. Moreover, this does not include any unique identifiers for the device or user. Seeing this name is more "branding" than authentication. It's like having "Levi's" stamped on the butt of your jeans.
  
  Notice that the C2PA manifest does not list the camera's make, model, photo capture time, lens settings, or anything else. That information is only found in the EXIF metadata.


• Inside the C2PA actions is a notation about the content:
  

  "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/computationalCapture"

  According to IPTC, this means:
  

  The media is the result of capturing multiple frames from a real-life source using a digital camera or digital recording device, then automatically merging them into a single frame using digital signal processing techniques and/or non-generative AI. Includes High Dynamic Range (HDR) processing common in smartphone camera apps.

  
  In other words, this is a composite image. And while it may not be created using a generative AI system ("and/or"), it was definitely combined using some kind of AI-based system.
  
  (Truepic's results are wrong when they say that no AI was used. They are also wrong when they say that it is not from a camera capture. Of course, someone might point out that Truepic only supports C2PA v2.1 and this picture uses C2PA v2.2. However, there is no C2PA version number in the metadata.)
  
  As an aside, Jeff assures me that he just took a photo; he didn't do anything special. But the metadata clearly states that it is a composite: "capturing multiple frames" and "automatically merging them". This same tag is seen with other Pixel 10 pictures. It appears that Google's Pixel 10 is taking the same route as the iPhone: they cannot stop altering your pictures and are incapable of taking an unaltered photo.


• The most disturbing aspect comes from the manifest's exclusion list:
  

  "assertion_store":  {
  
        "c2pa.hash.data":  {
  
          "exclusions":  {
  
            [
  
              {
  
              "start": "6",
  
              "length": "11572"
  
              }
  
            ],
  
            [
  
              {
  
              "start": "11596",
  
              "length": "4924"
  
              }
  
            ],
  
            [
  
              {
  
              "start": "17126",
  
              "length": "1158"
  
              }
  
            ],
  
            [
  
              {
  
              "start": "18288",
  
              "length": "65458"
  
              }
  
            ],
  
            [
  
              {
  
              "start": "83750",
  
              "length": "7742"
  
              }
  
            ]
  
          },

  When computing the digital signature, it explicitly ignores:
  
  
  • 11,572 bytes beginning at byte 6 in the file. That's the EXIF data. None of the EXIF data is protected by this signature. Unfortunately, that's the only part that defines the make, model, settings, and when the photo was taken.
  
  
  • 4,924 bytes starting at position 11,596. That's the JUMBF C2PA manifest. This is the only component that's typically skipped when generating a C2PA record because most of it is protected by different C2PA digital signatures.
  
  
  • 1,158 bytes beginning at position 17,126 is the XMP data.
  
  
  • 65,458 bytes beginning at position 18,288 is the extended XMP metadata that includes Google's Makernotes.
  
  
  • 7,742 bytes beginning at position 83,750 is the continuation of the extended XMP metadata record.
  
  That's right: everything that identifies when, where, and how this image was created is unprotected by the C2PA signature. C2PA's cryptographic signatures only covers the manifest itself and the visual content. It doesn't cover how the content was created.

Without C2PA, anyone can alter the EXIF or XMP metadata. (It's a very common forgery approach.)

With the Google Pixel's C2PA implementation, anyone can still alter the EXIF or XMP metadata. But now there's a digital signature, even if it doesn't identify any alterations.

The problem is that nothing on either of the "Content Credentials" web services reports the exclusion range. If you're a typical user, then you haven't read through the C2PA specifications and will likely assume that the file is trustworthy with tamper-evident protection since the cryptographic signature is valid.

Forgery Time!

Knowing what I can and cannot edit in the file, I altered the image to create a forgery. Here's my forgery:

• If you use the official Adobe/CAI Content Credentials validation tool, you will see that the entire file is still cryptographically sound and shows the same authoritative information. There is no indication of alteration or tampering. (The results at Truepic's validation service also haven't changed.)


• The metadata displayed by FotoForensics and Hintfo shows some of the differences:
  
  
  • The device model is "Pixel 11 Pro" instead of "Pixel 10 Pro". I changed the model number.
  
  
  • The EXIF software version was "HDR+ 1.0.790960477zd". Now it is "HDR+ 3.14156926536zd". (Really, I can change it to anything.)
  
  
  • The EXIF create and modify date has been backdated to 2025-07-20 12:10:17. (One month, 8 days, and 12 hours earlier than the original.)
  
  Although this is all of the EXIF data that I changed for this example, I could literally change everything.


• Hintfo shows the decoded JUMBF data that contains the C2PA manifest. I changed the manifest's UUID from "urn:c2pa:486cba89-a3cc-4076-5d91-4557a68e7347" to "urn:neal:neal-wuz-here-neal-wuz-here-neal-wuz". Although the signatures are supposed protect the manifest, they don't. (This is not the only part of the manifest that can be altered without detection.)

While I cannot change the visual content without generating a new signature, I can change everything in the metadata that describes how the visual content came to exist.

Consistently Inconsistent

Forgeries often stand out due to inconsistencies. However, the Pixel 10's camera has been observed making inconsistent metadata without any malicious intervention. For example:



According to Digital Photography Review, this photo of a truck is an out-of-the-camera original picture from a Pixel 10 using 2x zoom. The EXIF metadata records the subject distance. In this case, the distance claims to be "4,294,967,295 meters", or about 11 times the distance from the Earth to the Moon. (That's one hell of a digital zoom!) Of course, programmers will recognize that as uint32(-1). This shows that the Pixel 10 can naturally record invalid values in the metadata fields.

As another example:



DP Review describes this graffiti picture as another out-of-the-camera original using 2x zoom. It also has the "4,294,967,295 meters" problem, but it also has inconsistent timestamps. Specifically:

• The EXIF metadata has a creation date of "2025-08-25 19:45:28". The time zone is "-06:00", so this is 2025-08-26 01:45:28 GMT.


• The C2PA-compliant external trusted timestamp authority operated by Google says it notarized the file at 2025-08-26 01:45:30 GMT. This means it took about 2 seconds for the signing request to go over the network.


• This picture has a few attached parasites. (A parasite refers to non-standard appended data after the end of the main JPEG image.) The XMP metadata identifies these extra JPEG images as the GainMap, Depth, and Confidence maps. Each of these images have their own EXIF data.
  
  ExifTool only displays the EXIF data for the main image. However, these parasites have their own EXIF data. Using the Strings analyzer at FotoForensics, you can see their EXIF dates. (Scroll to the bottom of the strings listing, then page-up about 3 times.) The data looks like:
  

  0x0030ed57: 2025:08:25 19:45:31
  
  0x0030ed8d: 0232
  
  0x0030ee35: 0100
  
  0x0030ef09: 2025:08:25 19:45:31
  
  0x0030ef1d: 2025:08:25 19:45:31
  
  0x0030ef31: -06:00
  
  0x0030ef39: -06:00
  
  0x0030ef41: -06:00

  This data says that the parasites were created at 2025-08-25 19:45:31 -06:00 (that's 2025-08-26 01:45:31 GMT). That is one second after the file was notarized. Moreover, while the C2PA's manifest excludes the main image's EXIF data, it includes these parasites and their EXIF data! This indicates that the parasites were created after the file was notarized by Google.

With photos, it's possible for the times to vary by a second. This is because the timestamps usually don't track fractions of a second. For example, if the picture was taken at 28.99 seconds and the file took 0.01 seconds to write, then the created and modified times might be truncated to 28 and 29 seconds. However, there is no explanation for the parasite's timestamp to be 3 seconds after the file was created, or any time after being notarized by the trusted timestamp provider.

Remember: this is not one of my forgeries. This is native to the camera, and I have no explanation for how Google managed to either post-date the parasites before notarizing, or generated the manifest after having the file notarized. This inconsistent metadata undermines the whole point of C2PA. When genuine Pixel 10 files look forged, investigators will conclude "tampering", even if the file is not manually altered.

With the Pixel 10's C2PA implementation, either the timestamps are untrustworthy, or the C2PA signatures are untrustworthy. But in either case, the recipient of the file cannot trust the data.

However, the problems don't stop there. Both of these sample pictures also include an MPF metadata field. The MPF data typically includes pointers to parasitic images at different resolutions. In the lamp picture, the MPF properly points to the Gain Map (a JPEG attached as a parasite). However, in these truck and graffiti examples, the MPF doesn't point to a JPEG. Typically, applications fail to update the MPF pointers after an alteration, which permits tamper detection. With these examples, we have clear indications of tampering: inconsistent metadata, inconsistent timestamps, evidence of post-dating or an untrusted signature, and a broken MPF. Yet, these are due to the camera app and Google's flawed implementation; they are not caused by a malicious user. Unfortunately, a forensic investigator cannot distinguish an altered Pixel 10 image from an unaltered photo.

Google Pixel 10: Now with Fraud Enabled by Default!

There's a very common insurance fraud scheme where someone will purchase their new insurance policy right after their valuable item is damaged or stolen. They will alter the date on their pre- and post-damage photos so that it appears to be damaged after the policy becomes active.

• Without C2PA, the insurance investigator will need to carefully evaluate the metadata in order to detect signs of alterations.


• With C2PA in a Google Pixel 10, the investigator still needs to evaluate the metadata, but now also needs to prove that the C2PA cryptographic signature from Google is meaningless.

Typical users might think that the cryptographic signature provides some assurance that the information is legitimate. However, the Pixel 10's implementation with C2PA is grossly flawed. (Both due to the Pixel 10 and due to C2PA.) There are no trustworthy assurances here.

Privacy Concerns

Beyond their inadequate implementation of the flawed C2PA technology, the Google Pixel 10 introduces serious privacy issues. Specifically, the camera queries Google each time a picture needs to be digitally signed by a trusted signing authority. Moreover, every picture taken on the Google Pixel 10 gets signed.

What can Google know about you?

• The C2PA signing process generates a digest of the image and sends that digest to the remote trusted timestamp service for signing. Because your device contacted Google to sign the image, Google knows which signature they provided to which IP address and when. The IP address can be used for a rough location estimation. Google may not have a copy of the picture, but they do have a copy of the signature.


• Since the Pixel 10 queries Google each time a photo is captured, Google knows how often you take pictures and how many pictures you take.


• While the C2PA metadata can be easily removed, the Pixel 10 reportedly also uses an invisible digital watermark called "SynthID". Of course, the details are kept proprietary because, as Google describes it, "Each watermarking configuration you use should be stored securely and privately, otherwise your watermark may be trivially replicable by others." This means, the only way to validate the watermark is to contact Google and send them a copy of the media for evaluation.

All of this enables user and content tracking. As I understand it, there is no option to disable any of it. If Google's web crawler, email, messaging system, etc. ever sees that signature again, then they know who originated the image, when and where it was created, who received a copy of the media and, depending on how Google acquired the data, when it was received.

With any other company, you might question the data collection: "While they could collect this, we don't know if they are collecting it." However, Google is widely known to collect as much user information as possible. While I have no proof, I have very little doubt that Google is collecting all of this information (and probably much more).

The inclusion of C2PA into the Pixel 10 appears to be more about user data collection and tracking than authenticity or provenance.

Security and Conformance

C2PA recently introduced their new conformance program. This includes two assurance levels. Level 1 has minimal security requirements, while Level 2 is supposed to be much more difficult to achieve and provides greater confidence in the information within the file.

There is currently only one device on the conforming products list that has achieved assurance level 2: The Google Pixel Camera. That's right, the same one that I just used to create an undetectable forgery and that normally generates inconsistent metadata.

The Provenance and Authenticity Standards Assessment Working Group (PASAWG) is performing a formal evaluation on C2PA. Some folks in the group posed an interesting theory: perhaps the Google Pixel Camera is compliant with assurance level 2. Since Google explicitly excludes everything about the hardware, they are technically conforming by omitting that information. Think of this like intentionally not attaching your bicycle lock to the entire bike. Sure, the bike can get stolen, but the lock didn't fail!

What if they fixed it?

You're probably wondering how something like this could happen at Google. I mean, regardless of whether you like the company, Google is usually known for cutting edge technology, high quality, and above-average security.

• Maybe this is just an implementation bug. Maybe nobody at Google did any kind of quality assurance testing on this functionality and it slipped past quality control.


• Maybe they were so focused on getting that "we use C2PA" and "Assurance Level 2" checkbox for marketing that they didn't mind that it didn't protect any of the metadata.


• Maybe nobody in Google's security group evaluated C2PA. This would certainly explain how they could put their corporate reputation on this flawed solution.


• Maybe nobody in Google's legal department was consulted about Google's liability regarding authenticating a forgery that could be used for financial fraud, harassment, or propaganda.

You might be thinking that Google could fix this if they didn't exclude the EXIF and XMP metadata from the cryptographic protection. (That would certainly be a step in the right direction.) Or maybe they could put some device metadata in the manifest for protection? However, you'd still be wrong. The C2PA implementation is still vulnerable to file system and hardware exploits.

These are not the only problems I've found with Google Pixel 10's C2PA implementation. For example:

• In the last few days, FotoForensics has received a handful of these pictures, including multiple pictures from the same physical device. As far as I can tell, Google uses the exact same four root certificates on every camera:
  
  
  • Google LLC, s/n 4B06ED7C78A80AFEB7193539E42F8418336D2F27
  • Google LLC, s/n 4FCA31F82632E6E6B03D6B83AB98B9D61B453722
  • Google LLC, s/n 5EF6120CF4D31EBAEAF13FB9288800D8446676BA
  • Google LLC, s/n 744428E3A7477CEDFDE9BD4D164607A9B95F5730
  
  I don't know why Google uses multiple root certs. It doesn't seem to be tied to the selected camera or photo options.
  
  While there are a limited number of root certs, every picture seems to use a different signing certificate, even if it comes from the same camera. It appears that Google may be generating a new signing certificate per picture. What this means: if a device is compromised and used for fraud, they cannot revoke the certificate for that device. Either they have to revoke a root cert that is on every device (revoking everyone's pictures), or they have to issue revocations on a per-photo basis (that doesn't scale).


• My associates and I have already identified easy ways to alter the timestamps, GPS information, and more. This includes ways that require no technical knowledge. The C2PA proponents will probably claim something like "The C2PA manifest don't protect that information!" Yeah, but tell that to the typical user who doesn't understand the technical details. They see a valid signature and assume the picture is valid.


• There's a physical dismantling (teardown) video on YouTube. At 12:27 - 12:47, you can see the cable for the front-facing camera. At 14:18 - 14:35 and 15:30 - 16:20, you can see how to replace the back-facing cameras. Both options provide a straightforward way for hardware hackers to feed in a false image signal for signing. With this device, the C2PA cryptographic signature excludes the metadata but covers the visual content. Unfortunately, you cannot inherently trust the signed image.


• Even if you assume that the hardware hasn't been modified, every picture has been tagged by Google as a composite image. That will impact insurance claims, legal evidence, and photo journalism. In fields where a composite image is not permitted, the Google Pixel 10 should not be used.

With Google's current implementation, their C2PA cryptographic signature is as reliable as signing a blank piece of paper. It doesn't protect the important information. But even if they fix their exclusion list, they are still vulnerable to C2PA's fundamental limitations. C2PA gives the appearance of authentication and provenance without providing any validation, and Google's flawed implementation just makes it worse. It's a snake oil solution that provides no meaningful information and no reliable assurances.

A lot of people are excited about the new Google Pixel 10. If you want a device that takes a pretty picture, then the Pixel 10 works. However, if you want to prove that you took the picture, value privacy, or plan to use the photos for proof or evidence, then absolutely avoid the Pixel 10. The cryptographic "proof" provided by the Pixel 10 is worse than having a device without a cryptographic signature. Every picture requires contacting Google, the unaltered metadata is inconsistent, the visual content is labeled as an AI-generated composite, the signed data may be post-dated, and there is no difference between an altered picture and an unaltered photo. I have honestly never encountered a device as untrustworthy as the Pixel 10.

Last month I released my big bulleted list of C2PA problems. Any one of these issues should make potential adopters think twice. But 27 pages? They should be running away!

Since then, my list has been discussed at the biweekly Provenance and Authenticity Standards Assessment Working Group (PASAWG). The PASAWG is working on an independent evaluation of C2PA. Myself and the other attendees are only there as resources. As resources, we're answering questions and discussing issues, but not doing their research. (We've had some intense discussions between the different attendees.) The PASAWG researchers have not yet disclosed their findings to the group, and as far as I can tell, they do not agree with me on every topic. (Good! It means my opinion is not biasing them!)

Full disclosure: The PASAWG meetings fall under Chatham House rules. That means I can mention the topics discussed, but not attribute the information to any specific person without permission. (I give myself permission to talk about my own comments.)

Clarifications

For the last few meetings, we have been going over topics related to my bulleted list, the associated issues, and clarifying what the C2PA specification really provides. Having said that, I have found nothing that makes me feel any need to update my big bulleted list, except maybe to add more issues to it. There are no inaccuracies or items needing correction. The 27 pages of issues are serious problems.

However, I do want to make a few clarifications.

First, I often refer to C2PA and CAI as "All Adobe All The Time". One of my big criticisms is that both C2PA and CAI seem to be Adobe-driven efforts with very little difference between Adobe, C2PA, and CAI. I still have that impression. However:

• The C2PA organization appears to be a weak coalition of large tech companies. Adobe is the primary driving force, and to my knowledge, there are no C2PA working groups that do not have any Adobe employee as the chair or co-chair. The only exception is the top-level C2PA organization -- it's chaired by a Microsoft employee who is surrounded by Adobe employees. I refer to their structure as a "weak coalition" because Adobe appears to be the primary driving force.


• The Content Authenticity Initiative (CAI) is not "looks like Adobe". No, it is Adobe. Owned, managed, operated, and all code is developed by Adobe employees as part of the Adobe corporation. When you visit the CAI's web site or Content Credentials web service, that's 100% Adobe.

It's the significant overlap of Adobe employees who are part of both C2PA and CAI that causes a lot of confusion. Even some of the Adobe employees mix up the attribution, but they are often corrected by other Adobe employees.

The second clarification comes from the roles of C2PA and CAI. C2PA only provides the specification; there is no implementation or code. CAI provides an implementation. My interpretation is that this is a blame game: if something is wrong, then the C2PA can blame the implementation for not following the specs, while the implementers can blame the specification for not being concise or for any oversights. (If something is broken, then both sides can readily blame the other rather than getting the problem fixed.)

The specifications dictate how the implementation should function. Unless there is a bug in the code, it's a specification issue and not a programming problem. For example, my sidecar swap exploit, which permits undetectable alterations of the visual image in a signed file, is made possible by the specification and not the implementation. The same goes for the new C2PA certificate conformance (which is defined but not implemented yet); choosing to use a new and untested CA management system is a risk from the spec and not the implementation.

The third clarification comes from "defined but not implemented yet". Because C2PA does not release any code, everything about their specification is theoretical. Moreover, the specification is usually 1-2 revisions ahead of any implementations. This makes it easy for C2PA to claim that something works since there are no implementation examples to the contrary. By the time there are implementations that demonstrate the issues, C2PA has moved on to newer requirements and seems to disregard previous findings. However, some of the specification's assumptions are grossly incorrect, such as relying on technologies that do not exist today. (More on that in a moment.)

New Changes: v2.2

The current specification, v2.2, came out a few months ago. Although my bulleted list was written based on v2.1 and earlier, the review was focused on v2.2. When I asked who supports v2.2, the only answer was "OpenAI". Great -- they're a signer. There are no tools that can fully validate v2.2 yet. But there is some partial support.

I've recently noticed that the Adobe/CAI Content Credentials web site no longer displays the embedded user attribution. For example, my Shmoocon forgery used to predominantly display the forged name of a Microsoft employee. However, last month they stopped displaying that. In fact, any pictures (not just my forgeries) that include a user ownership attribution are no longer displayed. This is because the Content Credentials web site is beginning to include some of the C2PA v2.2 specification's features. The feature? User's names are no longer trusted and are now no longer displayed.

That's right: all of those people who previously used C2PA to sign their names will no longer have their names displayed because their names are untrusted. (While the C2PA and Adobe/CAI organizations haven't said this, I think this is in direct response to some of my sample forgeries that included names.)

If you dive into the specifications, there's been a big change: C2PA v2.0 introduced the concepts of "gathered assertions" and "created assertions". However, these concepts were not clearly defined. By v2.2, these became a core requirement. Unfortunately, trying to figure out the purpose and definitions from the specs is as clear as mud. Fortunately, the differences were clarified at the PASAWG meetings. The risks and what can be trusted basically breaks down to gathered assertions, created assertions, trusted certificates, and reused certificates.

Risk #1: Gathered assertions
Gathered assertions cover any metadata or attribution that comes from an unvetted source, such as a user entering their name, copyright information, or even camera settings from unvetted devices. Because the information is unverified, it is explicitly untrusted.

When you see any information under a gathered assertion, it should be viewed skeptically. In effect, it's as reliable as existing standard metadata fields, like EXIF, IPTC, and XMP. (But if it's just as reliable as existing standards, then why do we need yet-another new way to store the same information?)

Risk #2: Created assertions
Created assertions are supposed to come from known-trusted and vetted hardware. (See the "C2PA Generator Product Security Requirements", section 6.1.2.) However, there is currently no such thing as trusted hardware. (There's one spec for some auto parts that describes a trusted camera sensor for the auto industry, but the specs are not publicly accessible. I can find no independent experts who have evaluated these trusted component specs, no devices use the specs right now, and it's definitely not available to general consumers. Until it's officially released, it's vaporware.) Since the GPS, time, camera sensor, etc. can all be forged or injected, none of these created assertions can be trusted.

This disparity between the specification's theoretical "created assertions" and reality creates a big gap in any C2PA implementation. The specs define the use of created assertions based on trusted hardware, but the reality is that there are no trusted hardware technologies available right now. Just consider the GPS sensor. Regardless of the device, it's going to connect to the board over I2C, UART, or some other publicly-known communication protocol. That means it's a straightforward hardware modification to provide false GPS information over the wire. But it can be easier than that! Apps can provide false GPS information to the C2PA signing app, while external devices can provide false GPS signals to the GPS receiver. Forging GPS information isn't even theoretical; the web site GPSwise shows real-time information (mostly in Europe) where GPS spoofing is occurring right now.



And that's just the GPS sensor. The same goes for the time on the device and the camera's sensor. A determined attacker with direct hardware access can always open the device, replace components (or splice traces), and forge the "trusted sensor" information. This means that the "created assertions" that denote what was photographed, when, and where can never be explicitly trusted.



Remember: Even if you trust your hardware, that doesn't help someone who receives the signed media. A C2PA implementation cannot verify that the hardware hasn't been tampered with, and the recipient cannot validate that trusted hardware was used.

Requiring hardware modifications does increase the level of technical difficulty needed to create a forgery. While your typical user cannot do this, it's not a deterrent for organized crime groups (insurance and medical fraud are billion-dollar-per-year industries), political influencers, propaganda generators, nation-states, or even determined individuals. A signed cat video on Tick Tack or Facegram may come from a legitimate source. However, if there is a legal outcome, political influence, money, or reputation on the line, then the signature should not be explicitly trusted even if it says that it used "trusted hardware".

Risk #3: Trusted Certificates
The C2PA specification uses a chain of X.509 certificates. Each certificate in the chain has two components: the cryptography (I have no issues with the cryptography) and the attribution about who owns each certificate. This attribution is a point of contention among the PASAWG attendees:

• Some attendees believe that, as long as the root is trusted and we trust that every link in the chain follows the defined procedure of validating users before issuing certificates, then we can trust the name in the certificate. This optimistic view assumes that everyone associated with every node in the chain was trustworthy. Having well-defined policies, transparency, and auditing can help increase this trust and mitigate any risks. In effect, you can trust the name in the cert.


• Other attendees, including myself, believe that trust attenuates as each new node in the chain is issued. In this pessimistic view, you can trust a chain of length "1" because it's the authoritative root. (We're assuming that the root certs are trusted. If that assumption is wrong, then nothing in C2PA works.) You can trust a length of "2" because the trusted root issued the first link. But every link in the chain beyond that cannot be fully trusted.

This pessimistic view even impacts web certificates. HTTPS gets around this trust attenuation by linking the last node in the chain back to the domain for validation. However, C2PA's certificates do not link back to anywhere. This means that we must trust that nobody in the chain made a mistake and that any mistakes are addressed quickly. ("Quickly" is a relative term. When WoSign and StartCom were found to be issuing unauthorized HTTPS certificates, it took years for them to be delisted as trusted CA services.)

In either case, you -- as the end user -- have no means to automatically validate the name in the signing certificate. You have to trust the signing chain.

As an explicit example, consider the HTTPS certificate used by TruePic's web site. (TruePic is a C2PA steering committee member). When you access their web site, their HTTPS connection currently uses a chain of three X.509 certificates:

1. The root certificate is attributed to the Internet Security Research Group (ISRG Root X1). I trust this top level root certificate because it's in the CCADB list that is included in every web browser. (To be in the CCADB, they had to go through a digital colonoscopy and come out clean.)


2. The second certificate is from Let's Encrypt. Specifically, ISRG Root X1 issued a certificate to Let's Encrypt's "R11" group. It's named in the cert. Since I trust Root X1, I assume that Root X1 did a thorough audit of Let's Encrypt before issuing the cert, so I trust Let's Encrypt's cert.


3. Let's Encrypt then issued a cert to "www.truepic.com". However, their vetting process is really not very sophisticated: if you can show control over the host's DNS entry or web server, then you get a cert. In this case, the certificate's common name (CN) doesn't even name the company -- it just includes the hostname. (This is because Let's Encrypt never asked for the actual company name.) There is also no company address, organization, or even a contact person. The certificate has minimum vetting and no reliable attribution. If we just stop here, then I wouldn't trust it.
   
   However, there's an extra field in the certificate that specifies the DNS name where the cert should come from. Since this field matches the hostname where I received the cert (www.truepic.com), I know it belongs there. That's the essential cross-validation and is the only reason the cert should be trusted. We can't trust the validation process because, really, there wasn't much validation. And we can't trust the attribution because it was set by the second-level issuer and contains whatever information they wanted to include.

With web-based X.509 certificates, there is that link back to the domain that provides the final validation step. In contrast, C2PA uses a different kind of X.509 certificate that lacks this final validation step. If the C2PA signing certificate chain is longer than two certificates, then the pessimistic view calls the certificate's attribution and vetting process into question. The basic question becomes: How much should you trust that attribution?

Risk #4: Reused Certificates
Most services do not have user-specific signing certificates. For example, every picture signed today by Adobe Firefly uses the same Adobe certificate. The same goes for Microsoft Designer (a Microsoft certificate), OpenAI (a certificate issued by TruePic), and every other system that currently uses C2PA.

The attribution in the signature identifies the product that was used, but not the user who created the media. It's like having "Nike" on your shoes or "Levi's" on your jeans -- it names the brand but doesn't identify the individual. Unless you pay to have your own personalized signing certificate, the signature is not distinct to you. This means that it doesn't help artists protect their works. (Saying that the painter used Golden acrylic paint with a brush by Winsor & Newton doesn't identify the artist.)

As an aside, a personalized signing certificate can cost $50-$300 per year. Given all of C2PA's problems, you're better off using the US Copyright Office. They offer group registration for photographers: $55 for 750 photos per year, and the protection lasts for 70 years beyond the creator's lifetime. This seems like a more cost-effective and reliable option than C2PA.

Missing Goals

Each of these risks with C2PA pose serious concerns. And this is before we get into manifest/sidecar manipulations to alter the visual content without detection, inserting false provenance information, competing valid signatures, reissuing signatures without mentioning changes, applying legitimate signatures to false media, etc. Each of these exploits are independent of the implementation, and are due to the specifications.

The C2PA documentation makes many false statements regarding what C2PA provides, including:

• Section 3, Core Principles: "Content Credentials provides a way to establish provenance of content."


• Section 5.1: "Helping consumers check the provenance of the media they are consuming."


• Section 5.2: "Enhancing clarity around provenance and edits for journalistic work."


• Section 5.3: "Offering publishers opportunities to improve their brand value." (Except that the end consumer cannot prove that it came from the publishers.)


• Section 5.4: "Providing quality data for indexer / platform content decisions."

This is not the entire list of goals. (I'm literally going section by section through their document.) Unfortunately, you cannot have reliable provenance without validation. C2PA lacks attribution validation so it cannot meet any of these goals. C2PA does not mitigate the risk from someone signing content as you, replacing your own attribution with a competing claim, or associating your valid media with false information (which is a great way to call your own legitimate attribution into question).

What Does C2PA Provide?

An independent report came out of the Netherlands last month that reviews C2PA and whether it can help "combat disinformation by ensuring the authenticity of reporting through digital certificates." (Basically, it's to see if C2PA is appropriate for use by media outlets.) This report was commissioned by NPO Innovatie (NPO), Media Campus NL, and Beeld & Geluid. The report is written in Dutch (Google Translate works well on it) and includes a summary in English. Their key findings (which they included with italics and bold):

C2PA is a representation of authenticity and provenance, but offers no guarantee of the truth or objectivity of the content itself, nor of the factual accuracy of the provenance claims within the manifest.

(Full disclosure: They interviewed many people for this report, including me. However, my opinions are not the dominant view in this report.)

C2PA does not provide trusted attribution information and it provides no means for the end recipient to automatically validate the attribution in the signing certificate. Moreover, the specifications depend on trusted hardware, even though there is no such thing as trusted hardware. This brings up a critical question: If you cannot rely on the information signed using C2PA, then what does C2PA provide?

My colleague, Shawn Masters, likens C2PA's signature to an "endorsement". Like in those political ads, "My name is <name>, and I approve this message." You, as the person watching the commercial, have no means to automatically validate that the entity mentioned in the promotion actually approved the message. (An example of this false attribution happened in New Hampshire in 2024, where a deep fake robocall pretended to be Joe Biden.) Moreover, the endorsement is based on a belief that the information is accurate, backed by the reputation of the endorser.

The same endorsement concept applies to C2PA: As the recipient of signed media, you have no means to automatically validate that the name in the signing cert actually represents the cert. The only things you know: (1) C2PA didn't validate the content, (2) C2PA didn't validate any gathered assertions, and (3) the signer believes the unverifiable created assertions are truthful. When it comes to authenticating media and determining provenance, we need a solution that provides more than "trust", "belief", and endorsements. What we need are verifiable facts, validation, provable attribution, and confirmation.

Today's online environment permits the easy manipulation and distribution of digital media, including images, videos, and audio files, which can lead to the spread of misinformation and erode trust. The media authentication problem refers to the challenge of verifying the authenticity and integrity of digital media.

For four years, I have been reviewing the solution offered by the Coalition for Content Provenance and Authenticity (C2PA). In each blog entry, I either focused on different types of exploits, exposed new vulnerabilities, or debunked demonstrations. You would think that, after nearly 30 blogs, that I would run out of new problems with it. And yet...

I'm not the only person evaluating C2PA. I know of three other organizations, four government groups, and a half dozen companies that are doing their own independent evaluations. I learned about these groups the easy way: they start with an online search, looking for issues with C2PA's solution, and Google returns my blog entries in the first few results. They reach out to me, we chat, and then they go on with their own investigations. (With my blog entries, it's not just me voicing an opinion. I include technical explanations and step-by-step demonstrations. It's hard to argue with a working exploit.) In every case, they already had their own concerns and suspicions, but nothing concrete. My working examples and detailed descriptions helped them solidify their concerns.

"I've got a little list."

Near the beginning of this year, a couple of different groups asked me if I had a list of the known issues with C2PA. At the time, I didn't. I have my own private notes and my various blog entries, but no formal list. I ended up going through everything and making a bulleted document of concerns, issues, and vulnerabilities. The initial list was 15 PAGES! That's 15 pages of bulleted items, with each bullet describing a different problem.

I had the paper reviewed by some technical peers. Based on their feedback, I changed some statements, elaborated on some details, added more exploits, and included lots of references. It grew to 22 pages.

I noticed that Google Docs defaulted to really wide margins. (I'm not sure why.) I shrank the margins to something reasonable. The reformatting made it a 20-page paper. Then I added more items that had been overlooked. Today, the paper is 27 pages long, including a one-page introduction, one-page conclusion, and some screenshots. (The bulleted list alone is about 24 pages.)

With blogs, you might not realize how much information is included over time. It wasn't until I saw over 20 pages of bulleted concerns -- strictly from public information in my blogs -- that I realized why I was so passionate about these concerns. It's not just one thing. It's issue after issue after issue!

The current paper is almost entirely a list of items previously mentioned in my blog. There are only a few bullets that are from my "future blog topics" list. (After four years, you'd think I'd run out of new concerns. Yet, I'm still not done. At what point should people realize that C2PA is Adobe's Edsel?)

Last week, C2PA, CAI, and IPTC held their "Content Authenticity Summit". Following this closed-door conference, I was contacted by some folks and asked if they could get a copy of my "C2PA issues" list. I decided that, if it's going to get a wider distribution, then I might as well make my paper public. Having said that, here's a link to the current paper:

C2PA Issues and Evaluation (public release, 2025-06-09)
If you have questions, comments, thoughts, think there is something that should be added, or see any errors, please let me know! I'm very open to updating the document based on feedback.

Organizing Content

There are many ways to organize this data, such as by risk level, functionality, technical vs. usability, etc. I decided to organize the document by root cause:

• Fundamental problems: Issues that cannot be fixed without a significant redesign.


• Poor design decisions: Issues that could be fixed if C2PA changed their approach. (However, C2PA has been very clear that they do not want to change these decisions.)


• Implementation issues: Bugs that could be fixed. (Many haven’t been fixed in years, but they are fixable with little or no undesirable side-effects.)

There are also topics that I am intentionally not including in the paper. These include:

• Severity. While I don't think there are many minor issues, I don't try to classify the severity. Why? Well, one company might think an issue is "critical" while another may argue that it is "severe" or "medium". Severity is subjective, based on your requirements. I think the paper provides enough detail for readers to make their own judgment call.


• Simple bugs. The existing code base is far from perfect, but I really wanted to focus only on the bugs due to the specifications or design decisions. Problems due to the specifications or policies impact every implementation and not one specific code base. However, the paper does include some complicated bugs, where addressing them will require a significant effort. (For example, c2patool has over 500 dependency packages, many of which are unvetted, include known vulnerabilities, and have not been patched in years.)


• Solutions. With few exceptions, I do not recommend possible solutions since I am in no position to fix their problems. There may be an undisclosed reason why C2PA, CAI, or Adobe does not want to implement a particular solution. The paper does include some solution discussions, when every solution I could think of just introduces more problems; sometimes developers work themselves into a corner, where there is no good solution.


• Alternatives. Except as limited examples, I intentionally avoid discussing alternative technologies. (And yes, there are some alternatives with their own trade-offs.) I want this paper to only be focused on C2PA.


• Wider ramifications. If C2PA is deployed in its current state, it can lead to incredibly serious problems. It would become the start of something with a massive domino effect. Rather than focusing on theoretical outcomes, the paper is directed toward immediate problems and direct effects.

Simply seeing a random list of problems can be overwhelming. I hope this type of organization makes it easier to absorb the information.

The Most Important Issue

While the first question I usually receive is "Do you have a list?", the second question is almost always "What is the most important issue?" Looking at the bulleted list, you might think it would be the misuse of X.509 for certificate management. I mean, lots of problems in the paper fall under that general topic. However, I think the bigger issue is the lack of validation. C2PA is completely based on 'trust':

• You trust that the name in the certificate represents the signer.


• You trust that the information in the file (visual content, metadata, timestamps, etc.) is legitimate and not misrepresented by the signer.


• You trust that the signer didn't alter any information related to the dependencies.


• You trust that the timestamps are accurate.

And the list goes on. C2PA provides authentication without validation and assumes that the signer is not intentionally malicious. However, if I trust the source of the media, then I don't need C2PA to tell me that I can trust it. And if I don't trust the signer, then nothing in C2PA helps increase the trustworthiness.

Alternatives

Following some of my initial critiques on my blog, representatives from C2PA and CAI (all Adobe employees) asked me for a video chat. (This was on December 13, 2023.) During the call, C2PA's chief architect became frustrated with my criticisms. He asked me if I could do better. A few weeks later, I created VIDA, which was later renamed to SEAL: the Secure Evidence Attribution Label. SEAL is still being actively developed, with some great additions coming soon. The additions include support for derivation references (simple provenance), support for offline cryptographic validation, and maybe even support for folks who don't have their own domains.

SEAL is a much simpler solution compared to C2PA. While C2PA tries to do a lot, it fails to do any of it properly. In contrast, SEAL focuses on one thing, and it does it incredibly well.

Just as I've been critical of C2PA, I've been looking at SEAL with the same critical view. (I want to know the problems!) I've had my technical peers also review SEAL. I instructed them to be brutal and hyper-critical. The result? Two pages of bullets (it's a 3 page PDF with an introduction). Moreover, almost every bullet is from the general problem of relying on DNS and networked time servers. (Everyone with a domain or time-based signing service has these problems; it's not just SEAL. If/when someone solves these problems, they will be solved for everyone, including SEAL.)

While I don't think the C2PA paper has many "minor" issues, I think all of SEAL's issues appear to be minor. For example, problems like domain squatting apply to anyone with a domain. It doesn't directly impact your own domain name, but could fool users who don't look too closely.

Here's the current draft of the SEAL Issues (2025-06-09 draft). Again, if you see anything wrong, missing, or just have questions or concerns, please let me know!

Independent Reviews

Both of these documents represent my own research and findings, with a few contributions from peers and associates. Other groups are doing their own research. I've shared earlier drafts of these lists with some of those other groups; most seem to use these lists as starting points for their own research. Having said that, I hope that these documents will help raise awareness of the risks associated with adopting new technologies without proper vetting.

I can't help but hum "I'm Got A Little List" from The Mikado whenever I work on these bullet points.

Today, FotoForensics turns 11 years old! When I first introduced FotoForensics, I didn't know if it would be used by anyone or even if the implementation would have problems with the load. (As I originally wrote, "I wonder how it will scale?") Today, it has received over 6,050,000 unique pictures (with over 800,000 in the last year) and it's in the top 80,000 of internet destinations (the exact position changes every few minutes, but it's around 80,000 right now). As far as scaling is concerned, it seems to be holding up well.

Science!

Even though the site is popular, there are always some people who wonder if it is "scientific" or if it really works. A quick search on Google Scholar turns up lots of scientific journal articles that discuss FotoForensics and Error Level Analysis. They all conclude that it does, in fact, work as advertised. Google Scholar returns over 400 results. Here is a random selection of examples:

• K., P. B. M., Singh, K., Pandey, S. S., & O'Kennedy, R. (2019). Identification of the forged images using image forensic tools. In Communication and computing systems: Proceedings of the 2nd International Conference on Communication and Computing Systems (ICCCS 2018), December 1-2, 2018, Gurgaon, India. essay, CRC Press.
  

  Abstract
  The contents of the digital images can be easily manipulated with image editing software like Adobe Photoshop, Pixelmator, Inkscape, Fireworks, etc. In real life applications, it is indispensable to check the authenticity of the digital images because forged images could deliver misleading information and messages to our community. Different tools have been developed to detect the forged images. In literature, there is no study which presents an insight into image forensic tools and their evaluation on the basis of different criteria. Therefore, to address this issue, we present an insight into digital image forensic tools; and evaluate it on the basis of 15 different parameters like “error level analysis”, “metadata analysis”, “JPEG luminance and chrominance data”, etc. For our experimental work, we choose “FotoForensics” tool to show the forged region in digital images; and JPEGsnoop tool has been used to extract the metadata of the images.



• Kageyama, K., Kumaki, T., Ogura, T., & Fujino, T. (2015). Digital image forensics using morphological pattern spectrum. Journal of Signal Processing, 19(4), 159–162. https://www.jstage.jst.go.jp/article/jsp/19/4/19_159/_article/-char/ja/


• Scheidt, N., Adda, M., Chateau, L., & Kutlu, Y. E. (2021). Forensic tools for IOT device investigations in regards to human trafficking. 2021 IEEE International Conference on Smart Internet of Things (SmartIoT). https://doi.org/10.1109/smartiot52359.2021.00010


• Almalki, S., Almalki, H., & Almansour, A. (2018, November). Detecting Deceptive Images in Online Content. In 2018 14th International Conference on Signal-Image Technology & Internet-Based Systems (SITIS) (pp. 380-386). IEEE. https://ieeexplore.ieee.org/abstract/document/8706216

This is nowhere near the complete list. I'm seeing dozens of journal articles every year. Some evaluate FotoForensics, some use it to support conclusions, and others treat it as a baseline for evaluating new techniques. Moreover, those are just the articles that talk about "FotoForensics". The number of journal articles is even higher if I search for "Error Level Analysis".

Legal Use

"Forensics" means "for use in a court of law." When it comes to understanding forensic tools, the courts use a few criteria to determine if the tool or expert witness is qualified. In the United States, the criteria varies by state, but it's usually either the Daubert standard (from Daubert v. Merrell Dow Pharmaceuticals Inc., 509 U.S. 579 (1993)) or the Frye standard (from Frye v. United States, 293 F. 1013 (D.C. Cir. 1923)). In either case, there are five criteria for determining if evidence and expert testimony should be considered or accepted by the court. I think FotoForensics addresses each of them to the extreme:

1. Has the theory or technique in question been tested?
   In the case of FotoForensics, every algorithm and technique has been tested. Both by myself and by other experts in the field. The public FotoForensics service has a commercial counterpart. Every single one of the commercial customers has relied on their own independent tests before regularly using the tools.


2. Has it has been subjected to peer review and publication?
   This is a definite yes. It has both formally and informally been repeatedly subjected to peer review. While the original algorithms were published in a conference white paper, subsequent publications include this blog, the training material at FotoForensics, and the more than 400 third-party book and journal publications. (It's not just me writing about it.)


3. Does it have known or potential error rates?
   The question of "error rate" has always been difficult to answer. Confidence intervals are part of a statistical hypothesis. The cryptographic hashes from the Digest analyzer are good examples here. We can compute the SHA1 hash of two pictures and determine the likelihood of a mismatch. With cryptographic hashes, different hash values means that there were different input data sets. The likelihood of a false-negative match, where two byte-per-byte identical files are marked as being different, is zero (0); it doesn't happen. However, two different files could generate the same SHA1 hash value. The computed odds are about 1 in 2¹⁶⁰ (a huge number). It drops to 2⁸⁰ if we incorporate the Birthday Paradox.
   
   (Not all cryptographic hashes are the same. MD5 is considered 'weak'. A collision can be forced in around 2¹⁸ tries, or about 1 in 262,144.)
   
   In contrast, ELA, Hidden Pixels, Metadata, and the other data extraction systems do not use not a statistical hypothesis. These tools work like a microscope. What are the false-positive and false-negative rates for a microscope? It's a trick question; a microscope does not have them. As with other non-statistical systems, a microscope only identifies artifacts. The tests are deterministic and repeatable. It is up to a human to identify possible scenarios that are consistent with the observations. The documentation at FotoForensics identifies the various caveats and issues, but the tools never draw a conclusion. It's up to the human expert to evaluate the results and draw a conclusion.
   
   Since the various caveats and corner-case conditions are identified, it meets this requirement.


4. Are there existing and maintained standards controlling its operation?
   Yes. Most of the algorithms are documented and fixed (have not changed in a decade). If there is an implementation error, then we perform updates (maintenance). And some of the dependent applications, like ExifTool for metadata extraction, are regularly updated for detecting more information. This meets the criteria.


5. Has it attracted widespread acceptance within a relevant scientific community?
   Absolutely yes. Both the public and commercial versions are regularly used across a wide range of communities: mass media, financial, legal, insurance, UFO photo analysis (don't laugh), sales verification (receipt fraud is a big problem), contest validation, and more.

The courts also like to see historical precedence. The tools used at FotoForensics have been repeatedly used in legal cases. Everything from child custody battles and human trafficking to insurance and banking fraud. (I'm not the only expert using these tools.)

One Oversight

In my original (February 2012) announcement, I voiced some concerns about making tools publicly available. I was primarily concerned about possible misuse and the risks from educating criminals.

As for the tool being misused: I addressed this by releasing tutorials and challenges. Based on my web logs, these are some of the most popular documents I've ever written. Shortly after FotoForensics went live, a few trollish people posted bogus analysis on a wide range of topics to social media sites (Reddit, Twitter, Facebook, etc.). Each claimed that FotoForensics supported their arguments. I knew I did something right when those bogus claims would immediately be corrected by people who saw and understood the tutorials. (I don't have to police the internet; the community is doing that all by themselves.)

With regards to criminal behavior, I went so far as to write:

From an ethical viewpoint, I don't think this site violates concerns about educating criminals since (1) I don't distribute code, (2) bad guys generally don't like to submit their content to remote servers for evaluation, and (3) with the tutorial, people have the option to learn how to use the tool and are not left with a push-button solution.

Boy, was I wrong. Bad guys do like to submit their content to remote systems for evaluation! The public FotoForensics service regularly sees people developing new fraud techniques. Because new techniques stand out, I can often identify their tools and methods before they have a chance to deploy (weaponize) it for widespread fraud. Often, I can develop automated detectors before they distribute their forgery software. Over the years, I've written about everything from fraudulent scientific publications and government-sponsored techniques to widespread passport forgeries and commercially-sponsored fraud from Bayer and AvtoVaz.

FotoForensics is hardly a deploy-once-and-done service. I'm constantly learning new things and regularly improving it. I'm very thankful to my friends, partners, various collaborators, and the public for over a decade of helpful feedback, assistance, and insights. This year, I especially want to thank my mental support group (including Bill, Bob, and Dave), my totally technical support group (Marc, Jim, Richard, Wendy, Troy, and everyone else), Joe, Joe, Joe, AXT, the Masters and their wandering slaves, Evil Neal, Loris, and The Boss. Their advice, support, assistance, and feedback has been invaluable. And most importantly, I want to thank the literally millions of people who have used FotoForensics and helped make it what it is today.

Last Saturday we hit a milestone at FotoForensics: 6 million unique pictures! I was really hoping that this achievement wouldn't be marred by porn so I could do a deep dive into it. (SPOILER ALERT: Not porn! Woo hoo!)

Here's the picture! It arrived on 2023-01-14 at 11:50:55 GMT:


I'm not big on following sports, celebrities, or pop culture, so I approached this picture with zero knowledge. The picture shows two women and a guy at some kind of club or restaurant. However, I don't know the people or the situation. This sounds like a great opportunity to do some image sleuthing. (Click on the picture to view it at FotoForensics.)

Side note: I'm writing this as a streaming flow of consciousness. I didn't gather the pictures or complete this investigation before I started writing.

Where to start? Metadata!

When evaluating a picture, it's always good to check the metadata. A camera-original picture will often include date, time, camera settings, and other information that can help track down the source. For example, an embedded time zone or region-specific device can provide a good guess about where the photo was taken. Similarly, many photo editors leave details in the metadata.

On the downside, many applications re-encode the image and strip out the source metadata. If the metadata was stripped, then there may be no camera or location information.

Unfortunately with this picture, there is no informative metadata. At minimum, this means that the picture has been resaved from some other photo.

The only interesting thing in the metadata is the ICC Profile. This specific profile is from Google and indicates that the picture was processed by an app -- either through an Android application or a Google service.

Hidden Pixels and Quality

JPEG encodes pixels using an 8x8 grid. If the image doesn't align with the grid, then there are hidden pixel along the right and bottom edges that pad out the image. This image size is 940x788 -- neither dimension is divisible by 8, so there are 4x4 hidden pixels. (940+4 = 944, which is divisible by 8. Similarly, 788+4 = 792 which is also dibisible by 8.) The encoded image is 944x792 pixels, but automatically cropped to 940x788 before being displayed.

Different applications use different approaches for filling the JPEG padding. Adobe uses a mirrored pattern than often produces a butterfly-wing shape on high-contrast curves. In contrast, libjpeg just repeats the last pixel value, creating a stretched effect. However, a lossless crop often leaves the original uncropped pixels. With this picture, there is a stretched pattern used for the padding. That's consistent with libjpeg and not an Adobe product.


Similarly, different applications use different encoding tables. The 'JPEG %' analyzer shows that this image was encoded as a JPEG at 92% using the JPEG Standard.

While this doesn't tell us who these people are, the results from the metadata, hidden pixels, and JPEG % are consistent: this was re-encoded using a standard JPEG library. (Google uses standard libraries.) This was not last saved using an Adobe product.

The final quality test is the error level analysis (ELA). ELA evaluates the compression quality. Bright colors indicates the areas that will change more during a JPEG re-encoding. You should compare similar surfaces, similar textures, and similar edges. Any inconsistencies, such as a flat surface that is at a different intensity from other flat surfaces, denotes an alteration.


With this picture, there are a couple of things that stand out:

• All of the flat, smooth surfaces are equally dark. The dark clothing, dark ceiling, and even the smooth skin. (No comment about any potential plastic surgery to remove wrinkles.) An image that is this dark -- and yet last encoded at a high quality like 92% -- means that it has been re-encoded multiple times.


• The areas with fine details (high frequencies), such as the lace, hair, and jewerly, are very high quality. This could be due to someone dramatically scaling the picture smaller, but it also could be due to selectively editing. Someone likely touched up the faces and hair. In addition, Adobe products can boost high frequency regions. While this was not last processed by an Adobe product, the second-to-last processing could have been with an Adobe product.

If we can find the original picture, then I'd expect the people to not be as brightly lit or crisp; they appear to be selectively touched up. I also would expect to find an Adobe application, like Photoshop or Lightroom.

External Sources

Back in 2016, I wrote about different search-by-picture systems. FotoForensics includes quick links for sending the pictures to TinEye, Google Image Search, and Bing Image Search. These might find different web sites that host similar pictures. If they find any, then it can provide context.

Google's image search has undergone many changes. Prior to 2015, it was really good at finding variations of the same picture. Then they changed it to a system that uses AI to identify the content and shows you similar content. (In my 2016 example, I used a photo of Brad Pitt. Google's AI identified 'Brad Pitt' as the key term and returned lots of different photos of Brad Pitt, but none of the same photo.) Last year, Google replaced their system with Google Lens. According to Google Lens, this photo visually matches "Boys Tails Tuxedo with Cummerbund" from Walmart. (It's not even the same tux! And he doesn't have a cummerbund!)


At the top of the image in Google Lens is a button that says "Find image source". This does the type of "find similar picture" search that I want. Google associated the picture with the name "Lisa Marie Presley" and found news articles that included variations of the picture. For example, People Magazine has an article from last week titled, "Lisa Marie Presley, Daughter of Elvis and Priscilla, Dead at 54: 'The Most Strong and Loving Woman'". (Oddly, People put this in the "Entertainment" category. Do they think people's deaths are entertainment?) People's article included this picture:


The metadata includes a caption: "Priscilla Presley, Austin Butler and Lisa Marie Presley at the Golden Globes on Jan. 10, 2023. Shutterstock for HFPA". Now we know the who, where, and when. We can also see that this picture is vertically taller and contains more content. However, the image's URL shows that it was also post-processed by People's web site:

https://people.com/thmb/K08A8Ur6jWci4DJwdFzNT-vlzxg=/1500x0/filters:no_upscale():max_bytes(150000):strip_icc():focal(924x19:926x21):format(webp)/Lisa-Marie-Presley-Hospitalized-after-Cardiac-Arrest-011223-5512728ae3084977bd9eb9e0001c3411.jpg

In order to serve this picture, their web server:

• Stripped out any ICC Profile information. (The "strip_icc()" parameter.)


• Selected a focal point. ("focal(924x19:926x21)")


• Converted the file format to webp (dropping all JPEG metadata; "format(webp)").


• Used variable compression to ensure the file size is no longer than 150,000 bytes ("max_bytes(150000)"). The resulting webp is 136,214 bytes.

However, these alterations imply that there is another source image out there somewhere that isn't altered.

Bing Image Search worked similarly to Google Lens. However, instead of identifying clothing, it identified the people. Oddly, when I first ran this test last night, it only identified Austin Butler and Priscilla Presley. Today (as I proofread my writing), it also identifies Lisa Marie Presley.

TinEye was more interesting. It didn't just find the picture, it found an expanded version of the picture at The Daily Mail! If you scroll past all of the disturbing paparazzi photos, you'll eventually find this image:


The picture is annotated with credits at the bottom and scaled very small; there's no original metadata. The only informative metadata says "Copyright Shutterstock 2023;121266844;5372;4000;1673420322096;Wed, 11 Jan 2023 06:58:42 GMT;0". However, this version is wider, showing another man in the photo! Who's he? The movie Elvis won an award at the Golden Globes. Priscilla and Lisa Marie are the real Elvis's wife/widow and daughter. The tall man in the middle is Austin Butler, who won Best Actor for his role as Elvis in the movie. The man who was cropped out is the movie's director, Mark Anthony "Baz" Luhrmann, who didn't win his nomination. (They cropped him out! Oh, the burn!)

You might also notice that the faces and hair are not as bright as the 6 millionth image. This version of the picture is darker. (The photo was likely taken in a room with bad lighting.)

Bigger Version?

I found another version of the picture at US Magazine.


This is a large image distributed by Shutterstock. It's not original, but it's much closer than my starting point.

• The metadata says it was processed by Adobe Photoshop 2022 on a Mac.


• There are still hidden pixels (not the original dimensions) and they show padding that is consistent with Adobe's butterfly pattern.


• The JPEG quantization tables (JPEG %) are consistent with Adobe Save-for-Web quality 100 (equivalent to 99%).


• ELA shows that the faces and hair of Austin, Lisa Marie, and Baz were selectively touched up. Priscilla's eyes appear touched up, but not her face.
  

Interestingly, even though this picture was touched up, the faces are visually darker and not as digitally sharpened compared to the previous versions. This picture shows edits, while the previous versions are edits on top of edits.

The Shutterstock ID "13707319l" finds the source picture's sale page: https://www.shutterstock.com/editorial/image-editorial/13707319l. (They list it as "Editorial" and not "Entertainment".) According to them, the largest size should be 5372x4000 pixels.

Much Closer!

I ended up finding the 5372x4000 picture at Closure Weekly. The URL is https://www.closerweekly.com/wp-content/uploads/2023/01/Lisa-Marie-Presley-Then-and-Now-Elvis-Daughter-Over-the-Years-.jpg. However, depending on your web browser, their web server may return a JPEG or WebP file. My Firefox web browser could only download the WebP version, but FotoForensics was able to retrieve the JPEG. The WebP lacks any informative metadata, but the JPEG has everything that was provided by Shutterstock.


The metadata still doesn't identify the type of camera. The annotated metadata was added using ExifTool 10.80. (ExifTool 10.80 is a production release that came out on 2018-02-22. Shutterstock really should update to get the latest patches.) The embedded information still identifies the people, but also includes the location!

Mandatory Credit: Photo by Shutterstock for HFPA (13707319l)..Priscilla Presley, Austin Butler, Lisa Marie Presley and Baz Luhrmann..80th Annual Golden Globe Awards, Inside, Beverly Hilton, Los Angeles, USA - 10 Jan 2023

(I find it interesting that none of the other photos include this "mandatory" credit.)

The ELA is also interesting -- it's almost entirely dark. That indicates a resave but no significant alterations.


With this version, there is no indication of selective editing to the faces. Visually, the faces are even darker (bad lighting) than the previous version. If you look at the full size picture, you can see that everyone has acne, freckles, pores, and other human features that were removed by the selective edits.

Now we know the history of this 6 millionth image:

1. The Golden Globe Awards were held on 10 Jan 2023 at the Beverly Hilton in Los Angeles. (Technically, it's in a suburb called Beverly Hills). Priscilla Presley, Austin Butler, Lisa Marie Presley, and Baz Luhrmann posed for a photo at around 8:24pm (local time, according to the metadata). That same evening, Austin Butler won Best Actor for his role in the movie Elvis.


2. A photo was taken of the ensemble. The metadata does not identify the photographer or the type of camera.


3. The photo was sent to Shutterstock, where it was re-encoded (resaved) and metadata was added using a five-year-old version of ExifTool.


4. The Shutterstock image went to a media outlet (like US Magazine), where the faces were selectively touched up using an Adobe application.


5. The touched up version was then cropped on the right to remove Baz (maybe because he didn't win). Their faces were further brightened up and digitally smoothed out.


6. The cropped version was further cropped (bottom, left, right, and top) with some kind of Google application. The cropping focused the content on the three people.


7. Then the picture was uploaded to FotoForensics.

I'm certain that the source image used by the media came from Shutterstock (or related company owned by Shutterstock). However, I don't know if the picture went from Shutterstock to Closure Weekly to US Magazine to The Daily Mail to People to somewhere else before ending up at FotoForensics, or whether it took some alternate path. In addition, different media outlets may have applied similar brightness and sharpening edits; these may be branches of variations and not a linear chain of edits. However, given the similarities in cropping, nested edits, and handling artifacts, I don't think the final version took a much shorter path.

The picture originally had limited circulation since it was only associated with the Golden Globes. However, two days later, Lisa Marie Presley was hospitalized and then died. This picture received a resurgence in reporting and viral dissemination because it was taken shortly before her death.

When I first started FotoForensics (back in 2012), I was thrilled to see it receiving a few hundred pictures per day. These days, it receives over a thousand a day (and some days with over 10,000). Excluding two network outages, the last time it received fewer than 1000 pictures in a single day was 2016-12-31. (Dec 31 is always a very slow day, weekends are usually slower, and Dec 31 on a weekend? Only 818 uploads.) Still, six million pictures is quite a milestone. And every one of those pictures has some kind of story behind it.

I recently received requests from two different people who wanted help with their FotoForensics apps. It seems that their apps stopped working.

I do not provide a "FotoForensics app". Over the last decade, I have identified over a half-dozen knock-off apps that claimed to be "FotoForensics". These fake apps fall into 3 basic categories:

• Malware. A few of the knock-offs install viruses on the user's device. They just reuse a good product's name in order to lure the victim into installing the software. If the application is not from the official vendor, then assume it is malicious.


• Ads. Some of these knock-offs just wrapped my web service in their own application. This way, they can show ads and collect revenue from views and clicks. (I never see a penny of it, but my servers do all of the work.) My sites do not have ads. If you ever see an ad when viewing FotoForensics, this blog, RootAbout, Hintfo, or any of my other services, then your device is likely infected with adware or some other kind of unwanted application. I don't use ads.


• Theft. One knock-off just wanted to use my service's name for their app. Basically, he wanted to hijack the name recognition. (Apple gave them 24 hours to change their apps name or be kicked out of Apple's app store.)

When I learn of these knock-offs, I have them pulled from the Apple and Android stores. I also look for their application signatures on my site. If I detect an unauthorized app, I block access and return some kind of nasty notice.

Last month, I blocked another unofficial app. These users had likely installed something with adware and malware.

Why no app?

For other projects (including some research-only testing), I've made everything from Apple-specific apps using Swift to cross-platform apps using Flutter and Progressive Web Apps (PWA). (Personally, I found PWAs to be the easiest to build.) It isn't that I don't know how to build an app. Rather, it's that I understand the limitations. Some things just don't work well in apps and FotoForensics is one of them.

With any kind of forensic analysis, you want consistent results. If you run a test on your computer and your friend runs the same test on his computer, then both computers should show the exact same results. If everyone runs the same software, then we all get the same result. However, different libraries sometimes do different things. For example, in 2014 I mentioned that I use the old libjpeg6b (with patches) for image analysis. This is because the newer libjpeg8 does something "more than JPEG". You won't get the same results from a forensic test with libjpeg8 and the differences from libjpeg8 are not part of the JPEG Standard.

For my tools, I make no assumption about which image library you use. FotoForensics does the processing on the server side (using consistent libraries) and then shows the results in the web browser. The results are always PNG files, so I don't have to worry the client's JPEG library version. I also remove any ICC color profile information in order to mitigate any color shifting by the web client.

Inconsistent JPEG Libraries

Whenever someone talks to me about creating an app for FotoForensics, I channel my inner Edna Mode: "No apps!"

Error Level Analysis (ELA) might seem like a really simple algorithm. You load a JPEG, save it at a known quality level (e.g., 75%), and then see how much it changed. However, ELA is very dependent on the JPEG library. Different JPEG libraries implement things just a little differently. libjpeg6b is different from libjpeg8, libjpeg-turbo, Microsoft's JPEG library, Apple's JPEG library, etc.

Many years ago, I create a small "corrupt JPEG" test file that demonstrates these rendering differences. While this JPEG is intentionally corrupted, it's not bad enough to prevent any JPEG library from rendering it. The thing is, every JPEG library renders it differently.

Here's the test image. The different color blobs that you see will depend on your web browser:


I've been using this image for years to profile the underlying JPEG libraries. Depending on what is rendered, I can determine exactly which JPEG library and version some application is running.

For example:

	libjpeg6b (follows the JPEG Standard)
	libjpeg8. It may start the same as libjpeg6b, but bottom half is very different.
	libjpeg-turbo (2.1.3 or earlier); Microsoft Edge and older Chrome and Firefox browsers.
	libjpeg-turbo (2.1.4 or later); current Chrome and Firefox browsers. It might look similar to the previous libjpeg-turbo, but there is a little difference:
	libjpeg-turbo 2.1.4, but using Firefox on a Mac. The colors are a little different.
	Apple's library used by Safari (desktop) and iOS browsers (Mobile Safari, Mobile Chrome, and Mobile Firefox -- on an iPhone or iPad) is the only one that just gave up. (Of all of the libraries, this is probably the correct solution when encountering a corruption.)
	I need to dig into Mastodon and see what they use for re-encoding images. It looks like the default Windows 10 library.

This isn't the entire list. Older Androids used a different library than current Androids. Windows 7 is different from Windows 8 is different from Windows 10, etc.

It's not good science if the results cannot be reproduced by someone else. You don't want to do media forensics on any device where the results can vary based on some unspecified library version. This is why I don't have an app. If I provided an app, it would need to be massive in order to include all of the known, trusted, and vetted libraries. Instead, I use a web interface and have the server perform the evaluation. The FotoForensics web site provides consistent results regardless of your web browser.

Unnecessary Apps

There are many different types of apps that you should never install. These includes redundant functionality apps (flashlights, keyboards, etc.) that duplicate existing functionality while requiring invasive access to your device, customer loyalty apps that are really nothing more than a front for deep user-tracking, and ineffective apps. For example, most anti-virus apps are ineffective due to localized sandboxing and may actually be trojan malware.

In addition, there are some apps that really should make you wonder: why does it need to be an app? For example, do you really need an app for your coffee maker or washing machine? Then again, I'm opposed to apps that disable the house alarm and unlock the front door. (Lose your phone, lose you home.) Beyond the physical, there are some impressive apps for making fake photos. Fake images for fun is one thing, but some of these apps seem clearly designed for people interested in committing insurance and banking fraud. Do we really need to make crime easier?

Finally, there are some things that should not be apps for various technical reasons. Kim Rust wrote a great list of technical reasons why you shouldn't build an app. The list includes insufficient resources (time, money, engineering effort) to support the app and apps that provide minimal functionality. Her reason #4 really matches my concerns: "Don't Build an App When it provides no improvement upon your mobile website".

Over at FotoForensics, we see pictures that are related to scientific journals almost daily. These stand out because they are not your common social media, celebrity, or conspiracy images that we typically receive. We often see photos of cells, western blots, gel assays, things growing in petri dishes, and related results from science experiments. Sometimes these images come from people who are trying to validate the authenticity of the images, while other times the pictures seem to come from researchers who are intentionally making altered images.

Just Flesh and Blood

Fraud in scientific publications is a serious problem. This includes the widespread use of altered pictures in journal papers. The alterations may be simple, like copying the same picture and claiming it is from different experiments. However, they can also include editing, creative cropping, or "touching up" photos. The wholesale fabrication of "proof" pictures is also becoming more common. (And this is before we get to outright plagiarism.)

When this fraud is discovered, the journals sometimes issue retractions. However, any retraction can be too late. Subsequent research papers may continue to cite the previously retracted articles.

Sometimes these retractions are associated with a bunch of papers from one set of researchers, while other times it is a systemic problem within a particular research field. For example, the NIH identified four anaesthesiologists who had articles retracted due to "research misconduct". Some of their articles had been retracted, while others had not. (One of the authors, Yoshitaka Fujii, tops the leaderboard at Retraction Watch. They note that he has had 183 total article retractions.)

Back in 2014, RIKEN (a Japanese institute) began investigating over 20,000 papers for doctored images and plagiarism. During that same time, FotoForensics began to receive a large number of altered cell photos. Here's a small sample that were uploaded by someone at the Research Organization of Information and Systems, National Institute of Informatics in Japan:



Most of the pictures show cells and nearly all were digitally altered. Looking at the sequence of preview images, you might notice the same cells in the same positions but with more cells appearing in subsequent photo uploads. For example, here's one of the images:



With a little experience, you can probably tell that these are cells photographed through a microscope. With a some biology background, you might be able to tell that they are blood cells. With a lot of advanced education, you might be able to tell that these are fish blood cells.

At FotoForensics, we don't need marine biology lessons to know that something's fishy. It's faint, but FotoForensics shows the boxes around every cell that was pasted into the picture:



The commercial FotoForensics service includes more ways to highlight the alterations. (Ignore the colors; just focus on the edges of the colored regions.)



This one example is from the series of cell pictures where the "researcher" continually added cells and adjusted their positions in the picture. However, even without the sequence of images, advanced tools permit detecting the alterations from a single picture. These are not artifacts from some background lighting. This is a composite image where someone tried to blend the different cells into one picture.

Not What Teacher Said To Do

It's not just photos of cells. It's all sorts of sciency things. For example, these types of "western blot" images are common among the molecular biology community. These show dark lines where different chemical compounds cluster.


These examples are 2 of 56 pictures that were uploaded to FotoForensics in 2014 from someone associated with the University of Illinois in Urbana-Champaign. (The first four came from a Chinese research paper. The remaining 52 appear to be different revisions of alterations.) In these two examples, someone first pasted six dark lines into the gray background, then they tried to digitally erase three of the lines. In both cases, the annotation (2-T) and the hairline scratch below the annotation were added after the rest of the picture had been created.

The Magic from the Hand

While lots of different people upload science test images to FotoForensics, the people who do bulk uploading really stand out. (Bulk uploading is a violation of the public site's terms of service.)

A week ago, a user in India uploaded dozens of photos showing cultures in petri dishes. Many of the pictures were variations of base images, showing iterations and development cycles for the alteration process. The user appears to have been trying to develop a process that would avoid detection at the public FotoForensics service. Here are two of the base images that the user uploaded:


The first image shows five dark dots in a petri dish. Error level analysis (ELA) evaluates the image's compression artifacts. In this case, ELA highlights where the user erased some of the petri dish's contents. Because of how it was erased, I cannot tell you whether the person only erased around the five dots, or if the five dots were each pasted into the image before the erasure. The second picture has four crystals pasted into the image. I think that they're trying to show that the crystals repel the cultures, but the only thing repellent is their use of PicsArt for their scientific imagery.

Magic and Technology

These types of scientific publication alterations are not limited to biology. Since September, a user in China has uploaded hundreds of pictures of solar panel test results. (So many pictures, that we created a special auto-ban rule just for him.) A few of his pictures are unaltered, but many of them are modified. Here's just one (of over a hundred) examples:


The picture contains tiny gray squares of photovoltaic (PV) elements. The PV elements are arranged in small rectangular blocks. Each set of 12x6 blocks are organized into panels, and there are two panels per picture. (That's a lot of science!)

Using ELA, you might notice the lens effects. These are patterns created by a digital camera. This one picture is a composite made from small photos that were then captured in rows of blocks by a digital camera, leaving the camera's lens effect signatures. Each row of blocks was cropped and combined to form the final composite. After all of the compositing, someone replicated elements in the 2nd row in order to digitally alter the results. (The alteration distorts the ELA's lens effect patterns.)


But the alterations don't stop there. Some of FotoForensics' commercial tools highlight other edits. This example highlights the 1st and 9th elements on the first row, and 6 blocks on the 2nd row.


Considering that China dominates the world's supply of solar panels, it makes sense that someone might want to fake their test results in order to justify cost cutting methods or ways to manufacture inferior products. (But the products look great in the "test results"!)

As an aside, one of my associates speculated that these could be training images for an AI-based solar panel quality control system. Other researchers have papers that demonstrate this type of AI detection. (E.g. PDF1 and PDF2) However, we ruled that out since the time codes at the bottom of the chinese pictures shows them being produced at a slow rate (at most, a few per day). AI researchers would mass-produce training images at a much faster rate.

Diagrams and Charts

There has been a growing movement of anti-alteration researchers who want to identify altered imagery in journal papers. There problem is, most of the uploads to FotoForensics are not as easy to evaluate as the previous examples. Instead, we usually see complex pictures like these two examples:


Both of these examples were received within the last week, and they were uploaded by different people. These pictures are very representative of the scientific images received by FotoForensics almost daily for over a decade. The problems with analyzing these pictures are numerous:

• PDF. Most of these pictures come from published (or pre-published) journal articles. That means they are already converted to PDF. PDF files typically strip out the image's metadata, re-encode the image at a low quality, and scale the image to fit the space on the page. Moreover, they are often converted to grayscale. (Few journals publish in color.)
  
  For image analysis, it's all about how the evidence was handled. I typically use the analogy that evaluating an image is like trying to pull fingerprints off of a drinking glass. With a PDF, it's like running the glass through the dishwasher twice before trying to pull off any fingerprints. I can detect the encoding patterns used by most PDF encoders. But what happened before it was crammed into the PDF? That information is likely gone.


• Extractions. Making matters worse, how do you get the image out of the PDF? A lot of amateur sleuths just take a screenshot of the PDF page that is rendered on the screen. I can tell you about the tool that took the screenshot, but that doesn't tell you whether the science experiment's results were altered. However, even if you correctly extract the image (use pdfimages with -j to avoid any additional format conversions), you're still left with a picture that has been grossly abused by the PDF encoder.


• Annotations. Part of the scientific process is to communicate findings. I don't fault scientists for annotating their images. The problem is that the annotations are an edit to the picture and usually added last. If there was a misleading alteration in the scientific findings, the artifacts from those edits may have been obliterated when the image was annotated and formatted for publication.


• Composites. Along with annotations, it's common to see cut-and-paste results placed side-by-site. This is usually done for readability (a side-by-side comparison of results). However, the composite side-by-side image is still an edit that can distort or remove trace artifacts that would have identified other types of manipulations.


• Grayscale renderings. Assuming you get the pre-PDF image without annotations, you might still not have a "photo". For example:
  
  
  
  
  This one picture is a composite made from six separate images. It also includes annotations. However, each of those six pictures are not from a typical "photo". Instead, they appear to be from grayscale renderings of medical scans that were digitally colorized (and likely scaled and cropped). None of this is unusual in scientific papers, and it doesn't represent any intentional deception. However, the combination of a grayscale scan that was colorized, scaled, and cropped, plus the annotations and composition, makes it extremely difficult to tell if any of the original six scans were digitally altered.

A lot of amateur sleuths just rely on their eyes. And don't get me wrong, this can be extremely useful for spotting reused pictures or obvious alterations. With the right kind of science background, an experience molecular biologist might see something wrong in the experiment results.


However, I'm not a biologist. As a non-biologist who only relies on image analysis, I cannot evaluate these images and conclusively determine that the blank regions in these western blots from FOXO3a and p-ATM were digitally altered. For me, they are suspect but not conclusive due to the image's handling.

Bits and Pieces and, Bits and Pieces, Weird Science!

I periodiclly see articles about scientific imagery sleuths who spot image manipulation. Many have been successful in having pre-publication articles rejected and published works retracted. I've also seen reviews about tools like SILA, which tries to evaluate images from PDF documents. However, like most scientific papers, they only discuss the corner cases where it works. For example, SILA doesn't mention the problems with grayscale imagery, cropping or scaling, or the impact from annotations. It also uses a copy-clone algorithm which has limitations related to the image's resolution and false positives from similar imagery. At a small enough resolution, the edges along most western blot images should look like a copy-clone, even if they are not. (When I teach people how to do image analysis, I always provide some examples that are not obvious or definitive. An analyst should always consider the likelihood of other options and be willing to accept "inconclusive" or "I don't know" as viable results.)

Ideally, the publications should request full-sized unedited versions of any imagery for pre-publication analysis. However as far as I can tell, they do not. Then again, I doubt that they have the staff necessary to evaluate the media that they receive. Moreover, there is the arms race problem that is common to all types of image analysis tools: if the tools were shared beyond the publication's forensic analysts, then unscrupulous researchers could start testing their fraud techniques against the tools. Eventually they will make something that the tools cannot detect.

But let's assume that we have the pre-edited imagery and the tools (and ignore the arms race problem). Then we'll spot all of the problems and alterations, right? Well, not every alteration is as clear-cut as the examples in the beginning of this blog entry. There's a recent paper from PNAS titled, "Observing many researchers using the same data and hypothesis reveals a hidden universe of uncertainty" by Nate Breznau, Eike Mark Rinke, Alexander Wuttke, and Tomasz Żółtak, who conducted a fascinating experiment. They gave the same complex data to "seventy-three independent research teams". None of the teams reached the same conclusion about the data. As their paper concluded, "Considering this variation, scientists, especially those working with the complexities of human societies and behavior, should exercise humility and strive to better account for the uncertainty in their work."

(Huge thanks to Oingo Boingo for their album Dead Man's Party, including their song "Weird Science", which felt oddly appropriate for this topic.)