Legal export

The export produces an archive that a third party (lawyer, judge, journalist) can verify on their own, without going through ripoux.fr and without having to trust us.

From a session, choose Legal export, then Prepare archive. The archive is assembled in your browser: the segments are downloaded encrypted and decrypted on the spot. Make sure you have enough disk space: one hour in 1080p is about 1.8 GB.

#Archive contents

#The encrypted segments and the session key

The Also include the encrypted segments option, checked by default, doubles the size of the archive. It adds the segments as the server stores them and the private key of this session only (session-key.txt). With them, a third party recomputes hash on each file in encrypted/, finds the chain the server received, then decrypts each segment themselves with the key and compares the result with the decrypted file: they no longer rely on the phone's word to link the two.

This key opens nothing else: not your other sessions, not your account. But whoever receives the archive can replay this whole session, which is already the case with the decrypted files. Uncheck the option if the recipient only needs the originals.

#The assembled takes

The segments of 2 to 3 seconds are the evidence, but they are awkward to watch one by one. For each take in WebM (Android, Chrome, Firefox), the archive also contains prises/<take>.webm: the segments joined end to end without re-encoding. The video and audio data are copied as they are; only the time markers are shifted so that the pieces follow each other. A declared gap in the take remains a jump in the assembled file, never filled.

This file is a viewing convenience. It is not part of the manifest and has no signed hash: verification bears on the segments and the manifest.

Takes recorded in MP4 (Safari on iPhone) are not assembled in this version: only their segments are provided.

#Recipient

Download to this device saves the archive unencrypted on your computer. Protect it accordingly (encrypted disk, removable media). To hand it to a trusted contact, share the session with them instead: they prepare the archive themselves from their account, and nothing passes through unencrypted.

A protected single-use link for a lawyer does not exist yet.

#Write down the archive's hash

At the end, the screen shows the archive's SHA-256 hash. Write it down and pass it on through a different channel from the archive. It lets the recipient check that nothing changed on the way:

sha256sum ripoux-export.zip   # the exact file name may vary

The result must be identical to the hash you wrote down.

#How a third party verifies it

The simplest way: drop the archive on the public Verify a proof page, which redoes all these checks in the browser, sending nothing. For a check independent of ripoux.fr, the included VERIFICATION.md instructions are authoritative. The principle, with free tools (coreutils, OpenSSL 3):

#1. Each file against the manifest

For each segment, manifest.json gives plainHash: the SHA-256 hash of the decrypted file, declared by the phone when it sent the segment, then recorded by the server together with the time of receipt.

sha256sum segments/01/0001.mp4

The result must equal the plainHash of the corresponding segment in manifest.json. A file changed by even one byte gives a different hash.

#2. The server's signature on the manifest

The server's public key is included in PEM format in the archive, and published at https://ripoux.fr/.well-known/ripoux.json. The third party can compare the two.

openssl pkeyutl -verify -pubin -inkey server-public-key.pem -rawin \
  -in manifest.json -sigfile manifest.sig

Signature Verified Successfully: the manifest, and therefore every plainHash it contains, has not been modified since it was signed.

#3. The third-party timestamp

openssl ts -reply -in timestamp.tsr -text          # date and authority
openssl ts -verify -in timestamp.tsr -data manifest.json \
  -CAfile cacert.pem -untrusted tsa.crt

cacert.pem and tsa.crt are the timestamping authority's public certificates, to be downloaded from its website (by default freetsa.org). Verification: OK: this manifest, with its hashes, existed at the date shown.

#4. The chain

In manifest.json, each segment also carries hash (the hash of the encrypted segment, as received) and prevHash (the hash of the previous segment in the same take). The third party checks that each prevHash equals the hash of the previous segment, and that the only gaps are the declared ones. These hashes prove the continuity of reception on the server side; they are recomputed on the files in encrypted/ (with the encrypted segments option), not on the decrypted files.

#5. The log

Each entry in journal.json contains the hash of the previous entry and a server signature, which can be verified with the same public key.

#What the hashes prove

plainHash ties each file in the archive to the signed and timestamped manifest: nobody can produce, after the fact, another file with the same hash. Its limit: it is declared by the phone. The server only sees encrypted data and cannot check that it matches the content; it only attests that it received this hash at this time, with this segment.

hash and prevHash prove that the server received these encrypted segments, in this order, with these gaps.

See also Known limitations.

#Face blurring

The footage often contains the faces of people who did not ask to be filmed. The legal export is never blurred: it holds the originals, and they alone are authoritative.

To show a passage to the public, a collective can publish a blurred copy: faces masked in the browser, public page on ripoux.fr, with a signed document linking it to the source segments. For any other use (a screening, a press kit), blur a copy with a video editing tool and keep the original archive intact.