PingPong Privacy Policy

Last updated: September 15, 2026 · Effective: September 13, 2026

The short version

PingPong is a messenger with end-to-end encryption. Your messages, photos, audio and calls are encrypted on your device, and only the recipient's device can open them. The server delivers what it can't read: this isn't a promise not to look, it's a system where there's nothing to look at.

• We don't ask for an email, a real name or a date of birth.
• A phone number is optional.
• There are no ads, no tracking, no usage analytics and no third-party SDK inside the app.
• We don't sell any data, to anyone.
• The exception is the support chat, which is not end-to-end encrypted: the team reads what you write there. The app says so at the start of every support conversation.
• Bots you create are also outside end-to-end encryption: what a bot sends and the buttons you tap in it go through the server. A bot chat appears separate and labeled in the app.

This policy applies to everyone who uses PingPong, in any country. Where the law of the place you live gives you specific rights, they're in "Your rights where you live". This text says plainly what exists. Where there's a limit, it's written down.

Who is responsible for your data

The data controller, the person who decides how and why your data is processed, is Thomaz Junior, an individual who develops and runs PingPong. For anything about privacy, including requests under data protection laws, write to thomaz@xtech.international.

That email is also the contact for the data protection officer (DPO) under the laws that call for one: the controller answers it himself.

What stays on our servers

PingPong's servers run on Amazon Web Services infrastructure; where they are is in "Where your data is". Only this data is kept there:

• Account: a random identifier, not tied to your name, phone or email; your public encryption keys; the day the account was created and the day of your last access (no time of day).
• Account password: the vault encrypted on your device and the copy of your connections, also encrypted (see "Account password and signing in on another phone"). The server doesn't see the password or what's inside them.
• Username: required to create an account, and stored only in scrambled form (a hash with a secret that never leaves the server). The server can answer "this @ exists" when someone looks it up, but it can't list anyone's usernames. When you change your @, the old one stays reserved for you for 90 days, also scrambled, so no one can pose as you.
• Phone number, if you confirm one: a scrambled value of the number, never the number itself. If you turn on "Find me by my number", the value that makes contact discovery possible is kept too.
• Notification identifier that Apple gives your device.
• Block list: pairs of identifiers, with no name and no reason.
• Messages and attachments waiting for delivery, encrypted and unreadable to us.
• Invites you sent: the code, the channel and, if the person joins through the invite or accepts it later, the account that came from it.
• Bots, if you create any: each bot's number and name, the API keys only in scrambled form (with the name you gave each one, the date it was created and the day it was last used), the message templates you save, and your developer portal sessions (the browser and the dates). Also, for a short time, what a bot sent that hasn't reached your app yet, and taps on its buttons it hasn't fetched yet.
• Earlier suspension, from when the team still suspended accounts after a report: only the date. Nobody is suspended this way anymore; an existing one stays until the team lifts it.
• Block by the abuse limits or by reports, if the account goes past the limits or is banned: the step (a 1-hour pause, a 24-hour pause, or a ban), the name of the limit that triggered it (or "reports", or "banned by support" with the ticket number), the numbers the server counted (how much, over how long, and the ceiling), the account's device (1 to 8) and the dates. Never content, contacts or IP address.
• Reports against the account, for the automatic ban: the reported account, the reason chosen, whether the report counted (and, if not, why) and the date. The reporter is kept only scrambled, with a secret that never leaves the server: it's used to avoid counting the same person twice, and can't be turned back into their account.

A few more protective records, all short-lived and listed in the retention table: SMS sending controls, the per-device account limit and data about a replaced device.

What never stays on the server

Message content, call content, photos, videos, audio, documents, stickers, location, profile name, profile photo, status text, your address book, the nicknames you give people, group member lists and group names, chat and call history, your chat wallpaper and your IP address.

How each feature handles your data

Account and username

You create the account with a username (your @) and an account password (see below). The device generates its own keys and gets a credential from the server; there's no email. Your profile name, photo and status are sent to your contacts and to the people you chat with one to one inside encrypted messages, never to the server. If someone who isn't in your contacts writes to you, the name and photo they sent are kept, encrypted, only on your device, so the chat can show who it is; that doesn't make them a contact.

To stop accounts from being created in bulk, sign-up carries an Apple attestation (App Attest) proving the request comes from the real app. The server checks it and doesn't keep it. The app also sends a random device identifier, created by the app itself, to limit new accounts to three per device per day: the server keeps only a scrambled code of it, with the day, for two days, with nothing linking it to the account created. There's also a per-network limit, counted in the server's memory using a scrambled address, and forgotten when the server restarts.

At sign-up, the app sends the country set on the device (for example, "JP" or "US"). It only adds one to that country's count of new accounts for the day and isn't stored on your account.

Account password and signing in on another phone

With your @ and your account password, you can sign in to your account on any phone. The password never leaves the device. What goes to the server is a 256-byte vault, encrypted on the device with a key derived from the password and a server secret (a calculation called OPRF, in which the server takes part without seeing the password). Inside the vault are the account identifier, the account's master key, your profile key and a recovery token; never your conversations or the keys that open them. The server also keeps the salt and the parameters of the calculation, how many wrong attempts there were and when, and the recovery token only in scrambled form.

Every attempt to open the vault goes through the server, which counts them: ten free, then waits that grow up to one hour, about 40 attempts on the first day and 24 per day after that. Anyone asking about an @ that doesn't exist, or has no password, gets an answer with the same shape, so the question doesn't reveal who has an account. The honest limit: someone holding both the server secret and the database could test passwords outside the server, paying a heavy calculation for each guess. A weak password would fall within days; a phrase of four random words, like the one the app suggests, would not. That's why the app requires a minimum password and shows its strength. Saving the password in iCloud Keychain is your choice, and then it also depends on your Apple account.

Along with the vault, the app keeps a copy of your connections on the server: the people you've talked to (their @, the name you saw, each one's safety key and since when), who connected with you through Connect (and when you connected), who you blocked or verified, and your profile. It's encrypted on the device with the account's master key, which only exists on the device and inside the vault, and the server can't see who they are or how many. A Connect request travels end-to-end encrypted, like a message: the server doesn't know it exists.

When you sign in on a new phone, your account, @, profile and connections come back. Old conversations don't: they only exist, encrypted, on the device they were on. The old device stops right away, and your contacts see that your safety number changed. If you lose both the password and the device, the account can't be recovered: we have no way to do it. The app PIN is something else: it stays on the device and never goes to the server.

Phone number (optional) and SMS

You can create an account and use everything without a phone number. If you want to confirm a number, we send a code by SMS. The number passes through the server only in memory, at the moment of sending, and goes to the SMS company. What's kept is a scrambled value of the number and the code for 10 minutes, and a send counter, against abuse. Once confirmed, only the scrambled value stays on the account.

Finding contacts from your address book

Reading the address book is optional and depends on your iPhone permission. When you look for people who already use PingPong, the device scrambles each number before asking the server, using a blind calculation in which the server answers without learning which number was asked. The address book isn't uploaded. The numbers of your contacts who don't use PingPong aren't stored by us in any form.

To be found by your number, you have to turn on "Find me by my number", which is off by default. A limit that has to be said: whoever holds the server's key can test numbers in bulk against these scrambled values. That's why a phone number is optional and discovery is off by default.

Messages

Messages are encrypted end to end. The server keeps an encrypted message only until the recipient's device confirms it arrived, and then deletes it. Anything nobody picks up is gone after 30 days.

With sealed sender, a message reaches the server without saying who sent it: the sender travels encrypted inside it. When the app can't use that path yet, the message goes identified, and the sender's account is stored with it until delivery. Read receipts and "typing", when turned on, travel the same way, encrypted.

Photos, videos, documents and other attachments

Each attachment is encrypted on the device with its own key, which travels inside the message. The server receives an encrypted file, with no name, no type and no thumbnail, and keeps it only until every device the message went to has downloaded it: when the last one does, the file is deleted. Anything not downloaded is gone after 14 days at most, and deleting the message for everyone also deletes the file, as does deleting a message that hadn't reached anyone yet (waiting for the person to join, or not sent) or deleting all chats. To know when everyone has downloaded it, the server counts the devices that already did with a marker that doesn't say which device it is.

View-once photos

A photo can be sent to open only once. It's encrypted end to end like any photo, and goes without a thumbnail. A caption, if there is one, travels encrypted with it, only shows while the photo is open and disappears with it: it doesn't stay in the chat. The recipient opens it once, always with screen protection on, even if it's turned off in settings: where iOS allows it, a screenshot comes out blank, screen recording and mirroring cover the photo. No one is notified of screenshots. No device can stop someone from photographing the screen with another camera. When it's opened, the photo is deleted from the recipient's device; on the sender's device, the copy is deleted as soon as sending finishes. On the server, the encrypted file follows the same rule as other attachments: it's deleted when everyone who received it has downloaded it, or after 14 days at most. In a one-to-one chat, and with read receipts on, the sender learns that the photo was opened.

Voice messages

Audio is recorded to a temporary file that is deleted right after, and then takes the same path as an encrypted attachment. You choose whether to receive voice messages, for everyone or per contact. That choice lives on your device and goes, encrypted, in your profile, so people writing to you know before they record. Audio from someone you don't want voice messages from isn't kept.

Calls

Voice and video calls are end-to-end encrypted and connect the two devices directly whenever the network allows. When it doesn't, they go through a relay server of ours that only sees encrypted bytes and keeps no log. While the call is happening, that server can see that a call is passing through it and for how long, and it's the one that tells each device its own public address. We don't record calls. Call history stays only on your device. A number you leave typed on the dial pad also stays only on the device, and is cleared after 10 hours or when you save it as a contact; to show the name of whoever has that number, the app checks your address book on the iPhone itself, without asking the server. During a call, the Dynamic Island and the Lock Screen show who you are talking to, the time and the audio level, put together on the iPhone itself, going through neither our server nor Apple.

Groups

The server doesn't know a group exists. A group message is sent, encrypted, to each member separately; the group name, photo and member list travel inside those encrypted messages. In the details of a message you sent to a group, the app shows who has received it and who has read it, with each person's time; those times are when each confirmation reached your device, and they are stored only on it, outside the backup, for up to 90 days.

Location

You can send the spot where you are, or share your live location for 15 minutes, 1 hour or 8 hours. Only with your iPhone permission, only while the app is in use, and only after you tap. Location goes inside encrypted messages, and sharing stops at the end of the chosen time, when you stop it, when the chat is deleted or when the app is closed. The server never receives your location. While sharing is on, the Dynamic Island and the Lock Screen show that it is on, with whom and how long is left; this is put together on the iPhone itself and goes through neither our server nor Apple.

Maps inside the app come from Apple Maps (MapKit): to draw the map, the device downloads the area shown from Apple, as in any app with a map. "Open in Maps" hands the coordinates to Apple's Maps app, only when you tap it. With Google Maps or Waze installed, tapping a location asks which app to open it in; the coordinates go straight from the device to the app you choose, which follows its own policy, without passing through the PingPong server.

Stickers

Your sticker library stays only on your device, encrypted. Making a sticker from a photo happens on the iPhone itself; the photo doesn't go anywhere. When you import stickers from a file (a chat exported from WhatsApp or a .wastickers pack), the app reads only the stickers, ignores text, photos and videos, and deletes its copy of the file. Animated stickers made from a video or a GIF are also made on the iPhone itself; the video doesn't go anywhere. A sticker sent in a chat goes as an encrypted attachment.

GIFs

GIF search is provided by KLIPY (KIKLIKO, Inc.), but your device never talks to it: the app asks our server, and our server asks KLIPY. KLIPY receives only the term you searched for, the app's language (like "en_US") and our server's address; it doesn't receive your network address (IP), your account, your number or anything about your device. Previews and GIFs also pass through our server. The server doesn't store or log what you search for, or which GIFs you see or send. A GIF you send goes as an end-to-end encrypted attachment, like a photo: whoever receives it talks neither to KLIPY nor to the GIF server.

Link previews

When you write a link in a message, your device opens the page to build the preview: the site name, the title, the description and a small image. At that moment the site sees your network address (IP), just as if you opened the link in your browser; the request doesn't go through the PingPong server and carries no cookies, no account and nothing stored on the device. The preview travels end-to-end encrypted inside the message, and the recipient's device doesn't talk to the site: the link only opens if they tap it. If the message goes out before the preview finishes loading, the preview follows right after, also encrypted. Addresses on a local network don't get a preview. On the device, the preview is stored encrypted alongside the message and is deleted with it.

Chat wallpapers

The wallpaper you choose stays only on this device. It doesn't go in messages, doesn't go to the server and isn't included in backups. A photo used as a wallpaper is stored encrypted on the device.

Contacts

Your PingPong contacts, the nicknames you give them and your chats stay only on the device. You can add someone by their @ or by QR code. When you tap to save a contact to your iPhone's Contacts, the app creates the contact there, with the name and number you confirmed, and does nothing else with your address book.

When you block someone, their messages and calls stop reaching the chat, and they aren't notified. What they send while blocked (text, location, contacts, and the encrypted reference to photos and files, whose file follows the normal attachment period on the server) is kept hidden, encrypted only on your device and outside the iCloud backup, for up to 369 days, 23 hours and 58 minutes, and then deleted unopened. The server doesn't hold these messages: it delivers them like any other. When you unblock, you choose whether to see them or discard them. Only you see, in the chat, that you blocked or unblocked.

Invites

You can invite someone who doesn't use PingPong yet and start writing to them right away. Those messages stay encrypted on your device and are sent, end-to-end encrypted, when the person joins. On the invite screen, the app shows your inviter code: the same pseudonym your account has in the invite ranking the team sees in the admin panel, computed by the server from the account identifier. The panel doesn't know whose code is whose; only you see yours, and you show it if you want to be recognized.

The invite goes out through your WhatsApp, your SMS or the iPhone share sheet, with a link carrying a code. The server keeps the code, your account, the channel and the date, and, if the person joins, which account came from the invite. The number and name of the person you invited never reach the server. Your name goes at the end of the link, in a part (#de=) that browsers never send to the server; it reaches the recipient inside your message, and WhatsApp or the carrier see it like any other message you send through them. The link page has no trackers, loads nothing from other sites and keeps nothing about whoever opens it.

On the invite page, tapping download on the App Store copies the invite link (with the code and, if present, the inviter's name) to the clipboard of the device of the person who received it, and the page says so before the tap. At sign-up, PingPong only asks iOS whether a link is copied, without reading the content; if there is one, it shows the system Paste button. The app reads the clipboard only when you tap that button, and uses what it gets only if it is a PingPong invite: it fills in the invite code and shows who sent the invite. Anything else is ignored and not kept. The invite link is then cleared from the clipboard, and none of this leaves the device except the code, which goes to the server at sign-up like any invite code. We don't use IP addresses, device model, browser or any other fingerprint to connect the page to the app.

When the person you invited creates an account with the invite code, the server immediately tells the inviter, so the messages waiting on the inviter's device go out right away. The notice goes only to the inviter: a signal over the open app's connection, with the code and the new account, or, when the app is closed, a silent notification through Apple, with no text and no invite data. The server stores nothing new for this: it already kept which account came from which code. The sign-up screen says beforehand that whoever invited you will know you joined.

If you already have an account and get someone else's invite, you can accept it by pasting the link in the app (in New contact). Accepting links that code to your account, without counting as a referral, and notifies the inviter the same way; the app asks first. Each code works once, and an invite can be accepted up to 90 days after it was sent. Without the code, the inviter can only find you by your @ or, if you allow it, by your number in their address book; the server never receives the number of the person invited.

There is an automatic invite through WhatsApp, which you trigger by tapping invite and confirming on screen. Only with that tap do the invited person's number and your name leave the device: they go to our server, which hands them to Kapso and Meta so the message goes out on WhatsApp on PingPong's behalf. Neither is stored here, and neither appears in any log. Of the invited number we keep only a scrambled summary (HMAC), for 30 days, for one purpose: if ten people invite the same person, they get a single message. Meta learns that number was invited and when. The ordinary invite, sent from your own WhatsApp, still never passes through the server.

Notifications

We use Apple's notification service (APNs) to let you know something arrived. The notification leaves the server with no content, just fixed text like "New message"; what appears on your screen is put together by the device after decrypting. Apple learns that your device got a notification, and when.

Support

The support chat (in Settings, Support) is a separate service, with its own database, on the same infrastructure as our servers. It is not end-to-end encrypted: the PingPong team reads what you write there. Your other chats don't go through it.

Support keeps your account identifier, your @, the topic you picked and your answers to its questions, the messages exchanged, the rating from 0 to 10 you give the service (and your comment, if you write one), who handled it, and the dates. The support team sees the rating; the admin dashboard sees only totals and each agent's average. The app version, iOS version and device model are sent only if you tap "Send this information". Support doesn't receive your phone number, contacts, chats or device credential; the app signs in with a key that lasts 15 minutes. When the team replies, you get a notification with the fixed text "Support replied".

A resolved ticket closes on its own after 7 days with no reply, and a closed ticket is deleted 2 years after closing. To prevent ticket floods, support keeps a scrambled code of the account and the time of each ticket opened for 31 days. The team signs in with a password and a verification code, and each action they take is logged for 2 years.

Bots

In the developer portal you can create up to 5 bots, each with a number and a name, and the API keys your own systems use to send you notices on PingPong. For now, a bot can only message the person who created it.

To sign in to the portal, the page shows a QR code, you scan it with PingPong's camera and confirm with the app lock. The portal doesn't ask for an email or password and doesn't open any chat: it only sees your bots. Before you confirm, the app shows the browser and system that asked to sign in; that record is deleted as soon as the sign-in is used, or within 75 minutes if it isn't. A portal session lasts up to 12 hours, ends after 1 hour idle, and you can see and end sessions from the app.

A bot chat is not end-to-end encrypted: what the bot sends and the buttons you tap go through PingPong's server and reach whoever created the bot. Your other chats never reach it. The server keeps a bot message only until your app confirms it received it, and 7 days at most; a button tap, until the bot fetches it, and 24 hours at most. The notification for a bot message has a fixed text, without the content, the bot's name or its number.

An API key is shown in full only once, when it's created; the server keeps only a scrambled code of it, with a secret that never leaves the server. You can revoke a key from the portal or the app, and deleting a bot deletes its keys, templates and anything waiting for delivery.

Reports and bans

You report someone from inside the chat (Info, Report) or through the support chat. In the chat, you pick the reason and select, one by one, the text messages you received from that person and want to show: only those go to PingPong, with the text and time of each one, and the screen says so before the button. No other message leaves your device. Through the support chat, you give their @ and paste or type the excerpts. The app doesn't read any chat to build the report, and the reported person isn't told who reported them.

The report becomes a support ticket, and the team reads the excerpts you showed. The server counts how many different people reported each account: when 10 different people report the same account within 7 days, it's banned automatically. It doesn't count the same person reporting again, people the reported account had already blocked, or accounts less than 7 days old, so nobody can get someone banned by coordinating reports or creating accounts. The support team can also ban, but only an account with at least one valid report, always with a written reason linked to the report and the ticket. Beyond that, nobody on the team pauses, blocks or bans any account: pauses and blocks are automatic, by the limits below.

A ban is permanent: the account can't send or receive messages, but can still talk to support, to ask for a review, and delete itself. Only the support team lifts a ban. The report in support, with the excerpts and the decision, is deleted 90 days after the decision; the report count on the server, 90 days after the report. Accounts the team suspended before this rule stay suspended until the team reviews them, and can ask for a review through the chat.

Abuse limits

To protect the service from spam, bots and overload, the server counts the pace and volume of each account's use: requests per minute, reconnections, how many different people the account looks up per hour, and whether it keeps trying after being told it went past a limit. It doesn't look at content, and it still can't read your messages. This count lives only in the server's memory, for 24 hours at most, and disappears when it restarts.

Going a little past the pace only gets you a "wait a moment", with no consequence. Going past a ceiling that normal use never reaches counts as a strike: the first pauses the account for 1 hour; the second, for 24 hours; the third bans it permanently. Each strike counts for 90 days. During a pause or ban, the app shows the reason, how long is left and what happens if it continues; on the 24-hour pause and on a ban, the screen offers the support chat so you can ask for a review, with the reason already filled in (the 1-hour pause ends on its own). Deleting the account is still possible. When the account is blocked and when it's back, you get a notification with the fixed text "Your account has been blocked" or "Your account is back", with no reason or time: the reason shows only inside the app.

Each block is recorded for 1 year after it ends. The support team sees that record to review your request, and can unblock the account, if it was a mistake (cancelling the strike, so it no longer counts, is only for whoever manages the team); who decided and why goes into the team's action log, and the team can then see that the account was unblocked once before. The admin dashboard sees the totals, and each block only under the account's pseudonym, without its identifier (see "Usage numbers"). You can ask for a person to review any automated decision about your account: that's what the support chat is for.

Before an account exists (at sign-up and for SMS), there are no strikes: the limits are per device, per number and per network, and a network that keeps hammering long after the limit is paused for a few minutes, counted only in the server's memory and with the address scrambled.

Where your data is

PingPong is used in many countries, but the data described here sits in only a few places, and this is the full list. The controller is based in Brazil. Our servers, the databases (including the support one), encrypted attachments and the call relay are on Amazon Web Services, in the São Paulo region, in Brazil. A few companies take part in running the service, and each sees something specific:

If you don't use a phone number, no SMS company receives anything about you.

When you yourself send something to another app, such as an invite through your WhatsApp or your SMS, or a location opened in Google Maps or Waze, that app receives what you sent and follows its own policy. The PingPong server takes no part.

International transfers

Because our servers are in one place, using PingPong outside Brazil means your data crosses borders. These are the actual flows:

• From your device to our servers, in Brazil: everything the app sends to the server and to support, such as your account, your encrypted messages and attachments, and what you write in the support chat.
• From our servers to the United States: the notification identifier and the fact that a notification happened, to Apple; GIF search terms and the app's language, to KLIPY, with nothing that identifies who searched; and, once sending to numbers outside Brazil is turned on, the number and code of those SMS, through Twilio.
• From your device straight to Apple: the map area you open in the app.
• Cloudflare: answers DNS lookups from the point of its network closest to you.

Where the law of your country requires a safeguard for sending data abroad, we rely on what it provides: an adequacy decision for the destination country, where one exists; standard contractual clauses (such as those of the European Commission, the United Kingdom or Brazil's ANPD), in the data protection terms of the companies in the table; or, where the law allows it and there's no other route, the transfer being necessary to provide the service you asked for, or your consent. The United States has no general federal data protection law, which is why we send only the minimum described above there. You can ask at the contact email for a copy of the safeguards used.

How long each thing is kept

When the server deletes something, it's really deleted: there's no trash bin. The caveat that has to be said is the automatic backups, kept for 7 days so the service can come back if a disk fails. Something deleted may remain in one of those backups until it expires, and messages and attachments stay encrypted in them.

When your account moves to another device, the server keeps a code of the old device's credential and its notification identifier for 90 days, to tell that device to stop, even if it stays off for days.

Technical logs

The servers note what happens so we can find out when something breaks: the method, route and result of each request. Technical logs carry no IP address, headers, account identifier or content, stay only on the servers' own disks and are gone in 14 days. The call relay keeps no log, and the servers' front door keeps no access log.

Usage numbers

We follow the service through daily totals, not linked to any account: new accounts per country, messages accepted and delivered, SMS sent per company, invites per channel, call relay credentials issued, the time the service was up, how many automatic blocks happened per day, and support numbers (tickets, average rating and each agent's rating). These totals don't identify anyone and are kept with no time limit.

The admin dashboard also has a list of accounts, each under a pseudonym: a short code computed from the account identifier with a server key, which isn't part of the identifier and can't be turned back into it. For each account, the list shows only the day it was created and the last day it was seen (no time of day), whether it has an @ and whether it confirmed a phone number (yes or no, never the @ or the number), whether contact discovery is on, how many devices it has, whether it is active, paused, suspended or banned, how many different people reported it in the last 90 days, and how many invites it sent and how many became accounts. The list never shows the @, phone number, name, photo, messages, contacts, who the account talks to or when it sent messages: the server has none of that in the clear, and what it keeps scrambled isn't shown. The list is put together on the spot from what the server already keeps, and creates no new data.

Why we process each piece of data

Data protection laws require every use of data to have a justification, its legal basis. Ours are four, and the name each law gives them is in "Your rights where you live":

• To provide the service you asked for: account, keys, the account password and signing in on another phone (the vault and the copy of your connections), delivery of messages and attachments, notifications, calls, invites and support.
• With your consent: confirming a phone number, contact discovery, access to your address book and location, and device data in support. You can turn each one off at any time, without affecting what was done before.
• Legitimate interest: anti-abuse limits, technical logs, usage numbers and reviewing reports, always with as little data as possible. The interest is keeping the service safe, working and free of spam and of abuse against the people who use it, and you can object to it (see below).
• To comply with a legal obligation: responding to a valid order from a competent authority.

A username and an account password are needed to create an account; without them the service can't work. Everything else is optional.

Your rights where you live

In any country, you can:

• find out whether we process your data and get access to it;
• correct anything wrong or incomplete;
• ask us to delete your data, or to anonymize or block it when it's unnecessary;
• receive your data in a format you can take to another service (portability);
• object to processing, or ask for it to be restricted;
• withdraw consent you gave, at any time;
• ask for a person to review an automated decision about your account;
• know who we share with and what happens if you don't consent;
• and not be discriminated against or treated differently for using any of these rights.

In practice:

• Your profile, chats, contacts and stickers are on your device, and you change or delete all of it in the app. We have no copy to correct or hand over.
• Turning off "Find me by my number" deletes your number's discovery value right away.
• Deleting your account deletes what's on the server and in support (see below).
• Any other request, by email to thomaz@xtech.international. We reply within 15 days, free of charge.

Since we don't know who you are, for requests about a specific account we may ask you to confirm from the app itself, through the support chat, so we don't hand your account's data to someone else. Someone else can make the request for you with your written authorization; in that case, we confirm the authorization with you.

Brazil (LGPD)

Brazil's General Data Protection Law guarantees the rights in the list above (article 18), including information about the option not to consent, and review of decisions made solely by automated means (article 20): automatic pauses and bans are reviewed by a person through the support chat. Under the LGPD, our bases are performance of a contract, consent, legitimate interest and compliance with a legal obligation (article 7). You can complain to the National Data Protection Authority (ANPD), through the channels at gov.br/anpd.

European Union, European Economic Area and United Kingdom (GDPR and UK GDPR)

The General Data Protection Regulation (GDPR) and its UK version (UK GDPR) give you the rights of access, rectification, erasure, restriction of processing, portability, objection (including to what we do on legitimate interests) and withdrawal of consent, and the right not to be subject to a decision based solely on automated processing without being able to ask for human review. Our bases are performance of a contract, consent, legitimate interests and legal obligation (Article 6(1)(b), (a), (f) and (c)). You can complain to the data protection authority of the country where you live or work: the list of European authorities is on the European Data Protection Board's website; in the United Kingdom, it's the Information Commissioner's Office (ICO).

California (CCPA and CPRA)

If you live in California, the California Consumer Privacy Act, as amended by the California Privacy Rights Act, gives you the right to know what personal information we collect, where it comes from, what it's for and who we share it with; to ask for it to be deleted or corrected; and not to be discriminated against for using these rights. We don't sell personal information or share it for advertising, and haven't in the last 12 months, so there's no "do not sell" request to make. In the last 12 months, the categories were: identifiers (the account identifier, the scrambled username and phone number, the notification identifier); the account log-in credential, inside the encrypted vault, which is the only sensitive personal information under the law and is used only for you to sign in; and, if you use support or make a report, what you write or choose to show there. We don't collect precise geolocation: it only travels encrypted between devices. All of it comes from you or your device, for the purposes and with the companies described in this policy, for the periods in the table. The authorities are the California Attorney General and the California Privacy Protection Agency.

Japan (APPI)

If you live in Japan, the Act on the Protection of Personal Information (APPI) lets you request disclosure of the personal data we hold about you, including records of provision to third parties; correction, addition or deletion; and suspension of use, erasure or an end to provision to third parties. Requests go to the contact email, free of charge. The purposes of use are in "Why we process each piece of data" and in each feature; the security measures, in "Security". On provision to third parties in other countries: the data goes to Brazil, where our servers are, which has a general data protection law (the LGPD) and an authority that enforces it (the ANPD); and to the United States (Apple, KLIPY and, once turned on, Twilio), which has no general federal law but has state laws, such as California's, and sector-specific laws. Each of these companies protects the data under its own data protection terms and privacy policy. The authority is the Personal Information Protection Commission (PPC).

Anywhere else

If you live in another country, you have at least the rights in the list above, which we respect everywhere, and you can complain to the data protection authority where you live. If the law of your country gives more rights or a shorter deadline, it applies.

Deleting your account

In Settings, Account, Delete my account. The app wipes this device and asks the server to delete the account, the keys, the notification identifier, messages and attachments waiting, the scrambled phone value, your block list, the entries where someone else blocked you, your invites and your @ reservation. It's immediate, with no grace period. If you used support, the app first asks support to delete your tickets; if that request doesn't get through (no internet, for example), write to the email above.

People you talked to keep their own copy of your chats, on their devices. A report against your account, if there is one, is kept for the period in the table, to deal with abuse. Anything in backups is gone when they expire, within 7 days.

To delete only your chats and keep the account: Settings, Account, Delete all chats. Everything is removed from this device. If you tick "Also delete from the recipients' phones", the app asks the recipients' devices to delete the messages you sent. The request is end-to-end encrypted like any message, and it only works for messages you wrote. People on an older version of the app may still see them.

Legal requests

If we receive a valid order from a competent authority, such as a court order, we hand over what exists. From the server: the day the account was created and the day of last access, the public keys, the notification identifier, the block list and messages not yet delivered, which are encrypted and unreadable to us too. If the person used support, their tickets. We have no chat content, history, contacts or location, and we can't hand over what we don't keep.

Security

None of your conversations go into the iCloud backup. The database with your messages, the keys, the attachments and anything you left typed live in a folder the app marks as excluded from backup, and the keys that open the database stay in the Keychain tied to this device, never uploaded to iCloud. PingPong calls also stay out of the Phone app's Recents, which iCloud syncs. That is why switching phones doesn't bring your conversations along: signing in with your @ and password brings back your account and contacts.

• End-to-end encryption for messages, attachments and calls.
• A server that forwards what it can't open; username and phone number only in scrambled form.
• On the device, the app's data is encrypted, and you can turn on an app PIN and Face ID. Face ID belongs to iOS: the app never receives biometric data.
• The account password never reaches the server: on the device, it opens a vault the server keeps without being able to read it, and every attempt goes through the server's count.
• TLS connections, databases on encrypted disks with mandatory TLS, secrets kept out of the code.
• Support team access with a password, a verification code and a log of every action.
• Automatic deletion every hour, with a deadline for each kind of data.

No system is perfect, which is why we designed PingPong to keep as little as possible on the server.

Minimum age

PingPong is for people aged 16 or older, in every country, the same rating as on the App Store. If the law of your country requires a higher age to use a service like this, or to consent on your own to the processing of your data, the higher age applies. We don't ask for a date of birth, so as not to keep one more piece of data about you. If we learn that an account belongs to a child or a teenager without the authorization required by law, we delete the account.

If something goes wrong

If there's a security incident that could bring you significant risk or harm, we tell you and the data protection authorities the law requires, within each one's deadline, saying what happened, which data was affected and what we did about it.

Changes to this policy

When the app changes what it processes, this policy changes with it, and the "last updated" date at the top of the page changes too. An important change (new data, a new company, a longer retention period) applies from its publication here and is also described in the app's release notes on the App Store.

Contact

Thomaz Junior, data controller for PingPong. Email: thomaz@xtech.international