Privacy Policy

This Privacy Policy explains what personal data ShieldFive collects, why we process it, how long we keep it, and the rights you have over it. It is written to satisfy the disclosure requirements of the EU General Data Protection Regulation (Regulation (EU) 2016/679, “GDPR”) and the Spanish Organic Law on Personal Data Protection (LO 3/2018, “LOPDGDD”). It supplements the Terms of Service; in the event of conflict regarding the processing of personal data, this Privacy Policy controls.

1. Who we are

The data controller for personal data processed in connection with the ShieldFive service is Cho García, individual operator of the project, based in Spain, reachable at [email protected]. ShieldFive is currently a pre-incorporation operation; the operator will register a formal legal entity (autónomo or sociedad limitada) as the service scales, at which point this section will be updated with the registered entity’s full details. A postal address is available on written request to the Spanish Data Protection Authority (AEPD) or to data subjects exercising their rights under Articles 15–22 GDPR.

ShieldFive has not appointed a Data Protection Officer (DPO). Under Art. 37 GDPR a DPO is mandatory only for public authorities, controllers whose core activity consists of large-scale systematic monitoring of data subjects, or large-scale processing of special-category data — none of which applies to ShieldFive at current scale. We will revisit this if the threshold becomes relevant.

2. Scope

This Privacy Policy applies to the ShieldFive web application at shieldfive.com, the browser-based vault clients served from that origin, the ShieldFive Android and iOS apps, the public marketing pages, share-link recipient pages, and any HTTP API exposed under the same domain. It does not apply to third-party services we link to (for example external blog posts, GitHub repositories, or partner websites), which are governed by their own privacy policies.

3. What data we process

The categories of personal data we hold are as follows. Each category lists the actual fields visible in the database schema or in the third-party platforms that store them.

3.1 Account data

Email address (used as login and for transactional notices)
A password verifier managed by our authentication provider. Sign-in sends your email and a login value your browser derives from your password with Argon2id over HTTPS; the password itself is not sent. The key that unlocks your vault is derived separately and stays on your device.
Account creation timestamp and last sign-in timestamp
Multi-factor authentication state (whether TOTP is enrolled, the encrypted factor record — never the secret itself in cleartext)
Display preferences (interface locale, theme) and what the account signed up to do (store your own files, or collect documents from clients), which decides where you land and which reminder you get
From 30 October 2026: where the signup came from — the ShieldFive page the visit started on, the host name of the site that linked to it (for example www.bing.com, never the full address), and any campaign tags on our own links (utm_source, utm_medium, utm_campaign). Recorded once, at signup, on accounts created from that date; accounts created earlier are not backfilled. It is used to learn which pages and channels lead to accounts that use and pay for the service, and it is deleted with the account
Answers you choose to give to the optional questions in the app: what kind of work you do, roughly how many clients you collect documents from each month, and, in your own words, how you heard about ShieldFive. Nothing is recorded if you skip them. They are held on the account, never sent to an analytics provider, and deleted with the account

3.2 Vault and recovery metadata

Wrapped vault master key (ciphertext only — unwrapping requires a locally derived key or your recovery key)
Recovery-key acknowledgement timestamp (a marker that the user has been shown the recovery key — the recovery key itself is never sent to the server)
Plan tier and quota state

3.3 File metadata

File identifiers (UUIDs)
Wrapped per-file content keys (ciphertext only)
Encrypted file and folder names (ciphertext only)
Ciphertext size, MIME hint, and upload status
Created, modified, and (where applicable) trash timestamps
The opaque object key of the ciphertext blob stored at the cloud object-storage layer

3.4 Share metadata

Share link identifier, expiry, and maximum download count
Optional bcrypt hash of a share-link password set by the sender
Optional country-allow list (geographic gate)
Share-access events (hashed visitor IP, timestamp, user-agent class) retained for abuse detection

3.5 Billing data

Payment-processor customer identifier and subscription state
Plan price identifier, renewal date, and invoice history (held by the payment processor)
Cardholder data is processed exclusively by the payment processor and never transits ShieldFive servers. Payment instruments are tokenised in the customer’s browser before any network call to ShieldFive.

3.6 Operational telemetry

Request logs at the hosting layer (status code, route, response time — without request bodies)
Rate-limit counters keyed to hashed user identifiers and hashed IPs
Error events reported to our error-monitoring provider, with PII redaction applied at the source per the published redaction schedule
Anonymous page-view measurement — cookieless, and switchable off at any time from Your privacy choices below
Analytics are never linked to an account identifier. The signup-source record in 3.1 is held on the account itself and is not sent to any analytics provider
Browser error monitoring and campaign-attribution cookies, which run only after you explicitly accept the privacy prompt on first visit

3.7 Support correspondence

Email content and metadata when you write to [email protected] or [email protected], retained for the lifetime of the ticket plus a short archive window.

3.8 Consent and privileged-operation records

The two record types below store the full IP address and user-agent stringof the request, not a hash. Everywhere else in this policy where an IP is mentioned — share-access events (3.4) and rate-limit counters (3.6) — it is hashed. These two are the exceptions, because their purpose is evidentiary: a hash cannot be produced later as proof of who did what.

Consent records: written once when you create an account. Each row holds the Terms of Service and Privacy Policy version you accepted, your attestation that you are old enough to consent on your own behalf, the acceptance timestamp, and the IP address and user agent the signup request came from. The record is the evidence of consent required by GDPR Art. 7(1) and of the age check required by Art. 8; it is kept for the life of the account and deleted with it (see section 6).
Audit-log entries for privileged operations: written when a security- or billing-relevant action runs on your account — account deletion, e-mail change, MFA unenrolment, recovery-key acknowledgement, session-device revocation, share creation, checkout and subscription webhook processing. Each entry holds the action name, the account it applies to, a small structured metadata object, and the IP address and user agent of the request. See section 6 for how long these are kept.
Audit-log entries for document-request activity: three further kinds of entry are written for the document-request feature, in the same table and under the same retention. A seat refusalrecords that a firm was refused an additional seat, with the firm identifier and the seat counts it was refused on — and nothing at all about the person who was being invited, not even a hash of their address. A message recordis written for each e-mail the service sends, holding the message kind, our delivery provider’s message id, whether the send succeeded, and a one-way hash of the recipient address — never the address itself. And when a document-request link is opened, we record that it was opened, which request it belongs to, and the browser user agent that opened it — no IP address, and nothing that identifies the person. That last one is written for someone who is usually a client of the firm and has no account with us: it exists so the firm that sent the link can tell whether it was ever opened, which is otherwise invisible to them and to us.

3.9 AI assistant connections

If you connect an AI assistant to your vault (Settings → AI assistants), the assistant works through the ShieldFive MCP server, which runs on your own computer and decrypts there. We keep two kinds of record about the connection. Neither contains a file name or file content in the clear, an IP address or a user agent.

Connection records: the name you give the connection, which assistant it says it is for, the permissions you granted (read, organize, add files), the identifiers of the folders in scope, the upload allowance and how much of it has been used, the expiry, and when it was created, activated and revoked. We store a hash of the connection’s token, never the token, and folder and file keys wrapped so that only the connection can open them — we cannot.
Activity records: one row for every request the connection makes, including refused ones — the action, the identifiers of the files or folders involved, the result and the time, and for a change the encrypted fields needed to undo it.

What an assistant reads through a connection is decrypted on your computer and handed to the assistant you use. It goes to whoever runs that assistant, under their terms, as anything else you put in that conversation would. It does not pass through us, and we do not receive it.

4. What we do not have

The file upload and download paths encrypt and decrypt on your device. They do not send plaintext file contents, plaintext file or folder names, unwrapped vault keys or unwrapped file keys to our storage service. Your recovery key is used locally.

Authentication is a separate operation: only the derived login value described in section 3.1 is processed by our authentication service, so we do not receive your password or your keys. The app code is delivered by us, so the client we serve on each visit remains part of the trust model. Accounts created before this change migrate at their next sign-in, and that one sign-in still sends the password so it can be verified.

Android app permissions and local storage

You choose which photos, videos and documents to back up. Android photo and video access lets the app find selected media; access to original media location metadata preserves embedded tags when restoring a photo. We do not request your current device location. Files and their embedded tags are encrypted before upload. Backup runs while the app is open.

Session tokens and vault keys are kept in protected device storage. Imports, previews and exported copies use private app storage. Pending imports can remain for retry; decrypted previews and exports are cleared on cold start and sign-out. Copies you choose to save in another app are controlled by that app. Local originals are removed only after backup verification and your confirmation through Android.

The production Android app sends scrubbed JavaScript error events to Sentry. Native crash reports are not collected. File names, passwords, tokens, request bodies and breadcrumbs are removed from those events. Production performance tracing and session replay are not enabled. We use diagnostics to investigate failures, not for advertising.

To delete your account and associated data, follow the steps on our account deletion page. You can make the request without installing the app.

5. Why we process it and on what legal basis

Category	Purpose	Legal basis (GDPR Art. 6)
Account, vault, file, and share metadata	Operate the service, authenticate the user, deliver the ciphertext storage and share features you have signed up for	Art. 6(1)(b) — performance of a contract
Billing data	Charge subscriptions, issue invoices, handle refunds and disputes	Art. 6(1)(b) — performance of a contract; Art. 6(1)(c) — compliance with Spanish tax law
Hashed IPs in share-event logs; rate-limit counters; error monitoring	Detect and prevent abuse, denial-of-service, brute-force attempts, and service failures	Art. 6(1)(f) — legitimate interest in maintaining the integrity and availability of the service
Anonymous page-view measurement	Understand which pages are used, in aggregate, to improve the product	Art. 6(1)(f) — legitimate interest in understanding how the site is used. No information is stored on or read from your device for this purpose, so Art. 22.2 LSSI-CE does not apply; you may object at any time from Your privacy choices
Browser error monitoring and campaign-attribution cookies	Surface browser-side errors, and connect a signup to the campaign it came from	Art. 6(1)(a) — consent (opt-in via the privacy prompt shown on first visit; rejection or no choice blocks transmission)
Signup source (3.1, from 30 October 2026)	Learn which pages and channels lead to accounts that use and pay for the service, so marketing effort goes where it works	Art. 6(1)(f) — legitimate interest in measuring which of our own pages and channels work. The record is coarse (a page, a host name, our own campaign tags), is never shared with an advertiser or analytics provider, and is deleted with the account; you may object at any time using any of the routes in section 9, and we will remove it
Optional in-app answers (3.1)	Learn who uses the service and how they found it, so the product and its marketing are built for them	Art. 6(1)(a) — consent, given by choosing to answer. You can withdraw it at any time using any of the routes in section 9, and we will delete the answers
Support correspondence	Respond to inbound questions and incident reports	Art. 6(1)(b) — performance of a contract; Art. 6(1)(f) — legitimate interest in addressing your request
Audit logs of privileged operations	Forensic readiness and incident investigation	Art. 6(1)(c) — compliance with security obligations; Art. 6(1)(f) — legitimate interest in security

Other than the browser error monitoring and campaign-attribution cookies described above, which run only with your consent, and the optional answers you choose to give, we do not rely on consent (Art. 6(1)(a)) as a legal basis for any current processing activity. We do not engage in advertising profiling, cross-site tracking, or sale of personal data.

6. How long we keep your data

Account data: retained while your account is active. When you delete your account through the dashboard or via the /api/delete-account/ endpoint, account records, file rows, share rows, share-event rows, consent records (3.8), and stored ciphertext blobs are deleted within the same request, and the subscription (if any) is cancelled in the same transaction. The signup-source record (3.1) is part of the account record and is deleted with it.
Consent records: kept for as long as the account exists, then destroyed with it. They are not purged on a timer: a consent record that outlives the account proves nothing, and one that expires before the account does leaves the lawful basis for the account undocumented.
Files in the trash bin: until you empty the trash, or until the account is deleted. Nothing removes them on a timer. scripts/purgeLifecycle.ts does contain a bin purge, but it runs only when the script is invoked without --reap-only, and the one scheduled job that calls it (.github/workflows/retention.yml) passes that flag — so the purge is never reached on a schedule. Emptying the trash from the vault removes the ciphertext blob from object storage and hard-deletes the row; deleting the account removes both along with everything else.
Deleted ciphertext in object storage: when a file leaves your vault (emptying the trash, deleting a file permanently, or deleting the account), the storage provider keeps the deleted version of its encrypted blob for up to 30 days as a recovery window against accidental or malicious deletion, and then erases it. The disaster-recovery copy in a separate storage account mirrors each deletion on its nightly run and erases the deleted version within 60 days. Both copies are the same ciphertext the service already stores; neither is readable or restorable from your account.
Share-access event rows: 30 days, after which they are purged by scripts/cleanupShareEvents.ts / scripts/purgeLifecycle.ts using the purge_share_events_before RPC.
AI assistant connection and activity records (3.9): kept for as long as your account exists, including after a connection is revoked or expires, so that what it did stays visible and undoable in Settings → AI assistants. They are deleted with your account.
Application audit log: retained indefinitely, and not erased when you delete your account. The same immutability applies as to the service-role log below: DELETE, UPDATE and TRUNCATE are revoked from every role including the service role, and a database trigger refuses them, so no retention job can remove a row. The schema documents a seven-year retention target and nothing implements it. An earlier version of this policy said these entries were kept for 90 days. That was not true when it was written and is not true now — rows from the first weeks of the service are still present. Unlike the service-role log, these rows carry the account identifier, and for the privileged operations in section 3 the IP address and user agent as well.
Service-role audit log: retained indefinitely, and not erased when you delete your account. This table is append-only by design: a database trigger refuses every DELETE and UPDATE, and the service role holds no DELETE grant, so no retention job can remove a row without first weakening the control that makes the log worth keeping. An earlier version of this policy described a 90-day purge run by a named script. That script does not exist and the purge function it would have used was dropped, for exactly this reason.
Each row records one privileged server-side operation — a billing webhook, a session revocation, an erasure carried out under section 8 — together with the account identifier it acted on and identifiers and counts describing it: file ids, share slugs, row counts, byte sizes, subscription and price ids. It never contains file contents, filenames, or keys. A record that an erasure was carried out has to outlive the account it erased, or it cannot evidence that the erasure happened.
Billing records: retained while the account is active, plus the minimum period required by Spanish commercial-tax law from the date of each invoice — currently 4 years for VAT records and 6 years for accounting records. When the operator formally registers a legal entity, this retention schedule will be reconfirmed and updated here if needed.
Database backups: point-in-time recovery and daily logical dumps are retained per the database provider’s configured backup window, ordinarily measured in days rather than months.
Error monitoring events: retained per the monitoring provider’s plan default, with field-level redaction applied at the source.

To deliver the service we share limited categories of personal data with third-party infrastructure providers that act as data processors on our instructions. We share only what each category of recipient needs to perform its function. We do not sell personal data and we do not provide bulk access to any third party.

One advertising recipient exists and we state it plainly rather than by omission: if you accepted the consent prompt and arrived from a Google or Microsoft Bing ad, we may send Google Ads or Microsoft Advertising a conversion event containing the ad-click identifier from the sf_gclid cookie (see section 13) together with the fact and value of a signup or subscription. We do not send either of them your email address, your files, your filenames, or any vault content. If you reject the consent prompt, no click identifier is stored and no conversion is ever sent.

The provider of an AI assistant you connect to your vault is not a recipient of ours. What the assistant reads is decrypted on your computer and sent by the assistant you chose, under that provider’s terms (see 3.9); we cannot read it and do not send it.

The categories of recipient are:

Cloud infrastructure providers (hosting, edge delivery, database, object storage) — receive encrypted file blobs and the account / file metadata necessary to operate the service. None of these recipients receives unencrypted file content or unwrapped keys; file content is end-to-end encrypted before it leaves your browser or mobile app.
Payment processor — receives the billing data necessary to charge subscriptions and issue invoices. We never receive or store card numbers; payment instruments are tokenised at the payment processor.
Error-monitoring provider — receives application error events with personal-data redaction applied per the security posture published at /security.
Email-delivery provider — receives the recipient address and message content for transactional email (sign-up confirmation, password reset, billing receipts, security notices).
Abuse-prevention and rate-limit infrastructure — receives hashed IP addresses and rate-limit counters used for security telemetry, plus short-lived challenge tokens used to defend the sign-up and share-link flows against automated abuse.
Public breach-lookup services— the free breach checker at /tools/breach-checker queries two independent third parties directly from your browser, and only after you tick the consent box on that page. XposedOrNotreceives the email address you type — their lookup API is GET-only and takes the address in the request URL, so that is the form in which they receive it. Have I Been Pwnedreceives only the first five characters of your password’s SHA-1 hash (k-anonymity) — never the password and no identifier. There is no ShieldFive server in either path: we do not receive, log, or store what you enter, and nothing is sent if you do not consent. These are recipients of what you voluntarily submit on a public tool page, not sub-processors of account data; both are named in Annex III.

The full named list of sub-processors, with their purpose and processing location, is published in Annex III of our Data Processing Agreement. Business customers can execute that DPA at any time — email [email protected] to countersign.

Beyond these recipients, we disclose personal data only when legally compelled (court order, valid law-enforcement request) or to defend legal claims, and only the minimum metadata necessary — never plaintext content, which we cannot produce.

8. International transfers

Personal data we hold is primarily processed in the European Economic Area. Each sub-processor receiving personal data outside the EEA does so under Standard Contractual Clauses (2021)or an equivalent transfer mechanism approved by the European Commission, supplemented by adequacy decisions where available (for example the EU-US Data Privacy Framework for recipients that have certified to it). Encrypted file blobs that move through non-EEA infrastructure are ciphertext only; from that infrastructure’s point of view the content is unintelligible.

9. Your rights

Under the GDPR, you have the right to:

Access (Art. 15)— request a copy of the personal data we hold about you. Requests are fulfilled manually within the GDPR’s statutory one-month window; if a self-service export endpoint becomes available, this section will note it.
Rectification (Art. 16) — correct inaccurate personal data (most editable fields are available in the in-app profile).
Erasure (Art. 17) — delete your account via the dashboard or by emailing [email protected]. Deletion is irreversible and cascades to ciphertext blobs.
Restriction (Art. 18) — ask us to temporarily stop processing your data pending the resolution of a dispute about its accuracy or lawfulness.
Portability (Art. 20) — receive the data you have provided to us in a structured, commonly used, machine-readable format.
Objection (Art. 21) — object to processing that relies on legitimate interest, including abuse-detection telemetry.
Withdraw consent (Art. 7(3)) — applicable only where we rely on consent; not currently used for any processing activity.

To exercise any of these rights, write to [email protected]. We respond within the GDPR’s one-month default window. We may ask you to verify control of the account before fulfilling a request that would expose personal data. Business customers requiring a Data Processing Agreement to govern processing for their organisation may request one via the same address.

10. Right to complain

If you believe our processing of your personal data is unlawful, you have the right to lodge a complaint with a supervisory authority. For users in Spain, that authority is the Agencia Española de Protección de Datos (AEPD), aepd.es. Users elsewhere in the European Economic Area may complain to the supervisory authority of their habitual residence or place of work. We’d much rather hear from you first at [email protected] — but the right exists regardless.

11. Automated decision-making

We do not make decisions about you that produce legal or similarly significant effects on a solely automated basis within the meaning of Art. 22 GDPR. Rate-limiting and abuse-detection thresholds are programmatic but reversible on appeal.

12. Children

ShieldFive is not intended for children under 16, the default minimum age for digital-services consent under Art. 8 GDPR (some Member States set this lower, but ShieldFive applies the 16-year threshold uniformly). We do not knowingly collect personal data from children. If you believe a child has registered an account, contact [email protected] and we will terminate it.

13. Cookies and similar technologies

We rely on a minimal set of first-party cookies and similar storage strictly necessary to deliver the service:

Authentication session cookies — keep you signed in.
Locale preference cookie (sf_locale) — remembers your selected interface language.
CSRF cookies set by authentication and payment flows.
Sign-up hand-off — after you confirm your email, a cookie (sf_confirmed_email, 10 minutes, readable only by our sign-in endpoint and deleted when read) fills your address into the sign-in form. While you sign up or check out, the address you typed and any billing details you have not submitted yet are kept in this browser tab’s session storage, so a reload does not lose them. They are not sent to us until you submit, and are cleared when the tab closes or the details are saved.

These are strictly necessary cookies under Art. 22.2 of the LSSI-CE and do not require prior consent. We do not embed cross-site tracking pixels and do not use Google Analytics. The bot-protection challenge used on sign-up and share-link flows may set a short-lived first-party token to remember a successful challenge; it is strictly necessary for the security purpose and does not feed any advertising network.

In addition we use one consent cookie:

Privacy-choice cookie (sf-consent) — records your choice on the privacy prompt shown on first visit, or in Your privacy choices below. It is set only when you make a choice and stores one of three values: accepted (anonymous measurement, browser error monitoring and campaign-attribution cookies all on), measurement (anonymous measurement only), or rejected (all of it off, including anonymous page-view measurement). One thing is counted whichever you pick, including rejected: the choice itself, as a daily tally of how many people chose each option. That tally carries no identifier, no page, and no timestamp beyond the day — it cannot be traced to you, and it exists so we can tell what share of visitors decline measurement. While no choice is stored, anonymous page-view measurement runs — it places nothing on your device, as described below — and browser error monitoring and the attribution cookies stay inert until you accept.

Anonymous page-view measurement is provided by Vercel Web Analytics and is cookieless: it sets no cookie and writes nothing to your browser’s storage. A visit is identified by a hash derived from the request, and the salt behind that hash is regenerated every day, so the resulting count cannot connect you to your visit yesterday, to another device, or to any other website. Because nothing is stored on or read from your device, Art. 22.2 of the LSSI-CE does not require prior consent for it; we rely on Art. 6(1)(f) GDPR and give you the objection route required by Art. 21 in Your privacy choices. The one exception is the exclusion flag set if you visit /ignore-me: that is a value you write yourself, read only to honour the exclusion you asked for.

On the two pages where someone who is not our customer meets ShieldFive — the upload page of a document request (/r/…) and a Secure Forms response page (/form/…) — we count how often the “create your own” invitation is shown and how often it is pressed. That count is a shared daily total per page, not a record of your visit: the database row is a date, the name of the page, the name of the event, and a number. There is no identifier of any kind in it — no account, no IP, no device, no session, no hash — and no per-visitor row is written, so there is nothing about you to look up, export or erase. Pressing the invitation increments a counter that thousands of other people also increment. Because nothing there identifies anyone, it is not personal data, and it is kept indefinitely for the same reason.

If — and only if — you accept the consent prompt, we also set two first-party marketing-attribution cookies. Both are written on the client, are never set before you accept, and are not set at all if you reject:

Campaign-attribution cookie (sf_utm, 90 days) — records the utm_source / utm_medium / utm_campaign parameters of the first page you landed on, so that if you later create an account we can tell which campaign it came from.
Ad-click cookie (sf_gclid, 90 days) — records the Google Ads click identifier (gclid) or the Microsoft Advertising click identifier (msclkid) from the landing URL. If you later create an account or subscribe, that identifier may be sent to the ad network it came from as an offline conversion, so it can attribute the signup to the ad you clicked. This means Google Ads or Microsoft Advertising is a recipient of that conversion event; see section 7.

Neither cookie stores your files, filenames, keys or any vault content, and neither is readable by a third party from your browser — they are first-party and are only ever transmitted by us, to Google Ads or Microsoft Advertising, in the conversion export described above.

14. Security

The technical and organisational measures we apply to protect your data are summarised on the public /security page and tracked in the public build log at /build-log. In summary: client-side encryption with per-file content keys; new web and Android uploads use a post-quantum hybrid suite by default (ML-KEM-1024 + XChaCha20-Poly1305, joined by an HKDF-SHA-256 combiner), with a documented AES-256-GCM fallback. Android reads both formats. Older AES files remain readable. New vaults use Argon2id password stretching; legacy PBKDF2 vaults remain supported. Other measures include TLS 1.3 in transit; strict CSP; MFA support; rate-limiting; audit logging; and a published responsible-disclosure programme.

15. Changes to this policy

Material changes will be announced via email to the address associated with your account and via a build-log entry, at least 30 days before they take effect. Minor edits (clarifications, typo fixes) are made on a rolling basis; the “Last updated” date at the top reflects the most recent change.

Pending change. The 29 September 2026 revision adds the signup-source record in section 3.1, with its purpose and legal basis in section 5 and its retention in section 6. It takes effect on 30 October 2026; nothing is recorded under it before then.

16. Contact

For any privacy-related question or to exercise any of the rights described above, write to [email protected]. General product questions go to [email protected].