This Privacy Policy explains how theSHFT LLC ("theSHFT," "we," "us" or "our") collects, uses, shares, keeps and deletes information when you use the theSHFT mobile application, any web version of it we offer, our website at https://theshft.app, our support email, and our sales representative program (together, the "Services"). It applies everywhere we offer the Services. Words defined in our Terms of Service have the same meaning here. This policy describes what the Services do on the Last Updated date; where a feature is switched on for some users and not others, the policy says so.

1. WHO WE ARE AND WHAT THIS POLICY COVERS

1.1. The company responsible for your information (the "controller") is theSHFT LLC, 212 W. Troy St., Ste B, Dothan, AL 36303, United States, support@theshft.app.

1.2. This policy covers information about users of the Application, visitors to our website, people who email us, and applicants to and members of our sales representative program. It does not cover information handled by Apple, Google or other companies under their own policies, such as the App Store's purchase records or your device's operating system.

1.3. Other users of theSHFT decide what they do with the messages and Content you send them. This policy does not govern what they do with it.

2. INFORMATION YOU GIVE US

• Username: the name you choose when you create your Account. It is visible to every signed in user and is how others find you.
• Bio and profile photo: optional. Your bio is visible to every signed in user. Your profile photo is shown according to your Profile Photo setting, which is set to Everyone unless you change it. That setting controls where the Application shows your photo; the photo's storage address and key are kept on your account record, which other signed in users' Applications can read, so a modified application could obtain your photo whatever the setting. Profile photos are stored encrypted at rest with a key our servers hold, so they are not end-to-end encrypted.
• SHFT look: optional. If you save a SHFT look, its outfit, color and pose are kept on your account record and shown to every signed in user wherever your avatar shows without a photo. Some looks say something about you: a Pro look shows you have theSHFT Pro, a look you earned shows that you earned it, and the Birthday look shows that someone joined with your invitation.
• PIN: theSHFT no longer asks for a PIN to open, and nothing in this version asks you to choose one. We never receive a PIN, except as Section 17.4 explains for versions before 9.5. If your Account still has a PIN check from an earlier version as a two step method, we receive a one way value computed from it, never the PIN itself (Section 26.6).
• Profile card: optional. A display name (never a legal name, up to 30 characters), a bio of up to 150 characters, up to three interests from a fixed list, up to two more photos besides your profile photo, and up to three Open SHFTs you host that you choose to show. Other signed in users who can open your profile see them; someone who blocked you, or whom you blocked, sees nothing. Your email address and phone number are never on it. Each added photo is checked as Section 18.2 describes and is shown to nobody but you until it passes. You can change or remove any part at any time (Section 3 says how long photos are kept).
• Birth year: when you create your Account we ask "What year were you born?" and, in the one year where it matters, whether your birthday has come this year. We use the answer only to check that you meet the minimum age (eighteen (18), or higher in some countries, as Section 34 says) and we do not store it, on our servers or on your Device (Section 3).
• Email address or phone number: required, your choice of one (new Accounts at once, older Accounts after seven (7) days). You can add an email address confirmed with a code we email you, an email address with a password, Continue with Apple, Continue with Google, or a phone number, so you can sign in on a new phone and get back into your Account if you lose your phone. Sections 26.4 and 26.4A explain what we keep, why, where, for how long and how to change it.
• Password: asked when you sign up with an email address (not with Apple, Google or a phone number), and you can add or change it later in Settings, Keep your account; an Account made before passwords existed is never forced to add one. It is eight (8) to one hundred twenty eight (128) characters. You type it into the Application, it travels over an encrypted connection to our servers once, and the sign in record described in Section 26.4 keeps only a value computed from it with a secret key that only our servers hold, never the password itself, and nothing about it stays on your phone. It is not a lock: opening theSHFT never asks for it. It is asked only to sign in on a new phone and to change it, and a right password only starts an Account recovery (Section 26.5). Section 26.4 explains the rest.
• Saved chats for sign in, only if you turn it on: optional. If you choose to keep your chats for sign in, they are saved encrypted on our servers, in sealed pieces that only a key held by your account opens. That key is kept for you with the backup service of your phone (iCloud Keychain on iPhone, Google backup on Android), and a reset key is held in Google Cloud Key Management Service. The reset key lets your chats come back after you reset your password, and only after the check we email you and the waiting period that gives your old phone time to say no. Messages whose timer has ended are deleted from the saved copy. Turning this off deletes the saved copy (Sections 9.2 and 26.1).
• Show photos on calls, iPhone only, off unless you turn it on: if you turn this on and allow Contacts, theSHFT saves the friends you chat with to the Contacts on your iPhone, each with their profile photo and a contact address of the form username@calls.theshft.app, so your phone can show their picture when they call. This is saved only on your phone and is never sent to us. People you have blocked are never saved. A contact is removed when you turn the setting off, when you unfriend or block that person, and when you sign out.
• Two step, only if you turn it on: optional. You can ask that a new phone also needs a second step that only you have: a passkey, a code from an authenticator app or a backup code (an Account that already had a PIN check from an earlier version keeps it until you remove it; it is no longer offered as a new method). For a passkey we receive its public key and a few details about it, never its private key; for an authenticator app, the secret that makes its codes, which we keep encrypted; for backup codes, only one way hashes of them. Section 26.6 explains what each one keeps, why, for how long and how to remove it.
• Contacts: when you add a contact, accept a contact request or redeem an invitation, we store your contacts list (the account identifiers and usernames of your contacts, and any nicknames you give them) in a private part of your Account that only you and our systems can read, a relationship record for each pair of contacts (the two account identifiers and a time), and pending contact requests. The number of your friends (your accepted contacts) is public: it is shown on your profile to anyone who can see your profile, and someone looking at your profile sees how many friends you have in common (a number). Nobody sees your nicknames or your private contacts list. Who can see the names on your friends list is your choice in Edit profile, Who can see my friends list: Everyone (until you change it), Friends or Only me; a person you blocked or who blocked you never sees it, and each row shows only a username and display name. The Application reads your device's address book only if you tap Find friends from your contacts and allow it (below). If you invite people from your contacts, your Device's own contact picker opens. The Application never sees your Device's contacts: it receives only the people you pick, uses only the name shown and one phone number or email address for each, and puts them into a separate text or email for each person that your Device's messaging or mail app sends if you choose to send it. We do not receive those names, numbers or addresses, and the Application does not keep them.
• Find friends from your contacts: only if you tap it and allow access to your contacts, the Application reads the phone numbers in your Device's contacts, on your Device. Each number is turned into a scrambled code that only your Device can unscramble. We receive those codes and how many numbers you checked, and nothing else from your contacts: never their phone numbers or names. We cannot work the numbers out from the codes, and we do not learn which of your contacts are on theSHFT; your Device does the matching against the people who chose to be found. Nothing from your contacts is kept on our servers or on your Device after you leave that screen. To limit misuse we keep counts of how many checks and numbers each account and network made recently (not the codes), for up to thirty-one (31) days. People who are found are never told that you checked. If you send a request to someone you found this way, they see that you found them by their phone number, and we keep a record that the request came from a phone number match (the two account identifiers and a time) for thirty (30) days, so they can see that label and so we can act on misuse. If several people block requests you sent this way, Find friends from your contacts stops working for your Account for a while.
• Let friends find me by phone number: off unless you turn it on, and offered only if you have added and verified a phone number. While it is on, people who have your number saved and use Find friends from your contacts can see your username and send you a request; your number is never shown to them. To make this work we keep a scrambled code made from your number with a secret key that only our servers hold, together with your username and account identifier in sealed form, and the date your number was last verified. We delete them when you turn it off, when you remove or change your phone number, when you delete your Account, if your Account is suspended or banned, and twelve (12) months after your number was last verified. We never tell you who found you this way, and we do not use it for anything else.
• Messages and calls: the content of Direct Messages, Groups and calls, and the photos, videos, voice notes and files you send in them, are end-to-end encrypted (Section 9). We receive and store them only as encrypted data we cannot read.
• Community Content: posts, replies, polls, poll votes, reactions, images, videos and links you post in Communities. These are not end-to-end encrypted (Section 11).
• Community Votes: Upvotes and downvotes you cast on Community posts are recorded against your anonymous user ID. You do not need to join a Community to vote on its posts. If you upvote a post, its author is told that you did; nobody else is, and nobody is ever told who downvoted a post, including that post's own author. If you delete your account, your votes are deleted and no longer count (a vote cast from version 9.4 or earlier is relabelled as a deleted user instead). Votes on replies work differently: only members of the Community can vote on a reply, and each such vote is stored on the reply with your anonymous user ID, where other signed in users' Applications can read it.
• Stories: photos, videos, text and drawings you share as Stories, with their captions. These are not end-to-end encrypted (Section 12).
• Groups: a group's name, photo, members and admins.
• Voice Rooms: not offered in this version (Section 10.6). Talk inside your own SHFT is a call, not a Voice Room (Section 3).
• A SHFT's place: when you host a SHFT and type where it is, we store that address on our servers until the SHFT ends, then delete it. Only you and the people you let in can see it. If you make the SHFT findable, people who can find it see only a rough area (about 3 miles, shown as a neighborhood name), worked out on your Device; the exact address is shown only after they are in. To work out the rough area, your Device asks Apple's location service, the way Maps does; we never see that request. If you pick Anyone nearby, people near that area who do not know you can find the SHFT and see its rough area; they still see the exact address only after you let them in. Only accounts at least a week old that have added someone can pick Anyone nearby. Do not type your home address unless you want the people you let in to have it.
• An open SHFT's home area: if you run an open SHFT and turn on Show in Nearby, we store the area you type (a rough spot of about 3 miles, shown as a neighborhood or city name, worked out on your Device) with the open SHFT, and people who look up nights near them from everyone see the open SHFT's name, picture, member count and that area. It is removed when you clear it or the open SHFT is deleted.
• Close Friends: your Close Friends list stays on your Device. While a close friends Story is up, our servers hold who that Story is for, so only those people can open it; that is deleted when the Story expires.
• Reports, appeals and support requests: what you write when you report a user or Content, appeal a decision, send a bug report or email us. A bug report includes your account identifier and username.
• Referral codes: a sales representative's code, if you enter one (Section 20).
• Settings and preferences: for example your notification choices, privacy settings, a Story alert for a contact, a Community digest, and a Suggest me to people I may know choice. Some of these are stored on our servers so they work across sessions, and a few are on your account record, which other signed in users' Applications can read (Section 3).
• Information for legal requests: if you send us a privacy request, a legal notice or an arbitration opt out, the information you include.

3. INFORMATION CREATED WHEN YOU USE theSHFT

Our servers create and keep the following records so the Services can work:

• Account record: your internal account identifier, username, public encryption keys, account creation time, your profile photo's storage address and key, your bio, your SHFT look with its color and pose, some of your settings (whether read receipts and typing indicators are on, and who can see your Last Seen, bio and profile photo), the Communities you muted, the identifier of the Device that rings for your calls and which call encryption it supports, and fields our servers set, such as whether you have theSHFT Pro and when it ends, and whether your Account is suspended or restricted and why. Other signed in users' Applications can read this record, so a modified application could read these fields; please assume they are visible to other users.
• Age confirmation record: when you create your Account, the minimum age shown to you, the region your Device reports, the country associated with your network connection as our hosting provider reports it, and the time. This record is kept in the private part of your Account, which only you and our servers can read; your account record shows other users only that you confirmed your age and when. When signup asks your birth year, we use it only to check your age and we do not keep it: neither your birth year nor your answer about your birthday is stored on our servers or on your Device. We keep only that the check passed, the minimum age applied, how your age was confirmed and where the country came from. If the check finds you are under the minimum age, no Account is created; our servers keep only that the check was refused, and your Device keeps a note that signup was refused on it, neither with your birth year; the note makes another try on that phone refuse too, and it survives deleting and reinstalling the Application. The minimum is eighteen (18), nineteen (19) in South Korea, twenty one (21) in Indonesia and Singapore, and twenty one (21) where your region cannot be read. An Account that is locked because of the check can appeal from the lock screen. Accounts made before the birth year question are not asked again.
• Recovery key: a public key your Device computes from your Recovery Phrase, stored in the private part of your Account and in a lookup list our servers use to find your Account when you restore it. To restore, your Device signs a one-time challenge from our servers with the matching private key, which it computes from the words and never sends us. Neither record can be turned back into the words, and only our servers can read them. Accounts created before version 9.5 stored a one-way hash of the Recovery Phrase instead; when such an Account opens version 9.5 or later, the hash is replaced by the recovery key and deleted, and we keep only a keyed fingerprint of the old hash with your account identifier for one (1) year, to spot attempts to use an old copy, unless you delete your Account sooner.
• Conversation records: for each conversation, its participants (and the usernames shown for them), group details, the conversation's timer, and when the last message was sent and by whom; for each message we still store, the sender and recipient account identifiers, when it was sent, delivered and read, its type (for example text or photo), its timer and expiry, who has seen it, the usernames of its sender and recipient, the accounts that reacted to it (which emoji is end-to-end encrypted, except for a reaction sent from a version before 9.5, which is stored in readable form), and the encrypted payload. We also store the encrypted keys that let Group members read each other's messages, and short lived typing indicators if you turn typing indicators on.
• Call records: while a call is ringing or in progress, a record with the caller's and callee's account identifiers and usernames, whether it is a video call, its status and times, and the call key sealed so only the two people on the call can open it. Group call records hold the participants and sealed keys for each member.
• SHFTs and groups: a crew is now an ordinary group chat (a crew made before this version shows as a group chat, with everything kept), and where this policy says "crew" it means a group chat whose host turned on its invite link, Crew Moment or weekly plan prompt. A tonight SHFT and a crew are group conversations, and their messages, photos, videos and calls are end-to-end encrypted like any Group (Section 9). For each one our servers keep its name, its members and their usernames, its hosts and co-hosts, its kind, its start and end times, and its door: whether it is open, whether Ask me first is on, its current door codes and any code a host chose (kept until the code changes or the SHFT ends, and looked up by a one-way hash), the links its hosts made to bring people in and who brought whom, the people removed from it and its door style. If you ask to come in, the hosts see your username and photo until a host answers or the request expires: twelve (12) hours for a request at the door, until an hour after the SHFT ends for a request through a plan link, a plus one or Find, and seven (7) days for a request through a crew link; asking again starts that time again. A host's note is an end-to-end encrypted message like any other. If you delete your Account, your account identifier can stay in a crew's own records, for example as a host or co-host, a person removed from it, the person who made its link or who brought someone, until the crew is deleted.
• When a tonight SHFT ends: our servers delete it for everyone, usually within minutes of its end time: its messages, photos, videos and files, its plans and answers, its door, its codes, its address and the conversation itself (messages covered by a legal hold are kept as Section 27 describes). So that people can still report something that happened, connect with each other afterwards or keep it going as a group, we keep its name, its hosts and who was in it for forty eight (48) hours after it ends; that list keeps your account identifier for those forty eight (48) hours even if you delete your Account sooner. A crew does not end: it stays until it is deleted. Its posts are deleted seven (7) days after they are sent, and its other messages follow their timers like any Group. So a report can still name it, we keep a list of everyone who was ever in a crew (account identifiers only) until thirty (30) days after anyone last joined or left it; deleting your Account removes you from that list.
• Plans and answers: if you answer In, Maybe or Can't for a planned SHFT, we keep your answer until twenty four (24) hours after the SHFT ends. Other members can see the names of up to three (3) of the people who are in; nobody else sees your name on a Maybe or Can't, but members, and people who can find a findable SHFT, see how many people answered In or Maybe. To send the reminders for a plan, we keep which SHFT is due and when until about an hour after it starts. If you turn on a crew's weekly plan reminder, we keep that choice and your time zone offset until about eight (8) days after you turn it off. A SHFT's guest list, a repeat night and a full note keep the records Section 3 describes under Host Pro tools.
• Waves: if you wave at someone in a SHFT, we keep that you waved, which they are not told, for forty eight (48) hours after the last wave between you, even if you delete your Account sooner. If you both wave, you become contacts, and the contact is recorded as made by a wave. You can turn waves off; we keep that setting until you delete your Account.
• The Moment: when a host starts The Moment in a tonight SHFT, we keep on the SHFT who started it, its times and who joined, until the SHFT ends or the next Moment replaces it. The photos are end-to-end encrypted messages; each phone puts them together, and we never receive a combined picture. In an Open SHFT, which is not end-to-end encrypted, a host can also start The Moment: we keep who joined and each photo you take for it on our servers. Putting The Moment on Explore is not offered in this version, so nothing is posted there. You can take your photo out of it at any time, and leaving the SHFT, being removed from it or deleting your Account does the same. Photos taken for an Open SHFT's Moment are deleted promptly and all of them within 8 days. A photo that matches known child sexual abuse material is preserved and reported as Section 18.8 describes. In a tonight SHFT, if every person in The Moment's picture says yes to sharing it, their own phone keeps one small copy of it for the morning after recap (Section 4); we never receive it. If you turn on Crew Moment in a crew, we keep that choice and the crew's time zone so we can send you its notification; who was asked and who joined each day's Crew Moment is removed at the end of that day, and its photos are deleted then and never later than twenty four (24) hours after they were sent.
• Call in a tonight SHFT: while a SHFT's live audio stage is open, our servers keep who opened it, who is in it with their username and photo, who is speaking, who raised a hand (which everyone in the SHFT can see) and a number standing for each person in the call, until shortly after everyone has left it, the SHFT ends, or about six (6) hours after it opened, whichever is first; who opened it is kept on the SHFT until the SHFT ends.
• Time zone: when you start or plan a SHFT, or turn on a crew's weekly plan reminder or Crew Moment, we keep the time zone your Device reports, so times and endings are right where you are, until you delete your Account. Available (telling your people you are free tonight) is not offered in this version.
• Introductions: not offered in this version. An introduction made earlier is deleted on its own fourteen (14) day schedule.
• Your link: your link (theshft.app/u/ and your username) can carry a key. While People with my link can add me is on (it is on unless you turn it off), anyone who opens your link with its key can add you as a contact at once; without the key, they send you a request. We keep the key and that setting in the private part of your Account, and a count of how many people added you from your link each day, with no names, for about three (3) days. The contact is recorded as made through your link, and you see each one in Activity, where you can remove it. Turning the setting off, or getting a new link, retires the old key. While invite rewards are available, we also keep a keyed code of the network you last fetched your link from (never the network address itself), until you fetch it again or delete your Account (Section 20.6).
• Live Activity: if you show a tonight SHFT on your Lock Screen, Apple's token for that Live Activity and the SHFT it belongs to are kept until shortly after the SHFT ends, and no more than twelve (12) hours after your Device last registered it. A Live Activity token is a push token: it tells Apple's push service where to send an update to your Lock Screen. When we send one, Apple receives the token and the times of the SHFT (when it opens, when it ends and The Moment's time), and never a name, a message, a count or who is in it. The SHFT's name shows on your Lock Screen only if you turn on Show SHFT names on the lock screen in Settings, which is off unless you turn it on and is kept only on your phone. Every sign out, wipe and Account deletion ends your Live Activities and removes the tokens.
• Presence: whether you are online and when you were last seen, unless your Last Seen setting is Nobody (Section 13).
• Community Membership Records: when you join a Community we store your account identifier, your role in that Community and the time you joined. The join time enforces the five minute wait before a new member can post, reply or create a poll.
• Community Standing and Notifications: a per Community activity score derived from your public actions in that Community, and your Community notification entries.
• Invitation records: an invitation you create stores your account identifier and username, the group's name for a group invitation, and, once used, the account identifier and username of the person who redeemed it. An invitation can be redeemed for fourteen (14) days; the record then stays until the inviter or the person who used it deletes their Account. A short lived keyed hash of the inviter's network is kept to detect invitation abuse.
• Streaks and activity: records that two contacts have been in touch on consecutive days (the two account identifiers and times), and your in-app activity entries (for example that someone viewed your Story or reacted to your post).
• Legal acceptance record: which versions of the Terms, Privacy Policy and EULA you accepted, when, and on which screen, kept on your Device and in the private part of your Account. When you accept, our servers also write an acceptance record made of a keyed hash of your account identifier (a value computed from it with a secret key that only our servers hold), the versions you accepted, our server's time, your Device's time of the tap, the screen you accepted on and the Application's platform, version and build. We keep the acceptance record for seven (7) years after your Account is deleted, so that we can show what was agreed, and then delete it.
• Moderation and Administration Logs: Actions taken on your account or content by community moderators or theSHFT's administrator (for example a warning, a suspension, a removed post) are recorded with the actor, the target, the reason and the time. These logs exist so that every such action can be reviewed and appealed. Automatic removals and the strike counts and community bans that follow from them are recorded in that Community as well. We also keep reports about you or by you, appeals, automated flags, and our internal audit log of administrative actions. Section 18 explains these.
• Purchase records: whether you have theSHFT Pro, the product, its dates and renewal status, from Apple (or on Android, Google) through our subscription provider (Section 20).
• Night Pass records: a Night Pass is a one time purchase that makes one SHFT a Pro SHFT for everyone in it for that night. When a pass is placed on a SHFT, our servers write a ledger row for that purchase in a part of our database only our servers can read: your account identifier, the SHFT it was placed on, whether you bought it or a member gifted it, the store and the store's transaction identifier (which is the row's name), when it was bought and placed, and, if it is refunded, when. The SHFT's own record carries only that it has a pass, whether it was a gift and a short hash of the ledger key, never your purchase details, and it ends with the SHFT. Your account's private record keeps the times of passes you placed and of refunds, to apply the limits in Section 20.8. A pass you paid for but never placed stays on your Account as a spare, so the next time you buy or gift one it is used first. We receive no card number, no billing address and no name. When you delete your Account, your account identifier and the SHFT are removed from each ledger row; the row itself stays for up to four hundred (400) days so a purchase can never be spent twice.
• Host Pro tools: for a host with theSHFT Pro or the night's pass. A guest list for a SHFT (up to three hundred (300) rows) keeps, by account identifier, who you checked in and who you approved at the door; who is coming, at the door or here is worked out from the plans, requests and members we already keep, and only the host sees it. It is deleted forty eight (48) hours after the SHFT ends. A repeat night (Pro only) keeps the host's account identifier, the SHFT's name, the host's time zone offset, the time of the next night and how many nights it has made; the next SHFT is made six (6) days before its start with the same name and door, at most twelve (12) nights in a row, and only while the host still has Pro, and the row expires about forty eight (48) hours after the next night's start. A ticket look keeps its colours on the SHFT's door; a photo you pick for a ticket stays in your phone's memory and is gone when you close theSHFT or the SHFT ends. The HD recap saves The Moment (2160 pixels wide) and the recap card (1080 pixels wide) on your phone, only when you say yes; we do not receive them. When a person is refused because a Free SHFT is full, one record on our servers tells the host's door that the SHFT was full and how many times; it holds no name or identifier of the person who tried, and it is deleted about six (6) hours after the SHFT ends.
• Friend count: a record of how many friends you have (your accepted contacts, not counting people you blocked) and when it was last counted, readable by any signed in user who can open your profile, and recounted on the server whenever a friendship starts or ends. "Friends in common" is worked out on our servers when someone opens your profile and returns only a number, never names; we keep a short lived counter of how many times an Account asked, to limit abuse. Both are deleted when you delete your Account.
• People you may know: on by default; you can turn it off in Settings, Privacy and safety, Suggest me to people I may know. Our servers suggest a person only for a stated reason that is shown on the card: two or more friends in common, the same Open SHFT where the other person chose to be listed, or the same SHFT or group (never named on the card) that was active in the last thirty (30) days. We never use location, never use a phone number or email address to suggest anyone, and never suggest someone you blocked, who blocked you, who turned the setting off, or whom you hid. We keep your setting only if you turned it off, a list of the people you hid (account identifiers) and counters that limit how often you ask. They are deleted when you delete your Account. Adding someone from a card is an ordinary friend request; nothing marks it as a suggestion.
• Provider link (Apple or Google): if you use Continue with Apple or Continue with Google, we keep a link between your Account and a separate sign in record, the provider (Apple or Google) and the verified email address the provider shares (with Apple's Hide My Email, a relay address), plus a masked copy of the address in your private record. Any name or profile photo the provider shares is cleared from the record at once and never used or shown. For Apple we also keep, only on our servers, the refresh token Apple gives at sign in, to cancel your Apple sign in when you delete your Account, remove the Apple sign in, or leave signup unfinished (Section 26.4).
• App Clip and Apple Wallet pass: the theSHFT App Clip is a small part of the Application that Apple can open from a SHFT's link so you can see its card (the SHFT's name, day and time, door look and, if the host shows it, how many are going) before you install anything. It asks for no account, age, contacts, location, camera, microphone or notifications, has no keys and no tracking, joins nobody, and leaves no data behind on your phone after it closes. Its one request to our servers sends only a one way hash of the link, with no cookies; our servers keep no record of who asked beyond the short lived counters that limit abuse (Section 5). When you install theSHFT from it, the link you opened can be handed to the full Application through a small file on your phone that is read once, deleted, and expires in twenty four (24) hours. An Apple Wallet pass is an option on a SHFT's link with its ticket: a pass file made by our servers holds the SHFT's name, day and time, "Ask to join" and a code for the link, nothing about you, and has no update service; we do not keep a copy, and the pass lives in your Wallet under Apple's terms (including any iCloud sync).
• Data exports: if you use the export feature, a file with your account information that you can download through a link that works for twenty four (24) hours.
• Keep your account records: if you add an email address or phone number, the records Section 26 describes: the link between your Account and your sign in method, a masked copy of the address or number, any Account recovery and its status, if you set a password, a record that the sign in record has one and when it was set (and, for a password set on our servers, the sign in record's copy of the keyed value described in Section 26.4, never the password), the optional two step methods (an older PIN check, passkey records, an authenticator app's encrypted secret and backup code hashes), single use challenges and permissions that two step uses, any removal of a two step method that is waiting, and short lived records used to move your Account to a new phone and to limit sign in codes.
• Profile card and added photos: the card in Section 2 is kept on our servers in a record only our servers read; the profile screen shows it through a request that refuses anyone who blocked you or whom you blocked. An added photo is re-encoded on your phone, and stripped of embedded information again on our servers, to leave out location and camera details, then checked before it shows (Section 18.2); until it passes, only you see a "Waiting for review" note. You can remove or reorder photos at any time; removing one deletes it. A photo uploaded but never accepted is deleted within about a day. Everything on the card, and its photos, is deleted when you delete your Account. Photos on your card are not end to end encrypted, and a link someone was handed before they were blocked can keep working until the photo is removed.
• Devices, remote wipe and gifts: if you verify a Device or use remote wipe, a list of your Devices (an identifier, the platform and when it was added) and any remote wipe command (which Device sent it and when); and which seasonal SHFT looks you claimed as gifts and when. These are kept in the private part of your Account.

4. INFORMATION STORED ONLY ON YOUR DEVICE

The following stays on your Device and is not sent to us, except as stated:

• PIN: theSHFT no longer asks for a PIN to open and keeps none. A phone that had a PIN or a second erase PIN from an earlier version removes them the next time theSHFT opens, writes a plain marker that an Account is there in their place, and shows once the line "theSHFT no longer asks for a PIN to open." If your Account still has a PIN check as a two step method (Section 26.6), theSHFT asks for those digits only where our servers need them, and sends us only a one way value computed from them.
• Recovery Phrase and private keys: your Recovery Phrase and your private encryption keys are created on your Device and kept in its secure storage (the iPhone Keychain, marked for this device only, except as Section 26.2 explains). Keychain items stay on an iPhone when the Application is deleted; signing out or deleting your Account removes them. We only receive the recovery key, signatures and, for older Accounts, the hash described in Section 3. If you use Move to a new phone, your old phone sends your Recovery Phrase to your new phone through our servers, sealed end to end so that only the new phone can open it (Section 26.7); we cannot read it.
• Your messages: the readable text of your messages, and decrypted photos and videos while you view them, are kept on your Device in the Application's local database and caches. The text is sealed with a key kept in the Keychain; details such as times and which conversation a message belongs to are not sealed. Decrypted media is removed from the cache when you leave the Application and when a message expires.
• Face ID, Touch ID and your phone passcode: before a sensitive action (backup codes, deleting your Account, linking a device, moving to a new phone, approving a recovery, or changing how you get back in) theSHFT asks your Device to check that it is you. This is your phone's check, not a lock on the Application: opening theSHFT never asks for it. Your Device's operating system performs the check; theSHFT receives only whether it succeeded and never receives biometric data or your passcode.
• Passkey private key: if you make a passkey for theSHFT (Section 26.6), its private key is created and kept by your Device's passkey manager (iCloud Keychain on iPhone, Google Password Manager on Android, or another passkey manager you choose), and is never sent to us. Apple, Google or that manager may sync it to your other devices under their own terms and privacy policies. Using a passkey asks for your face, fingerprint or Device passcode; your Device performs that check and we receive no biometric data and no passcode.
• Authenticator app and backup codes: if you set up an authenticator app (Section 26.6), that app keeps its own copy of the secret that makes your codes, under its maker's terms, including any backup or sync it offers. Backup codes are shown once on your Device; we keep only one way hashes of them.
• Search history and settings: your recent searches, most settings, and any marks an earlier version kept to unlock some looks. Stars and achievements are not offered in this version; the screen is now Your streak.
• Keep vault: if Keep or Report and keep is on for you, copies kept on your Device in an encrypted vault (Section 19).
• Home Screen and Lock Screen widget: if you add the widget, it shows the usernames of recent senders, times and your unread count, without message text, and SHFT, whose mood your Device works out from when you last opened the Application or sent a message and from your Pet and Feed taps. None of this is sent to us.
• The Moment on your recap: when every person in The Moment's picture said yes to sharing it, your Device keeps one small copy (540 pixels wide, sealed) for the morning after recap, for at most thirty six (36) hours and for at most three (3) SHFTs. It is never sent to us, and signing out, a wipe or switching Accounts removes it. The HD recap, when you say yes to saving it, is saved on your phone and is not sent to us.
• One year ago tonight: not offered in this version. A list an earlier version kept on your Device stays sealed there, is not used and is removed when you sign out or erase the Application's data.

5. INFORMATION COLLECTED AUTOMATICALLY

• Installation identifier: a random identifier created the first time the Application is installed on a Device and kept in the Device's secure storage, so on an iPhone it stays the same if you delete and reinstall the Application. We use it to limit how many Accounts a Device can create, to apply device restrictions after a ban, and to manage push notifications and incoming calls for your Device. The identifier of the Device that rings for your calls is also on your account record, which other signed in users' Applications can read, so a modified application could tell that two Accounts were used on the same Device. It is not your device's advertising identifier and cannot be used to track you in other apps.
• Delivery counts: daily totals of the notifications our servers sent and of those that failed, with no account, token or conversation information, kept for about thirty (30) days, so we can see whether notifications are being delivered.
• Daily totals: we count totals, like how many accounts were created each day, without tracking any person. Once a day our servers count, from the records described in Section 3 and this section, how many Accounts were created the day before; of the Accounts created a week earlier, how many had added a contact, had sent a message and had opened the Application again; and of those created a month earlier, how many had opened it again. We keep only the numbers for each day, with no account, username, contact or conversation information, for about thirteen (13) months.
• First message mark: the first time your Account sends a message, our servers set a single yes or no value in the private part of your Account saying that it has. It holds no time, no count, no recipient and no content. It is used only for the daily totals above and, while invite rewards are available, so that an Account that has already sent a message is not counted as invited (Section 20.6). It is deleted with your Account.
• Push notification tokens: if you allow notifications, the tokens that let Apple (and, on Android, Google) deliver notifications to your Device, including a separate token for incoming calls on iPhone and a token for each Live Activity (Section 3). They are deleted when you sign out, when the Application is wiped, and when you delete your Account. If you turn notifications off in the Application, the tokens stay, but our servers stop sending notifications to them, except for incoming calls (Section 15.5).
• App integrity checks: Apple's App Attest or DeviceCheck services, through Google's Firebase App Check, confirm that requests come from a genuine copy of the Application. We may also use Apple's DeviceCheck to record, for a device that was used to break our rules, a flag that Apple stores for us; it lapses about a year after it was last set, and an approved appeal clears it.
• Network addresses: our hosting provider receives your IP address whenever the Application or website connects to our servers. We do not store IP addresses in our databases in readable form. To slow down password and code guessing, account restore abuse, and mass Account creation, our servers keep short lived counters keyed to a shortened hash of the network address that made the request. Because such a hash could be matched back to the address, we treat it as your IP address. The counters expire within hours to a few days.
• Server logs: Google Cloud keeps logs of our server functions and of our real time relay for about thirty (30) days under its default settings. The logs record operations and errors and can include account identifiers, conversation identifiers, a freed username at account deletion, and, for relay connections, IP addresses. We use them to run and fix the Services and to investigate abuse.
• Crash and stability reports: described in Section 17, and you can turn them off.
• Country: the country associated with your network connection when you create your Account, as described in Section 3. We do not collect GPS or other precise location. If you tap Nearby in SHFTs, the Application asks for permission to use your location while you use it, and uses it only on your Device to show nights close to you; your exact location is never sent to us or anyone else, never stored, and is dropped when you turn Nearby off. Nearby is optional; My city works without it. If you turn on Show nights near you from everyone, your Device sends us a rough area (about 20 miles across) to look up nights there. We use it only to answer that request and do not store it.

6. INFORMATION FROM OTHER SOURCES

• Apple, Google and our subscription provider: whether you bought theSHFT Pro or a Night Pass, the product, and its dates, renewal and refund status. We do not receive your name, payment card or billing details.
• Apple and Google sign in: if you use Continue with Apple or Continue with Google, the provider tells our servers that you signed in and the verified email address it shares (with Apple, possibly a relay address). We ask only for the email address, never your name or photo, and clear any name or photo the provider sends at once.
• Other users: other users may give us information about you, for example by adding you as a contact, inviting you, mentioning you, voting on or reacting to your posts, viewing your Story, or reporting you.
• Our hosting provider: the country associated with your network connection.

7. WHAT WE DO NOT COLLECT

From users of the Application, we do not ask for or collect: your real name; your birth year or birthday (signup asks the year only to check your age, and we do not keep it, Section 3); the password you type (we keep only a keyed value computed from it, Section 26.4); your email address or phone number (other than the one you add to keep your Account as Sections 26.4 and 26.4A explain, or when you email us or apply to our sales program); your postal address (if you type an address for a SHFT you host, see "A SHFT's place" in Section 3); government identification numbers; payment card or bank details; GPS or precise location; your device's address book (Find friends from your contacts checks it on your Device and sends us only scrambled codes, as described in Section 2); your device's advertising identifier; biometric data; health information; or the content of your end-to-end encrypted messages, calls and media, which we cannot read. theSHFT has no analytics software and does not track you: we do not record which features you use or measure any one person's engagement, and apart from the first message mark (Section 5) we keep no record of any one person's activity for counting. We use no analytics or advertising software, advertising networks, tracking pixels or fingerprinting. We count totals, like how many accounts were created each day, without tracking any person (the daily totals in Section 5). We do not track you across other companies' apps or websites. The only diagnostic information we receive is the crash and stability reports described in Section 17, which you can turn off, and the delivery records described in Sections 3 and 5.

This Section describes the Application. When you add an email address or phone number to keep your Account, we collect it as Sections 26.4 and 26.4A describe, and we never use it for marketing, for analytics or to track you. We never use an email address to find people. We use a phone number to let people who have it saved find you only if you turn on Let friends find me by phone number (Section 26.4). If you email us, we receive your email address. If you apply to our sales representative program, we collect the information in Section 21, which includes your name, contact details, a tax form and an identity document.

8. HOW WE USE INFORMATION

We use information only for these purposes:

• To provide the Services: deliver messages, calls, Stories and Community Content; run Communities, voting, moderation and notifications; keep your settings; process restores; and show you what the features show.
• To keep theSHFT safe: prevent and investigate spam, fraud, abuse, harassment, child exploitation and other violations of our Terms; enforce limits and bans; review reports and appeals; and protect our systems.
• To manage theSHFT Pro and Night Pass: confirm purchases, apply Pro features and a Night Pass to the SHFT it was placed on, limit refund abuse, and track referral commissions.
• To check your age: use your birth year once at signup to check that you meet the minimum age, and keep only the result (Section 3).
• To communicate with you: send the notifications you allow, show notices in the Application, and respond to your requests.
• To help you keep your Account: if you add an email address or phone number, to let you sign in on a new phone (with a code, with your password or with Apple or Google) and sign back in to your Account, to confirm that a sign in method was added, and to send the security emails listed in Section 26.4. We use it for nothing else.
• To keep the Services working: find and fix crashes and performance problems, watch whether notifications and messages are delivered, and see how many people join and keep using theSHFT from daily totals that name no one. We do not build profiles of individual users, and we use no analytics software.
• To comply with law and protect rights: respond to legal process, preserve records under legal holds, report child sexual abuse material as the law requires, enforce our agreements, and establish or defend legal claims.
• To run our sales representative program: evaluate applications, pay commissions, and keep tax records.

We do not sell your information, share it for cross-context behavioral advertising, or use it to target ads. Apart from the automated moderation described in Section 18, which can hide or remove Content and, for suspected child sexual abuse material, suspend an Account, we do not use your information to make automated decisions that have legal or similarly significant effects on you, and you can ask for a person to review an automated moderation decision by appealing it.

9. END-TO-END ENCRYPTION AND ITS LIMITS

9.1. What Is End-to-End Encrypted. Direct Messages and Groups, and the photos, videos, voice notes and files sent in them, are encrypted on your Device before they leave it, and only the Devices of the people in the conversation hold the keys. The Application uses the following:

• X3DH (Extended Triple Diffie-Hellman): to agree the first keys of a Direct Message conversation, even when the other person is offline.
• Double Ratchet: to change the keys of a Direct Message conversation as messages are exchanged, so that a compromised key exposes as little earlier or later message text as the protocol allows.
• NaCl (Curve25519, XSalsa20 and Poly1305): for authenticated encryption.
• ML-KEM-768 (post-quantum hybrid): a NIST standardized post-quantum key encapsulation mechanism mixed in with Curve25519 when a Direct Message session starts, whenever the recipient's Device has published a post-quantum key. Where it applies, an adversary must defeat both the classical and the post-quantum primitives to derive the session key, providing resistance to "harvest now, decrypt later" attacks against quantum-capable adversaries. For Groups, ML-KEM-768 protects a message key only when every member of the Group can receive it, and a key issued after a member leaves or is removed is not protected by it; Group message keys without it rely on Curve25519 alone. This protection applies to message text only. If the recipient's Device has not published a post-quantum key, the Direct Message session is classical only, and the Application does not refuse a classical session with a contact whose Device has never published one. Later ratchet steps add only classical key exchanges, so the post-quantum layer does not restore protection after a Device is compromised.
• Sender Keys: for Groups, a key per member for sending, shared with the other members in sealed envelopes.
• Media keys: photos, videos, voice notes and files are sealed with a key for the conversation rather than the ratchet. In a Direct Message that key is computed from the two people's long term identity keys, so media does not have the forward secrecy of message text, is not protected by ML-KEM-768, and can be opened by anyone who obtains either person's identity private key. Media sent before an Account's first restore can also be opened with that Account's Recovery Phrase.

9.2. What We Can and Cannot Do. In ordinary use we cannot read, decrypt, moderate or produce the content of end-to-end encrypted messages, calls or media, because the keys are on the devices of the people in the conversation and we do not have them. We can see the metadata described in Section 3, such as who is in a conversation and when messages are sent and read.

The one exception is saved chats for sign in (Section 26.1), which is optional and off unless you turn it on. When it is on, your Device saves an encrypted copy of your chat keys and of your chat history on our servers, so that your chats can come back when you sign in on a new phone. The copy is locked in the following ways, and only these ways can open it: with your password; with the backup service of your phone (iCloud Keychain on iPhone, Google backup on Android); and, after you reset your password, with a reset key that is held for us in Google Cloud Key Management Service. We do not hold your password, and the backup service keys stay with Apple or Google, so with those two we cannot open the copy. The reset key is different: because we hold it, theSHFT could technically unlock the copy of any Account that has this feature on. We use it only to give your chats back to you, and only after an email check (a code or link sent to the email address you added) and a waiting period that gives your old phone time to say no, as Section 26.5 describes. We do not use it to read your chats or for any other purpose. This is a choice you make: it trades some of the protection of keeping every key on your own devices for being able to get your chats back. You can turn the feature off at any time, and turning it off deletes the saved copy and its locks from our servers. Deleting your Account deletes them too.

Messages whose timer has ended are deleted from the saved copy as well: the history is saved in pieces, and a sweep that runs every fifteen (15) minutes deletes the pieces whose timers have ended, so a message that has ended does not come back on a new phone. A message that has not ended can come back until its timer ends.

9.3. Limits. End-to-end encryption does not protect Content on a Device that is unlocked, lost, stolen or compromised; Content a recipient copies, forwards, photographs or records; text captured by a keyboard or other software; information in an old backup of a Device; or metadata. When a Contact restores their Account, moves it to a new phone, or gets back into it with an email address or phone number (Section 26), their keys change, and the Application shows a notice when it notices the change; it cannot tell a restore from an attack, and it records a Contact's key without a notice the first time it sees it. The encryption module is published at github.com/wma1101/theshft-crypto; the rest of the Application and our servers are not open source, and no external audit has been commissioned.

9.4. Not End-to-End Encrypted. Community Content and votes, Stories (with their captions, reactions and viewer lists), which accounts reacted to messages in Direct Messages and Groups (and, for a reaction sent from a version before 9.5, which emoji), profile photos, group photos, your SHFT look, bios, usernames, your contacts list, Voice Room listings, reports, appeals, the text of a Community notification your Device fetches (Section 15), and all the records in Section 3 are not end-to-end encrypted. We can read them, and some of them are visible to other users as this policy explains.

10. CALLS AND VOICE ROOMS

10.1. Calls. Voice and video calls are end-to-end encrypted with AES-256-GCM. Between current versions of the Application the key is random for each call and is exchanged sealed under X25519; with older versions, and with devices that have not advertised the newer method (for example an Android phone), the key is derived from an X25519 exchange of the two identity keys and is the same for every call between the same two accounts. Calls do not yet have forward secrecy. Call audio and video pass through our call provider's relay servers as encrypted data that neither the provider nor we can decode.

10.2. No Recording by Us. We do not record, store or transcribe calls or Voice Rooms.

10.3. Call Records. While a call is ringing or in progress, our servers keep the record described in Section 3. A one to one call record is deleted when the call ends, and our servers delete any record left behind within minutes for a call that was never answered and within about twelve (12) hours for one that was. A group call record is deleted when the last participant leaves; if that does not happen, our servers delete it within about twenty (20) minutes after nobody is left in it, and in any case within about seven (7) hours after the call started. The call history you see is kept only on your Device.

10.4. Your Phone's Call History. theSHFT does not add your calls to your phone's own call history. They are not listed in Recents on iPhone, so iCloud does not copy them to your other devices, and they are not written to the call log on Android. Calls that an earlier version of theSHFT added to Recents stay there until you delete them in the Phone app; no app can delete them for you.

10.5. Who Can Call You. For one to one calls, our servers ring you only when the caller is one of your contacts. A group call rings every member of the Group unless the member blocked the caller or muted the Group.

10.6. Voice Rooms. Voice Rooms in Open SHFTs are not offered in this version (they are switched off), so no new Voice Room listing is made. Talk inside your own SHFT is unchanged and is described in Section 3. The rest of this Section describes how a Voice Room worked and applies if we turn them on again, and to any listing an earlier version left. A Voice Room is a live audio room in a Community. It is encrypted with a room key the host's Device creates and shares with each listener's Device. Any member of the Community who is not banned can join and listen, and people removed from a room may still hold its key, so treat a Voice Room as public to its listeners. The room's listing (its Community, channel, host and status) and the list of people in the room (their usernames and roles) are stored on our servers and readable by any signed in user while the room is live. When the host ends the room, the listing is deleted. If the host's Application disconnects instead, our servers end the room within a few minutes and remove the host's name; a record that the room existed and ended can remain. A scheduled room's host and start time are readable by any signed in user until about two (2) hours after the scheduled time.

11. COMMUNITIES

• Visibility: Community messages are visible to every signed in user of the Application, including users who have not joined the Community, inside the Community and in the app wide feed. You should not post sensitive or private information in Community channels. In each Community you choose Show me in the member list, which is off until you turn it on; when it is on, other signed in users can see you in that Community's member list. The Community's admins and moderators are always shown and can see every member, as can our administrators. Until our servers enforce this choice for every version of the Application in use, an older or modified version of the Application may be able to read a Community's full member list.
• Voting data: Each upvote or downvote you cast on a Community post is stored on our servers in its own record under your anonymous user ID, which only your own Account and our servers can read. Any signed in user may vote on any post without joining the Community. The number of upvotes (likes) is visible to anyone who can see the post; the number of downvotes is not shown to anyone, although a post with many more downvotes than upvotes is folded and then removed (see Retention). A post's author is told who upvoted it; nobody is ever told who downvoted a post. Votes on replies work differently: only members of the Community can vote on a reply, and each such vote is stored on the reply with your anonymous user ID, where other signed in users' Applications can read it.
• Author name: your username is shown on your posts unless you turn on Hide my name in open SHFTs in Settings; even then, your posts are stored with your account identifier, we know which Account posted, and a modified application could read it.
• Moderation logs: actions taken by Community moderators (for example removing a post or banning a member), with the moderator, the member, the reason and sometimes a copy of the content, are recorded in a log that members of that Community and our administrators can read.
• Retention: Community messages remain visible for as long as the community exists unless you delete your own post, a moderator removes it, or it is removed automatically because its downvotes exceed its upvotes by twenty or more. Content you delete is removed, except that content someone has reported is kept only until moderators review the report, and for no more than 90 days unless the law requires us to keep it longer. Posts removed by moderators, by the automatic rule or by theSHFT are hidden from other users but may be kept, with the removal recorded, so that the removal can be reviewed and appealed and so that strikes and bans can be applied; we do not currently delete removed posts on a schedule. When the newest post in a Community changes, a short preview of it is stored with the Community.
• Official Community: every Account is added to the official theSHFT Community when it is created. Only theSHFT posts there; members may reply and any signed in user may vote.
• Legal requests: because Community Content is not end-to-end encrypted, we may be able to produce it in response to valid legal process.

12. STORIES

• Audience: a Story is visible to your contacts, and our servers enforce that. Blocked users cannot see it.
• Not end-to-end encrypted: Story media is stored encrypted at rest with a random key kept with the Story on our servers, so we can read it and could produce it under valid legal process.
• Views and reactions: when a contact views your Story, their account identifier is added to a viewer list stored on the Story; you can see the list and viewers cannot see each other in the Application, but a modified application used by one of your contacts could read it. Reactions and poll votes are stored on the Story and appear in your activity. Replies to a Story are sent to you as end-to-end encrypted Direct Messages.
• Deletion: a Story expires twenty four (24) hours after it is posted. A job on our servers deletes expired Stories and their media every thirty (30) minutes, so a Story may remain on our servers for a short time after it expires. Viewer lists, reactions and poll votes are deleted with the Story. A contact may have captured a Story before it expired.

13. SEARCH, CONTACTS AND PRESENCE

13.1. Search. Searching your contacts, messages and groups happens on your Device. Searching Communities sends the longest word you type to our database, which returns Communities whose name or topic matches it; your Device narrows the results with the rest of your words. When you look up a username to add a contact, your Device asks our servers for that exact username; the Application looks up only an exact username, never part of one, and the number of lookups is limited. We do not keep a record of your searches (to enforce that limit we keep, for up to two days, a count of how many lookups an Account and a network made, never what was looked up), although our hosting provider's logs may show that a lookup happened. Your recent searches are kept on your Device.

13.2. Contacts. Your contacts list and the relationship records described in Section 2 are stored on our servers so that your contacts list works across restores and so our servers can enforce audience rules (for example who can see your Stories and who can call you). Our servers also keep a count of your contacts so profiles can show it. When you or a contact removes the other, the relationship record is deleted, and the one-to-one conversation is deleted as Section 25 explains.

13.3. Presence. Unless your Last Seen setting is Nobody, the Application stores whether you are online and when you were last seen in a record that any signed in user who has not been blocked by you can read, and the Application shows it according to your setting (Everyone or My Contacts). The My Contacts setting controls what the Application displays; it is not enforced by our servers, so a modified application could read your status. In addition, our real time relay may tell connected devices when an account comes online or goes offline, which a modified application could read, whatever your setting.

13.4. Blocking. When you block someone, we store that on our servers so we can stop their one-to-one messages, calls, contact requests and Story views from reaching you and hide your online status from them. We do not notify the blocked person, but the block record is readable by them, so a modified application could learn that you blocked them. The block record never says that you reported them: if an older version of the Application wrote a report reason there, our servers replace it with a plain block reason. Blocking does not remove anyone from a Group.

14. MEDIA, FILES AND LINK PREVIEWS

• Encrypted before upload: photos, videos, voice notes and files sent in Direct Messages and Groups are encrypted on your Device before they are uploaded to our storage. We cannot view them.
• Location and camera data in photos and videos: before a photo or video leaves your Device, in a chat, a Story or a Community, the Application re-encodes it, which removes embedded information such as GPS location and camera details; if that fails, it is not sent. Files you send from the Files picker are sent as they are, except that the Application removes location and camera details from JPEG and PNG files; other kinds of files (for example HEIC, PDF or office documents) may contain location or other embedded information. If that matters to you, remove it before you send.
• Community and Story media: media in Communities and Stories is not end-to-end encrypted, as Sections 11 and 12 explain.
• View once: a view once photo or video is deleted from our storage when it is opened.
• Link previews: when you send a link, your own Device fetches the page's title, description and site name and sends them inside the encrypted message; the linked site sees a request from your Device. The recipient's Device does not contact the linked site for the preview, and we never see it. In a Community post, your Device makes the preview the same way and it is stored with the post, which is not end-to-end encrypted. Link previews are on unless you turn them off in Settings.
• Saving and sharing: recipients can save photos without a timer to their photo library, forward messages and share files outside the Application, and those copies are outside our control.

15. NOTIFICATIONS

15.1. Optional. Push notifications are optional. You can turn them off in your Device settings, and choose kinds of notifications in the Application.

15.2. What Is Visible, and What Is Sent. The text of a notification our servers send for a direct or group message never includes the message. A notification for one message is generic. When new messages arrive while you have not opened the Application for a while, one notification can say how many people wrote, and, if you chose Name only or Name and action under What notifications show, their usernames (at most two). If you choose Name only or Name and action under What notifications show, a notice theSHFT shows while it is open can name the sender, and your phone may keep it in its notification list. It never includes message text, a message preview, or the body of anything you have been sent in a direct or group chat. A typical notification says only that you have a new message. Three other kinds of notification can show more:

• Community notifications: when we make it available and your setting allows it, a notification about a post in a Community you joined, a reply to you or a mention of you can show that post's text, and the Community's name as its title. That text is not end-to-end encrypted (see Section 11). It is never part of the push notification: after the notification arrives, your Device fetches the text from our servers over an encrypted connection, presenting a random key your Device created, and our servers keep only a one-way hash of that key. On iPhone, text is fetched for no more than five (5) minutes after you last left the Application, and only when your Device's notification preview setting allows it. It is not fetched for a post that was removed or hidden by moderation, reported, marked as a spoiler, or from or to someone who is blocked, or for a Community you left or muted. Text already shown stays until you clear it or open the Application, even if the post is later removed. If your Device cannot fetch the text within a few seconds, the notification shows generic text instead. You can turn this off with the switch for showing post text in Community notifications.
• Official theSHFT announcements: an official theSHFT announcement, a public post written by theSHFT for every member, shows its headline. It is never a message someone sent you. Announcements and tips from theSHFT are sent only if you turn on Tips and updates, which is off unless you turn it on.
• Incoming calls: an incoming call shows who is calling, as any phone call does: the nickname you saved for that person in the Application, or otherwise their username. On an iPhone, a call that arrives while the Application is closed can show the username even when you saved a nickname; on Android, it shows no name until you open the Application.

15.3. The Routing Payload. Separately from the visible text, every push carries a routing payload that your Device uses to open the correct screen. It is not shown on your lock screen, but it is transmitted to and can be read by our push delivery providers. It never contains message content or Community post text. For most notification types it identifies the other person, group or post by an account, group, post or conversation identifier, and message notifications include a conversation identifier which, for a one-to-one chat, is derived from the two participants' account identifiers. A mention, reaction, story, group change or contact request includes the other person's account identifier, not their username; being added to a group includes the group's identifier, not its name. We may replace these identifiers with a random reference that only your own Account can resolve; where we do, the reference and what it points to are stored in your Account for seven (7) days. An incoming call includes the caller's username and account identifier, because Apple requires a name in order to display an incoming call before the Application has started, and your device uses the identifier to show the nickname you saved instead, if you saved one.

15.4. Delivery Providers. Notifications are delivered through Expo's push notification service and Apple Push Notification service (APNs), and on Android through Google's Firebase Cloud Messaging. These services receive your device push token, the visible title and body, and the routing payload described in 15.3. An incoming call reaches an iPhone through APNs directly, not through Expo; that push carries only the call identifier, the caller's account identifier and username, whether it is a video call, and the time it was sent. A second notification about the call goes through Expo with the call's channel identifier, the caller's account identifier and whether it is a video call, but not the caller's username, and group calls ring only through Expo. A Live Activity update goes to Apple's push service directly, not through Expo, with the activity's token and the SHFT's times only (Section 3). None of these services receives the content of your messages, calls or media, or the text of Community posts (only the headline of an official theSHFT announcement, as 15.2 explains).

15.5. If You Want Less Information Sent. Turn off Push Notifications in the Application's Settings, and turn off notifications for theSHFT in your Device settings. The Application keeps working, and messages arrive when you open it. Incoming calls still ring so you can answer them: a call from one of your contacts still reaches an iPhone through Apple with the caller's username and account identifier, and a second call notification with the caller's account identifier still goes through Expo (Section 15.4). To stop calls from someone, block them or remove them as a contact; for a Group call, mute the Group.

15.6. Community Notification Keys. When this feature is available and you allow notifications, your Device creates a random key so it can fetch the text of a Community notification, and our servers store a one-way hash of that key with a random identifier (up to eight per Account), plus short lived counts of those requests, including an hourly count keyed to a hash of your account and the post's author. The key itself stays on your Device, and your Device sends it only when it fetches a notification's text. Our servers refuse a key after ten (10) days, and your Device replaces it more often. The hashes are deleted when you sign out, when the Application is wiped while it can reach our servers, and when you delete your Account; a hash left by a wipe done offline cannot be used after ten (10) days.

16. SCREEN CAPTURE PROTECTION AND SCREENSHOT NOTICES

16.1. Screen Capture Protection. Screen capture protection is always on, and there is no setting to turn it off. It covers your conversations: the Chats list, every one to one, group, SHFT and crew conversation, the photos and videos opened from a conversation (view once included), a contact's or group's shared media, message search and the messages you keep. It also covers the screens that show a secret: the recovery phrase, backup codes, device link codes and the code that moves your account to a new phone. On those screens the Application draws through a protected layer, so on iPhone and iPad a screenshot, a screen recording or AirPlay screen mirroring comes out blank, and on Android the system refuses the screenshot or records a black screen. The rest of the Application, such as your code, profiles, SHFT pages, calls and the settings screens that do not show a secret, can be captured. This applies on your Device and on the Devices of the people you message that run version 9.5 or later of the Application. A screen recording blanks the picture, not the sound, so a voice note or video played in a conversation can still be heard in a recording. The one exception: our administrator can exempt a specific account, which we do only for accounts theSHFT itself uses to make promotional recordings. Each exemption is granted and removed only by our administrator through our servers, and each change is recorded in our administrative audit log. An exempt account's account record carries a single value saying so, which the Application of any signed in user can read. Even on an exempt account's Device, every screen that shows messages or content from someone who is not exempt stays blank. An exemption never makes your messages capturable on anyone's Device.

16.2. Screenshot Notices. When you take a screenshot in a one to one or group conversation on iPhone or iPad, iOS tells the Application, and the Application writes a system event to that conversation so the other participants learn a screenshot was taken (the screenshot itself is blank, as Section 16.1 explains). That record contains your user identifier as the sender, the event type ("screenshot taken") and a server timestamp. It does not contain any message content or an image of your screen. It is stored as a message in that conversation, is written with a 30 second disappearing timer, and is removed when the conversation is deleted. A screenshot taken of a screen that can be captured, such as a profile, a SHFT's page or a call, writes no notice.

16.3. Limits. Limits we will not paper over: iOS does not tell Applications when a screen recording begins, so recordings are blanked but no notice is sent; screenshot notices are sent only from iPhone and iPad; the protection does not cover the on screen keyboard or alerts drawn by the operating system itself; it relies on how iOS and Android draw protected content, which a future system update could change; a modified copy of the Application, a jailbroken or rooted Device, or a version of theSHFT older than 9.5 may not apply it; a web version of theSHFT, if we offer one, cannot blank captures; and no software can prevent someone from photographing the screen with another device or copying out what they read.

17. CRASH AND STABILITY REPORTS

17.1. What We Use. We use Sentry (sentry.io) for crash and stability reporting. It is on by default, and you can turn it off at any time in Settings, Privacy, Advanced privacy, "Send crash reports." When it is off, no reports are sent; turning it off stops reporting at once, and when it is off at launch the reporting software is not started.

17.2. What a Report Contains. Sentry receives: (a) the type and stack trace of errors; (b) device and app context attached to every event (device model, operating system version, Application version and build, locale and time zone, and technical details such as memory, screen size and whether the Device is jailbroken or rooted); (c) session records (when a session starts and ends and whether it ended in a crash); (d) app hang events; (e) sampled performance traces of app start, screen navigation and network requests, including screen and route names, from about ten percent (10%) of sessions (all sessions in test builds); and (f) a short trail of the screens opened and requests made before an error. Each report also carries a random identifier that Sentry's software creates when the Application is installed; it is not your account identifier or username.

17.3. What Is Removed Before Sending. Before a report is sent, the Application removes touches, taps and key presses, and filters the rest: for a request the Application makes, a report keeps its method and status, and keeps only the name of the server when it is one of theSHFT's own servers; every other address, including a link someone sent, is recorded as "not recorded." Account, chat and group identifiers, database paths and call channel names in the text of a report are replaced with placeholders, and values under names that identify a person are dropped. The Application is built so that Sentry does not receive message content, call media, your contacts list or precise location. Like any server, Sentry receives the network address of the connection that sends a report; we have set it not to store that address. We do not use crash reports for advertising or to build profiles.

17.4. Older Versions. Versions of the Application before 9.5 did not apply all of these filters. If crash reports were on, which was the default, a report from one of those versions could include the text of a message you touched in a chat, the words of your Recovery Phrase if you touched them while saving or checking it, the digits you touched on a PIN keypad in the versions that had one, including a second erase PIN, the web address of a link someone sent in a conversation, and file storage paths that contain the account identifiers of both people in a one-to-one conversation. We have switched off the key those versions used to send crash reports, so Sentry no longer accepts reports from them, and we have deleted the reports it had stored from them.

17.5. Retention. Sentry keeps reports for ninety (90) days. You can ask us at support@theshft.app to delete reports sooner; because reports from current versions do not contain your username or account identifier, we may not be able to find reports that relate to you.

18. SAFETY PROMPTS, CONTENT FILTERING, REPORTS AND MODERATION

18.1. Safety Prompts on Your Device. If Safety prompts is on (it is on unless you turn it off in Settings, Safety), the Application checks text you are about to send in a Direct Message or Group, on your Device only. If it finds signs you may need help, it offers help lines; if it finds words that may hurt someone, it asks whether you still want to send them. Nothing about this check is sent to us.

18.2. Content Filtering. The Application checks the text of new messages, captions, Community posts and replies, the name and description of a new Community, the name of a new Group, and your bio, on your Device, against a short list of patterns. Text matching patterns associated with child sexual abuse material is not sent; in Direct Messages and Groups, text matching patterns associated with threats of violence or self harm shows a warning you can dismiss. The check does not examine images, video, calls, Voice Rooms or Stories, and nothing about it is sent to us. For Community posts and replies, which are not end-to-end encrypted, our servers run an automated check for text that indicates child sexual abuse material. That check reads text. Photos are checked separately, as this Section describes below. When a check matches, the post and its media are removed from view at once and preserved as Section 18.8 describes, the Account that posted it is locked pending review by a person (for a copy another member reposted, a person reviews the original author's Account first), and a record of the action is kept for review. If you think a lock is a mistake, you can appeal it from the lock screen. While an Account is locked in this way, and for up to one year, we also keep a salted hash of the signals of the phone it used, not the signals themselves and nothing that names you, only to stop a locked Account from starting over on the same phone while the review runs; a new Account made on that phone is locked in the same way and can be appealed. If the review finds the match was a mistake, that hash is deleted. Separately, when a locked Account is deleted, the identifier of its phone can be kept for up to one year so the restriction still applies, as Section 25.2 describes for the device restriction record of a banned Account. We do not and cannot scan end-to-end encrypted messages or their media on our servers. Photos in Community posts and replies, and the added photos on a profile card, are also checked against lists of known child sexual abuse material. Our servers make a hash of the photo, a numeric fingerprint that cannot be turned back into the photo, and send only that hash to Microsoft's PhotoDNA service, which compares it with its lists and answers match or no match. Microsoft does not receive the photo, your username or any identifier of your Account. An added profile card photo is checked before it can be shown to anyone, and if the check cannot be completed it is not shown. When this check is switched on, an added profile card photo is also sent to Google Cloud Vision as the photo itself, not its storage address, with nothing that names you or your Account. Vision returns a rating for adult content, violence and suggestive content, and descriptive labels such as whether a person looks like a child. A photo rated likely or very likely for adult content, violence or suggestive content is not shown and is held for a person to review, and so is a photo when the check cannot be completed or the monthly limit we set on this check has been reached. A held photo leaves a review record in our administrator queue with your Account identifier and the ratings, kept for up to 90 days; a sexual rating together with a label for a child also holds the photo in place for review and is handled as the paragraph above and Section 18.8 describe. This check is used only for added profile card photos, never for messages, calls, Stories or any end-to-end encrypted media. Explore, where people could show photos to the members of an Open SHFT, is not offered in this version, so no photo is sent to Explore and no Explore photo check runs. A photo in a Community post or reply is checked soon after it is posted. This photo check does not examine video. Before we use a service to check video, we will name it in Section 22. A match is never shown, and it is handled as the paragraph above and Section 18.8 describe. When a person reviewing a match decides it was a mistake, nothing is reported, and the preserved copy and any words taken from your content are deleted 30 days later, after a window in which the decision can be undone. The short reason the reviewer typed to explain the decision stays in our review log; it is the reviewer's own words, and reviewers are told not to copy your content into it.

18.3. AutoMod and Crowd Removal. Community administrators can set automatic rules that hide, remove or flag posts based on their text, length, links or the age of the posting Account. When a rule flags a post, we keep a record of the flag and a copy of the post for the Community's moderators. The copy is deleted when a moderator acts on the post, and the record and any remaining copy are deleted ninety (90) days after the flag. A post whose downvotes exceed its upvotes by ten (10) or more is folded, and by twenty (20) or more is removed automatically; three removals in one Community ban the author from it.

18.4. Reports. When you report a person (from a conversation, their profile, a Story or a contact request), a Community post or reply, or a Community, we receive the reason you choose, anything you write, the reported account and the item. For server-readable Content, we save a copy of the reported item (its text, any photos, videos or files in it, its author and its time) with the report so moderators can review it even if it is later deleted. For end-to-end encrypted conversations, a report does not send us the content of your messages; we act on what you write and on what we can see. We do not tell the reported person who reported them. Reporting a person from a conversation, their profile, a Story or a contact request currently also blocks them (see Section 13.4). A report sends an email to our administrator mailbox with the reason, the reported account, the Community if there is one, your description and a report number. The email does not show your username, but the report number contains your account identifier. For a child safety report, the email says only that a report is waiting. Reports still open after twenty four (24) hours are flagged to our administrator. A Community post may be hidden automatically after an urgent report or after reports from three (3) different people.

18.5. Who Reviews. Community moderators can review reports about their Community's posts, including the reason and a short preview of a post that is still up. For the most serious categories (child safety, violence, doxxing, hate, self harm and copyright), the saved copy of an item that has been deleted is shown only to theSHFT's administrator. Reports about accounts go to theSHFT's administrator. The full record of a report of suspected child sexual abuse material opens only for theSHFT's administrator; a Community's moderators may see that a post still up in their Community was reported for it, with the reason and a short preview. Each time anyone views such a report, their account and the time are recorded.

18.6. Moderation Records and Retention. Reports and moderation records are kept as follows: the saved copy of reported Content is deleted when the report is resolved (where a removal is upheld, it is kept as evidence) and at the latest when its review queue entry expires after ninety (90) days, except for suspected child sexual abuse material, which we keep for review and as the law requires; review queue entries expire after ninety (90) days, except entries about suspected child sexual abuse material; Community moderation logs are kept for three (3) years after the action each one records, and then deleted; strike counts and Community ban records are kept while the Account they name exists and are deleted with it; report records and our administrative audit log do not yet have a fixed deletion date: we keep them while they are needed for appeals, repeat violations, safety and legal claims (records of child sexual abuse material are kept as Section 24 describes), and we will add the period to this policy when we set it.

18.7. Appeals. You can appeal an account suspension or warning in the Application; theSHFT's administrator decides it within fourteen (14) days. The administrator cannot decide an appeal of an action they took personally: that appeal waits for another administrator to review it, which can take longer than fourteen (14) days. Community bans and post removals are appealed in the Application to that Community's moderators, who decide them. We keep appeals and their outcomes with the moderation record.

18.8. Child Sexual Abuse Material. We report apparent child sexual abuse material to the National Center for Missing and Exploited Children, and preserve it, as 18 U.S.C. 2258A requires. A report to that center can include the Content, the account identifier, username and other information about the Account that posted it. If you report an account or a Community for child safety, your description may be included in our report to that center; your identity is not.

19. KEEP AND REPORT AND KEEP

19.1. Status. Keep and Report and keep are built into the Application but are not available to users on the Last Updated date. This Section applies when we make them available to you.

19.2. Keep. A theSHFT Pro user can ask to keep a one-to-one conversation. Nothing is kept unless the other person accepts on their own Device. While Keep is on, both Devices show a banner, the conversation's timer is set to Off, and messages sent while Keep is on cannot be edited or deleted for everyone, even after Keep stops. Kept messages are copied into an encrypted vault on the keeper's Device. If the other person removes the keeper or deletes their Account while Keep is on, or within the closing period after it stopped, our servers hold the kept messages and their media, still encrypted, for the closing period (thirty (30) days unless we set a shorter or longer period, and never more than ninety (90) days) so the keeper's Device can finish its copy, and then delete them; everything that was not kept is deleted at once. Our servers can see that a conversation is under Keep, who keeps it, who accepted or stopped it, when Keep was requested, accepted, stopped or began closing and why, how many times it was requested in the last thirty (30) days, and a stamp on each message sent while it was on, but not the content.

19.3. Report and Keep. When you report a person in a one to one chat, you may choose to keep what that person sent you: your Device copies their messages that are still on your Device or not yet read, and that have not yet disappeared (up to five hundred (500)), into the encrypted vault on your Device, without marking them read and without telling them. View once messages are not copied; only a note of their type and time is kept. Nothing is kept for a report of child sexual abuse material. Kept photos, videos, voice notes and files can be viewed only inside the vault. We receive only a summary: how many messages, media files and view once notes were kept, a fingerprint of the kept set, and when we recorded it. To spot misuse, we note for seven (7) days whom you reported with a kept set, and a moderator reviews it if you keep sets against more than three (3) people, or more than two (2) against the same person, in that time. We do not record the summary at all until we have set how long we keep it and stated that period in this policy.

20. PURCHASES, SUBSCRIPTIONS, PROMOTIONS AND REFERRAL CODES

20.1. Purchases. Apple (or on Android, Google) processes every purchase of theSHFT Pro and of a Night Pass, and shows the price in the Application. We use RevenueCat to manage purchases: the Application gives RevenueCat your internal account identifier as its customer identifier, and RevenueCat receives purchase information from Apple or Google. We and RevenueCat receive whether you have theSHFT Pro, the product, whether it began with a free trial or an introductory offer, and its dates, renewal, cancellation, billing and refund status; for a Night Pass, that you bought it, when, and whether it was refunded. To offer a free trial or an introductory offer, the Application asks Apple, through RevenueCat, whether your Apple Account can still use one. We do not receive your name, payment card or billing address. Your theSHFT Pro status, your plan, when it ends and when it last changed are stored on your account record, which other signed in users' Applications can read.

20.2. Purchase Records After Deletion. RevenueCat and Apple keep their own records of your purchases under their own policies, and deleting your theSHFT Account does not delete them. We also keep, after your Account is deleted and linked to your former account identifier: any App Store transaction record an earlier version of the Application created (transaction identifier, platform, product and time), for accounting, refund, tax and dispute purposes; our server's log entries of each time it checked your theSHFT Pro status with RevenueCat (whether you had theSHFT Pro and when it ended); and, for thirty (30) days, the notices RevenueCat sent us about your purchases. Each Night Pass ledger row stays for up to four hundred (400) days with your account identifier and the SHFT removed (Section 3). Google keeps its own records of purchases made on Android under its own policies.

20.3. Promotion Codes. If you redeem a promotion code, we record the code, the number of days of theSHFT Pro it gives, and when it was redeemed and ends, on your Account and in a list of redemptions, which we delete when you delete your Account.

20.4. State Codes. If you enter a state code on the upgrade screen and then buy theSHFT Pro, we record the code, the state, the product, the time and your account identifier, to measure where our promotions reach people. When you delete your Account, we remove your account identifier from these records and keep the rest, which no longer identifies you.

20.5. Sales Representative Referral Codes. If you enter a sales representative's referral code, we record the code and the representative on the private part of your Account, and the Application shows you the representative's name. If you then subscribe, a commission record is created with the product, the price and commission amounts, the commission status, your account identifier, your installation identifier and the representative's name and code; the representative can see the product, the commission amount and status and the date, but not your username or account identifier. Sales representative records about you are deleted when you delete your Account, except the record of each commission (the amount, the date, and which representative earned it), which is kept for four (4) years from the date it was paid to satisfy federal tax recordkeeping requirements, with your identity removed, as described in Section 24.

20.6. Invite Rewards. When we make it available, you can earn theSHFT Pro by inviting friends. A person counts for you if their Account, while less than fourteen (14) days old and before it has sent a message, joins through your invitation or your link (never an in-person code) and then, within thirty (30) days, adds a contact of their own: someone other than you, at least seven (7) days old, whom you did not also invite. For every three (3) people who count, we add thirty (30) days of theSHFT Pro to your Account, at most three (3) such months in a calendar quarter. The person you invite gets nothing from it, and each Account counts for one inviter only. To run it we keep, in the private part of the invited person's Account, who invited them and when, and when they qualified and were counted (never whom they added), and, in the private part of your Account, how many people counted, the rewards you received and until when your reward lasts. To stop people inviting themselves, we compare the installation identifiers of the Accounts involved, and keyed codes of the networks an invitation or link was created or fetched from (Sections 3 and 24), never the network addresses themselves; we also keep totals with no account information (how many people counted and how many were turned down, and why). These records are deleted with the Account they are kept in; if the inviter deletes their Account, it is removed from the invited person's record.

20.7. Giveaways. When we run a giveaway, its official rules are posted where we announce it. Entry comes from having an account and at least one accepted contact, and we collect nothing new from people who are entered. To draw a winner we read records we already keep for the Services to work: your account identifier, when your account was created, whether it is suspended, banned or being deleted, whether it is one of our own test or staff accounts, and whether it has at least one accepted contact and when that contact was made. We save the list of eligible account identifiers and the random number used for the draw so the draw can be checked, and delete them two (2) years after the draw. We collect personal information only from the person drawn, and only after we tell them they may have won: their legal name, mailing address, a signed affidavit of eligibility and release, an IRS Form W-9 (which includes a taxpayer identification number), and, if they choose a bank transfer, the bank details needed to pay them. We may look at a government issued photo ID to confirm their name and age; we record only that we checked it and when, and we delete any image of it once the check is done. We use this information only to confirm eligibility, pay the prize and meet tax law, including filing an IRS Form 1099-MISC. We keep it in our support mailbox and prize records, apart from the Application's data: we never add it to the winner's account or link it to their messages, contacts or other app data. We keep the W-9, the 1099 and the payment record for four (4) years after the year the prize is paid, as tax law requires, and then delete them; bank details are deleted once the payment clears, and the records of a person drawn who is not verified are deleted ninety (90) days after we draw an alternate. We publish only the winner's username and, where a state's law requires it, the winner's first name, last initial and state.

20.8. Night Pass. A Night Pass is a one time purchase, not a subscription, that makes one SHFT a Pro SHFT for everyone in it for that night. Apple or Google processes the payment and shows the price in the Application. The host buys it, and any member may gift it once the SHFT is full at the Free size. When you buy or gift one, the Application asks our servers whether you may place it on that SHFT, pays through the store, and our servers then check RevenueCat's own record of your purchases (never the Application's word) and place it, as Section 3 describes under Night Pass records. It ends with the SHFT, and a crew made from the SHFT does not carry it. Because a Night Pass is used up when it is placed, there is nothing to restore; one paid for but not placed stays a spare on your Account. If the store refunds a pass, it comes off the SHFT it was on (nobody already inside is removed) and the purchase can never be placed again. To stop abuse, we limit how many times you may check or place passes in an hour, we allow at most five (5) passes placed per Account in twenty four (24) hours, and after two (2) refunded passes in ninety (90) days we stop placing new passes for the Account. For this we keep, in your Account's private record, the times of passes you placed and of refunds. A Night Pass is never part of theSHFT Pro subscription.

20.9. Host Pro Tools. With theSHFT Pro, or for a SHFT that has a Night Pass, a host can use a guest list, a ticket look and the HD recap (repeat nights need theSHFT Pro itself). Our servers decide on their side whether you may use a tool; they use the same Pro answer described in Section 20.1 and, for a pass, the SHFT's own record. The records these tools keep are described in Section 3 under Host Pro tools. They are used only to run the tool, never for marketing, and are deleted as Section 24 says.

21. THE WEBSITE, SUPPORT EMAIL AND THE SALES REPRESENTATIVE PROGRAM

21.1. The Website. Our website is hosted by Vercel, which receives visitors' IP addresses and request details in its logs. Our pages load fonts from Google Fonts, so your browser sends your IP address and the page address to Google when a page loads. Our sales representative application, upload and dashboard pages load Google's Firebase software, and the upload page uses Google reCAPTCHA through Firebase App Check, which collects device and interaction information and may set a cookie to tell people from automated programs. Two partner pages show images loaded from those partners' websites, which receive your IP address. We do not use analytics, advertising or tracking cookies on the website. The sales representative dashboard page remembers your representative code in your browser's local storage until you sign out. Pages that open an invitation, a user, a crew or a SHFT link, or a Community link pass that link to the Application. Their App Store or Google Play button adds at most a fixed word for the kind of page (for example "invite", "community", "flyer" or "giveaway") to the store link as the store's campaign code, never a username, invitation code, link key or Community identifier, so the store receives only that word if you tap the button; on our download page, a campaign name written in the link (which we use for a poster, post or advertisement) can take its place. The link itself, including any username, invitation code, link key or SHFT link code in it, is part of the page's address, so Vercel's logs receive it, and the page passes it only to the Application on your Device.

21.2. Support Email. If you email us, we receive your email address, your name if you include it, and whatever you write and attach. Our support mailbox is provided by Microsoft (Microsoft 365, through GoDaddy). We use it to respond, to keep records of legal notices and requests, and to improve the Services, and we keep support email for up to three (3) years unless it is needed longer for a legal claim or obligation.

21.3. Sales Representative Program. If you apply to be a sales representative, we collect your name, email address, phone number, home address, PayPal email address, social media handles, the reason you give for applying, and a dashboard PIN (which we store only as a hash). We do not store the IP address an application came from; to limit abuse, a short lived counter is keyed to a shortened hash of it. If we approve you, we collect a signed representative agreement, an IRS Form W-9 (which includes your taxpayer identification number) and an image of your government issued identity document, and we record the commissions you earn and the payments we make. We use this to evaluate applications, verify identity, prevent fraud, pay commissions and meet tax obligations. We store it with Google Firebase, and we send application and account emails through Google's email service. Application details, including your phone number, address and PayPal address, are emailed to our administrator mailbox. We keep these records as follows: images of identity documents are deleted thirty (30) days after we decide your application; Form W-9 information is kept for four (4) years after the last payment we make to you (or after we approve you, if we never pay you), as tax law requires, and then deleted; the records of an application we reject are deleted one (1) year after we reject it; and the records of an approved representative (the agreement, commission and payment records and contact details) are kept while you are a representative and then for as long as tax and accounting law requires. You can ask us to delete your application at support@theshft.app, subject to records the law requires us to keep.

21.4. Using theSHFT in a Web Browser. If you link a web browser to your Account at app.theshft.app, the following applies in addition to the rest of this Privacy Policy.

(a) Storage in your browser. The browser keeps the keys it needs to send and read your messages in its own storage on that computer. theSHFT for web has no PIN or lock, and a browser cannot check that it is you, so a sensitive action asks you to confirm it and each action's server checks still run. Each stored value is sealed with an encryption key that the browser creates and does not allow any website to export. The messages the browser shows are held in that browser while you use it. Anyone who can use that browser profile, and any program or browser extension that can run code inside it, may be able to see what the browser shows.

(b) Removing a browser. You can remove a linked browser from your phone at any time, in Settings, Linked devices. The browser is signed out of your Account and can no longer read your messages; it may still show generic notifications until you turn off notifications for app.theshft.app in that browser. While a browser is linked, our servers keep its record in your Account: its public keys, the name shown for it and when it was linked and expires. A linked browser also stops working 30 days after it was linked unless you link it again. Deleting your Account removes every linked browser.

(c) Hosting. The web version is served by Google Firebase Hosting, which receives your IP address, your browser's details and the addresses it requests, in its logs.

(d) Abuse protection. The web version uses Google reCAPTCHA Enterprise, through Firebase App Check, to tell real browsers from automated abuse. reCAPTCHA collects hardware and software information, such as device and browser data, and sends it to Google for analysis. Its use is subject to Google's Privacy Policy and Terms of Service.

(e) Notifications in a browser. If you allow notifications in your browser, your browser's push service (for example Google for Chrome, Apple for Safari, or Mozilla for Firefox) receives a push token for that browser and each notification we send to it, which we send through Google's Firebase Cloud Messaging. We keep the token with your Account until it stops working or you delete your Account. Notifications about direct and group messages never contain the message's content.

(f) What other people see. People you talk to are told that you also use theSHFT on the web, where screenshots cannot be blocked, and any signed in user who has not been blocked by you can read that your Account has a linked browser.

(g) Limits in a browser. In a browser, screen capture protection does not exist, the post-quantum step of the encryption runs in JavaScript rather than the phone's native code, using an open-source library (@noble/post-quantum) that has had no independent security review yet, and the browser does not check our server's certificate the way the phone does. Use the phone for anything you would not want shown on a computer screen.

22. SERVICE PROVIDERS AND OTHER THIRD PARTIES

We use the following providers. Each receives only what it needs to provide its service to us, under its own terms and privacy policy.

• Google (Firebase and Google Cloud): hosts our databases, file storage, server functions and real time message relay in the United States, and provides sign in, app integrity checks and logging. It stores all the server records described in this policy. Through Firebase Authentication it also stores an email address or phone number you add to keep your Account, with its sign in method and, for an email address with a password, a value computed from the password (a keyed value our servers compute for a password set in theSHFT, or Firebase's own hash for one set the older way), never the password itself, and it sends the email verification, password reset and text message sign in codes described in Section 26.4. If you use Continue with Google, Google confirms your sign in under its own terms and tells us your verified email address. On Android, Google Play also processes purchases (Section 20). On Android, if you make a passkey for theSHFT, Google Password Manager (or another passkey manager you chose) creates and keeps its private key and may sync it to your other devices under Google's own terms; we never receive it (Section 26.6).
• Apple: distributes the Application, processes purchases, delivers push notifications (including incoming calls directly), provides App Attest and DeviceCheck, the Keychain, and Face ID and Touch ID on your Device. If you use Continue with Apple, Apple confirms your sign in under its own terms and, if you chose Hide My Email, forwards our emails to you from a relay address; our servers keep Apple's refresh token for your sign in only to tell Apple to cancel it when you delete your Account, remove the Apple sign in or leave signup unfinished, and then delete it. Apple also makes the Apple Wallet pass you add to your Wallet, and Apple's push service delivers Live Activity updates, with the SHFT's times only (Section 3). Apple's App Clip service opens the App Clip. On iPhone, if you make a passkey for theSHFT, iCloud Keychain (or another passkey manager you chose) creates and keeps its private key and may sync it to your other Apple devices under Apple's own terms; we never receive it (Section 26.6).
• Expo: relays push notifications to Apple and, on Android, to Google's Firebase Cloud Messaging, and receives your push token, the visible notification text and the routing payload (Section 15).
• RevenueCat: manages subscription and Night Pass purchase status and receives your account identifier and purchase information from Apple or Google (Section 20). It does not receive your name, payment card or billing details.
• Agora: relays the encrypted audio and video of calls and Voice Rooms, and receives a channel name, a numeric identifier for the call, your IP address and the encrypted media, which it cannot decrypt.
• Sentry: receives crash and stability reports if you leave them on (Section 17).
• Google email (Gmail): sends email to sales representatives and applicants, and our administrator notices (Section 21), and, while the Microsoft sender below is not set up, the account emails described in Section 26.4.
• Microsoft (Microsoft 365, through GoDaddy): hosts our support and administrator mailbox, which receives support email, report notices and sales representative applications (Sections 18.4 and 21). Through Microsoft Graph it also sends the account emails described in Section 26.4 from an address on our domain; we send them without keeping a copy in our mailbox.
• Microsoft (PhotoDNA Cloud Service): receives a hash, a numeric fingerprint that cannot be turned back into the photo, of photos in Community posts and replies and of added profile card photos, and answers whether it matches a list of known child sexual abuse material (Section 18.2). It does not receive the photo or any identifier of your Account. Under its own terms, Microsoft may send the National Center for Missing and Exploited Children aggregate reports of matches that name theSHFT.
• Google (Cloud Vision): receives each added profile card photo, when this check is switched on, and answers with a rating for adult content, violence and suggestive content (Section 18.2). It is not used for messages, Stories, calls or any end-to-end encrypted media. Our servers also keep a monthly count of photos checked, with no names.
• Vercel and Google Fonts: host our website and serve its fonts (Section 21).

We use no analytics or advertising provider.

23. WHEN WE SHARE INFORMATION

We do not sell your information or share it for cross-context behavioral advertising. We share information only:

• With other users, as the Services work: for example your username, bio, profile photo (per your setting), public keys, presence (per Section 13), your SHFT look, pose and avatar color, whether you have theSHFT Pro, Community posts, vote totals (your upvote on a post is shown to the post's author only, and votes on replies are stored on the reply), Stories with your contacts, and the other items this policy describes as visible.
• With our service providers: as Section 22 describes.
• For legal reasons: in response to valid legal process, to comply with the law (including reports to the National Center for Missing and Exploited Children), to enforce our Terms, or to protect the rights, property or safety of any person, as Section 27 describes.
• In a business transfer: if theSHFT LLC is involved in a merger, acquisition, financing, reorganization, bankruptcy or sale of assets, information may be transferred to the successor, which must honor this policy for information it receives. We will tell you in the Application before your information becomes subject to a different privacy policy.
• With your direction: when you choose to share something, for example by forwarding a message or exporting your data.
• In aggregate: counts that do not identify anyone, such as the number of accounts.

24. HOW LONG WE KEEP INFORMATION

• End-to-end encrypted messages on our servers: until read and the timer runs out (in a group, until every member has read it and the timer runs out); a timed message not opened (in a group, not opened by every member) is deleted three (3) days after it was sent, or three (3) days plus the timer for a seven (7) or thirty (30) day timer, and a group message is deleted then even if its timer is still running; a message with the timer off, until the sender deletes it for everyone, the conversation is deleted, or one (1) year after it was sent, when our servers delete any conversation message that has had no expiry.
• Messages on your Device: until their timer runs out, you delete them, the conversation is deleted (including by the other person, Section 25), or theSHFT's data on your Device is erased.
• Account record, contacts list, settings and private records: until you delete your Account.
• Community Messages: Stored on our servers for as long as the community exists. You can delete posts and replies you authored; deleting a post also removes the replies under it, and a copy of anything someone has reported is kept for moderators only until the report is reviewed. Community moderators and theSHFT's administrator can remove content that breaks the rules, and a post is removed automatically when its downvotes exceed its upvotes by twenty or more. Removed posts are kept hidden as Section 11 explains, and your posts stay, relabelled to a deleted user, after you delete your Account.
• Community Votes: a vote on a post is kept in a record only the voter's Account and our servers can read until the voter changes or withdraws it or deletes their account, when the record is deleted and the vote leaves the post's count; it may remain after the post itself is deleted. A vote on a reply or in a poll, and a vote cast from version 9.4 or earlier, stays counted under a deleted user marker when the voter deletes their account.
• Stories: twenty four (24) hours, deleted by a job every thirty (30) minutes.
• Call Data: Not recorded or stored. No call logs are maintained on our servers; the call history you see is kept only on your device. A small signaling record (who is calling whom, and whether the call is ringing, answered or ended) exists on our servers while a call is being set up or in progress and is deleted when the call ends; a one to one record left behind is deleted within about twelve (12) hours, and a group call record left behind within about seven (7) hours after the call started. theSHFT does not add your calls to your phone's own call history (Section 10.4).
• Voice Room listings (not offered in this version; this applies to any left by an earlier version): until the host ends the room; if the host's Application stops responding, our servers end the room within a few minutes and remove the host from the listing, and a record that the room existed and ended can remain. Scheduled Voice Room announcements: until about two (2) hours after the scheduled time.
• Presence: replaced as you come and go; deleted with your Account.
• Contact removal signals: thirty (30) days. Removal records on your Account: until you delete your Account, except that a record naming an account that was deleted expires thirty one (31) days after that deletion.
• Invitation records: until the inviter, or the person who redeemed the invitation, deletes their Account (redeemable for fourteen (14) days). The keyed hash of the inviter's network: until the invitation is used or revoked, and at most one (1) day after it expires.
• Streak records: until either person deletes their Account.
• SHFTs and crews: a tonight SHFT, with its messages, media, door, codes, plans and address, until it ends (usually deleted within minutes of its end time); who was in it, its hosts and its name, forty eight (48) hours after it ends; answers to a plan, twenty four (24) hours after the SHFT ends; requests to come in, until answered or expired (twelve (12) hours at the door, an hour after the SHFT ends through a plan link, a plus one or Find, seven (7) days through a crew link); waves, forty eight (48) hours after the last wave; who joined The Moment, until the SHFT ends; Crew Moment, until the end of that day; the live audio stage, until everyone leaves and at most about six (6) hours; a crew's weekly plan reminder, until about eight (8) days after you turn it off; your time zone, until you delete your Account; an introduction made by an earlier version, fourteen (14) days; a Live Activity token, until shortly after the SHFT ends and at most twelve (12) hours after your Device last registered it; a guest list and a repeat night, forty eight (48) hours after the SHFT ends or the next night starts; the full note, about six (6) hours after the SHFT ends. A crew stays until it is deleted, its posts for seven (7) days, and the list of everyone who was in it until thirty (30) days after anyone last joined or left.
• Your link: the key and setting until you change them or delete your Account; the daily count of adds, about three (3) days; the network code, until you fetch your link again or delete your Account.
• Invite rewards: until you delete your Account (Section 20.6).
• Delivery counts: about thirty (30) days.
• Daily totals: about thirteen (13) months.
• First message mark: until you delete your Account.
• Acceptance records: the record on your Device and in your Account until your Account is deleted; the server acceptance record (Section 3) for seven (7) years after your Account is deleted.
• Push routing references: seven (7) days, when used.
• Community notification entries: seven (7) or thirty (30) days.
• Rate limit counters: from hours to a few days, except the login and username check counters for your Account, which are kept until you delete your Account. Restore attempt records, and the PIN attempt records of earlier versions: up to fourteen (14) days.
• Device restriction after a ban: three hundred sixty five (365) days; a DeviceCheck flag stored by Apple, if we set one, lapses about a year after it was last set and is cleared if an appeal of the ban is granted.
• Recovery key records: the public key made from your Recovery Phrase, linked to your account identifier, until you delete your Account; a one time restore challenge, two (2) minutes or until used. Retired Recovery Phrase records: a keyed record of a Recovery Phrase hash our servers stopped keeping, linked to your account identifier, one (1) year, or until you delete your Account if sooner. Recovery counts: daily totals of restore attempts, with no account information, four hundred (400) days.
• Keep your account (Section 26): an email address or phone number you added, its sign in record at Firebase Authentication (with any password hash), the link to your Account and the masked copy, until you remove it, replace it with another, or delete your Account, and then they are deleted; an Account recovery record, until the recovery ends and at most thirty (30) days after it started; the two step PIN check, until you remove it, turn two step off or delete your Account; each passkey record and its lookup entry, until you remove that passkey, turn two step off or delete your Account; the encrypted authenticator app secret with its last used time step, until you remove it, turn two step off or delete your Account, and a secret you started setting up but did not confirm, until you set one up again, remove it, turn two step off or delete your Account (it stops working after ten (10) minutes); backup code hashes and which codes were used, until you make new codes (which replaces them at once), turn two step off or delete your Account; a passkey challenge and a single use permission to make one change, until used, and each stops working after five (5) minutes and is then deleted automatically, usually within a day; a removal of a two step method that is waiting, until it finishes after seven (7) days or is cancelled; the random passkey user handle for your Account, the day and count of wrong two step answers on your phone (only the current day counts), the count of wrong two step answers across recoveries (reset when you set your PIN check again) and the end of any pause after too many (a pause lasts twenty four (24) hours), until you delete your Account; the counters that limit two step answers, checks of your PIN on your phone, new two step methods, new backup codes and password reset notices, two (2) days; the seven (7) day hold after a recovery, until it ends; a phone move, until the new phone collects it and at most ten (10) minutes; the counters that limit text message sign in codes, two (2) days; monthly totals of sign in codes and their estimated cost, and daily counts of sign in methods added and recoveries started, finished and cancelled, with no account, address or number, four hundred (400) days; the keyed value computed from a password and the record of when it was set, until you remove or replace the email sign in or delete your Account; the counters of wrong password tries, kept under a keyed hash of the address and never the address, two (2) days; the one time proof a right password or a code gives for a new phone's next step, ten (10) minutes; the Apple refresh token, until you delete your Account, remove the Apple sign in or an unfinished signup passes a day, when it is revoked and deleted (a revoke that fails is tried again daily, up to thirty (30) times); and the proof an Apple or Google signup holds before its Account is linked, at most thirty (30) minutes of use and deleted by the link or within two (2) days.
• Bug reports: kept until we delete them; your account identifier and username are removed when you delete your Account.
• Reports, moderation logs, strike and ban records, appeals and the audit log: see Section 18.6. Community moderation logs are deleted three (3) years after the action they record. Strike counts and Community ban records are deleted with the Account they name. Account appeals are deleted with your Account.
• Review queue entries and automated flags: ninety (90) days, except entries about suspected child sexual abuse material.
• Child Safety Reports (NCMEC): When we report apparent, planned, or imminent child sexual abuse material, or the apparent enticement or sex trafficking of a minor, to the National Center for Missing & Exploited Children's CyberTipline under 18 U.S.C. § 2258A, we preserve the reported content and the reported account's identifying information for one (1) year from the date the report is submitted, as federal law requires. We do not keep this material longer than the statute requires, except under a time-limited legal hold tied to a specific law enforcement request, court order, or similar legal process. A report reviewed and found not to involve child safety is closed, and its record is kept until ninety (90) days after the report was made, or thirty one (31) days after it was closed if that is later, to support an appeal of any resulting account action, then deleted. If you delete your account after filing such a report, your identity as the reporter is removed from the record (its reference number keeps your former account identifier, which is no longer linked to a username in our systems); the reported content and the reported account's information are kept for the periods above.
• Crash reports: ninety (90) days at Sentry.
• Server logs: about thirty (30) days at Google Cloud.
• Data export files: until you delete your Account, unless deleted sooner.
• Purchase records: as Section 20 explains.
• Night Pass: the pass on a SHFT, until the SHFT ends; the ledger row, up to four hundred (400) days after the purchase, with your account identifier and the SHFT removed when you delete your Account; the pending placement record, about an hour; the times of passes placed and refunds, in your Account's private record, until you delete your Account (Section 20.8).
• Host Pro tools: a guest list, forty eight (48) hours after the SHFT ends; a repeat night, until it expires about forty eight (48) hours after the next night's start or you turn it off; the full note, about six (6) hours after the SHFT ends (Section 3).
• Friend count, People you may know and the profile card: until you delete your Account, or sooner where you change or remove them yourself: a hidden suggestion stays hidden until then; an added profile photo until you remove it, a photo never accepted within about a day, and a photo held for review until a person decides.
• Birth year: not kept. The age check result (Section 3) stays until you delete your Account; a note on a phone that was refused stays on that phone and does not expire.
• Profile photos: your profile photo and its key stay on your account record until you change or remove them or delete your Account, when your photo files are deleted from our storage (Section 25.1); added profile card photos as above. We have not set a shorter fixed period for a profile photo you left in place.
• Test data: our separate test environment, which is not the live Services, can hold a sign in code for one reserved test address that cannot receive email, for fifteen (15) minutes. The live Services never write such a record.
• Giveaways: the list of eligible account identifiers and the draw's random number, two (2) years after the draw; the winner's W-9, 1099 and payment record, four (4) years after the year the prize is paid; bank details, until the payment clears; records of a person drawn who is not verified, ninety (90) days after an alternate is drawn (Section 20.7).
• Sales Representative Commission Records: If you make a purchase through a sales representative's referral code, the record of that commission (the amount, the date, and which representative earned it) is kept for four (4) years from the date it was paid, to satisfy federal tax recordkeeping requirements, even if you later delete your account. If you delete your account, your identity is removed from that record; it is kept only to show that a representative was paid, how much, and when.
• Support email: up to three (3) years.
• Sales representative records: as Section 21 explains.
• Legal holds: records covered by a legal hold are kept for as long as the hold requires (Section 27).

Where this policy says a record has no fixed deletion date yet (report records and our administrative audit log), we keep it only while it is needed for the purpose we collected it for, and we will update this policy with the period once we set it.

25. DELETING DATA, YOUR ACCOUNT AND THE OTHER PERSON'S COPY

25.1. Deleting Your Account. You can delete your Account at any time in Settings, Account Actions, Delete Account. Your sign in is removed at once and you cannot sign back in. Then:

• Your Account, your one-to-one conversations and their messages, your contacts and relationship records, your Stories, your encryption keys, your push tokens, your presence, your invitations, your streaks, your exports, your account appeals, your promotion redemptions, your profile card and its photos, your friend count, your People you may know setting and hides, your password's keyed value and your Apple or Google link, and your other private data are deleted from our servers. For accounts with a lot of content, part of this finishes over the following hours through a scheduled job.
• The second erase PIN and the Panic Wipe of earlier versions are not offered in this version. In earlier versions that had them, entering the second PIN erased the data on the device and deleted the account on our servers in the same way, without a confirmation step, when the device could reach our servers; if it could not, the device's data was still erased, but the account stayed until it was deleted later, and notifications and incoming calls for it could still reach the device until then.
• Your contributions to public conversations (posts and replies you authored in communities, votes on replies and in polls, and reactions on community posts and Stories) are relabelled to "deleted user" rather than removed entirely, and your votes on community posts are deleted and leave the posts' counts. Posts and replies keep their text, but the author is shown as a deleted user, so that other users' content and reply chains are not changed; photos and other media you attached are deleted, or kept hidden for moderators while a report about them is open. The deleted user marker on votes, reactions and reports keeps your former internal account identifier, which is no longer linked to a username in our systems, so these records are pseudonymous, not anonymous.
• In group chats, the messages you sent stay with the other members as they received them. We remove your name from our servers' copies, but members whose phones already hold those messages keep seeing your username on them. Your read receipts, your reactions, your mutes and every notice that named you are removed, and group ownership passes to another member. Those messages leave the other members' devices when their timers end or the members delete them.
• Any email address or phone number you added to keep your Account, its sign in record at Firebase Authentication, the link to your Account, the masked copy, any Account recovery and every two step method (the PIN check, each passkey record and its lookup entry, the authenticator app's encrypted secret and the backup code hashes), with the challenges, permissions and any waiting removal that go with them, are deleted. A passkey stays in your passkey manager until you delete it there, but it no longer works for theSHFT. If you used Continue with Apple, we tell Apple to cancel the Apple sign in for theSHFT (revoke the token we kept) when you delete your Account, and we retry daily if Apple cannot be reached. If you added an email address and you delete your Account in Settings, we send one last email to that address saying your Account was deleted. A remote wipe sends no email (nor did the second erase PIN or Panic Wipe of earlier versions), so that the email cannot tip off someone forcing the wipe.
• Your username is released and may be claimed by another user.
• All theSHFT data on your device is erased.
• This action is PERMANENT and IRREVERSIBLE.

25.2. What Stays After Deletion. Some records can stay after you delete your Account, for as long as Section 24 describes. They can include: records the law requires us to keep (for example records of reports of child sexual abuse material, tax and accounting records, and records under a legal hold); the server acceptance record of the versions of our terms you accepted (Section 3), for seven (7) years; reports naming your former Account, Community moderation logs (for three (3) years after the action each records), review queue entries about suspected child sexual abuse material, our administrative audit log (which has no fixed deletion date yet), a device restriction record if your Account was banned, App Store transaction records, Night Pass ledger rows with your identity removed (Section 3), Pro status check log entries and state code records without your account identifier (Section 20), records held under a legal hold, a record of the deletion kept for up to thirty (30) days if our deletion job cannot finish (which can include your username, contacts list and installation identifier while the step that needs each is unfinished, for us to complete the deletion), a removal record holding your former account identifier in each former contact's account for thirty one (31) days, contact removal signals for thirty (30) days, bug reports with your identity removed, and our server logs until they expire. RevenueCat, Apple, Sentry and our other providers keep their own records under their policies; for example, Microsoft and Google keep their own delivery records of the account emails and sign in codes they sent for us, and your own mailbox and phone keep the emails and texts you received.

25.3. Deleting Your Account Does Not Cancel theSHFT Pro. Cancel your subscription in your Apple account settings; deleting your Account does not stop App Store billing.

25.4. When a Contact Removes You, or You Remove a Contact. When you remove a contact, or a contact removes you, the conversation between you is deleted from our servers and from both of your devices, including every message either of you sent in it. The other person's device deletes its copy the next time theSHFT runs on that device and connects to our service. This cannot be undone, and adding each other again does not bring the conversation back. We cannot delete anything either of you copied outside theSHFT, such as a screenshot or a photo of the screen.

25.5. When You Delete Your Account, the Other Person's Copy. When you delete your account, your one to one conversations are deleted from our servers, and each of your contacts' devices deletes its copy of its conversation with you, including the messages you sent and the messages you received, the next time theSHFT runs on that device and connects to our service. A device that does not open theSHFT again keeps its encrypted copy until it does or until theSHFT is removed from it. Messages you sent in group conversations remain on the other members' devices until their disappearing message timers end or the members delete them (a message sent with the timer off stays until it is deleted), as when you leave a group. We cannot delete anything another person copied outside theSHFT, such as a screenshot or a photo of their screen. Community messages you posted will remain as described in Section 11.

25.6. Keep. This applies only when Keep is available (Section 19). If you delete your account while the other person in a conversation is keeping it with the Keep feature, or stopped keeping it within the closing period, the encrypted messages that were kept in that conversation, and the media they refer to, stay on our servers only for the closing period, which is thirty (30) days unless we set a shorter or longer period, and never more than ninety (90) days, so that the other person's device can finish saving its copy. We cannot read these messages. At the end of that period, or sooner if the other person finishes saving or deletes their own account, they are permanently deleted. Messages in that conversation that were not kept are deleted when your account is deleted. A Legal Hold, as described in Section 27.2, may extend this period. The same closing period applies when the other person removes the keeper as a contact while the conversation is kept; if the keeper removes the other person, nothing is held on our servers.

25.7. Other Deletion Tools. You can delete a message for everyone within one (1) hour of sending it, delete your own Community posts and replies, delete a Story, leave a Group, turn off features that store preferences, and sign out to erase theSHFT's data on your Device.

26. BACKUPS, KEEPING YOUR ACCOUNT AND MOVING TO A NEW PHONE

26.1. Saved Chats for Sign In (Optional). Unless you turn on saved chats for sign in, we do not keep a copy of your messages, and Move to a new phone (Section 26.7) and getting back in with an email address or phone number (Section 26.5) bring back your Account, not your messages. If you turn it on, your Device saves two things on our servers: a locked copy of the keys it needs to open your chats, and an encrypted copy of your chat history, in pieces. Both are encrypted on your Device before they leave it. The keys are locked with your password and with the backup service of your phone (iCloud Keychain on iPhone, Google backup on Android), and a reset key held for us in Google Cloud Key Management Service holds one more lock, which is used only after you reset your password. When you sign in on a new phone, the copy is opened with your password or your phone's backup service, your chats come back, and you may be asked for your second step if you turned on two step (Section 26.6). If you reset your password, the reset key can open the copy only after the email check and the waiting period in Section 26.5, and your old phone can still say no during the wait. Because we hold the reset key, theSHFT could technically open the copy of an Account that has this on; we use it only to give you back your own chats after that check and wait. We cannot open the copy any other way. Messages whose timer has ended are deleted from the saved copy, and a message that has ended does not come back. If the saved copy is full, older chats stay only on your phone. Turning the feature off, or deleting your Account, deletes the saved copy and its locks. Our hosting provider may keep recovery copies of our database and files for up to fourteen (14) days after a change or deletion, as part of its service; these hold end-to-end encrypted messages and media only in encrypted form.

26.2. Your Device's Backups. On iPhone, the Application leaves its message database, local storage and files out of any iCloud or computer backup made after a version of the Application that does so (version 9.5 or later) has been opened on that iPhone. A backup made before then keeps its copy until that backup is replaced or deleted. Items the Application stores in the iPhone Keychain, which it marks for this device only and which can include your Recovery Phrase and keys, can be included in a backup of your iPhone and restored to the same iPhone; a few such items written by installations older than May 19, 2026, which can include your Recovery Phrase, may be restorable to another iPhone. On Android, backups of the Application's data are turned off.

26.3. The Retired Chat Backup. Versions before 9.5 offered an encrypted backup of chats. It has been retired, and the first time version 9.5 or later is opened on your Device it deletes any backup an earlier version made there.

26.4. Keep Your Account: Your Email Address or Phone Number. An email address or a phone number is required to have an Account (Section 26.4A); this Section describes what we keep when you add one. Continue with Apple, Continue with Google, a password and phone numbers are offered only on versions of the Application that include them, and phone numbers only in the countries we allow (at first the United States and Canada).

• What it is: when you create an Account, and in Settings, Keep your account, you add a way to sign in and to get back into your Account if you lose your phone: an email address confirmed with a six (6) digit code we email to it, an email address with a password (eight (8) to one hundred twenty eight (128) characters; an older email and password sign in set up before may have needed ten (10)), Continue with Apple, Continue with Google, or a phone number. An Account can have one of the email kind (an email address, Apple or Google) and one phone number. Adding, replacing or removing one asks your phone to check that it is you (Face ID or your phone passcode, Section 4), except the first one you add right after creating your Account. You can replace the last email address or phone number on your Account but not remove it. Your Recovery Phrase keeps working as before.
• What we keep and where: the email address or phone number is stored once, on a separate sign in record at Google's Firebase Authentication, with the sign in method (email and password, Apple, Google or phone), whether the email address was confirmed and, for an email address with a password, a value computed from the password. For a password you set in theSHFT, our servers set that value themselves: it is computed with a secret key that only our servers hold (so a guess made straight at Firebase tells nobody anything), bound to the sign in record, and never the password you typed. Your typed password crosses an encrypted connection to our servers once, is checked against our rules (length, and not a common or guessable password; the check uses no outside service) and is dropped; it is never stored, never logged and never on your phone. For a password set the older way, Firebase keeps its own hash. We cannot read either one. With Continue with Apple or Google, the record holds the email address your Apple or Google account shares with us (with Apple's Hide My Email, a relay address, which we support); we ask only for the email address, and any name or profile photo that Google or Apple share at sign in is cleared from the record at once and never used or shown. This sign in record is not your Account: it cannot read your messages, your contacts or anything else in your Account, and the only thing it can do is ask our servers to start an Account recovery (Section 26.5). Our database keeps the link between the sign in record and your Account, the method and when you added it, and a masked copy of the address or number (for example w•••@gmail.com or •••• 0246) so that Settings can show you which one you added. Our servers read the full address from Firebase Authentication only when they send you an email.
• What we use it for: only (1) to let you sign back in to your Account on a new phone (Section 26.5); (2) to confirm that a sign in method was added; (3) to send security emails: a sign in method was added or removed, your email address was changed (sent to the old address), someone started signing in to your Account on a new phone (with a link to cancel it), a sign in was cancelled, you were signed in on a new phone, your Account was restored with your Recovery Phrase or moved on a new phone, someone tried a Recovery Phrase that stopped working when a recovery replaced it, a two step method was added or removed, a seven (7) day removal of a two step method started or was cancelled, someone asked from the Application to reset the password for your email sign in, a password was set or reset on your Account, and your Account was deleted after you deleted it in Settings; (4) the email verification and password reset emails and the text message sign in codes that Firebase sends; (5) a notice the law requires us to send, such as a security incident notice (Section 28.3); and (6) for a phone number, only if you turn on Let friends find me by phone number, to let people who have your number saved find you, as described below. Our emails do not include your messages or the names of your chats, contacts or SHFTs; the only detail of your Account in them is your username. Every one of them says that theSHFT never asks for your PIN or Recovery Phrase by email. We send no security notices by text message, because a text could reach someone who has taken over your number; security notices go to your email address, if you added one, and to your phone as a push notification and an alert in the Application. We never send email or text messages of our own to a phone number you add; Google sends only the sign in codes.
• Being found by your phone number, only if you turn it on: if you added and verified a phone number, you can turn on Let friends find me by phone number, when we make it available to you. It is off unless you turn it on, and you can turn it off at any time. While it is on, people who have your number saved and use Find friends from your contacts can see your username and send you a request; your number itself is never shown to them. Section 2 describes Find friends from your contacts and Let friends find me by phone number, and what each one keeps. An email address is never used to find you.
• What we never do with it: we never show your email address or phone number to other users, never use your email address to find people or to let people find you, never use your phone number that way unless you turn on Let friends find me by phone number, never use it for marketing, never sell it or share it for advertising, and never use it for analytics or to track you. There is no marketing choice in the Application. If we ever offer marketing email, it will be a separate choice that is off unless you turn it on, and we will update this policy first.
• How emails and codes are sent: our account emails are sent through Microsoft 365 (Microsoft Graph) from an address on our domain, without a copy kept in our mailbox; if you reply, your reply reaches support@theshft.app and is kept as support email (Section 21.2). While that sender is not set up, they may be sent through Google's email service (Gmail). Firebase (Google) sends the email verification and password reset emails and the text message sign in codes. Your mobile carrier's message and data rates may apply to a code. To confirm that a phone sign in comes from a real phone, Firebase may use a silent notification from Apple or a Google reCAPTCHA check, which collects device and interaction information as Section 21.4 (d) describes.
• Limits on sign in codes: to stop abuse and keep costs down, our servers may refuse to send a text message code to a number outside the countries we allow, after too many codes to one number or from one network in a day, or once a monthly total is reached. To count codes we keep, for two (2) days, counters keyed to a keyed hash of the number and of the network (never the number or network address itself), and for each month a total of codes sent and refused and their estimated cost, with no number or account. If a code is refused, you can use an email address or your Recovery Phrase instead.
• How long we keep it, and removing it: until you remove it in Settings, Keep your account, replace it with another, or delete your Account. Then the sign in record, the link to your Account and the masked copy are deleted. When you remove or replace an email address, we send a last email to it saying so. Section 24 lists how long each related record is kept.
• Signing in with your password, and Forgot password: on a new phone you type your email address and password. Our servers check them (not the Application), count wrong tries under a keyed hash of the address and never the address itself (five (5) wrong in fifteen (15) minutes pause that address for fifteen (15) minutes, ten (10) in a day pause it until a day after the first, an address with no Account is counted the same way so a pause says nothing about it, and the counter is kept two (2) days), and answer the same way and in the same time whether or not the address has an Account. A right password gives a one time proof for ten (10) minutes and only starts an Account recovery (Section 26.5): it never skips the wait and never opens your chats by itself. Your chats come back only from your Recovery Phrase, your old phone or, if you turned on saved chats for sign in, the saved copy (Section 26.1). For a password set in theSHFT, Forgot password emails a six (6) digit code to the address (sent only to an address that keeps an Account, with the same answer either way), then lets you choose a new password; your Account's phone gets a notice and an email goes to the address. Changing a password asks for the current one. For an older email and password sign in, if you forget the password, tap Forgot password. Firebase (Google) emails you a link to set a new one; the link works for about an hour, which is the time Firebase sets, and Firebase limits how many it sends. So that nobody can use this to learn whether an address has a sign in, the Application gives the same answer whether or not it does. When you ask from the Application, our servers also check whether the address belongs to a sign in linked to an Account and, if it does, send a push notification to that Account's phone and an email to the address saying a password reset was asked for, at most three (3) a day. To limit abuse we keep, for up to two (2) days, counters keyed to a keyed hash of the address and of the network, never the address or network address itself, and to the Account. The reply takes the same time either way. A new password never skips anything: a recovery still waits seventy two (72) hours, your phone can still cancel or decline it, and two step is still asked. We keep the time your sign in record was last confirmed so that, if a recovery starts after the password was changed, the notice about it says the password was reset.

26.4A. An Email Address or Phone Number Is Required. The rules are:

• New Accounts: signup asks you to add an email address or a phone number, your choice, as one of its first steps. If a step was lost (for example the Application was closed), the Application asks again before anything else, shows only that step until you add one, and our servers refuse to start chats, add people, make calls, or start or join SHFTs, crews or groups for your Account; you can always read our legal pages, contact support@theshft.app and delete your Account.
• Accounts made before: the first time you open theSHFT after this requirement began, we ask you to add one. You can choose Not now for seven (7) days, counted by our servers from that first time. After that, the limits for a new Account apply until you add one. To count the seven days we keep, with your Account's sign in record, the time we first asked and the time the seven days end, until your Account is deleted.
• Email codes: if you type an email address, we email a six (6) digit code to it from account@theshft.app through Microsoft. The code works for ten (10) minutes and five (5) tries. We keep only a keyed scrambled form of the code, the number of tries and the times, for up to one (1) day, never the code itself, under a key made from a keyed scrambled form of the address, never the address. To limit abuse our servers keep counters keyed to keyed hashes of the address, the network, the session and the Account, for up to two (2) days. If you type an address on a new phone to get back in, we send a code only if that address keeps an Account through an email code or an email and password, and the Application answers the same way, and in the same time, whether or not it does. After a correct code on a new phone we keep a single use proof of it (only its scrambled form) for up to ten (10) minutes for that phone's next step, and the row holding it for up to one (1) day.
• Phone numbers: text codes work only for numbers in the United States and Canada for now; everyone can use email instead. Google (Firebase) sends the code. Before a code is sent, our servers check the number against that list, against daily limits per number, per device session and per network, and against daily and monthly limits on what we spend on text messages. For this we keep, for up to two (2) days, counters keyed to keyed hashes of the number, the session and the network, never the number itself, and daily and monthly totals with no number in them for up to about thirteen (13) months. When a limit is reached, the Application asks you to use email instead. We never send security notices by text message. An Account whose only way back in is a phone number waits seven (7) days, instead of seventy two (72) hours, before a recovery can finish, unless two step is on.
• What does not change: the email address or phone number is never shown to other users, never used for marketing and never sold; everything in Sections 26.4 to 26.7 applies to it; your Recovery Phrase still works; and deleting your Account deletes it as Section 26.4 describes.

26.5. Getting Back In on a New Phone. If you added an email address or phone number, you can get back into your Account on a new phone by signing in with it on the new phone, or, for an email address confirmed with a code or an email address with a password, with a code we email you (Section 26.4A). This is an Account recovery, and it works as follows:

• It starts with a notice: when a recovery starts, we email your email address, if you added one, with a link to cancel it, and send a push notification to your Account's phone, which shows an alert when you open the Application. The push names no one and contains no message content.
• It waits: a recovery can finish only seventy two (72) hours after it starts, unless you approve it on your Account's phone after a phone check (Face ID or your phone passcode), in which case it can finish at once. If your Account is used on its phone during the wait, the recovery cannot finish unless you approve it on that phone. You can cancel it at any time from the email or from your phone. Only the new phone that started a recovery can finish it, and you sign in again with your email address or phone number to finish it (or, for a recovery started with your passkey, use your passkey again). A recovery that is not finished within seven (7) days of its start ends. After a recovery is cancelled, a new one cannot start for twenty four (24) hours, and we limit how many recoveries can be started for an Account, a sign in method and a network.
• What comes back, and what never does: when it finishes, your new phone makes a new Recovery Phrase and new encryption keys, and the old Recovery Phrase stops working. Your username, your contacts, your groups and your theSHFT Pro come back. Your call history does not come back. Your old messages and the photos, videos, voice notes and files in them come back only if you had saved chats for sign in turned on (Section 26.1), and then only what that section says, never messages whose timer had ended. With it off, they were end to end encrypted and kept only on your old phone, we never had them, and nobody can recover them, including us. Your contacts see a notice that your security code changed (Section 9.3). As with a restore with your Recovery Phrase, your old phone is signed out and theSHFT's data on it is erased the next time it connects to our servers.
• Sign in with your passkey: if you made a passkey for theSHFT (Section 26.6) and it is on your new phone, for example because Apple or Google synced it there, you can start a recovery with it, with no email address, password or phone number. Your passkey tells our servers which Account it belongs to. This is a recovery like any other under this Section: the same seventy two (72) hour wait, the same notices, the same chance for you to cancel it or for your Account's phone to decline it, and the same limits. To finish it, you use your passkey again, and, when your Account has another two step method, that other method as well (Section 26.6).
• A hold after a recovery: for seven (7) days after a recovery finishes, sign in methods cannot be added, replaced or removed, two step cannot be turned off and no two step method can be removed, and while a recovery is waiting none of these can be changed. A recovery that starts cancels any removal of a two step method that is waiting. This gives you time to hear about a recovery you did not start before anyone can change the other way back in.
• Your Recovery Phrase still wins: a restore with your Recovery Phrase on a new phone, including Move to a new phone, cancels any recovery that is waiting, and if you added an email address we email it that your Account was signed in on a new phone.
• What a recovery cannot protect against: someone who controls your email account or your phone number (for example through a SIM swap at your carrier), and who waits out the seventy two (72) hours while you do not open theSHFT and do not act on the emails and alerts, can take over your Account's username, contacts, crews and Pro, but not your old messages. Two step (Section 26.6) closes this for people who turn it on, unless that person also has your second step. Someone who controls the Apple or Google account your passkey syncs to may be able to use your passkey to start a recovery; if your Account has another two step method, they also need that method, and if your passkey is your only method left, only the wait, the notices and your chance to cancel stand in their way. Someone who controls your email account can also cancel a recovery you started; you can then use your Recovery Phrase or your old phone. Our support team can cancel a recovery but can never finish one, move an Account or give anyone access to it. If you lose your phone, can no longer use your email address and phone number, and have no Recovery Phrase, nobody can get your Account back, including us.
• Records of a recovery: while a recovery runs, our servers keep which Account and which sign in method it is for (for a recovery started with a passkey, which passkey), its status and times, whether your phone was seen or approved it, how many wrong two step answers were entered, and one way hashes of the cancel link and of a secret only the new phone holds. A copy of its status is kept in the private part of your Account so your phone can show it. They are deleted when the recovery ends, and in any case thirty (30) days after it started. Opening the cancel link shows a page from our servers; like any page, our hosting provider receives your IP address.

26.6. Two Step: a New Phone Also Asks for Something Only You Have. In Settings, Keep your account, you can turn on two step. It is off unless you turn it on. With it on, a recovery under Section 26.5 cannot finish without a second step that only you have, and changing how you get back into your Account on your phone needs one too. The methods are a passkey (the one we recommend), an authenticator app and backup codes. An older PIN check is no longer offered as a new method: theSHFT no longer has a PIN, but an Account that already had the PIN check keeps it until you remove it or turn two step off. Passkeys work only on versions of the Application that include them; until a method is offered to you, we collect nothing for it. A passkey is a way back into your Account on its own (Section 26.5, Sign in with your passkey), so you can make one without adding an email address; an authenticator app is only a second step, so it needs a way back in first: an email address, Sign in with Apple or Google, or a passkey. We do not offer text message codes as a second step, because a text can reach someone who has taken over your phone number. All the records this Section describes are kept in parts of our database that only our servers can read, and our servers never write a passkey response, a code, a backup code, a secret, your PIN or a value computed from it to a log.

• When we ask for it: (1) before a recovery by email address, phone number or passkey can finish on a new phone; and (2) on your Account's phone, before you add, replace or remove a sign in method, add a two step method when two step is already on, remove a two step method, make new backup codes or turn two step off. On your phone, the second step gives a permission that works once, for that one change, for five (5) minutes; we keep only a one way hash of it, with your account identifier and the change it is for, until it is used or expires. Two step is on while you have a passkey, an authenticator app or the PIN check.
• Which answers count: once you have a passkey or an authenticator app, the answers that count are a passkey, a code from your authenticator app and a backup code, and your PIN no longer counts as a second step. Your PIN counts only while it is your only method. A recovery started with your passkey (Section 26.5) needs a different second step when your Account has one: a code from your authenticator app or a backup code, or your PIN when your PIN is your only other method. If your passkey is your only method, that passkey, together with the wait, the notices and your chance to cancel, is what protects your Account, and the Application tells you so.
• Passkey (recommended): a passkey is a sign in key for theSHFT that your Device makes and opens with your face, your fingerprint or your Device's passcode. Your Device's passkey manager creates a pair of keys. The private key stays in that passkey manager, which is iCloud Keychain on iPhone and Google Password Manager on Android unless you chose another one on your Device, and it is never sent to us. Apple, Google or the passkey manager you chose may sync it to your other devices signed in to the same account, protected and governed by their own terms and privacy policies, not ours; that is how a passkey can follow you to a new phone, and anyone who controls that account may be able to use it. For each passkey we keep its public key, its credential identifier, a counter, the ways your Device said the passkey can be reached, whether it is backed up or synced and whether it is kept on one device or synced, when it was added and when it was last used, plus a lookup entry from the credential identifier to your Account so that Sign in with your passkey can find your Account with no username. We also keep one random user handle for your Account that is not your account identifier or username. We do not ask for or keep any information from the maker of your Device or passkey manager about it. Each time a passkey is used, our servers send a random challenge that works once, for five (5) minutes, and check the answer with the public key; the face, fingerprint or passcode check happens on your Device, and we receive no biometric data and no passcode. A passkey works only for theshft.app, so a look alike website cannot use it. If the counter shows that a passkey may have been copied, we refuse it and put an alert for our administrator in our review queue saying that a passkey of your Account was refused, without saying which passkey; like other review queue entries, it expires after ninety (90) days (Section 18.6). To let the Application use passkeys, our website publishes two files that tell Apple and Google which apps may use passkeys for theshft.app; they hold nothing about you.
• Authenticator app: you scan a QR code, or copy a setup key, into an authenticator app you choose, such as Google Authenticator or 1Password, and it then shows a new six (6) digit code every thirty (30) seconds. The QR code holds a secret that both the app and our servers use to make the codes. Our servers keep that secret encrypted with AES-256-GCM under a key that only our servers hold and that is not kept in the database, together with that key's version, the time you set it up and the last thirty (30) second step a code was used for, so that a code cannot be used twice. A code is accepted for its own thirty (30) seconds and the steps just before and after it. The setup turns on when you enter your first code; a secret you start setting up and do not confirm within ten (10) minutes stops working. The authenticator app keeps its own copy of the secret under its maker's terms, including any backup or sync it offers, and it often lives on the same phone as theSHFT.
• Backup codes: when you turn on a passkey or an authenticator app, the Application shows you ten (10) backup codes of twelve (12) characters each. They are shown once, on your Device; we cannot show them again. Each works once, in place of your passkey or authenticator app, including at a recovery, where the code you use is spent. A passkey or authenticator app counts as on only after you confirm you saved the codes. We keep only a one way hash of each code, made with a secret key that only our servers hold, which codes were used, when they were made and when you confirmed you saved them. Making new codes replaces all ten at once: the old ones stop working and their hashes are deleted in the same step. Backup codes cannot be your only method. Keep them somewhere safe, not only on your phone.
• An older PIN check: earlier versions let you use your Account's PIN as a two step method (the switch Also ask for my PIN). It is not offered as a new method, and nothing in this version changes or sets a PIN. If your Account already has it, theSHFT asks for those digits only where our servers need them, never to open the Application. To check the PIN, your phone computes a slow one way hash of the digits (PBKDF2 with at least 600,000 iterations) with the random salt our servers stored, and sends us that hash. Our servers keep the salt and a further hash of that value made with a secret key that only our servers hold, never your PIN itself, and never write the PIN or the hash to a log. The check is deleted when you remove it, turn two step off or delete your Account. Because PINs are short, someone who obtained both the stored value and our secret key could try to guess your PIN; that is why the PIN check is no longer offered as a new method and, except as Which answers count above describes, stops counting once you add a passkey or an authenticator app.
• Wrong answers: during a recovery, five (5) wrong answers of any kind end the recovery and stop recoveries for your Account for twenty four (24) hours, and ten (10) wrong answers across recoveries pause recoveries by email address, phone number or passkey until you turn them back on from your Account's phone. On your phone, five (5) wrong answers in a day pause the changes that need two step for twenty four (24) hours, and we send a push notification to your phone. Every check of your PIN on your phone (for a second step, to replace your PIN check or to start a removal) shares one limit of five (5) a day, and your phone can try a second step at most ten (10) times a day. Closing your Device's passkey prompt without using it sends us nothing and counts as nothing.
• If you lose a passkey or your authenticator app but still have your phone: on your Account's phone (after a phone check and, if your Account still has a PIN check, after those digits, where a wrong PIN counts as a wrong answer), you can ask to remove that method without it. The removal finishes only after a seven (7) day wait. When the wait starts we send a push notification to your phone and, if you added an email address, an email; you can cancel it from your phone at any time, and we email you when you do and when the method is removed. The method keeps working until the wait ends. A removal cannot start or finish while a recovery is waiting or during the seven (7) day hold after one, and a recovery that starts cancels it. We keep which method is being removed and when the wait started and ends, until it finishes or is cancelled.
• Turning two step off: needs a second step on your Account's phone, and is not possible while a recovery is waiting or during the seven (7) day hold after one. Turning it off deletes every method in one step: the PIN check, every passkey record and its lookup entry, the authenticator app's encrypted secret and any secret being set up, the backup code hashes and any removal that is waiting. Removing one passkey deletes its record and lookup entry the same way. A passkey you removed, or that belonged to an Account with two step turned off or deleted, stays in your passkey manager until you delete it there, but no longer works for theSHFT.
• Notices: if you added an email address, we email it when a passkey or an authenticator app is added, when you confirm you saved backup codes, when a two step method is removed, when a seven (7) day removal starts and when it is cancelled. We also send a push notification to your Account's phone when you remove a method there, when a seven (7) day removal starts and when too many wrong answers pause changes. Like our other emails, these carry your username and no other detail of your Account, and never your codes.
• The trade off, and what we cannot do: two step makes getting back in harder for anyone who is not you, and that includes you if you lose your second step. If two step is on and you lose your phone and every method that counts for your Account (your passkey, your authenticator app and your backup codes, or your PIN when it is your only method, for example because you forgot it), a recovery by email address, phone number or passkey cannot finish, and only your Recovery Phrase can bring your Account back. If you have neither, your Account is permanently lost. Our support team cannot turn two step off, remove a method, skip a second step or reset one for you.

26.7. Move to a New Phone. If you still have your old phone, you can move your Account without an email address or phone number. Your new phone shows a QR code, which holds only a one time public key, and a six (6) digit match code. On your old phone, after a phone check (Face ID or your phone passcode), you scan the code and check the match code; your old phone then sends your username and Recovery Phrase to the new phone through our servers, sealed end to end so that only the new phone can open it. Our servers cannot read it, and delete it when the new phone collects it, and in any case within ten (10) minutes. Your new phone then restores your Account with the Recovery Phrase as Section 3 describes, and your old phone is signed out. Your messages do not move. To limit abuse, we limit how many moves can be opened from a network and sent from an Account.

27. LEGAL PROCESS, PRESERVATION AND LEGAL HOLDS

27.1. Legal Process. We disclose information in response to valid legal process, such as a subpoena, court order or search warrant, as the law requires. What we can and cannot provide is described in our Law Enforcement Guidelines. We cannot provide the content of end-to-end encrypted messages, calls or media, your PIN, your Recovery Phrase, your private keys, a passkey's private key or your backup codes. If you added an email address or phone number to keep your Account (Section 26.4), it is information we hold and can be required to disclose.

27.2. Legal Holds. In rare circumstances, we may be required by valid legal process (court order, preservation request under 18 U.S.C. § 2703(f), grand jury subpoena, or comparable authority) to preserve specific messages or message metadata past the point they would otherwise be deleted. When such a legal hold is in place affecting you OR another participant in a conversation you are in, disappearing-message timers may be temporarily overridden for the server copies of the messages covered by the hold. Important properties of legal holds:

• Legal holds only preserve messages we already store in encrypted form for delivery. They do NOT grant us the ability to decrypt end-to-end encrypted content. Only content we can read (such as community posts, Stories, profile pictures and which accounts reacted to a message) can be produced in readable form under a hold.
• Legal holds are governed by valid legal process. We do not unilaterally preserve messages; preservation requires a binding legal request, or our own obligation to preserve evidence of child sexual exploitation or of a claim involving theSHFT.
• A hold stops our scheduled deletion of the messages and Stories it covers; in a Group it covers the messages the held account sent, not those other members sent. It does not stop short lived records from expiring, does not stop the removal of suspected child sexual abuse material from view, does not currently stop every deletion a user starts on our servers, and never stops the erasure of messages on your Device.
• Some preservation orders include non-disclosure provisions that legally prohibit us from notifying affected users. Where notification is permitted, we follow our Law Enforcement Guidelines.
• Held records are preserved only for the scope and duration of the legal hold. When the hold is lifted or expires, normal deletion resumes.

27.3. Notice. Where the law permits and we can reach you in the Application, we try to tell you about legal process seeking your information before we disclose it, unless doing so is prohibited, would risk harm to someone, or concerns an emergency.

27.4. Emergencies. We may disclose information without legal process where the law allows, if we believe in good faith that disclosure is necessary to prevent imminent death or serious physical injury, to protect a child, or to respond to fraud or a security threat.

28. SECURITY AND DATA INCIDENTS

28.1. Measures. We protect information with measures that include:

• End-to-end encryption for direct messages, group chats and calls, as Section 9 describes
• Encryption in transit (TLS) for connections to our servers, and at-rest encryption provided by our hosting provider
• Per item keys for Stories, profile photos and group photos
• Access rules that limit which accounts can read each record
• A phone check (Face ID, Touch ID or your phone passcode) before sensitive actions such as deleting your Account or moving to a new phone
• Sealing of message text in the Application's local database
• Screen capture protection, always on, that blanks screenshots and screen recordings of your conversations and of the screens that show a secret, on your device and on the devices of the people you message (Section 16)
• Limits on password, code and restore attempts
• For an Account recovery by email address or phone number, a seventy two (72) hour wait, notices by email and on your phone, a cancel at any time, and optional two step with a passkey, an authenticator app or backup codes (Section 26)
• Restricted administrative access, with a record of each opening of a child safety report

28.2. No Guarantee. No method of transmission or storage is completely secure. We cannot guarantee that information will never be accessed, disclosed, altered or destroyed by a breach of our safeguards, and we are not responsible for access that results from a compromised Device, malware on your Device, your sharing of your password, Recovery Phrase or backup codes, or someone else's control of the email account or phone number you added to keep your Account, of the Apple, Google or other account your passkey syncs to, or of your authenticator app.

28.3. Incidents. If the law requires us to notify you of a security incident, we will do so by a notice in the Application, a notice on our website, notice through major media where the law calls for it, and email to anyone who gave us an email address (including an email address added to keep an Account, sales representatives and applicants), and by any other method the law requires, and we will notify regulators as the law requires.

29. YOUR CHOICES AND CONTROLS

• Notifications: turn them off in your Device settings or choose kinds in the Application; Tips and updates is off unless you turn it on; turn off post text in open SHFT notifications.
• Crash reports: Settings, Privacy, Advanced privacy, Send crash reports.
• Read receipts and typing indicators: off unless you turn them on.
• Last Seen: Everyone, My Contacts or Nobody (Section 13 explains the limits).
• Profile photo: Everyone, My Contacts or Nobody.
• Link previews: on unless you turn them off.
• Screen capture protection: always on, with no setting (Section 16).
• Safety prompts: on unless you turn them off.
• Blocking and reporting: available on people, messages, posts and Stories.
• Keep your account: add, replace or remove an email address or phone number, add or change a password, turn two step on or off, add or remove a passkey or an authenticator app (or remove an older PIN check), and make new backup codes, in Settings, Keep your account (Section 26).
• People you may know: on unless you turn it off in Settings, Privacy and safety, Suggest me to people I may know; Hide removes a person from your suggestions.
• Who can see my friends list: Everyone, Friends or Only me, in Edit profile; your profile card, its interests and added photos, and which Open SHFTs you show, in Edit profile. Your friend count is public.
• Find friends from your contacts and Let friends find me by phone number: only if you tap or turn them on (Section 2).
• Show SHFT names on the lock screen (Live Activities): off unless you turn it on, in Settings, Notifications.
• Export: request a copy of your account information in the Application.
• Deletion: Section 25.

30. YOUR PRIVACY RIGHTS

30.1. Everyone. Wherever you live, you may ask us to: tell you what personal information we hold about you and give you a copy; correct inaccurate information; delete your information (you can delete your Account yourself at any time); give you your information in a portable format; and stop or limit processing you have consented to, such as notifications or crash reports. You can use many of these rights directly in the Application. Otherwise, email support@theshft.app and include your username, and we will respond within thirty (30) days or any shorter period the law requires.

30.2. Verifying Requests. We do not have your real name, so we verify requests by asking you to show control of your Account, for example by confirming the request from inside the Application. If you added an email address, we may also verify a request by sending a message to that address. We will never ask for your password, your PIN, your Recovery Phrase, a backup code or a code from your authenticator app to verify a request. We cannot give anyone the content of end-to-end encrypted messages, because we do not have it. We may refuse or limit a request where the law allows, for example where it would reveal another person's information or where we must keep the information for a legal reason, and we will tell you why.

30.3. Appeals. If we deny your request, you may appeal by replying to our decision with the subject line "Privacy Appeal." We will respond within the time the law requires (for example forty five (45) or sixty (60) days in states whose laws provide for appeals) and explain how to contact your state attorney general if you disagree with the result.

30.4. Authorized Agents. Where the law allows, you may use an authorized agent to make a request for you. We may require proof of the agent's authority and confirmation from you in the Application.

30.5. No Discrimination. We will not deny you the Services, charge you a different price or give you a different quality of service because you exercised a privacy right.

31. UNITED STATES STATE PRIVACY RIGHTS

31.1. California. This Section applies to California residents and supplements the rest of this policy. We describe the categories of personal information defined by the California Consumer Privacy Act, as amended (CCPA), that we collected in the past twelve (12) months:

• Identifiers: username, account identifier, installation identifier, push tokens, IP address (in logs and rate limit hashes); an email address or phone number, which an Account requires (Section 26.4), and, if you use Continue with Apple or Google, the provider link and verified email address (Section 3); Live Activity tokens (Section 3); and for sales representatives, name, email, phone, postal address and taxpayer identification number.
• Customer records (Cal. Civ. Code 1798.80(e)): a telephone number, only if you choose a phone number as your way to sign in; and for sales representatives, name, address, telephone number, identity document and financial account (PayPal) information.
• Commercial information: theSHFT Pro purchase and subscription status, Night Pass purchase and ledger records, promotion and referral code use, invite rewards.
• Internet or other electronic network activity: message and call metadata, presence, Community activity, votes, crash and stability data.
• Geolocation data: the country associated with your network connection and your Device's region setting; the rough area of a SHFT you host and make findable, until it ends; not your precise location (your exact location is never sent to us; if you turn on Show nights near you from everyone, a rough area is used to answer that request and not stored).
• Audio, electronic, visual or similar information: Community and Story photos, videos and text, and profile photos (end-to-end encrypted content is received only in encrypted form).
• Professional information: for sales representatives, application details.
• Inferences: a per Community standing score derived from your public actions there.
• Sensitive personal information: account log in credentials (the recovery key computed from your Recovery Phrase, or for older Accounts a hash of it; the email address or phone number you added to keep your Account, with the value computed from your password (never the password) and, for Continue with Apple, the refresh token we keep to revoke it; and, if you turn on two step, an older PIN check, your passkeys' public keys and credential identifiers, the encrypted authenticator app secret and the backup code hashes) and, for sales representatives, taxpayer identification numbers, the citizenship or tax status certification on Form W-9, and government identity documents. We use sensitive personal information only for purposes the CCPA permits (such as providing the Services, security, verifying identity and meeting legal obligations), so the right to limit its use does not apply.

Sources, purposes and recipients are described in Sections 2 to 6, 8, 22 and 23, and retention in Section 24. We disclose each category for a business purpose only to the service providers in Section 22 that process it, to other users as Section 23 describes, and as the law requires. We do not sell or share personal information as the CCPA defines those terms, including for cross-context behavioral advertising, and we have not done so in the past twelve (12) months; we have no actual knowledge of selling or sharing the personal information of anyone under sixteen (16). California residents have the rights in Section 30, including to know, delete, correct, and not be discriminated against, and may use an authorized agent. We do not offer financial incentives for personal information; promotion codes, referral rewards and invite rewards are not offered in exchange for personal information. California's "Shine the Light" law (Civil Code 1798.83) permits requests about disclosures for direct marketing; we do not disclose personal information to third parties for their direct marketing purposes.

31.2. Other States. Residents of states with comprehensive privacy laws (for example Colorado, Connecticut, Delaware, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah and Virginia) have the rights in Section 30, including the right to appeal a denied request, and residents of Oregon and Minnesota may ask for a list of the specific third parties we disclosed their personal data to. We do not sell personal data, process it for targeted advertising, or profile you in furtherance of decisions that produce legal or similarly significant effects. Because we do not sell or share personal information or use it for targeted advertising, there is nothing for a universal opt out signal such as Global Privacy Control to turn off, and we treat such a signal as a request to opt out of any future sale or sharing.

31.3. Nevada. We do not sell covered information as Nevada law defines it.

31.4. Washington and Other Health Data Laws. We do not collect consumer health data. The Safety prompts check (Section 18.1) runs only on your Device. The only thing it keeps is when it last showed each kind of prompt, on your Device, so it does not repeat too often; its result is never sent to us or anyone else and is not used for any other purpose.

32. EUROPEAN ECONOMIC AREA, UNITED KINGDOM AND SWITZERLAND

32.1. Not Offered There. theSHFT is not offered in the European Economic Area, the United Kingdom or Switzerland, and the Application is not available in the App Store in those places. We do not direct the Services to people there or monitor people there. If you use the Services while you are in one of those places anyway, for example while travelling, this policy still describes how we handle your information, and you can use the rights in Section 30.

32.2. If That Changes. Before we offer the Services in any of those places, we will update this policy to describe the controller, our legal bases for each purpose, your rights under the General Data Protection Regulation and the United Kingdom's and Switzerland's laws, how you can complain to a supervisory authority, how we transfer information to the United States, and the representative we appoint there.

33. OTHER COUNTRIES

If you live in another country, you may have rights under local law similar to those in Section 30, for example under Brazil's Lei Geral de Protecao de Dados, Canada's Personal Information Protection and Electronic Documents Act, Australia's Privacy Act 1988, South Korea's Personal Information Protection Act, Singapore's Personal Data Protection Act or Japan's Act on the Protection of Personal Information. Contact us at support@theshft.app to use them. Your information is transferred to and processed in the United States, whose laws may differ from those where you live.

34. CHILDREN

theSHFT is for adults eighteen (18) and over, and older where our regional minimum or local law requires. It is not directed to children and we do not knowingly collect personal information from anyone under eighteen (18). If you are a parent or guardian and believe your child is using theSHFT, contact us at support@theshft.app with the username if you know it, and we will close the Account and delete its information, except records we must keep by law. If we learn that an Account belongs to someone under the minimum age, we will close it.

35. INTERNATIONAL TRANSFERS

We are based in the United States, and our providers store and process information in the United States (Google's Firebase database in a United States multi-region, and our server functions and relay in the us-central1 region) and in other countries where they operate. By using the Services from outside the United States, you understand that your information will be transferred to and processed in the United States.

36. COOKIES, SIMILAR TECHNOLOGIES AND DO NOT TRACK

We do not allow third parties to collect personal information about your activity over time or across other websites through the Application. The Application does not use cookies for tracking, advertising identifiers or tracking pixels, and it does not track you across other companies' apps or websites, so it does not show Apple's App Tracking Transparency prompt. Our sign in and database software stores session information on your Device so you stay signed in. The website uses no tracking or advertising cookies, and its sales representative dashboard stores your representative code in your browser's local storage. Because we do not track you across other sites, we do not respond differently to browser "Do Not Track" signals.

37. APPLE APP STORE PRIVACY DETAILS

Apple's App Store shows a summary of our data practices that we provide, in Apple's categories. We keep it consistent with this policy; if you find a difference, tell us at support@theshft.app and we will correct it. Among the data types it lists are: contact information (your email address or phone number), identifiers (your account identifier and push tokens, including Live Activity tokens), purchases (theSHFT Pro and Night Pass purchase records), diagnostics (crash and stability reports), the result of your age check (never your birth year), and the provider link when you use Continue with Apple or Google. We do not use any of it for tracking.

38. CHANGES TO THIS POLICY

We may change this policy when the Services or the law change. The "Last Updated" date and version show when it last changed. If a change is material, we will tell you in the Application before it takes effect and, where the law requires, ask for your consent. We will not use information we already collected in a materially different way without telling you and, where required, obtaining your consent.

39. CONTACT US

theSHFT LLC, Attn: Privacy, 212 W. Troy St., Ste B, Dothan, AL 36303, United States

Email: support@theshft.app (privacy requests, appeals, California requests, EEA and UK requests, account deletion help, and law enforcement requests)

Website: https://theshft.app

Please include your username and a description of your request. We aim to acknowledge requests within five (5) business days, and we respond in full within thirty (30) days, or any shorter period the law requires.