App privacy

Monitoring: the part we store

This is the one place the app is not private-by-absence, so it comes first rather than buried.

A URL you add to monitoring is stored on our server in full — scheme, host, path and query string — for as long as you monitor it. It has to be: the whole point of monitoring is that the measurement happens on a schedule whether or not your phone is on, and a server cannot fetch a page whose address it does not have.

Alongside each monitored URL we keep what is needed to tell you when it changes:

• The address, the site it first resolved to, and when you added it.
• When it is next due, when it was last measured, and whether the last check succeeded.
• The result of the most recent measurement — the status of each check — so the next one has something to compare against.
• The changelog entries produced by those comparisons.
• A hash of an opaque key your app generates, which is how we recognise your list without an account. It identifies a subscription, not a person: it cannot be turned back into a name, an email address or an Apple Account.

We do not store the content of a monitored page, only the verdicts. Stop monitoring a URL and its row and changelog are deleted.

Decide accordingly: a page whose address is itself a secret — an unlisted preview, a URL with a token in it — should not be monitored. Inspecting it once is different, and is covered below.

What stays on your device

• Every report the app has fetched, stored whole, so reopening one shows exactly what you saw.
• A copy of your monitored list and changelog, so the screens work offline. The server's copy is the one that counts.
• Your manual inspections, which never leave the device beyond the request that produced them.
• Your settings — appearance, alert mode, notification permission.

Deleting the app deletes all of that. It does not delete the monitoring rows above; those go when you stop monitoring the URL.

A manual inspection

Inspecting a URL on demand is the same request the website makes, and it is treated the same way: we record the hostname only — example.com, never example.com/private/page?token=…. Paths and query strings are discarded before anything is written, and the content of the page is never stored. That record feeds the public statistics.

As with any HTTP request, our server sees the connecting IP address while it handles it. Raw IP addresses are never written to disk. They are used in memory for rate limiting and to derive the rotating daily hash described in the website policy, which cannot be linked across days.

Note what this still means: inspecting an internal or unreleased page tells us that hostname exists and was measured. That is true whether the request comes from the app or the website.

Subscriptions

Purchases go through the App Store. We never see your name, email address, Apple Account or payment details; Apple does not give them to us. What we can verify is whether a subscription is currently active, through Apple's own receipt mechanism, together with the anonymous transaction identifier Apple issues for it.

That identifier is what lets a slot lock survive a reinstall or a new phone, and it is the only durable value connected to a subscription that we hold. It identifies a subscription, not a person: it cannot be turned back into an Apple Account, an email address or a name.

Apple's own handling of your purchase is governed by Apple's privacy policy, not by this one.

What the app does not do

• No advertising identifier (IDFA), no ad networks, no advertising of any kind.
• No analytics SDK, no crash-reporting SDK, no third-party code that observes your use of the app.
• No contacts, photos, location, calendar, microphone or camera access. The app does not ask, because it has no use for any of them.
• No profile of you, no cross-app tracking, no data sold or shared with brokers.
• No email address collected, because there is no account.

Notifications

Notifications are asked for at the moment they first become useful — when you add a URL to monitoring — not on first launch. Declining is a normal state: the app keeps working and the changelog still fills in; you simply read it rather than being told.

The text of a notification is generated on your device from the report and names the site and what changed. Treat it as you would any notification shown on a lock screen.

Your rights

For monitored URLs there is a handle: the hash of your app's key. Remove a URL from monitoring and its row and history are deleted immediately; that is the export and erasure route, and it is in your hands rather than ours.

For everything else — inspection statistics — we hold a hostname, a coarse client label and a rotating daily hash. Nothing links those to you, so we genuinely cannot find "your" rows in order to export or erase them. That is not a refusal; it is a consequence of never collecting the link.

If you believe a specific record concerns you, or you want a hostname removed from the public statistics, write through the contact form and say which one. You may also complain to your national supervisory authority; in Romania that is the ANSPDCP. The controller is BTN GROUP.

Retention

Monitoring rows — the URL, its schedule, its last result and its changelog — live for as long as you monitor that URL, and are deleted when you stop. A subscription record with no monitored URLs left is removed once it has been inactive for a year.

Statistics rows from inspections are kept for as long as the public statistics they feed are published. Because they carry no identifier for you, they age into pure aggregate rather than becoming a growing record about a person. On-device data lives until you delete it or delete the app.

Changes

The date at the top always reflects the current version. If a future release sends anything this page does not describe, this page changes first.