Privacy Notice

What does Aurora collect about me?

It depends on what you use. The app processes your conversations on your device; no server of ours receives them unless you attach them to a diagnostic report. Its named network paths, such as the model download and anonymous usage measurements you can refuse, are all listed under what can leave. A diagnostic report leaves only when you send it, and its session-details switch starts on (reports). Conversation sync, if you turn it on, keeps text, never audio, in your own private iCloud. This website keeps your email address if you join the waitlist, and loads self-hosted analytics (website).

This notice covers three things: the Aurora app, the diagnostic reports you choose to send us, and the website at auroraisyours.com. The app is built so that your conversations are processed on your device, and no server of ours receives them unless you attach them to a diagnostic report; if you turn on conversation sync, their text is also kept in your own iCloud. A diagnostic report leaves only when you send it, and this page says what is in one. The website collects a little, and this page lists all of it.

Contents

1. Who we are
2. The app: what stays on your device
3. The app: what can leave, and why
4. Diagnostic reports
5. This website
6. What we store about you, and why
7. Deleting your data and unsubscribing
8. Your rights
9. Transfers outside the EU
10. Children
11. Changes to this notice

Who we are

The controller for the data described here is The Code Lab by Leandro Piccione, the maker of Aurora, of ul. Świeradowska 47, 02-662 Warszawa, Poland (NIP 7011105083, REGON 523096127, EU VAT PL7011105083). You can reach us at hello@auroraisyours.com.

The app: what stays on your device

Recording, transcription, speaker separation, summaries, notes and Ask Aurora run on the device in front of you. Audio, transcripts and everything generated from them are stored in the app's library on that device. The audio of each recording is deleted from the device once seven days have passed since it was last written, at the next cleanup, which runs when the app opens or comes back to the screen; audio that is still waiting to be refined is kept until that work is done. The transcript and everything generated from it stay until you delete them. Audio never syncs, and it leaves the device only if you attach it to a diagnostic report. We do not operate a server that receives your conversations. There is no account with us, and the app carries no tracking. The only measurements it sends are the anonymous usage counts described below, which you can refuse, and, if you use Aurora without a subscription, the minutes you record, counted against your free allowance; neither contains anything you said.

The app: what can leave, and why

Aurora is local-first, not network-free. These are the named network paths, and there are no others. Each one is listed here with what starts it, what it carries and where it goes; the same list is kept in the site's repository as a network inventory, read out of the app source at a named commit so it can be checked line by line.

• Model download. The speech and language models are fetched at setup, and again when a model is added or changes, so the device can work offline from then on. It is a real network request: no conversation content travels with it, but the host serving the models sees the request itself: your IP address, the time, and how much you fetched. Over a cellular connection, anything more than 100 MB waits until you allow it; the small live speaker-separation model is fetched either way.
• Setup time estimate. While models are being prepared, Aurora asks our own service how long preparation usually takes on a device like yours. The request carries four coarse fields (the platform, a device class, whether Low Power Mode is on, and the model generation) and no identifier. What comes back is an aggregate. Alongside it, the app downloads our published preparation profile, an aggregate table of timings that asks for nothing about you. A build with no estimate endpoint configured makes no request at all.
• Update check. An install from TestFlight or the App Store asks this website which build is current (at most every six hours on TestFlight and once a day on the App Store) so it can show an "update available" banner. The request carries no identifier, no cookie and no account; like any request, it shows the server your IP address. Development builds never send it.
• Settings in your iCloud. A few preferences (the workspace view, the transcription and refinement models you chose, your language list, your profile name, and your avatar, including the profile picture you chose as one small compressed copy) follow your Apple Account through your own iCloud key-value storage, together with each device's running totals of recording time and number of recordings, so the app can show them across your devices. This is always on and has no switch. It carries no audio, no transcript and no title, and no server of ours is involved: the data sits in your iCloud, under Apple's terms, where we cannot read it.
• Conversation sync, if you turn it on. Off by default, and set on each device separately: on iPhone in Settings → Sync → "Sync conversations with iCloud", on a Mac in Settings → General → Meetings & Sync. When it is on, the text of your conversations (titles, transcripts, notes, summaries, action items, speaker names, tags, location, Ask Aurora chats and folders, with their dates) is stored in your own private iCloud database and reaches your other devices where sync is also on. Audio is never part of it; the setting says so itself: "Audio stays on this device." No server of ours is involved, and we cannot read that database. With sync on, deleting a conversation deletes it from iCloud as well. Turning sync off stops it but does not remove what is already in iCloud, and a conversation you delete while sync is off stays there.
• Subscription check. When the main screen opens, Aurora asks our purchase provider, RevenueCat, whether you have a subscription, and it talks to RevenueCat and Apple's App Store again when you open the subscription screen, buy or restore. RevenueCat sees a random identifier its software creates in the app, your App Store purchase history for Aurora, basic device details such as the platform, system version, app version, locale and currency, and your IP address. It never receives your payment details, and we give it nothing else: no name, no email address, no advertising or device identifier, and nothing from your conversations. In a TestFlight build the subscription screen is also reachable from Settings so testers can exercise the real purchase flow.
• Free minutes, if you use Aurora without a subscription. Free use includes 20 recording minutes per calendar month, counted in UTC. To count them, Aurora talks to our own free-minutes service, which runs on Cloudflare: when the main screen opens, when you start a recording and after it ends. Each request carries the App Store's signed record that your Apple Account obtained Aurora, the platform, a random identifier for this installation kept in the device's Keychain and, for a recording, a random identifier for it and how many seconds it lasted. It never carries audio, a transcript or a title. Where the device supports Apple's App Attest, the requests are also signed with a key that proves they come from a genuine copy of Aurora; setting that key up asks Apple's own service to vouch for the device. Our service keeps no Apple identifier: it turns the App Store record into a keyed pseudonym, the same one each time so that your devices share one allowance, and stores under it the seconds used in each month, when each counted recording started and was settled and how many seconds it was charged, a pseudonym of each installation, and the App Attest public key. It answers with a balance it signs, which the app keeps in the device's Keychain, so you can record offline until that balance runs out; before its first answer, a device can use its first 20 minutes offline, once. Rows are deleted as they age past these limits the next time that account checks in: monthly totals after a year, recordings after 120 days, offline-use records and unused keys after 400 days. An account that never checks in again keeps its rows; there is no automatic deletion for that case yet. To limit abuse, the service counts requests per hour under a keyed hash of your IP address, which expires within the hour. Subscribers, development builds and copies that did not come from the App Store or TestFlight never contact it.
• Usage metrics, if you agree. Aurora asks whether it may share anonymous usage data (setup timings, recording time and the number of recordings) to help improve the app, and the question itself says it never shares recordings, transcripts or anything that identifies you. On iPhone it asks at the end of setup; on a Mac it asks once after setup, before the main window opens. One answer covers two kinds. The first is how long model preparation took on your device, whenever models are prepared (at setup and later, after an update for example): the model and its version, the queue and run durations, the outcome, and the thermal and Low Power conditions while it ran. The second is how much you record: recording time, the number of recordings, and how many of them fall into each length range (under 1 minute, 1–5, 5–15, 15–60, and 60 minutes or more). Recording measurements are sent as additions since the last report the intake accepted, never as running totals, so they need no identifier; the first report adds up what you had recorded before. A report is sent after a recording is saved on the device, when the app starts and when you change your answer, and one that fails to arrive is retried later. Each report also carries the platform, a device class, the major OS version and the app build. It contains no identifier, no audio, no transcript, no titles and nothing generated from what you said. A report holds no dates or times, but it is usually sent right after a recording is saved, so our intake can see roughly when that happened. Like any request it arrives with your IP address, which is used only to limit how often one address can send within an hour and is not stored with the report. Stored usage reports are kept for at most 30 days; after that only totals remain, and totals cannot be traced back to a device. Saying no, or never being asked, means nothing is sent. You can change your answer at any time: on iPhone in Settings → Privacy → Share anonymous usage data, on a Mac in Settings → General → Privacy.
• "How did you hear about Aurora?" At the end of setup on iPhone, Aurora asks how you heard about it. Skip sends nothing. Send posts the option you chose, anything you typed after "Somewhere else" or about an AI assistant, and the app's version to this website, signed with App Attest so we know it came from the app. It is kept with the research answers described under What we store about you, for two years.
• Diagnostics you send. A report leaves the device only when you choose to send one. What it carries is set by two switches: the one for the session's details starts on, and the one for the recording starts off. Diagnostic reports describes both, how a report is encrypted, and how long it is kept. When the app opens, it may ask our report intake where reports are delivered and which public key encrypts them; that lookup carries nothing about you or your sessions.
• Exports you make, and links you open. Anything you export or share goes to the destination you pick, and nowhere else. A meeting link from your calendar, or Help on a Mac, opens in the app or browser that handles it. From that point its own privacy terms apply, not ours.

Calendar access is not in that list because it is not a network path. Aurora reads your next event on the device, through the system calendar, and sends nothing anywhere for it.

Putting the phone in airplane mode and recording is a good test, and it proves one thing precisely: capture, transcription, speaker separation and summaries work with no network at all. Without a subscription, a recording starts offline as long as the minutes your device last had confirmed are not used up. The test does not prove that none of the paths above exists, because each of them happens at a different moment: when the app opens, around a recording, when you allow something, or when you send something. Adding a new network path is a product decision we would have to make on purpose and write down here.

Diagnostic reports

Recording, transcription, speaker separation and everything generated from them stay on the device, as above: none of it is sent to us as part of normal use. Aurora does keep technical diagnostics locally, so that a problem can be investigated if you decide to report it. Nothing is sent or shared until you act. When you do, Aurora sends an encrypted report to our report intake; the report flow has no other destination, and no Share, Files or Save control that would hand the package to another app. After a crash Aurora may ask once whether to send what it collected; if you decline, nothing is sent. Once you start a send, the same attempt may continue or retry in the background or after a relaunch; Aurora does not create a second report and does not widen what it includes during those retries.

Two switches, and where they start

Every report carries the description you type, which the form requires, and the technical diagnostics. On top of that, the form has two switches. The first, "Include session details in report", adds the images and, on a report about a session, that session's title, tags, transcript, summary and Ask Aurora chat; the caption under it names exactly what it is adding at that moment. The second, "Include the recording", appears only on a report about a session whose audio is still on the device, and adds that recording. It can only be on while the first one is. Notes you wrote against a session are never attached.

The first switch starts on; the recording switch starts off. We would rather tell you that than describe a default the app does not have: the decision in front of you is not "shall I attach my transcript" but "shall I leave my transcript attached". Turning it off before you send takes one tap, and the report stays useful, because the technical diagnostics are what explain most failures. Aurora's product contract still describes reports as content-free by default; for the recording that is how the build behaves, for the rest of a session it is not, and where the contract and the build disagree, this page describes the build.

Images. When you open the form, Aurora takes a screenshot of its own window, not of your whole screen, and shows it first; a report that begins at a crash prompt has none. You can add photos or image files of your own, up to six images in all, and remove the ones you added; the screenshot goes when you turn the first switch off. Every image is re-encoded on your device as a compressed JPEG, at most 1,600 pixels on its longest side, and the location, camera and date details a photo carries are left behind. Images travel only while the first switch is on.

A report with no session attached (one you start from Settings rather than from a recording) never carries a transcript, a chat, a summary or a recording, whatever the switches say; there the first switch adds only the images, and the form says so itself.

What a report contains

The form does not show tiers by name; the first switch picks one of two:

• Standard. What the first switch, off, sends. Your description, app and build details, device details, technical session state, a scrubbed diagnostic log, lifecycle and MetricKit diagnostics, an environment snapshot with recent environment history, model presence and integrity state, and recent session outcomes. Session title and tags are removed. It contains no transcript, summary, session note, chat, image or audio.
• Full. What the first switch, on, sends. Everything in Standard, plus the images and, on a session report, the session's title, tags, transcript and summary and its Ask Aurora chat. The recording is added only when the second switch is on too, and only while the audio is still on the device: after the seven days described under The app, there is none left to attach. A global report never picks an arbitrary recording or transcript for you.

Scrubbing the log is a protective filter, not a promise that technical diagnostics can never contain personal information. A full report can carry highly sensitive speech and text. Read what the form tells you it is attaching, and turn the switches off unless that content is what makes the problem reproducible.

How a report travels

For a direct send, Aurora checks the report's structured contents against their schema and then encrypts the complete archive on your device with the maintainer's public key, before anything is uploaded. The upload itself uses HTTPS. The public intake and its Cloudflare R2 storage hold the encrypted envelope and a limited receipt: a random attempt and ticket identifier, the time it was received, the encrypted size, the app version, and the identifier of the encryption key. The public service has a health route, a route that tells the app where to deliver and with which public key, and authenticated write routes, and no route that reads or decrypts a report. The token the app carries limits abuse; it is not proof that a caller is a genuine Aurora installation.

The plaintext can be decrypted only with the matching private key, on a private report dashboard that is not reachable from the public internet. Cloudflare provides the encrypted storage and transport and holds no decryption key. To slow abuse, the intake may count requests per IP address for one hour; that counter expires with the hour, and the IP address is not written into the report receipt.

There is no separate export path today. The plaintext package exists on your device only as part of a delivery you started, and it is deleted when the delivery succeeds or when you discard it. If we ever add a control that hands the package to another app, this page will describe it before it ships, including the fact that a copy in another app is one we cannot recall or delete.

How long we keep it

On your device, the diagnostic stores are bounded:

• Lifecycle events and MetricKit rows. Normally 14 days, capped at 20,000 events and 500 payloads. MetricKit payloads for a crash whose report prompt is still unanswered, or accepted but not yet sent, can be kept beyond that window.
• Environment change history. A report carries the most recent 48 hours, and the file is capped at roughly 1 MB.
• Diagnostic logs. A ring bounded by size, normally capped at about 16 MB. That is a size limit, not a guaranteed number of hours.
• Unfinished deliveries. The plaintext, the encrypted copy and the receipt for a delivery in flight are deleted when it succeeds or when you discard it, and otherwise become eligible for cleanup after seven days. Cleanup runs when delivery processing runs, so seven days is when a file becomes eligible, not the moment it disappears.

On our side there is no automatic age-based deletion today. An encrypted report stays in storage until the maintainer closes it and explicitly runs the remote cleanup; the routine cleanup clears only the private dashboard's local cache. Retention is therefore manual and, until someone closes the report, potentially indefinite. We owe this page a maximum age and do not have one yet; if we ship an automatic policy, it will be written here.

What we do with a report

Reports are used to diagnose, support, secure and improve Aurora, and for nothing else. They are not used for advertising, marketing, sharing with data brokers, cross-app tracking or personalizing the product. There is no report account identifier, and we do not join reports to advertising or other identity datasets.

Deleting a report

To have a report closed and deleted, write to hello@auroraisyours.com. The app does not show you the report's ticket identifier after sending, so give the approximate date and time you sent the report, the Aurora app version, and what you wrote in its description. Because there is no report account identifier, we may not be able to identify your report reliably from that. Once the request is verified we close the ticket and delete the encrypted object and the dashboard cache under our control. Deletion cannot undo diagnostic work already done before the report was deleted, so it is worth writing to us promptly.

This website

The site sets no cookies. Production pages load one self-hosted analytics tool, Rybbit's tracker and session recorder. It is not loaded when your browser sends Do Not Track. It omits query strings and fragments. It also records anonymous waitlist steps, each one only an event name with no value attached: a click on a "Join the waitlist" link, starting the form (once per form on a page), sending a form that passed the page's own check, a sign-up only after the server has accepted it, and a view of the page that thanks you for confirming the newsletter. None of them carries your address or the link's code. The tracker sees the page path, title, hostname, referrer, language, screen size, browser and operating system. Rybbit also derives an approximate location (country, region and city) from your IP address, using a database on our own server; the IP address itself is not stored. Its visitor identifier is a hash that changes every day, so visits on different days are not linked. Opening one of our short links (an address on this site that forwards you elsewhere) is counted as a page view of that address, which our server sends to the same self-hosted Rybbit with the path, hostname, referrer, language and browser details, and your IP address for the location and daily identifier above; it is not counted when your browser sends Do Not Track. Rybbit records a session replay of the page: clicks, scrolling, navigation and page structure, with every input field masked and the lines that name your address or your place in line blocked out. The waitlist's own pages, which can show your address, and the research forms are never replayed. We no longer record heatmaps. These analytics never receive your email address, form values, audio, transcripts or diagnostic reports. The page-view and waitlist-step history collected earlier by our self-hosted Umami analytics was moved into Rybbit, and Umami was deleted. The site relies on six services, each for one job:

• Cloudflare. Hosts the site and its DNS, routes inbound mail for hello@, runs the Turnstile bot check on the waitlist and research forms, stores research answers in our own database in its EU jurisdiction, and provides aggregate, cookieless analytics: page counts and load times with no identifier for a person. Turnstile processes browser signals to tell people from automated traffic; it does not read what you type into the form. Cloudflare's Turnstile privacy addendum applies to that check.
• Rybbit. Our self-hosted page-view, event and session-replay analytics collector is served through serveaurora.leandropiccione.com/rybbit. It accepts only the tracker and recorder scripts, their settings and their event and replay ingest paths; the dashboard is at tracking.auroraisyours.com, reachable only over Aurora's private tailnet.
• Brevo. Holds the waitlist, in its EU hosting: it stores the email address you give us, sends one email to say you are on the list (or, if you are already on it, a short note saying so), and later the one email with your invite. The newsletter is a separate list with a separate consent: ticking the box sends a separate confirmation email for the newsletter alone, whether you are joining or already on the list; nothing else changes. Brevo counts how many of those emails are opened and how many of their links are clicked; we have set it to count those in total, not per person. The one thing it keeps against your address is the date you last opened one of our emails, which it uses to keep its mail deliverable.
• Cal.com. Only if you say yes to a call at the end of a research survey: once your answers are saved, the page shows Cal.com's booking calendar, and loading it gives Cal.com what any website receives, such as your IP address and browser. What you enter there to book goes to Cal.com and to us, and we use it only to hold that call. None of your answers is passed to Cal.com. Cal.com, Inc. is a US company and processes data in the United States; its privacy policy says it relies on the EU-U.S. Data Privacy Framework, and on standard contractual clauses where appropriate, for transfers from the EEA.
• Better Stack. Probes our own site to tell us when it is down. The probes contain no visitor data.
• Apple TestFlight. The beta is distributed through Apple's TestFlight, by invitation. There is no public TestFlight link on this site, and joining the waitlist sends nothing to Apple. When we release your invite from our internal dashboard, Apple (App Store Connect) receives your email address, so that Apple can send you the TestFlight invitation. Apple's terms and privacy policy apply to that invitation and, once you accept it, to the app.

Our own counters record that a sign-up happened and whether the welcome email went out. They carry no email address, no IP address and no other dimension that points at a person.

Once the server has accepted your request, your browser keeps one note on this device: the address, the day you asked, your place in line if the server gave one, and whether you ticked the newsletter box. It is there so the form can show your request on a later visit instead of an empty form. It lives in your browser's local storage, not in a cookie, and it is never sent anywhere. It is ignored and removed after 180 days, and "Not you? Start over" clears it at once. Nothing is kept on the device before the server accepts a request.

What we store about you, and why

If you join the waitlist, your email address goes on the waitlist as soon as you send the form, together with the time you joined, your place in line and the version of the consent sentence you saw. There is no separate confirmation step: the form says what the address is for, and giving it for that purpose is your consent (GDPR Art. 6(1)(a); Polish Electronic Communications Law, art. 398(2)). The first email we send confirms that you joined and carries a link to remove your address, so if someone else typed in yours, you can take it off. If our mail provider refuses to send to an address, we take it off the list again; if an email to it bounces as undeliverable, we block it from further email and leave it out of the count. Invites go out in waves, chosen either by place in line or by random draw among the people still waiting; we may also add an address by hand, for example for someone who wrote to ask, and invite it straight away. When your invite goes out, we record the time it was sent, and later waves skip addresses already invited. Our internal dashboard also keeps a record of each release: who on our team released it, when, how the wave was chosen and its label, and for each person the address and whether the invite went through; we keep it as long as the beta runs. We use the address for one thing: your invite to the Aurora beta: giving it to Apple so that Apple can send you the TestFlight invitation, and emailing you once, when your invite is ready. Your consent, given at the form, is the legal basis.

The newsletter is a separate consent, with its own confirmation. The box is unticked; if you tick it, whether you are joining or already on the list, we send a confirmation email that covers the newsletter and nothing else, and we record when you asked and the version of the newsletter's consent sentence you saw. The newsletter starts only after you confirm from that email. A newsletter request that is never confirmed is dropped after 30 days. Your entry page lets you leave the waitlist or stop the newsletter separately; the unsubscribe link in any email from us stops every email from us.

The link in the welcome email, and the link in the note we send when an address is already on the list, open your entry page. It shows your entry (the lists it is on, when you joined and were invited, your place in line, and which version of the consent sentence you saw) and lets you leave the waitlist, stop the newsletter, or delete everything. If you leave the one list we hold your address for, nothing is left to keep, so we delete the address and our log of the emails we sent you as well. A link works for 180 days; after that, join again with the same address and we send a short note with a fresh one. The page takes the link's code out of your browser's address bar as soon as it opens and keeps it only in that browser tab.

Until your invite, the only emails we send are replies to your own request: the welcome email when you join, or, if the address is already on the list, a short note saying so, at most one a day; and, if you tick the newsletter box, the newsletter's own confirmation email, at most one a day. If we cannot send it straight away, because the day's sending allowance is used up or our mail provider is down, we keep the request and send it automatically, within about a day, and the form tells you so.

We keep an address on the waitlist until you leave, your invite is sent and the beta ends, or we close the waitlist, whichever comes first. The form never says that an address was already on the list and never shows an existing member their place; that answer goes only to the address's inbox. The homepage may show how many people have joined; that number is a count from Brevo, leaves out addresses that are blocked from email, and says nothing about any one person. If you send a diagnostic report, what we hold for it is the encrypted report and its receipt, on the terms in Diagnostic reports.

From the app, we hold only what the paths above describe: if you use Aurora without a subscription, the free-minutes ledger under a pseudonym, for the times given under The app: what can leave; if you agreed to them, anonymous usage reports, for at most 30 days; your answer to the onboarding question, if you sent one; and any diagnostic report you send. Your conversations are not among them, and the text you sync stays in your own iCloud.

Some pages ask optional research questions about how you work and what you would use Aurora for. Your answers are sent only when you press send at the end, and they are stored in our own database at Cloudflare, held in its EU jurisdiction, separate from the waitlist and from Brevo. With them we store which form and version you answered, the time you sent it, that it came from the website, the language you answered in and, if the link you followed named one, the channel it was shared on (such as LinkedIn or Reddit). We also keep how long each question was on your screen, in whole seconds, to see which questions take longest: only how long, with no time of day. We do not store your name, email address, IP address or any cookie or device identifier with them, and joining the waitlist from the same page is a separate request that is not linked to your answers. The invitations on our own pages name only where they were: the newsletter's thank-you page or the waitlist form, never who followed them. While you fill in a survey, your browser keeps your answers so far, and how long each question has been on screen, on this device so you can close it and continue later where you left off, and the site's other pages show a small card inviting you back. They are kept in your browser's local storage, not in a cookie, and are not sent before you press send. They are removed once your answers are saved or when you choose “Start over”, and ignored and removed 30 days after your last change; closing the card hides it for that browser session and keeps your answers. If you type personal details into a free-text answer, they are stored as you wrote them, so please leave them out. If a survey ends by asking whether you would talk to us and you say yes, the booking calendar that follows is Cal.com's, loaded only then, or later when you choose to book from the reminder below (see Cal.com above); the booking is not stored with your answers. Your browser then keeps a note on this device that you asked to book a call, with the language you answered in and the time but without your answers, for up to 14 days, so the site's pages can show a small card reminding you. The note is removed when you book through the calendar on our page, or when you choose “Don’t ask again” on the card. To notice the booking, the page reads only the calendar's own message that a booking was made, and posts nothing back to it. We read the answers in our private dashboard to decide what to build. Your consent, given by sending the form, is the legal basis. We delete answers two years after they were sent. Because an answer carries nothing that identifies you, we cannot look up yours by your name or address; to have one removed, write to hello@auroraisyours.com with roughly when you sent it and what it said, and we will delete it.

Aurora's own question at the end of setup on iPhone, “How did you hear about Aurora?”, is stored in the same database. An answer sent from the app carries the form and version, the time it arrived, that it came from the app, and the app's version and build, and no name, email address or IP address. So that one installation answers only once, we keep with it a keyed hash of the App Attest key that signed it, and separately that key's identifier and public key, which name nothing about you; a key unused for 400 days is deleted. We delete these answers two years after they were sent, like the others.

Deleting your data and unsubscribing

Every email we send has an unsubscribe link, and using it stops every email from us straight away: the welcome, the newsletter and your invite alike. To stop only one of them, use your entry page instead. To have your address and everything attached to it removed, write to hello@auroraisyours.com from that address. We aim to finish within a month and confirm when it is done. You can also do it yourself: "Delete everything we hold" on your entry page removes your address and our log of the emails we sent you from Brevo at once, and it cannot be undone. To delete a diagnostic report, write to the same address with when you sent it: see Diagnostic reports for what we can and cannot remove.

Your rights

Under the GDPR you can ask for access to your data, have it corrected or erased, restrict or object to how we use it, and receive a copy in a portable form. Where we rely on consent, you can withdraw it at any time, as easily as you gave it. Your entry page is the quickest way to see your waitlist entry or erase it; for a copy of everything we hold about your address, including when each of our emails went out, write to hello@auroraisyours.com from that address. You can also complain to a supervisory authority: in Poland, the President of the Personal Data Protection Office, UODO; elsewhere in the EU, the authority in your own country.

Transfers outside the EU

Brevo holds the waitlist in its EU hosting, and the research answers are held in Cloudflare's EU jurisdiction. The app's diagnostic reports, usage reports and free-minutes ledger are stored at Cloudflare without a location restriction, so they can be held outside the European Economic Area. Where Cloudflare or Brevo handles data outside the EEA, the transfer is covered by the European Commission's standard contractual clauses in our agreements with them. RevenueCat, Inc., which answers the app's subscription check, is a US company; its Data Processing Addendum makes the same standard contractual clauses available for transfers from the EEA. Your settings and any conversation text you sync are held by Apple, in your own iCloud, under Apple's terms.

Children

The website and the beta are not directed at anyone under sixteen. If you think we hold an address from someone younger, tell us and we will remove it.

Changes to this notice

When this notice changes, we update the date at the top and keep this address stable. If a change affects what we collect or why, we tell testers by email first.

See also

1. Terms of Use: the website and the beta.
2. Recording & Consent: recording other people, and your responsibility to them.
3. The boundary: the same list of what stays and what can leave, on the homepage.
4. Support: the one address, deletion requests, and how to report a wrong claim on this site.
5. How invites work: the private beta on TestFlight, what an iPhone needs, and the waitlist.
6. Engineering notes: first-party measurements of what the app does and what it costs.