# Confidential PDF copies - format and technical limits

Prepare copies at https://checkthisfile.com/tools/pdf-ai-permissions. The Spanish tool is at https://checkthisfile.com/es/tools/pdf-ai-permissions.

## Workflow

1. Select a compatible PDF, enter the issuer and list one recipient or recipient reference per line.
2. Review the visible declaration and compatibility information. Confirm that you are authorised to set these restrictions.
3. Create the copies. Each receives a declaration page, a footer outside the original page content, a random copy identifier and an embedded C2PA credential.
4. Download the signed recipient record separately and keep it private. Download and review each PDF before sharing it.
5. To check a returned copy, select it in **Check a copy**. Add your independently retained recipient record to compare its final hash and recipient assignment.

No account or hosted registration is involved. Preparing, signing and checking do not consume hosted quotas. Registration for a public verification link is a separate, explicit workflow: register the final downloaded bytes after all changes and signatures.

## Processing and privacy

PDF bytes, recipient names and signing keys are processed on the device. They are not uploaded or automatically stored in localStorage, IndexedDB or a service account. Static application, worker and WebAssembly resources are downloaded from CheckThisFile. Consent-based product measurement uses only the existing coarse tool events, not file names, hashes, recipients, keys or document content. Offline availability is not guaranteed.

An ephemeral, non-extractable ECDSA P-256 signing key and a separate certificate issuer key are generated with Web Crypto for each batch. No common private key is shipped in the application. Private keys remain in memory and are not offered as downloads. Cancelling or resetting releases workers and download URLs; the browser controls memory reclamation.

The recipient record is **not encrypted**. It contains the issuer, recipients, original file name and hash, final copy hashes and public verification material, but no document content or private keys. Keep it separately and do not distribute it with a confidential copy unless you intend to disclose those assignments.

## Visible declaration and machine-readable permissions

The declaration requests manual review by the intended recipient and separate issuer permission before uploading the document or its contents to AI services. It is visible at ordinary reading size, not a hidden prompt.

The embedded `cawg.training-mining` assertion sets these four entries to `{"use":"notAllowed"}`:

- `cawg.ai_inference`
- `cawg.ai_training`
- `cawg.ai_generative_training`
- `cawg.data_mining`

The custom assertion `org.checkthisfile.usage` uses profile `checkthisfile-pdf-usage-v1`. It records the declared issuer, recipient, batch and copy UUIDs, language, device-reported date and signing-key fingerprint. The fingerprint is SHA-256 of the RFC 8785 canonical public JWK (`kty`, `crv`, `x`, `y`).

**AI services can ignore these permissions. The tool does not guarantee that an AI will refuse, stop reading or stop extracting content.** It does not add DRM, opening passwords, adversarial patterns or a hidden instruction layer.

## Signature and trust

The PDF contains an ES256 C2PA signature, with a locally generated certificate chain. The signer returns a detached COSE_Sign1 structure; the SDK binds the credential to the prepared PDF bytes and verifies the result before download. A CAWG usage assertion is not a CAWG identity assertion.

The key is self-issued. It does not prove legal identity, authorship, ownership, truth, acceptance, delivery or legal compliance. No trust-list accreditation, qualified electronic signature or independent/qualified timestamp is provided. Dates come from the device. The certificates last one year; without a trusted timestamp, later certificate validation can report expiry.

During creation the tool checks against its own local batch anchor. This is a consistency check, not independent identity verification. With the independently retained recipient record, checking also pins that batch anchor and compares the final file's exact SHA-256. Without that record the result can establish signature/content consistency, not the issuer's identity or a trusted recipient assignment.

## Signed recipient record

The JSON envelope uses `algorithm: "ECDSA-P256-SHA256"`, `body` and a standard-base64, 64-byte IEEE-P1363 signature. The signature covers the UTF-8 RFC 8785 canonical JSON encoding of `body`.

`body.profile` is `checkthisfile-recipient-record-v1`. It contains `batchId`, `issuer`, `deviceDate`, `source`, `publicKey`, `keyFingerprint`, a literal PEM `rootCertificate`, and `copies`. Each copy has `copyId`, `recipient`, `filename`, final `sha256` and byte `size`. The JSON schema is https://checkthisfile.com/schemas/pdf-recipient-record-v1.json.

The final hash is computed **after** the visible marks and C2PA signature are complete. Nothing is appended afterwards. File names are not used to identify a match, so renaming a copy does not break exact-byte comparison. Record signatures, duplicate identifiers, key fingerprints and bounds are checked before use. Trust material supplied as a URL is rejected; remote manifests and OCSP fetching are disabled.

Anyone can create a new self-issued key and a new record. Obtain the original record through an independent trusted channel; a record supplied alongside an untrusted document cannot authenticate itself. A signature failure alone is not proof of tampering. The retained final hashes can still support exact-byte comparison when certificate validity expires.

## Traceability scope

A matching original record identifies the issued copy assigned to a recipient. It does not establish who actually disclosed the document. Screenshots, cropping, copying tables or re-exporting can remove identifiers and invalidate or strip credentials. A surviving visible copy code can be checked manually against the original record, but is not itself a cryptographic integrity check. There is no automatic leak detection or tracking of recipients opening their copies.

## Compatibility and limits

- Input PDF: up to 20 MiB and 100 pages; each page's CropBox must be at least 240 points wide and high, at most 20,000 points per side, with a quarter-turn rotation.
- Up to 10 distinct recipients, 160 characters per issuer or recipient, without control or directional-formatting characters.
- Each output: at most 50 MiB; combined outputs: at most 100 MiB. Recipient JSON: at most 256 KiB.
- Existing digitally signed, encrypted, Content-Credentials-bearing, form-bearing, active-content and embedded-content PDFs are not rewritten. Preserve and register the original instead.
- Output is a new sharing copy. Original page text and graphics remain vector-based where originally vector-based. No OCR, rasterisation of original pages or AI processing is performed.
- Pages are oriented for reading and gain a 64-point footer band; narrow pages gain side margins to keep the footer readable. A declaration page is inserted first. Original pages are embedded without scaling their content.
- Links, annotations, bookmarks, forms, accessibility tags, advanced structure and original document properties are not retained. This is unsuitable when those structures must survive. Review every page and retain the original for accessibility-dependent use.
- Recipient names are visible in their copies; long footer names may be shortened, while the full value remains on the declaration and in the signed data. Copy UUIDs are not shortened.
- Current browsers require a secure context, Web Crypto, WebAssembly and workers. HTTPS is required for the production signing worker. Large files can exceed a device's available memory despite being within the limits.

Third-party licences and the pinned signing asset checksums are available at https://checkthisfile.com/vendor/c2pa/0.15.4/NOTICE.txt and https://checkthisfile.com/vendor/c2pa/0.15.4/assets.json.