PlainApp Security Deep Dive

Why Does Local Network Security Matter?

When you use an app to manage your Android phone from a PC browser, your SMS, photos, contacts and files travel across your Wi-Fi network. Most apps send all of this as readable plain text. Anyone on the same network could see it.

You might think: "It's my home Wi-Fi, who would snoop?" But consider:

• Public Wi-Fi — Cafés, airports, hotels — anyone nearby can capture traffic
• Shared networks — Roommates, guests, or compromised IoT devices
• Router vulnerabilities — Outdated firmware with known exploits

If an app sends your SMS messages as plain text over HTTP, anyone with a free tool like Wireshark can read them. This isn't theoretical — it's trivially easy.

Most phone-management apps do exactly this. Open Chrome DevTools (F12 → Network tab) while using their web UI, and you can read every API call in plain JSON — SMS bodies, file paths, contact names, everything.

GraphQL API — Ask for Only What You Need

Most apps use old-style REST APIs: one URL per resource, returning everything whether or not you need it. PlainApp uses GraphQL — a modern approach where the browser asks for exactly the data it needs, nothing more.

Why this matters:

• Less data exposed — If you only need a file name, that's all that's sent
• One endpoint — There's a single /graphql URL instead of dozens, which reduces the attack surface
• Per-query permissions — Each query checks its own permission (e.g., reading SMS requires READ_SMS permission even after you've logged in)

Digital Signatures (Ed25519) — Device-to-Device

When two PlainApp devices communicate with each other (e.g., phone-to-phone chat), encryption alone isn't enough — each device needs to verify that the message truly came from the other device and wasn't forged.

timestamp

The receiving device verifies the signature using the sender's public key, and rejects any request with a timestamp older than 5 minutes. This prevents both forgery and replay attacks.

Encrypted URLs — Hiding File Paths

Here's a detail most people don't notice: URL paths reveal information too.

When you download a file, the URL tells the server which file you want. In many apps, the URL looks like:

Anyone sniffing traffic (or looking at browser history) can see exactly what file you accessed and your phone's folder structure.

PlainApp encrypts the file path in the URL:

The id parameter is the file path encrypted with XChaCha20-Poly1305 using a random key called the URL Token. By default, this key is permanent and persists across app restarts, so shared links keep working. No one can guess the real path, enumerate your files, or craft download URLs without the key.

Login Protection

PlainApp limits login attempts to prevent password guessing:

• 5 attempts per 60 seconds per IP address
• After that, connections are rejected
• Stale rate-limit records are automatically cleaned up

Supply Chain Security — Fewer Dependencies, Less Risk

A security threat that many users don't think about: supply chain attacks. When an app uses hundreds of third-party libraries, any one of them could be compromised — injecting malicious code that steals data, mines cryptocurrency, or opens backdoors.

This is especially dangerous in the JavaScript ecosystem. In recent years, popular npm packages like event-stream, ua-parser-js, and colors were hijacked to inject malicious code into millions of projects. If a phone management app's web UI pulls in hundreds of JS packages, each one is a potential attack vector.

PlainApp takes a deliberate approach: use as few dependencies as possible, and build custom code when it makes sense.

Android App (plain-app)

• No dependency injection framework (no Hilt, no Dagger) — uses simple singletons
• Crypto handled by only 3 well-known libs: Google Tink, Bouncy Castle, and the built-in Java Cryptography Extension
• Server runs on Ktor (official Kotlin framework by JetBrains) — no obscure third-party server libraries

Web UI (plain-web)

Only 28 runtime dependencies — far fewer than typical web apps. Several things that would normally require npm packages are built from scratch:

Crypto on the web side uses @noble/ciphers — a well-audited, zero-dependency JavaScript crypto library — instead of pulling in large, bloated alternatives.

Why this matters

Every dependency you add is code you don't control. PlainApp's approach means:

• Fewer places for malicious code to hide
• Smaller attack surface
• Easier to audit (the entire codebase is open source)
• No risk from abandoned or hijacked npm packages

Frequently Asked Questions