One Time Secret - Tool - by Alexandru Jungean
Privacy Policy
RomânăGDPR information about what this service processes, what it never sees, how long data lasts, and your rights.
Version 1.1.0 · Effective 22 August 2026
This Privacy Policy explains how Alexandru Jungean (“Operator”, “we”, “us”) processes personal data when you use One Time Secret - Tool - by Alexandru Jungean at https://secret.alexjungean.com (the “Service”). It is the Article 13 / 14 GDPR notice for this Service.
Read it with the Terms of Use, Cookies and Local Storage, Infrastructure and Subprocessors, and, if you are a professional customer, the Data Processing Addendum. The Romanian text is at Politică de confidențialitate.
This Policy describes the shipped architecture. It does not claim a certification, perfect secrecy, recipient identity, or exactly-once delivery. Browser encryption and at-most-once server release are implemented as documented in the public product contracts and covered by automated tests.
1. Who is the controller
The controller for operational data of this Service is Alexandru Jungean, a natural person established in Romania, European Union. Contact: alex.jungean@gmail.com. There is no appointed data-protection officer. A postal address for official and data-subject correspondence is provided on verified request, as stated in the Legal Notice.
When a professional customer uses the Service to host ciphertext that contains personal data of others, that customer is the controller of that content and the Operator is a processor for that ciphertext only. Those roles are set out in the Data Processing Addendum. Hashed rate-limit identities and application privacy logs remain under the Operator as controller.
2. Scope and what we never process
The Service has no accounts, no profiles, no marketing list, no payment data, no recipient directory, and no application cookies. Create and reveal pages load no analytics, tag manager, captcha widget, font CDN, or other third-party script.
The following never leave the browser as part of the application protocol and are never stored by the Operator: plaintext; the AES key; the raw lookup proof (the server stores only a 32-byte HMAC verifier); the URL fragment; and the full capability link. The create interface sends only the public identifier, the proof (used once to build the verifier and then discarded), the chosen expiry hours, and the versioned envelope. The reveal interface sends only the public identifier and the proof.
3. Categories of data we do process
Application-layer processing. Infrastructure logs of processors are described in section 7.
| Category | What it is | Why | Retention |
|---|---|---|---|
| Ciphertext envelope | Versioned AES-256-GCM blob, nonce, authenticated associated data bound to the public identifier, envelope version | Host the secret until Reveal or expiry, then release at most once | Until successful Reveal or expiry (1 hour, 24 hours, 3 days, or 7 days). Physical delete within 6 hours after expiry |
| Public identifier | Non-secret 16-byte path identifier stored as the primary key | Address the row for create/reveal and bind authenticated data | Same as the envelope |
| HMAC verifier | 32-byte keyed hash of the lookup proof, plus key version | Authorize the single disclosure without storing the raw proof | Same as the envelope |
| Timestamps | Created and expiry timestamps from database clock | Enforce TTL and purge | Same as the envelope |
| Hashed rate-limit identity | SHA-256 bucket over a server key, the create/reveal kind, and the platform connection address. No raw address column | Abuse control (5 create / 20 reveal per hour per identity). Fail closed at 4096 live buckets | Until the one-hour window reset, then hourly purge |
| Application privacy log | Request identifier, route template, status, duration, generic error class | Operate and debug the Service without capability material | Hosting-provider log retention (see section 7). Not joined to secret rows |
| DSA or rights correspondence | Whatever you send to the contact email | Respond to notices, rights requests, and legal process | For the time needed to handle the matter and any legal hold |
Forbidden on the secret table and in any related persistence: plaintext, AES key, raw proof, fragment, full capability URL, raw IP, user-agent, recipient identity, and unused envelope JSON copies.
4. Is ciphertext personal data? Article 11
Encrypted data can still be personal data if it relates to an identified or identifiable person. The Operator cannot decrypt an envelope and cannot identify the author or recipient from the secret row. A public identifier plus a valid proof is a bearer capability, not an identity.
Under Article 11 GDPR, where the Operator is not in a position to identify a data subject, Articles 15 to 20 do not apply except to the extent you provide additional information that enables identification. If you cannot show that a row is yours (for example by presenting the public identifier while it still exists and proving control in a way that does not require us to log capability material), we will tell you that we cannot identify you and will not search indiscriminately.
Do not send us plaintext, AES keys, raw proofs, or full capability links in email. Describe the issue with a public identifier only when necessary, and use the Illegal Content Notices process for alleged illegal content.
5. Legal bases (Article 6 GDPR)
| Processing | Legal basis | Notes |
|---|---|---|
| Hosting and at-most-once disclosure of an envelope you asked us to store | Art. 6(1)(b) contract | Accepting the Terms and clicking Create / Reveal is the request to perform that contract. We do not use a separate marketing consent. |
| Hashed rate-limit identities and cross-site POST rejection | Art. 6(1)(f) legitimate interests | Interest: keep a free anonymous tool from being flooded or used as an open relay. Balancing: no raw IP stored on application tables; short TTL; fail-closed cap; not used for profiling. |
| Application privacy logs | Art. 6(1)(f) legitimate interests | Interest: operate, secure, and diagnose the Service. Allowlist only; no capability material. |
| Responding to a valid legal order or DSA notice that identifies a row | Art. 6(1)(c) legal obligation, and where applicable Art. 6(1)(f) | We can delete or, if still present, produce the stored allowlist fields. We cannot produce plaintext. |
| Email you send us | Art. 6(1)(b) or 6(1)(f), depending on the request | You choose what to write. Do not include secrets. |
We do not process special-category data as a readable category. If you encrypt special-category data inside plaintext, we cannot see it. We do not seek Article 9 consent because we cannot know the meaning of an envelope. You must not submit content you are not allowed to process.
We do not take automated decisions that produce legal effects concerning you within the meaning of Article 22. Rate limiting is a technical throttle on request volume.
7. Recipients and processors
We do not sell personal data. We do not share secret rows with advertisers. Recipients are limited to:
- Netlify, Inc. — application hosting, TLS termination, CDN, serverless runtime, operational logs. Privacy: https://www.netlify.com/privacy/.
- Supabase, Inc. (managed PostgreSQL on Amazon Web Services) — durable storage of the secret-row allowlist and hashed rate-limit buckets, region eu-west-1 (Ireland, EEA). Privacy: https://supabase.com/privacy.
- Google LLC (Search Console) — DNS-only property verification and crawl of pages we mark indexable; no application script, tag, or analytics. Privacy: https://policies.google.com/privacy.
- A person who presents a valid lookup proof — receives the envelope at most once, then decrypts locally if they also have the AES key.
- Competent authorities, when a legally binding order requires it and a row still exists.
The public list is Infrastructure and Subprocessors. The Operator’s application does not use the Supabase Data API for disclosure; disclosure is a single elevated delete-and-return from the application server.
8. International transfers
Secret rows and hashed rate-limit buckets are stored in Ireland (EEA). The application runtime and CDN are provided by a United States company (Netlify) and may process connection metadata and application privacy logs in the United States or at global edge locations.
Where a transfer to a third country occurs, it relies on an adequacy decision if one applies (including the EU–US Data Privacy Framework for certified importers) and otherwise on the European Commission’s standard contractual clauses and supplementary measures implemented by that processor. Google Search Console, if it processes verification or crawl data, is likewise a US recipient limited to indexable first-party pages. Reveal routes and APIs are noindex and are not submitted as secret-bearing sitemap entries.
9. Retention and deletion
- Authorization to disclose a row stops at database expiry. A successful Reveal deletes the row immediately.
- Expired secret rows are physically deleted within 6 hours by an in-database hourly job. There is no HTTP purge endpoint.
- Expired rate-limit buckets are deleted hourly.
- After delete, we cannot restore the envelope. A lost reveal response after commit has the same effect.
- Email correspondence is kept only as long as needed for the request and legal holds.
10. Security measures
Measures that exist in the shipped Service include: browser-only AES-256-GCM with a unique nonce and authenticated associated data; fragment-only proof and key; HMAC verifier with version-bound keys and constant-time compare; atomic delete-and-return; deny-all row-level security for public database roles; first-party Content-Security-Policy; no-referrer; no-store; no third-party scripts on create/reveal; generic API error bodies; privacy-denylist logging; TLS to the site and to the database in live production; and rate limits. Details of encodings are engineering contracts, not a public invitation to extract secrets.
Report vulnerabilities under the Vulnerability Disclosure Policy. Do not test in a way that consumes other people’s envelopes.
11. Your rights
You may request access, rectification, erasure, restriction, objection (for legitimate-interest processing), and portability, and you may lodge a complaint with a supervisory authority. Contact alex.jungean@gmail.com. Because of Article 11 and the at-most-once design, we usually cannot locate or amend an envelope, and we cannot decrypt it.
The lead supervisory authority for the Operator is Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP), B-dul G-ral. Gheorghe Magheru 28-30, Sector 1, 010336 București, Romania, https://www.dataprotection.ro/, anspdcp@dataprotection.ro. You may also complain to the authority of your EU habitual residence or place of work.
You may object to hashed rate-limiting only by not using the Service. Turning it off for one person would disable abuse control for a bearer protocol.
12. Children
The Service is for users aged 16 or over. We do not knowingly collect identity data from children. If you believe a child has been identified in correspondence, contact us and we will delete that correspondence.
13. Changes
Material changes get a new version and effective date on this page. Version 1.1.0, effective 22 August 2026. Continued use after that date is acceptance. If you do not agree, stop using the Service. Old envelopes continue under their existing expiry; we cannot rewrite history we cannot read.