Privacy Policy

Who is responsible for your data

Dominique Top is the data controller for the hosted dlectroflow instance at dlectroflow.dev — an individual in the United Kingdom, running it as a personal, non-commercial hobby project. There is no company, no business and no trade behind it: nothing is charged for, nothing is sold, and there is nothing to buy.

Being the controller means I am the person legally answerable for how your data is handled here, under the UK GDPR and the Data Protection Act 2018.

Being a hobby project does not make it exempt

This is worth saying out loud, because it is the obvious thing to wonder and the obvious thing for me to try to hide behind. The UK GDPR does not apply to processing by an individual “in the course of a purely personal or household activity” (Article 2(2)(c)). That exemption does not cover this, and I am not claiming it.

Two reasons, and either on its own is enough:

• dlectroflow is offered over the public internet to other people, and it processes their data on infrastructure I control. That is not my personal or household activity, whatever my motive for building it.
• Even where someone uses it for purely personal purposes of their own, Recital 18 says the Regulation still applies to whoever provides the means for that processing. That is me.

So every obligation in this notice is a real one, and every right below is a real right. Being unpaid changes what this project can afford; it does not change what you are entitled to.

Getting hold of me

For anything to do with privacy, your data, or your rights, write to privacy@dlectroflow.dev. That address is monitored and it is the right route for every request in this policy — you do not need to find another one.

There is no data protection officer: Article 37 requires one only for public authorities, for large-scale regular monitoring of people, or for large-scale processing of special category data, and this is none of those. The person reading that inbox is the same person who wrote the code.

What this policy covers

This policy covers only the instance running at dlectroflow.dev.

dlectroflow is open source under the AGPL-3.0 licence, and it is built to be self-hosted. If you run your own copy, that instance is yours: youare its controller, your users’ data never touches anything of mine, and this policy does not apply to it. If you are using someone else’s instance, ask them for their policy — not this one.

What I collect, and why

Everything here falls into one of four groups. Nothing is bought from a third party, inferred about you, or collected in the background.

1. What you write

This is the bulk of it, and it is all typed by you or produced by using the app:

• Brain-dump items — the free text you capture, plus when you captured, triaged, snoozed, saved or completed each one.
• Tasks and steps — titles, step text, emoji, time estimates and the history of those estimates, what is done, and the scheduling intent you picked.
• Focus sessions — start and end times, pauses, planned and added minutes, and how the session ended.
• Daily roll-ups— the day’s counts, and a short AI-written narrative about your day (see Sending your text to an AI provider).
• Rewards — points events, your current streak, past streak records, badges earned, and the daily quote you were shown.
• Settings — voice, typeface, appearance, timer style, focus sounds, working days and hours, reminder times, freshness thresholds.
• AI usage counters — how many breakdowns have been requested, so a fair-use cap can be applied.

2. If you use it as a guest

You can use dlectroflow with no account at all. When you first arrive, a sandbox workspace is created for you and its identifier is put in a signed cookie. There is no name, no email address, and no sign-in — the sandbox is not linked to you as a person, only to that cookie.

One extra thing is stored for guests: a salted SHA-256 hash of your IP address, used purely to count AI breakdowns against the daily guest cap and the instance’s overall cap. The address itself is never written to the database — only the hash, and only with a secret salt, so it cannot be turned back into an address or matched against a list of addresses.

3. If you have an account

Accounts are invite-only. There is no sign-up form: your identity has to be on an allowlist before sign-in will work at all. Sign-in is through GitLab, and it is the only sign-in method.

• From GitLab: your GitLab user id, your username, and your email address if GitLab returns one. The only permission requested is read_user — no repositories, no code, no groups, no ability to act as you.
• The invitation record: the username or email address that was entered to invite you, an optional private note written by whoever invited you, and when the invitation was created and claimed. This exists before you first sign in — it is what makes the allowlist work.
• Your account state: your role, whether the account is active or revoked, your AI allowance and how much of it you have used, and when you were last seen.

4. Optional connections

• Google Tasks, if connected: an encrypted access token and refresh token, the granted scope and its expiry, plus the Google list and task identifiers for anything pushed there — so a change updates the existing task instead of creating a duplicate. Details in Connecting Google Tasks.
• Your own AI provider API key, if you save one: the key itself, encrypted, and nothing else — no account name and no billing details, because the key is all the provider needs and all the app asks for. Signed-in accounts only. Details in Sending your text to an AI provider.
• The end-of-day round-up email, if switched on: the email address you type in. It is off by default and guests cannot set one.

What is not collected

No analytics. No tracking pixels. No advertising. No profiling. No session recording. No device fingerprinting. No third-party scripts of any kind. This is not a policy position that could quietly lapse — there is no analytics or tracking package in the codebase at all, and because the source is public you can check that for yourself rather than take my word for it.

No payment details either: the hosted instance is free and there is nothing to pay.

One honest caveat about IP addresses. The application never stores your IP address, only the salted hash described above. But the web server sitting in front of it writes ordinary access logs, and those include IP addresses, as web server logs everywhere do. They are platform logs: kept only as long as they are useful for investigating errors and abuse, never joined to your account or your content, and never used for analytics.

My lawful basis for each purpose

The UK GDPR requires a lawful basis for each purpose, not one blanket basis for everything. Here is the honest breakdown, purpose by purpose.

• Running the app for someone with an account — storing and showing your tasks, steps, sessions, settings and rewards.
  Contract (Article 6(1)(b)). You accepted the Terms and asked me to provide the service; it cannot be provided without storing what you type into it.
• Running a guest sandbox for someone with no account.
  Legitimate interests (Article 6(1)(f)). My interest is letting you try the app without handing over an identity first — which is the more privacy-protective option, not the less. The data is only what you type, it is tied to a random identifier rather than to you, and it deletes itself within about a day. Weighing that against your interests, a trial that asks for nothing seems to be what most people would prefer; if you disagree, you can object.
• Signing you in and keeping your workspace yours.
  Contract (Article 6(1)(b)) for authenticating you and giving you access to your own workspace, and legitimate interests(Article 6(1)(f)) for the security machinery around it — signed sessions, and making sure one workspace can never read another’s data.
• Keeping the invitation allowlist.
  Legitimate interests(Article 6(1)(f)). Being invite-only is the main control that keeps a personal project’s data closed. It costs one username or email address per invitation and nothing else. If you were invited and would rather not be on the list, ask and it comes off.
• Generating AI task breakdowns — which means sending your task text to a third-party provider.
  Contract (Article 6(1)(b)). The breakdown is the feature you asked for, and it cannot happen without sending the text. This is deliberately notcalled consent: consent has to be freely given and freely withdrawable, and “withdraw it and the feature ceases to exist” is not a real choice, so labelling it consent would dress up a necessity as an option. If you would rather your text were not sent, do not use the breakdown — capture, tasks, steps, the focus timer and the rewards all work without it.
• Connecting Google Tasks.
  Consent(Article 6(1)(a)). Genuinely optional, separately asked for through Google’s own consent screen, and withdrawable at any time in Settings — which revokes the grant and deletes the stored tokens. If your access to this instance ends before you get round to it, the grant is withdrawn for you. Nothing else in the app stops working if you never connect it.
• The end-of-day round-up email.
  Consent (Article 6(1)(a)). Off by default. You type the address and switch it on; switching it off withdraws it.
• The guest fair-use cap — the salted IP hash.
  Legitimate interests(Article 6(1)(f)). The AI endpoint costs real money and is open to anyone with a browser; without a cap, one visitor can spend a whole day’s budget in a minute. The processing is minimised to a salted hash that is never the address itself, and it is deleted after 30 days.
• Backups, security, and keeping the service running.
  Legitimate interests (Article 6(1)(f)). Article 32 requires appropriate security in any case, and a service with no backups would be a worse deal for you than one with them.
• Answering a rights request, or a lawful legal demand.
  Legal obligation (Article 6(1)(c)).

Where I rely on legitimate interests, you can ask me for the balancing reasoning in more detail, and you can object — see Your rights.

Sending your text to an AI provider

This is the most significant thing that happens to your data, so it gets its own section rather than a line in a list.

To turn “sort out the tax return” into a list of small steps, the text has to go to a large language model, and that model is not mine. Anthropic (Anthropic PBC, United States) is the provider this instance uses.

What is sent

• When you ask for a breakdown: the task’s title, the steps currently proposed (their text, emoji and time estimates), and anything you typed into the “tell Claude how to adjust” box.
• Note where the title comes from.If you break down a brain-dump item, that item’s text becomes the task title — so the words you captured are sent. Brain-dump items you have not broken down are not sent anywhere.
• When the end-of-day roll-up is written (signed-in accounts only): the text of up to five steps you finished and up to three carrying over, so the narrative can mention them.
• When you overrun a focus stepand ask for a kinder estimate (signed-in accounts only): that step’s text and its current estimate.

What is not sent

The context sent alongside a breakdown, so the model knows roughly where you are in your day, is numbers and flags only — small integers, booleans and one preference. It contains no free text, no identifiers, no email addresses and no dates. Your email address, your GitLab identity, your Google tokens and your settings are never sent. The daily quote is generated from a fixed prompt containing nothing about you.

Training, and what happens to it there

I do not use your content to train anything, and Anthropic’s commercial terms state that they do not train their models on inputs or outputs sent through their API. Where the request is made on my API key — which is the default, and the case for everyone who has not saved their own — Anthropic processes this text on my instructions, as a processor, to answer the request and for nothing else. If you have saved your own key, the request is made on yours instead; see If you bring your own API key below.

Which provider, and why it matters

The code can talk to other providers — there is an OpenAI-compatible adapter for people self-hosting against a local model or another vendor — but which one is used is a deployment setting, chosen by whoever runs the instance, not something you choose in the app. On this instance that setting is Anthropic, and this instance uses Anthropic for every request — whoever is asking, and whether or not they brought their own key. If that ever changes here, this page changes with it and the effective date at the top moves.

If you bring your own API key

If you have an account, Settings lets you save your own API key for the AI provider. It is entirely optional — everything works without one — and guests cannot save a key, because there is no account to hold it against.

What saving a key changes:

• Your breakdowns are paid for by you, not by me. The instance’s fair-use cap on AI requests stops applying to your account, because it exists to protect my bill rather than to ration yours.
• The key is encrypted at restwith AES-256-GCM, the same way the Google tokens are, with the encryption key held in the deployment’s secrets rather than in the database. It is never displayed back to you, never sent to your browser, and never shown to anyone else — there is deliberately no “reveal my key” button. You can remove it in Settings whenever you like.
• The request is then made as you, so your own agreement with the provider governs it. Your text still travels from this server to the provider exactly as described above, but authenticated with your credentials — so it lands in your account with them and is subject to whatever terms you have accepted. The processing terms and transfer safeguards I rely on cover requests made on my key; they cannot cover requests made on yours.

And the significant thing it does not change: it is a key, not a destination. A key you save is used against this instance’s configured provider — Anthropic — and nothing else. It does not let you choose a different company, a different endpoint, or a different address for the server to send your text to, and there is no field in the app for any of those. That is a deliberate security decision rather than an oversight: a per-account setting that chose which host this server connects to would let anybody with an account aim it at a machine of their own choosing. Choosing your own provider is not something dlectroflow can do today, and if it is ever built, this page changes before it ships.

What the administrator can see about this is whether you have saved a key — a yes or no in the admin panel — and never the key itself.

Because Anthropic is in the United States, this is an international transfer of your data. It is not buried in a list — see Data that leaves the UK.

Connecting Google Tasks

Connecting Google is optional. Everything else works without it, and steps can be exported as a calendar file instead.

One permission, and only one

The connection requests exactly one OAuth scope:

https://www.googleapis.com/auth/tasks

Nothing else. No Gmail, no Calendar, no Drive, no Contacts, no access to your profile or photos, no ability to read anything outside Google Tasks.

What it is used for

Creating and updating tasks in a Google Tasks list inside your own connected Google account, so that a scheduling tool which syncs from that list can find them and book time for them. What is written is a task title (built from your task and step text, with a duration) and a due date.

The only thing read from your Google account is the list of your Google Tasks list names, so the right list can be found to write into. Nothing from your Google account is copied into dlectroflow beyond the list and task identifiers needed to update the right task later.

Whose Google account it goes into — yours

If you have an account here, you can connect your own Google account, and the tasks dlectroflow creates are written into yourGoogle Tasks. Not the administrator’s, and not a shared one. Everyone who connects Google connects their own: there is one connection per person, each independent of the others, and each connected and disconnected by the person it belongs to.

Your connection is not visible or usable to anyone else — including me, as the person who administers this instance. The stored credential is held against your account and can only ever be looked up by the account it belongs to. There is no administrative route to somebody else’s Google connection: the admin panel cannot use it, cannot show it, and does not even disclose whether you have one. That is not a promise I am asking you to take on trust — an automated check reads the source on every change and fails the build if any query for a stored credential is not tied to the account making the request.

Guests cannot connect Google. It needs an account, because the connection has to belong to somebody.

Tokens, and how to disconnect

The access and refresh tokens are encrypted at rest using AES-256-GCM. The encryption key is held in the deployment’s secrets, not in the database, so a copy of the database on its own yields no usable tokens.

Disconnecting in Settingsasks Google to revoke the grant and then deletes your stored tokens — the deletion happens whether or not Google’s revoke call succeeds, so dead tokens are never left lying around.

The same happens if your access here is withdrawn. If your account is frozen by the administrator, or it is deleted, dlectroflow asks Google to revoke the grant first and then deletes the stored tokens — the same two steps, without you having to ask for them. That is a deliberate choice: the grant only ever existed so this app could write your tasks, and a frozen account can no longer reach the Disconnect button, so leaving the grant live would hand you a permission you could not withdraw here any more. Nothing in your Google account is deleted by this. What ends is dlectroflow’s access to it.

Being straight about the limits of that. Revoking is a call to Google, and that call can fail — a network problem, or a grant Google has already expired. When it does, your tokens are still deleted at this end, so the app is left with no way to try again and the grant can stay listed in your Google account until you clear it. The same is true of any connection that was frozen or deleted before this behaviour existed.

So the route that always works, and the one that does not depend on me at all, is your own Google account’s security settings: you can withdraw dlectroflow’s access there at any time, and it takes effect immediately whatever is or is not stored at this end.

Who else is involved

A short list, and it is the whole list. Your data is not sold, rented, traded or shared for anyone’s marketing — mine included.

• Google Cloud Platform — hosting. The servers, the database and the backup storage all run here, in the UK. A processor: it holds the data but may only act on my instructions.
• Anthropic (United States) — the AI provider that generates breakdowns, roll-up narratives and re-estimates. A processor, and an international transfer.
• Google Tasks — only if you connect it, and only to write into the connected Google account.
• Resend(United States) — only if you switch on the end-of-day round-up email. It receives the address you gave and the email itself, which contains the day’s counts and the AI-written narrative. A processor, and an international transfer. Leave the feature off and Resend is never contacted.
• GitLab— the identity provider for sign-in. GitLab is not my processor: it is a service you already have an account with, and when you choose to sign in, your browser goes to GitLab and GitLab tells me your id, username and email address. GitLab’s own privacy notice governs what GitLab does.

Beyond that: nobody. No advertising networks, no data brokers, no analytics vendors, no “partners”. I would also disclose data if I were legally required to — a court order or a valid demand from a public authority — and I would tell you unless I were prohibited from doing so.

Data that leaves the UK

Your stored data sits in the UK. Two flows leave it, and both are named plainly rather than folded into a list of “service providers”.

• Anthropic, United States— the task text described above. The transfer relies on the standard data protection clauses permitted by Article 46 UK GDPR: the EU standard contractual clauses together with the UK International Data Transfer Addendum, as incorporated in Anthropic’s data processing terms.
• Resend, United States — the round-up email, only if you turn it on. Same safeguard: standard contractual clauses with the UK Addendum.

Two more worth being straight about. If you connect Google Tasks, tasks are written into your own Google account; Google LLC is certified under the UK Extension to the EU–US Data Privacy Framework, and its cloud terms also carry the standard clauses and UK Addendum. And although the hosting is in the UK, Google may access it from outside the UK for support purposes under those same terms.

You are entitled to a copy of the safeguards relied on. Ask at privacy@dlectroflow.dev and I will point you at them.

Where your data is stored

The application and its Postgres database run on Google Kubernetes Engine in London, United Kingdom (GCP europe-west2). The database is backed up nightly at 02:00 UTC to Google Cloud Storage in the same region.

So your data at rest — live and backed up — is in the United Kingdom.

How long I keep it

• Guest sandboxes expire on a fixed time-to-live — about a day from the moment the sandbox is created — and a job at 03:30 UTC each night deletes the expired ones and everything inside them. Worth knowing: continuing to use it does not push the expiry back, so a guest sandbox is one day, not a rolling one. If you want to keep what you captured, you need an account.
• Guest AI counters — including the salted IP hash — are deleted after 30 days by the same nightly job.
• Account data is kept for as long as you have an account, and until you ask for it to go. Being honest about a gap:if an account’s access is revoked, its content is not deleted automatically today. It stays until it is deleted by hand. Email me and it will be.
• Google tokensare kept until you disconnect, until your access here is revoked or your account is deleted, or until the grant is revoked at Google’s end — at which point they are cleared.
• The round-up email address is kept until you clear it or turn the feature off.
• Backups are deleted after 30 days. This is the one that matters for erasure: when something is deleted it is gone from the app immediately, and gone from the backups within 30 days. I am not going to pretend backups do not exist.
• Cookies — see the table in Cookies.

How it is protected

• Encrypted in transit. HTTPS everywhere, with HTTP redirected and HSTS set for two years including subdomains, plus a strict Content-Security-Policy.
• Encrypted at rest where it counts. OAuth tokens and any stored provider API key are encrypted with AES-256-GCM, with the key held in the deployment’s secrets rather than the database.
• IP addresses are hashed, never stored. SHA-256 with a secret salt, as described above.
• No open sign-up. Sign-in is invite-only against an allowlist, so an attacker cannot simply create an account and start looking around.
• Sessions are signed tokens in cookies marked HttpOnly, SameSite=Lax and Secure.
• Workspace isolation is enforced structurally, not promised. A check in the build pipeline reads the source and fails the build if any database query against workspace-scoped data is not constrained to a single workspace. It is not a policy anyone has to remember: a change that broke the isolation would not merge.
• What an administrator can see: counts, never content. The admin panel shows a handle, a role, a status, an AI policy and how many breakdowns an account has used. It cannot show your tasks, your steps, your notes, your email address or your stored key — and the same automated check is what keeps that true rather than my word for it.
• Automated scanning for known vulnerabilities and risky code patterns runs on every change before it can ship.

And the honest limits. This is a personal project run by one person. There has been no third-party security audit. Encryption protects tokens and keys, not the task text itself, which has to be readable by the application to work. The source is public, so you can form your own view rather than trust an assurance — and if you find something wrong, the repository has a security policy telling you how to report it.

Cookies

There are six, they are all strictly necessary, and that is the entire list.

• df_guest — identifies your guest sandbox so the app can show you your own work. Without it an anonymous visitor has no workspace and the app cannot function. About a day.
• df_owner — your signed-in session. 30 days, or until you sign out.
• gitlab_oauth_state and gitlab_pkce_verifier — protect the GitLab sign-in round trip against request forgery and code interception. Deleted the moment sign-in finishes. 10 minutes.
• google_oauth_state and google_pkce_verifier — the same protection for connecting Google Tasks. 10 minutes.

All six exist solely to deliver the service you asked for, so under the Privacy and Electronic Communications Regulations no consent is required for them — which is why there is no cookie banner. There is nothing to consent to: no analytics cookie, no tracking cookie, no advertising cookie, no profiling cookie, and no third-party cookie of any kind.

Separately, your light/dark theme choice is stored in your browser’s own local storage under df-theme. It never leaves your device and is never sent to the server.

Sensitive information, and a word about ADHD

dlectroflow is built for people with ADHD, so let me be direct about what that does and does not mean.

Using this app is not a diagnosis, and I do not record why you use it. There is no health field, no diagnosis field, no questionnaire, and nothing infers anything about your health, your mind, or how you are doing. It is a to-do app with a kind tone. Plenty of people use it who have never been near an assessment.

What I cannot control is what you type into a free-text box. If you write “phone the psychiatrist about the dose change”, that is health information, and it is treated exactly like every other task: stored, and sent to the AI provider if you ask for a breakdown of it. Where you choose to include details like that, you are sharing them knowingly and explicitly, and it is that explicit consent — Article 9(2)(a) UK GDPR — that permits me to hold them. You can delete the item yourself at any time, or ask me to.

A practical suggestion, not a rule:the app works just as well if you write “phone the clinic” and keep the clinical detail out of it. Nothing is lost by being vague, and it is the simplest way to keep sensitive detail out of a system you did not build.

No automated decisions about you

Nothing here makes a decision about you. The AI suggests a list of steps; you accept them, edit them, reorder them, or throw them away. There is no scoring of people, no eligibility decision, no ranking, and no automated decision producing legal or similarly significant effects — so the Article 22 rules on automated decision-making do not come into play.

Streaks, points and badges are counters of what you did, calculated automatically. They produce a number on your own dashboard and nothing else: no consequence, no judgement, nothing shared with anyone.

Your rights, and how to use them

Under the UK GDPR you have all of the following. To use any of them, email privacy@dlectroflow.dev — one address, no forms.

• Access — a copy of the personal data I hold about you, and confirmation of how it is used.
• Rectification — correction of anything inaccurate or incomplete. Most of it you can edit yourself in the app.
• Erasure — deletion of your data. Ask, and it goes.
• Restriction — you can ask me to stop using your data while a dispute about its accuracy or my basis for holding it is sorted out.
• Portability — your data in a structured, machine-readable form. I will send it as JSON.
• Objection — you can object to anything I do on the basis of legitimate interests (the guest sandbox, the allowlist, the fair-use cap, security and backups). Tell me and I will either stop or explain the compelling grounds for continuing.
• Withdrawing consent — disconnect Google in Settings, or switch the round-up email off. Either takes effect immediately. You can also just ask me.

How that actually works here

There is no self-service export button yet. I am telling you rather than implying otherwise: access, portability and erasure requests are handled by me, by hand, from that email address. It is less slick than a download link and it is exactly as binding.

I will respond within one month of your request, which is the statutory deadline. If a request is genuinely complex I may extend that by up to two further months, and if I do, I will tell you why inside the first month. There is no charge, unless a request is manifestly unfounded or excessive.

I may need to check you control the GitLab identity your account is linked to, so that I do not hand your data to somebody else claiming to be you.

One real limitation, for guests.A guest sandbox has no identity attached to it — that is the point of it — so I have no way to find “your” sandbox from an email address. It will expire and be deleted on its own within about a day. To be rid of it sooner, clear the df_guestcookie or use a private window. If you want it deleted now and can read the sandbox identifier out of that cookie in your browser’s developer tools, send it to me and I will delete it.

Nothing in this policy or in the Terms limits your rights under UK data protection law.

Complaining to the ICO

If you think I have handled your data badly, please tell me first — I would genuinely rather fix it than have you discover I cannot be bothered. But you do not have to, and you lose nothing by going straight to the regulator.

The UK supervisory authority is the Information Commissioner’s Office:

• ico.org.uk/make-a-complaint
• Helpline: 0303 123 1113
• Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

Children

dlectroflow is not intended for children under 13. In the UK, 13 is the age at which a child can consent to an online service like this one on their own behalf.

Accounts are invite-only, so I know who has one. Guest use needs no account, which means I have no way to verify anyone’s age — so if you are a parent or carer and believe a child’s data is in here, email privacy@dlectroflow.dev and I will delete it.

Changes to this policy

The effective date at the top of this page is its version. If the substance changes, that date changes with it in the same breath.

Because this is an open-source project, the complete, timestamped history of every word on this page is public in the source repository. You can see exactly what changed and when — which is a considerably better change log than an email saying a policy has been updated.

There is no in-app notification system yet, so the effective date and that history are the reliable ways to check. If a change would materially reduce your protections and the law requires your consent, I will ask before it takes effect, not after.