Key Please

Privacy
policy.

A privacy policy is a claim about what the code does. Every sentence here was written against the app and the server as they are built, and each one is deliberately narrower than it could be.

Last written against the code on 6 September 2026

Where this page stands

Key Please has not been released yet. This page is here early so it can be read before anybody installs anything.

It is not legal advice and no solicitor has checked it. Where a question is still open, we say so rather than sound certain.

There is no contact address yet. One will be here, and on the App Store listing, before release.

The short version

  • No account, no password, no email address. Your phone identifies itself with an id it makes up.
  • We cannot see which apps or sites you chose to block. Apple seals those even from us.
  • We cannot see your messages, browsing, location, contacts, photos, health data, or how long you spend on anything.
  • Counting is off unless you turn it on, and on a child’s phone there is nothing to turn on.
  • No analytics company, no advertiser, no crash reporter, no data broker. There is no outside company’s code in the app at all.
  • What you type when you ask for something is deleted a week after your request is answered.

You will not find “we never collect any personal data” or “your data never leaves your device” here. Both stop being true the moment a request reaches a second person, and the whole product depends on that happening.

What stays on your phone

The first names you typed for the people holding your keys
So the app can say “Ask Dave” rather than “Ask your keyholder”.
What you called each block
Shown to you, and to the person holding that key.
How many times you opened something and walked away
The number this app exists to move, and it is yours to look at. If you switch the counting on, the server is told it happened that day, and nothing else.
Which apps and sites you chose
Nowhere anybody can read. Apple seals those even from us: the app cannot see the name of what you picked, and the server is never sent it.
The minutes left on a daily time limit
Worked out on your phone and kept there. The server is told the limit and never a minute of what you used.

What leaves your phone, and why

There is a server. It exists so a request can reach a second person, and so each of you can be told when the other’s phone has gone quiet. This is everything sent to it.

An id your phone makes up for itself
So the server knows which phone is which. Not your Apple Account, not the advertising identifier, not your number.
The first name of the person holding the key, and what you called the block
They are what a request says. The person holding it sees both anyway.
Your own first name, if you gave one
So somebody holding two people’s keys can tell who is asking.
The reason you typed, and how long you asked for
The reason is the whole point of asking.
Their answer, and any note they wrote
It has to get back to you.
A push token, if you turned notifications on
So Apple can wake the right phone.
The moment your phone last checked in
The moment, and nothing about what you were doing. It is how either side is told a phone has gone quiet.
That the app was deleted and put back, if it was
Once, with the name of the block it concerns. Not when, not how long it was gone, not what happened while it was.
A daily time limit, if one is set
How many minutes a day, who set it, and when. Never how many were used.
That a key is ending, and when
So the person you are standing down hears it from the app rather than from silence.

None of that is anonymous. It is tied to the id your phone made up, and Apple counts an id like that as identifying you even when it says nothing else about you.

Who else is involved

Two companies are in the path. Neither is a partner, an advertiser or a data broker. They are named because a policy listing what we hold, but not who else touches it, is not finished.

Cloudflare

They run the server and the database. The database sits in western Europe, and the code runs at whichever of their locations is nearest your phone.

Your IP address reaches them, as it does with every website you visit. Our own logs carry the first few characters of the id your phone made up.

Our own tables have no column that could hold an IP address. That is not the same as saying nobody in the path ever sees one, so both halves are written out rather than the flattering one.

Apple

They deliver the notifications. The reason you typed is never inside one. A banner says who is asking, which block, and how long for, then points the reader into the app. A note written back is the same: the banner says only that one exists.

What does go to Apple is the push token, the block name and the first names. Those are the standing labels of the arrangement, and both of you already know them. A sentence somebody typed just now is not, and it stays inside the app.

Nobody else

No analytics company, no advertising network, no crash reporter, no split testing tool, no data broker. Adding one would quietly make most of this page false, which is why it is written down as a line rather than left as a habit.

What the person holding your key can see

The requests you send them, for the one block they hold. Not your other blocks, not who else holds a key, not anything you did not deliberately send.

Never your location, your app list, your browsing, your messages, or how long you spend on anything. None of that reaches the app at all, so there is nothing for us to hand anybody.

If you named a backup, they see a request too, but only once it has waited three hours. Until then they see that they are the backup on a block of yours, and its name, and nothing else.

What each of you is shown about the other’s phone

The server records the moment each phone last contacted it, and each of you is shown the other’s. The alert saying somebody has gone quiet is built from it, and promising that alert without checking would be dishonest.

You are also shown whether their notifications are switched on. They are not shown that about you.

Two things they are told about your phone

  • Your phone has not checked in for a day and a half. The message names the ordinary reasons, a flat battery, no signal, or the app having been removed, and picks none of them, because from here they look identical.
  • The app was deleted and put back. That one is said flatly, because your own phone can prove it. It carries no reason, and it adds that the block came back switched off, because Apple does not keep the app choices through a reinstall.

Neither notice says anything about what you did, and neither ends anything.

Which screen you open is never reported. Opening the app counts as checking in, so that moment moves; what you looked at does not leave the phone.

When a key ends, they are told

If you stand somebody down, replace them, or delete the block, their phone is told: what you called the block, the moment it stops, and which of a short list of words applies. A fact and a date, never a reason.

They are told because the alternative is a key that quietly stops working one morning, and a person left to work out for themselves that they were removed.

The counting, and the switch that is off

The app is being tested against one question: is the person holding the key still replying on day seven? Answering it needs a little counting, and this section is all of it.

It is off unless somebody turns it on

Off on the phone and off on the server. A phone the server has never heard of counts as a no, because no answer is not an answer. The switch is in the app, under Settings, then Privacy.

What is counted

A number per pairing, per whole day, of five things: the block screen appeared, you pressed “Not worth it”, the other phone checked in, a way out was used, a pairing ended. For the last two, one word from a fixed list saying which.

What is never counted, and cannot be

Not as a promise about our intentions. The table has no column that could hold any of it.

  • No times of day. Only whole days since the pairing started. A record saying a named person’s phone reached for a bookmaker at twenty to three in the morning is a gambling record, and this app must not hold one about anybody.
  • No list of what a block covers. Not in the counts and not anywhere else. The server used to keep one, on the pairing. It was deleted on 6 September 2026, the column with it, because nothing on the server ever read it. There is no longer a place to put one.
  • No app opens, no screen views, no session lengths. A list of when you opened a betting blocker is a record of when you wanted to bet.
  • No minutes used against a daily time limit. Not today’s and not any day’s. There is no column for it.
  • No block names, no reasons, no notes, no free text of any kind. The server checks every field against a fixed list and throws away anything else, rather than trusting the app not to send it.
  • No IP addresses, no location, no advertising identifiers and no push tokens in the counts. Your IP address still reaches Cloudflare, as it does on any website.

Turning it off deletes what is already there

Not just future counting. Switching it off deletes every count already held on the server, not only the ones on your phone, and throws away anything queued rather than sending it later. Nothing is written down while it is off.

This is analytics, and we say so

“We do not use analytics” would be false here. No outside company is involved, and the app’s own server counts five things a day. Both halves are true and you should have both.

On a child’s phone, none of the counting happens

An adult can set this app up on a child’s phone and hold the key themselves. The app says so to the server on its first call, and the server writes it against that phone for good.

From then nothing is counted about that phone or that pairing. Not one row. Not the block screen appearing, not a change of mind, not a way out being used.

There is no switch, anywhere

Not on the child’s phone and not on the adult’s. If a child’s phone asks the server to turn counting on, the server refuses. If the adult turns their own counting on, which they are entitled to do, it does not start counting the child. Anything counted before the app said whose phone it was is deleted, not merely stopped.

The list of what is blocked is not stored either

For an adult it is kept so the counts can be grouped, and only while counting is on. A child’s pairing has no counts to group and no switch that could make any. All that would be left is a record saying a named child is blocked from betting and adult sites, kept for no reason. So it is not kept.

The two notices are not switched off, though

A child’s phone is not exempt from them. If it stops checking in for a day and a half, or if the app is deleted and put back, the adult holding the key is told, in the same words as anybody else. The page written for the child says so as well.

What is still collected, because the app cannot work otherwise

The id the phone made up, the child’s first name if one was given, what the adult called the block, the sentence the child types when they ask, how long they asked for, and the answer. All of it goes to the person holding the key, which is the point of it, and it is deleted on the schedule below.

The child mode has not launched

Nothing in this section is switched on for anybody yet. The UK has a code for services children are likely to use, and it requires an assessment before launch. Ours is written and has not been reviewed by anybody qualified. Until it has been, there is no child mode.

When there is, it will be for the United Kingdom and the European Union. Whether it can lawfully be offered in the United States is an open question: the rules there require a verified parental consent, and nothing in this app can verify that anybody is a parent.

The same thing, in fewer words Written for the person whose phone it is, whatever age they are

How long anything is kept

The reason you typed, and the note they wrote back
Deleted seven days after your request is answered. A request nobody answers opens by itself after eight hours, so the seven days always start, even if both phones go quiet.
The counts, the notices, and the record that a request happened
Deleted after ninety days, by a job that runs nightly whether or not anybody opens the app.
Your blocks and your pairings
Kept until you end them or erase them.

Both of those deletions have been watched actually running, not just read in the code. A retention promise nobody has watched run is a promise rather than a behaviour.

Erasing everything

Deleting the app removes what is on the phone. It does not remove what the server holds. Those are two different things and this page will not pretend otherwise.

The control, and where it is

In the app: open Settings, then the privacy section, then the screen listing what is collected. Erasing everything is at the bottom of it.

You type the word ERASE first, and the server checks that word as well as the app. Every block is lifted before anything is deleted, so nobody is left with a blocked phone and no way to open it.

What it removes

  • Every block that phone owns, and with it the whole request history: every sentence typed and every note written, immediately, rather than after seven days.
  • Every count and every notice held about those pairings.
  • The phone’s own record: its push token, when it last contacted the server, and its settings.

What it deliberately does not do

If you were holding somebody else’s key, that block is still up on their phone. Deleting the pairing would leave a phone blocked with nobody in the world able to open it, which is the worst thing this app could do to anybody.

So you come off the pairing and the pairing stays. The block’s owner is told nobody holds their key any more, and what happens to the block is their decision. They are not stuck: every request opens on its own after eight hours, and they can end the pairing on the spot.

What survives, and why

The first name the block’s owner typed for you stays in their own block. Taking it would blank their screen, and with your id off the row it is a word in somebody else’s notes with nothing left to link it to a person.

Two small tables are also left alone. Neither holds anything traceable to a phone, and both delete themselves anyway.

  • One stops the same batch being counted twice if your phone had to retry. It holds a random number and the moment it arrived, and nothing in it points at a phone. Deleted after ninety days.
  • The other is the counter behind the limit described further down: a scrambled version of the request, a day, and a number. Deleted after two days. It also limits erasing, so wiping it would let an erasure reset its own limit.

The server looks for the rows again before it says it is done, and if any are left it says so rather than claiming success. Erasing twice is not an error: a phone that lost the answer to a flat battery has to be able to ask again.

Ending a pairing is not erasure

Standing somebody down takes their key away: after it, that phone is shown nothing about the pairing and cannot answer for it. The record stays, because a deleted record cannot tell the old keyholder anything and they have to be told. It ages out on the schedule above.

Your rights, and what we can actually do today

Under UK and EU data protection law you can ask for a copy of what is held about you, ask for it to be corrected, ask for it to be deleted, object to it being used, and complain to a regulator. One of those works properly today, one works in part, and the rest do not work yet.

Deletion
Works, through the erase control above. It needs no proof of who you are, because it is operated from the phone whose data it is.
Correction
Partly. The names you typed, and what you called your blocks, can be edited in the app.
A copy, objection, restriction, portability
No way to do any of it yet. Doing it by post or email needs a contact address, and there is not one published. That has to be fixed before release, and it is on the list of things blocking one.

Because there are no accounts, we cannot look you up by name or email. The id your phone made up is the only handle there is, and it lives on your phone.

Complaining

If you are in the United Kingdom you can complain to the Information Commissioner’s Office. You do not have to raise it with us first, though we would rather you did once there is an address to raise it to.

Information Commissioner’s Office ico.org.uk, the UK regulator for data protection

Why we are allowed to handle any of this

For an adult blocking their own phone: delivering the service they asked for. For the counting: your consent, which is what the switch is.

For the person holding a key, whose first name was typed by somebody else before they agreed to anything: our legitimate interest in getting the request to them, which is the only reason their name is held at all.

These are our position rather than a settled answer, and they are among the questions written down for a solicitor.

The categories, and the sentence you type

Some of what this app blocks is not neutral. A block covering adult sites is a person having asked for pornography to be blocked on their own phone, and a block covering betting sits close to something that is, for some people, a recognised health condition.

The app never says so, never diagnoses anybody and never infers anything about anyone. A person holding a key makes a human decision. Nothing is decided about you by a machine.

What the design does about it: the server keeps no list of what a block covers. It kept one until 6 September 2026. Nothing ever read it, so it was deleted along with the column it sat in, and there is no longer anywhere to put one. Nothing about this is sent to another company, used for advertising or profiled. The apps and sites themselves are unreadable to everybody, including us.

A link inviting somebody to hold your key carries no part of it either. The name you gave the block travels in a part of the address that no server, and no chat app fetching a preview, ever sees. What the block covers travels in neither part, because a link that shows somebody blocks betting is a link that tells whoever else reads that message.

You can type anything into a reason, including something you would not want kept. It goes to the person you sent it to and nobody else, and it is deleted seven days after they answer.

How this is kept safe, and the trade-off in it

  • Everything travels encrypted. There are no cookies and no sessions.
  • Only the person holding a key, or the backup, can answer a request. That is checked on the server, because the app is running on the phone of the person being blocked.
  • Only the blocked phone can end its own pairing. The person holding the key cannot end it for them.
  • The server turns a phone down if it asks for the same thing far more often in a day than a real phone would. Reading your own state and answering a request are never turned down, because those are how somebody gets let through.
  • Errors never hand an internal message back to a phone.

The trade-off, stated rather than left out: the id your phone made up is what authorises it, so anybody holding one could act as that phone. There is no password and no second step, which is the price of a product with no accounts. Ids are made by the server, so a phone cannot claim somebody else’s.

The backup file

The backup the app writes holds the first names of the people holding your keys and the reasons you typed. It is a plain file, it is not encrypted, and it goes wherever you save it. It is never sent to us. The screen that makes it says the same thing.

When this page changes

When the code changes, this page is wrong until it is changed too. The date at the top says when it was last written against the code. If something here has stopped being true and we have not caught it, that is a fault worth telling us about, once there is an address to write to.