Safeleaf — Privacy Policy

Last updated: 8 October 2026

Safeleaf is published by n12n. Contact: n12n.can@proton.me

The short version

Safeleaf collects nothing about you, and there is nothing about your family we are able to read.

There is no Safeleaf account. We do not receive your data or your child's data in any form we can open.

Everything the app knows lives on the phones it is installed on. When a parent's phone and a child's phone are on the same wifi, they talk to each other directly. When they are not — you are at work, they are at school — the few things that need to cross go through our relay, sealed on one phone so that only the other can open them. The relay holds those sealed messages in memory, cannot read or change them, and forgets them within a week. Since 4 October 2026 that is how a parent unlocks a phone, answers a request and sends rules from away from home; the section The relay below says exactly what it carries and what it can see.

We do run a website and a relay, and the honest exceptions come from those:

• If you type your email address into the waitlist form, we have your email address — and, saved beside it, the address you sent it from and the browser you sent it with, because Canadian anti-spam law says we must be able to show when and from where you agreed to be emailed. That is everything Safeleaf ever holds about anyone.
• Setting up a child's phone downloads the app from mysafeleaf.ca. Like any download, our host sees that a request was made, from some address, at some time. It carries no name, no account and nothing about your family.
• The relay, described above and in its own section below, is the third place the app meets anything of ours. It sees that a phone made a request, from some address, at some time, to a mailbox whose name is derived from your pairing and means nothing to us. It cannot open what is in the mailbox.
• Beyond the relay the app contacts us again only if you ask it to. A parent can turn on update checking for the child's phone, and it is off unless you do. With it on, that phone asks mysafeleaf.ca once a day which version of the app is published — a few hundred bytes — and, if you chose to have it install updates by itself, downloads the app when there is a newer one. Our host sees the same thing it sees for any download: a request, from some address, at some time. It still carries no name, no account and nothing about your family, and it still says nothing about what the phone is used for. Turn it off and the phone stops asking.

The website below says exactly what happens to both.

Two commitments hold regardless of what we build later, and we would rather be held to these than to a claim about our servers:

• Everything Safeleaf relays is sealed so that we cannot open it. This was a promise about the future until 4 October 2026, when the relay went live; it is now a description of what it does. If it ever stops being true, this policy and the Google Play Data Safety listing will say so before it ships, not after.
• No system we run will ever be able to unlock your child's phone or add itself as a parent. Recovery is a code we show you once and never keep a copy of. There is deliberately no master key on our side, because a master key is a thing that can be stolen.

What the app stores, and where

On the child's phone, Safeleaf keeps:

• the network policy — which apps may use cellular, which may use wifi
• active temporary unlocks and when they expire
• an audit log of which parent changed what, and when
• per-app foreground time and per-app data usage, read from Android's own usage statistics
• the public keys of the parents it trusts

On the parent's phone, Safeleaf keeps:

• the policy being authored
• that parent's own signing key, held in the Android Keystore and marked non-exportable, so it cannot be read out by Safeleaf or anything else
• a copy of the activity most recently read from the child's phone

None of this is transmitted to us in a form we can read. It moves between the parent and child phones directly over your own local network, or by one phone showing a QR code that the other photographs — that happens in both directions, the parent holding up an unlock and the child showing the code that pairs a parent to it — or by a number read aloud down the phone, or, when the two phones are apart, sealed through the relay. The activity figures and the list of apps on the child's phone never use the relay: they cross only on your own wifi.

How the two phones find each other, and what that means on a shared network

The child's phone shows its address; the parent's phone is told it. When a parent's phone does not know where the child's phone is — the first time, or after the wifi handed it a new address — the child's phone puts the answer on its own screen: a QR code for a parent standing in the room to scan, or a short number the child can read down the phone to a parent who is not. The parent's phone remembers it and goes straight there afterwards, so this is something you do occasionally rather than every time.

Nothing is announced, and nothing is searched for. Neither phone puts anything onto the network to find the other. The child's phone does not appear the way a printer or a speaker does, and the parent's phone does not ask the network who is out there. On school, café and friends' wifi, a phone running Safeleaf is not distinguishable from one that is not — which is the whole point, because "there is a managed phone in this room" is a fact about a child and nobody else's business.

The address is not a password, and holding it grants nothing. It is a hint about where to knock. Every exchange is sealed with the key the two phones agreed when you paired them, so a wrong number, an overheard one, or a guessed one reaches a phone that will not answer it. That is what lets the spoken version be short enough to say out loud, and it is why handing it to the wrong person costs you nothing.

The child's phone does listen, and that is the part of this visible to somebody else. Safeleaf keeps a small server running on the child's device for the parent's phone to connect to, for as long as enforcement runs — which on a set-up child device means from the moment the phone starts. Somebody deliberately scanning your network could tell that something on that phone is listening, the way they could tell about any open port. What they cannot do is get anything through it: a connection from anything but a paired parent phone fails to open rather than revealing what is behind it.

On the same wifi, the parent's phone reads. When you open the dashboard at home, your phone connects and asks for the current state, and the child's phone answers.

Apart, the child's phone leaves a short note for each parent at the relay — what it is waiting for an answer to, recent signs of tampering, whether the things that parent sent from away were applied, and the fact that it is still running — every quarter of an hour and whenever the child asks for something. Each note is sealed for that parent alone. It never contains what the child does with the phone, which apps they have, or how long they spend in them, and it never reports anything to us that we could read.

The one thing the child's phone does start on its own is the update check described above, and only if a parent turned it on. That is a request for a file rather than a report: it asks our website which version of the app is published and, when set to, asks for the app. It sends nothing about the phone, the policy, the apps on it, or the child.

An earlier version of this policy, published briefly on 28 August 2026, described the child's phone announcing itself over mDNS on whatever network it joined. That was accurate when written and is no longer how it works — see the note at the end.

The relay

What it is for. A parent away from home can unlock the child's phone, answer what the child asked for, and send new rules or a new schedule; and is told when the child asks for something or the phone shows signs of tampering. On the same wifi none of this touches the relay. It runs at safeleaf-relay.fly.dev, on the same kind of hosting as our website, in Toronto.

What it carries. Each message is sealed on the phone that sends it with a key derived from the secret your two phones agreed when you paired them. We never have that secret, so the relay holds bytes it cannot open, and any change to them makes the receiving phone refuse them. Every instruction inside is also signed with the parent's own key, exactly as it is on the wifi, so even a relay that could open a message could not write one: it cannot unlock a phone, change a rule, replay an old instruction or add a parent. Adding a parent and installing an update are not accepted through the relay at all.

What it can see. That some phone, from some internet address, at some time, left or collected a message of some size in a mailbox. The mailbox name is derived from your pairing and cannot be connected to a name, a phone number or an account, because there are none. Internet addresses are used only to stop one machine flooding the relay, are forgotten within two minutes of the last request, and are not logged; the relay's own log is a count of mailboxes.

What it keeps. Sealed messages, in memory only — never on disk — for at most seven days, and fewer if a restart clears them sooner. Each mailbox holds the last few messages and nothing older.

What it cannot stop. It can fail to deliver. If the relay is down, or withholds a message, an unlock sent from away does not arrive, and the child's phone going quiet shows up on the parent's phone as not having been heard from. Nothing that keeps the rules in force on the child's phone depends on the relay.

What a screenshot of Safeleaf cannot capture

Every screen and dialog that puts a code on display — the code that pairs a parent to the child, an unlock, an authorisation to re-pair, the recovery key, the child's own address — is marked so that Android refuses to screenshot it, screen recorders and remote-support tools see black where it was, and the launcher keeps no thumbnail of it in the recent-apps list. That last one is why this sits under what the app stores: without it, the pairing code outlived the dialog that showed it, as an image on the phone's own storage, for as long as the app stayed in the recent-apps list.

This does nothing about somebody photographing the screen with a second phone, and nothing can. It is why the codes on those screens are also single-use, short-lived, or both.

Taking over the child's phone takes a parent, not just the phone

The rules, an unlock, and any change to who counts as a parent are each signed with that parent's own key — the non-exportable one described above — and the child's phone applies none of the three unsigned. Since 28 August 2026 that also covers replacing the code that pairs a parent to the child: whoever is holding the child's phone can no longer produce a working parent credential from its own screen. Doing that now needs either a signed authorisation from a parent already on the phone, or the recovery key you were shown once at setup.

We hold neither and cannot obtain either. That is the second commitment at the top of this policy, described from the other side.

What we do not do

This section describes the app once it is running. The website is a separate thing, covered under The website below — it is the one place we can hold anything about you at all, and the one moment the app touches it is the download during setup.

• We do not collect personal data. The relay stores sealed messages between your own phones that we cannot open, in memory, for at most seven days, and nothing else.
• We do not use analytics, crash reporting, advertising, or tracking of any kind.
• There are no third-party SDKs that transmit data. Safeleaf carries no analytics, advertising, crash-reporting or telemetry library of any kind, and no software development kit in it reports your use of the app to anyone — including to us.
• We do not read, inspect, log, or store the contents of network traffic. Safeleaf works by deciding which applications may reach the network at all; it has no code capable of interpreting the traffic itself.
• We do not read messages, calls, photos, contacts, or browsing history.
• We do not track location. The parent's phone can ask for location access for one purpose, explained under Permissions below: reading the name of the wifi network it is on. No location is read, stored or sent.

Permissions, and why each exists

Children's data

Safeleaf is used by a parent to manage a child's device, so it plainly concerns children. We collect no data from anyone, including children: the relay carries messages between your own phones that are sealed against us, so there is nothing we can read and nothing for us to disclose, sell, share, or retain.

Android tells the child that the device is managed. Safeleaf does not attempt to hide itself, and cannot be made to: the "managed by your organisation" notice remains visible in Settings. This is not a covert monitoring tool.

Payments

If you buy the paid unlock, the purchase is handled entirely by Google Play Billing. Google processes the payment and tells the app whether a purchase exists. We never see your name, card, address, or email. Google's handling of that transaction is covered by Google's own privacy policy.

App updates

A parent may point Safeleaf at a URL to update the child's app. That connection goes to the host the parent chose and to nowhere else. We do not operate it and receive no record of it.

The website

mysafeleaf.ca is where this policy and our public pages live. It is ordinary web hosting, and it is deliberately not held to the same claims as the app — the app runs on your family's phones, the website runs on ours.

If you enter your email address to join the waitlist, we have your email address. We use it to tell you when Safeleaf is available and nothing else. We do not sell it, share it, or hand it to an advertiser, and every message we send has a one-click unsubscribe.

Four things are saved beside it, and this is all of them:

That is the whole row. There is no cookie, no identifier we assign you, nothing that follows you to another site, and nothing here is ever combined with anything from the app — the app has no account, and what it sends through the relay is sealed against us, so there is nothing to combine it with.

The row lives and dies with the address: unsubscribe, or write to us, and the record goes with it.

Joining the waitlist is entirely optional and is not required to read anything here. The pages themselves carry no analytics, no advertising and no tracking scripts, and they do not load anything from a third party.

Our web host and, if we use one, our mailing provider necessarily see the address in the course of storing and sending — that is what hosting and email are. We will not add anything to this site that watches you.

One thing here does touch the app, and it is worth being exact about. Setting up a child's phone downloads Safeleaf from this site, so our host sees a download request the way any host sees any download: an address, a time, a file. We do not connect it to anything, because there is nothing to connect it to — no account, no name, no waitlist entry unless you separately typed one in.

What that download cannot do matters more than what it records. The setup code on the child's phone is pinned to our signing certificate and checks the file against it before installing. We have never held that key on the server. So this host can give you the app or fail to, and nothing else — it cannot hand you a different one.

Beyond that moment, the app has no account, sends us nothing we can read, and does not know or care whether you ever visited this website.

Data deletion

Uninstalling the parent app removes everything it holds. Removing Safeleaf from the child's device requires a factory reset, which erases the device entirely. The relay holds nothing we can read, and whatever sealed messages it holds for your phones are gone within seven days of the last one, or at its next restart. There is nothing to request deletion of from us — but if you would like written confirmation of that, write to the address above and you will get it.

If you joined the waitlist, the unsubscribe link in any message removes your address and the consent record kept beside it — the whole row, not just the mailing part. You can also write to the address above and ask us to delete it, and we will.

Changes to this policy

If Safeleaf ever gains a feature that transmits anything anywhere, this policy will say so plainly and in advance, and the Google Play Data Safety listing will change to match. We will not quietly add a server.

4 October 2026: the relay. Safeleaf now runs a server that the app uses, which until today it did not, and we said we would tell you before that happened. It is the relay described above: when a parent's phone and a child's phone are not on the same wifi, the parent's unlocks, answers and rules, and the child's notes back, go through it — sealed on the phones so that we cannot read them, and signed by a parent so that we cannot write them. Activity figures and the list of apps on the child's phone still cross only on your own wifi. This policy was changed on the day the app that uses the relay was published, and the Google Play Data Safety listing is being updated to match.

28 August 2026 is that in practice. Setting up a child's phone now downloads the app from our own site rather than from somewhere you have to find yourself, so a server is in the setup path where previously none was. It is not in the app's path: nothing about your family goes to it, and nothing on either phone reports to it afterwards. We are noting it here on the day it changed rather than leaving the old sentence standing.

28 August 2026, twice in one day, and the second time we changed the app rather than the wording. Earlier versions of this policy said only that data "moves between the parent and child phones directly over your own local network". That was true and it was not the whole picture: the child's phone runs a server to make it possible, and it used to announce itself on the network so the parent's phone could find it. We wrote both down.

Then we looked at the second one again. A child's phone announcing itself on every network it joins tells strangers on school and café wifi that there is a managed phone in the room, and that is a fact about a child disclosed to people with no business knowing it. It was never load-bearing — the parent's phone remembers the address, and the announcement was only a fallback for when it changed — so it has been removed entirely. The child's phone now shows its address on its own screen instead, to a parent who asks for it.

Then the other half of it went, later the same day. Taking the announcement off the child left the parent's phone still searching for it — a query onto the local network, under a name that said safeleaf out loud, whenever the address it remembered stopped answering. That is the same fact about a child disclosed to the same strangers, said by the other phone, and it survived the first removal because the first removal was aimed at the child. It has now been removed as well. Neither phone announces anything and neither goes looking: a parent's phone reaches a child's at an address the child showed it, and nowhere else. Nothing is broadcast, on any network, at any time.

We are recording the sequence rather than quietly publishing the better version, because the first note was live and somebody may have read it.

Also 28 August 2026, and in the other direction. This policy used to list a permission called "query all packages", and said the app had to be able to list which apps exist on a phone. It no longer asks for that permission at all, and the app that replaced it cannot see the apps on your phone that it has no rule about. The parent's editor shows the apps on the child's phone, sent from that phone over your own local network, which was always the list it should have been showing. Nothing was ever sent to us either way; the app now simply asks for less.

Also 28 August 2026, and these are additions rather than corrections. Two things this policy had never described are now written down: the screens that show a code cannot be screenshotted, screen-recorded, or left behind as a thumbnail in the recent-apps list; and replacing the code that pairs a parent to the child now takes a signature from a parent already on it, so holding the phone is no longer enough. The find-each-other section was also rewritten around what the app now does — the child showing its address — rather than around the announcing it no longer does, and it is franker than it was about the one thing a network scan can still see. None of the three changes what we receive, which remains nothing. Both are things we would want to know if we were reading this about somebody else's app.

Contact

n12n.can@proton.me