Menu

Technical and Organisational Measures

Current complete version. The German version controls where stated in the document.

Version: 1.6
This English version is provided for convenience. The German version controls.

These risk-based measures are the minimum state to be demonstrated and may evolve without materially reducing the agreed protection level.

1. Organization and responsibility

  • Operator and privacy contact: V-IZ Video-Integrationszentrum, sole proprietor Fuat Karacocuk, info@doliapp.de.
  • Documented operational, development, support, and incident responsibilities.
  • Confidentiality duties for people with administrative access.
  • Periodic review of data flows, providers, and release gates.

2. Access control

  • Least privilege, need to know, and individual revocable access.
  • Multi-factor authentication where technically available.
  • Key-only Hetzner SSH; production secrets remain server-side.
  • Doli's real-time server runs in a container without root privileges, without additional Linux capabilities and with a read-only file system.
  • Rotation and immediate revocation on suspected compromise.

3. Transmission security

  • HTTPS/TLS and WSS transport.
  • One-use tickets and provider credentials excluded from URLs/content logs.
  • Size, format, and source validation for frames and files.
  • Doli's server signs in to Google without a service account key: workload identity federation with X.509 certificates that are valid for 30 days, renewed automatically and approved one by one by fingerprint. The service account may only call AI models.
  • Other API keys restricted to the required project and service.

4. Separation and authorization

  • Supabase Row Level Security and owner-bound rules.
  • Private control tables outside the public Data API and default deny.
  • Server binding of user, session, ticket, allowance, and contract.
  • Content features only after a valid DPA and active business entitlement.

5. Data minimization and content boundary

  • Technically necessary temporary recordings on the device are deleted after processing or cancellation. Files selected or expressly saved by users remain under their control.

  • No persistent Doli conversation history of audio, transcripts, translations, prompts, images, documents, or suggested replies.

  • Bounded memory buffers cleared on completion, cancellation, overflow, sign-out, or secure termination.

  • No Live Session Resumption, Search/Maps Grounding, File API, stored Interactions, or explicit context caching.

  • Gemini Developer Logging/Datasets and RevenueCat Rico disabled.

  • Zero data retention applies to Google Cloud project 674711097607 as defined by Google: approved exception from Vertex abuse-monitoring prompt logging, data cache disabled, no storing Google features.

6. Integrity, abuse, and cost controls

  • Authenticated one-use, short-lived relay tickets.
  • Server-authoritative allowance checks, atomic reservations, and usage records.
  • Shared-allowance serialization across concurrent devices.
  • Hard size, queue, and duration limits with fail-closed termination.
  • Relay-created provider setup; client setup is discarded.

7. Availability and recovery

  • Health checks, automatic container restart, and TLS termination.
  • Necessary-metadata backups only; no Doli conversation content.
  • Database, Edge, and Relay recovery/rollback procedures.
  • Fail-closed behavior for inconsistent session or contract state.

8. Logging and monitoring

  • No conversation content, prompts, translations, credentials, or authorization headers in Doli operational/security logs.
  • Coarse errors, timestamps, states, and necessary technical security data only.
  • Restricted log access and provider-security-notice review.
  • Separate Google policy enforcement under Annex 1.
  • Automatic alerts on every change to the Google sign-in configuration, on refused renewal requests and when the server certificate is no longer accepted or about to expire.

9. Secure development and change control

  • Version control, code review, and automated privacy/security tests.
  • Database migrations, RLS, and pgTAP tests.
  • Type checks and tests before Relay, Edge, or app changes.
  • No secrets, production data, or private evidence in the repository.

10. Deletion and processing end

  • Session stop closes provider connections and clears content buffers.
  • Valid deletion instructions are documented and flowed down.
  • At contract end, return or deletion and deletion of remaining copies except restricted data under mandatory retention.
  • Separate purpose-limited retention of statutory contract evidence.

11. Incident response

  • Documented detection, containment, evidence, recovery, and review.
  • Immediate revocation of compromised keys, accounts, and sessions.
  • Customer notice upon awareness without waiting for internal confirmation.
  • Phased categories/counts, contact, consequences, and measures as available.

12. Provider and physical security

  • Supabase: Central EU (Frankfurt) primary project region, DPA and TIA.
  • Hetzner: Nuremberg Relay, concluded DPA, public TOMs/subprocessor list; confidential evidence remains private.
  • Google: Cloud Data Processing Addendum for Vertex content; zero data retention for project 674711097607 (approved logging exception, data cache disabled). No promise of EU-only processing of all service data.
  • RevenueCat: DPA/SCCs and Rico disabled.
  • STRATO: contract email under DPA/TOMs; Netlify public website only, without forms.