Technical and organisational measures

Under Art. 32 GDPR. This page describes what is actually implemented in BlueOcean Orbit — not what we intend to do. As of 19 August 2026.

Art. 32 GDPR requires measures appropriate to the risk. We describe them openly so that you, as the controller, can assess whether they are sufficient for your purpose. Where something is not implemented, that is stated here too.

1. Confidentiality

Access control (who gets into the system)

• Sign-in with e-mail and password. Passwords are hashed with scrypt (n=2^14, r=8, p=1) and stored with a random salt per account. Plaintext passwords never exist in the database.
• Registration requires double opt-in: an account only becomes active after confirmation via a one-time link.
• Two-factor authentication (TOTP per RFC 6238) with single-use backup codes. The secret is stored encrypted.
• Sessions expire after 12 hours. Session tokens are stored only as SHA-256 hashes; a database dump reveals no valid sessions.
• Rate limiting with a violation counter: repeated failures lead to an increasing lockout (starting at 15 minutes, doubling per violation, capped at 24 hours). Registration, password reset and chat are limited as well.
• Personal API keys per user, individually revocable, with an optional expiry date. Only the hash and a recognisable prefix are stored.

Access control (who sees what)

• Tenant separation in the data model. Every record with a user reference — profiles, memory, chats, documents, attachments, reports, jobs — carries its owner. Filtering happens in the data access layer, not in the user interface. A faulty interface cannot bypass this separation.
• Access to another user's object returns 404, not 403 — the existence of other users' data cannot be probed.
• Roles and groups with a permission tree; sharing individual objects is explicit and revocable.
• The administration area is restricted to a separate account.

Encryption

• In transit: HTTPS (TLS) only. Access runs through a Cloudflare tunnel; the application server is not directly reachable from the internet and listens on the local interface only.
• Third-party credentials (Anthropic keys, mailbox passwords) are stored encrypted with Fernet (AES-128-CBC with HMAC-SHA256) and are never displayed or logged in plaintext.
• E-mail delivery over STARTTLS, DKIM-signed; DMARC is in place.
• End-to-end in the messenger. Messages, attachments and voice messages are encrypted on the device and become readable again only at the recipient — following the Matrix standard with Olm and Megolm (m.megolm.v1.aes-sha2), implemented with the open-source matrix-rust-sdk. The keys live exclusively on the participants' devices. The server operator does not hold them and cannot obtain them after the fact. A new device reaches old messages only through confirmation by an existing device or through the user's recovery key.
• Not implemented: encryption of the database file at rest. The server disk is not fully encrypted. For data with especially high protection needs, please discuss this with us in advance. For messenger content this is immaterial — it is stored there encrypted and without keys anyway.

Separation of processing

• Separate databases for accounts, billing, profiles, chats and the knowledge space.
• The language model runs in its own container with no outbound connection.
• For chat on our model, content never leaves the server.

2. Integrity

• Tamper-evident log. Security-relevant events (sign-ins, sharing, consents, administrative changes) are written to an append-only log in which each entry contains the hash of its predecessor. Any subsequent alteration visibly breaks the chain. Database triggers additionally prevent updating and deleting entries.
• Referential integrity with enforced foreign keys and CASCADE deletion: deleting an object removes its related data immediately and completely, not via a later cleanup job.
• Schema changes run exclusively through versioned migration scripts.
• Protection against accidental disclosure: a filter detects credentials (API keys, tokens, passwords) in messages bound for external models and blocks the message rather than redacting it.

3. Availability and resilience

• Containers restart automatically; user data lives in a persistent volume separate from the application code.
• Sessions and queues survive a restart because their state is in the database, not in memory.
• Load limiting with a visible queue instead of collapse.
• Misconfiguration is reported at startup, not by the first user.
• Not yet implemented: automated backup. Regular backups with tested restoration are in preparation. Until then the availability guarantee is limited — we state this explicitly.

4. Review and evaluation

• Automated tests run on every change to the software, including tests for tenant separation and access rights.
• Errors are logged with a case number; users receive only that number and a plain-language message, no technical details.
• Usage is recorded per account and day — as a basis for billing and for spotting anomalies.
• Source-code review of both messenger apps (18 August 2026): 21 findings, the serious ones fixed, the remainder documented and worked through. This is our own review, not an external audit — we name it as what it is.
• Not yet implemented: external security assessment (penetration test) by a third party.

5. Processors

We use the following for operations:

• Hetzner Online GmbH (Germany) — servers and storage.
• Cloudflare — access and connection protection.
• Anthropic PBC (USA) — only if you store your own key and expressly consent to the transfer. Without that consent no transfer takes place.

Data processing agreements under Art. 28 GDPR are being concluded. Please ask us for the current status before productive use with personal data.

6. Jurisdiction and requests from authorities

Technical measures are only one half. The other is the question of who can compel us to do what. We answer it here as precisely as the rest of this page.

• Applicable law: EU law (GDPR, ePrivacy) and Cypriot law — BOP BLUEOCEAN PRIVACY LTD is seated in Larnaca. Added to that, where relevant, the law of the country the user is in; currently Germany, Austria or Switzerland.
• Server location Germany (Hetzner) is a statement about the technology, not about the seat of the company. Both belong stated separately.
• Who sees the network path: Cloudflare, sitting in front of our server — and, now that the apps also announce messages while they are closed, the delivery services of Apple (APNs) and Google (Firebase Cloud Messaging). They learn that a device is being woken and when; not by whom and not what. The wake-up call carries no content, only an identifier — the device fetches the text itself and decrypts it there. This is a transfer to a third country; the basis is each provider's standard contractual clauses.
• No US law. We are not a US company and have no establishment there; the CLOUD Act and FISA 702 presuppose exactly such a connecting factor. Nor are we subject to orders under the UK Investigatory Powers Act.
• What we can hand over on a lawful order: subscriber and traffic data — that two accounts communicate, when, and from which IP address. What we cannot hand over is content and keys, because we do not hold them. That is a technical fact, not a promise: a promise would hold until the first order, the architecture holds beyond it.
• The server deletes messages after 30 days by itself — which also limits what can be the subject of a request at all.
• What lies outside our reach: the user's device (seizure, malware, an unlocked phone), the person they write to, and the network path. In front of our server sits Cloudflare protecting the domain; there it is visible that a connection takes place, not its content.

Set out in full and in plain language under Which law applies to us — and which does not.

7. Your role

When using BlueOcean Orbit, you are generally the controller under the GDPR and we are the processor. You decide what data you enter. We provide the measures described above.

This page is a technical description, not a certification and not legal advice. No provider can declare "GDPR compliant" on your behalf — compliance depends on how you use the tool.

8. Questions and reports

Please report security issues and privacy questions to [email protected]. We respond within 72 hours.

How your iPhone protects your messages · To the privacy policy · To the terms of service