Skip to content

Instantly share code, notes, and snippets.

@n8fr8

n8fr8/gist:9620ad08755f44fdc8f6eac80102ed05

Created April 26, 2026 20:58
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save n8fr8/9620ad08755f44fdc8f6eac80102ed05 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save n8fr8/9620ad08755f44fdc8f6eac80102ed05 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
Claude finished the response
1748635752784.jpg
You are a digital media forensics analyst specializing in content provenance, authenticity verification, and chain-of-custody analysis. Analyze the attached ProofCheck report for a media file and produce a structured forensic assessment. Your analysis should cover the following areas, in order: 1.
pasted
4:53 PM
Claude responded: Forensic Analysis: ProofCheck Report for 1748635752784.
Forensic Analysis: ProofCheck Report for 1748635752784.jpg
1. File Identity & Hash Verification
The file is 1748635752784.jpg, a JPEG image identified by the SHA-256 hash 2a8b24e75f135df8da8060c5cac5baf21c7429f81848bd68db522db183b4d9ca. SHA-256 is a cryptographically strong hash algorithm; barring a preimage collision (practically infeasible), this hash serves as a reliable unique content identifier. The same hash appears consistently across the ProofMode metadata, the C2PA manifest's data hash assertion, and the OpenTimestamps commitment, which is an important sign of internal consistency — the file has not been altered after these records were created.
2. Capture Device & Sensor Analysis
The claimed device is a Google Pixel 9, manufactured by Google. This identification is consistent across four independent metadata sources: the ProofMode device record, the EXIF Make/Model fields, the C2PA EXIF assertion (tiff:Make: Google, tiff:Model: Pixel 9), and the ICC profile (Device Manufacturer: GOOG). The device record also notes a screen size of ~5.79 inches, consistent with the Pixel 9's actual display.
The camera parameters are as follows: focal length 6.9mm, aperture f/1.68, ISO 45, exposure time ~1/120s, auto white balance, flash not fired. The Pixel 9's primary wide camera has a 6.9mm equivalent focal length and an f/1.68 aperture, so these values align precisely with the known hardware specifications. The ISO 45 and 1/120s exposure suggest a well-lit indoor scene, which is consistent with what the image actually shows — a daylit room with a window providing natural light. There are no inconsistencies between the claimed device and the sensor data.
The image resolution is 4080×3072 pixels (approximately 12.5 megapixels). The Pixel 9's main sensor is a 50MP sensor that typically bins down to 12.5MP for standard photos, which matches exactly.
The EXIF orientation tag is 6 (row 0 at right, column 0 at top), indicating the phone was held in portrait orientation — consistent with the vertical framing of the image.
3. Temporal Analysis
Multiple timestamps are available, and their consistency is worth examining carefully:
EXIF DateTimeOriginal: 2025-05-30 16:09:12 (UTC-04:00), with sub-second precision of 855751 (microseconds)
EXIF DateTime: 2025-05-30 16:09:12 (same local time)
C2PA GPS timestamp: 2025-05-30 20:09:13 GMT (which equals 16:09:13 EDT — one second after the EXIF capture time, expected given processing delay)
C2PA signature time: 2025-05-30T20:09:14+00:00 (16:09:14 EDT — two seconds after capture)
ProofMode file creation: 2025-05-30T16:09:15.288Z — this is labeled "Z" (UTC), but the value 16:09:15 is actually the local EDT time, three seconds after capture. This is likely a timezone labeling artifact in ProofMode's output rather than a genuine four-hour discrepancy; the alternative interpretation — that the file was created at 16:09 UTC (12:09 EDT) and then signed four hours later — is inconsistent with all other timestamps clustering within seconds.
GPS location timestamp: 1748632844585 (Unix milliseconds) = 2025-05-30T19:20:44 UTC = 15:20:44 EDT, approximately 49 minutes before capture.
The GPS timestamp being ~49 minutes stale is notable but not alarming. The location provider is listed as "network" (cell tower/WiFi-based, not GPS satellite), and Android caches network location fixes. If the device was stationary indoors (as the image suggests — someone sitting at a desk), the system would not necessarily refresh the location fix. The 20.6m accuracy figure is typical for network-based positioning.
The capture-to-signing pipeline spans roughly 2 seconds (capture at :12, signature at :14), which is consistent with automated on-device processing by ProofMode. There are no suspicious temporal gaps.
The offset time fields consistently report UTC-04:00 (Eastern Daylight Time), which is consistent with the GPS coordinates placing the device in the Boston, Massachusetts area.
4. C2PA Manifest & Cryptographic Integrity
The file contains a single C2PA manifest with the claim generator identified as org.witness.proofmode.ProofModeApp/2.6.0-BETA-1 c2pa-rs/0.39.0. This tells us the manifest was created by ProofMode version 2.6.0 (beta), using the Rust C2PA library version 0.39.0.
Signature details: The manifest is signed using ES256 (ECDSA with P-256 and SHA-256), a standard and well-regarded algorithm for content credentials. The signer is identified as ProofMode-User-0x4de561d3c44a5905, with the signing time countersigned by DigiCert Timestamp 2024.
Assertion hash validations: All 13 hashed URI assertions passed validation, including the claim thumbnail, ingredient thumbnail, ingredient reference, actions, all four permissions assertions, both CreativeWork metadata assertions, the EXIF assertion, and critically the data hash. The data hash match confirms the image pixel data has not been modified since signing.
Validation failures: There is one failure — signingCredential.untrusted. This means the signing certificate is not anchored to a recognized institutional trust list (like the C2PA Trust List maintained by the Content Authenticity Initiative). This is expected and benign for ProofMode: it generates per-user self-signed certificates tied to a PGP identity rather than purchasing certificates from a commercial certificate authority. This is a structural characteristic of ProofMode's trust model, not evidence of tampering.
Timestamp validation: The DigiCert timestamp is both validated (the digest matches) and trusted (DigiCert is on recognized trust lists). This provides a strong external anchor proving the signature existed at the claimed time, even though the signing credential itself is self-issued.
5. Trust Chain Assessment
The signing credential is self-issued by ProofMode under the identity ProofMode-User-0x4de561d3c44a5905. This is not an institutionally-trusted credential — no certificate authority has vouched for this signer's real-world identity. However, ProofMode provides an alternative verification path:
The C2PA manifest includes two stds.schema-org.CreativeWork assertions. The first identifies the author by the PGP key fingerprint 0x4de561d3c44a5905 with a reference to keys.openpgp.org. The second provides a direct lookup URL: https://keys.openpgp.org/search?q=4de561d3c44a5905. This means anyone can look up the public key on the OpenPGP keyserver and, if the key owner has verified an email address or established a web-of-trust path, link this credential to a real identity.
The trust model here is: "I can't prove who the signer is via institutional certificates, but I can prove (1) the signature is mathematically valid, (2) it was created at the claimed time per DigiCert, and (3) here's a PGP key you can independently verify." For grassroots documentation and movement contexts (which is ProofMode's design intent), this is a reasonable and appropriate trust architecture.
6. Ingredient & Provenance Lineage
The manifest lists one ingredient: the original 1748635752784.jpg with relationship type parentOf. The ingredient validation produces an informational code: ingredient.unknownProvenance — the raw camera capture has no C2PA manifest of its own.
This is entirely expected. The Pixel 9's stock camera app does not embed C2PA manifests. ProofMode captures the image (or receives it from the camera), then wraps it in a C2PA manifest as a post-capture step. The ingredient graph is: raw camera JPEG (no provenance) → ProofMode signs and wraps it (adding provenance). There is no missing link here; this is the normal capture pipeline for ProofMode on Android.
7. AI Generation Detection
The AI detection result is createdWithAI: false with an empty matches array, indicating no AI-generation signatures were detected. While the specific detection methodology isn't identified in the report, this result is consistent with everything else in the evidence: the image has valid device-specific EXIF data from a real camera sensor, plausible optical parameters, a network GPS fix, and visual content (a real room, a real laptop screen with code, natural lighting, lens aberrations) that is consistent with a genuine photograph rather than AI generation.
8. Permissions & Rights Assertions
The manifest declares a fully permissive licensing posture across all four C2PA permission categories: AI training (allowed), AI generative training (allowed), data mining (allowed), and inference (allowed). This means the creator has explicitly opted in to allowing downstream use of this image for machine learning and data analysis purposes. There are no restrictions declared. This is a deliberate choice by the signer and is consistent with ProofMode's defaults, which tend toward openness for documentary/evidentiary content.
9. Visual-Metadata Consistency Check
The image shows a person's foot propped up behind a laptop screen in what appears to be a residential room with hardwood floors, a window providing natural daylight, a Progress Pride flag, and what looks like a child's play area (pink/blue mat visible). The laptop screen shows Android Studio with a project called "proofmode" — specifically the VideosContentJob.java file — with a connected Google Pixel 9 in the Device Manager. The system clock on the laptop reads "May 30, 4:09 PM," and the bottom status bar shows "Build proofmode: finished At 5/30/25, 4:01 PM."
This is strikingly consistent with the metadata:
Time: The laptop clock shows 4:09 PM on May 30, matching the EXIF timestamp of 16:09:12 EDT precisely.
Device: The Android Studio Device Manager shows a connected Google Pixel 9, matching the claimed capture device.
Software: The developer is actively working on the ProofMode codebase (org.witness.proofmode), specifically on video content job processing with C2PA sidecar generation — the very software that signed this image. This strongly suggests the photographer is a ProofMode developer testing their own tool.
Lighting: Natural daylight through a window with indoor ambient light; the ISO 45 and 1/120s exposure are consistent with this well-lit scene.
Location: The GPS coordinates (42.3286, -71.1250) place the device in the Brookline/Boston, Massachusetts area, and the timezone offset of UTC-04:00 (EDT) is correct for that location on May 30. The residential setting visible in the image is plausible for that area.
Orientation: The portrait orientation (EXIF orientation 6) matches the vertical framing.
There are no contradictory visual-metadata signals. The visual evidence actually provides unusually strong corroboration because the laptop screen independently confirms the time, device, and software chain.
10. Forensic Summary & Confidence Assessment
Overall Authenticity Confidence: HIGH
Strongest links in the provenance chain:
All cryptographic hashes are internally consistent across ProofMode metadata, C2PA assertions, and OpenTimestamps — the file has not been modified after signing.
The DigiCert trusted timestamp provides an external, independently verifiable proof that the signature existed at the claimed time.
All 13 C2PA assertion hashes validate successfully, confirming manifest integrity.
EXIF camera parameters match the known Pixel 9 hardware specifications exactly.
The visual content independently corroborates the metadata: the laptop clock, the connected Pixel 9 in Android Studio, and the ProofMode source code all align with the claimed capture circumstances.
The OpenTimestamps commitment (pending blockchain confirmation across three calendar servers) will, once confirmed, provide an additional immutable temporal anchor.
Weakest links in the provenance chain:
The signing credential is self-issued and not on any institutional trust list. Authenticity ultimately depends on trusting that the PGP key 0x4de561d3c44a5905 belongs to who it claims to belong to. This can be strengthened by verifying the key on the OpenPGP keyserver and checking for email verification or web-of-trust signatures.
The GPS fix is 49 minutes stale and network-based (20m accuracy), so it confirms general area but not precise location at the moment of capture.
The ProofMode file creation timestamp appears to have a timezone labeling issue (labeled UTC but likely local time), which is a minor metadata hygiene concern but doesn't affect the substantive provenance chain.
The OpenTimestamps attestations are still pending blockchain confirmation, so the third temporal anchor is not yet independently verifiable.
Additional verification that would strengthen the assessment:
Looking up the PGP key 0x4de561d3c44a5905 on keys.openpgp.org to verify the key owner's identity
Waiting for the OpenTimestamps calendar servers to confirm the attestations on the Bitcoin blockchain
Cross-referencing the ProofMode developer community to confirm whether this key belongs to a known contributor (the visual evidence of active ProofMode development strongly suggests it does)
In summary, this image presents a robust and internally consistent provenance chain. Every available signal — cryptographic, temporal, device-specific, and visual — tells the same story: a photograph taken on a Google Pixel 9 at approximately 4:09 PM EDT on May 30, 2025, in the greater Boston area, by someone actively developing ProofMode, and signed within seconds of capture. The only meaningful gap is the identity verification of the signer, which is addressable through PGP key verification.
Claude is AI and can make mistakes. Please double-check responses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment