Privacy Policy

Version and scope

1. Who we are

Shieldora is an iOS content-protection app operated by [Legal Entity Name] — to be completed before launch, registered in [Jurisdiction] — to be completed before launch at [Registered Address] — to be completed before launch.

For privacy law purposes, [Legal Entity Name] — to be completed before launch is the data controller for the information described in this policy.

Contact: contact@shieldora.app

2. The short version

We built Shieldora to protect children, and collecting more data than we need would work against that. So:

• We do not record what your child looks at. Filtering happens on the device, applied by Apple. Individual blocks are not reported to us — not the address, not the page, not the fact of a block at all.
• We do not keep a browsing history. We could not show you one if you asked.
• We never sell your data, and we never share it for anyone else's advertising or marketing.
• We collect the minimum needed to run accounts, keep protection working, and tell you when something happens.

This summary is written for humans. The detail below governs.

3. What we collect

3.1 Parent account information

3.2 Device information

Collected from both parent and child devices:

3.3 Child profile information

3.4 Protection records

Shieldora records whether protection is running, not what your child does with the device.

Filtering is performed on the device by Apple's Family Controls. Apple's web content filter enforces silently: it reports individual blocks to nobody, including us. So there is no record of a block anywhere in Shieldora — we are not withholding it or protecting it, we never receive it.

We do not record the URL, the search term, the page, or any browsing history. Those are not stored in a form we could read back later, because they are never sent to us at all. See section 4.

We also store the state of the protections a parent has set:

• The five device restrictions — app installation, account modification, passcode change, automatic date and time, and explicit media — and whether each is on or off
• The web content filter setting
• The browser allowlist: which third-party browsers are blocked, and which a parent has chosen to allow

And we record protection-status events:

• The device's regular check-in, which is how we can tell protection is still running
• Protection going offline — the check-ins stopping, whether because the device is off, has no network, or the authorisation has been removed
• Protection coming back — the device checking in again
• A parent allowing a third-party browser, which changes what is filtered
• Alerts generated from any of the above, and whether each was delivered

Filtering uses Apple's Family Controls, applied on the device. Shieldora is not a VPN, does not route your child's traffic through our servers, and does not inspect traffic in transit.

3.5 Waitlist sign-ups

If you join the waitlist on our website, we store your email address, the date and time you joined, the page you were on, and a source tag from the link you followed (for example ?ref=instagram). Submitting the form is your consent to be emailed about Shieldora, and the date and page are the record of it.

We use this for one thing: to email you once, when Shieldora is ready. We do not send a confirmation email in the meantime, we do not sell the address, and we do not pass it on. It is stored in our database in Sydney, Australia, alongside everything else. A summary we send ourselves carries counts only, never addresses.

We delete waitlist sign-ups three months after the launch email is sent, or sooner if you ask. To be removed at any time, email contact@shieldora.app.

4. What we deliberately do not collect

This section states what the software does not do, and it is written to be held to.

• No browsing history. We do not build, store or have access to a record of the sites a child visits.
• No URLs or web addresses. The filter evaluates addresses on the device to decide whether to block. That evaluation happens locally and the address is not transmitted to us and not stored.
• No page content. We never see or store what was on a page.
• No message content. We do not read, collect or have access to messages, emails or chats in any app.
• No search terms, and no search detection at all. We do not see, record or detect what a child searches for. There is no search-detection layer in Shieldora. Filtering is applied by iOS on the device, and nothing about what was filtered reaches us — not the search, not the page, not the block.
• No location data.
• No contacts, photos, camera or microphone access.
• No advertising identifiers, and no tracking across other apps or websites.

A limitation we want to be honest about

Filtering uses Apple's Family Controls and applies to web content: Safari, including private browsing. Other browsers are blocked by default, and a parent may choose to allow one — content inside a browser allowed that way is not filtered, and the app says so at the moment you allow it.

Content inside other apps is not filtered. Apps such as TikTok, Instagram or YouTube serve their own content inside the app, and neither iOS web filtering nor Shieldora reaches inside them. We do not see what is shown there, we cannot block it, and no alert will be raised about it.

No filter catches everything, and some material will get through even in Safari. What Shieldora offers is not a guarantee that nothing is seen, and not a report of what was blocked — Apple's filter does not provide one. It is that you are told when a child's phone stops checking in, or reports that protection has been turned off — the failure that would otherwise leave a child unprotected without anyone noticing.

We say this because a parent who assumes we cover everything on the device has been misled, even if no single sentence here is untrue.

5. Children's data

Shieldora is used by children, on children's devices, at a parent's direction. We know children's information is involved and that stricter rules apply.

The parent holds the account. Children do not have their own accounts, do not sign in, and cannot sign out. A child device holds limited credentials that let it report events and receive settings — nothing more.

6. Parental consent

The parent sets up the account, links each child device, and must approve every change to protection settings with a two-factor code.

Each time a parent consents, we record when they consented, how, and which version of this notice they were shown.

7. How we use data

We use the information described above only to:

• Operate accounts and sign parents in securely
• Verify changes to protection settings with two-factor authentication
• Apply and update filtering settings on child devices
• Detect that protection has stopped working and alert the parent
• Send alert emails about the events listed in section 3.4
• Provide support when a parent contacts us
• Keep the service secure and investigate abuse
• Meet our legal obligations

We do not use this data for advertising, profiling for marketing, training machine-learning models, or any purpose unrelated to protecting the child.

8. Who we share data with

We do not sell your data. We do not share it for anyone else's advertising or marketing. We do not disclose it to data brokers.

We do use a small number of service providers to run Shieldora. They process data on our behalf, under contract, and only for the purposes we set:

We may also disclose information where legally required — for example a valid court order — or to protect someone's safety.

9. Where data is stored, and international transfers

Data is stored in Australia (Sydney) — the database on Supabase (Postgres, Sydney region), and the application on Fly.io's Sydney region.

One exception, which we would rather state than have you discover. Fly.io stores the operational logs and metrics its machines produce in the United States, not in Australia, regardless of where the machine itself runs. Fly has confirmed this to us in writing. Logs are kept 7 days and metrics 15 days, the storage region cannot be changed, and the log sink cannot be switched off. These are operational records — request timing, errors, IP addresses — not the database, and they do not contain alert history or account contents. But they are personal information leaving Australia, and this policy would be wrong not to say so.

Resend, which sends our alert and account emails, keeps a log of each message — the recipient's email address and the message content — for 30 days, and offers no way to delete a sent message early. An alert email names the child (the name the parent set) and the device type, such as "Emma's iPhone", so a parent can tell their children's devices apart; it never carries what was blocked, browsed or searched, which stay in the app behind the login. So a child's first name and device type sit in Resend's logs for up to 30 days from when a message was sent. That is personal information, and after an account is deleted it is the longest-lived copy of anything about that account — the live data goes at deletion, and a Resend message clears 30 days after it was sent, on Resend's own clock, which we cannot bring forward.

10. How we protect data

• All data is encrypted in transit.
• Data is encrypted at rest by our infrastructure providers.
• Passwords are stored only as cryptographic hashes, never in readable form.
• Parent accounts require two-factor authentication, and every change that reduces protection — turning protection off, unblocking a category, unlinking a device — requires a fresh two-factor code. Changes that increase protection do not, so that a parent who cannot reach their authenticator can always restore it.
• Child devices hold limited credentials that cannot read the parent dashboard or change settings.
• Access to production data is restricted to one person — the founder, who operates the service — and is logged. Shieldora is run by one person, and we would rather say that plainly than imply a team and an approval process that do not exist. If that changes, this section changes with it.

No service can promise perfect security, and we do not.

11. How long we keep data

When an account is deleted, we delete the associated data within 30 days (the cancellable grace period). Copies then persist in backups and provider logs and clear as those expire: database backups within 7 days, and our email provider's message logs within 30 days, which is the longest-lived copy of any personal data after deletion. We keep something beyond this only where a legal obligation requires it.

12. Your rights, and how to use them

A parent may:

• Access the information held about their account and their children
• Correct inaccurate information
• Delete a specific child's information, while keeping their own account
• Delete their whole account and all associated data
• Export their data in a portable format
• Withdraw consent and stop using the service
• Complain to a privacy regulator

To do any of these, contact contact@shieldora.app. We respond within 30 days.

Australian users may complain to the Office of the Australian Information Commissioner (OAIC).

13. Changes to this policy

If we make material changes we will notify account holders by email before the changes take effect.

14. Contact

[Legal Entity Name] — to be completed before launch [Registered Address] — to be completed before launch contact@shieldora.app