In plain English, what I know about you and what I do with it.

Who this applies to

This policy covers everyone who interacts with Armadoc: people who create an account and send files (senders), people who receive a file via an Armadoc link (recipients), and visitors who just browse the marketing site.

It also covers people who receive an outreach email from me: if you use its unsubscribe link, the record that creates is governed by this policy too, whether or not you have an Armadoc account.

It applies to armadoc.link and any subdomain, plus the underlying API and infrastructure that powers the product.

What I collect, and why

Armadoc is end-to-end encrypted, which means most of what you’d assume a file-sharing service collects, I don’t have. Here is the full picture of what touches my servers, organized by what it relates to.

Your account:

• Your email address. Email is your account identifier and is always required. I use it to send sign-in codes, to identify your account, and to send transactional notifications about shares you create or receive and about your subscription if you’re on Pro. I don’t use your email for marketing.
• Your phone number, if you choose to provide one. A phone number is optional. If you add one, I use it for a single purpose: sending sign-in codes by SMS when you choose to receive your one-time code that way. I do not send share notifications, billing messages, marketing, or anything else to your phone. Message frequency is tied to your sign-ins — one code per sign-in attempt. Standard message and data rates from your carrier may apply. Your phone number and any related SMS opt-in data are never shared with third parties or affiliates. You can remove the phone number from your account anytime while you’re signed in.
• Your public lock. Each account has a keypair — a private key, which lives only on your device, and a public lock, which I publish so that other Armadoc users can seal files for you. I store the public lock. I never see, store, or transmit your private key.

Your files and shares:

• Encrypted file blobs. When you send a file, it is encrypted on your device before it reaches me. I store the encrypted blob; I cannot read it. When the share expires, the blob is deleted.
• Share metadata. For each share, I store the recipient identifier, the filename you gave the file, and the timestamps when the share was created and opened. This is what powers your dashboard and lets me notify your recipient. If a filename is itself sensitive, rename it before sending — the security page makes the same point. When a share expires, this metadata is deleted along with the encrypted blob.

Operating the service:

• Application events. As the service runs, the application records operational events — things like a share was created, a recipient opened a share, an upload succeeded or failed. These events are tied to your account by an internal account identifier and do not contain file contents, recipient identifiers, or any personal information about you beyond that internal link. They’re used to operate the service correctly, debug issues, and understand in aggregate how the product is being used. They’re retained indefinitely; when you delete your account, the link to your identity is removed (see Your choices below).
• Operational logs. The application emits error and warning logs to my cloud infrastructure for debugging and monitoring. These logs do not contain personally identifiable information — they describe what went wrong, not who was affected. Logs are rotated every two weeks.
• Rate-limit records. To prevent abuse and brute-force attempts, I briefly retain your IP address against the endpoint you are hitting. Each record is set to expire at the rate-limit window boundary and is removed automatically thereafter. Beyond this short-lived rate-limit record, Armadoc itself does not log IP addresses. (Cloudflare, my edge provider, does see IPs as a function of routing requests to me — see Sub-processors below.)

Billing (Pro plan only):

• Billing data, if you upgrade to Pro. Stripe handles all card data on its own servers. On my side, I store your plan tier, your Stripe checkout and subscription identifiers, the price (amount and currency), and your billing period dates. I do not store card numbers, CVVs, billing addresses, or Stripe customer IDs.

Outreach email (if I contacted you):

• Your unsubscribe record. If I send you an outreach email you didn’t ask for, its footer carries an unsubscribe link with an opaque token in it. When you use that link, I store the token, the time you opted out, and the user agent your browser sent — no IP address, and no email address. The token is a one-way value: the page receiving it cannot turn it back into an address. Only the outreach system that generated it can match it against its own list, which is what makes the suppression work. The record is never linked to an Armadoc account, so unsubscribing has no effect on one if you have it. I keep the record indefinitely, because it is my proof that your request was honored — deleting it would put you back in scope for a later send.

That is the complete list. I do not collect: file contents in any readable form, private keys, decrypted previews or thumbnails, passwords (the system has none), third-party analytics, advertising pixel data, or any cross-site tracking that would let me follow you around the web.

What I cannot see

The architecture of the product takes some categories of data off the table entirely. By design, I do not have access to:

• The contents of your files. They are encrypted on your device before they ever leave your browser, and I never receive the key to decrypt them.
• Your private key. It lives only on your device. I publish your public lock so that others can seal files for you, but the matching private key is never transmitted to me.
• What your recipient does after decryption. Once the file decrypts in their browser, it’s their device, their copy, their choice.

This isn’t a policy I can change. It’s how the system is built. If you want the technical detail, the Security page walks through it.

Sub-processors

I do not sell, rent, or trade your data. I share it only with the small set of vendors I rely on to run the service, and only the data they need to do their specific job. These are my sub-processors:

If I add or replace a sub-processor in a way that affects what data is processed or where, I’ll update this page and revise the effective date at the top. The list above is meant to be exhaustive — if it isn’t on this page, it isn’t in the loop.

I will also disclose data if compelled by valid legal process (for example, a subpoena). I’ll push back on overbroad requests. Worth noting: even with a court order, the encrypted files are not something I can decrypt for anyone — I don’t hold the keys.

Where your data lives

All application data is stored in the United States. If you’re using Armadoc from outside the US, your data is being transferred to and processed in the US.

For users in the EU/UK: I rely on the standard contractual clauses Stripe and AWS already maintain for international transfers, plus the inherent protection that the file contents themselves are encrypted before they ever leave your device.

How long I keep things

• Encrypted file blobs and their share metadata are deleted when the share expires.
• Public locks and account identifiers are kept for as long as your account is active.
• Application events are retained indefinitely. The link between events and your identity is removed when you delete your account.
• Operational logs are rotated every two weeks.
• Rate-limit records expire automatically at the end of the rate-limit window.
• Stripe billing records are retained for the duration of your subscription, subject to Stripe’s own retention requirements for completed transactions.
• Outreach unsubscribe records are kept indefinitely. They are the proof that an opt-out was honored, and there is no address in them to delete.

If you delete your account (see below), I delete the data tied to it.

Your choices

Access. You can see your active shares, account identifier, and subscription status from your dashboard at any time.

Correction. Most account fields you can change yourself in the dashboard. For anything you can’t, email hello@armadoc.link and I’ll handle it.

Export. Because there is little to export — an account is essentially an identifier and a list of share records — I don’t run a self-service export tool. If you want a copy of what I have on file for you, email hello@armadoc.link and I’ll send it.

Deletion. To delete your account and the data tied to it, email hello@armadoc.link from the address — or with reference to the phone number — on file. I process deletion requests manually within seven business days. Deletion removes your account, your public lock, your share metadata, and any encrypted blobs that have not already expired. Application events stay in the system but are unlinked from your identity at deletion time, so they remain only as aggregate signal with no path back to you. Operational logs and rate-limit records roll off on their own existing schedules.

If you live somewhere with specific privacy laws — the EU/UK (GDPR), California (CCPA/CPRA), or anywhere else with similar protections — the rights above are how I honor those laws in practice. If your local law gives you a right I haven’t listed, you have it too. Email hello@armadoc.link and tell me what you need.

I do not sell or share personal information for cross-context behavioral advertising under any law’s definition of those terms.

How I protect what I hold

The honest version: most of the data I have about you is intentionally narrow, and the most sensitive part — your file contents — is encrypted in a way that doesn’t involve me. On top of that:

• Encryption in transit (TLS) for everything between your browser and my servers.
• Encryption at rest for stored data.
• No passwords to leak. The system uses one-time codes via email or SMS — there are no long-lived passwords stored anywhere, hashed or otherwise.
• A small set of administrative accounts with audited access. In practice, that’s me.

The Security page goes into the cryptographic detail.

Cookies and tracking

The Armadoc app sets one cookie: a session cookie, used to keep you signed in.

The marketing site at armadoc.link does not use third-party analytics, advertising pixels, or cross-site trackers. The only data collected about visits to the site is whatever Cloudflare aggregates at the edge as part of routing traffic to me — see Sub-processors above for the scope of that.

Children

Armadoc isn’t designed for, marketed to, or directed at children under 13. I don’t knowingly collect personal information from anyone under that age. If you’re a parent or guardian and you believe a child has signed up, email me and I’ll remove the account.

Things I will never do

These commitments also appear on the About page. Restating them here gives them the same standing as the rest of this policy.

• I will never train machine-learning models on your files. I could not if I wanted to — they are encrypted — but I’m saying it anyway.
• I will never sell, share, or rent your data, your contact list, or your usage patterns.
• I will never add a server-side preview feature that requires me to decrypt your files. The encryption boundary stays where it is.
• I will never quietly weaken these guarantees to grow faster. If something has to change, you’ll hear it from me first.

Changes to this policy

If I change something material — adding a sub-processor, expanding what I collect, anything that meaningfully changes the deal — I’ll email account holders before it takes effect, and I’ll bump the effective date at the top of this page. Cosmetic edits and clarifications won’t trigger an email but will still be reflected in the date.

Older versions of this policy aren’t archived publicly yet, but if you want to see what changed between two versions, email me and I’ll send you the diff.

Contact

For anything — a privacy question, a deletion request, a correction, a concern, or just “hey, this paragraph could be clearer” — the address is hello@armadoc.link. The reply will come from the same person who built and maintains the service.