Read this first

This is a draft, written by reading the source code, not by a lawyer. It is accurate about what the software does. It is not legal advice, and it has not been reviewed by anyone qualified to tell you whether it satisfies GDPR, UK GDPR, CCPA, or the law wherever you happen to be. If you are going to charge money for this service, have a solicitor read it first.

The facts this page turns on are filled in and were checked against the running system rather than remembered: the host, the region it sits in, how often backups are taken and how long they survive, and a contact address that receives mail. What remains unreviewed is the legal drafting itself — see above.

Privacy

What we know about you

aRDee lets you reach your own computers from somewhere else. That means a server sits between you and machines you care about, and a person runs that server. This page says what that server holds, what it can technically reach, and where the honest limits of the encryption are.

1 · The short version

Your email address, a hash of your password, the names of your machines, and each machine's LAN hardware (MAC) address are stored on one server.
Every sign-in, failed sign-in, screen peek, file send and print is written to an append-only log with your IP address and the time. Nothing currently deletes that log.
Desktop screen-sharing sessions are encrypted between your device and the machine. The server does not see them.
Screen previews ("peek"), iPhone and iPad screen sharing, machine-to-machine file copies, print jobs and queued shares do pass through the server.
The key that signs your login session lives in a plain file on that server. Whoever runs the server can therefore reach any enrolled machine. Section 6 says this properly.
Every machine keeps a list of the sessions on it — when, for how long, from which account and IP — and you can read it yourself in the portal, under Recent Connections. It records sessions you did not start, which is the point.
You can download everything held about you, and delete your account outright, from the portal. Both ask for your password. Section 12.
No cookies. No analytics. No trackers. No third-party scripts or fonts. The pages you are reading make no request to anyone but this server.

2 · Security

The part a buyer wants, without the marketing.

TLS everywhere Media encrypted end to end Single server, single operator No third-party trackers

Passwords

Never stored. Held as a scrypt hash with a random 16-byte salt per account, at Node's default cost parameters. Minimum length is eight characters, which is a floor, not a recommendation. A tuned Argon2id would be stronger; this is on the list.

Sessions

The web portal keeps a signed token in your browser's local storage, not a cookie, and ties it to a server-side browser-session record. The portal signs out after 30 minutes without activity, and every browser session ends after 12 hours even if it stays active. Signing out revokes that browser session on the server. Compatible native apps still use signed account tokens that last up to 30 days. Changing your password or choosing "sign out everywhere" invalidates every account token and browser session immediately.

Transport

HTTPS with a Let's Encrypt certificate, HTTP redirected. Screen and input traffic uses WebRTC's own DTLS-SRTP encryption between the two endpoints, not the server's TLS.

The relay

When two networks can't reach each other directly, a TURN relay on the same server forwards the session. A relay moves already-encrypted packets and holds no keys, so it cannot read the stream. Relay credentials are minted per session and expire in an hour.

Machine enrollment

Each enrolled machine gets its own random key and must present it to connect. Removing the machine in the portal invalidates that key. A machine can only be reached by the account that owns it — the server checks ownership on every request, not just at connect.

Brute force

Sign-in is limited to 10 attempts per 15 minutes per IP; signup and password reset to 5 per hour; changing your password, signing out everywhere, exporting and deleting share a budget of 10 per 15 minutes. Support codes have their own escalating lockout — a pause after each wrong code that grows, then a lockout — because a six-digit code is otherwise guessable at machine speed. That lockout is counted per account and per network address, since an attacker who can create accounts can otherwise reset it by creating another one. The per-network limit only ever refuses support codes, never a machine you own, so somebody else on your network cannot cost you access to your own computers.

Signup

Invite-only by default. Accounts can be disabled by the operator, and a disabled account cannot sign in from anywhere.

The honest weakness

One server, one operator, and the token-signing key sits in a plain file on it. That is the concentration of trust in this design, and section 6 does not dress it up. Self-hosting removes it entirely.

3 · What is collected

All of this lives in one JSON file on the server, except where noted.

Email address: Lowercased. Used to sign in, to verify the address, to reset a password, and to send the alerts you ask for.
Password: Not stored. A 64-byte scrypt hash and a random per-account salt are stored instead.
Account metadata: When you signed up, whether the address is verified, and whether the account is disabled. Separately, the invite code you signed up with keeps a record of who used it.
Machine names: Whatever the agent reported, or whatever you renamed it to. Also any custom names you give individual monitors.
Machine keys: A random secret per enrolled machine, stored in the clear so the server can check it when the machine connects.
MAC addresses: Yes, really. Each machine's LAN hardware address and its local network address, recorded every time the agent connects. This exists so another machine on the same network can send a Wake-on-LAN packet to a sleeping one — a sleeping computer can't be asked anything, so the address has to be stored while it is awake. A MAC address is a durable hardware identifier.
Connection history: Each machine's record keeps its recent screen-sharing sessions: when each started and ended, why it ended, the email address of the account that connected, that viewer's IP address, and whether the video went straight between the two machines or was carried by the server. That last one is reported by the viewer once the connection settles — the server brokers the introduction and then sees nothing, so it genuinely cannot work this out for itself, and a session that never reports reads as "Path not recorded" rather than being guessed at. The most recent 40 per machine are kept; older ones drop off as new sessions arrive. This is deliberately readable by you — Recent Connections in the portal — because "did someone connect to my Mac last night" should not be a question only the operator can answer. Support-code sessions are not recorded: that machine is someone else's and has no record here to attach a history to.
IP addresses: In the audit log, and in the connection history above. See section 4.
Alert rules: Which machine, what to watch for (online, offline, idle, low disk), the threshold, and whether the condition was true last time it was checked.
Relay usage: A running byte count per account per calendar month, so the relay allowance can be shown and enforced.
Held shares: If you send a file, link, clipboard text or print job to a machine that is offline, the contents are written to disk on the server and held until that machine comes back. Metadata (which machine, what action, the file's name) goes in the account file. Files are capped at 20 MB.
AI Assist settings: Which mode you chose, and — if you supply one — your own provider API key, encrypted at rest with AES-256-GCM under a key derived from the server's secret. See section 9.
Email tokens: Single-use random tokens for address verification and password reset, with an expiry. Deleted the moment they are used.

Collected live, but not stored

When the portal shows a machine's status it asks the machine directly, right then. That answer — OS version, uptime, free disk, how long since someone touched the keyboard, which app is in front, battery — is shown to you and thrown away. The one exception is an alert rule, which keeps a single true/false so it can email you on the change rather than every minute.

Not collected at all

No cookies. Nothing is set, nothing is read.
No analytics, no telemetry, no advertising or tracking pixels, no third-party JavaScript, no fonts loaded from a CDN.
Your keystrokes and mouse movements during a session do not reach the server. They travel inside the encrypted session, straight to the machine.
The desktop app does not send your session video anywhere but to the person you connected with.

4 · The audit log

Security-relevant events are appended, one JSON line each, to a file beside the account file. It exists so that if something happens to your account you can be told what and when — and it will tell on the operator as readily as on anyone else, which is the point.

Every line records the time, the event, and the IP address the request came from. Depending on the event it also records your email address, your account id, which machine was involved, and for a file sent to a machine, that file's name — never its contents.

What gets logged: signups, sign-ins, failed sign-ins, rate-limited attempts, attempts on disabled or unverified accounts, refused and throttled connection attempts, address verifications, password reset requests and completions, password changes and failed password changes, browser sign-outs, "sign out everywhere", data exports, account deletions and failed deletion attempts, screen peeks, shares sent and shares queued, print jobs, links and files thrown at a machine, machines removed, and accounts that hit their relay cap.

Nothing rotates or trims this file. There is no retention limit in the code today. It grows until the operator deletes it by hand. If that matters to you — and it should if you are in the EU or the UK — ask the operator what their actual practice is, and treat the answer as the policy until this page says otherwise.

Separately, the server writes ordinary operational logs to the system journal, which the operating system rotates on its own schedule.

5 · Where it lives

One virtual private server. Not a cluster, not a cloud region, not a managed database — a single Ubuntu machine running a Node process behind nginx, with the TURN relay on the same box. The account file, the audit log and the queued-share directory all sit on that one disk. Snapshots of the account file are kept in another directory on that same machine, /var/backups/ardee; the job that writes them runs on the server rather than being part of the application. It runs every 15 minutes and keeps the most recent 192 snapshots — about 48 hours. A copy is pulled once an hour to a separate machine off this server, where the most recent 72 are kept, about three days. That matters for deletion — see section 12.

The hosting provider is Hivelocity, Inc. and the server is physically located in Chicago, Illinois, United States. This page will not guess at either. If you are deciding whether your data may leave a particular jurisdiction, ask the operator and get it in writing.

DNS is served by Cloudflare in DNS-only mode — Cloudflare answers where ardee.help and the aRDee service hostname are, and nothing more. Your traffic is not proxied through them and they do not terminate its encryption.

If none of that is acceptable to you, run your own. The software is designed to be self-hosted, and an account can even point at its own TURN relay so that no traffic touches this server at all.

6 · What the operator can technically reach

The person who runs the server can reach any machine enrolled on it. Not through a back door — through the ordinary front door, using a key that necessarily sits on that machine.

Session tokens are signed with a 32-byte secret. That secret is stored in plain text in the same JSON file as the accounts. Anyone with root on the server can read it and sign a valid session token for any account, without knowing that account's password and without sending any email. That token is indistinguishable from one you got by signing in.

With it, they could list your machines, take a screenshot of any that is online, read and write files on them, print, put things on the clipboard, wake them, and start a full screen-sharing session with keyboard and mouse. The same file also holds every machine's enrollment key.

This is not a bug report. It is what "someone else hosts it" means, and it is true of every hosted remote-access product on the market. The difference is that most of them do not write it down.

What actually constrains it

The machine keeps its own receipt. During every session the agent writes a plain-English record to a file on that machine's disk — ~/Documents/aRDee — what happened on this Mac.txt — listing what was done: files copied, apps opened, the screen blanked, the session recorded. It records what was done, never what was seen: no keystrokes, no clipboard contents, no file contents, no screenshots. It is written by the machine, not the server, so a server-side token cannot rewrite it. Read it. It is a text file in your Documents folder, on purpose.
The operating system tells on us. macOS lights its screen-recording indicator whenever capture runs, and the agent deliberately stops capturing the moment nobody is watching, so that the indicator stays honest rather than permanently lit.
The desktop app shows a live session panel while someone is connected, and a red ● REC badge if they start recording.
The connection history is yours to read. Nothing can reach a machine without this server brokering the session, and every brokered session is written to that machine's record with the account and IP it came from — including one opened with a minted token. It shows up in your portal under Recent Connections, next to the sessions you started yourself. Same limit as the audit log: someone with root can edit the file it lives in.
The audit log records peeks, shares, prints and sign-ins with an IP and a timestamp. Note the limit: an operator with root can also edit that file. It is evidence against an outsider and a deterrent against an insider, not proof.
You can end it. Quitting the agent on a machine disconnects it. Removing a machine in the portal destroys its key.
You can remove the operator. Self-host, and this section stops applying to anyone but you.

7 · What is end-to-end, and what isn't

End-to-end

Desktop screen-sharing sessions. The server introduces your viewer to the machine — it passes the connection offer and the network candidates — and then gets out of the way. The video, audio, keyboard, mouse, chat and in-session file transfers all travel inside WebRTC's own DTLS-SRTP encryption, directly between your device and the machine where the networks allow it. Where they don't, the TURN relay on the server forwards the encrypted packets without the keys to open them.

The honest caveat: that guarantee rests on the signalling server passing along truthful encryption fingerprints. A server that lied could put itself in the middle of a session, and neither end would necessarily notice. The code does not do this. You are trusting that it never starts — which is, again, an argument for self-hosting.

Not end-to-end

These pass through the server in a form the server can read. No amount of TLS between hops changes that.

Peek. The screen thumbnails on the machine list are captured on demand and relayed through the server to your browser. They are held in memory and forwarded, not written to disk — but they are, at that moment, a picture of your screen inside the server process.
iPhone and iPad screen sharing. Every frame crosses the server. This is not a shortcut: Apple's App Store rejects builds that embed the WebRTC library, so the iOS sharer cannot make a peer-to-peer connection at all and has to relay through the server instead. The server counts the bytes for your usage allowance and forwards them.
Machine-to-machine file copies. Copying a file from one of your machines to another reads it into the server and writes it out to the other. The bytes pass through.
Print jobs, links, clipboard pushes and anything sent from a phone's share sheet. Same path.
Held shares. Anything sent to an offline machine is written to the server's disk until that machine returns. See section 11 for how long.
Fleet search results. When you search your machines for a filename, the matching paths come back through the server.

8 · Recording

A session can be recorded. It happens entirely on the viewer's own machine — the video is captured from the on-screen canvas and saved to that person's downloads folder as a .webm file. Nothing is uploaded, and no copy exists on the server.

Because recording is invisible from the other end, the viewer's software sends a notice to the machine when it starts and when it stops. The desktop app shows a red ● REC badge in its session panel while it runs, and the session receipt on the machine's own disk notes that the session was recorded.

The limit of that promise: the notice is sent by our client. Someone running a modified client, or simply pointing a phone at their monitor, can record without it. Treat the badge as a courtesy that works in the normal case, not as a guarantee.

Recording someone's screen may require their consent where you or they live, and the rules differ by country and by state. Getting that consent is your responsibility, not the software's.

9 · AI Assist

AI Assist sends a screenshot of the machine you are viewing, plus your question, to a large language model. It is off unless you turn it on.

If you supply your own OpenAI or Anthropic API key, the screenshot and question go to that company under your own account and their terms — not ours. Your key is stored encrypted with AES-256-GCM, but the encryption key is derived from the server's secret, which lives on the same server. It is protected against someone reading the file off a stolen backup. It is not protected against someone with root, and neither is anything else on that box.

The operator's own account can instead route Assist through a command-line tool signed in to their personal subscription, running on the server. That path is admin-only and is checked twice — once when saving the setting and once at the moment of the call.

In "act" mode the model returns a plan of steps rather than prose. Nothing is executed until you read it and confirm, so a misread screen produces a wrong suggestion rather than a wrong click.

10 · Other companies involved

SendGrid (Twilio) delivers verification, password-reset and alert email. Your address and the message content pass through them.
Cloudflare answers DNS queries for the domain. In DNS-only mode, as configured, they do not carry or decrypt your traffic.
Let's Encrypt issues the TLS certificate.
OpenAI or Anthropic, only if you turn on AI Assist and only under your own key.
In development builds without a relay configured, the browser may use Google's public STUN server to discover its own address. STUN reveals a network address and nothing else, and the production server does not use it.

That is the complete list. Nobody is paid for your data, because nobody is given your data.

11 · How long things are kept

Account and machines: For as long as the account exists. Including the MAC addresses.
Audit log: Indefinitely. There is no automatic retention limit in the code. It is appended to and never trimmed.
Held shares: Delivered and deleted as soon as the machine reconnects. Otherwise dropped after 14 days, or after five failed delivery attempts.
Web portal sessions: 30 minutes without activity, or 12 hours total, whichever comes first. Signing out revokes the current browser session immediately. The server keeps the account id plus created, last-active, and expiry times until the session ends and the expired row is removed.
Native account tokens: Up to 30 days, or until you change your password or choose "sign out everywhere" — either action invalidates every account token and browser session immediately.
Verification links: 24 hours, single use.
Password reset links: 1 hour, single use. Using one deletes it, so a link that later leaks out of your mailbox is already dead.
Connection history: The last 40 sessions per machine. Older rows are pushed off as new sessions arrive. Removing a machine, or deleting your account, takes its history with it.
Usage counters: One number per account per month. The current month and the two before it are kept; older months are dropped automatically.
Backups: Snapshots of the account file, on the same server, in /var/backups/ardee. A snapshot is taken every 15 minutes and the most recent 192 are kept, which is about 48 hours. A copy is also pulled once an hour to a separate machine, where the most recent 72 are kept — about three days. Deleting your account does not reach backwards into snapshots already taken.
Support codes: In memory only. Gone when the session ends, or five minutes later if the connection dropped and is expected back.

12 · Your choices

Remove a machine yourself in the portal. Its record and its key go with it. Its MAC address goes with it too.
Sign out to revoke the browser session you are using. Change your password to end every session on every device at once, or use sign out everywhere to do the same without changing it. Do this first if you think something is wrong.
Read your connection history under Recent Connections in the portal, and check it against sessions you remember starting.
Turn off AI Assist and remove your key at any time.
Download everything held about you from the portal, as one JSON file: your account, your machines and their connection history, your alert rules, anything queued for an offline machine, and your usage counters. It asks for your password, so a borrowed browser session is not enough to walk off with all of it. Three things are deliberately left out because they are live credentials rather than records — your password hash, each machine's enrollment key, and your stored Assist API key. Audit-log lines are not in the file either; ask the operator for those.
Delete your account in the portal. It asks for your password and makes you type the word DELETE. It removes the account, every machine enrolled to it and their connection history, your alert rules, anything queued for delivery along with its contents on the server's disk, any invite codes you created yourself, and your usage counters. Sessions in progress end immediately. One record deliberately survives: the invite code you signed up with belongs to whoever issued it, and it stays as their record that the code was spent — but your account id is wiped from it, so what is left says only "used, by an account since deleted". It cannot be cleared instead of scrubbed, because a single-use code with nobody attached to it is an unused code, and deleting your account would hand it back to the next person who typed it. aRDee stays installed on those computers but stops belonging to anyone — getting one back means walking to it and signing in again. There is no undo.
Deleting the account does not remove audit-log lines that mention your address or IP, and it does not reach into backups of the account file that were already taken. The log is append-only by design and editing it would defeat its purpose. If you want those gone too, ask the operator explicitly and get confirmation.

If you are in the EU, the UK or California you may have stronger statutory rights than the list above. Those rights are not created by this page and are not waived by it. This draft does not attempt to describe them; that is one of the things a lawyer should add.

13 · Children, changes, contact

aRDee is not intended for anyone under 16, and accounts are not knowingly created for children.

If this page changes in a way that matters, the date at the top changes and the operator will email account holders. Silent rewrites of a policy that admits this much would be worse than no policy.

Questions, deletion requests, and anything you think is wrong here: support@ardee.cksz.us. Security problems in particular are welcome and will not be met with lawyers.