Article 50(2) has two limbs; markproof measures one
Art. 50(2) requires that outputs be marked in a machine-readable format and
detectable as artificially generated or manipulated. The Commission Guidelines
on Article 50 are explicit that satisfying one limb does not discharge the other.
markproof measures the first limb: it verifies, against the operator's own
watermark configuration, that the mark arrived at the user. It says nothing about
the second, and — importantly — it cannot. Whether a third party who does not
hold the operator's keys can detect the mark is a property of the ecosystem, not
of the endpoint under test. No probe run against a system can establish it.
Why this is a documentation issue and not a feature
The honest response is not to build a detection check. It is to stop a passing
MPF-T-001 from being read as "Art. 50(2) satisfied", because it is not: it is
"the marking limb of Art. 50(2), as far as a self-conformance test can reach it".
This matters right now. The current state of practice is that detection tooling
for text watermarks is announced rather than shipped, and where it exists it is
key-gated — which is the weaker of the two footings the Guidelines describe. An
operator reading a green markproof run as full Art. 50(2) compliance would be
wrong in a way that only surfaces when someone asks.
Proposed change
- Findings for
synthetic-text-marking and synthetic-media-marking state which
limb they cover.
docs/DISCLAIMER.md names the boundary. (Done in the PR that opens this issue.)- The Markdown summary and the PDF carry a line to the same effect wherever a
marking rule passes, so the limitation travels with the artefact rather than
living in a README the report's reader never sees.
Not in scope
Building a detector for other people's marks. That is the universal-detection
problem the project refuses on purpose.
Article 50(2) has two limbs; markproof measures one
Art. 50(2) requires that outputs be marked in a machine-readable format and
detectable as artificially generated or manipulated. The Commission Guidelines
on Article 50 are explicit that satisfying one limb does not discharge the other.
markproof measures the first limb: it verifies, against the operator's own
watermark configuration, that the mark arrived at the user. It says nothing about
the second, and — importantly — it cannot. Whether a third party who does not
hold the operator's keys can detect the mark is a property of the ecosystem, not
of the endpoint under test. No probe run against a system can establish it.
Why this is a documentation issue and not a feature
The honest response is not to build a detection check. It is to stop a passing
MPF-T-001from being read as "Art. 50(2) satisfied", because it is not: it is"the marking limb of Art. 50(2), as far as a self-conformance test can reach it".
This matters right now. The current state of practice is that detection tooling
for text watermarks is announced rather than shipped, and where it exists it is
key-gated — which is the weaker of the two footings the Guidelines describe. An
operator reading a green markproof run as full Art. 50(2) compliance would be
wrong in a way that only surfaces when someone asks.
Proposed change
synthetic-text-markingandsynthetic-media-markingstate whichlimb they cover.
docs/DISCLAIMER.mdnames the boundary. (Done in the PR that opens this issue.)marking rule passes, so the limitation travels with the artefact rather than
living in a README the report's reader never sees.
Not in scope
Building a detector for other people's marks. That is the universal-detection
problem the project refuses on purpose.