Sour Client — Privacy Policy

Effective date: 2026-08-21 Policy version: 2026-08-21.2 Operator / data controller: sourama (an individual, New Zealand) Contact: [email protected] Official site: https://sourclient.com

This policy describes what the Sour Client launcher, game-side mod, and backend actually collect and do with it. It is written against the real code paths (audited 2026-07-11); nothing is collected beyond what is listed here.

Changed on 2026-09-06: Terminology only. What this document used to call a cape is now called a cloak, throughout — the same feature, the same data, the same handling. Nothing about what is collected, shared, or retained changed, and no new collection was introduced. Two things are deliberately NOT renamed: the endpoint paths (/cape/<uuid>.png and the others), because those are the real URLs and renaming them here would document routes that do not exist; and the reference in section 4 to the official-Minecraft-cape check, which screens uploads against Mojang's own capes and is named accurately.

Changed on 2026-08-21: Two disclosures, both of things already happening.

1. Section 4 (Sharing) now names the content-moderation provider that uploaded cloak images are screened by. 2. Section 1.1 now describes your public profile — the playtime, join date, plan and cosmetics behind the players page — and the switches that control it. This was already being collected and published and was not described here, which also made one line in section 1.2 wrong: it said playtime "is not uploaded", and the launcher has been reporting it to the backend. That line is corrected rather than removed, because a policy that quietly drops a claim it used to make is harder to check than one that says what changed.

No new collection was introduced by either change; both close a gap between this document and the code.

Also changed on 2026-08-21 (second revision), again all disclosure of things already happening — no new collection:

3. Section 1.1 now names the third party your skin is loaded from (minotar.net) and says plainly that it receives the IP address of anyone viewing the page, not only the player whose card it is. The old wording said "a third party" without naming it and described it from the wrong side. 4. Section 1.1's public-profile table now separates what the API publishes from what the player page draws, because the page stopped drawing the owned-cosmetics list on 2026-08-21 while the API kept publishing it. The switch that governs it did not change. 5. Section 4 (Sharing) and 1.4 now name Lemon Squeezy as the payment provider and merchant of record, instead of describing payments as hypothetical. Payments are live. 6. Section 5 (Retention) now lists two stores it was silent about: the staff audit log, and the cloak moderation record — which includes the UUID of anyone who reports a cloak. 7. Section 6 (Your rights) now offers objection, restriction and portability, which were missing, and Section 9 explains our position on an EU Article 27 representative.

1. What we collect and why

1.1 Sour Client backend (cloak sync / accounts) — data sent to sourclient.com

Authentication works by the standard Minecraft server-join handshake: the backend asks Mojang's session server to confirm your account performed the join. We never see or store your Microsoft/Minecraft password or Microsoft access token on the backend.

Anyone using Sour Client can query whether a given UUID has a cloak and fetch that cloak image (GET /cape/<uuid>.png) — that is how cloaks are shown to other players. Your cloak image and its association with your UUID are therefore public to other users while set.

Your public profile (the players page). Signing in creates a profile on the backend that powers sourclient.com/players, where anyone can look up a Sour Client user by username.

"Published" and "drawn on the page" are not the same thing, and the difference is in your favour. The switches control what the backend publishes — what GET /profile/by-name/<you> returns to anyone who asks. What any given page chooses to *draw* from that is a separate, narrower thing: since 2026-08-21 the player page shows the cloak you are wearing, on a model you can turn, and the mark beside your name, and no longer lists everything you own. Your cosmetics switch still governs publication exactly as before. Nothing you switched on is published more widely than it was, and nothing you switched off is published at all.

Your skin is loaded from minotar.net, and that means minotar.net sees the visitor. The skin shown on the players page, on a player's page, and in the launcher's sign-in card is fetched from minotar.net by the browser at the moment the page is viewed. We do not store it. Two consequences worth stating plainly:

• minotar.net receives your username, because it is in the image URL, and
• minotar.net receives the IP address of whoever is looking at the page — which is usually not you. Anyone viewing anyone's card makes that request.

minotar.net is a third party with its own privacy policy; this one does not govern it. There is no way to view a page that shows Minecraft skins without some service being asked for the skin.

You are asked before any of this is published. The launcher shows a consent screen straight after your first sign-in, listing the four details above as individual switches plus a single switch for whether you appear on the players page at all. You can change any of it later on your account page at sourclient.com. Turning a detail off blanks it on your card; turning off the top switch removes you from the players page and from search entirely, so a lookup for your username returns nothing.

Your username and skin cannot be hidden while you are on the page — they are what a public card is. The switch that covers them is the one that takes you off the page.

Where a detail is switched off, the backend omits it rather than serving a placeholder, so the difference between "hidden" and "zero" is not inferable from the public response.

1.2 Launcher (on your device)

• Your Microsoft sign-in uses Microsoft's device-code flow. Tokens issued by Microsoft (access/refresh tokens, XUID, UUID, username) are stored locally on your device in the launcher's data folder so you stay signed in. They are sent to Microsoft/Xbox/Mojang services to authenticate you — never to our backend.
• Launcher settings, instances, logs, and diagnostics are stored locally on your device and are not uploaded.
• Playtime is tracked locally and, while you are signed in, reported to the backend as a running total so it can appear on your public profile. (This line used to say playtime was not uploaded. It is — see 1.1 — and switching off the playtime detail on your public profile stops it being *shown*, not being *counted*. To stop it being sent, sign out.)

1.3 Optional third-party integrations (off by default, your own API keys)

• Hypixel API stats overlays: if you enable them and supply your own Hypixel API key, the client sends other players' UUIDs/usernames to Hypixel's API and displays the responses. Governed by the Hypixel API Policy (https://developer.hypixel.net/policies/). Responses are cached in memory only. Your API key stays in your local config file.
• Urchin tags: if you opt in and supply your own Urchin API key, the client sends player UUIDs/usernames you encounter to the Coral API (api.urchin.gg) and displays returned tags. Your key stays in your local config; it is never logged or transmitted to us.
• Mojang/Microsoft services: the launcher downloads game files from Mojang servers and authenticates via Microsoft; those services see your IP and account data under their own privacy policies.

1.4 What we do NOT collect

No email addresses, no real names, no passwords, and no payment card details — card data is handled entirely by Lemon Squeezy, which is the merchant of record for every purchase and operates under its own privacy policy. Card numbers never reach any Sour Client system. We receive only the fact that an order succeeded and which account it was for.

Also not collected: no telemetry/analytics, no advertising identifiers, no behavioural profiling, no targeted advertising, and nothing is ever shared with advertisers or data brokers.

2. Legal bases and applicable law

sourama operates from New Zealand, so the Privacy Act 2020 and its 13 Information Privacy Principles apply (https://www.privacy.org.nz/privacy-act-2020/privacy-principles/) — including collecting only what is necessary (IPP1), security safeguards (IPP5), access and correction rights (IPP6–7), retention limits (IPP9), and controls on cross-border disclosure (IPP12).

For users in the EU/UK, the GDPR/UK-GDPR may apply to the backend service (https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations_en). Our legal bases are: performance of a contract (operating the cloak/account service you request) and legitimate interests (rate limiting, abuse prevention, security logging).

3. Children

Sour Client is not directed at children under 13, and the backend does not knowingly collect personal information from children under 13. Minecraft UUIDs, usernames, and IP addresses can be "personal information" under the US COPPA rule (see the FTC's COPPA guidance, https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa — persistent identifiers such as IP addresses count). If we learn that a child under 13 has created backend data, we will delete it. Parents/guardians can contact [email protected] to request deletion.

The Terms of Use set a minimum age of 13 to use the Service, or 16 where that is the local age of digital consent, and require a parent or guardian's permission and payment for anyone under 18 who buys something. That is a condition of use, not only a statement about who we aim at.

4. Sharing

We do not sell or rent personal information. Data is shared only:

• with Mojang (session server) to verify account ownership during sign-in;
• with other Sour Client users, limited to: your cloak image and the fact that your UUID has one, plus whichever public-profile details you have left switched on (see 1.1);
• with anyone visiting the website, for the same public-profile details — the players page needs no account to read, so "public" there means public, not "public to other users";
• with the content-moderation provider used to screen uploads before they are stored (currently Sightengine, an EU processor). The image only — no username, UUID, IP address, or account data is sent with it, and the image is transmitted for classification rather than stored by us there. Screening is described in the Content Policy; the official-Minecraft-cape check runs locally and sends nothing anywhere;
• with infrastructure providers hosting the backend (Oracle Cloud Infrastructure, in Australia, and Cloudflare as CDN/proxy) acting as processors — this is also the cross-border disclosure for NZ Privacy Act IPP12 purposes: backend data is stored in Australia, a jurisdiction with comparable privacy safeguards (the Australian Privacy Act 1988);
• with Lemon Squeezy, the payment provider and merchant of record, when you buy something. They receive what a card transaction needs, plus your Minecraft UUID so the purchase can be applied to the right account. We receive their confirmation, never your card details;
• with minotar.net, whenever a page showing a Minecraft skin is viewed — see the note in 1.1. This one is not a disclosure we make; it is a request the viewer's own browser makes, and it carries the viewer's IP address;
• if legally required (e.g. a valid legal demand).

5. Retention

• Auth challenges: minutes (single-use, expired entries swept).
• Session tokens: expire automatically (hours; the token TTL is enforced server-side).
• Cloak images: until you replace or delete them, or until removed by moderation.
• Public profile (playtime total, join date, plan, cosmetics, username): until you ask us to delete it. Switching yourself off the players page stops it being published; it does not by itself erase it.
• Rate-limit records: minutes, in memory.
• Server logs (which may include IPs, UUIDs, usernames): rotated and kept no longer than 90 days.
• Staff audit log: an append-only record of actions that change what an account has or whether it can play — plan grants and revokes, bans and unbans, role changes, and purchases. Each entry holds the UUID acted on, the action, and when. It exists so that "who took this away" and "I paid and did not get it" have answers, which is why it cannot be edited or deleted selectively. It is capped at the most recent 20,000 entries; past that, the oldest are dropped. That is a size limit, not a time limit — a quiet period means entries live longer. Erasure requests are handled as described in section 6.
• Cloak moderation record: for each cloak, its rating, where the rating came from, and any reports made against it. A report stores the UUID of the person who made it, so that the same account cannot report one cloak repeatedly to force it out of view. Reports are cleared when a cloak is re-rated; the rating itself is kept while the cloak exists.

6. Your rights

You can, at any time:

• See your data: your cloak image, fetchable directly (GET /cape/<your-uuid>.png), and your public profile, visible on the players page or at GET /profile/by-name/<your-username>.
• Delete your data: delete your cloak from the launcher (DELETE endpoint) or email [email protected] from a verifiable channel and we will remove your cloak, your public profile, and any associated records.
• Stop publishing your data without deleting it: switch yourself off the players page, from the first-run screen, your account page, or by asking us.
• Correct your data: usernames come from Mojang; change your name there and it propagates on next sign-in.
• Take your data with you (portability): your public card is already machine-readable at GET /profile/by-name/<your-username>, and we will send you your full backend record — profile, settings, cloak, and any audit entries about your account — as JSON on request.
• Object to processing we do on the basis of legitimate interests (rate limiting, abuse prevention, security logging). Tell us why and we will stop unless we have grounds that override it, and we will say what they are rather than simply refusing.
• Ask us to pause (restrict processing) while a complaint, a correction, or an objection is being worked out, instead of having to choose between leaving it and deleting it.
• Complain: in NZ, to the Office of the Privacy Commissioner (privacy.org.nz); in the EU/UK, to your local supervisory authority.

We answer these within 30 days. There is no charge, and using any of them never costs you access to the Service or any part of it.

7. Security

Backend transport is HTTPS. Session tokens are signed with a server-side secret. Cloak uploads are validated (PNG structure and fixed dimensions) and size-limited. Rate limits apply to auth and upload endpoints. No password database exists to breach. If a data breach occurs that risks serious harm, we will notify affected users and the NZ Office of the Privacy Commissioner as required by the Privacy Act 2020.

8. Changes

Changes to this policy will be announced via the launcher and/or sourclient.com. The current version always lives at sourclient.com and in this repository.

9. Contact, and our position on an EU representative

sourama — [email protected]

There is one data controller and it is one person, reachable at the address above. Everything in section 6 goes there.

On GDPR Article 27 (an EU/UK representative): we do not have one, and rather than leave that unexplained — a representative is what a policy is usually silent about — here is the reasoning. Article 27 requires a representative unless the processing is occasional, does not involve large-scale processing of special-category data, and is unlikely to result in a risk to people's rights and freedoms. Sour Client processes a Minecraft UUID, a username, a playtime total, a join date, an optional image you chose to upload, and server logs. It processes no special-category data at all, sells nothing to advertisers, and profiles nobody. We consider the exemption to apply. If that assessment is wrong we would rather be told than be right by default: write to the address above, or complain to your supervisory authority, and we will appoint one.