What the baseline reading log contains

The value is 128 bits of randomness with no internal structure and no payload. It is not derived from an email address, a party id, a file id or anything else about the visitor, and it cannot be reversed into any of them. It indexes a server-side session holding a read link id and a creation timestamp.

Three denials matter more than that description, because the questions a privacy reviewer asks about a cookie are all negative ones.

It is not an identifier that follows anyone across sites. The cookie is host-only, so it is never transmitted to another origin, and the read link surface embeds no resource from another origin that could read it. Cross-site correlation needs a shared identifier and a second origin able to receive it; the surface offers neither.

It is not linked to the signer's identity before consent. A visitor who goes on to sign is joined to a party record at the moment of signing, inside the signing record. That join is forward-only: it does not reach back and attach a name to the pre-consent reading rows.

It is not a durable visit counter, and that guarantee is server-side rather than a claim about browser behaviour. OctoDoc sets no expiry attribute and no persistent identifier, and never joins two cookie values into one visitor, so two cookie values yield two "opened" rows with no edge between them. How long a session cookie survives is the browser's decision — session restore can carry one for days — which is why non-correlation is enforced on the server instead of inferred from lifetime.

Article 5(3) of Directive 2002/58/EC, in its consolidated form, sets a default and then names two carve-outs: "Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."

Two phrases do the work. "Strictly necessary" governs the second carve-out, anchored to the service the visitor explicitly asked for — for a read link, delivery of one file behind one URL. "Terminal equipment" bounds the Article's technical scope, but the location of the resulting server record does not settle whether the source information originated there. EDPB Guidelines 2/2023 say at paragraph 55: "Unless the entity can ensure that the IP address does not originate from the terminal equipment of a user or subscriber, it has to take all the steps pursuant to the Article 5(3) ePD." The planned counter therefore rests on a narrow security purpose and lifetime under the strictly-necessary exemption, not on its server-side location.

The closest technical pattern in the Article 29 Working Party's Opinion 04/2012 on Cookie Consent Exemption is "User input cookies (session-id), for the duration of a session or persistent cookies limited to a few hours in some cases." The planned cookie shares the first-party, random, temporary Session-ID mechanics described in the opinion, but purpose controls the exemption: a read link is not an authentication cookie because no user logs in. The same opinion separately lists "User centric security cookies, used to detect authentication abuses, for a limited persistent duration." That category supports purpose and lifetime discipline for the abuse control without deciding the legal treatment of an IP-based server counter by label alone.

Version 2.0 of the European Data Protection Board's Guidelines 2/2023 on the technical scope of Article 5(3), adopted 7 October 2024, closes a second escape route at paragraph 12: "In conclusion, the notion of information includes both non-personal data and personal data, regardless of how this data was stored and by whom, i.e. whether by an external entity (also including other entities than the one having access), by the user, by a manufacturer, or any other scenario." On that reading a pseudonymous or wholly anonymous value written into a browser is still information in terminal equipment, so OctoDoc does not treat "the value is anonymous" as an answer to the storage question.

A privacy answer of "minimal analytics" or "only what is necessary" carries no information. It cannot be falsified, so it cannot be relied on, and it cannot go into a data processing agreement without a schedule underneath it.

The rows above are the whole of the pre-consent path. Anything a future release adds to it changes this page, the privacy notice, and the consent notice text whose hash is stored on every consent row — not an implementation detail that lands quietly in a deploy.

That planned shape would be checkable from outside. Once the post-v1.0 read link exists, a network recording should show one document fetch on one origin, one host-only session cookie with no expiry attribute, and no request to any other hostname.

The operative standard the second half of this design is written against is Article 4(11) of the General Data Protection Regulation, which defines consent as "any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her". Recital 32 restates it as a "clear affirmative act", but a recital is an interpretive aid rather than operative text, so the design is pinned to the Article. Storing the notice hash alongside the event is how OctoDoc keeps a record of which words were on screen when the affirmative act happened.

Nobody wants to read the contract. OctoDoc is being built so you do not have to: write a document from a prompt, ask plain-language questions about the one you were sent, and keep every one of them in a single place instead of four accounts and an inbox.

Unlimited human sends on the paid tier.