What PocketRoles and the StarPocket services look at, keep and send

Summary

• We install nothing and check nothing on the PC or phone of people who only join a room.
• Records on a host's PC stay only on that host's PC. They do not reach us.
• Aegis evidence records on a host's PC (the record made when someone is removed or restricted) are kept 90 days for everyone, because appeals can arrive late (the records of a restriction still in effect may stay longer; 3.10). Other records, such as logs, are deleted after 30 days.
• PocketRoles will check (planned), inside that PC, whether your own Among Us account that is signed in is on the shared-ban list. Nothing is sent.
• What reaches us is only what you send yourself (support requests, "Join us" applications, report zips, appeals, applications for a Steam copy) and the information of an account you made yourself. Planned Client sign-in and Friends also send the information described below.
• Support requests are deleted 30 days after being marked resolved (if you write nothing for 7 days after our reply, the request is marked resolved automatically (planned); requests waiting for a reply stay until resolved; emails: deletion after 90 days is planned; not automatic today). Our servers do not store IP addresses. To count repeated sends, a mark made from the IP address that cannot be reversed is kept for 1 day only (it stays in the server backups for as long as they are kept; Article 5). If you write a reply-to email address on the contact page, we email you when we receive the request (planned) and when there is a reply. The emails never contain the subject or message you wrote, or the reply text.
• Server backups keep the newest 14 on the home server and the newest 30 on the author's PC. These are counts: gaps in creation or retrieval can leave backups older than 14 or 30 days. Manual and USB copies currently stay until deleted by hand. Planned deletion is after 90 days for manual backups and on the next copy for USB copies older than 90 days; disconnected USB copies can stay longer (Article 5).
• The support chat at the bottom right of the site (planned) requires signing in with a StarPocket account. It starts with article search without AI. The AI bot can answer people aged 18 or over in an allowed country who consent to sending text to AI (AI starts off). Text written to the bot is sent to Anthropic, a company in the United States, after contact details and similar parts are masked. Chat records not handed to a person are deleted from the server database 24 hours after the chat starts. Even during that time, the author cannot read them on the management screen. Nightly backups retain them for the backup retention period (Article 5). AI drafts for staff replies are off today. Do not write real names, addresses, phone numbers, schools or passwords.
• Chat translation is off by default. When it is turned on, the room's chat text is sent to Google or DeepL. You can turn it on from the first screen of StarPocket Client and in settings. That is for a fresh install: for someone who upgraded from v0.5.4 or earlier and never changed this setting, it may still be on (3.9).
• Players removed for a "Certain" cheat in a room are reported to Innersloth (off by default). You can turn it on from the first screen of StarPocket Client and in settings. Every way of installing starts off (3.9).
• You do not have to make a StarPocket account for the contact form. Support chat requires creating an account and signing in. If you do, it is not linked to you in the game. If you connect Discord, both your email address and your Discord ID and name are kept.
• Client account sign-in and StarPocket Friends are planned (3.12). Only signed-in Clients send our server the sign-in token, current status and, if enabled, hosted-room details and code. Only approved friends see your display name, avatar, status and shared room, within the age rules. Online status is kept only in memory. Signed-out Clients do not send the new Friends status or room data (sign-in and existing traffic are described in 3.9). People under 13 cannot use Friends.
• To have your records erased, type /cmd id in a room's chat and send us the code it shows.
• If you are under 18, read this together with a parent or guardian.
• Support requests are read by the author and by admins and support members chosen by the author. Support members read only requests for their own teams, and only those received after they were added. Support members must be at least 16 and live in Japan; ages 16-17 need parental consent. Help is unpaid. On staff screens, contact details in messages are masked, reveals and views are recorded for 1 year, and watermarks and stops for mass viewing reduce leaks (Articles 2 and 11). However, requests received from support chat, including live conversations, are read only by the author today.
• Room restriction appeals sent through the support site that say the restriction was a mistake are read by the author and by members of the Room Access Team chosen by the author. Staff see only appeals meeting the time conditions in Article 2(4) and submitted through a form with the new viewing notice version 1.2; an unset, empty or invalid access start time, old, missing or unknown versions, appeals failing the time conditions, and requests to erase records or reports about a host sent through the same form, are read only by the author. Staff can write only assessments and a reply draft; only the author decides whether to reply and whether to lift a room restriction (Article 2(4)).
• If you have connected Discord, you can choose "Also tell me by Discord DM when there's a reply". Only if you choose it, our bot sends you a Discord DM with "There's a reply", the receipt number and a link to where you can read it. The reply text is never sent. "Stop all Discord notices" also stops individually enabled notices; resumption starts with the next reply, without resending past notices. Unknown delivery and attempt numbers are kept for 90 days, but result records contain no Discord ID or DM text. Only temporary errors known to be unsent allow attempts at least 15 minutes apart, up to 3 including the first; unknown delivery is not retried. Attempts in progress and unknown deliveries count toward interval and attempt limits (3.1, item 7).
• The author reads in Japanese. Only the requests of people who ticked "may be sent to DeepL for translation" when sending them (this tick is planned) may be translated with DeepL in Germany (the paid DeepL API Pro), when the author or a staff member who can read that request presses "Translate". Parts that look like contact details are hidden before sending, and translations are not kept (3.1, item 12; Article 6).
• Applications to the contributor recruitment ("Join us") are sent while signed in. Every role requires applicants to be 16 or older, and applicants aged 16 or 17 need a parent or guardian's consent. Only the author reads applications; you choose a text or call interview, and calls are not recorded. Unlike ordinary support requests, applications that are not selected or are withdrawn are deleted after 90 days, and those of approved people are kept while they are contributors or support members and for 1 year after they stop (3.13; Article 5).

Article 1 (About this policy)

1. This policy explains how StarPocket Games ("we", "us") handles information about individuals in:
   1. Software: PocketRoles (the mod), Aegis, today's launcher, StarPocket Client
   2. Websites: the PocketRoles site, the StarPocket Games site, the support site (the Help Centre, the contact page and the account pages)
   3. Support: email, Discord tickets, the contact page on the site (the form and the receipt-number page), the support chat at the bottom right of the site and its AI bot (planned), applications to the contributor recruitment ("Join us")
   4. The StarPocket Account
   5. Central lists: the shared-ban list, the erase list and the lift list in the definitions file
   6. The Discord server "PocketRoles 役職部屋"
   7. The home server: support, accounts, the room list (planned) and so on
2. This policy keeps two things apart.
   1. Information we handle: what reaches us (Article 3, sections 3.1 to 3.8, 3.12 and 3.13, including communications to our server listed in 3.9)
   2. Information a host handles on their own PC: what the Software records on the host's PC, and what it sends directly from the host's PC (Article 3, sections 3.9 to 3.11)
      • Information kept only on the PC or sent directly to other companies does not reach us. Section 3.9 lists the information sent to our server and its destination.
      • But because we decide the Software's default settings and explanations, we describe it in detail here.

Article 2 (Operator)

1. Name: StarPocket Games
   • The activity name of one individual developer. Not a company.
   • The author's activity name: もみじちゃ (Momijicha)
2. Name and address: given without delay on request. Contact us through Article 14.
3. Person responsible for personal information: the author
4. Staff: the author, admins chosen by the author (such as the Aegis team), and support members who help with requests. Support members who read requests must be at least 16 and live in Japan. Ages 16-17 need a parent's or guardian's consent. The help is unpaid (3.13). Before including members living abroad, we will change this document and announce it in advance.
   • Admins help with support and appeals, following the author's instructions.
   • Support requests can be read by the author, the admins the author has allowed into the staff page, and support members chosen by the author. Support members read requests within the following limits. Only the author can add staff. The author adds them by entering an email address or Discord ID, by choosing from a list of accounts belonging to people who applied through "Join us" (below the table in 3.2), or by approving someone for support through "Join us" (3.13). They can enter as staff only when signing in by the same method. Requests are split into 9 teams: bugs, room access, help, suggestions, accounts, privacy, reports, parents and guardians, and general support, with names in the form "StarPocket … Team". Support members can read only requests for teams assigned to them. One person may have several teams. Admins can read across all teams (room restriction appeals, as described below, only if they are assigned the Room Access Team). Staff other than the author cannot see requests received before they were added (Article 11). Applications for a Steam copy are read only by the author and admins, never by support members (3.1; applications are not open yet). Until requests can be separated by subject, the general support team (category "Other") is not assigned to support members. "Join us" applications and the author's notes (including interview notes) are read only by the author, not by admins or support members (3.13). This is a separate contact category from the 9 teams. Translation and development contributors do not see support requests. Support members are not shown reply email addresses or account IDs, but can see the display name of people who sent while signed in, to greet them in replies. Email addresses, phone numbers, URLs, IP addresses, account numbers and friend codes in message text will initially be masked. A staff member with permission to read that request must press "Reveal" to see them, and the reveal is recorded (Article 11). This does not reveal the dedicated reply-address or account-ID fields hidden from support members. Please leave out unnecessary personal information. Support members cannot access the room, user or room-restriction management screens (Article 11). Requests received from support chat and live conversations are read only by the author today; admins and support members cannot see them.
   • Room restriction appeals: room restriction appeals sent through the support site where "What would you like the author to do?" is "I think the room restriction was a mistake" are read by the author and by staff the author has assigned to the Room Access Team (support members and admins). Even an admin cannot read them without that team. Staff access requires both submission through a form with the new viewing notice version 1.2 and receipt at or after the latest of four times: (1) the appeal access start time explicitly set by the author, no earlier than 2026-10-08 00:00 Japan time, when this policy version 1.2 takes effect; (2) when this feature was introduced on the server; (3) the additional viewing start time for all requests, shared by all staff; and (4) when that staff member was added. Each member's addition time and the shared start times are separate conditions. Lifting a pause does not change the member's addition time or set a new individual viewing start time. If the appeal access start time is unset, empty or invalid, only the author can read appeals. Even if received after introduction, appeals submitted with an old, missing or unknown viewing notice version are read only by the author. Stored notice versions are not filled in with the current version. Introduction time alone does not exclude old forms: the new form's notice version is also checked. Appeals that fail the time conditions are also read only by the author. If the same form is used for "Please erase my records" (an erasure request under Article 12) or "I want to report something about a host" (information about someone else), it is read only by the author, whenever it arrives. Staff can see masked parts (friend codes, evidence numbers, /cmd id codes and so on) with "Reveal", and each reveal is recorded. Room codes, in-game names and host names are not masked. Staff can write only assessments (text for the author that you cannot see; each staff member adds them one at a time and cannot change or delete anyone else's) and a reply draft (staff cannot overwrite a draft written by someone else). The author's notes are not shown to staff. Only the author decides whether to post a reply, whether to change the appeal's status or language and whether to lift a room restriction. Staff do not use AI drafts for appeals. Version 1.2 does not change how appeals sent by email or Discord ticket are handled.
   • Admins promise to keep things confidential. There are three parts. They do not tell anyone what they read for this work. They keep the promise after they stop being an admin. If they break the promise, they are removed as an admin.

Article 3 (Information we handle, and why)

3.1 Support (email, Discord tickets, the contact page on the site, the support chat)

"Join us" applications have separate information, access, retention and withdrawal rules in 3.13. The ordinary support-request retention and deletion plans in this section do not apply to those applications.

Support chat and AI bot (planned)

This is the chat planned for the bottom right of the site. You sign in with a StarPocket account, and the records are linked to the account number. The contact form can still be used without an account. Items 6, 7, 9 and 10 below also apply to the form; chat-only handling is identified separately. S-14 stops all chat use, form submissions by signed-in users, and "Join us" applications. The email contact remains available (Terms, Article 13).

1. Article search without AI answers first. When the bot is enabled, it answers people who meet the age and country conditions and consent to sending text to AI. AI starts off.
   • The bot uses Claude by Anthropic PBC (United States).
   • The bot is not a person. We say so at the start of every conversation.
   • Article search is not AI. It sends your search text to our server to find help-center articles. Search text and results become chat records (item 8: 24 hours from the start if not handed to a person; backups: Article 5). They are not written to server logs. If you consent to the bot, your text is also sent to Anthropic as described in item 3.
2. The bot answers only from help-center articles. We send the public articles in that language, the language code, and your own text from the same chat (up to the latest 20 previous messages plus the current question, favoring newer text within the character limit). Before sending, we mask parts that look like contact details or numbers, including email addresses, phone numbers, URLs, IP addresses, room codes, friend codes, Discord names or IDs, and receipt numbers; masked parts are not restored. Names within text and anything that cannot be masked are sent as written. Previous bot answers, the author's text, other people's requests, room-restriction and shared-ban records, and account information are not sent. The bot has no tools to read or change records.
3. Your text, after contact details and similar parts are masked, is sent to Anthropic to produce an answer. Previous bot answers are not sent.
   • Anthropic promises not to use content received through its API to train its AI.
   • Anthropic states that it deletes received content automatically within 30 days.
   • However, content judged to break Anthropic's usage rules may be kept for up to 2 years. Safety scores (trust and safety classification scores) may be kept for up to 7 years.
   • Under Anthropic's rules, the answer may be computed in a region outside the United States (storage is in the United States).
4. Before a chat starts, the screen explains records, readers and retention, and shows links and versions for the Terms and this Policy. You press "Agree and start"; the Terms, Policy and screen-explanation versions and time are kept. Eligible bot users see Anthropic (United States), what is sent and how it is masked, and a separate optional "I agree to send text to AI" tick (initially unticked). The country's system, Anthropic's measures and retention periods are explained in this Policy, linked from that screen (Article 6). Without the tick, article search and "Ask a person" remain available. The AI agreement version and time apply to that chat only; we do not add agreement to previous chats.
5. We do not use the bot for the following people or situations. Article search answers, and the author answers through "Ask a person". Article search and "Ask a person" are available regardless of country.
   • Anyone whose age band is not "18 or over", including those who have not answered. Chat uses the account-page band without asking for age again
   • Countries and regions absent from Anthropic's published supported-country list, including mainland China, Hong Kong and Macao; all of Ukraine; Kosovo; an unknown country (including Tor); and any additional country or region we block. Only countries allowed from the published list receive the bot. We use only Cloudflare's country mark, never browser time zone or language. The country mark is not stored
   • Monthly cost, per-chat cost, per-person daily (UTC) usage or service-wide daily AI usage limits; AI downtime; timeouts or unusable answers. We reserve the maximum cost first, so AI may be unavailable before actual spending reaches the limit. Failed answers count too. Article-search results are shown for that question. If an AI answer was attempted but unusable, a notice explains this
   • AI is used for staff reply drafts (item 11) only for requests where "The author may use AI to draft the reply" was ticked when sending. Even if ticked, the text of people under 16 and people using it from mainland China is not sent (item 11; the same as in 1.0)
6. "Ask a person" sends a short description and other details as a support request. It does not accept room restriction appeals; it directs you to the appeal form. If the author has marked themselves available, you enter a waiting room; once accepted, you exchange messages on the same screen, regardless of language. The current wait is 5 minutes. If the author does not accept, is unavailable, or chooses to handle it as a request, you go to the receipt-number page for a later reply. "Cancel" in the waiting room does not delete the request; it marks it resolved as cancelled by you. Chat requests do not give you a secret link.
   • For form requests, staff Discord receives only the receipt number, category and language, never the subject or message. For chat requests, only the author's Discord DM receives fixed text about arrival, waiting or additions, and a management-page link containing the internal request number. The receipt number, category, language, subject, message and search text are not sent. Live conversation messages do not trigger notices. If the email saying Discord was connected fails, the account number (starting with u_) is also sent so the author can notice and tell you manually.
   • Today, only the author reads and answers requests from chat and live conversations. Admins and support members cannot see them. Before giving staff access, we will change this document and announce it in advance. Availability uses a mark the author changes, not whether you or the author have a page open. The mark, waiting deadline and last message time are stored on the server.
7. Live and later replies are kept as the same request. For chat requests, you sign in to read your receipt-number page and "Your requests"; there is no secret link. Form requests can also be read through a secret link. When the author ends the chat, the request is marked resolved. If you choose to wait for a later reply, or neither side sends a message for 15 minutes, you move to the receipt-number page with the request unresolved. If you write nothing for 7 days after our reply, the request is marked resolved automatically (planned). For 48 hours after resolution, you can add text on the same page.
   • Only if you wrote an email address on the form, we also email that a reply has arrived. Chat has no reply-to field, so today neither receipt nor reply notices are emailed. Live messages trigger neither email nor Discord DMs, and these notices are not sent later after the chat ends. Emails contain neither your subject or message nor the reply text.
   • If you sent from the form while signed in and the account has an email, it will also receive the reply notice (planned; only one email if both addresses match). For Discord-only accounts, only the reply-to field is used. Today only the reply-to address receives it.
   • If you wrote a reply-to email address on the contact page, we also email that address to say we received the request (planned). It contains fixed text and the receipt number, and will include the team name (planned). The subject and message you wrote are not included. In case someone wrote another person's address, it also has the line "If this doesn't ring a bell, you can ignore this email." At most 3 receipt emails a day go to the same address (item 9).
   • The reply email shows the name of the person handling it and the name of the team decided by the request's category (9 teams; Article 2(4); planned). The handler's name is the display name of the staff account that wrote the reply, not a real name. The handler's icon and a stamp (pictures we made) are added too (all planned). The email opening also gives the team name, not your name (planned). This is staff information, not additional information about you.
   • Only support members assigned to the request's team may help with it (Article 2(4)). Staff may use reply templates, but a person checks the content before replying. At first, every reply from a support member is checked by the author before it reaches you (Article 11). Only the author posts replies to room restriction appeals. Chat requests are excluded from this support-member access; only the author reads and answers them.
   • Discord DM notices: if you are signed in with an account that has Discord connected, you can choose "Also tell me by Discord DM when there's a reply" (on the contact form, the receipt-number page and your account page). Only if you choose it, our bot (the bot StarPocket runs on Discord) sends a DM to your Discord when a reply arrives. If you choose it on your account page, replies to your "Join us" application are announced the same way (3.13). If you are under 16, please decide together with a parent or guardian (this is also written where you choose; Article 10). Live chat messages do not trigger DMs, including after the chat ends. Later replies after the chat ends follow these DM settings.
     • The DM contains only the fixed text "There's a reply", the receipt number, a link to where you can read it ("Your requests") and how to stop these notices. It never contains the reply text, the subject, your message or the handler's name (the same rule as email notices).
     • To send the DM, your Discord user ID (as the recipient) and the DM text are passed to Discord Inc. (United States) (Article 6). Where you choose also says "Sent to Discord Inc. (United States)" and links to this policy.
     • The DM only arrives if you are in our official Discord server and allow DMs from server members. Even if it does not arrive, you can read replies on the site. After 3 failed deliveries in a row, we send no DMs for 7 days from the last failure (so Discord doesn't see us as a nuisance). Your account page shows this; once you fix the setting, press "Resume from the next reply". Notices resume when the next reply arrives. Past notices are not sent again.
     • To avoid sending too many, DMs for the same request are at least 15 minutes apart, with a daily limit per person. Only temporary errors where the notice is known not to have been sent allow another attempt, at least 15 minutes later, up to 3 attempts for the same notice including the first. If a timeout or connection loss after sending leaves delivery uncertain, it is recorded as "delivery unknown" and the same notice is not resent. Attempts left in progress after a restart are also treated as delivery unknown. Attempts in progress and unknown deliveries count toward the 15-minute interval and attempt and quantity limits. Restarting does not reset the attempt count. Past notices from the paused period are not sent again either.
     • When Discord is unlinked (for example at your request through the contact in Article 14) or another Discord is linked, this choice is cleared. We send to the new Discord only if you choose again.
     • We keep records of sending attempts and DMs sent, not delivered, delivery unknown or not sent under these rules (times including the sending start, attempt number, which reply, request and account numbers, the result and a short reason code) for 90 days. The attempt number and sending start are recorded before communication. This record does not contain your Discord ID or the DM text (Article 5).
     • You can stop at any time on the receipt-number page or your account page. Even if your account-wide choice is off and only individual requests are on, you can press "Stop all Discord notices" on your account page. This clears individual choices too and stops all Discord notices, including those for "Join us" applications.
     • We only send these DMs if you choose them. We keep your choice (and, if you chose on your account page, when you chose it) as your consent to sending to Discord (Article 17(3)).
   • For a request you sent while signed in, the email has a way into the "Your requests" list (planned; opening it needs sign-in). If you sent it without signing in, the email gives only the receipt number. Either way, the secret link is never put in an email.
   • If someone else saw your secret link, "Renew secret link" on the receipt-number page makes the old link stop working (planned).
8. Chat records not handed to a person (your questions, search results, bot answers and notices such as AI unavailability, account number, agreement versions and times) are deleted from the database 24 hours after the start, not after the last use. During that time, the author cannot read them on the management screen. Deleting the account also deletes them. "Attach the conversation so far" in "Ask a person" starts ticked and can be unticked. Attached records are copied into the request, read by the author, and kept for the request's retention period (AI answers remain marked). Search records on the chat side are deleted immediately on handover, whether attached or not. Agreement and related records are deleted with the request. Other records contain no message text: daily usage totals, an AI cost ledger (no automatic deletion; unlinked when the chat is deleted), per-person AI counts (until the next UTC day), and chat usage counts (24 hours). After database deletion, nightly backups retain records for their own retention period (Article 5).
9. To prevent abuse, we use:
   • a bot check (Cloudflare Turnstile)
   • sending limits
   • To count sends, the IP address is mixed with a random secret that changes each time the server restarts, turned into a mark that cannot be reversed, and kept with the request and sign-in records for 1 day only. The IP address itself is not kept. After 1 day the mark is deleted from the server's database. It does stay in the server backups (the last row of Article 5) for as long as they are kept. Requests made from chat do not include this IP mark. Chat rate records instead keep the account number and time for 24 hours (Article 5).
   • To keep receipt emails (item 7) to 3 a day per address, the reply-to email address is mixed with a secret that exists only inside the server, turned into a mark that cannot be reversed, and kept for 1 day (planned). The mark cannot be turned back into the address. After 1 day it is deleted from the server's database. Like the IP mark, it stays in the server backups for as long as they are kept.
10. The server never opens URLs written in messages.
11. Staff reply drafts and translations (AI) (off today; we will announce it before we start using it)
    • Staff may have AI (Claude by Anthropic PBC, United States, used through its API) write drafts or translations of replies.
    • Something is sent to the AI only for requests where "The author may use AI to draft the reply" was ticked when sending, and only when a staff member presses the "Draft with AI" button. A request without the tick is not sent even if a staff member presses the button. Nothing is sent automatically. Even with the tick, the text of people under 16 and people using it from mainland China is not sent.
    • What is sent: the subject and text of that support request (the conversation so far), its category, language and the "Game info" field (app version, codes such as R-31)
    • Friend codes, email addresses, URLs and long numbers written in the text are hidden before it is sent (the same as 3.5, item 5).
    • What is not sent: email addresses, Discord names and IDs, friend codes (whether from the special field or written in the text), attachments (report zips, images), receipt numbers
    • A staff member always reads and edits the draft, and a staff member sends it. The AI never sends a reply by itself.
    • The AI is never allowed to decide room restrictions, shared bans, appeals, limits on the Services or erasing records. Staff always decide those.
    • How Anthropic handles it (not used for training, days until deletion) is the same as for the bot in item 3.
    • Chat has no tick for staff AI drafts, so requests sent from chat are not used for those drafts, regardless of age. Requests received by email or Discord ticket are not sent to AI until the basis for sending abroad (Article 6(3)) is settled.
12. Translating support requests (DeepL)
    • The author reads in Japanese. To read requests written in other languages, and to write replies in the sender's language, we may translate the text of requests received through the support site (https://support.starpocketgames.com) with the paid translation service of DeepL SE (Germany), DeepL API Pro. Requests that came by email or Discord ticket are not translated with this feature.
    • We translate only requests sent with "may be sent to DeepL for translation" ticked. The box starts unticked; you can send without it. Requests without the tick, including those received before the box existed, are not translated. The box is provided on the contact form and in chat's "Ask a person" (planned).
    • Next to the box we show that text goes to DeepL SE (Germany), that Germany (EU) is recognised as protecting personal information at a level similar to Japan, and that DeepL states the paid DeepL API Pro does not keep translated text or use it for training (planned; Article 6(3)).
    • Ticking keeps this Policy's version and time with that request. Text you add later may also be translated under that tick. You can untick it on the receipt-number page; after that, no translation takes place. You cannot tick it again for the same request (planned).
    • Text is sent only when the author, or a staff member who can read that request, presses "Translate". Nothing is sent automatically. Support members can translate only requests for the teams they handle (for Room Access Team staff, this includes the room restriction appeals they can read; Article 2(4)).
    • What is sent: only the text you wrote, or the text of a reply draft written by staff, and the languages to translate between. Before sending, parts that look like contact details or numbers are hidden: email addresses, phone numbers, URLs, IP addresses, friend codes, Discord and other IDs, ticket numbers and so on. Parts opened with "Reveal" on the staff screen are still sent hidden (Article 11). Anything in the text that cannot be hidden, such as names, is sent as it is. The reply email address, the account and attachments are not sent. The same masking applies when the author presses the button.
    • The translation is only shown on screen and is not kept on our servers. If staff check it, put it into a reply draft and send it as a reply, it is kept like any other reply.
    • The only record kept is who translated how many characters of which request (Article 5). Each person can translate up to 20,000 characters a day.
    • Only the paid DeepL API Pro is used; "Translate" does not work with an API Free key. DeepL states that with the paid API Pro, text it receives is deleted once translated and is not used for training or to improve its services (Privacy Policy, API plan information).
    • This is separate from the AI (Anthropic) in item 11. Translating "Join us" applications is covered in 3.13. It is also separate from the translation for the Steam-copy program at the end of this section.
    • Replies may also use Japanese, Simplified Chinese and English templates: choosing one in Japanese displays the recipient's language. A person checks it before sending.

Applying for a Steam copy (for people who want to host)

1. We plan to give up to 10 Steam copies of Among Us to people who want to host. We will announce the day requests open in a notice on the site (planned). Requests are open for 30 days from that day (they close sooner if all 10 are decided). This is not a lottery: the author reads the requests and decides. Donating, following and so on are not conditions, and donors get no priority.
2. What we receive: what you send on the contact page with the category "Other" and the subject "Steam copy request". The answers are letters: where you have Among Us now, roughly when and with whom you plan to host, whether you have a Steam account, whether you could tell us once what you thought after playing, your age band (16-17 / 18 or over), your Steam store country or region, where you heard about PocketRoles, and whether you agree to this explanation. Only people the author would like to choose are asked, on their receipt-number page, for their Steam friend code. After becoming friends, the author looks at your Steam profile for when the account was created and how many games it has (no copies are kept). We don't need your real name, address, phone number, school, social media or WeChat IDs, or passwords.
3. Who reads it: only the author and the contact page's admins. Until requests can be separated by subject, the general support team is not assigned to support members (Article 2(4)).
4. Purposes (only these): (1) choosing who receives a copy; (2) becoming Steam friends, sending the gift and checking it was accepted; (3) making sure nobody gets two copies; (4) receiving your impressions or bug reports after playing (a request, not a condition); (5) counting where people heard about PocketRoles (the tally keeps only the numbers).
5. What we don't do: no AI decides who is chosen. Requests aren't used for AI reply drafts, even if "The author may use AI to draft the reply" is ticked. We don't look up your other support requests, Discord, GitHub or video-site accounts to combine them with your request. Nothing is sold or passed on.
6. Translation: the author reads only Japanese. Anything written in another language may be run through machine translation by DeepL (DeepL SE, a company in Cologne, Germany) so the author can read it. Only that text is sent to DeepL, and the receipt number, Steam names and friend codes are removed first. Germany is in the EU, which Japan's Personal Information Protection Commission recognises as having a system of the same standard as Japan's. This program uses paid DeepL Pro. DeepL states that it deletes text after translation and does not use it for training or service improvement. For this Steam-copy program, DeepL Pro is used only during the 30-day application window, separately from support translation in item 12.
7. Steam: friend requests and gifts go through Steam (Valve Corporation, USA). The only thing the author picks on Steam is your account. Your request isn't given to Valve.
8. These purposes apply only to requests sent after reading and agreeing to this explanation on the guide page. Information from people who did not apply (other support requests and so on) is never used for them.
9. How long it is kept: the request and the messages on your receipt-number page stay on the author's home server in Japan and are deleted automatically 30 days after we tell you the result and mark it resolved. The same applies to people who weren't chosen. Within 7 days of the close, every request still open gets a reply and is marked resolved. The author removes the Steam friendship once the gift has been accepted. The author's Steam gift history and purchase records (including the purchase confirmation email) keep who received a gift, as part of how Steam works, and the author cannot delete them. The author keeps these purchase records for tax. The new-request notice sent to the author's Discord contains only the receipt number, category and language.
10. Age: we can't accept requests from people under 16. Steam accounts are only for people 13 and over, and Article 5 of the Terms says that when consent is needed for the personal information of someone under 16, we get a parent's or guardian's consent. This programme has no way to check that. If you are 16 or 17, please tell a parent or guardian before applying.
11. Cancelling: write "cancel" on your receipt-number page at any time. We mark it resolved straight away, and it is deleted 30 days later.

3.2 StarPocket Account

The contact form needs no account; support chat requires signing in with a StarPocket account (Terms of Use Article 8).

• Your account is not linked to you in the game. Your Among Us account, friend code, PUID, in-game name and Aegis records are not put in the account.
• When you join a friend's room, you see each other's in-game names through Among Us itself; StarPocket Friends does not link those names to accounts (3.12; planned).
• We do not use accounts to show ads or give information to other companies.
• The list for adding staff (Article 2(4)) includes only people who applied through "Join us". People who have signed in but have not applied are not listed. Only the author sees the list: display name, sign-in method (Discord name and last 4 ID digits, or a partly hidden email address), and last sign-in date. These are used for applicant selection and staff registration (3.13; Article 4(10)). Suspended accounts and existing staff are not listed. A person becomes staff only when the author adds them or approves their application.

3.3 Report zips and "One player's evidence" zips

1. Pressing "Make a report zip" in the launcher or the Client makes a zip on the host PC's desktop. It is never sent automatically. You decide whether to send it.
2. Contents
   • Game logs, launcher records, PC and game versions
   • Aegis evidence records from the last 90 days (the newest 200, up to 5 MB; older records go in a "One player's evidence" zip, item 5), and, for records older than 30 days, the two game-log lines that back each one (in place of the deleted log) (3.10)
3. Left out or masked
   • Left out: API keys, Discord webhooks, settings files, passwords
   • Masked: PUIDs, friend codes, the start of hashes, erase codes (in logs), places containing the Windows user name
   • Evidence records contain the player's name, the hash of their PUID and their erase code (not the friend code or its hash).
   • The code is left unmasked so the author can handle erase requests. Matching it against the erase list and erasing that person's records kept by the author and admins is planned (today's ban console does not match against the list yet; 3.5, item 4).
4. A zip also contains the names of other people who were in the room, and the codes of the people in its evidence records. Send it by email; do not post it in public places.
5. "One player's evidence" (for appeals): when the host enters a person's erase code, friend code or evidence number (AEG-…) under "One player's evidence" in the launcher (in the Client, in the report area), a small zip with only that person's records is made on the desktop. The author asks the host to make it when looking into an appeal, and the host sends it to the author by email. It is never sent automatically. A host can also make one at any time, unasked, for any player whose records are on their PC (what goes in is what that PC already holds). Passing it to anyone but the author is forbidden by the Play Rules, Article 7. When you appeal, the author receives every record of you on that host's PC (not only the restriction you appealed, but also records of a removal alone).
   • Contents: that person's evidence records still on the host's PC (of records older than 90 days, only the evidence of a restriction still in effect), the game-log lines that back them, and the PC and game versions (the same system.txt and so on as in a report zip, so the ban console can tell zips from the same PC apart). Records an erase request covers (already emptied, or listed on the erase list) are left out.
   • Other people's records and logs are not included (the detection text of that person's record may still name other players of the same match).
   • The erase code in the records is what says which records an appeal is about: the author compares it with the code the appealing person saw with /cmd id. That code does not prove who sent the appeal (Article 12(5): it is not a password; in an unregistered room everyone sees it, and it is in hosts' records and report zips, so other people may know it). So a matching code alone never makes the author tell anything from the records (the reason, dates, room codes, other people's names). To check further, the author uses the extra questions of Article 12(2) (their answers are exactly what this zip holds, so when a copy of the zip is in someone else's hands, matching answers are not taken as proof either). Neither the friend code nor its hash is included, also when the host searched by friend code (a friend code's hash can be turned back by trying them all, so including it would not protect anything).
   • Masking is the same as for report zips. Like report zips, the launcher deletes it automatically after 30 days.
   • Send this zip to the author only (Play Rules, Article 7(1)). It holds that person's erase code and the hash of their PUID, which the restriction list uses.

3.4 Central lists (lists anyone can read)

They are in the definitions file (public on GitHub, signed). Details are in Article 8.

• Names and friend codes are not on them.

3.5 Ban console (the author's and admins' PCs)

1. Evidence records from report zips and "One player's evidence" zips (3.3) sent to us are imported into the ban console on the author's and admins' PCs.
   • Imported evidence records contain the player's name, the hash of their PUID and their erase code (3.3). So the author and admins also receive the codes of other people, not only of the person who sent the zip.
   • The codes are used to match against the erase list, so the records of people who asked for erasure are erased (today's ban console does not match them yet; see item 4).
2. The action record (audit.log) keeps:
   • time, action, evidence number, name, rule, reason, who proposed it
   • Friend codes and PUIDs are not kept.
3. Why: to decide shared bans and appeals correctly and in a way that can be checked later.
   • When a shared ban is based only on records sent by other hosts, these rules apply (Play Rules, Article 9(2)).
     • A "Certain" detection whose record matches that host's game log: one host's record is enough, but only for the first level (up to 30 days); at most 2 per 30 days from one and the same host
     • Anything else (a "Repeat" detection, chat, hurtful words, harassment, or a restriction the host decided by watching): records from 2 or more different hosts received within 30 days, or a report from a trusted admin; or the author writes down the reason and keeps it in audit.log
     • The three lines here count different things. The hosts: 2 or more different hosts (this may go up as more hosts join). The bans: at most 2 per 30 days from one and the same host. The mistakes: 3 times within 30 days, on the next line.
     • If a host's reports are found to be wrong on appeal 3 times within 30 days, we stop accepting reports from that host (mistakes of "Certain" detections do not count; Play Rules, Article 7(3); Terms of Use Article 13; S-11)
   • For this, when the author lifts a shared ban as a mistake, a record of the hosts who sent the original reports is kept (the report-host record reporters.txt, and lines in the action record audit.log). It holds the host's name (the name the author gave the report zip when importing it), a PC mark (a short mark made from files inside the zip, to tell zips sent from the same PC), the date, the evidence number and which lift it was. It is used only for counting. Lines in reporters.txt are deleted after 30 days. Lines in audit.log are handled like the action record in item 4.
4. Today, imported records and the action record have no expiry, and they are not yet matched against the erase list. We plan the following, and will update this document on the day it is built (planned):
   • delete them 90 days after the case ends (planned)
   • erase records for codes on the erase list (planned)
   • make names in the action record maskable (planned)
5. Reply drafts (AI): only when the author, unlocked as the author in the ban console, presses "Draft with AI", the reply's kind, language, ban number, rule category, dates and template are sent to Anthropic PBC (United States) to make a draft.
   • The addressee's and the staff member's names are replaced by placeholders (NAME_1, STAFF_1), and so is a shared ban line's number (the first 8 hex digits of a hash; BANID_1); they are put back into the returned draft on the author's PC.
   • PUIDs, friend codes, hashes and evidence files are not sent.
   • The box for pasting the support request's text is not shown until the basis for sending it abroad (Article 6(3)) is settled. Once it is used, friend codes (their name part too), e-mail addresses, URLs, @names and long numbers are hidden and the addressee's, the recorded and the staff member's names become placeholders before it is sent; anything else in the text that cannot be hidden, such as other people's names, is sent as written. Before it first goes out, the author sees exactly what is sent. Text from people under 16 and from people in mainland China is not pasted (3.1, item 5). Text of requests that came by e-mail or Discord ticket is not pasted until the basis is settled.
   • The draft is checked on the author's PC (a draft that does not keep the template's result paragraphs word for word, has words against the result, has a number, date, e-mail address, URL or the like that the template does not have, or leaves out the template's number or dates is not used), and a person sends the reply. The ban console never sends a reply.
   • Anthropic's handling (no training, deletion period) is the same as in 3.1, item 3.

3.6 Websites

1. The official site (starpocketgames.com) and the PocketRoles site (pocketroles.starpocketgames.com) are both on Cloudflare Pages (Cloudflare, Inc., United States). The support site and the account pages are served by the home server (3.8) through Cloudflare.
   • Cloudflare states that it records visitors' IP addresses for security. So does GitHub, where downloads and the definitions file are kept.
   • Text uses the fonts already on your device (computer or phone). Nothing is loaded from other sites or companies, fonts included (no Google Fonts). The exception is the bot check (Cloudflare Turnstile), loaded from Cloudflare on the contact page, account pages and support chat (planned; item 4).
2. The site stores only the following in your browser:
   • the language you chose (on the support site, opening an article page is enough for the language to be remembered in a cookie for 1 year)
   • light or dark display (official site)
   • what the contact page and the account pages need to work (Article 16(2))
3. We use no ads, no analytics and no social media buttons.
4. On the contact page, account pages and support chat (planned), Cloudflare Turnstile runs as a bot check (3.1, item 9). Client sign-in uses request limits instead of Turnstile (planned).

3.7 Discord server

1. The Discord server runs on the service of Discord Inc. (United States). Discord's privacy policy also applies.
2. What we see:
   • names, messages and roles in the server
   • what is written in tickets
3. Ticket transcripts are set not to be kept. Appeal tickets are deleted when decided.
4. StarPocket Client shows only Discord's "online now" count. It does not collect members' names. The request that gets the count is in 3.9.

3.8 Home server

• A room is listed only when the host chose "Agree" in the settings.

3.9 What the Software sends from the host's PC

The table lists traffic from the host's PC. Traffic addressed to our server reaches us; traffic sent directly to another company does not.

• As with any connection, the other side's server receives the host's IP address.
• Checking your own shared ban (planned): PocketRoles in the game uses the definitions file it received to check, inside this PC, whether the Among Us account signed in is on the shared-ban list (3.11). Nothing new is sent for this.
  • Also checking with our server (by receiving the whole list) is not done now. If we start it, we will first change this policy and ask for consent again in StarPocket Client (Article 17(3)). The PC of anyone who has not agreed does not make these requests.
  • In the planned form, nothing about your account would be sent: PocketRoles would receive the whole list from our server and compare it inside this PC. As with any connection, the IP address would reach our server and Cloudflare.
  • We will not use a form that asks "does this account have a shared ban?" (sending the first 5 characters of the hash of the PUID and a number that changes every time). Because the list's hashes are public, the server could tell who is asking when someone on the list asks.
• How chat translation is decided
  • In StarPocket Client, the first "Terms of Use and Privacy Policy" screen has a "Use chat translation" checkbox. It starts unticked. Unless you tick it, nothing is sent (someone who upgraded from v0.5.4 or earlier may keep the old setting until the mod is reinstalled or updated with StarPocket Client (v1.1.2 or later); see below).
  • You can change it later in settings, under "PocketRoles → Chat translation".
  • A fresh install defaults to "off" from v0.5.5 on (Bind("Translate", "Enabled", false)). But for someone who upgraded from v0.5.4 or earlier and never changed this setting, the config file may still say "on". BepInEx does not overwrite a value that is already in the file, and the file cannot tell "on because the host chose it" from "on because that was the default". v0.5.5 tells that host once and hands them /opt upgrade off, but changes no value. When the mod is reinstalled or updated with StarPocket Client (v1.1.2 or later), the answer given on the first screen is written to the config file.
• How automatic reporting is decided
  • On the first screen of StarPocket Client, under chat translation, there is an "Automatically report players removed for cheating to Innersloth" checkbox. It starts unticked. Only if you tick it does anyone get reported automatically (players are still removed from the room either way, as before).
  • You can change it later in settings, under "PocketRoles → Aegis".
  • However PocketRoles is installed, the default in v0.5.5 is "off" (Bind("AntiCheat", "AutoReport", false)). The key [AntiCheat] AutoReport existed in no build up to v0.5.4, so an upgrader's config file does not hold it either: every way of installing starts off.
• People who join have not agreed to anything. When translation is on, the welcome line says "Auto-translation is on" (not if the host changed or turned off the welcome line).

3.10 What the Software keeps on the host's PC

• If [Diagnostics] WireLog (off by default) is turned on, raw network content goes into the log. Turn it on only while investigating.
• The host handles the records on the host's PC. We cannot see records on other hosts' PCs.

3.11 Aegis scans

1. Aegis checks only these things on the host's PC:
   • names and contents (hashes) of files in the Among Us and mod folders
   • the names and the program files of running apps (from v0.5.5)
     • To find renamed cheats, the program file (.exe) is checked too. What is checked: a mark made from its contents (SHA-256), the product information written in the file, and the name of whoever signed it. These are compared with the list of tools that can be used for cheating, inside this PC only.
     • Whether something is Microsoft's is decided by whether its certificate chains to a Microsoft root, not by the name of the signer.
     • Only the exe's location is asked of Windows. An app's memory, windows and screen are never looked at.
     • Only apps in your own Windows session are checked (not Windows services, and not other users' apps).
     • The result is not sent anywhere.
   • names of loaded drivers
   • Windows protection settings (Secure Boot, TPM, test mode and so on)
   • Inside the game (PocketRoles' self-check), it also checks the names, locations and signatures of DLLs loaded into the game (compared with cheat names; names of ones loaded from Windows folders are compared too), and whether the game's code (GameAssembly.dll in memory) has been changed. It only looks inside the game itself.
   • PocketRoles in the game (planned) turns the PUID and friend code of the Among Us account signed in into hashes of the same form as the shared-ban list, and compares them with the list. The PUID and friend code are only used in memory; they are not written down or sent.
   • PocketRoles in the game, the tray Aegis, today's launcher and StarPocket Client (all planned) will read the number of the Steam account signed in now from Windows settings (the registry), turn it into the short mark in 3.10 and the key that opens the line, and use it only to tell which line of access-status.txt to use. This is so that, on a PC shared with family, the screens don't show another person's ban or code. The number itself is not written down or sent.
2. It does not look at photos, documents, other apps' screens, key presses, browsers or passwords.
3. Results of the PC scan are never sent anywhere.
   • Even when you press "Contact support" on the "You can't play yet" screen, only the code, app version and language are filled in at first. Names of what was found are not added (you can write them yourself if you want).
   • Reporting a player removed for a "Certain" cheat to Innersloth (3.9) is a decision about what happened in the room, not a result of the PC scan.
   • The result of checking your own shared ban is not sent anywhere either (3.9).
4. When scans happen
   • Today's launcher: when it opens; every 30 seconds while the tray Aegis is running (app names and program files; newly started apps are noticed every 2 seconds; it only notifies and writes to events.log, it never stops anything); and when Play is pressed
   • StarPocket Client (planned): when it opens, when game files change, when a newer definitions file arrives, every 30 seconds while the window is visible (app names and program files), when "Check again" is pressed, and when Play is pressed
   • PocketRoles (in the game): at start, every 60 seconds, and when menus open (only inside the game itself)
   • Checking your own account (PocketRoles; planned): while signed in, it looks every 2 seconds for a change of account. It compares again when the account changes, when a newer definitions file arrives, when a ban ends, and before a room is created
5. Aegis installs no driver. It does not restart the PC or change settings.

3.12 StarPocket Friends (planned)

This feature is for people signed in to StarPocket Client (Terms Article 8(10)). It is not in today's Client. A Client that is not signed in does none of the communication or storage described here.

• Only friends you approved see your display name, avatar, status and shared room. There is no public URL or name search.
• We cannot prevent people who see your status from recording it on their PC or in screenshots. Add only people you really know.
• Uploaded images go only to approved friends in the same age band. Photos showing a real person's face, including your own, are not allowed. If reports accumulate quickly, the image is hidden automatically before human review, and the author checks it (Terms Article 13(1)). Fingerprints of images the author removes are kept for 1 year to block reupload. No AI inspects image content.
• People under 13 cannot use Friends. Ages 13-15 need confirmation through a parent's or guardian's email, cannot upload images and see supplied pictures instead of friends' uploads. Ages 16-17 check "I will use this with my parent or guardian" and may upload images, shown only to friends aged 16-17. Images from people aged 18 or over are shown only to friends aged 18 or over. Friends in a different band see a supplied picture instead.
• In a friend's room you see each other's in-game names through Among Us itself. StarPocket Friends does not use, send or receive Among Us's own friends, friend codes, PUIDs or in-game names, and does not contact Innersloth or send it Friends information.
• What the Client sends and keeps on the PC is in 3.9 and 3.10; retention is summarized in Article 5 and deletion in Article 12.

3.13 Applications to "Join us" (contributor recruitment)

These are applications to the recruitment of contributors who help as hosts, with support, with translation or with development (Terms of Use Article 6(4)). This is separate from the Steam-copy program (3.1). You apply by signing in to the support site (https://support.starpocketgames.com) with email or Discord. Every role requires applicants to be 16 or older, and applicants aged 16 or 17 need a parent or guardian's consent. Support members, who read the content of support requests, must live in Japan. Host, translation and development contributors are not shown support requests. Helping is unpaid; no money is paid. If we decide on a non-cash thank-you, we will tell you.

• Who reads it: only the author reads applications, your replies and the author's notes. Admins and support members are not shown them. This is a separate channel from the 9 support teams (Article 2(4)).
• Notices to the author: when an application or a reply arrives, only a fixed message such as "There is an application" and the URL of the admin page are sent to the author's Discord DMs. The receipt number, content and names are not sent.
• Discord notices to you: if you chose "Also tell me by Discord DM when there is a reply" on your account page, replies to your application also trigger a DM under the same rules as 3.1 item 7. It contains only fixed text, the receipt number, a link to read it and how to stop; no application content or reply text. Nothing is sent if you did not choose it.
• Selection: the author reads the application, decides whether to invite you to an interview or not to go ahead, and decides after the interview whether to approve it. The quiz result alone never decides it. Applications are not used for AI reply drafts (3.1, item 11).
• Interviews: text interviews take place in the reply box of your application. If you choose a call, the interview is a Discord voice call. It is not recorded. We do not ask for your real name, address, school or a photo of your face. To confirm it is you, we may ask you to write your receipt number and a phrase given in the interview as a reply to your application. We never ask for passwords or sign-in codes.
• If you are 16 or 17: before approval we check a parent or guardian's consent. Ask them to read what is involved and give consent, then tell us in a reply to your application, and we record the date we confirmed it. We do not ask for the parent's or guardian's real name or address.
• After approval: the author sends the contributor pledge. The pledge has 16 items, and the current version is 2026-10-04. The full pledge is also on the pledge page of the support site (https://support.starpocketgames.com/en/join/pledge). When you reply "I agree", we record the date you agreed and the pledge version (Terms of Use Article 6(4)). Support members also agree to the staff pledge. People approved for support read support requests as support members within the limits in Article 2(4) and Article 11. Before reading any, they first agree to the staff pledge and complete two-step verification with an authenticator app (Article 11).
• Translation: the author reads in Japanese. To read applications written in other languages, and to write replies in the applicant's language, only the author may translate the application text, your replies and the author's reply drafts with DeepL API Pro from DeepL SE (Germany). We ask you to agree to this on the application page, and keep the version of this policy you agreed to with the application. Applications with no agreed version kept (those sent before this is added to the application page) are not translated. It will be added to the application page (planned). Hiding parts that look like contact details or numbers before sending, not keeping translations, the records kept, and how DeepL handles the text are the same as in 3.1, item 12.
• How long we keep it (also summarised in Article 5)
  • An application with no decision yet is withdrawn automatically 90 days after the last activity (the application, a change of its status, or a reply from either side). The author's notes and drafts do not extend this.
  • Applications that are not selected or are withdrawn (including automatic withdrawal) are deleted 90 days after the decision.
  • The applications and records of approved people are kept while they are contributors or support members and for 1 year after they stop.
  • The number of wrong quiz answers if you stopped without applying is deleted 90 days after your last answer.
  • While the author has decided to keep something for an investigation, such as into a leak, deletion waits.
  • After deletion, it stays in server backups (the last row of Article 5) for the backup period.
• Applying again: after an application is not selected or is withdrawn (including automatic withdrawal), you cannot apply again for 30 days. While you have an application in progress, and while you are a contributor or support member, you cannot send a new application.
• To withdraw: if you want to withdraw your application or stop being a contributor or support member, sign in and reply to your application.
• We use this information only for selection, contact, registering contributors and support members, the record of agreeing to the pledge, and limiting the number of applications. We do not sell it or give it to others (Article 7).

Article 4 (Summary of purposes)

We use information about individuals only for:

1. answering support requests;
2. deciding and reviewing Aegis decisions, room restrictions, shared bans and appeals correctly;
3. erasing records and handling other requests (Article 12);
4. running accounts and keeping sign-in safe;
5. fixing bugs and improving the Software and Services (when improving the FAQ, in a form where no individual can be identified);
6. preventing abuse, attacks and impersonation;
7. telling people about changes to the terms and this policy;
8. doing what the law requires.
9. showing the people you choose what you choose to share through StarPocket Friends (3.12; planned).
10. selecting and contacting applicants to contributor recruitment ("Join us"), and registering contributors and support members (3.13). Display names, sign-in methods and last sign-in dates viewed by the author in the add-staff list are used only for selecting and registering these applicants (3.2). Non-applicants' information is not used for this list.

Article 5 (How long we keep things)

• How long things stay on a host's PC is in 3.10: Aegis evidence records (and the 2 log lines backing each) 90 days; logs, report zips, copies of sent reports and the like 30 days. These are records on the host's PC, but we set these defaults.
• About GitHub's change history: the central lists are managed on GitHub. Even after a line is removed from a list, the old line stays in GitHub's change history. Only hashes and codes are there; no names.

Article 6 (Companies we use, and sending information abroad)

1. We use the services of these companies. For each company we show the company's country, the country of the servers that handle the data, the legal basis for sending it abroad, and the measures the company takes (Act on the Protection of Personal Information, Article 28; Enforcement Rules, Article 17(2); the Personal Information Protection Commission's Q&A 10-24 and 10-25).

2. Where things sent directly from the host's PC (3.9) go
   • Google LLC (United States) and DeepL SE (Germany): translation
   • Innersloth LLC (United States): official reports
   • Discord Inc. (United States): the count in the Client's community panel (planned)
   • These are sent by the host from their own PC.
3. About sending information abroad (Act on the Protection of Personal Information, Article 28)
   1. When we have a foreign company handle your information, for each company we rely on one of the following (the "Basis" column in the table in item 1):
      • your consent
      • a system meeting the standards: an agreement with the company (such as a DPA), or APEC CBPR certification (Enforcement Rules, Article 16)
      • only renting servers in a form where the company does not handle the data (the cloud exception; Q&A 7-53)
   2. When we rely on consent, before you start we show the following on screen and ask for your consent (Enforcement Rules, Article 17(2)): For the support-chat bot, the consent screen shows the destination country and company, what is sent and how it is masked; the country's system, company measures and retention periods are explained in this Policy linked from that screen.
      • the country and the company it is sent to
      • that country's personal information system
      • the measures that company takes (including any points where they fall short of the OECD's 8 principles)
   3. When we rely on a system meeting the standards, we tell you on request what that system is and how we keep checking it (Article 28(3)).
   4. Countries' systems
      • The United States has no national personal information law like Japan's. There are state laws (such as California's). For details, see the Personal Information Protection Commission's research page: https://www.ppc.go.jp/enforcement/infoprovision/laws/offshore_report_america/
      • Germany (EU) is recognised by Japan as protecting personal information at a level similar to Japan.
      • Where the servers' country cannot be identified, the table in item 1 says so and why.
4. The home server is in Japan (its location is not published).

Article 7 (Giving information to others)

1. We do not sell information about individuals.
2. We do not give your information to others without your consent, except:
   1. when the law requires it;
   2. when it is needed to protect someone's life, body or property and it is hard to get the person's consent;
   3. when we need to cooperate with the work of national or local government;
   4. when the running of the Services is handed over to another person or group (Terms of Use Article 27; Act on the Protection of Personal Information Article 27(5)(ii)). We tell you at least 30 days before the handover date, and anyone who wants to leave can delete their information before that date (Terms of Use Article 27(3) and 27(5)).
   5. when you use StarPocket Friends (3.12; planned) to show approved friends your display name, avatar (including your uploaded image), online status and selected room details and code. You choose the recipients and settings; age limits also apply.
3. Publishing the central lists is described in Article 8.
4. Official reports to Innersloth are sent by PocketRoles on the host's PC (3.9). They are not sent from us.

Article 8 (Lists we publish)

1. The shared-ban list, the erase list and the lift list are put in the definitions file and can be read by anyone on GitHub. This is so they reach every host's PC.
2. Only these are on them:
   • Shared-ban list: PUID hash (a value that cannot be turned back into the original number), level, end date, short reason word
   • Erase list: erase codes and dates
   • Lift list: erase codes, and the evidence number and date of the record we checked
   • Names, friend codes and IP addresses are not on them.
3. Even so, please note:
   1. Hosts using PocketRoles can make the PUID hash of people who join. So a host can find out whether someone who joined is on the shared-ban list. This is how shared bans work.
   2. Anyone who knows your code can see that the code is on the erase list.
   3. If you type /cmd id in an unregistered room, everyone in the room sees the code. If you can, type it in a registered room.
   4. The lift list holds only erase codes and evidence numbers; no names or friend codes. However, the code is made from your PUID, so the host of any room you have joined (and, if you typed /cmd id in an unregistered room, the people who were there) can find out that you are on the lift list, that is, that you once had an automatic restriction. The list also stays in GitHub's history (Article 5). If you do not want to be listed, say so when you appeal. In that case, restrictions in other hosts' rooms are not lifted.
   5. PocketRoles also uses the same list to check whether your own account signed in on that PC is on it (planned; only inside that PC; 3.11).
4. The author can sometimes connect a value on a list with a person, through support messages or report zips. So publishing the lists may count as "giving information to others" under the law. The lists are already published. Whether this applies has not been settled yet. We will check it, and if it applies, we will change how the lists are published and update this document.

Article 9 (For people who only join a room)

1. We install nothing and check nothing on your PC or phone. You have not agreed to anything.
2. The host's PC may keep the following (3.10):
   • name, device type, room code, join and leave times
   • Aegis detection numbers
   • an evidence record, if you were removed (90 days; 3.10)
3. PUIDs are kept as hashes that cannot be turned back. A friend code's hash can sometimes be turned back by trying them all, so it is treated like the friend code itself (how long it is kept is in 3.10). The exception is lists the host writes by hand (Banlist.txt and others), which hold the PUID or friend code as it is.
4. IP addresses are not kept. In rooms on the official servers, even the host does not receive your IP address.
5. In rooms where chat translation is on, your chat text is sent to Google or DeepL for translation. The welcome line says "Auto-translation is on" (not if the host changed or turned off the welcome line).
6. If you are removed for a "Certain" cheat:
   • an official report is sent to Innersloth (unless the host turned automatic reporting off);
   • everyone in the room sees your name and the reason.
   • during a match in an unregistered room, if the cheat changed the match (for example, a kill landed), the match may be ended for everyone (at most once per match and 3 times an hour; Play Rules, Article 8(2)(4)). Aegis's message to everyone then does not show your name (Among Us's own notices may still show it). No new information is collected or sent to stop the match.
7. If the host of the room you are in gets a shared ban while the room is open, that host's PocketRoles leaves the room (planned; not in today's PocketRoles yet; Play Rules, Article 9(6)).
   • When no match is being played, it leaves at once. During a match, if the reason is one of the certain cheat detections (killrole, ventrole, abilityrole or taskimpostor in Play Rules, Article 9(5)), it leaves at once even mid-match; for any other reason (cheat, chat, harass, name, other: cheating the author decided from the records, chat, bothering others and so on), it leaves after that match ends. A reason word we do not know also waits for the match to end.
   • The people in the room are not told about the ban or its reason (in the lobby it only says "The host is leaving this room"). When the host leaves, Among Us's own "… left the game" notice still appears.
   • No new information is collected or sent for this.
8. To have your records erased, see Article 12. You do not need to ask the host.
9. How these records are handled is up to the host on their own PC. We have set the defaults to "delete automatically (Aegis evidence records after 90 days, logs and the like after 30 days)" and "do not keep IP addresses".
10. Innersloth's Terms of Use ask users not to collect or store other people's personal information from the game without their clear permission (section 11(c)). We will check how Aegis keeping records on host PCs relates to this.

Article 10 (Children's information)

1. Many people who use our Services are children. So we do the following.
   1. We collect as little as possible. The contact form works without an account or email address, and replies can be read through a secret link. Support chat requires signing in with a StarPocket account.
   2. When consent is needed for information about someone under 16, we get it from a parent or guardian.
   3. People under 13 cannot use Discord. Please use email, the contact form or support chat (planned; chat requires signing in with a StarPocket account).
   4. Support chat (planned) uses the age band answered on the account page (3.2), without asking for a birth year in chat. If it is not "18 or over", including unanswered ages:
      • the screen asks people under 18 to use it with a parent or guardian. It also shows this to people who have not answered. Confirming this guidance is not a condition for using chat;
      • article search and the author answer, without the bot. Requests sent from chat are not used for staff AI drafts regardless of age;
      • chat has no email-address field, regardless of age.
   5. People under 18 must make accounts with a parent or guardian (Terms Article 5(1)). The account-creation confirmation screen is planned and not yet present; the account age field and an optional "I will use this with my parent or guardian" tick for people under 18 are not yet in production. They are planned to be introduced together with support chat. You choose a birth year on the account page to determine bot eligibility and before using StarPocket Friends (planned); only the band is kept. Under 13 cannot use Friends. Ages 13–15 cannot upload images and see supplied pictures instead of friends' uploads; images uploaded by ages 16–17 are visible only to friends aged 16–17 (all planned).
   6. Parents and guardians can ask to check or delete their child's support requests, account and records (Article 12).
   7. Where something still relies on consent for someone under 16 (such as sending information abroad), we take steps to check with a parent or guardian (for example, a confirmation link sent to the parent's or guardian's email; once confirmed, that email address is deleted). As far as we can, we arrange things on bases that do not rely on consent (such as a system meeting the standards in Article 6(3)), so that a child's consent is not needed. For StarPocket Friends, ages 13-15 must complete this check before use: a one-use link to the parent's or guardian's email expires after 24 hours; the email is deleted on confirmation or expiry and only the confirmation date remains. For StarPocket Friends, ages 16-17 only check that they will use it with a parent or guardian (planned). "Join us" applications are covered separately in item 8. Reply DMs on Discord (3.1 item 7) are sent only if you choose them. The choice asks people under 16 to decide with a parent or guardian (age is not asked).
   8. Only people aged 16 or older can apply to the contributor recruitment ("Join us"; 3.13). Applicants aged 16 or 17 need a parent or guardian's consent. Before approval, the author confirms through the applicant's reply that a parent or guardian has read what is involved and agreed, and records the date. We do not ask for the parent's or guardian's real name or address.
2. People under 16 are expected to become able to ask us to stop using their information even when no law was broken (a 2026 amendment of the law, expected to start by 2028). When it starts, we will update this article.
3. Under Chinese law, information about children under 14 is especially sensitive information.
4. The same amendment is expected to require that minors' information be handled putting what is best for them (their best interests) first (Article 40-2). We handle it that way from now on.

Article 11 (What we do to keep information safe)

1. Rules and structure
   • A responsible person is set (the author).
   • The author, designated admins and support members chosen by the author can read ordinary support requests (Article 2(4)). Only the author reads "Join us" applications and the author's notes; admins do not see them (3.13). Support members read only their assigned teams' requests, excluding Steam-copy and author-only "Join us" applications. Room restriction appeals are shown only if they say the restriction was a mistake, only to staff assigned to the Room Access Team (including admins), and only if they meet the time and viewing notice version conditions in Article 2(4). An unset, empty or invalid access start time, or an old, missing or unknown version, means author-only access. Requests to erase records and reports about a host are read only by the author. Staff can write only assessments and reply drafts; only the author posts replies and changes status or language. The author's notes are not shown to staff. Support members see the signed-in sender's display name for greetings, but not reply email addresses or account IDs, and cannot access room, user or restriction management screens. These limits apply at every server entry point, not only on screen. However, the method for keeping Steam-copy applications from support members is still undecided, as stated above. Requests received from support chat and live conversations are read only by the author today, never by admins or support members.
   • We record which staff member did what and when.
   • Email addresses, phone numbers, URLs, IP addresses, account numbers and friend codes in message text will initially be masked; only a handler allowed to read the request can press "Reveal". The dedicated reply-address and account-ID fields remain hidden from support members. We record who revealed information, when and for which request.
   • For staff other than the author, the staff member's name and the current time are watermarked throughout the management pages. We record who opened which request and when; unusually many views in a short time notify the author and stop that member's viewing. View and reveal records are kept for 1 year.
   • Support members have no export, bulk-copy or print view. Screenshots and screen recordings cannot be completely prevented. Article 13 applies if information leaks.
2. People
   • Admins promise confidentiality.
   • We explain information handling to admins.
   • Staff other than the author will agree to confidentiality on the staff agreement screen. At first, all support replies will wait for the author's approval. The author may turn this setting off for individual members, but replies containing apparent private contact details or similar content will always require approval. A staff member does not see requests received before they were added. These three measures and the two-step verification below are in place together with staff and teams, as the four staff safeguards.
3. Physical
   • The home server is inside a home.
   • Disk encryption and TPM key protection on the home server have not been checked on the actual machine. Current backups are ZIPs without key-file encryption. We will encrypt server backups with a key file (planned; Article 5): the public key stays on the home server, which encrypts backups before sending them to the author's PC. The private key and its passphrase stay only on the author's PC. Backups are decrypted only for restoration.
4. Network
   • Cloudflare Tunnel hides the home IP address; no home port is opened.
   • The staff page is accessible from the internet, but only listed Discord IDs or email addresses and staff added by the author can enter. Support members and admins other than the author must agree to the staff pledge and pass two-step verification with an authenticator app. Only the author adds admins and support members, one at a time (Article 2(4)), and they can enter only by the method used when added.
   • IP addresses are not written to logs.
   • URLs sent to us are not opened.
   • Email goes through an email-sending company, not directly from the home server, to keep its IP address out of mail.
5. Foreign environments
   • Article 6 lists companies' and servers' countries and the measures taken (United States and Germany, or the reason a country cannot be identified).
   • The home server is in Japan. Support members must also live in Japan.
6. Details that would weaken security if published are omitted.

Article 12 (What you can ask us to do)

1. For your information that we hold, you can ask us to:
   1. tell you what we use it for
   2. show it to you (disclosure)
   3. correct it
   4. stop using it, or delete it
   5. stop giving it to others
   6. show you records of giving it to others
   • There is no charge.
2. How to ask
   1. To erase records (the easiest)
      1. Type /cmd id in the chat of a PocketRoles room. Your erase code (16 letters) appears.
      2. Send that code to the contact in Article 14 (write "Erase records" in the subject or first line). You can also choose "Please erase my records" on the support site's room restriction appeal form. This is read only by the author, never by Room Access Team staff (Article 2(4)).
      3. The author puts the code on the erase list. Each host's PC erases your records the next time it gets the definitions file (at game start, and once a day while running).
   2. To delete an ordinary support request (withdrawal and retention for "Join us" applications are in 3.13; you can also make the information requests in paragraph 1 of this article): press "Delete this request" on the receipt-number page (a secret link for forms; sign-in for chat) (planned; it is deleted after 24 hours and you can undo it until then). Until that button exists, ask through Article 14.
   3. To delete an account: press "Delete account" on the account page (planned). Until the button exists, ask through Article 14 (the contact page, category "Other") and we will delete it. After deletion, it stays in the server backups for the periods in Article 5 (manual backups currently stay until manually deleted; automatic deletion after 90 days is planned). Friends data alone (connections, blocks, settings and images; 3.12) will be deletable through "Delete Friends data" in the Client settings, leading to the account page, and is also deleted with the account (planned).
   4. To see your information: besides the code, we ask a few questions to confirm it is you (when you joined, what in-game name you used and so on). This is so we do not show it to someone else. For account information, sign in first and then ask. You can choose how we show it (for example, as electronic data by email).
   5. From a parent or guardian: ask with your child's code, a support request written together with your child, or from your child's account.
   6. To withdraw or delete a "Join us" application: sign in and reply to that application under "Your requests". The application is marked as withdrawn and deleted 90 days after the withdrawal (3.13, Article 5). For people approved as contributors or support members, the records are deleted 1 year after they stop.
3. What is erased (with a /cmd id code)
   • names, history (room codes where entry was stopped and so on)
   • evidence records and the log lines backing them (without waiting for the 90 days; for records newer than 30 days, the name, room code, log lines and detection text are removed at once and the rest is kept until 30 days)
   • copies held by the author and admins (not erased automatically yet. Copies on the author's PC: the author erases them by hand when asked. Copies on an admin's PC: the author asks the admin to erase them (the author can only ask). Names written in the ban console's audit log (audit.log) cannot be erased at present (a form that masks them is planned). Matching against the erase list automatically is also planned; 3.5, item 4)
4. What stays
   • For a restriction that is still in effect, the minimum needed to keep it working (hash, level, end date) and the evidence record for that restriction. If your erase request is still listed when the restriction ends, they go at once (a record younger than 30 days is emptied at once and deleted at 30 days). If it is not listed any more, they stay until the later of 30 days after the restriction ends and 90 days after the record was made (kept for good if it has no end).
   • The count of violations (PUID hash, count, dates). 1 year after the last restriction ends.
   • Your line in the lift list (the erase code and evidence number from when your appeal was accepted). Even if you ask for erasure, it is not removed for at least 180 days (removing it would leave the restriction in place on host PCs that did not start in the meantime). It stays in GitHub's history after that (Article 8(3)(4)).
   • Lists the host writes by hand (Banlist.txt and others). Please ask that host.
   • Your name written in someone else's evidence record
   • Records on PCs running old PocketRoles (before v0.5.5), or on PCs that are no longer started
   • Your name in the game logs on a host's PC (and their log archive), in events.log, in report zips and "One player's evidence" zips on the desktop, and in the Client's recent people (recent.json; planned). The erase list does not erase these. They go away automatically after 30 days.
5. Please note
   • The code is not a password. Anyone who sees your code can ask for erasure in your place.
   • The author and admins also receive other people's codes, in the evidence records inside report zips (3.5).
   • Only what is in item 3 is erased. A restriction still in effect stays in effect.
6. We cannot see records on hosts' PCs. So even if asked, we cannot show records on a host's PC.
7. When asked, we respond without delay. If we cannot, we tell you why.
8. You can make the requests in this article without an account, and even if your account is limited.

Article 13 (If information leaks)

1. If information leaks, is lost or damaged, or might be, we act quickly to stop it spreading and look for the cause.
2. When the law requires it, we report to the Personal Information Protection Commission and tell the people affected. For example:
   • when someone may have broken in on purpose
   • when more than 1,000 people are affected
   • after the 2026 amendment of the law starts, when information was given to others in a way the law does not allow (whether the way the central lists are published is such a case has not been settled yet; Article 8(4))
3. For people we have no way to contact, we announce it on the site.
4. We have a procedure for when information leaks, or may have leaked, from a staff member: pause or remove that member at once, hold the requests that member recently opened, revealed or replied to so they are not deleted (Article 5), investigate the scope using view and reveal records, and check whether affected people must be notified and a report made to the Personal Information Protection Commission.

Article 14 (Questions and complaints)

• Contacts
  • The contact page on the site (support.starpocketgames.com). Choose the kind and send. No account is needed
  • Email support@starpocketgames.com (please start the subject with "Personal information")
  • A ticket on the Discord server "PocketRoles 役職部屋"
• Requests from hosts (shared-ban requests, report zips) go by email to support@starpocketgames.com. Appeals, erase requests and security reports stay with support@starpocketgames.com above.
• Japanese, Chinese or English are all fine.
• We are not a member of an "accredited personal information protection organisation".

Article 15 (What we show at installation)

1. The first time StarPocket Client opens, before it installs or sends anything, it shows these screens in this order:
   1. "Terms of Use and Privacy Policy": a summary and the full texts, the versions and dates, a "Use chat translation" checkbox (unticked at first; nothing is sent unless you tick it; if you upgraded from v0.5.4 or earlier, see 3.9), an "Automatically report players removed for cheating to Innersloth" checkbox (unticked at first; nobody is reported automatically unless you tick it), an "I have read and agree to the Terms of Use and the Privacy Policy" checkbox (unticked at first), and "Agree"
   2. About Aegis: what it checks, what it does not do (no driver, no restart, PC scan results not sent), and "Install"
   3. Installation: progress, with a one-line explanation of what is happening now
2. Changes to PC settings (starting the Client when the PC starts, making a desktop shortcut and so on) are made only when you choose them.
3. There is a way to uninstall (settings, "General" → "Uninstall"). You can also uninstall from the first screen, without agreeing. If you do not agree, the official Client closes, and it sends nothing (Terms of Use Article 3(3)). The first time you open it, nothing is kept. If you do not agree after the terms change, what is already installed (the mod copy, settings, the earlier consent record, logs) stays as it is. To remove it, press "Uninstall".
4. If we add something new that sends information, the Client asks you again.
5. Code signing: the programs we distribute (such as StarPocket Client) are not code-signed today (code signing uses a certificate to show Windows who made a program; it is separate from the signature we put on the definitions file). We applied to SignPath Foundation for free code signing, but were not accepted this time. We have not decided whether to apply again.

Article 16 (Cookies and similar)

1. Pages of the site that you only read use no cookies other than one that remembers the language you chose (1 year) (the official site stores your language and display choices in the browser; 3.6).
2. The contact page, the receipt-number page, the account pages (and the support chat (planned)) use the following. All are only what is needed to make the service work.
   • the language cookie (1 year)
   • Cloudflare Turnstile (bot check)
   • when signing in with Discord, a mark kept only between leaving for Discord and coming back, and a mark that shows the result of connecting Discord once on the screen (2 minutes)
   • the secret link token that lets you read replies (only in that browser)
   • a sign-in cookie while signed in (30 days) and a device mark (planned; Article 5)
3. On a PC shared with family, links stay in the browser history. Sign out when you finish.

Article 17 (Changes to this policy)

1. This policy always shows a version number and the date it takes effect. Each time we change it, we add to "Change history" on the site the version, the date, a summary of the change and the differences from the previous version. Older versions can be read there too.
2. When we change this policy, we announce what changes and when, in advance, on the site and on Discord. Once StarPocket Client's news (planned) exists, we announce it there too. The copy of this document inside the Client is updated when you install a new version of the Client.
3. For important changes, such as sending more information or to more places, or using information for more purposes, we ask for your consent again in StarPocket Client, the StarPocket Account and the support chat.
   • If we change a purpose so much that it can no longer be said to be related to the previous purpose, we get the person's consent before using it that way (Act on the Protection of Personal Information, Articles 17 and 18).
   • When we send information abroad based on consent, we ask for consent for each new recipient (Article 28).
   • For people who have not agreed, we do not start the new sending or the new use.
4. Corrections that do not change the meaning, such as typos, are only added to the change history.
5. The correct text of this policy is only the text on the official site, in the official GitHub repository, and inside the official StarPocket Client (signed by us).

Change history