Privacy policy

The short version

protcul is a free digital pillbox. It schedules the medication protocols you enter and records what you took — nothing more. It is not medical advice, it checks nothing about your medication, and it never reminds you. Use it as a memory aid alongside your own judgment and your clinician's instructions, never instead of them.

1. Who we are

protcul is operated by Reinny Almonte, an individual based in the Dominican Republic.

In the language of the GDPR, that makes Reinny Almonte the controller for the processing described here: the person who decides why and how it happens, and the person answerable for it. The companies we use to run the service — our hosting provider and our database provider (section 4) — are our processors: they handle what they hold on our instructions and for no purpose of their own. The one thing that works differently is the public issue tracker (section 8), which GitLab runs on its own account, not ours.

For anything related to privacy or your data, contact hello@movmnt.quest. We answer in plain language.

2. What protcul stores on your device

Whether you use protcul as a guest — the default — or with an account, everything you enter lives in a database inside your browser, on your device:

• your medication protocols (medication names, quantities, schedules),
• your record of doses taken or skipped,
• any profiles you create for people whose medication you manage,
• your display preferences.

As a guest, this data never leaves your device. We cannot see it, and we could not hand it over to anyone even if asked, because it is not in our possession. Nothing in it is ours to be responsible for either: you are running software on your own machine, and the data protection duties this policy describes start where data actually reaches us (from section 3 onward).

Two honest consequences of that design:

• It is stored unencrypted on the device. Anyone who can use this browser profile can read it. This is true in both modes — sync encryption (section 4) protects data in transit and on our servers, not the local copy. Your device's login, disk encryption, and browser settings are the protection boundary — we say this in the app too.
• Guest data can be lost. Clearing this browser's data, uninstalling the browser, or losing the device deletes it, and without an account there is no copy anywhere else. Export regularly — the app lets you do this at any time (see section 7).

3. What our servers see when you load the app

Our servers deliver the application itself — the pages, code, and styles. Guest use sends no health data to them, ever.

When your browser loads protcul, our hosting provider (Vercel) keeps standard server logs: your IP address, the page requested, the time, your browser type, and any technical errors. This is the same record essentially every website produces. These logs cannot contain your medication data, because that data is never transmitted in readable form. Vercel keeps them for us as our processor. We use them only to keep the service running and diagnose problems, and our hosting plan retains them for one hour, after which they are gone. Vercel's data processing agreement applies to its Pro and Enterprise plans; protcul currently runs on the free Hobby plan, so that agreement does not cover us. Moving to a plan it covers is an open item, and we would rather tell you that than imply a protection you do not have.

The legal basis for this processing, where the GDPR applies, is our legitimate interest in operating and securing the service (Art. 6(1)(f) GDPR). Because it rests on that basis rather than your permission, you can object to it — section 9 says how, and what we can realistically do about a log line that identifies nothing but an IP address.

4. Registered accounts and sync

Creating an account is optional and adds one thing: end-to-end encrypted sync across your devices. If you never create an account, nothing in this section applies to you.

Accounts shipped in 0.0.5. Before that release protcul was guest-only and nothing in this section applied to anyone; the changelog records which release brought what.

When you register, here is everything our servers store:

• A handle you choose. A pseudonymous username — not your name, not an email. We collect no email address and no directly identifying account field, anywhere in the system. The handle is stored in plaintext because the server needs it to find your account; it is never shown to other users. It cannot be changed while the account exists.
• Authentication material. A hashed verifier derived from your passphrase. Your passphrase itself never reaches us, and neither does your encryption key — both exist only on your devices.
• Encrypted records. Your data is encrypted on your device before upload. The server stores ciphertext it cannot read. A breach, a seizure, or a legal demand can yield only that ciphertext, your handle, and the metadata described below — the keys don't exist on our side.
• Record metadata. The server necessarily sees how many encrypted records of each type your account holds, how much space they take up, their opaque identifiers, and when they change. It cannot see their content, but write timing could in principle approximate your usage rhythm (for example, when you tend to mark doses), and a record's size loosely bounds how much you typed into it. We state this plainly because it is real, even though we do nothing with it.
• Account bookkeeping. A few small values the account needs in order to function: a random internal identifier for it, the date you created it, the version of the encryption settings it was set up under, and a counter that increases each time you change your passphrase, which is how your devices know which generation of keys to use. That last one means we can count how many times you have changed your passphrase — never what any of them was.
• Session records. While you are signed in, the server keeps a session entry — a hashed random token with its creation and expiry times — so it can recognize your signed-in browser (this is the server side of the cookie described in section 5). At expiry it becomes unusable and inaccessible through the application. Signing out removes the current session; an inert expired row may remain until later account maintenance or account deletion.
• Sign-in attempt counters. To slow down passphrase guessing, we keep fixed-window counters of recent sign-in attempts, keyed by a hash of the handle tried and a hash of the network (IP) address the attempt came from. They contain no health data and no plaintext IP address. Each count has an explicit expiry; after that instant it is inactive, cannot affect sign-in, and cannot be retrieved through the application. The inert row may remain until the same hashed key is attempted again, when it is replaced by a fresh window.
• Passphrase-change staging. While you change your passphrase, the server temporarily holds a small change registration and a staged copy of your records re-encrypted under the new passphrase — still ciphertext we cannot read. An open change expires after 24 hours without a successful staging step; after expiry it is inaccessible and cannot complete, and starting a new change removes the abandoned staging. When a change completes, the new copy becomes active and the old copy becomes inaccessible immediately; bounded cleanup removes the old copy during later authenticated account maintenance.

This data is stored with our database provider (Neon, Postgres) on servers located in Frankfurt, Germany, inside the European Union, and the code that reads and writes it also runs in Frankfurt on our hosting provider (Vercel). Both act as our processors, and neither is handed anything readable: what they hold is the same ciphertext we hold. Both are companies established in the United States, so their staff can in principle reach those systems from outside the European Economic Area. Vercel's data processing agreement — which carries the standard contractual clauses covering exactly that access — applies to its Pro and Enterprise plans, and protcul runs on the free Hobby plan, so it does not cover us today. Moving to a plan it covers, and confirming the equivalent position with our database provider, are both open items. We would rather say that than claim a protection you do not have. Pseudonymous identifiers and encrypted records are still personal data under the GDPR, and we treat them accordingly.

protcul is not directed at children. If you are under 16, create an account only with a parent or guardian involved. An adult who keeps a Profile for a child they care for is doing exactly what Profiles are for — that is the adult using the app, on their own device.

Why we are allowed to hold it

Each thing we hold has its own reason, so here they are one by one, where the GDPR applies:

• Delivering and securing the app itself, including the hosting logs in section 3 — our legitimate interest in keeping a service online and defending it against attack (Art. 6(1)(f) GDPR).
• Your account and sync — the handle, the authentication material, the encrypted records and their metadata — performing the service you asked us for when you created the account (Art. 6(1)(b) GDPR).
• The content of those encrypted records — this is medication data, which the GDPR treats as a special category even though it reaches us unreadable. We rely on your explicit consent (Art. 9(2)(a) GDPR), given by the deliberate, entirely optional step of creating an account and turning sync on, which the app explains before you take it. You can withdraw that consent at any time by deleting your account, which erases what we hold; withdrawing does not unmake what was lawful before it.
• Sign-in attempt counters and session records — our legitimate interest in stopping passphrase guessing and keeping accounts secure, and our duty to protect what we hold at all (Art. 6(1)(f) and Art. 32 GDPR).

Two things this list is not. It is not consent used as a shortcut: the design collects almost nothing, and consent appears here only for the encrypted health content you choose to sync — everything else stands on a basis that does not depend on permission we could pressure you for. And it involves no automated decision-making or profiling of any kind; nothing here decides anything about you.

Nothing obliges you to give us any of it. Without a handle and a passphrase there is no account, and the only consequence of that is that you use protcul as a guest, which is the default and gives up no feature except sync.

Keeping it secure, and telling you if that fails

The protection here is mostly structural rather than promised: records are encrypted on your device with keys we never receive, your passphrase reaches us only as a hash, the session cookie is secure and HTTP-only, and the database is reachable only through narrow operations that check your session and work out who you are on the server side. No system is perfect and we won't pretend otherwise.

If a breach ever did put your data at risk, we would report it to the competent supervisory authority as the GDPR requires, and we would tell you — but honestly about how. We hold no email address for you, so there is nowhere to send a message. Notice would go up on this page, in the app, and in the public changelog, promptly and in plain language.

No recovery, honestly

There is no passphrase reset and no way to recover a forgotten handle — we have no email to send anything to, and your keys never existed on our side. Your export file is your backup. The app says this at signup, and it is worth repeating here: export regularly.

5. Cookies

Registered use sets exactly one cookie: an essential, secure, HTTP-only session cookie that keeps you signed in. It lasts 30 days from the moment you sign in — signing in again issues a fresh one — and it is revoked when you sign out. It is strictly necessary for the service and is the only cookie protcul sets.

Guest use sets no cookies at all — your guest session lives in local browser storage and is never sent to us.

Because that one cookie is strictly necessary for a service you actively asked for, European rules do not require us to ask your permission for it, and there is no other cookie to ask about — which is why protcul shows no cookie banner. The same reasoning covers what the app stores on your device: that is the pillbox doing the job you opened it to do, on your own machine.

6. Analytics and tracking

None, of any kind. No product analytics, no behavioral tracking, no third-party trackers, no advertising, no crash reporters that phone home. This is a design principle, not a current setting: for health data, the data tracking would need is data we never have — guest data never leaves your device, and synced records reach us only as ciphertext we cannot read. The honest limit of that promise is the app itself: you necessarily trust the application code we serve, which is why section 10 commits to announcing any change in what we collect before it happens. The other check on us is that the code is published for anyone to read and audit, under the PolyForm Noncommercial License 1.0.0 — source-available rather than open source, and readable either way. That is auditability, not a guarantee: what your browser runs is whatever our servers send it.

7. Export, deletion, and your control

• Export: you can download your complete dataset as a file at any time, optionally protected with a password. The password is processed on your device, is never sent to us, and is never stored anywhere — so a file whose password is lost cannot be opened by you or by us. Exporting without a password produces a file readable by anyone who opens it, and the app says so before it will do it. This is your backup and your way out — the format is documented and there is no lock-in.
• Deletion (guest): the app has a "wipe my data" action that erases everything protcul stores in this browser. It asks whether you want to export first, because the deletion is irreversible.
• Deletion (registered): account deletion, available in the app, wipes the server-side ciphertext, content-free sync tombstones, handle, account bookkeeping, sessions, and passphrase-change staging, then deletes that account's local data on the device. The released handle may be registered again, by anyone on a first-come basis; that registration is a new, empty account with no link to the deleted one. While an account exists, deleting an individual Profile retains content-free sync tombstones until account deletion so an offline device cannot resurrect it; there is no soft-delete holding period.

Because your data is local-first, you exercise these controls directly in the app — there is no request to file and no one to wait for.

How long things are kept

• Everything on your device: until you remove it. A guest wipe or an account deletion takes it out immediately, and nothing on our side holds a copy of it that you cannot reach.
• Encrypted records, your handle, and the account bookkeeping: only for as long as the account exists. Account deletion removes them outright, along with your sessions and any passphrase-change staging.
• Deletion markers: when you delete a single Profile while the account continues, what stays on the server is a content-free marker — the record type, its opaque identifier, and when it was deleted, with the encrypted content erased in the same step. They exist so a device that was offline during the deletion cannot bring the data back, and they go with the account.
• Sessions: the cookie in your browser lasts 30 days from when you signed in, or until you sign out. The matching entry on our side expires after 30 days without a request from your device, so it can outlive the cookie — inert either way, because the cookie is the only thing that could ever use it. From the expiry instant the session cannot be used for anything; the leftover row may sit there until later account maintenance or account deletion clears it.
• Sign-in attempt counters: the fixed window they were opened for. After that instant the count cannot affect sign-in at all, and the row is replaced the next time the same hashed key is tried.
• Passphrase-change staging: 24 hours without progress, and immediately once the change completes or a new one starts.
• Hosting logs: one hour, the retention of our current hosting plan (section 3).
• Provider backups: our database provider keeps a 24-hour restore window on our current plan, so a deleted row can survive in it for up to a day before ageing out. We cannot reach into a backup to pick out a single record, and what is in it is ciphertext in any case.

8. Reporting an issue

If you report a bug, the app opens a prefilled issue on our public GitLab issue tracker. The prefilled template contains only technical details — app version, browser, recent error traces — never your protocols or completion records, and you can inspect and edit everything before submitting.

Be aware of the boundary: the tracker is public and run by GitLab, outside protcul. Anything you write there is visible to everyone and covered by GitLab's privacy policy, not this one. GitLab is not our processor here — it runs that tracker as its own controller, and your dealings there are with GitLab. Don't include personal or health details in an issue. protcul itself transmits nothing — submission happens on GitLab, by you.

9. Your rights

Where the GDPR applies, you have rights of access, rectification, erasure, restriction, portability, and objection, the right to withdraw a consent you gave, and the right to lodge a complaint with your local supervisory authority.

For your local and synced domain records, these rights are built into the product: you can read them (access), edit them (rectification), export them in a documented format (portability), and wipe them or delete your account (erasure) — directly, without asking us. We cannot read, correct, or selectively extract synced records on your behalf: they are ciphertext to us, and only your devices hold the keys.

Withdrawing consent works the same way: the only thing we hold on your consent is the content of your synced records (section 4), and withdrawing is deleting your account — one action in the app, effective at once.

The in-app controls do not expose operational hosting logs or inactive sign-in/session counters. For a rights request about those records, or to object to the log processing in section 3, contact hello@movmnt.quest. We will assess and act on the request where the right applies and the record can reasonably be linked to you; hosting logs generally cannot be identified beyond an IP address, and sign-in counters retain only hashed handle/IP keys. We answer within one month, as the GDPR requires, and if something is genuinely complicated we will tell you that — and why — before the month is out rather than going quiet.

10. Changes to this policy

If this policy changes, the new version is published on this page with an updated date, and the change is listed in the app's public changelog. We will never change this policy to quietly start collecting what this version says we don't. A change that expands what we process would be communicated clearly before it takes effect.