Privacy Policy
Officially Useless
Last updated: 28 June 2026
We sell novelty "officially useless" certificates — joke achievements like Certified Overthinker or World's Okayest Developer — as a digital PDF and, optionally, printed and framed. They are for entertainment only and are not a real qualification, accreditation, diploma, or official document.
This policy explains what personal data we collect, why, who we share it with, and the rights you have. It applies to officiallyuseless.com and our API at api.officiallyuseless.com.
1. Who we are (the data controller)
The data controller responsible for your personal data is:
- Legal entity: Arturs Vanags
- Registered address: Rīga, Latvia (full registered address available on request via support@officiallyuseless.com)
- Country of establishment: Latvia
- Company registration number: Not applicable — sole trader (self-employed individual), not a registered company
- VAT number: Not applicable — not registered for VAT (PVN)
- Privacy contact: support@officiallyuseless.com
We have not appointed a Data Protection Officer (not required at our scale); privacy questions go to support@officiallyuseless.com. We are established in the EU (Latvia), so an Article 27 GDPR EU representative is not required.
2. The short version
- We collect the bare minimum to take your order, make your certificate, deliver it, and let people verify it.
- The certificate title and subtitle are shown publicly on the verification page — by design. That is the whole point of a verifiable certificate. The recipient name is not shown there; it appears only on the certificate itself, which we deliver to you. Please don't put anything in the title you wouldn't want the world to read.
- We never see or store your card details — Stripe handles payments.
- If you choose on-chain anchoring, a fingerprint (hash) of your certificate PDF and its public ID are written to a public blockchain. That record is permanent and cannot be deleted — but no name, email, or address is ever written on-chain.
- We host in the EU and use a handful of well-known providers, listed in full below.
- You have GDPR rights (access, deletion, etc.). Email us to use them.
3. What we collect, why, and our lawful basis
We only collect what we need. Here is the full list, grounded in what our systems actually store and do.
3.1 Account & sign-in data
| Data | Why we process it | Lawful basis (GDPR Art. 6) |
|---|---|---|
| Email address (login identity) | To create your account, sign you in via passwordless magic link or Google, and be the key that ties your orders together | Performance of a contract — Art. 6(1)(b) |
| Display name and (for Google sign-in) avatar/profile picture URL | Your user-facing profile | Performance of a contract — Art. 6(1)(b) |
Google account identifier (sub), Google email + "email verified" flag | To securely link your Google identity to your account, if you sign in with Google | Performance of a contract — Art. 6(1)(b) |
| Last-login timestamp and account status | Account and session lifecycle | Legitimate interests (account security and integrity) — Art. 6(1)(f) |
| Magic-link token record (your email + a one-way hash of a single-use token, expiry, used-at) | To run passwordless login securely (single-use, expires in 10 minutes) | Performance of a contract — Art. 6(1)(b) |
| Server session record in our server-side session store (a random session ID mapped to your user ID, 7-day lifetime) and a short-lived OAuth state record during Google sign-in | To keep you logged in / protect the sign-in flow against CSRF | Performance of a contract — Art. 6(1)(b); security — Art. 6(1)(f) |
3.2 Order, certificate & delivery data
| Data | Why we process it | Lawful basis |
|---|---|---|
| Recipient name (printed on the certificate) | To create your certificate; printed on the certificate PDF but not shown on the public verification page (see §4) | Performance of a contract — Art. 6(1)(b) |
| Certificate title, type, tier, design, language, and a public verification ID (a randomly generated verification code — not derived from your personal data) | To generate, render, and verify the certificate | Performance of a contract — Art. 6(1)(b) |
| Buyer email address | Order ownership, receipts, and delivery of the certificate and order emails. For digital orders you enter this in our order form; for physical orders the email field is hidden in our form and your email is instead collected by Stripe Checkout during payment and passed back to us. | Performance of a contract — Art. 6(1)(b) |
| Optional scheduled delivery date/time | To send the certificate when you asked | Performance of a contract — Art. 6(1)(b) |
| Shipping details (physical orders only): recipient name, street address, apartment/line 2, city, postal code, country, shipping method; plus tracking number and status | To print, frame, and ship a physical certificate and let you track it | Performance of a contract — Art. 6(1)(b) |
| The generated certificate PDF (which embeds the recipient name, title, and a QR code) | The actual thing you bought — stored, emailed to you, and (optionally) hashed for on-chain anchoring | Performance of a contract — Art. 6(1)(b) |
| Payment metadata: Stripe checkout session reference, amount, currency, status, payment rail | To record and reconcile your payment and issue an invoice. We do not store card or PAN data — Stripe does. | Performance of a contract — Art. 6(1)(b); and legal obligation for invoice/tax records — Art. 6(1)(c) |
Entering someone else's name. If you buy a certificate for a friend and type their name as the recipient, you're providing us with another person's personal data and asking us to process it (it is printed on the certificate, though it is not published on the public verification page). Please only do this if you're allowed to.
3.3 Browser & technical data
| Data | Why we process it | Lawful basis |
|---|---|---|
| Cloudflare Turnstile captcha token + your IP address (sent to Cloudflare at the moment you request a magic link; not stored in our database) | To tell humans from bots and rate-limit abuse on the login endpoint | Legitimate interests (security, anti-abuse) — Art. 6(1)(f) |
| IP address used transiently as a rate-limit key and potentially visible in HTTP traces/logs | Security and abuse prevention; service reliability | Legitimate interests — Art. 6(1)(f) |
| Your browser's locale region and timezone (read client-side) | To prefill the shipping country and show your local time next to scheduled delivery — this stays in your browser; we don't store it | Legitimate interests (convenience) — Art. 6(1)(f) |
| Withdrawal-waiver consent (given at the payment button, confirmed with your order by email) | To make sure you actively confirm immediate delivery before checkout can continue | Legal obligation / contract — Art. 6(1)(b)–(c) |
| Telemetry: performance metrics, JavaScript errors, console logs, page views, a session identifier, and distributed traces; the telemetry receiver also sees your IP and user-agent | To monitor performance, catch errors, and keep the site working (see §8) | Legitimate interests — Art. 6(1)(f) |
user_id attached to server logs/traces | To correlate logs for debugging and security | Legitimate interests — Art. 6(1)(f) |
3.4 On-chain anchor record (off-chain copy)
If you choose the on-chain tier, we keep an off-chain record of the anchor (the certificate's public ID, chain name, contract address, content hash, transaction hash, status, and anchored-at time) so the verification page can show the proof. Lawful basis: performance of a contract — Art. 6(1)(b). What actually goes on-chain is covered in §7.
3.5 Our legitimate interests, named
Where we rely on legitimate interests (Art. 6(1)(f)), those interests are: preventing fraud and bot abuse, keeping the service secure and available, debugging and improving performance, and maintaining basic records. We've balanced these against your rights; you can object at any time (see §10).
3.6 Is providing data mandatory?
Some data is genuinely required to deliver what you bought — e.g. we can't make a certificate without a recipient name, can't email it without an email address, and can't ship a physical certificate without an address. If you don't provide it, we can't complete that order. Account creation requires an email. Everything else is optional.
3.7 Automated decision-making
We do not make decisions that produce legal or similarly significant effects about you using solely automated processing (no automated profiling, credit scoring, or the like) within the meaning of Article 22 GDPR. Turnstile performs automated bot-detection on the login request, but it does not make significant decisions about you as an individual.
4. The public verification page
Every certificate has a public verification page at officiallyuseless.com/verify/<id> that anyone can open without logging in. By design, that page publicly displays:
- the certificate title and subtitle,
- the tier, the issue date, and the certificate ID,
- and, if you anchored it, the blockchain transaction hash and content hash with a link to a block explorer.
The recipient name is not shown on the verification page. We also generate a social share image (Open Graph image), and it shows only our branding and the certificate title — not the recipient name.
In plain terms: the recipient name is not made public — it appears only on the certificate itself, which we deliver to you. The certificate title is public, so don't put anything in the title you wouldn't want the world to read.
5. Who we share data with (sub-processors & recipients)
We don't sell your data. We do use a small set of trusted providers to run the service. Here's exactly who, for what, and where.
| Provider | What they do for us | What they receive | Where they process | Transfer safeguard | Their privacy info |
|---|---|---|---|---|---|
| Stripe | Card payments via Stripe-hosted Checkout, plus hosted invoices | Buyer email, recipient name, certificate details, and (for physical orders) the full shipping address as checkout metadata. Card data goes straight to Stripe and is never stored by us. | EU — Stripe Payments Europe, Ltd. (Ireland); some payment processing in the USA under Standard Contractual Clauses | EU–US Data Privacy Framework + Standard Contractual Clauses | Privacy · Sub-processors |
| Resend | Transactional email (magic-link login, certificate delivery, order overview) | Recipient/buyer email, recipient name, certificate title + verification link, and the certificate PDF attachment | EU — Ireland (Resend region eu-west-1); Resend, Inc. is US-based | Data Privacy Framework + Standard Contractual Clauses | Privacy · Sub-processors |
| Cloudflare | DNS, CDN, WAF, Turnstile captcha, and R2 object storage for the generated certificate PDFs | All inbound traffic (IP, request metadata); Turnstile receives your IP + token; R2 stores the certificate PDFs (which embed the recipient name) | Global edge network (US company). Our R2 bucket uses region auto — not restricted to an EU jurisdiction; Cloudflare may store and serve the PDFs from multiple regions. | EU–US/UK/Swiss Data Privacy Framework + Standard Contractual Clauses | Privacy · Sub-processors |
| OAuth "Sign in with Google" (optional). Google acts as an independent controller for your Google account. We also fetch a web font from Google when rendering the share image. | The OAuth exchange; we receive your email, basic profile (name, picture), and a stable Google ID | Global (US company) | EU–US Data Privacy Framework + Standard Contractual Clauses | Privacy · OAuth data policy | |
| EU-based hosting provider | Hosting for the API, database, and sessions (our servers and databases) | Hosts essentially all data at rest | EU data centres | EU-based processor (no third-country transfer by default) | Available on request (see §15) |
| Alchemy | Blockchain RPC provider used to broadcast and read the on-chain anchor transaction (optional tier; falls back to a public RPC if not configured) | Only the on-chain transaction (public certificate ID + PDF hash) and our server's request. No buyer name, email, or address. | USA — Alchemy Insights, Inc. (used only if on-chain anchoring is enabled); transfers under Standard Contractual Clauses | Standard Contractual Clauses + UK Addendum | Privacy · Sub-processors |
| BNB Smart Chain (public blockchain) | The public, immutable ledger that stores the optional on-chain anchor | The certificate's public ID + a one-way hash of the PDF + block timestamp + our registrar wallet address. No personal data. See §7. | Public, globally distributed network | Public ledger — no controller/processor contract is possible (see §7) | — |
Telemetry collector (telemetry.snowlint.com) | Error/performance monitoring — a first-party monitoring service on our own EU infrastructure | Performance metrics, JS errors, console logs, page views, a session ID, traces; the receiver sees IP + user-agent | Our own EU infrastructure behind Cloudflare — the collector is ours, not a third-party vendor | First-party EU infrastructure (Cloudflare the only external transit) | See §8 |
6. International data transfers
Our core data lives in the EU. However, some of the providers above are based in or process data in the United States (notably Stripe, Cloudflare, Google, Resend, and Alchemy), and the blockchain is globally distributed.
Where personal data is transferred outside the EEA:
- For US-based providers, transfers are protected by the EU–US Data Privacy Framework (where the provider is certified) and/or the Standard Contractual Clauses adopted by the European Commission, with the UK Addendum where relevant. The specific mechanism for each provider is noted in the table in §5.
- Our telemetry/monitoring is received by our own collector on EU infrastructure, so no third-country transfer occurs beyond Cloudflare transit (see §5 and §8).
- For the public blockchain (optional on-chain anchoring), data we publish is, by nature, replicated across nodes worldwide. We minimise this drastically by publishing no personal data on-chain — only an opaque ID and a one-way hash (see §7).
You can ask us for more detail on, or a copy of, the relevant transfer safeguards using the contact in §13.
7. Blockchain & on-chain anchoring
Some certificate tiers include optional on-chain anchoring on the BNB Smart Chain (mainnet in production; a test network in development), to provide tamper-evidence. This section matters because a public blockchain is permanent and immutable: records on it cannot be edited or deleted by us, by you, or by anyone.
What we write on-chain — and what we deliberately do not. When you anchor a certificate, our system calls a function on a registry smart contract with exactly two pieces of data:
certId— the certificate's public verification ID. This is a randomly generated verification code; it is not derived from your name or email. (It is the same public ID already shown on your verification page.)contentHash— akeccak256cryptographic hash of the certificate PDF. A hash is a one-way fingerprint: it lets anyone holding the PDF prove it hasn't been altered, but the original cannot be reconstructed from it.
The blockchain transaction also inherently makes a few things public: the block timestamp, the transaction hash, and our registrar wallet's sender address (a business wallet, not your data).
We never write your name, email, shipping address, or any other personal data on-chain. The smart contract is built this way on purpose, so that the personal data in our normal database stays erasable.
A nuance, stated plainly. Because the PDF embeds the recipient name, the on-chain hash is derived from personal data. But the hash is one-way, so it does not reveal the name. The recipient name is not public on the off-chain verification page — only the certificate metadata (title, tier, issue date, and certificate ID) is shown there (see §4); the hash can only confirm a PDF is genuine, not disclose its contents.
The limit on erasure. If you ask us to delete your data (see §10), we can and will delete the off-chain records — your account, order, certificate record, the PDF in storage, and so on. We cannot delete or alter anything already written to the blockchain, because the technology does not permit it. What remains on-chain is only the opaque ID, the hash, the timestamp, and our wallet address — none of which is, on its own, identifying. This reflects guidance from the European Data Protection Board (Guidelines 02/2025 on processing personal data through blockchains), which we follow by keeping personal data off-chain and publishing only a hash and pointer.
8. Cookies, local storage & telemetry
We keep this lean. We do not use advertising or cross-site tracking cookies.
8.1 Strictly necessary cookies
| Cookie | Purpose | Type | Lifetime |
|---|---|---|---|
__Host-ou_session | Keeps you logged in. It's an opaque random ID mapped to your account on our server. Host-only, Secure, HttpOnly, SameSite=Lax. | Strictly necessary | 7 days |
__Host-ou_oauth | Short-lived protection for the "Sign in with Google" flow (anti-CSRF/PKCE state). Cleared after sign-in. | Strictly necessary | 10 minutes |
Cloudflare cookies (e.g. __cf_bm, cf_clearance) and any Turnstile challenge cookie | Set by Cloudflare in front of the site for bot mitigation and security. | Strictly necessary / security | Set by Cloudflare |
Strictly necessary cookies don't require consent; we describe them anyway for transparency.
8.2 Local storage (not cookies)
- Theme preference (light/dark) is stored in your browser's local storage, not a cookie.
- Our telemetry SDK uses a session identifier stored in your browser to group a single visit's events.
8.3 Telemetry / monitoring
We run a first-party monitoring service in the browser, sending data to our own collector at telemetry.snowlint.com on our own EU infrastructure, not a third-party vendor, so this is first-party monitoring rather than third-party data sharing. It automatically collects performance metrics (Web Vitals), JavaScript errors and exceptions, console logs, page views, a session ID, and distributed traces; the collector also sees your IP address and user-agent. We use this strictly to keep the site fast and working, under our legitimate interest in monitoring and security, and not for advertising or cross-site tracking.
We also export server-side traces to an internal collector when configured; these are server-only, not set in your browser, and off by default unless an OTLP endpoint is set.
9. How long we keep your data (retention)
Our systems do not currently auto-delete most stored data, so we retain it until it is manually removed or you ask us to delete it.
- Account, order, customer, payment, shipment, certificate records, and the certificate PDF: retained for the life of your account, and deleted within 30 days after you close it — except payment/invoice data kept to meet legal accounting obligations, which we retain as required by Latvian accounting and tax law (generally 5 years for source documents; some records up to 10 years).
- Magic-link tokens: single-use and expire after 10 minutes; expired tokens may persist until cleaned up.
- Server sessions: 7 days; the OAuth sign-in state expires after 10 minutes.
- Certificate verification pages and PDFs: retained so verification continues to work, unless you request deletion.
- On-chain anchor data: permanent and immutable — cannot be deleted (see §7).
- Telemetry/logs: retained for a short period (typically 30–90 days).
When you ask us to delete your data, we delete the off-chain records as described in §10; on-chain records cannot be removed.
10. Your rights
If you're in the EU/EEA (and in many other places), you have the right to:
- Access the personal data we hold about you;
- Rectify inaccurate or incomplete data;
- Erase your data ("right to be forgotten") — subject to the on-chain limitation in §7 and any data we must keep for legal reasons;
- Restrict or object to processing based on legitimate interests;
- Data portability — receive your data in a portable format;
- Withdraw consent at any time, where we rely on consent (this won't affect processing done before withdrawal), as easily as you gave it.
How to exercise them: email support@officiallyuseless.com. We'll respond within the time limits required by law (generally within one month). We may need to verify your identity first.
Complaints: if you think we've mishandled your data, we'd appreciate the chance to fix it first — but you have the right to lodge a complaint with a supervisory authority. You can complain to the authority in your country of residence or work, or to our lead authority: Datu valsts inspekcija (Data State Inspectorate of Latvia) — https://www.dvi.gov.lv. EU/EEA residents can find their national authority via the European Data Protection Board's member list.
11. Where data comes from (when it isn't you)
Most data comes directly from you. Two exceptions:
- Recipient details: if someone buys a certificate for you, your name (and any shipping details) were provided by the buyer.
- Google sign-in: if you sign in with Google, we receive your email and basic profile (name, picture, a stable ID) from Google.
We do not scrape personal data from the blockchain or anywhere else.
12. Security
We use industry-standard technical and organisational measures — including encryption in transit, secure passwordless authentication, and access controls — to protect your data. No system is perfectly secure, but we work hard to protect your data.
13. Children
Officially Useless is meant for adults buying joke gifts and is not directed at children. We don't knowingly collect personal data from children under the applicable age of digital consent (13, the age set by Latvia under GDPR Article 8). If you believe a child has provided us data, contact us and we'll delete it.
14. Changes to this policy
We may update this policy as the product or the law evolves. When we make material changes, we'll update the "last updated" date at the top and, where appropriate, notify you. The current version always lives at officiallyuseless.com/privacy.
15. Contact
Questions, requests, or concerns about your data:
Email: support@officiallyuseless.com Controller: Arturs Vanags, Rīga, Latvia (full registered address available on request via support@officiallyuseless.com) Governing law / jurisdiction for this policy: the laws of Latvia, and the courts of Latvia have exclusive jurisdiction