Security and architecture

At a glance

• Out by light: Bouraq Prism, an HTML file opened from disk, encrypts files with the account key and shows them as QR codes; a permitted camera reads them and sends them to the account's space, where they are rebuilt and verified (sha256).
• Back through a channel you choose: the user's private GitHub or GitLab repository, or a USB key. It never goes through our servers.
• Nothing to install, no network access opened: no agent, no executable, no background sync. The offline PC only emits light.
• No end-to-end encryption today: our server holds each account's key and decrypts files to rebuild them. See "What our server sees".
• Hosted in the European Union: Hetzner, Helsinki data centre (Finland).

Data flow

Out (offline PC → the user's space):

• On the offline PC, Prism compresses the files (zlib) and encrypts them with the account key (XSalsa20-Poly1305), file name included, then splits them into numbered QR codes with an integrity check.
• The Bouraq app reads the codes with a phone camera or a computer's webcam and sends them over HTTPS to the server, tied to the signed-in account.
• The server reassembles the stream, decrypts it with the account key, checks the sha256 fingerprint and places the file in the account's space.
• On the personal PC, the user downloads the file from their space, in a browser.

Back (personal PC → offline PC): Prism packs the changed folder into a single text file (Repomix) and pushes it to the user's private repository, or saves it for a USB key. On the offline PC, Prism checks every path before writing and never deletes a file. This trip does not touch our servers.

What our server sees

To rebuild and verify a transfer, the server decrypts it: it therefore sees the file, its name and its size. The file is kept in the account's space for up to 7 days after it arrives, then deleted; with the “Delete after download” option it is deleted as soon as it has been fully downloaded, and only its name, size, fingerprint and receipt remain; a transfer over the quota is deleted as soon as it is collected and after 24 hours at most. The application claims no encryption at rest.

The server never sees: the way back (private repository or USB key), the GitHub or GitLab access token, or any file on the offline PC the user did not choose.

If your organisation requires that content is never readable by a third party, Bouraq can run on a server you control: write to us.

Cryptography and accounts

• Transfer encryption: XSalsa20-Poly1305 (TweetNaCl secretbox), a random 32-byte key per account, a random 24-byte nonce per transfer. A photographed QR code reveals nothing of the content without the key.
• Versioned key: renewing Prism from the app changes the key, and the server then refuses earlier copies.
• Integrity: a check per code and a sha256 fingerprint of the whole file, verified before the file is made available.
• Transport: HTTPS only (TLS 1.2 and 1.3, Let's Encrypt certificates).
• Passwords: scrypt hashes; sign-in attempts are rate-limited. Browser session through an HttpOnly, Secure, SameSite=Lax cookie, valid 30 days at most.
• Two-factor authentication (TOTP, RFC 6238) for every account, with any authenticator app; an organisation can require it for its administrators. A command-line token also requires the code.

The Bouraq Prism file

Prism is a single HTML file of about 490 KB that the user opens from disk. Your team can read it before use: all the code is in the file.

• Content Security Policy: default-src 'none'; the only connections allowed are api.github.com and gitlab.com, and only when the user uses the private-repository way back.
• Before any push or fetch, Prism asks the provider whether the repository is private and refuses a public or internal one.
• Bundled libraries, pinned and checked by hash: pako 2.1.0, fflate 0.8.2, qrcode-generator 1.4.4, js-sha256 0.11.1, TweetNaCl 1.0.3.
• The personalised copy contains the account key: keep it like a credential.
• Check the copy before carrying it in: your space shows your copy's SHA-256 fingerprint (certutil -hashfile <file> SHA256 on Windows, shasum -a 256 on macOS, sha256sum on Linux). Every copy issued enters the audit trail with that fingerprint and its key version; a key renewal is recorded there too and revokes the older copies.
• Signed release: the instance publishes the signed statement of each Prism version's template (/.well-known/bouraq-prism.json). The bouraq-verify.py prism command of the verification script removes a copy's single account line and proves everything else is exactly that code, byte for byte, without ever printing the key.
• Every code Prism shows carries, under its number, the account and the first 8 characters of the file's sha256 fingerprint, the one in the audit trail: an authorised transfer is recognisable on screen, and discreet use would be visible to colleagues.

Hosting and sub-processors

• Hetzner Online GmbH: server, database and files, Helsinki data centre (Finland, EU).
• Cloudflare, Inc.: domain names and reception of e-mails sent to contact@getbouraq.com.
• Stripe: payment and subscription; card data never reaches us.
• Google Workspace: our mailbox, where your e-mails arrive.
• Audience measurement is hosted on our own server, with no external tracking tool.

Data and retention details are in the privacy policy.

Governance and authorised use

Bouraq is a neutral transfer channel: it exploits no vulnerability and disables no control. Our terms only allow transferring content the user is entitled to move.

• Every transfer belongs to a named account, is time-stamped and identified by its sha256 fingerprint.
• Authorisation on file: each account records who authorised it to move data out, their role, the scope and the period. It enters the audit trail, travels with every delivered transfer and appears on its receipt; an organisation can refuse any transfer without a current authorisation.
• Tamper-evident transfer audit trail (each entry seals the previous one by hash): deliveries, failures with their reason and downloads, with account, file name, size, sha256 and time, never the content. Your administrator exports it as CSV or JSON Lines for your SIEM, and each account exports its own entries (for the client whose files left); kept 365 days.
• A signed receipt for every delivered file: name, size, sha256, account, time, key version and the matching audit-trail entry, signed with the instance's Ed25519 key. An auditor, a client or a court checks it without us, using the public key at /.well-known/bouraq-receipt-key; a single changed byte breaks the signature.
• Verifiable without us: a standalone script (Python, standard library only, no network) checks an audit-trail export and a receipt's signature, and compares a file with its receipt.
• Approval of each transfer (an option for organisations): an arrived file waits until an administrator of the organisation, other than its sender, approves or rejects it, with a reason; a rejection deletes the file. Every decision is signed: the approver types their password again, and their code when they have a second factor; it enters the audit trail with how it was signed.
• Allowed file types (an option for organisations): only the types you name may leave; a folder sent as a ZIP is checked file by file, without extracting it. A refused file is never written and the refusal enters the audit trail with its reason. The check is on declared types; it is not malware scanning. An organisation can also have medical images (DICOM, patient data) refused, recognised by their content even when renamed or zipped, and text files bearing a protective marking (Diffusion Restreinte, VS-NfD, OFFICIAL-SENSITIVE, CUI…), a safety net against mistakes, not a classification system.
• Each direction is authorised separately (an option for organisations): export can be opened alone; issued Prism copies then offer Send out only, without Pack & send back or Bring back, and the server's down channel is closed. The way back by repository or USB key never touches our servers, so your media and repository policy remains the control that counts.
• Named, revocable devices: every signed-in phone or browser is listed with a name (editable, such as “Work phone”) and its last use; each transfer records the device that carried it, in the audit trail and on its receipt; a lost device is signed out in one click.
• An instance's administrator creates accounts, sets quotas, renews keys and signs a session out remotely. On the shared service, an organisation has its own administrators: they add and remove colleagues within their seats, change roles, see each member's last use, devices, second factor and authorisation on file, and set their own transfer policy (approval, file types, authorisation on file, directions, second factor), never looser than the service's; every change enters the audit trail, whose own part the organisation exports (CSV, JSON Lines) for its SIEM. An access review flags members without a second factor, unused for 90 days or without a current authorisation, and the completed review is recorded in the trail.
• For an organisation: a dedicated instance or an installation on your own servers, on request.

Reporting a vulnerability

Write to contact@getbouraq.com describing the issue; we answer quickly and keep you informed of the fix. Please do not access other users' data. Machine-readable contact: /.well-known/security.txt.