The burden of proof rests on the cross-border worker, and the proof that matters is daily: it cannot be manufactured after the fact. A logbook kept day by day is worth exactly its dates — and the dates are the first thing an administration can call into doubt. Who guarantees this register was not filled in as one block, the night before the audit, with whatever dates suited?
On paper, nobody. In Frontalio, a precise mechanism, which this page explains in full — because a guarantee you cannot verify is not one.
The chain
Every evidence event — a proof deposited, a presence attestation, a deletion too — is written into a hash chain. A fingerprint (a SHA-256 digest, 64 characters) is computed over the event's facts and over the previous event's fingerprint. Rewriting or removing an entry changes its fingerprint, therefore the next one's, therefore all the others: tampering with one line visibly breaks everything after it.
A chain alone still has a limit: whoever hosts the database could recompute it whole. What is missing is an outside witness.
The seal
That is what RFC 3161 timestamping is for. Once a day, the head fingerprint of every chain is condensed into a single digest and sent to an independent timestamping authority. The authority signs it with its own clock and returns a token: proof, signed by a third party, that this digest — and so the whole register it summarises — existed exactly as it stands on that date.
What leaves the server: thirty-two bytes of digest and one random number. No document, no name, no date belonging to anyone. What comes back is kept whole, because it verifies with public tools, without Frontalio, in ten years as well as tomorrow.
What the seal proves — and what it does not
It proves existence at a date and order: this attestation, that deposit were in the register no later than the day of the seal, in this position, and nothing earlier has moved since. It does not prove a receipt is genuine, nor that you were where the receipt suggests — that remains the business of the documents themselves. The seal protects the credibility of the register, not the content of each piece.
Under EU law, an electronic timestamp cannot be denied legal effect solely because it is electronic (eIDAS regulation, art. 41). A qualified timestamp additionally enjoys a presumption of accuracy. The standard seal, applied free to every account, is not qualified but publicly verifiable — an element of assessment. Pro accounts are sealed with a qualified trust service provider: the date of their register is presumed accurate (art. 41(2)).
Verify it yourself
The seal shows in three places: at the foot of the PDF export (date,
authority, fingerprint), on the Account page under "Register integrity", and —
in full — in your data export. The ZIP archive contains, in donnees.json,
the ledger section: every chain entry with its fingerprint, and every
timestamp token in base64.
Two checks are possible, from simplest to most complete:
- Recompute the chain. Each entry's fingerprint is
sha256(previous fingerprint + payload + write date formatted YYYY-MM-DDTHH:MM:SSZ). Any scripting language recomputes it; a modified entry stands out immediately. - Verify the token. Decode the token into a
.tsrfile, then:openssl ts -reply -in seal.tsr -textprints what the authority signed — the date and the fingerprint.openssl ts -verifywith the authority's published certificate verifies the signature itself.
That is the point of the construction: the sentence "this register was not rewritten" is not the site operator's. It is a timestamping authority's, and it is verified against them, not against us.
In practice
Nothing to do. Sealing is automatic and daily, on every account, free. Keep the register as you go — that is the one thing the seal cannot do for you: it proves when you wrote, it will never write for you.