# Security This page summarises the security built into Phlip to reduce risk for **hosts** and **members**, and how a host can minimise their own risk when running a server. > [!warning] Honest boundary first > Phlip is an early alpha built by a solo developer. Encryption is real but still under development, and some metadata is not covered yet. **Treat Phlip as not fully secure and don't use it for anything sensitive.** The measures below are steps taken in good faith to reduce risk — **not proven guarantees**, and **they have not had an independent security audit**. Where we can't be certain, we say so. The exact boundary is in the [[FAQs]]. > > In short, Phlip **does not offer any guarantee on encryption**. Instead, our aims are simply to **offer an alternative platform that doesn't collect your data for advertisements**. ## What Phlip does to protect you ### Your identity and password - **By design, your password itself never leaves your device.** When you set a password, your device turns it into a cryptographic key. The host stores a **random salt** and a **verifier** (a one-way value derived from that key), not the password itself. Note that the verifier *does* travel to the server to sign you in, so on an unencrypted local connection someone on the same network could in principle observe it. - **Strong key stretching.** Passwords are put through **PBKDF2-HMAC-SHA-256 with 150,000 iterations**, which makes guessing attacks slower and more expensive. - **A join code isn't enough to be you.** The join code gets a new device to the door; signing in also needs **your own password**, and the host can require the current join code on every sign-in as a failsafe. - **Rotating, expiring join codes.** Join codes are short-lived and rotate automatically, so an old code that leaks stops working. - **No username fishing.** Asking the server about a name without a valid code returns a realistic-but-fake answer, which is intended to stop outsiders probing who's a member. - **Brute-force throttling.** Repeated failed attempts are rate-limited. (This is strongest for public servers behind Cloudflare; on a plain local network it's a softer barrier.) - **Fresh session tokens.** Sign-in issues a new random 128-bit session token and retires the old one, so a previously captured token dies when you log back in. ### Your content - **Content is encrypted.** Message and event *content* is encrypted with **AES-256-GCM** under a shared group key. That key is itself **wrapped by your password-derived key**, so it isn't stored in plain form. - **What this is aimed at.** Because the stored data file holds ciphertext, this is intended to protect content from someone who gets hold of the file, and from outsiders who don't have the key. - **What it does _not_ do.** It is **not** secrecy from the host or your fellow members. The group key is shared, so **the host — and anyone who can see a channel — can read its content.** Encryption here is about keeping your group's content from *outsiders*, not from each other. - **Not everything is covered yet.** Metadata such as event times, display names, icons, categories and routing information is **not** encrypted, and connections over your local Wi‑Fi may be unencrypted — so someone on the same network could observe traffic. This part is still in development, so please **don't treat any of it as a guarantee** (see the [[FAQs]]). ### Who can see and do what - **Approve / Deny on every join.** New members don't get in until the host (or an admin) admits them. - **Roles.** Host, admin, moderator, user and viewer where each have a defined set of powers, checked on **every** action, not just in the UI. - **Per-channel privacy is enforced on the server.** If a channel is restricted, members who aren't on it don't receive its messages, events or pitches at all. The filtering happens on the host, not just by hiding things in the app. - **Host stays in control.** A host can remove a member, force everyone to re-enter the current join code, and revoke a public share at any time. ### Photos and metadata, minimised by design - **Photo-free by design.** Chat has no image uploads. Reactions are drawn, not uploaded — fewer images to moderate. - **Profile photos are never stored on the host.** A live photo is shown only while that person is online and sharing it; it's never written to the host's data file. - **Minimal permissions.** No contacts, location, or general storage access is requested. ### Keeping less data on the host - **Auto-purge of ended events (optional, host-controlled).** The host can have finished plans wiped from the phone automatically once the event is over (after a short grace period) — the event's RSVPs, notes, share links, mirrored chat and related notifications go with it. A lost or compromised host then holds only *currently active* plans, not a back-catalogue of past events. - **Chat retention (optional, host-controlled).** The host can choose to keep chat for only the last **1, 7, 30 or 90 days** (or keep everything, which is the default). Older messages are removed from the host periodically, along with their notifications. - **Members keep their own copy.** Purging only affects what sits on the *host* — each member's device-local **Memories** archive is theirs and isn't touched. - **Honest scope.** This limits how much history is exposed if the host is lost, seized or compromised — it's about keeping less around in the first place. It doesn't reach data already copied elsewhere (including phone backups), and it isn't a forensic secure-erase. ### Share links (Broadcasts) - **A share only ever exposes one event.** A guest with the link sees that single item and nothing else on the server. - **The share is re-encrypted under its own one-time key** that only ever travels in the link's `#fragment` not the group key. - **Guest sessions are tightly scoped and capped**, rate-limited, and the link **auto-closes** once the event has passed. - **Optional passcode** on public share links. Treat it as a light gate to reduce casual access, not a strong secret. ### On the device and at the edge - **Secrets are held in the Android Keystore.** Tunnel tokens, the Cloudflare API token, edge secrets and the on-device data file are encrypted with the **Android Keystore** for hardware-backed on devices that support it. This ties them to the device, but it isn't magic: a lost, unlocked, or compromised (e.g. rooted) phone is still a real risk, which is why the host-setup advice below matters. - **Public access is outbound-only.** Going public opens a **Cloudflare Tunnel** from inside the app, so **no inbound ports are opened on your router**, and the origin uses a random, unpublished address. - **Edge join-code gate.** When enabled, Cloudflare can check the join code before traffic reaches your phone, and members' tokens are only ever sent to the edge as **hashes**, not in the clear. - **Locked-down web app.** The interface runs under a strict **Content-Security-Policy** and is built to load only its own bundled code rather than open external web pages. - **Runs in Android's app sandbox** like any other app. --- ## How hosts can minimise their risk You are the host: your phone holds the data and is the thing exposed to your members (and, if public, to the internet). Most of your safety comes from **how you set up the host phone**, especially for public servers. ### Use a clean, dedicated host phone - **Factory-reset the phone** before using it as a host, so old apps and accounts aren't in the mix. - **Prefer a dedicated spare** as the host and use your **daily phone as a normal Phlip client**. If a host is ever compromised, you want it to be the appliance in the drawer, not your main device. - **Sign in with a throwaway Google account** for Play Store updates. An account with **no personal email, photos, contacts, or payment methods** attached. Or sideload the app and check for updates yourself. - **Keep it patched.** Security updates matter most on an always-on device. Phlip shows a warning when the phone's security patch level is old — take it seriously, and avoid hosting sensitive groups on a phone that no longer gets updates. - **Lock the device.** A strong screen lock plus Android's device encryption protects the data file if the phone is lost or stolen. > [!tip] Which Android version is safe enough to host on? > What matters most is the **security patch level**, not the version number on its own. Check **Settings → Security → Security update** (or **Settings → About phone → Android security update**) and look for a date within the last month or two. > - **Rule of thumb:** Google only backports security fixes to roughly the **three most recent major Android versions**. Once a phone is more than about three versions behind the current release, it has most likely **stopped getting OS security patches** — even though it still switches on and runs. > - **As of early 2026** that puts a safer floor at around **Android 14**, with **Android 15 or 16** better. This moves up by one number roughly every year, so re-check it against whatever the latest Android version is when you read this. > - **The phone maker matters more than the number.** Recent Google Pixel and Samsung flagships now promise up to **7 years** of security updates; many budget phones get only 2–3 years. Look up your model's stated support window and check it's still inside it. > - **Phlip runs on much older Android**, but that's about the app installing, not the phone being safe. An old, unpatched phone with no more OS updates can be used but a poor choice for anything public or sensitive. ### Keep the host off your trusted network - **Best: host on cellular, not your home Wi-Fi.** Put the host on a **mobile/SIM data connection** (its own SIM, or a hotspot) so it never joins the network your laptop, NAS and smart devices are on. Public hosting works fine over cellular — the Cloudflare Tunnel is outbound-only. - **Otherwise: use guest Wi-Fi.** If it must be on Wi-Fi, put it on a **guest network or separate VLAN**. Network isolation means that even if the host phone were compromised, it can't reach your router, storage or other devices. - Either way, **no router/port-forwarding setup is needed** as Phlip never asks you to open ports. ### If you go public with Cloudflare - **Scope the Cloudflare API token tightly.** Give it only what it needs (DNS, Tunnel, Workers and KV for the one domain you use) — not a global key. If the phone is ever compromised, a narrow token limits the damage. - **Use a dedicated domain / account** for Phlip rather than one tied to important sites. - See [[Guides/5. Go public with Cloudflare]] for the walkthrough. ### General good-host habits - **Don't host anything sensitive** while Phlip is in alpha — this is the single most important rule. - **Keep the app updated** so you get security fixes. - **Look after the battery**: keep the phone cool, and use a charge limit (~80%) if it has one. - **Keep less history around.** In **host server settings** you can auto-purge ended events and cap chat retention (1–90 days). Turning these on for a public or semi-sensitive server means the host holds little more than what's currently in play, so there's less to lose if the phone is. - **Moderate.** As host you're responsible for your servers: use roles, Approve/Deny, and the report inbox to keep the space healthy. > [!note] In-app help > **Settings → Hosting** shows a short "Safer hosting setup" tip and a patch-age warning when the phone's security update is old. See also [[Guides/4. Host a server on your Android phone]] for setup, including the safer-setup checklist. --- **Quicklinks:** [[Why Phlip|Home]] · [[About]] · [[FAQs]] · [[Guides/4. Host a server on your Android phone|Hosting guide]] · [[Roadmap]] · [[Notices/Legal]]