Privacy Policy

This policy explains what personal data RetroRelay collects, why we hold it, who else processes it, how long we keep it, and what rights you have over it. We have written it in plain English. If anything is unclear, please contact us using the details at the bottom of this page.

RetroRelay is operated by Adapanos Ltd (“we”, “us”, “our”), a company registered in England and Wales (company number 17167951), of 483 Green Lanes, London, England, N13 4FG, United Kingdom. We are the data controller for the personal data described below.

Adapanos Ltd is registered with the UK Information Commissioner's Office: registration number ZC151922.

1. What data we collect and why

1.1 Account identity (Firebase Authentication)

When you sign up or sign in we collect the data Firebase Authentication holds about you: your email address, your display name and profile photo address (where your sign-in provider supplies them, as Google sign-in does), your authentication provider, the date your account was created, and the date you last signed in. We also receive an internal Firebase user ID that we use to link the rest of your data together.

Lawful basis: performance of a contract (Article 6(1)(b) UK GDPR); we cannot provide the service without identifying who is signed in.

1.2 Paired device records

When you pair a retro phone with your account, we store: a randomly generated session token (used by the phone to authenticate its requests, and from which the encryption key for the legacy network channel is derived), the time you paired the device, the time the device was last seen, and a device name (initially derived from the phone's self-reported model, e.g. "Nokia6300", which you can rename at any time). The device record also carries the operational state the service needs to run: the phone’s self-reported model token and language/region setting, a copy of your timezone and offline-authenticator preference (so screens render correctly for you), per-feature freshness counters, a replay-protection counter for the encrypted channel, and, if a lapsed subscription leaves more devices paired than your plan allows, a flag marking which devices are paused.

We also read these device records in aggregate, as counts per phone model and language, to understand which handsets the service needs to support. Only the counts come out of that analysis; it produces nothing about individual accounts.

Lawful basis: performance of a contract; pairing is the core function of the service. The aggregate counts rest on our legitimate interest in improving the service (Article 6(1)(f)).

1.3 Authenticator (TOTP) secrets

If you add an authenticator account, we store the account name you give it, the position it sits at in your list, that account's code settings (issuer, algorithm, digits, period), the date you added it, and the shared secret used to generate one-time codes. The secret is encrypted at rest using AES-256 with a key held only on our server, so a database-only breach does not expose readable secrets. The encrypted secret leaves the server only when generating a code for your paired device, when you turn on the Authenticator's offline mode (which downloads the seeds to your paired phone so codes can be generated without signal), or when you request a copy of your data via the export feature.

Lawful basis: performance of a contract.

1.4 User settings

If you configure a location, we store the city name, latitude, and longitude you chose, along with your preferred weather units. We also store your timezone (used to render dates and times correctly on your phone), your Authenticator offline-mode preference, the date you completed onboarding, and small bookkeeping flags: whether you have dismissed the two-step-verification reminder, which in-app notices you have acknowledged, and a few internal “last changed” timestamps used to keep your devices in sync. Any setting we add later is stored the same way and listed here.

Lawful basis: performance of a contract.

1.5 Server logs

Our servers record technical information about requests: the IP address they come from, the time, the URL path, and the response status. Our application’s own log lines also carry your internal account ID on signed-in requests, and a short prefix of any session token involved (the first eight characters, never the full token), used for correlating events across log lines. Occasional diagnostic lines record the specific value that caused a problem, such as a location search our weather provider rejected, or the technical headers of a phone we could not identify. We use these logs only for security, abuse prevention, and diagnosing problems.

Lawful basis: our legitimate interest in keeping the service secure and operational (Article 6(1)(f)).

1.6 Pairing requests in flight

When a phone starts the pairing process, we briefly store the pairing code and session token, along with the phone’s self-reported model and language, in a separate “pairing requests” collection. An unused code stops working 5 minutes after creation (the record itself is swept shortly afterwards); when pairing succeeds the record is deleted immediately.

Lawful basis: performance of a contract.

1.7 Subscription state (paid plans only)

If you subscribe to a paid plan, we store a small set of identifiers and status fields so we can decide whether to render paid features for you without calling Stripe on every request: an identifier for your Stripe customer record, an identifier for your active or most recent subscription, the subscription's current status (active, past‑due, cancelled, etc.), the price plan you are on, the end of the current billing period, and any scheduled cancellation date. This mirrors what Stripe holds on its side.

We do not store your card number, CVC, billing address, or any other payment details. Those are held by Stripe; we only ever see the Stripe-generated identifiers described above.

Lawful basis: performance of a contract; we need this state to provide the paid features you have subscribed to.

1.8 Anonymous diagnostic data

We record a small set of anonymous diagnostic events that help us improve the service over time. These events let us answer questions like “what fraction of phones that request a pairing code actually complete pairing?” or “which integrations get the most use?” without ever needing to know which specific user is involved.

The events we record:

• Active-user counts. When you open the app on your paired phone, we increment daily, weekly, and monthly tallies. Each tally is a single count grouped by phone model and locale (your phone's language and region setting, for example “en-GB”); no row identifies you.
• Pairing-funnel events. When a pairing code is generated, when it is confirmed by the web app, and when an unused code expires. Where these events originate on the phone, we also record the phone model and locale. This shows us how many phones request a code but never complete pairing.
• Feature-usage counts. When you open a feature screen on the phone (for example the Authenticator, Weather, Habits, or a connected task or calendar service), we increment a per-feature counter for the day, grouped by phone model and locale.
• Retention cohorts. How many of the accounts created in a given week are still active one, two, three… weeks later. Each weekly cohort document holds only counts, with no identifiers.
• Subscription-funnel events. When a Stripe checkout starts, completes, is scheduled for cancellation, is cancelled, or has a payment fail. We also note the plan name (monthly or annual) where it is available. This shows us how many users who start checkout finish it.
• QR scan diagnostics. When you photograph a QR code to add an authenticator account, we record the outcome (success, or a short technical note on why decoding failed; never the account name or secret), the size and dimensions of the uploaded image, and the phone model and locale. The photograph itself is decoded in memory and never stored.

Where these events record a phone model, it is a normalised model token (for example “Nokia6300”) that we derive from the technical headers the phone sends, including its User-Agent line. The raw User-Agent string itself is not stored on any diagnostic row; it appears only briefly in the server logs described in section 1.5.

These records contain no user identifier, no session token, no IP address, and no account information. Where a timestamp is stored it is rounded to the hour, so it cannot be aligned with your paired-device activity to identify you indirectly. The active-user counter documents do not store a timestamp at all; each counter is identified by the day, week, or month it covers (for example “2026-W21” for the twenty-first week of 2026). Where the phone model is recorded it is the model the phone reports about itself (for example “Nokia6300”), which is not strongly identifying on its own, since many users share the same phone model. We therefore do not treat these records as personal data; they are described here for completeness rather than because UK GDPR requires it.

So that the active-user counts above are not inflated by repeat visits, three small dedup fields on your user record track the most recent day, week, and month you opened the app. We compare these against the current period before incrementing the tallies, so opening the app five times in one day adds one to each counter rather than five. The retention-cohort counts work the same way: your user record stores the week your account was created and which cohort weeks have already been counted, so each account adds at most one to each cohort tally. These fields live only on your user record and are deleted along with the rest of your data on account deletion.

Lawful basis: our legitimate interest in understanding how the service is used so we can improve it (Article 6(1)(f)). The dedup fields on your user record exist only to keep these counts accurate.

1.9 Connected integrations (tasks and calendars)

If you connect a third-party service to RetroRelay, we access that service on your behalf using only the access you explicitly grant during the provider’s own authorisation flow. We currently support two kinds: task services (Todoist, Google Tasks, Microsoft To Do) and calendar services (Google Calendar, Outlook Calendar); any integration we add later works the same way and will be listed here. We use this access for one purpose: to show that service’s items (your tasks or your calendar events) on your paired retro phone, and to let you manage them from the phone (for example create, edit, complete, organise, and delete).

The credentials that allow this, meaning the access token the connected service issues (plus a refresh token where the provider uses one), are stored on our server encrypted at rest with AES-256-GCM, under a key held only on the server. Your content itself is retrieved from the provider when you use the feature and during the short background checks that keep your phone's copy fresh; either way, we do not retain your tasks or events on our server beyond serving the request (the one exception, the names of your task lists and calendars, is described below), and a copy may be stored on your phone so it remains visible when the phone is offline. We do not sell or share this data, we do not use it for advertising, and we do not use it to develop, improve, or train generalised artificial-intelligence or machine-learning models.

Alongside the credentials we keep a small connection record for each integration: whether it is connected and shown on your phone, when you connected it and last used it, the permissions (scopes) you granted, the account identifier the provider assigns you (for example a numeric Todoist user ID, stored so that when the provider notifies us of a change we can route that notification to your account), the account name or email the provider displays for you (shown as “connected as” in your settings), the provider’s own account timezone where the provider exposes one (cached so dates on your phone render in that service’s timezone), and, for providers that support incremental sync, an opaque “position” bookmark issued by the provider, which contains none of your content, plus the names of your task lists or calendars (the one piece of your content this record does hold, kept so we can tell when a list or calendar is renamed, added, or removed between syncs; these names are included in your data export). All of it is deleted when you disconnect the integration or delete your account.

You can disconnect any integration at any time from RetroRelay’s settings. Each integration is its own sign-in with its own stored credentials — you can connect Google Tasks and Google Calendar (or Microsoft To Do and Outlook Calendar) with the same account or different ones. Disconnecting an integration always deletes its stored tokens, and we also ask the provider to revoke RetroRelay’s access — with one wrinkle: if the same provider account is still connected to another RetroRelay integration, the provider-side permission is left in place (revoking it would cut off the other integration), and we ask the provider to revoke it when the last integration using that account is disconnected. You can also review or revoke RetroRelay’s access from the provider’s side: for Microsoft services at account.live.com/consent/Manage, and for Google services at myaccount.google.com/permissions.

Google services specifically: RetroRelay requests the basic identity scopes (openid and email, used to show which Google account is connected, as described above), plus only the scope for the Google feature you connect: the read-and-write Google Tasks scope (https://www.googleapis.com/auth/tasks) for Google Tasks, and the Google Calendar event scope (https://www.googleapis.com/auth/calendar.events, plus the read-only https://www.googleapis.com/auth/calendar.calendarlist.readonly scope to list your calendars) for Google Calendar. RetroRelay’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Lawful basis: performance of a contract (Article 6(1)(b) UK GDPR); we access a connected service only to provide the synchronisation feature you have asked us to enable.

1.10 Habits

If you use the built-in habit tracker, we store each habit’s configuration and your completion history. The configuration covers its name, the reason you give for building it (if any), its cadence, any goal length, time of day, and measurement target; the history is a per-date log of the days you marked it done (and the amount, for measured habits). Habits are the one built-in feature whose content lives on our server rather than being fetched from elsewhere, so this data is included in your data export and deleted with your account.

Lawful basis: performance of a contract.

1.11 Two-step verification enrolment (web dashboard)

If you enable two-step verification for the web dashboard, we store an encrypted copy of its authenticator seed (AES-256-GCM, under a key held only on our server), one-way hashes of your recovery codes (we cannot read the codes back; we can only check a code you enter against its hash), the date you enrolled, and the time window of the most recently accepted code (kept so a just-used code cannot be immediately replayed). Disabling two-step verification deletes this record. Alongside it, your account carries a single “sessions valid after” timestamp that advances when you change your password or email, disable two-step verification, or use “Sign out of all sessions”. Anything issued before that moment stops being accepted.

Lawful basis: performance of a contract; this data exists solely to operate the security feature you enabled.

1.12 Emails we send you

RetroRelay has no mailing system of its own. The only emails you get are the ones the service needs to work. Firebase Authentication sends account emails on our behalf, to verify your email address and to handle password resets you ask for. Onelink, the merchant of record for subscriptions, sends billing emails such as receipts and renewal notices (see section 1.7). We may also email signed-in users about material changes to this policy, or about urgent service or security matters, as described in section 9.

We do not send marketing or promotional email. We run no newsletter and no mailing list, and we never give your address to anyone for marketing. There is nothing to unsubscribe from, because there is nothing non-essential to opt out of.

Lawful basis: performance of a contract for the account and billing emails; our legitimate interest in keeping you informed of material changes and security matters (Article 6(1)(f)) for policy-change and service notices.

1.13 Messages you send us

If you email us, whether for support, to make a data-protection request, or to raise a complaint, we hold that correspondence. That means your email address, what you wrote, and anything else you put in the message. We use it to answer you, to keep a record of what was asked and how we dealt with it, and to meet any legal obligation the message brings with it, such as logging a data-protection request. Our contact and support mailboxes are hosted on Google Workspace (see section 2).

Lawful basis: our legitimate interest in responding to correspondence and keeping a record of it (Article 6(1)(f)); and, where your message is a data-protection request, compliance with our legal obligations under UK GDPR (Article 6(1)(c)).

A note on sensitive information

RetroRelay does not ask for, and is not built to hold, special-category data. That is information about your health, ethnicity, religion, political opinions, sexual orientation, trade-union membership, or your genetic or biometric details. Some fields let you type freely, such as the name of a habit and the reason you give for building it, or the name you give an authenticator account, so please do not put anything sensitive in them. We do not set out to process special-category data, and if any turns up in a free-text field we treat it only as part of the feature you typed it into.

2. Who else processes your data (sub-processors)

We use a small number of third-party services to deliver RetroRelay. Each is bound by their own privacy terms and a data processing agreement with us.

• Google Cloud (Firebase Authentication, Cloud Firestore, Compute): handles sign-in, stores all the data described in section 1 (except server logs), and hosts our API server. Your data is processed under Google's Cloud Data Processing Addendum, which incorporates the UK Standard Contractual Clauses where international transfers occur. Everything is provisioned in the europe-west2 (London) region. It also hosts the mailboxes behind our contact and support addresses (Google Workspace). Email held in Google Workspace is covered by the same Google Cloud Data Processing Addendum and Standard Contractual Clauses, but unlike the rest of your data it is not tied to the europe-west2 region: Google may store and process it elsewhere under those terms.
• WeatherAPI.com: provides weather forecasts and location search. When you check the weather, we send WeatherAPI.com only the latitude and longitude of your saved location; when you first search for your city, we send the search text you typed. We never send your name, account, or device details. Their privacy terms apply to those requests.
• Stripe (your purchase itself is made through Stripe’s affiliate Sold through Link, LLC, branded “Onelink”, the merchant of record for subscription payments): processes subscription billing. When you start a paid plan we redirect you to Stripe’s hosted checkout to enter your card details, and afterwards to Stripe’s hosted Customer Portal to manage or cancel your subscription. Stripe holds your name, email, billing address, card details, and payment history; we do not. Receipts and renewal emails come from Onelink, and your card statement will show Onelink’s descriptor rather than our name. We only ever see the Stripe-generated identifiers listed in section 1.7. Stripe processes data under its Data Processing Agreement and acts as a separate data controller in respect of fraud prevention and regulatory compliance. International transfers are governed by the Standard Contractual Clauses incorporated into Stripe’s terms.
• Connected integrations (tasks and calendars): services you choose to connect so their items appear on your phone (described in section 1.9). While an integration is connected we hold an encrypted access token for it and exchange your data with that provider only to serve your requests on your phone. Each provider processes your data under its own terms: see Todoist’s privacy policy, Microsoft’s privacy statement, and Google’s API terms referenced in section 1.9 for Google Tasks and Google Calendar. These integrations are optional and active only while connected.

One more company your browser contacts directly. Once you sign in, your browser talks directly to Google’s Firebase services to keep your session and dashboard live. Google is already our processor for sign-in and storage (see above); this is simply how its service is delivered. Those requests unavoidably carry your IP address and user-agent, so Google receives that technical information. (The Firebase scripts themselves — along with fonts, icons, and every other script — are served from our own site, so if you are just reading our public pages and have not signed in, no third party is contacted to render them.)

We do not sell your data. We do not share it with advertisers. We do not use it for profiling or automated decision-making. We do not use your data to train artificial-intelligence or machine-learning models.

3. Cookies, local storage & similar technologies

RetroRelay stores only what the app needs to work. We use no advertising, analytics, or cross-site tracking technologies, so the web app shows no cookie-consent banner: there is nothing non-essential to consent to. Everything we place on your device is first-party and falls into one of these:

• A two-step-verification cookie (__Host-rr_mfa). Set only if you turn on two-step verification. It proves you cleared the check for the current session so you are not challenged again on every request. It is HttpOnly, Secure, and locked to our own domain.
• Your sign-in session. Firebase Authentication keeps your signed-in state in your browser's local storage and IndexedDB so you stay logged in between visits. Clearing it signs you out.
• Display preferences. Your light/dark theme, kept in local storage.
• Housekeeping markers. The email address you last signed in with (kept in local storage so we notice when your sign-in email changes and can update your billing contact to match), plus a few short-lived markers set only during an email change or account deletion so the confirmation step survives the sign-in redirect. Each holds at most your email address and a timestamp, nothing more, and each is cleared when its flow completes.
• An offline app cache. RetroRelay is a Progressive Web App, so your browser caches its own program files (scripts, styles, icons) to load quickly and work offline. No personal data is stored here.

All of these are strictly necessary or purely functional. None of them track you, and none leave your device for a third party.

Some actions hand you to an external provider's own pages, where that provider, not us, sets its own cookies under its own policy:

• Signing in with Google. Google sets its own account cookies on google.com to sign you in to your Google account, governed by Google's cookie policy. Signing in with an email address and password instead does not involve them.
• Subscribing or managing billing. You are taken to Stripe's hosted pages (checkout.stripe.com, billing.stripe.com), where Stripe sets cookies for session security and fraud prevention under Stripe's cookie policy.
• Connecting an integration. When you connect a third-party service so it can appear on your phone, you authorise it on that provider's own sign-in and consent pages, where the provider sets its own cookies under its own policy. This applies to every integration we offer.

In every case the cookies are set by that provider on that provider's own site, not by us, and we neither control nor read them. Connecting or using these services adds no tracking cookie of ours: the access we store lives on our server, not in your browser. The providers' roles in handling your data are described in sections 1 and 2.

4. Where your data lives

All your data is held in Google Cloud's europe-west2 (London) region. This includes Firestore (account data, devices, encrypted authenticator secrets, settings) and the Compute instance that runs our API server (server logs and the master encryption key used to protect the stored secrets).

Google may temporarily route operational data through other regions during normal cloud operations (e.g. for replication or support). Where this happens, it is governed by the Standard Contractual Clauses incorporated into Google's Cloud Data Processing Addendum.

There is one exception to the europe-west2 location above. Any email you send to our contact or support addresses is held in Google Workspace (Gmail), which Google may store and process in other regions under its Workspace terms and the Standard Contractual Clauses.

Payment data (card details, billing address, payment history) is processed by Stripe in Stripe's own infrastructure under their terms. The only Stripe-related data held by us are the identifiers in section 1.7, which sit alongside the rest of your data in europe-west2.

5. How long we keep your data

• Account, devices, authenticator secrets, habits, settings: kept until you delete them or delete your account. Account deletion removes all of these in a single, immediate operation; the two preconditions are that an active subscription must be cancelled first, and that we re-check your sign-in before deleting.
• Correspondence you send us: support and contact emails are kept for up to 2 years after your query is closed, then deleted. This covers data-protection requests too, where the exchange stays for the same period as our record that we handled the request.
• In-flight pairing requests: automatically purged 5 minutes after creation, or immediately on completion. The single-use state records behind sign-in and integration-connect flows are likewise deleted the moment the flow completes, and swept automatically if abandoned. Duplicate-delivery markers (webhook delivery IDs and phone offline-write IDs only, no content) are kept for 7 days.
• Subscription state: kept while you have an active paid subscription. After you cancel we retain the most recent state (status, customer and subscription identifiers, period end) so the “your previous plan ended on…” line on your account page can still render. All of it is deleted when you delete your account. Stripe retains its own payment records under their separate retention policies, which we cannot override.
• Connected-integration tokens (tasks and calendars): the encrypted access credentials for any integration you connect are kept while it stays connected, and deleted when you disconnect it or delete your account. We do not retain the task content itself on our server (see section 1.9).
• Server logs: retained for 30 days and then deleted by automated rotation.
• Anonymous diagnostic data (active-user counts, pairing-funnel events, feature-usage counts, retention cohorts, subscription-funnel events, QR scan diagnostics): retained indefinitely. These records contain no identifiers (see section 1.8), so they fall outside UK GDPR's storage limitation requirements and are kept for long-term trend analysis.
• Backups: We keep disaster-recovery backups of our Firestore data for up to 7 days: a combination of Firestore's point-in-time recovery (a continuous 7-day window) and a daily snapshot retained for the same length of time. We use these backups only to restore service after data loss; never for analytics, profiling, or any other purpose. If we ever need to restore from a backup, we re-apply any account deletions that took place between the backup being taken and the restore, so a deletion is never undone by a restore. Within 7 days of deletion, no copy of your data remains in our systems or backups, with one deliberate exception: the deletion ledger below.
• Deletion ledger: when you delete your account we write a single ledger entry holding only your internal account identifier and the deletion time. No name, no email, no content. It exists so that if we ever restore from a backup taken shortly before you deleted, the restore re-applies your deletion instead of resurrecting your data. It is purged automatically after 14 days (the 7-day backup window plus a safety margin).

6. Your rights

Under UK GDPR you have the following rights over the personal data we hold about you:

• Access: get a copy of the data we hold about you, in machine-readable form. Use the “Download my data” button on the Account page for an instant JSON export. It leaves out two kinds of field: security credentials it would be dangerous to hand out (session tokens, integration access tokens, and the web dashboard’s two-step-verification seed and recovery-code hashes), and internal operational counters (including the anti-double-counting markers described in section 1.8).
• Rectification: correct inaccurate data. Most fields (device name, location, account email) you can change yourself in the app.
• Erasure (“right to be forgotten”): permanently delete your account and every piece of data tied to it. Use the “Delete Account” button on your Account page. You will be asked to confirm your sign-in, and an active subscription must be cancelled first; the deletion itself is immediate and cannot be undone.
• Portability: receive your data in a structured, commonly used, machine-readable format. Our export is JSON, which fits this requirement.
• Restriction: ask us to stop processing your data while you contest its accuracy or our basis for holding it. Email us if you want to exercise this right.
• Objection: object to processing carried out under our legitimate interest (server logs and the aggregate usage counts in sections 1.2 and 1.8). Email us if you want to exercise this right.
• Complain: to us directly (see section 10; we acknowledge every data-protection complaint within 30 days), and/or to the UK Information Commissioner's Office at ico.org.uk if you believe we have mishandled your data.

We aim to respond to access, rectification, and erasure requests immediately (the dashboard tools are instant). For requests by email, UK GDPR allows us up to one calendar month to respond, extendable by two further months for complex cases. We will tell you if we need an extension.

Exercising any right is free of charge for the first request.

7. Security

We design RetroRelay to be safe against common attacks. Authenticator secrets are encrypted at rest with AES-256. Web sessions are protected by Firebase ID tokens transmitted over HTTPS. Sensitive endpoints are rate-limited.

A note about the legacy phone channel. Communications between paired retro phones (2003–2013 hardware) and our server use plain HTTP rather than HTTPS, with modern authenticated encryption (ChaCha20-Poly1305, the same cipher TLS 1.3 uses) layered on top, using a per-session key and a monotonic replay counter. This is because legacy phones cannot validate modern TLS certificates and would otherwise be unable to use the service at all. The trade-off:

• A passive observer on your phone's network can see that you are talking to RetroRelay, but cannot read or modify the request and response contents, and replayed captures of earlier traffic are rejected.
• The one residual gap is server authentication: there is no equivalent of “this server presented a certificate I trust”, so a network-positioned attacker could in principle impersonate api.retrorelay.app to the phone. Authenticator codes generated on a paired retro phone are therefore best treated as “medium-security”: appropriate for low-risk accounts, less appropriate for high-value financial or administrative accounts.
• The web app and all dashboard features run over modern HTTPS and are not affected by this trade-off.

No system is perfectly secure. If we ever discover a personal data breach that is likely to result in a risk to your rights, we will notify the UK Information Commissioner's Office within 72 hours and contact affected users as soon as is reasonable.

8. Children

RetroRelay is not directed at children. By using the service you confirm that you are at least 13 years old (or the higher age of digital consent in your jurisdiction). We do not knowingly collect personal data from anyone below that age. If you believe we have, please contact us and we will delete it.

9. Changes to this policy

We may update this policy as the service evolves. The date at the top shows when it was last changed. For material changes that affect what data we collect or how we use it, we will notify signed-in users by email or in-app notice before the change takes effect.

10. Contact

For any privacy question, data subject request, or breach concern, email us at contact@retrorelay.app. For postal correspondence: Adapanos Ltd, 483 Green Lanes, London, England, N13 4FG, United Kingdom.

We are not required to appoint a Data Protection Officer under UK GDPR, and we have not appointed one. All data-protection questions and requests go through the contact details above.

Complaints. If you think we have got something wrong in how we handle your data, you can complain to us directly using either contact route above; just make clear it is a complaint. We will acknowledge it within 30 days (usually much sooner) and tell you the outcome of our investigation without undue delay. Complaining to us is free, and you can also go to the ICO at any time. You do not have to come to us first.

If you are not satisfied with our response, you may lodge a complaint with the UK Information Commissioner's Office at ico.org.uk.

For technical details on how this data is protected, encryption algorithms, key derivation, and threat model, see how it works.