LIBRARY
Consent
A post-v1.0 read link could measure how a document was read. Each page here names the instrument that would govern one piece of that planned design.
Product status
OctoDoc-specific descriptions of proof files, public verification, read links, reading logs, AATL or B-LTA trust, and Object Lock on this page describe post-v1.0 designs, not capabilities in the current product. The cited standards and primary-source facts remain educational references.
01
The posture, stated once
The post-v1.0 read-link design would serve the file, set one opaque session cookie, record that it was opened, and keep a truncated-IP abuse log for twenty-four hours. Nothing else would happen before an affirmative, versioned, hashed consent event.
Device fingerprinting and TLS fingerprinting are excluded from that design rather than switched off. A capability that exists behind a flag is a capability, and the point of these pages is to make the planned privacy posture reviewable before it ships.
CONTENTS
Everything in this section
consent
- Article 5(3) of the ePrivacy Directive, and what a read link may measure
Article 5(3) of the ePrivacy Directive conditions the storing of information on, or the gaining of access to information already stored in, a person's terminal equipment on consent and names only two exemptions; the post-v1.0 OctoDoc read-link design applies that rule to a four-item baseline.
- Retention and erasure against a sealed record
OctoDoc's post-v1.0 erasure design destroys the per-file data-encryption key so document bytes stop resolving while the hash chain still recomputes and a verification report reads erased rather than mismatch; it is not a current v1.0 capability or legal advice.
- Global Privacy Control and Do Not Track
OctoDoc's post-v1.0 read-link design treats Sec-GPC: 1 as a declined telemetry answer, suppresses the consent interstitial, and does not read Do Not Track; this page explains the cited specifications behind that planned behavior.