Pal — Privacy Policy

Last updated: 13 October 2026

Applies to the Pal iOS application and its backend services. Pal is distributed through Apple — on the App Store, and through TestFlight to testers — and is operated from the United States.

1. Who operates Pal

Pal is operated jointly by two individuals: Kayacan Kaya and Jordan Wong. There is no company behind Pal. When this policy says "we", it means those two people, and both of us are responsible for the data described here.

2106 Lockwood Ave, Fremont, CA, United States

Contact: jwong@thepal.app — this is the address for every question, request and complaint in this document.

If we ever incorporate, we will update this section and tell you in the app before the change takes effect.

2. What Pal does, and the one rule that shapes everything else

Pal learns your individual palate from meals you log and rate, and uses it to recommend restaurants and specific dishes.

Your taste profile is built only from meals you log and rate. Nothing else touches it. Swiping a card, saving a restaurant, liking a post, browsing the map, or chatting with Pal never moves it — not a little, not indirectly.

That is not a marketing line. It is a rule enforced by a test that reads our own source code, finds every piece of code that can write your taste profile, and fails the build if one appears that is not on an approved list with a written justification. Today that list has four entries: the code that records a rated meal, the code that rebuilds your profile from your own past rated meals, and two administrative paths that only ever recompute from those same meals.

We also state the negative, because in this category it is not obvious:

• We do not buy or use restaurant ratings, review scores, or star ratings from anywhere to build your profile.
• We do not use transaction data. We do not have, buy, or look at credit card records, bank data, or any record of what you have spent.
• We do not buy purchase history about you from any third party.

Section 6 lists, item by item, the things that we do record about your activity and that still never reach your taste profile.

3. What we collect

3.1 Your account

You create an account with Sign in with Apple or an email address and password. Pal cannot be used without an account.

What we receive depends on which one you use:

• Sign in with Apple — an Apple-issued identifier, and the email address Apple gives us, which may be a private relay address that hides your real one.
• Email and password — your email address, your display name, and a scrypt hash of your password. We never store your actual password and cannot recover it.

You can link both of these to the same Pal account.

Alongside that we store the profile you build: your display name, your username (a unique handle, used so friends can find you), your bio if you write one, and your profile photo if you set one.

We keep a session record so you stay signed in for up to 30 days of inactivity.

If you forget an email-and-password account's password, you can ask for a reset link from the sign-in screen. Here is exactly what that does:

• We e-mail a one-time link to the address on the account. The mail is sent through Resend (section 9), so Resend sees that address.
• We store a SHA-256 hash of the link's token, never the token itself, along with when it was made and when it expires.
• The link works once and stops working 30 minutes after it was sent.
• When you use it, we set your new password, spend that link, cancel any other reset links outstanding on the account, and end every signed-in session on every device — so if someone else was signed in as you, they are not any more.
• Whether or not the address has an account, the app answers the same way. We do this deliberately: a different answer would tell a stranger which addresses are registered with Pal.

A spent or expired link cannot be used again, but the record of it is not deleted on a schedule: those reset records are kept until you delete your account (sections 10 and 11).

3.2 Meals you log — this is the product

For every meal you log we store:

• The photograph, if you attach one. Section 4 is about photos specifically.
• The dish name, whether you typed it or accepted our suggestion.
• Your verdict — nope, meh, good, or crave — and any per-dish ratings you give afterwards on the taste axes.
• The restaurant, if you tagged one; or the fact that a meal was home-cooked or at a place you could not name.
• Your caption and dish tags, if you write them.
• When you ate it, and when you logged it.
• Where you were, if you had granted location permission. See section 5.
• The cuisine and country of origin we worked out for the dish.

3.3 Your taste profile

From your rated meals we compute a numeric profile across seven flavour dimensions — sweet, sour, salty, bitter, savoury (umami), heat and fat — plus a separate running record of dishes you rejected. This is data we derive; you never give it to us directly, and it means nothing outside Pal.

3.4 Dietary needs — please read this one

During setup we ask two separate questions, and we store both answers on your profile:

• Things you never want served. We offer eleven presets — shellfish, peanuts, tree nuts, dairy, gluten, egg, soy, sesame, pork, beef, alcohol — and a free-text box for anything else. We treat these as absolute.
• How you eat. Vegetarian, vegan, pescatarian, halal, kosher, or no red meat.

We consider this sensitive information and you should too. An allergy is health information. Halal and kosher can reveal religious belief. We ask for it because a recommendation engine that ignores it is useless to you, and we deliberately never ask how allergic you are — there is no severity setting anywhere in Pal, because an exclusion is an exclusion.

Answering is optional. You can skip the question entirely, and you can change or clear your answers later in Me › Food preferences.

Where this data goes: it is stored on your profile, it filters and re-ranks what we recommend, and it is included in the context we send to our AI provider when you chat with Pal (section 8). Dietary needs you state in a chat with Pal are also recorded in the app event for that reply (section 3.7). All of it is deleted when you delete your account.

3.5 Your activity in the app

We record which restaurants you view, save, like, mark as visited, or pass on in the Decide deck; whether you tapped to reserve a table or get directions to one; how you answered when we asked whether you went somewhere; which spec cards you have collected; which recommendations we showed you and the match score we predicted; and which countries you have eaten your way through.

None of this touches your taste profile. See section 6.

3.6 Social features

If you follow someone, send a friend request, post to the feed, or write in a group thread, we store those connections, posts and messages. Anything you send into a shared thread is visible to everyone else in it.

3.7 App events

We record a fixed set of moments to understand where the app is confusing or slow — for example app opened, photo taken, dish resolved, verdict submitted, meal logged, rating card offered and answered, a push notification opened, an app update found and applied — and a handful of timing measurements. These events are stored against your account when you are signed in.

Events the app sends carry only a short list of pre-approved fields per event, and our server discards anything else before writing it down. Those fields are counts, durations, file sizes, named outcomes, and which version and build of the app you are running. A few events also carry the internal Pal identifier of the thing they are about — the restaurant you opened or corrected the cuisine of, the meal you rated, or the notification you opened — because that is the point of them. No photo, no photo content, no dish name, no caption and no coordinate reaches an app event by that route. One event about the map records the raw error text the phone's map component returned when it failed to load; that text describes the phone's software, not you. Section 3.10 covers the events that are diagnostics.

Our server also writes events of its own, and those are not filtered by that list. Most of them are timings, counts and named outcomes — how long a Pal reply took, which step of signing up you reached, a notification setting you switched, and the restaurant identifiers behind a reserve or directions tap. One is different and you should know about it:

• When you send a message to Pal's chat, we ask a language model to turn it into a small structured summary of what you are asking for, and we store a record of each reply as an app event. That record can contain short words taken from what you typed — a cuisine you named, for example — and the dietary needs or exclusions you stated in the conversation (such as vegetarian or halal), which section 3.4 explains are sensitive.

We use no analytics SDK. There is no third-party analytics company in Pal.

3.8 Your IP address

Our server sees your IP address on every request, as any server does. We use it for one reason: to limit how fast one network can use features that could be abused — chat with Pal, friend search, signing in, creating an account, requesting a password reset, uploading a photo, identifying a dish from a photo, loading restaurant photos, and adding a restaurant by typing its name. For most of these the address is kept as a key in a rate-limit record in our database; for password resets it is held only in the server's memory. Those records are short-lived and are pruned (section 11). We do not use your IP address to build a profile, and we do not use it to determine your location.

3.9 Notifications

If you turn on notifications we store an Expo push token for each of your devices, your per-category settings (messages, friend requests, being tagged at a meal, nearby dishes, meals you have not rated yet, "did you go?" about a place you liked, saved, or looked up a reservation or directions for, a weekly note about your friends, and a meal reminder — with, if you turn that one on, the time you picked and your phone's time zone), and a log of pushes we attempted — which category, the outcome, and what the push service replied. That log is how we enforce limits such as "at most one nearby push per day" and how we notice when pushes are silently failing. Most of it is pruned by age; the "did you go?" entries are not, because they are how we make sure we ask about a place only once (section 11).

3.10 Diagnostics — crash reports and performance data from your device

The app sends us diagnostic data, and it is tied to your account. An earlier version of this section said no crash report, error or diagnostic data left your device. That stopped being true, and this is the correction. There are two routes, and both go only to our own server.

1. The crash trail. While you publish a meal — including the rating that follows it — the app keeps a short trail on your phone of the steps it has reached. When publishing finishes cleanly the trail is thrown away. If the app crashes or the publish does not finish, the trail is still there the next time you open Pal, and the app sends it to our server. The same happens, anywhere in the app, when it hits an error it did not expect. The trail contains:

• the error message, the technical stack of where in the app's code it happened, and, for a screen that failed to draw, which part of the screen it was;
• the names of the steps that ran, with a few small details about each — counts, outcomes, server status codes, and on one step the name of the dish you were publishing.

It is sent with your sign-in, so our server records it against your account id. It is written to our server's log, not to our database, and it stays there for as long as our hosting provider keeps server logs (section 11); deleting your account does not reach those logs. If the trail cannot be sent — you are offline, say — the app keeps it on your phone and tries again on a later launch, a limited number of times, then deletes it.

2. Diagnostic app events. Some of the app events in section 3.7 are diagnostics, stored in our database against your account when you are signed in:

• performance data — how long uploading a photo or video took, how large it was, and how long each stage of publishing a meal took;
• other diagnostic data — which version, build and update of the app you are running, and, when the map fails to load, the raw error text the phone's map component returned.

These are kept until you delete your account (section 11).

Who else sees the crash trail and these events. Nobody outside the providers that run our servers and database (section 9).

The Sentry SDK in the app. The app also contains the software kit of Sentry, a crash-reporting service. It sends nothing unless a Sentry project key is set when the app is built. If a build carries one, that build sends crash reports and error reports to Sentry — the error, where in the app's code it happened, and technical details about the app and your phone such as the model and operating-system version. The kit is configured not to attach personal information: we set no name, e-mail address or account id on it, and we switch off its default collection of personal data.

Our server's own errors. Our server sends its errors to Sentry too, so we can see when our backend breaks. A server error report can include details of the request the server was handling when the error happened, which may include what the app sent in that request.

3.11 Feedback you send us

There is a Send feedback box in the app. It used to open your own mail app; it no longer does. What you type is sent from your phone to our server, and our server e-mails it to us through Resend (section 9). Resend handles the text of your message on the way.

The mail carries:

• Everything you typed, in full.
• A reply address, only if you type one. It can be any address; it does not have to be the one on your account, and if you leave it blank we have no way to write back.
• A short diagnostics block the app fills in — the app version, the build number, which app update you are running and its release channel, and your phone's operating system and its version (not the phone's model) — plus one fact our server adds rather than trusting the app for: whether the request came from a signed-in session.

We do not store your message. There is no feedback table in our database and no copy on our servers: the message is turned into an e-mail, handed to Resend, and that is the only place it exists. The honest cost of that choice is that a message which fails to send is not saved anywhere, which is why the app tells you plainly when it fails instead of pretending it went.

Your account is not attached to the message. We do not put your user id, your name or your account e-mail address in it. If you are signed in, the mail says only that — signed in: yes — and if you typed a reply address, that address is in it because you chose to put it there.

3.12 Reports, blocks, and agreeing to the terms

If you report a post or a profile, or block someone, we store a record of it: who filed it, who it is about, the post if there is one, the reason you picked, and any words you added. We also e-mail it to ourselves at once, through Resend (section 9), so that a report reaches a person rather than waiting in a queue. That e-mail carries the display names and Pal account ids of both of you, the reason, your words, and — for a post — the post's caption. The record in our database is removed when either account is deleted (section 10). The e-mail stays in our inbox, which deleting an account does not reach; write to us if you want it removed.

When you agree to the terms of use, we store that you agreed, which version you agreed to, when, and on which sign-in screen.

3.13 Places you import from Google Maps

You can import places you saved in Google Maps, from a Google Takeout file you pick on your phone. The file is read on your phone and never reaches us. Only the places you choose to import are sent: each one's name, and the address, position and Google Maps identifier the file gives for it. A place that matches a restaurant Pal already knows is added to your saved restaurants. A place on one of your lists that does not match is kept privately against your account, with those details, so we can try to match it later; to do that we may send its position — not its name, and nothing about you — to OpenStreetMap's map-query service (section 9) to look for a food place of that name there, and if one is there, the place is added to our restaurant catalogue. We also keep a count of how many places you imported each day, to cap it. Your imported places and that count are deleted with your account.

4. Your photos and videos — in plain language

This is the part testers most often assume wrongly, so here is exactly what happens when you attach a photo to a meal.

Everything in this section is true of video as well as of photographs, and video has one thing a photograph does not: sound. You can attach a video of up to 60 seconds, shot in the app or picked from your library, and it is uploaded with its audio track — whatever the microphone recorded along with the picture, including anyone talking nearby. That is why Pal asks for microphone permission. There is no way to attach a video with the sound stripped off, and we do not remove it for you. If a video would capture something you would not post, attach a photograph instead.

1. It leaves your phone. The app uploads it to our storage — a Google Cloud Storage bucket we operate through Replit.
2. We send it to an AI provider to work out what the food is. The image is sent to DeepInfra, an inference company, whose vision model reads the plate and returns a dish name, a cuisine, a list of components, and an estimate of how the dish tastes. Depending on which part of the flow you are in, this can happen up to four times for one photo.
3. We store what the model said about your photo. Not just the answer — the model's raw reply, before we parse it, including replies we could not parse. That record is how we find out when the model is wrong. It is stored against your account and deleted when you delete your account.

4. Who sees it depends on where you added it. This is the part to read twice.

   • A photo or video you post from the meal composer becomes a feed post. Tapping Post is the share; there is no second step. A video posted to the main feed can be played, with its sound, by every Pal user.

     • If you tagged a restaurant, the post goes to the main feed, where every Pal user can see it.
     • If the meal was home-cooked or the venue was unknown, the post goes to the Home segment, which is visible only to people who follow you.
   • A photo you rate from your camera roll is a post only you can see. That is every photo rated on "Show me three meals you've had lately" during sign-up, and every one from Me → Add past meals from photos. It does not appear in anyone's feed, Following, Trending, profile, or a restaurant's photos, and it is not in Pal's search. It goes public only if you open the post and tap Share to the feed. Pal never shares one for you.
5. The stored file is served from a public URL. Once a photo or a video is attached to a post, the file can be fetched by anyone who has its link, without signing in. This is equally true of a video and of its audio, and of a camera-roll photo only you can see: Pal never shows that link to anyone else, but the file itself is not locked. The link is a long random string that we do not publish, but it is not protected by a password.
6. The file can carry where it was taken. Phones often write the place a photo or video was taken into the file itself. Most photos are re-saved at a smaller size before upload, which normally drops that information, but some are uploaded as they are (a photo that is already small, for example), and videos are uploaded as they are. We do not separately strip that information, so a stored photo or video may still carry the position it was recorded at, and anyone with the file's link (point 5) can read it. If that matters to you, turn off location for your camera in your phone's settings, or attach a photo taken without it.

You can delete a post, and you can delete your account, and both remove the file (section 10).

What we do not do with your photos and videos: we do not scan your photo library — we only ever receive files you pick or shoot inside Pal. We do not use them to train anyone's AI model, and we do not sell them. We do not run face recognition on them, and we do not transcribe, analyse or send anywhere the audio on a video: it is stored and served with the video and is not read by us or by any model.

5. Location — what we store, and when

We ask for location permission only while you are using the app. Pal never requests background location. There is no background tracking, no significant-change monitoring and no geofencing anywhere in Pal. If you decline, Pal still works — you pick places by name instead.

There are several separate things we do with location, and they are not the same:

5.1 To find things near you — sent with the request, not stored. When you search for a place, open the Decide deck, load the feed, ask Pal for a recommendation in chat, or plan a day, the app sends your current position with that request so the answer can be about where you are. For restaurant search we pass it on to the Google Places API so it can bias results towards you; it goes to Google as a search parameter with no identifier attached. We do not save the position from any of these requests, with one exception: when the Decide deck has to pay Google to look up restaurants in an area Pal has not covered yet, we record that a lookup was made for that area — a square roughly 5 km across, not your position — together with a scrambled code derived from your account id, so that we can cap how many paid lookups one person triggers in a day. That record is part of our spending ledger and is not deleted when you delete your account.

5.2 On a meal you log — stored. If you had granted location permission when you logged a meal, we save a position onto that meal record, along with a note of where it came from. That position is either the one your device reported when you logged the meal, or — if the photo you attached recorded where it was taken and you accept it when the app offers it — the position stored in the photo. We keep it so that maps, distances and travel features work later. It is deleted with your account.

(An earlier version of this policy said we never store your device's location. That was wrong, and this section is the correction.)

5.3 Your home base — stored if you set it. If you tell the app to use where you are as your home base, it takes your current position and we save it on your profile, so distances still work when location is off. It is replaced if you set it again, and deleted with your account.

5.4 A place you name that Pal does not know — becomes a catalogue entry. If you log a meal at a restaurant by typing a name we have no record of, we add that place to our restaurant catalogue, which other Pal users may see. If you had location on, the meal's position (section 5.2) is stored as the place's position, so the next person who eats there can be matched to the same place. To check that such a place exists, we may compare that name and position with other sources, including OpenStreetMap: either against a copy of its map data we hold, or by sending the position — not the name, and nothing about you — to its public map-query service. We may also send the place's name and address — again nothing about you — to xAI to find the restaurant's own website.

5.5 For nearby-dish notifications — stored only if you opt in. If, and only if, you switch on "nearby dishes" notifications, the app occasionally sends your current position to us while it is open, and we keep one row — your most recent position, and nothing else.

• It is overwritten each time. We never build a trail or a history.
• If nearby notifications are off, our server refuses to record it at all.
• Turning nearby notifications off deletes the stored position immediately.

The precision is roughly city-block level; we never request the highest-accuracy mode.

6. What never touches your taste profile

Stated as a list, because this is the commitment in section 2 made concrete:

• Swiping, passing or liking a card in Decide
• Saving or bookmarking a restaurant
• Liking or saving a post
• Marking a restaurant as visited
• Browsing the map, the Atlas, or the feed
• Talking to Pal in chat
• Which recommendations we showed you
• Your app events

Every one of these is recorded (section 3.5), and every one of them is used only to order what you are shown next or to help us fix the app. Chat is worth calling out specifically: a group thread does keep a note of foods the conversation liked or rejected, so Pal can pick a restaurant for the group — but that note belongs to the thread, never to you, and it does not reach your taste profile. Code that once nudged a taste axis from a chat message was found and removed, and the test described in section 2 exists so it cannot come back.

7. Your contacts

If you open Find Friends, Pal asks for permission to read your contacts. If you allow it, the app reads the email addresses in your address book — up to 1,000 of them — and sends them to our server so we can tell you which of them already have a Pal account.

We do not store them. Our server compares the list against registered accounts in memory, returns the matches, and keeps nothing — not the addresses that matched and not the ones that did not. We never contact anyone in your address book, and we never tell anyone that you have their address. This holds when the comparison fails, too: if our database is unreachable mid-check, what gets written to our server's own error log is that it failed, why, and how many addresses were in the batch — never the addresses.

This only happens on that one screen, only when you allow it, and you can say no and use Pal normally. Nothing else in Pal reads your address book.

Tagging who you ate with. When you log a meal you can name who was there — a friend on Pal, or anyone else by a name you type. A friend you tag gets a notification from Pal if they allow that kind of notification, and can rate the dish themselves. We keep the name you type with your meal for as long as the meal is in your log, so it can show who was there. For someone who is not on Pal you may also type their email address yourself, so the meal can find them if they join. We never store that address. We store only a digest derived from it: a scrambled fingerprint we can match against an address someone later signs in with, but cannot turn back into the address. That digest can be matched for 48 hours after you tag them, and no longer. If they have not signed in with that address within those 48 hours, the digest can never be matched and we erase it; the name you typed stays on your meal. Pal never contacts that person. If you want to tell them, Pal opens your phone's share sheet with a suggested message, and nothing is sent unless you choose where it goes and tap send.

(An earlier version of this policy listed contacts under "what we never collect". That was wrong, and this section is the correction.)

8. Talking to Pal

Pal's chat is powered by a language model run by DeepInfra. When you send a message, we send that model your conversation, your taste profile, how many meals it is based on, your dietary tags, and — before you have logged anything — the dishes you named at signup.

We store your conversation so it is there when you come back. In a group thread, Pal is given a blended summary of the members' profiles and dietary needs so it can suggest something everyone can eat.

9. Who else handles your data

• Replit — runs our application servers. Handles everything the app sends us, in transit.
• Neon — hosts our database. Holds everything in section 3, at rest.
• Google Cloud Storage (through Replit) — stores uploaded photos and videos. Gets your meal photos and videos and your profile picture.
• DeepInfra — identifies dishes in photos and powers Pal chat. Gets your meal photos, and your chat messages, taste profile and dietary tags.
• Google Places — supplies restaurant names, addresses, hours, photos and reviews. Gets your search text, and your coordinate as a search bias with no identifier attached.
• Google Static Maps — draws the small map of the places you have eaten. Gets the positions of up to 40 restaurants you have logged meals at, with no identifier attached.
• Google Cloud Vision — reads text off restaurant menu images. Gets menu images from restaurant websites. Never gets your photos.
• Bright Data — fetches restaurant menu pages we could not reach directly. Gets restaurant website addresses. No user data.
• OpenStreetMap — its public map data is how we check that some restaurants exist. Its map-query service can get a position: a restaurant's; the position of a place you imported from Google Maps (section 3.13); or, for a place you named that Pal did not know, the position of the meal you logged there (section 5.4). Never a name, and nothing about you.
• xAI — its model searches the web for restaurants' own websites. Gets restaurant names, addresses and cities — which can include a place you named — and nothing about you.
• Resend — sends the three kinds of e-mail Pal sends. For a password reset (section 3.1) it gets the e-mail address on your account and the one-time link. For feedback (section 3.11) it gets the full text of your message, the reply address if you typed one, and the diagnostics block — but not your account e-mail address and not your user id. For a report or a block (section 3.12) it gets the mail we send ourselves: both people's display names and Pal account ids, the reason, any words the reporter added, and a reported post's caption. Pal sends no marketing e-mail and no newsletter, so there is nothing else it ever gets.
• Expo — builds the app, delivers updates, and delivers push notifications. Gets your push token and the text of the notifications we send you.
• Apple — distributes Pal through the App Store and TestFlight, provides Sign in with Apple, draws the maps in the app, and turns a position into a place name on your phone. Gets what Apple's own terms describe.
• Sentry — receives our server's error reports, which can include details of the request being handled when the error happened. If a build of the app carries a Sentry key, it also receives that build's crash and error reports — see section 3.10.

We do not sell your personal information. We do not share it with advertisers. Pal shows no advertising, contains no advertising SDK, and does not use Apple's advertising identifier or ask for tracking permission.

On our AI provider specifically. DeepInfra publishes its own statements about how it handles data submitted for inference. We are not in a position to independently verify another company's internal practices, so we will not repeat their claims here as if they were our findings. What we can tell you is what we do: we send them your photo and the text described above, we send no name, no email address and no account identifier alongside it, and we have no other arrangement with them. Their own policy governs what they do with it.

10. Deleting your account

You can delete your account and its data from inside the app: Me → Settings → Danger zone → Delete account. You will be asked to confirm. There is no form to fill in and no email to send.

Deleting removes: your account and sign-in identities, your sessions, your meal logs, your uploaded photographs, your taste profile and every backup copy of it we hold, your snapshots and history, the stored AI readings of your photos, your posts, captions and notes, your likes and saves, your restaurant saves, likes and visits, your Decide history and card collection, your travel plans, your preferences and dietary answers, your home base, your push tokens, your notification settings and notification log, your stored location, the places you imported from Google Maps, reports you filed and reports about you, blocks you made and blocks of you, your record of agreeing to the terms, your friendships, follows and friend requests, your messages, and any one-to-one thread between you and Pal.

Six things it does not remove, and you should know all six. The terms of use, section 11, covers the same ground table by table, with counts.

1. Other people's messages in a group conversation you were part of. Those belong to them. We remove your messages and your membership, and we replace your identifier on any thread you created so it does not name you. The surviving thread keeps one more thing of yours: if the group locked in a place to eat, that record stays, because the choice was the group's and not only yours. The identifier saying you were the one who locked it in is overwritten with a flat marker meaning "a deleted account" — the same marker on every such row, naming nobody. In a thread that was yours alone there is no group to preserve a decision for, and the record goes with the thread.
2. Your dish ratings — kept, but no longer connected to you. When you rate a dish's flavour, that measurement is folded into a running average that becomes the dish's published taste in Pal's catalogue, for every user. An average cannot be un-computed, so the ratings themselves stay. What goes is the link: on deletion we replace your identifier on those rows with a one-off code that names nobody, that is not derived from anything about you, and that no account can ever be issued. The code is unique to your deletion, so your ratings still count as one person's rather than being merged into somebody else's — but nothing in Pal can tell you they were yours. This used to be a genuine gap: the ratings were kept still carrying your account identifier. If you would rather they were removed outright, write to jwong@thepal.app and we will remove them by hand.
3. Catalogue records made by a curator, if you were one — records that a venue or dish was checked on a given date. These are claims about the catalogue rather than about you. An ordinary account has none.
4. Restaurant and dish information that was never personal to you.
5. A keyword note attached to a group conversation that survives you. If somebody added a note to a thread, the record of who added it sits inside a stored JSON value, and replacing your identifier on a column does not reach inside one. It is a single identifier in one place. We know about it, it is written down, and it is not closed yet.
6. An uploaded photo can outlive the database rows. Photos are deleted after the database, deliberately — the other order would destroy your photos and then leave your account intact if the database step failed. The consequence is that storage can refuse after your rows are already gone. When that happens the app does not report a clean success: it tells you the account and all of its data were deleted and that some photos could not be removed from storage. Which files those were is recorded on our side. Write to jwong@thepal.app and we will remove them by hand.

Deletion is immediate and permanent. We cannot restore an account. Copies may persist for a short time in our database provider's automatic backups, which expire on their own schedule (section 11).

11. How long we keep things

• Your account, meals, photos and taste profile: until you delete your account.
• Notification logs: pruned by age. A record that a push was sent to you is deleted once it is 30 days old — except the record that we asked "did you go?" about a place, which is kept until you delete your account, so that we never ask about the same place twice.
• Rate-limit records: pruned by age. A record is deleted once it has gone 24 hours without being used, on a sweep that runs every half hour.
• Crash trails (section 3.10): kept in our server logs, under the schedule below.
• The spending-ledger record of a paid area lookup (section 5.1): kept; it is not deleted with your account.
• App events (including the diagnostic ones in section 3.10), prediction records and password-reset records: kept until you delete your account. We say this rather than quoting a retention period because we do not currently delete any of them on a schedule, and a promise we do not keep is worse than a plain answer. All three are removed in full when you delete your account (section 10). A reset link itself stops working 30 minutes after it is sent, whatever happens to the record of it.
• Server logs: held by our hosting provider under its own schedule.
• Backups: our database is hosted by a managed provider whose backups expire automatically under that provider's own schedule. We do not control that schedule and we will not quote you a number we cannot guarantee.

12. Your rights

12.1 California

You have the right to know what personal information we collect, to get a copy, to correct it, to delete it, and to limit how we use sensitive personal information. We will not treat you differently for exercising any of them.

We collect information that the CCPA treats as sensitive: your dietary exclusions and patterns (section 3.4), which can reveal health information and religious belief, and your precise geolocation (section 5). We use both only to run the features they belong to — filtering and ranking recommendations, placing your meals, and sending the nearby notifications you asked for. We do not use sensitive personal information to infer characteristics about you, and we do not sell or share it.

We do not sell or share personal information as the CCPA defines those terms, and we do not process it for cross-context behavioural advertising.

To exercise any right, use the in-app deletion path or write to jwong@thepal.app.

12.2 The rest of the United States

Several other states give similar rights. We apply the same rights to everyone, wherever you live.

12.3 Outside the United States

Pal is operated from the United States and built for people there. If you are outside the US and believe we hold data about you, write to us and we will delete it.

13. Children

Pal is not directed to children under 13 and we do not knowingly collect information from anyone under 13. We do not ask your age. If you believe a child under 13 has given us information, write to jwong@thepal.app and we will delete it.

14. Security

Everything travels over HTTPS. Passwords are stored only as scrypt hashes and are never sent back to any client. Your sign-in token is held in your device's secure keychain. Data at rest sits with the providers in section 9 under their security controls.

Pal is early software built by two people. No system is perfectly secure, and we would rather say that than imply otherwise. Please do not upload anything you would be unwilling to have stored on someone else's server.

15. Changes

We will post changes here and update the date at the top. If a change materially affects how we handle your data, we will tell you in the app before it takes effect.

16. Contact

jwong@thepal.app

Kayacan Kaya and Jordan Wong 2106 Lockwood Ave, Fremont, CA, United States