Privacy Policy

Effective date: 1 November 2026

In short

Your records live on your device. There are two ways they can leave it, and they are different enough to keep apart.

The first is your own cloud. On iPhone the app copies your records to your own iCloud. On Android, if you allow it, the app keeps a copy in your own Google Drive, encrypted on your phone before upload. We can read neither.

The second is BearingKind Sync, a service we operate. It is what lets you share a diary with other people, on iPhone and on Android. If you use it, your records pass through our server, encrypted on your phone with keys we never receive. We cannot read a sleep record, a note or your child's name. The server does see a short list of technical facts, such as when each record was written and how large it is, and section 3 lists them all. If you never turn BearingKind Sync on, never accept an invitation and never start a purchase of the subscription, the app sends us only two things: crash and error reports, and, each time it starts, a check for a corrected version of its code. Neither carries your name or any of your records; sections 3 and 4 say what they hold.

There is no sign-in. The app never asks for your name, email address or phone number. It contains no advertising, attribution or product analytics code. When the app crashes or hits an error, it sends us a report that says what the code was doing. A report holds no name, no account, no device identifier and none of your records. Section 4 says what it holds.

1. Who this policy is from

Ivan Kuindzhi
Box 69, Nalbandjan 28, 0010 Yerevan
support@bearingkind.com
+374 55 843957

"We" and "us" below mean the publisher named above. "The app" means BearingKind Baby Sleep Tracker on iPhone and Apple Watch, together with its widgets and Live Activities, and the Android version of the same app. "BearingKind Sync" is the name of the sync service described in section 3.

2. What the app records

The app records:

• About a child you add: the name you give them, their date of birth, the hours you consider night, and any reference ranges you adjust yourself.
• Sleep records: when sleep started and ended, how the record was made (by hand, from the watch, or imported), the time zone it happened in, and corrections you make later.
• Notes: free text you write, with a time and optionally an end time. The app does not restrict what you put in a note, so a note holds exactly what you choose to put in it. Nothing prompts or requires you to record anything health-related.
• Data you import from a backup file or from another app you export from.
• If you share a diary: the household name you set, which the people you invite can see. A name you type for each invitation so you can tell people apart, which only you see. Each person's role, and which of your children's profiles they see. Who made each sleep record and note. A person who joins a diary can give it and its children private labels that only they see.
• Subscription status. If you buy the subscription, the app keeps the record the App Store or Google Play gives it, which is the product, its current state, and its expiry, grace-period and revocation dates. It also keeps our server's answer about it, which is what the subscription allows and until when, and whether each diary's sync allowance for the month is nearly used or used up, and until when. It never holds your card details. Section 7 says what our server learns about a subscription.
• Technical records the app keeps for itself: an identifier for each of your own devices so records made in two places can be merged in the right order, and a local diagnostics log of sync outcomes used to explain errors to you.
• A sync account, if you use BearingKind Sync or buy the subscription. The app creates it silently from cryptographic keys it generates on your phone, the first time you move your diary to BearingKind Sync, accept an invitation, start buying the subscription (even if you then cancel), or restore or redeem it. It has no name, email address, password or phone number attached, and it is not linked to your Apple or Google account.

The app does not ask you for your name, phone number, contacts, location, or photos. It uses the camera only to scan a code another phone shows: when you move your diary to a new phone, or when someone invites you to their diary. Nothing from the camera is stored or sent anywhere.

Allowing the Google Drive copy on Android connects a Google account you already have, and section 3 says what the app can and cannot see through it. It asks Google for permission to use one hidden folder and for nothing else, so it does not learn the name or the email address on that account.

3. Where it is stored

On your iPhone. The app's records live in a database in the app's own storage, which the app asks iOS to keep under file protection. iOS encrypts it and keeps it encrypted while your device is locked. One technical exception is worth stating: a file the app already had open when you locked the phone can remain readable to the app until it is closed, which is what allows a running sleep timer to keep recording in your pocket. Deleting the app removes the database.

On your Android phone. The records live in the app's own private storage, which Android's app sandbox keeps unreadable to other apps on an ordinary, unrooted phone. Most Android phones also encrypt their storage, but that is the phone's doing and not something the app can promise for every device, so treat your screen lock as the protection that is actually yours to set. That directory is left out of Google's automatic cloud backup and out of device-to-device transfer, so a new phone set up from your old one does not arrive holding your child's records. The encryption key for the Google Drive copy is the one deliberate exception, and the paragraphs below say what happens to it. Deleting the app removes the database.

In your own iCloud. On iPhone the app copies your own diary to a private CloudKit database tied to your Apple Account, on its own, whenever iCloud is available. We cannot read that private database. The app has no switch for this copy. iOS has one, in the Settings app under your Apple Account, where you can also delete what the app has stored. While your diary is on BearingKind Sync the app stops copying it to iCloud. The copy made before that stays in your iCloud until you delete it there or use Full reset (section 10).

In your own Google Drive, on Android, if you allow it. When you set the app up on Android, it offers to keep a copy of your diary in your own Google Drive, so that it comes back if you reinstall the app or change phones. Google then asks for your permission, and you choose the Google account on Google's own screen. If you skip this or decline, your diary stays on the phone only; you can turn the copy on later in the Sync section of Settings. Once you allow it, the copy keeps itself up to date.

The records themselves are encrypted on the phone before they leave. The app generates a key on the device, seals the records with it, and uploads the sealed files. Google holds those files and can no more read what is in them than we can. The wrapping around them is not sealed, and the paragraph below says what that leaves visible. The phone talks to Google directly, and no BearingKind server is involved in the Drive copy.

What Google can see is that wrapping. Each file's name holds an identifier of the key that sealed it, an identifier of the installation of the app that wrote it, and which stretch of records it covers. Google also sees each file's size and when it was created and deleted, and those times show roughly when the diary was used. After a Full reset, a small record there holds a random identifier, the time and progress of the reset, the identifiers of your diaries on BearingKind Sync and fingerprints of the recovery material described below. None of that holds a child's name, a note, or a sleep record. Everything about your child is inside the sealed part.

The files go in the hidden folder Google gives each app, not into your visible Drive, and they count against your Google storage. Drive's settings list the apps that have stored data this way, and you can delete everything the app holds there from that list. That is also how you stop the copy.

The key matters more than the files. We never receive it. The app keeps it on the phone in Google Block Store, a small store Google provides to apps. When the phone has a screen lock and its Google backup is on, Block Store also puts the key in that backup, encrypted end to end so that Google cannot read it, and a phone set up from that backup gets the key back. Without a screen lock the key is not put in that backup, though a direct transfer from the old phone to a new one during setup can still carry it. A second phone can also get the key by scanning a code the first phone shows. There is no recovery code. A phone that gets the key in none of these ways makes a new key and a copy of its own, and cannot open the old one; if every phone that held the key is lost and no backup carried it, nobody can open the Drive copy again, including us.

On BearingKind Sync, if you use it

BearingKind Sync is a server we operate. Your diary goes there in two cases. You turn BearingKind Sync on for your own diary, which you must do before you can invite anyone. Or you accept an invitation to someone else's diary. Starting to buy the subscription, restoring it or redeeming an offer code contacts the server too, before any diary moves: the app creates your sync account then, so that a purchase has an account to belong to, even if you cancel the store's purchase sheet, and sends a completed purchase to be checked (section 7). Your diary stays where it is until you move it. In every other case the app never contacts it.

What the server cannot read. Before anything leaves your phone, the app encrypts it with keys that exist only on the devices of the people in the diary. That covers sleep records, notes, your child's name, date of birth and settings, the household name, the names you type for invitations and private labels. The server stores the result and passes it to the other devices. It holds no key that opens it, and neither do we. When a new person or a new device needs the diary's keys, a device that already has them wraps them for that one recipient. The server carries the wrapped package and cannot open it either.

What the server can see. Encryption hides what a record says. It does not hide that a record exists. The server sees and stores:

• the identifier of your sync account, the identifier of each device on it, and the public halves of those devices' keys;
• the identifier of each diary, which account owns it, and the list of member accounts with each one's role, status and the time they joined, and, for a person you let see only some of your children's profiles, which ones. These are identifiers made of random-looking characters, and a profile is one of those values: the server cannot tell which child it is. The server has no names and no email addresses for anyone;
• for every record, what kind it is (a sleep record, a note, a child's settings, a private label and so on), how large it is, the exact time it was written, and which installation of the app wrote it. People mostly write records as things happen. So although the server cannot read a single sleep, these times show roughly when the app is being used, and that says something about a household's day. We would rather tell you than have you work it out;
• for every sleep record and note, which child's profile it belongs to, as one of those random-looking values, and for a sleep moved to another child, that child's value too. The server uses them to send each person only the profiles they may see. It cannot tell which child a value stands for, but it can tell that records belong to the same child;
• for every invitation, its identifier, the role it grants, which of your children's profiles it shares if it does not share all of them, which account created it, when it expires and whether it was accepted, and after acceptance the identifiers and public keys of the device that joined;
• the public half of the recovery key described below;
• your subscription state, and how much of its monthly sync allowance each diary has used, as section 7 describes.

Your IP address. Every internet request carries one. Our server reads it once per request, to limit how fast a single address can send requests, and does not store or log it. Cloudflare, which runs the network and the machines the server uses, handles it as any network provider does.

While the app is open. For each diary on BearingKind Sync, the open app keeps a connection to the server, so that an entry made on another phone shows up within seconds. The server uses it for one thing: a one-word signal with no content, telling the app that something changed and it should sync. While a connection is open, the server knows which of your devices holds it, and so that the app is open on that device. It keeps this only while the connection lasts and writes it neither to storage nor to its logs. The connection closes when you leave the app.

Server logs. The server logs requests. A log entry holds the name of the operation, whether it succeeded, how long it took and how many bytes went each way. It holds no IP address, no account or diary identifier, no address or headers, and nothing from inside a request. Log entries are kept for at most 7 days.

Where it is. BearingKind Sync runs on Cloudflare. Everything it stores, which is the database, the archive of older encrypted records and the backups, is pinned to Cloudflare's European Union storage region. A request from your phone is handled at the Cloudflare location nearest to you, which can be anywhere in the world, and passes through to that storage. We administer the service from Armenia. What we can see from there is the list above and never your records.

Recovery material. A sync account records from one phone at a time. So that another phone of yours can get into the account, for example after you lose the first one, your phone makes a secret we call recovery material. It holds your diary's keys and a key the server accepts for enrolling a new device. Your phone saves it into your own iCloud, in fields iCloud encrypts, as soon as your diary is on BearingKind Sync. On Android it goes into your Google Drive, sealed with the Drive copy's key, when you have allowed the Drive copy. You never see it and we never receive it. The server holds only its public half, which opens nothing. If there is no shared cloud between two phones, the old phone can show the same material as a code for the new one to scan. The material is deleted when you move your diary back to iCloud or Google Drive and when you use Full reset.

This has one hard consequence. BearingKind Sync does not know who you are, so we cannot let you back into an account on your word. If you lose your phone and the recovery material is in neither your iCloud nor your Drive, the account is out of reach for everyone, us included.

How long the server keeps things. Your diary stays on the server for as long as it is on BearingKind Sync. It is deleted when you move it back to iCloud, as soon as your phone confirms the move. It is deleted when you use Full reset. It is deleted after a subscription ends, on the schedule in section 7. Backups of the server's storage are kept for at most 30 days, so a deleted diary can remain inside a backup, still encrypted, for up to 30 days more. Login sessions expire after at most 30 days without use. Section 10 says what stays behind after an account is deleted.

In backup files you create. The app can export everything it holds as a file, so that your records are yours to keep and to move. That file is ordinary, unencrypted JSON. Anything that opens text can read it. That is deliberate: a backup you cannot open is not a backup. It also means the file deserves the same care as any other document holding your child's information. Where it goes after the export is entirely in your hands.

App updates

Each time the app starts, it asks our update server whether a corrected version of its code is available for the version you have installed. The request says which system the phone runs (iOS or Android), whether the app is a test version or the store version, which build of the app is installed, which update it is running, and which updates, if any, recently failed to start on it. Everyone with the same version sends the same values. The update system that the app uses also adds a random number made once when the app was installed, and, if the app failed to start the previous time, a short description of that error. Our server reads only the system, the version and the build, to choose its answer. It does not read, store or log the rest of the request, the random number and the error description included. It answers with the newer code or with nothing, and keeps no record of the request. Downloading the newer code, when there is some, sends the same random number, and our server does not read it there either. It does not read your IP address; Cloudflare, which runs the network and the machines the update server uses, handles it as any network provider does. Nothing from your diary is sent.

4. Analytics, advertising, and diagnostics

The app has these limits:

• No analytics or product measurement. The app contains no code that measures which screens you open, what you tap, or whether you come back. The only place a screen name leaves the phone is inside a crash or error report, as described below.

• No advertising and no tracking. There are no ad networks, no attribution SDKs, no advertising identifiers, and nothing that follows you across other apps or websites.

• Crash and error reports, without identity. When the app crashes, stops responding, or records an error, such as a sync step that failed or an invitation our server refused, it sends a report to Sentry, the error-tracking service we use. A crash is reported the next time the app starts. A report holds:

  • what the code was doing: the call stack, the kind of error, which part of the app reported it, and the error's message only when it is one of the app's own fixed messages or a fixed system message with any values in it removed (any other message is replaced whole);
  • the last few screens the app showed before the fault, by the screen's name in the app and the time it was shown, never what was on it;
  • when the fault happened, and whether the app was on screen;
  • the app's version and build, and the code libraries it had loaded, with their versions;
  • the phone's make and model, its system version, its language and region setting, and its technical state: processor type and count, total and free memory, screen orientation, whether it is a simulator, and whether its system has been modified (rooted or jailbroken);
  • a random number the app makes fresh each time it starts, which ties together the reports from one run.

  It holds no name, email address, account, sync or device identifier, and none of your records. Every installation reports under the same placeholder, so reports cannot be grouped by person or by phone. Sentry is set not to store your IP address or a location worked out from it. We use the reports only to find and fix faults, on our legitimate interest in an app that works. Because a report carries nothing that identifies you, we cannot find or delete one person's reports; they are deleted no later than 90 days after they reach Sentry.

BearingKind Sync keeps the operational log described in section 3 and nothing else of this kind. It runs no analytics, and no monitoring or error-reporting company receives anything from it.

Apple diagnostics that are separate from the app

Everything above is about what the app does. Separately, and whatever any app contains, iOS itself may send Apple crash reports and usage statistics. Apple shows some of that information to developers, including us. Two things come from Apple's own measurement, not from any code of ours:

• Aggregate statistics in App Store Connect: roughly how many devices installed the app, how often it is opened, and how many people keep using it. These are totals and averages. They do not identify you and we cannot use them to look up a person.
• Crash reports, which describe what the app was doing when it stopped working. They contain technical state, not your records. They do not contain a child's name, notes, or sleep history.

This only happens if you have left Share with App Developers switched on, under Settings → Privacy & Security → Analytics & Improvements on your iPhone. It is Apple's switch, it applies to every app on your device, and you can turn it off there at any time. We would not know if you did.

We are telling you this because "we collect nothing" is the sort of claim that quietly stops being true at the edges, and an edge you find yourself later is worse than one we point out now.

Google's own measurement on Android

The same holds on Android, with Google in Apple's place. Google Play shows developers aggregate figures such as how many devices installed the app and how it is rated, and Android vitals reports crashes and freezes from phones whose owners have left Usage and diagnostics switched on. A crash report describes what the app was doing when it stopped working. It does not contain a child's name, notes, or sleep history, and the aggregate figures are totals that cannot be used to look up a person. The switch is Google's, it covers your whole phone, and it sits in the Android Settings app under Google, where the exact wording varies between phone makers.

5. Health information about your child

Infant sleep, and anything you choose to write in a note, can be sensitive information about a child. Laws in many countries treat it as a special category needing extra protection.

No readable information about your child reaches us unless you choose to send it to us yourself (section 8). It stays on your device, in your own iCloud, in your own Google Drive as sealed files if you allow the Drive copy, and on the devices of the people you invite. If you use BearingKind Sync, it also sits on our server in a form neither the server nor we can read.

Why we are allowed to handle it, where the GDPR or UK GDPR applies. We run BearingKind Sync for you because you asked for it, by turning it on or by accepting an invitation, and we cannot provide it without storing what section 3 lists. An encrypted record about a child's sleep is still information about a child's health, even though we cannot read it. For that we rely on your explicit consent, which the app asks for at the moment you turn BearingKind Sync on or accept an invitation. You can withdraw it at any time. Move your diary back to your own cloud or use Full reset, and the server copy is deleted as section 10 describes. Leave a diary you joined, and it is deleted from your phone as section 6 describes. Withdrawing does not undo what was done before you did.

Two consequences worth stating plainly:

• Protect your own access. Use a device passcode, protect your Apple and Google accounts, and take care with exported backup files.
• Your own copies are the recovery path. We hold no readable copy of your records and cannot restore them for you. What can be restored is what is on your device, in your own iCloud, and in the backup files you export. A diary on BearingKind Sync comes back on a new phone only through the recovery material in your own iCloud or Drive, or from the old phone. The Google Drive copy opens only with its key: on a phone already using the copy, on a phone set up from a Google backup that carried the key, or on a phone that scanned the code another of your phones showed.

6. Sharing a diary with other people

If you invite another person, such as a partner, grandparent, nanny or your child's doctor, this section applies. If you never do, it does not.

How sharing works. Sharing runs only through BearingKind Sync, on iPhone and on Android alike. iCloud and Google Drive are private copies for one person and share nothing. To share, your own diary has to be on BearingKind Sync first. The people you invite do not need to move their own diaries anywhere. Their own diary stays where it was, and yours is added next to it.

Invitations are links, and a link is a key. You create an invitation, choose a role, and send the link however you like. We never see who you sent it to, and the app never asks for anyone's email address. The link carries the household name and the secret that opens the diary's keys, in a part of the link that is never sent to our server. So treat the link like a key. Whoever opens it first gets in. A link works once and stops working after 30 days, or sooner if you cancel it. The list of people in your diary shows that the invitation was accepted and when, and you can remove whoever accepted it.

Roles. A caregiver can record sleeps and notes and can edit and delete any of them. A viewer can read the shared records but cannot change them. Only the owner invites, removes people and changes roles.

Which children each person sees. For each invitation you choose whether the person sees all of your children's profiles, including ones you add later, or only the ones you pick. You can change that after they join. A profile you take away is deleted from their phone the next time it connects; on a phone still running an app version from before this choice existed, it stays until that phone updates the app, and nothing new of it arrives meanwhile. A person sees the records of their profiles and nothing of the others, not even that they exist, with three exceptions. If you move a sleep from a profile they see to one they do not, their phone learns a random-looking value for that other profile, never its name or records. Their phone can tell that the diary changed, and roughly how much, never what. And if that other profile's history is later erased, their phone downloads the diary again. The household name and the event types are seen by everyone in the diary. Each record carries which member made it. The app has no names for the people in a diary, other than the ones you type for your own invitations, which only you see. What the people you invite see is the household name you set.

Removal and what others keep. You can remove a person, and a person can leave. The next time that person's phone connects to the server, the app deletes the diary from it, including anything they recorded there that had not been sent yet. The records they made earlier stay in your diary. The diary's keys are replaced, so nothing written afterwards can be read with what they had. Three things are outside anyone's technical control, so invite people you trust. A phone that stays offline, or from which the app was deleted, is never told and keeps what it has. A backup file the person exported before removal is theirs. So is a screenshot.

If your subscription ends while the diary is shared, section 7 says what happens to the people in it.

7. Purchases

BearingKind Sync is paid for by a subscription. Recording, the reports and the copy in your own iCloud or Drive are free. The subscription belongs to the owner of a diary, and the people the owner invites need none.

If you buy a subscription, Apple or Google is the seller, depending on where you got the app. The purchase happens through the App Store with your Apple Account or through Google Play with your Google account. The store handles payment, receipts, renewals, refunds, and any statutory right of withdrawal. We do not receive your card details, your name or your billing address.

What our server learns. To check that a subscription is real, the app sends the store's proof of purchase to our server, which checks it with the store. Before your diary is on BearingKind Sync, that check is all: the server answers and keeps nothing about the purchase. Once a diary runs on it, the server keeps what is listed below, and while the subscription is active, in a grace period or in a payment retry, it asks the store again on its own, at least once a day and more often around the end of a period, so that a renewal, a cancellation or a refund reaches the diary without your phone. After an App Store subscription has ended, the server keeps asking Apple once a day through the 14 days that follow, because subscribing again on the App Store continues the same purchase. A new Google Play purchase after the end reaches the diary through your phone. From the App Store the proof is a record Apple signs; the server checks it and does not keep it. Google Play signs nothing, so its proof is the purchase token Google issues, and the server keeps the newest one, because asking Google again needs it. Tied to your sync account and to the diary the subscription pays for, the server keeps:

• the store's name;
• the store's identifier for the original transaction (App Store), or the purchase token (Google Play);
• the product, the subscription's state (active, in a grace period, in a payment retry, ended or refunded), whether the current period is a free trial, an offer code or paid, and whether it is set to renew;
• its dates: when the current period started and when it ends, the end of any grace period, the date of a refund, the time on the store's newest proof, when the diary started running on this purchase, when the server last checked it, and when the purchase last stopped paying for the diary, because it ended or because it moved to another sync account;
• for Google Play, whether Google holds the purchase as acknowledged.

When you buy, the app gives the store a code made from your sync account's identifier, which the store keeps with the purchase. It is a one-way fingerprint: the store learns nothing about the account from it, and our server uses it to tell whether a purchase was made from the sync account that sends it.

A purchase follows you to a new sync account. If you start again under a new sync account, for example after Full reset, the same store account's purchase moves to the new account when its diary claims it: when you move that diary to BearingKind Sync, or buy, restore or redeem once it is there. The purchase then stops paying for the diary it paid for before. To do that, the server keeps a short record of every purchase a diary has run on: the store's name, the transaction identifier (for Google Play a fingerprint of the purchase token, not the token itself), the product, the identifiers of the sync account and the diary it last paid for, and the time of the newest proof it saw. This record stays after the account or the diary is deleted, so that one purchase pays for one diary at a time. It also means the server can tell that two sync accounts were paid for by the same purchase.

The monthly sync allowance. Each subscription includes a monthly allowance of BearingKind Sync (terms section 3.1). To keep to it, the server counts, for each diary, how much of the service it used in the calendar month: database rows written and read, requests, processing time and storage, and what they cost at our provider's prices. These are totals. They say nothing about what was recorded. They are kept for the current month and the month before. When the diary a purchase pays for is deleted, for any reason, that month's totals move to the purchase record above: the costs, which other diaries' use was counted and when the allowance changed. They stay with that record, which has no end date, so that the purchase does not start the month afresh in another diary.

Why we are allowed to keep this, where the GDPR or UK GDPR applies. We keep the subscription details, the purchase record and the allowance totals because we need them to provide the subscription you bought, under our agreement with you. The purchase record that stays after a deletion is kept on our legitimate interest in one purchase paying for one diary at a time.

What happens when a subscription ends. For 14 days everything keeps working, sharing included, except that you cannot send new invitations. After 14 days the people you invited are removed, which deletes the diary from their phones as section 6 describes, and open invitations stop working. Your diary goes back to a copy in your own iCloud or Google Drive on its own, or stays on your phone where neither is available. Nothing is asked of you and you can keep recording throughout. The server keeps its encrypted copy for 30 more days and then deletes it, together with the purchase token it held for the diary; that month's allowance totals go to the purchase record, as above. Subscribing again within the 14 days changes nothing; after them, it does not bring the server copy back, and you move the diary and invite people again. The same schedule applies if you delete the app and let the subscription run out.

The handling of the transaction itself is governed by Apple's or Google's own privacy policy, not by this one.

8. When you send us something

Support is a separate route by which your data can reach us.

To help with a problem, we may ask you to send a diagnostics summary or a backup file. If you send one, we receive whatever is in it. A backup file contains your child's name, date of birth, and every record and note you have written.

So:

• Sending anything is your choice. We will explain what we are asking for and why. You can decline and we will still try to help.
• Consider removing what is not needed. The backup file is plain text; a note you would rather not share can be taken out before you send it.
• We keep it only while we are working on your problem. We delete attachments and the correspondence containing them once the issue is closed, and no later than 12 months. We use support material only to answer and investigate your request.
• We cannot look your diary up. Your sync account has no name or email address on it, so nothing in a support message lets us find your data on the server, and we could not read it if we did.
• Legal basis, where the GDPR or UK GDPR applies. We handle an ordinary support message because it is necessary to answer the request you made of us, and because we have a legitimate interest in supporting the people who use the app. If you attach a diagnostics summary or a backup file containing health-related information about your child, that is special-category data, and we process it only with your explicit consent, given by choosing to send it, and only for the purpose of resolving your support request. You can withdraw that consent at any time by writing to support@bearingkind.com and asking us to delete it; withdrawing does not undo processing already carried out before you did.
• Where your message goes. We are based in Armenia and read support mail there. The mailbox is hosted by Apple, through iCloud+ Custom Email Domain, which handles the message in the course of delivering it to us. We do not route it anywhere else, and no other company receives it.

9. Service providers

Apple processes information for the App Store, purchases, and iCloud features under its own privacy policy and its agreement with you. We do not choose Apple's terms and cannot vary them on your behalf. See apple.com/legal/privacy.

Google processes information for three purposes on Android, all under its own privacy policy: it holds the encrypted copy described in section 3 in your Drive and keeps that copy's key in Block Store, it distributes the app through Google Play, and it sells the subscription there. See policies.google.com/privacy.

What we ask Google for, and what we promise about it. The app asks for one permission, to use the hidden folder Drive gives each app inside your own Drive. It asks for nothing else, so it never learns your Google name or email address. It uses that access only to store and read the copy you allowed. We use what we receive through Google's APIs only to provide that copy. We pass it to nobody, we serve no advertising with it, we run no analytics on it, and no person at BearingKind reads it, which we could not do in any case, because it is encrypted with a key we never receive. Those are the Limited Use commitments in the Google API Services User Data Policy, and they are what we hold ourselves to here.

Cloudflare, Inc. runs the machines, the storage and the network that BearingKind Sync and the app's update server use, and is the only company that does. It acts on our instructions under its data processing agreement, which includes the European Commission's standard contractual clauses for data that leaves the EU. It holds what section 3 lists, which means encrypted records and the technical data around them. It stores them in its European Union region and handles requests at the location nearest to you. See cloudflare.com/privacypolicy.

Functional Software, Inc., trading as Sentry, receives the crash and error reports described in section 4. It stores them in its European Union region, in Frankfurt, on our instructions under its data processing agreement, which includes the European Commission's standard contractual clauses for data that leaves the EU. See sentry.io/privacy.

For a copy of the standard contractual clauses that apply to Cloudflare or Sentry, write to support@bearingkind.com.

These policy pages are a separate, smaller matter. They are static pages with no cookies, no analytics, and no advertising, delivered by Amazon Web Services (S3 and CloudFront), which processes request details such as your IP address in the course of serving a page, under its own terms. We keep no access logs of these pages, and none of those request details reach us.

10. Your rights

If you are in the EU, the UK, or another place with similar law, you have rights to access, correct, delete, restrict, object to, and port your personal data.

Your records are under your direct control:

Crash and error reports (section 4) carry nothing that identifies you, so we cannot find yours to show or delete it, and Full reset does not reach them. They are deleted no later than 90 days after they reach Sentry.

Erasing a child's history. In a child's settings, Erase sleep history removes that child's sleeps and notes from your phone, your other devices and the app's copies in iCloud, Google Drive and BearingKind Sync. In Google Drive, files that another phone of yours wrote stay unchanged until that phone opens the app again; a phone that never does keeps its part of the history there until Full reset. A copy left in iCloud or Google Drive when the diary moved to BearingKind Sync, or when the phone changed its Apple or Google account, keeps the history as it was then. Two copies on the server side are out of the app's reach: the point-in-time recovery copy of the server's database, kept for 30 days, and a backup copy we make of the encrypted archive, kept for at most 30 days.

Full reset erases your diary and every diary you joined from your phone at once, also when the phone is offline. Then, in the background and until it is confirmed, the app deletes your diary on our server, then your sync account, which ends your membership in every diary you joined, then the app's copy in your iCloud or its files in your Google Drive, and the recovery material. On Android the Drive key stays in Block Store, so that another phone of yours on the same Google account can start its copy again; with the files gone, it opens nothing. The app returns to its first screen as after a fresh install. Know these things before you use it:

• Other people's phones delete your diary the next time they connect.
• It does not erase your other devices. A second iPhone on your Apple Account keeps its local copy and stops copying it.
• On a phone that shows your diary read-only because another phone records it, Full reset erases only that phone. The diary stays on the phone that records it.
• It does not cancel a subscription. Do that in the App Store or Google Play.
• Export a backup file first if you want to keep anything.
• Use it before you delete the app. If you delete the app first, the phone no longer holds the keys it needs to ask the server for the deletion. The server copy is then deleted on the subscription schedule in section 7.

What stays on the server after an account is deleted. A marker saying that the account and the diary were deleted, and the account's identifier together with the public half of the key it was made from. They are kept so that a restored backup or an old phone cannot bring deleted data back to life, and so that the same keys cannot recreate the account. If you ever bought a subscription, the short purchase record stays too (section 7). None of it says anything about a child. Backups are gone within 30 days (section 3).

What we cannot do for you, and why. Your sync account has no name or email address on it. If you write to us asking for your server data to be shown or deleted, we have no way to tell which account is yours, and no way to check that the person writing is you. That is the price of a service that never learns who you are. It is why the app does these things itself, from the phone that holds the keys. Write to us anyway if something goes wrong and we will help you get the app to do it.

For support material sent under section 8, write to support@bearingkind.com.

No sale or targeted-advertising feature exists or is planned.

If you think we have got any of this wrong, tell us first. You also have the right to complain to your national data protection authority.

11. Children

The app is designed for parents and caregivers to use. It is not directed at children and children are not its users.

It does hold information about a child, entered by you. This policy treats that information as sensitive throughout, even though the person using the app is an adult. The app is rated 4+ and is not published in the Kids Category.

12. Changes to this policy

If we change this policy, we will publish the new version at https://bearingkind.com/baby-sleep-tracker/privacy with a new effective date.

We will describe material changes to what BearingKind Sync stores, to sharing, analytics, advertising, or crash reporting before they take effect when the law or platform rules require notice or consent. We will not rely on a quiet policy edit to introduce a materially different use of child or household data.

13. Contact

Questions about this policy, or about anything in it:

support@bearingkind.com
Ivan Kuindzhi
Box 69, Nalbandjan 28, 0010 Yerevan\