0 Fork 0

mirror of https://github.com/wiltodelta/remove-ai-watermarks.git synced 2026-10-14 13:30:55 +02:00

Files

T

Victor KuznetsovandClaude Opus 5.5 7ba07869d2 Add paid-service captures, aggregator attribution, and provenance vetoes

Collect provider samples from Higgsfield, Runway and Dreamina plus Google
Photos, Gemini, Grok and YouTube re-encodes into data/captures/2026-09 with
a hash-checked manifest, and use them to fix attribution and false positives:

- Attribute aggregator outputs: Higgsfield job metadata, Dreamina's
  re-signed manifests, Runway's own C2PA signer, TC260 video producers.
- Veto any visible video mark when a valid C2PA claim names another vendor
  (a Gemini Omni clip read as Sora on steam), and gate Kling and Hailuo
  matches on edge, anchor and white-label evidence.
- Veto the Gemini sparkle when trusted provenance names another vendor.
- Report SynthID as present for Google Photos AI edits: Google's checker
  found it on all four measured edits, though manifests record no action.
- Add Vidu video and Wan image marks, TC260 audio placements, and record
  the AIGC key in metadata records.
- Document the research sweep, the Dreamina badge decision, and verified
  Google statements on SynthID in Photos.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-09-26 14:32:53 -07:00

4.8 KiB

Raw Blame History

C2PA soft-binding resolution research

Development-only investigation, 2026-09-07, completing the privacy-tiered C2PA resolution item from the original research map. The outcome is a product decision rather than a feature: this tool resolves nothing over the network, and this page records what the resolution ecosystem would learn if it did.

The normative shape

C2PA 2.2 specification section 18.10.5 defines the soft binding resolution API: a standard way of retrieving manifest stores from a resolution endpoint given a soft binding value, a manifest identifier, or an asset - three input modes that are exactly three privacy exposure levels. The algorithm registry (c2pa-org/softbinding-algorithm-list) carries the endpoint URIs in softBindingResolutionApis. As of the packaged revision 1b3ef637890e, 8 of 53 entries publish them.

Measured contracts

Algorithm	Kind	Endpoint	Input	Content leaves	Content digest leaves
`com.aiwatermark.audioseal.1` / `videoseal` / `pixelseal`	watermark	`aiwatermark.com/api/v1/resolve`	`GET ?payload={extracted payload}&alg=`	no	no
`com.joinmonolith.sha256`	fingerprint	`api.joinmonolith.com/api/c2pa/matches/byBinding`	`GET ?alg&value=base64(SHA-256 of asset)`	no	yes
`me.deepmark.audio.vigil.128`	watermark	`resolution-api.deepmark.me`	payload-based per vendor site	no	no
`ai.trufo.pawprint.watermark` / `.fingerprint`	both	`c2pa.trufo.ai/v1`	not published publicly	?	?
`io.blockfact.audio.watermark.32`	watermark	`api.blockfact.io/api/soft-binding/v1`	not published publicly	?	?

Sources, verified 2026-09-07 against the vendors' own pages: the Monolith soft-binding documentation (lookup endpoints public by design, "a verifier is usually a stranger"; only manifest minting is authenticated), the AIWatermark algorithm page ("after extracting the watermark payload from an audio file, validators can resolve the payload"; model source Meta FAIR AudioSeal), the Deepmark product description ("the signal is detected and its payload resolved"), the Trufo developer documentation and trufo-py repository (signing-side only), and the BlockFact API reference (its public verify endpoint takes a Starknet transaction hash, not a soft binding).

The privacy gradient, concretely:

Payload-only resolution (AIWatermark, Deepmark) sends a locally extracted watermark payload - opaque bits that identify the mark, not the file. This is the mode our pinned local oracles could serve without ever touching the network with content or a digest.
Digest resolution (Monolith) sends base64(SHA-256) of the whole asset. No bytes leave, but the digest is linkable to the exact content: the registry learns you are inspecting that precise file.
Undocumented (Trufo, BlockFact): no public contract; any integration would be guesswork and is not attempted.

The product decision

This tool does not resolve anything over the network, at any tier, and no local_only / binding_only / full_content modes ship. The reasoning:

The tool's user processes their own generated or edited content and wants to know which provenance signals it carries and to remove them. Local payload extraction - already available through the pinned development oracles - answers the identification question without a network.
Querying a vendor's resolver tells that vendor someone is inspecting the specific content (directly for digest-based lookups, via the payload for payload-based ones). For a removal tool that is a leak in the opposite direction of its purpose, and it contradicts the offline runtime boundary the project already guarantees.
No user scenario of this tool requires manifest recovery from a registry: that is a verifier-of-third-party-content function, which is outside the intended use.

The runtime boundary stays: identification reports locally decoded evidence only, and docs/known-limitations.md states the resolution boundary in user terms. A guard test pins the packaged registry's published-API set, so an upstream ecosystem change surfaces as a conscious decision recorded against this page rather than a silent regeneration.

Investigation note

The first reconnaissance pass concluded "upstream publishes zero resolution APIs" because the probe searched the registry JSON for guessed key names instead of the softBindingResolutionApis key the sync actually reads. The drift-guard test written from that wrong premise failed immediately against the packaged snapshot and exposed the error - eight live endpoints, including resolution hosting for the exact AudioSeal and VideoSeal schemes this project benchmarks. The corrected guard now pins the real set. Field names are verified against the consumer's schema, never guessed.

4.8 KiB Raw Blame History