Phone → Computer Security & design

How your files stay yours.

This page is where we show our work. A backup tool is only as good as its boundaries — so here is exactly what RabbitDrop does, how it's protected, and which choices are design rather than accident.

The one thing to understand first

The app runs a small web server on your computer so your phone can reach it. That server listens on every network interface — which is exactly what makes "scan and send" work.

The security boundary is credentials — the keys described below. Anyone on the same local network is a candidate, so those keys do the work. At home with a password on, that's all you need.

Credentials

Three keys, three different lifetimes

They are independent. Knowing one does not give you another. They exist because "scan and go" and "someone else can't get in" are both requirements, and one mechanism can't be good at both.

① Launch token

Generated fresh every time the app starts. Printed as the QR code and the on-screen URL.

Restarting the app invalidates every previously issued QR / link. That's deliberate: it's the short-lived one.

⚠️ If a password is set, the token is no longer an entry credential. The QR code does not carry it. Scanning still asks for the six digits.

② The 6-digit code

Exactly six digits. Auto-generated. Does not rotate on restart — that's the point. You can only change it by resetting it yourself.

With it on, both the QR path and hand-typing the URL go through the same two gates.

③ Device credential

A long-lived key issued once, at the moment you click "Allow". Valid 30 days. No renewal.

⚠️ Built for a future phone App. The App is not usable yet — this is foundation work, not a feature. A foundation is not a feature.

Device credentials are the only place this product is less safe than it used to be

Everything else in the security posture is additive. This one is not: the boundary moves from "invalidated every restart" to "valid for 30 days". We're stating that plainly instead of burying it, because a tool that quietly weakens itself is the one you can't reason about.

Device credentials never skip the computer-side confirmation. Long-term passes get no free door.
The key is issued exactly once, at approval. It is stored only as a hash.
「Reset token · disconnect all phones」 revokes every device too. The button says what it does.

Two switches

Two gates, stacked — not either/or

pinEnabled controls the first gate (do you type the six digits). autoAccept controls the second (do you click "Allow" on the computer). They multiply. Four combinations:

Password	Computer confirms	What the phone has to do	Gates
On	On	Type the 6 digits and wait for you to click Allow	Two
On	Off	Type the 6 digits only	One
Off	On	Wait for you to click Allow	One
Off	Off	Nothing. Scanning is enough.	Zero

"How many faces" is a different question from "how many gates"

Whether the phone shows you a password box or a knock-knock "Request access" button is decided only by pinEnabled. Those two faces are mutually exclusive — you never see both.

Don't mix that up with the gate count above. A phone can show one face and still face two gates.

The six digits

How strong is a 6-digit code, really

What it stops

Someone who found a link in a chat history and tries it out of curiosity.
A neighbour's laptop that scans every open port and pokes around.
A colleague who "just wanted to see if it works" on the office Wi-Fi.

Against casual attempts it is plenty. Rate limits make fumbling expensive.

What it's designed for

People who have the link but can't see the screen — the realistic case.
It stops anyone who found a link, a screenshot or a forwarded message but doesn't have the six digits.
One million combinations is plenty against casual attempts.

It's a convenient gate for everyday use — turn on both switches and you're comfortable.

Rate limits

Three independent buckets. The point of splitting them is that one device fumbling never locks everyone out.

Bucket	Limit	Applies to
General request	20 per 60 s	Normal authenticated traffic, per source IP
PIN attempts	5 per 10 min	Wrong 6-digit entries, per source IP
PIN attempts (cross-device)	60 per 5 min	Aggregate wrong codes from different IPs — catches a spray

⚠️ IPv6 is compressed to a /64 for bucketing. Devices that reach you over IPv6 from the same prefix share those buckets. On most home networks that's one phone and one laptop, so it doesn't matter — on a large corporate IPv6 range it might.

The code is stored in plain text

In settings.json, on your disk, unencrypted. Not because we couldn't hash it — because the app has to display it on screen. A hash you can't show back to the owner isn't a password prompt, it's a password you can't use.

Implication, stated plainly: anyone who can read that file has the code. If that's a problem for your threat model, this is the wrong tool.

Information exposure

What the phone can see — and what stays on your computer

What is sent to the phone

Your target folders — only the ones you explicitly added. Each as { id, note, real path }.
The note is what you wrote. The real path is the path on your disk, including your username and folder structure.
Batch preview info and endpoint configuration.

⚠️ This is a deliberate information-separation reduction made for usability. Two folders can have the same note; only the real path disambiguates. Logged as such, not as a pure UI change.

What is never sent back

The default save directory (saveDir) is never sent to the phone at all.
The phone never transmits a path. It sends an opaque id back. Display ≠ transmit.
The five unauthenticated doors below contain zero path bytes.

Visible is not the same as exfiltratable. The phone is a display and a picker, not a remote filesystem.

How it works

Plain HTTP — fast and simple on a home LAN

Why not HTTPS. A self-signed certificate makes every phone show a terrifying red warning that trains people to click through warnings — which is worse than the disease. A real certificate needs a domain and a public network, which defeats the point of a LAN tool. Version 1 chose simplicity and transparency.
Where it's ideal. Your own home Wi-Fi, your own devices, your own files. At home, the realistic threat is low and the convenience is high.
Where to be careful. Café, office, dorm, hotel — anywhere with strangers on the same network. Use your judgment for sensitive items (scanned documents, ID photos). A home network is the right place for this tool.

We tell you this up front so there are no surprises mid-transfer.

How the gate works

The gate is credentials, not "same Wi-Fi"

Why that's the right design

"Same Wi-Fi" is a convenient coincidence, not a security guarantee. Routers don't authenticate every client. So RabbitDrop does the work itself.

That's what the credentials below are for — three kinds, each with a different lifetime.

What that means in practice

The server binds 0.0.0.0 and accepts inbound connections from any device on the local network. "Local network" includes everyone at the café, everyone in the office, everyone in the dorm.

Credentials are the gate. If you turn both switches off, there is no gate — scanning is enough.

Attack surface

Exactly five doors need no credentials

Counted, not estimated. Every other endpoint verifies first, before parsing or handling anything.

Door	What it does	Why it has to be open
GET /	Pairing entry page	The phone has to get somewhere before it has a credential. This is that somewhere.
GET /api/pair/mode	Which face to show: password box or knock-knock button	Chicken-and-egg: the phone must know whether to ask for a code before it has one.
POST /api/pair	Submit the pairing request	The authentication attempt itself. The password is checked before a queue slot is taken.
GET /api/pair/status	Am I approved yet?	The phone is waiting for you to click Allow. Polling that wait can't require the thing being waited for.
/m/* (static)	The mobile page's own HTML / CSS / JS	You can't authenticate to a page you haven't loaded yet. Contains no user data and no paths.

Authentication comes before processing

Every write handler's first statement is a credential check. A request that fails it is answered without reading the body, without touching disk, without allocating a transfer session. The five doors above are the entire exception list — not "the ones we remember", the ones that exist.

Where your data goes

Nowhere, except the folder you chose

What stays on your computer

The files themselves.
Settings.
The content-deduplication ledger (hashes only, local file).
Transfer history — in memory only, capped at 200 entries, gone when you quit. Clean by default.
No analytics. No accounts. No telemetry. No remote backend.

The one outbound channel

A mobile-page update channel: the computer pulls a signed resource bundle so the phone page can be improved without repackaging the app.

Off by default. No update source configured = not usable and no network traffic.
Ed25519-signed and verified before anything is written.
The downloaded content is served as static files and is never require'd, eval'd or import'd. It can only ever run in the phone's browser sandbox.
Production signing keys are not yet in the trust table, which means everything fails verification for now — the safe default.

Capability overview

Three kinds of "done"

Grouping everything into "works" and "coming soon" would miss the point: some of these are permanent design choices, deliberately simple. So there are three bins, and the distinction is the point.

① Works today

Scan a QR, send photos / videos / any file — no app to install
Never overwrites: collisions become xxx (1).jpg
Files land in the folder you chose, with a note-named subfolder
Chunked transfer + resume for files over 16 MiB
Three-stage funnel: size → date → content hash
Tap a thumbnail to open it; videos play in place

② On the way

Running on a real Windows machine (final verification)
Code signing / SmartScreen
macOS beta distribution without Developer ID signing or notarization; first-install testing pending
Encrypted transfer (HTTPS)
Continuing after the phone screen locks
The phone App (an optional extra, not a requirement)
Real-device throughput and behavior of every feature above

③ We keep it simple on purpose

Phone → computer only. The one direction phone content should travel.
No accounts. Nothing to sign up for.
No cloud. Nothing to upload to.
No transfer history across sessions — clean by default.
No auto-update for the desktop app — you stay in control.

Item by item

Tags mean exactly what they say. Implemented = the code exists and has been exercised. Unverified = the code exists, real-device confirmation is pending. Not implemented = not part of this product. Design choice = deliberately simple, staying that way.

Capability	Status	Why / what it means for you
Scan-to-send, no app install	Implemented	The phone opens a complete web page. The App is an optional future, not a requirement.
Any file, not just photos	Implemented	Photos, videos, and an "any file" picker.
Never overwrite on name collision	Implemented	Renames to xxx (1).jpg. Two-phase write: stage → verify → publish.
Chunked upload + resume	Implemented	Over 16 MiB. Survives a network blip within the same run.
Resume across app restart	Design choice	Staging is cleared on next launch, so nothing half-written lingers. Within one run, resume works.
Keep uploading with the screen locked	Unverified	iOS freezes page scripts. A server watchdog aborts after 60 quiet seconds — real-device behavior pending.
Album roll backup / incremental sync	Implemented	Three-stage funnel and content dedup exist. Real-device confirmation is pending.
Automatic date / type folder layout	Implemented	EXIF for JPEG / MP4 common paths. HEIC is classified, not parsed.
Video plays in the browser	Unverified	Desktop Chrome and iOS Safari support different codecs. One side playing proves nothing about the other.
HEIC thumbnails	Unverified	Usually degrades to a generic icon. The file still transfers.
Runs on Windows	Unverified	Packaging produces .exe on macOS. It has never been executed on Windows.
Code signing	Beta is unsigned	The Mac beta has no Developer ID signature or notarization. First launch may be blocked; see the installation guide. Apple has not reviewed it.
HTTPS / encrypted transfer	Design choice	Plain HTTP by design in v1 — fast and simple on a home LAN. See above.
Computer → phone transfer	Design choice	The product is one direction. Inventing the reverse would be a different product.
Accounts / sync / cloud backup	Design choice	No account system exists and none is planned. Files stay on your machine.
Transfer history across sessions	Design choice	Memory only, 200 entries, gone on quit. Your files are the durable record.
Phone App	Coming later	An optional extra. The web page is the full experience — no install needed.

A word about our words

"Implemented" and "verified" are not the same sentence.

Verified means it was run in a real environment and someone looked at the result. Evidence exists.
Implemented means the code is there and working. Where a real-device check is still pending, we tag it — and we'll flip the tag the moment we know.
How we phrase things We prefer specifics over vague reassurance. If something needs a real-device check, the tag says so. You'll see that on this site and in the app.

This is how we'd want a backup tool to talk to us.

Practical advice

How we'd actually use it

Home

Your own Wi-Fi

Defaults are enough. Password optional. Auto-accept is fine when you're the only person in the house and you can see the screen.

Reset the token occasionally. It costs one click.

Guests / office

People you didn't invite

Turn on both gates. Password plus computer-side confirmation. When you're on a shared network, both gates are the comfortable default.

When you're done: reset the token. It disconnects every phone and every device key.

Café / hotel / dorm

On a shared network

Best used at home, where you control the network. On a shared network, use your judgment for sensitive items. A home network is where this tool shines.

Home Wi-Fi is the sweet spot — that's what it's built for.

Get it (when it's ready) First time guide