How we handle what you put in The Stage

No password

The Stage does not use passwords at all. Not "we hash them carefully," not "we require special characters." There is no password to create, and no password field to sign into. Sign-in is Sign in with Apple, Sign in with Google, or a one-time 6-digit code to your email, which is a much more secure setup than storing a password on our side.

This was a deliberate design decision. A lot of the breaches people hear about start with passwords: a stolen password database, a reused password from another site, or a fake login that tricks someone into typing one. We do not use passwords, so those particular failure modes are not how someone gets into The Stage. A code is still only as safe as the inbox it lands in, and it is only good once and for a short window. If you signed in with Apple or Google, we never see a credential at all. Apple or Google tells us "this is her," and that is the entire conversation.

Email is sign-in, not inbox access

If you are wondering about "connecting your email," that is really just how you sign in here, same as a lot of apps. Whether you use Sign in with Apple, Sign in with Google, or the one-time code, we are establishing who you are so you can get into your account. We are not asking for permission to read your mail, send mail as you, or sync your messages. There is no Gmail (or any mail provider) connect to grant or revoke, because that permission does not exist in the product.

The only optional external account you can actually connect for calendar is Google Calendar, covered below. That is calendar write access to a Stage-created calendar, not email.

Getting permission from Apple and Google is not a form you fill out

This is the part that says something about how seriously a company is being taken by people who audit these things for a living.

Apple

Offering Sign in with Apple means Apple grants your app a specific entitlement, and then holds you to their rules. Apple dictates where their button sits on the screen relative to everyone else's. Apple requires the credential we use on the web to be re-signed and rotated on a fixed schedule, and if we miss the window, Apple stops letting people in until we fix it. Apple requires that when we ask for a permission, the sentence explaining why has to be specific to what you actually get out of it. A generic "we need access to your calendar" tends to get the app rejected.

Apple also makes you fill out a privacy questionnaire that becomes public on your App Store listing, and you are on the hook for its accuracy. Ours says: we collect your email, the content you create, and an account identifier, all for running the app. It says we do not collect your location, your contacts, your photo library, your browsing history, or advertising data. It says we do not track you. That is a statement Apple can hold us to.

One more thing that tells you how far the passwordless design goes: Apple's review team needs a working login to test the app, and we had no password to give them. We had to build a purpose-made, single-reviewer, rate-limited entry path just so they could get in. We could not simply hand them an account, because we do not have that kind of account.

Google

Connecting a Google account for calendar meant going through Google's full verification review, which is the months-long one with the sensitive-scopes assessment where they examine what you are asking for and why you need it. It is approved. This is the process a lot of small apps skip, which is why you may have clicked past a red "this app isn't verified" warning before. You should not see that warning here.

The calendar, which is optional and off

You do not have to connect it. It is off by default, nothing in onboarding asks you to, and the app is fully usable without it. It exists only because some people want their bookings showing up in the calendar they already live in.

If you do connect it: we ask Google for a permission that is meant to let us write to a calendar our app itself creates (calendar.app.created). That scope is not for reading your existing calendars: not your meetings, not your other auditions, not your personal life. Your Stage events land in a separate calendar named "The Stage" inside your Google account, so it does not mix into your own by default. You choose which categories sync, down to the individual type.

Disconnect is one button, and it does two things: tells Google to revoke our access at their end, then deletes our copy. There is a separate, unchecked-by-default box if you also want the events removed. We deliberately did not build a single button that does both, because that puts deleting your data one wrong click away.

There is also a no-permissions option: a read-only subscribe link that works with Apple Calendar or Outlook and requires connecting nothing.

Your sides

By default, sides you upload or paste stay in your account. Private storage, temporary keys when you open a file, no permanent public address sitting around.

You can share sides on purpose. There is an opt-in link that publishes a clean page with the title and the sides so a partner, coach, or reader can run lines with you. Printable. No account required for them. Your notes, objectives, takes, and workbook stay off that page. That is enforced at the database level: the public page is built to receive only the lines you chose to publish, not the rest of your workbook.

Worth knowing: that link shows the dialogue, so use it for material you are free to share. You turn it on, you turn it off.

How "off" actually stops access

Turning a share off does not change the link text. The URL stays the same. What changes is a flag on our server (on or off). Every time someone opens that link, our server checks the flag before it returns anything. If the flag is off, nothing is returned: the viewer gets a not-found response. It is not your browser hiding the page. The server refuses to serve it. Anyone who already had the link will stop being able to open it once it is off.

How private files work when you are not sharing

A lot of products give your file a permanent address. Anyone who ends up with that address can often keep opening it. Ours do not work that way for private files. When you open a side file in your own account, we check that it is yours and then cut a temporary key on the spot. That key works for that one file, and it stops working in about an hour. There is no long-lived private-file link meant to leak by accident. If someone else tries to request a key for your file, the answer is no, checked against who owns it, at the database level rather than just hidden in the interface.

The same pattern applies when media sits behind a live share: the server checks the share flag first, then cuts a fresh temporary key for the file. An expired key stops working even if someone bookmarked it.

What else you can share

All opt-in. All yours to switch off. Same mechanism as sides: the link text stays the same; our server checks an on/off flag and returns nothing when it is off.

• Your public profile page is off by default. You turn it on, and you control it section by section. The slug stays the same when you turn it off; the public lookup returns empty / not found until you turn it back on. That switch is enforced on our server, not only in your browser.
• You can publish a package of selected photos, clips and voice samples as a private link. The link is a long random string, so it is hard to guess, and you can add a password on top if it is something confidential. If you unpublish it, the same link stops working (server returns not found) and we remove those published copies on our side.
• You can share an individual self-tape as a link, and switch it off. Same flag check: off means the server will not hand out a view key for that tape.

We also mark these share surfaces so search engines are asked not to index them. That is not a guarantee that nothing ever gets cached elsewhere.

Two honest limits: any link you already handed out keeps working until you turn it off or it expires, and if you posted something somewhere that generated a preview thumbnail, that service may keep its own cached copy and we cannot reach into it. That is true of most websites, but we would rather say it than let you find out.

The AI voice, and exactly what moves where

Cue gives you three ways to hear the other character. Your phone's built-in voice, which is free and does not send the line text to our voice vendor. A recording of a real friend reading their lines, which is just audio you already made. Or an AI voice.

If you pick the AI voice, here is the entire transaction: we send the words of that line to the voice provider, and they send back an audio file of those words. Text goes out, sound comes back. It is the same basic shape as any AI voice tool that speaks a line.

Your voice does not go there. Your recordings do not go there. Your microphone is not connected to that vendor. The traffic for that feature runs one direction, it carries text, and the only thing that comes back is a sound file we store privately with you. The audio is cached on our side, so re-running the same line usually does not go out again.

If you are ever rehearsing something under NDA and you would rather no line of it leave the building, use the phone voice or a friend's recording. Both are free, and neither sends line text to the voice vendor.

And a related one, since we would rather over-disclose: when Cue listens for you to finish your line, that is your phone's own speech recognition, the same thing that powers dictation on your keyboard. On a current iPhone it runs entirely on the device. On some older devices, and in a web browser, the operating system or browser may process that audio on its own servers, exactly as dictation does. That is Apple's or Google's plumbing rather than ours, and we do not receive or store that audio, but "your voice never leaves your device" is a sentence we do not want anyone saying when it is not universally true everywhere.

Payments

Checkout runs inside Stripe's own window, or through Apple if you are in the app. Your card number stays with them. It does not pass through our servers, so it is not something that can leak from us.

The boring foundation

Your data is encrypted while it is moving over the network and while it is sitting on our servers. The database and file storage are run by two of the larger infrastructure providers, both independently audited, which means we are not hand-rolling the parts that are easy to get wrong.

What we claim credit for is the discipline. Sensitive keys and secrets live on the server, not baked into the app on your phone for someone to dig out. Permissions are enforced at the database itself rather than only in the interface, which is the difference between "we do not show it to you" and "the system is not supposed to hand it over." Sensitive tokens get a second layer of encryption on top of the first, tied to your specific account, so one stolen blob is much less useful on its own. Secrets are rotated on a written schedule rather than whenever someone remembers. And the whole thing has been audited more than once, with the findings written down and tracked, including the ones still open.

We are a small company, not a bank. We design for the failure cases that matter here (account access, private media, sharing) and we have reviewed those paths more than once.

Questions: privacy@thestage.actor. The legal Privacy Notice is at thestage.actor/privacy.