Privacy Policy

Effective date: 2026-07-31 · Last updated: 2026-07-31 · Version 1.0

The short version

BrickDocket is split in two. On my servers: the files you upload, the snapshot behind any client link you publish, and — only if you switch it on — your away-timer schedule. You can download a copy of all of it and you can have all of it deleted, at any time, free. In your own browser: your commission records — your clients, projects, tasks, prices, notes. Those are not on a server, so I cannot see them, search them, back them up, or recover them for you. Export them regularly; that file is your safety net, and the app has a button for it.

Four things you create leave your device: the identity your sign-in provider hands over, files you upload, the snapshot behind a client link you publish, and the away-timer schedule if you switch that on. Six more are ordinary web plumbing: notifications you set up, an exchange-rate lookup when a crypto amount is on screen, web fonts and one script, your Discord avatar, images you attached by URL, and the connection metadata every website receives. All ten are listed in full below, and nothing else leaves at all.

BrickDocket never handles money and never touches Robux. It processes no payments, holds no funds, and converts nothing.

There is no analytics, no telemetry, no error reporting, no advertising, no tracking pixel and no fingerprinting anywhere in BrickDocket. I do not sell your data, and I never hand it to advertisers, data brokers, analytics companies or AI training sets. The only companies that touch any of it are the ones running the parts you switched on, and every one of them is named in "Who receives data". BrickDocket is free and there is nothing to monetise.

That is the whole shape of it. The rest of this page is the detail, because the details are where privacy policies usually go wrong.

Who I am

BrickDocket is built and run by one person: Otron_TV. There is no company behind it, no team, no legal department and no support desk. When this policy says "I", it means that one person. When it says "creator", it means you — the person using BrickDocket to run commissions.

Contact: otrontv@gmail.com

I have not appointed a Data Protection Officer and I am not required to. That is for public authorities, for organisations that monitor people at scale, and for ones handling sensitive data at scale. None of that is me. Write to the address above.

A representative in the EEA or the UK. BrickDocket is offered to people living in the EEA and the UK, so Article 3(2) of the GDPR can reach me even though I am not established there — and with it Article 27's requirement to appoint a representative. I have not appointed one, and I would rather say so plainly than claim an exemption I am not confident of: the Article 27(2) derogation is written for occasional, low-risk processing, and although BrickDocket collects very little, profiles nobody and holds almost nothing on a server, it runs continuously. If a supervisory authority tells me a representative is required, I will appoint one and name them here within 30 days. In the meantime every request, complaint and regulatory contact reaches me directly at otrontv@gmail.com, and I answer it myself, within the time limits set out below.

BrickDocket is an independent tool. It is not affiliated with, endorsed by, or sponsored by Roblox Corporation, Google, Discord, or anyone else named on this page.

What this policy covers

• The website at brickdocket.com — the homepage, the sign-in page, the app, and client pages.
• The sign-in routes at brickdocket.com/auth/\* and the client-link route at brickdocket.com/p/<token>, which run on Cloudflare Pages.
• The storage service at brickdocket-storage.otrontv.workers.dev, which is a different origin and holds uploaded files, client-link data and away-timer schedules.

It does not cover Roblox, Google, Discord, Cloudflare, Supabase, Coinbase, jsDelivr or ntfy themselves. Those are their own services with their own policies.

This policy sits alongside the Terms of Service. The Terms describe what you may and may not do with BrickDocket; this policy describes what happens to information. Where the two overlap — what you may record about a client, what a client link is — they say the same thing, and if they ever appear not to, this policy governs anything about personal data.

You can reach this policy from everywhere on brickdocket.com: the homepage footer, the note beside the provider buttons on the sign-in page, the app's settings screen, and the footer of every client page. Each section below has its own web address — the heading links are stable — so you can send someone straight to the part you mean rather than to the top of the page.

Where your information actually lives

BrickDocket is split in two, and almost every question on this page comes down to which half a thing is in. So here is the split, before anything else.

On my servers

These are held on Cloudflare infrastructure — R2 object storage and Workers — filed under your account id, and they stay there until you remove them or ask me to:

• Files you upload, and their metadata — file name, type, size, which commission, when
• The snapshot behind every client link you publish — the redacted copy of a commission that makes the link work on your client's device
• The grant for each link, and the queue of anything your client sends back
• Your away-timer schedule, only if you switch away-delivery on — and this one holds your Discord webhook URL and your ntfy token
• A small index of your published link hashes, and short-lived pending-upload records

Each is described in full under "What leaves your device", including exactly what a snapshot contains. Two things are true of all of them: you can get a copy of every one, and you can have every one deleted. How, and what deletion does and does not reach, is set out under "How long things are kept" and "Your rights".

In your browser

Your commission records themselves are not in that list, and this is the fact that shapes everything else.

Every client, commission, task, price and note you create is saved in your web browser's local storage, on the device and browser profile you are using. One JSON record under the key brickdocket:v1. There is no account database holding your work, no nightly backup, and no support tool that can look it up.

That record contains: your clients (name, emoji, contact string, private note), commission requests, commissions (title, type, currency, status, deadline, brief), tasks and add-ons with their prices, notes and paid flags, milestones, revisions, approvals, updates, external links, private internal notes, file metadata, reference image URLs, your studio branding, your payment destinations, notification preferences, your activity log, your inbox, and your timers.

The things listed under "What leaves your device" are the exceptions, and you switch most of them on yourself.

What this means, plainly

Your records do not follow you. Sign in on a different browser, a different computer or a phone, and BrickDocket will look empty — no clients, no commissions, no tasks. Same account, different device. That is not a bug, and the export file described below is how you move them.

Three things do outlive your browser, because they have to keep working when you are not there: uploaded file bytes, published client links, and away-timer schedules. Those sit on my servers under your account, which is why a client link you sent still opens from a device where your own workspace looks empty, and why clearing your browser does not clear them. Removing them is a separate step, set out under "How long things are kept".

These things destroy your records:

• Clearing browsing data, site data or cookies
• A browser setting that clears data on exit
• Private / Incognito windows — data is discarded when the window closes
• Uninstalling, resetting or reinstalling the browser
• Deleting or switching the browser profile
• A device wipe, reset or reimage
• Browser storage eviction when the disk is low
• Safari and some other browsers evicting script-written storage after a period of not visiting the site

If your browser data is cleared, your records are gone permanently. I cannot recover them. There is no server copy and no backup on my side to restore from. Emailing me cannot bring them back. I am using "cannot", not "may not be able to", because that is the accurate word.

There is a way to protect yourself, and you should use it. BrickDocket has an export button that works in every browser and writes your whole workspace to a JSON file. It also has an automatic backup that rewrites one file on your own disk on a schedule. Automatic backup needs the File System Access API, which today means Chrome and Edge only — Firefox and Safari cannot do it, and on those browsers Export is the whole of your safety net. Even where it works, automatic backup only runs while a BrickDocket tab is open, and after a browser restart it waits for you to re-allow access to the file before it can write again. Check Settings occasionally to confirm it actually ran. Export regularly regardless, and keep the file somewhere other than the same browser — a cloud drive, an external disk, emailed to yourself. Restoring is done by importing that file. The backup file is never uploaded anywhere; it contains one account's records only, and the sign-in session is stripped out of it.

Removing your data, on both sides. You are not stuck with any of it. In the app you can delete individual items, delete a file, delete a commission and every file under it, revoke a client link — which deletes its grant, its snapshot and its queued messages together — switch away-delivery off, which deletes the uploaded schedule including your webhook URL and ntfy token, and use "clear this workspace from this browser" to wipe the local side and sign out. There is no single button that purges everything at once, so if you want the server side gone in one go, email otrontv@gmail.com from the address on your account and I will remove it by hand: files, snapshots, grants, action queues, your link index, and any timer schedule. The order matters — revoke your client links before you clear your workspace, because clearing it erases the link tokens and the app can no longer revoke what it can no longer name. "How long things are kept" sets out exactly what each of these reaches and the five places where deletion falls short.

Shared computers. Anyone who can use this browser profile can read your BrickDocket records. They are not encrypted at rest by BrickDocket, and other software running under the same user account on that device can read them. Do not use BrickDocket on a shared or public computer unless you clear the data afterwards.

I cannot see any of it. Not the client names, not the prices, not the notes. Not on request, not with a warrant, not by accident. For the records that stay in your browser I carry out no processing operation at all: no copy reaches me, I cannot read, search, back up, produce or erase them, and no server of mine ever sees them. On the ordinary reading of the GDPR that leaves me neither controller nor processor of those records. I state that as my considered position rather than as a settled conclusion — and if a supervisory authority ever took a different view, the practical facts would not change: I still could not reach the data, and I would tell you so.

Signing in

Sign-in is the only thing BrickDocket requires. BrickDocket offers no email-and-password sign-in — the sign-in page has only the provider buttons, and no password is ever collected, stored or transmitted by anything you can reach in the app.

Three providers are described below: Google, Discord and Roblox. The sign-in page itself is the authoritative list of which are switched on right now, and that set can change. A provider described here but not offered on that page collects nothing from you, because the exchange never runs.

The sign-in exchange happens server-side on brickdocket.com, in a Cloudflare Pages Function, using PKCE and a CSRF state check. The provider's client secret never reaches a browser. That also means the consent screen you see says brickdocket.com rather than some backend hostname.

Sign in with Google

Scope requested: openid email profile. Google returns: sub (your Google account id), email, email_verified, name, and picture (an avatar URL). No refresh token is requested (access_type=online), and prompt=select_account is set.

What is never asked for. Gmail, Google Drive, Google Calendar, Google Contacts, Google Photos, or any other Google API. The openid email profile scopes cannot reach any of them. If a future feature ever needed one, you would see a new consent screen before it happened.

Limited Use. BrickDocket's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Revoking access. Remove BrickDocket at myaccount.google.com/permissions whenever you like. That stops any future sign-in and any further contact with Google. It does not close a session already open on a device, and it does not erase what is in your browser — sign out there, or use the deletion steps below.

Sign in with Discord

Scope requested: identify email. Discord returns: id, email, verified, global_name or username, and an avatar hash, which BrickDocket turns into a cdn.discordapp.com URL. Because your avatar is stored as that URL, your browser fetches it from Discord's CDN when it paints your name and picture.

What is never asked for. BrickDocket does not join, read or scan your servers, channels, messages or friends. The identify email scopes cannot see any of that, and BrickDocket never sends you a direct message. The only Discord messages it ever posts are the reminders you set up yourself, to a webhook URL you created and pasted into Settings, containing the text you wrote. Delete the webhook in Settings and they stop.

Revoking access. Remove BrickDocket under Authorised Apps in your Discord user settings. Same effect as above: no future sign-in, and nothing removed from your browser.

Sign in with Roblox

The scopes requested are Read User ID (openid) and Read User Profile (profile), and nothing else. Roblox's /v1/userinfo returns exactly these fields for that pair:

| Field | What it is | |---|---| | sub | Your Roblox user ID | | preferred_username | Your Roblox username | | name and nickname | Your Roblox display name | | created_at | When your Roblox account was created (a Unix timestamp) | | profile | Your Roblox profile URL | | picture | Your avatar headshot image URL — may be empty |

BrickDocket keeps three of those and discards the rest. It keeps your Roblox user ID, your username (falling back to your display name if the username is missing), and your avatar image URL. The account creation date and the profile URL arrive in the response and are thrown away — nothing stores them.

Roblox does not give BrickDocket your email address, your age, your friends, your groups, your inventory, your Robux balance, or anything about your experiences. There is no scope requested that could return any of it. BrickDocket will not post anything to Roblox, not join or manage groups, not touch trades or friends, and not act on your Roblox account in any way.

How the tokens are handled. The authorization code is exchanged for an access token server-side, inside a Cloudflare Pages Function, using PKCE. No refresh token is requested. The access token is used once, within that same request, to read the profile fields above. It is held in memory for the life of that request and is never written to disk, never stored in any database, never placed in a cookie, never sent to your browser, and never disclosed to anyone. Nothing about it survives the response.

Revoking access. You can withdraw BrickDocket's access at any time from the authorised-applications page of your Roblox account. That ends the connection immediately. It does not delete the commission records in your browser — those are yours, and you delete them with the in-app control described below.

Use limits. Roblox data is used for one purpose: identifying your BrickDocket workspace and showing your own name and avatar back to you. It is never sold, never shared, never used for advertising, never used to train any model, and never combined with data obtained from anywhere off Roblox. Nobody is tracked across experiences. You are identified only by your Roblox user ID. If BrickDocket's access to Roblox's APIs ever ends, for any reason, I will delete the data obtained through them. BrickDocket complies with the Roblox Terms of Use and Community Standards.

What is done with it

Your account id becomes provider_providerUserId (for example roblox_1234567). That string is what names your folder in file storage.

The identity is minted into a first-party signed session token and then written into your browser's own record: external id, handle, email (where the provider gave one), provider name, display name, avatar URL, and the date the account record was created. There is no BrickDocket account database, so nothing about your account is written to one. The one exception is the fallback sign-in path described further down: if first-party sign-in were ever unconfigured, Supabase's own auth store would hold your provider id, email and provider metadata. The session token is checked by the storage service to prove a request is yours; it is not stored there either.

Your account is keyed on the provider's user ID (sub), never on your username or display name, because those can change. It is also the only identifier used — there is no fingerprinting and no cross-service tracking.

If you sign in with a second provider using the same email address, BrickDocket will attach it to your existing local workspace only if that provider marked the email verified. An exact user-id match is trusted unconditionally; an unverified email match is not.

What leaves your device — the complete list

Only these ten things. If it is not on this list, it stays in your browser.

1. Your sign-in identity

Covered above. Exchanged server-side on brickdocket.com, held in your browser afterwards.

2. Files you upload

Uploaded file bytes go to a Cloudflare R2 bucket at the key users/<your user id>/files/<file id>, written only through the storage service, which derives that path from the verified user id and never from anything the page claims. Alongside the bytes sits: your user id, the commission id, the original file name, the MIME type and the upload time.

Limits: 100 MB per file; per commission, 100 MB of storage across at most 40 files; per account, 2 GB and 500 objects. The per-file and per-commission figures are both 100 MB, so one maximum-size upload fills a commission on its own. Executable files are refused.

Images are watermarked, downscaled and re-encoded in your browser, on a canvas. When that succeeds, only the marked copy is uploaded, the original never leaves your device — and the original is not kept. By default the longest edge is capped at 1,600 pixels and the file is re-saved as WebP at reduced quality, so keep your own copy of every source file. When marking fails, the original is stored untouched. Only ordinary raster images are marked: JPEG, PNG, WebP, AVIF and BMP. GIF, APNG and SVG are refused on purpose, and anything that is not an image is stored exactly as you uploaded it.

Files you tick as final delivery at upload time are not watermarked under the default setting. That is a setting, not a guarantee: the watermark options include "Every image, finals included", and if you choose it your finals are marked and downscaled too. Your watermark logo itself is held in your browser as a data URL and never fetched over the network.

There is a second, dormant path: when no cloud storage is configured, the app stores file bytes in your browser's IndexedDB instead. On brickdocket.com cloud storage is configured, so uploads go to R2 and the local path is not used.

3. The snapshot behind a client link

A commission lives in your browser, so a client opening a link on their own device would otherwise see nothing. When you publish a client link, BrickDocket builds a redacted copy and stores it at _shares/<SHA-256 of the link token>.snap.json. It is stored under the hash of the token, never the token itself, so listing the bucket reveals no working links. Cap: 512 KB.

What the snapshot contains — read this properly, because it is more than the phrase "a snapshot of the commission" suggests:

• Your studio name, wordmark, tagline, welcome text, mark, accent colour and theme
• Your payment destinations — PayPal, Stripe or Ko-fi URLs, Cash App handles, and crypto wallet addresses with their networks — plus any note you attached to them
• Your link-preview thumbnail URL, your display currency and your Robux-to-USD rate
• That one client's id, name and emoji
• Per commission: title, type, currency, status, deadline, created date, released flag, the revision allowance and how much of it is used, visible sections and their text, the brief, tasks and add-ons (title, price, done, paid, and the note you attached to the line), milestones, every file row — name, kind, size, version, MIME type, id, shared and gated flags — reference image URLs, external links, updates, approvals and revisions
• The link token and the view count

A link's scope decides how many commissions that covers. A commission-scope link publishes one. A client-scope link publishes every non-archived commission you have for that client, so check the scope before you send it.

A file you are still holding back still appears in the snapshot by name, size and version, marked as held — only its address is withheld, and a final-delivery file attached by URL has that URL blanked until you release it.

What is deliberately excluded and never uploaded: your private commission notes, the client's contact string, the client's private note, the passcode hash (it goes to the storage service, never to the client), your integrations block (Discord webhook, ntfy topic and token), every other client's work, and every other link.

Alongside the snapshot sit two more objects: a grant (_shares/<hash>.json) naming your user id, the commission, exactly which file ids that link may read, the label, the expiry, the revoked flag and the passcode record; and, when the client uses the page, an action queue (_shares/<hash>.actions.json).

There is also a small per-account index of published link-token hashes at _shareindex/<your user id>.json, used only to cap one account at 500 live links, and short-lived pending-upload records at _pending/<your user id>/<file id>.json so a file's size can be checked against your quota before any bytes are accepted.

4. The away-timer schedule — the only feature that uploads secrets

Off by default. Opt-in.

Timers otherwise stop the moment your last tab closes. When you turn away-delivery on, BrickDocket uploads a schedule to _timers/<your user id>.json containing exactly:

• Your Discord webhook URL and your studio name (used as the bot's username)
• Your ntfy server URL, topic and access token
• For each of up to 120 jobs: the timer id, the instant it should fire, its title, its body, a link back to the timers page in the app, the repeat interval, the expiry, and which of the two channels to use

The body is the note you typed on the timer, plus On "<commission title>" when the timer is attached to a commission — so your timer note and a commission title do leave your device. Prices, client names, file names and your private notes do not.

Your browser still decides everything: when a timer is due, whether its condition still holds, and what it should say. The server holds "at 09:00, send this text to that webhook" and a once-a-minute sweep. It also keeps a send log of up to 60 entries — timer id, title, when it was due, when it was sent, and which channels succeeded — so your browser can fold what fired while you were away into your inbox instead of firing it twice.

Only reminders due within the next 21 days are uploaded at all, so a reminder set further ahead will not fire unless you open BrickDocket again before it comes into range.

Switching away-delivery off deletes the whole schedule, webhook URL and ntfy token included. If that delete fails, the app tells you so. Be aware of what a failed delete means: a schedule stops sending 14 days after its last republish, but it is not erased by that alone. The stored file, with your webhook URL and your ntfy token in it, stays until a delete succeeds. Switch away-delivery off again once you are back online, or email me and I will remove it.

5. Notifications you configured (Discord webhook, ntfy)

Only if you paste a webhook URL or set an ntfy topic and enable them. These are sent from your browser directly to the service you named, or by the storage service instead when away-delivery is on. There is a ceiling of 30 notifications an hour.

A Discord message carries your studio name as the bot username and embed author, an embed colour from your accent, your link-preview thumbnail URL, the client link URL, and for commission events the progress percentage and the outstanding balance — plus the event's title and body. Read that last part properly. The body is built from your own records, so depending on the event it contains the commission title, the task or milestone title, an amount, the amount still outstanding, your client's name, and — for a client message — the text your client typed. An ntfy message carries the same title and body, an ASCII-stripped title header, a "bell" tag, and your bearer token if you set one.

A link can also carry its own ntfy topic and server, set by you from the client page on your own device and stored on that link. Client-facing events are pushed there too, carrying the same title and body and the client link URL. No access token is sent to that topic.

Something you would want to know: both channels set the client link URL — the one containing the live link token — as the embed's link and as ntfy's click target. The token is the credential for that client page. So a notification routes a working client-page link into a Discord channel or a push topic. That is deliberate, because it is what makes the notification useful, but if other people can read that channel or guess that ntfy topic, they can open that client page.

6. Exchange rates

When a crypto amount is on screen, BrickDocket asks api.coinbase.com/v2/exchange-rates?currency=USD. No user data is sent — no identifier, no query parameter, no body, no cookies, and the referrer policy is set to no-referrer so the page URL is not disclosed. What Coinbase unavoidably sees is the IP address and user agent of whichever browser made the request, as with any HTTP request. This call is made from the app and from client pages, so your clients' browsers make it too.

BrickDocket never handles money and never touches Robux. It processes no payments, holds no funds, operates no wallet, custodies nothing, and provides no escrow, exchange, cash-out or trading of any kind. Payment destinations are plain text you type in so a client can see where to pay you directly, and BrickDocket only displays them. The Robux-to-USD figure uses a fixed default of $0.0035 per Robux — the Developer Exchange cash-out rate Roblox published when this was written. It is a constant in the app, not a live lookup, and you can replace it with your own figure in Settings, in which case that is what your client's page shows too. It is a read-only display convenience, not an offer, a quote, or a means of converting anything. BrickDocket has no access to your Robux balance, your transactions, or your Roblox account beyond the two read-only profile scopes named above, and it does not facilitate the sale, purchase or exchange of Robux, Roblox accounts, items or in-experience content.

7. Fonts and one script

Every page loads web fonts from fonts.googleapis.com and fonts.gstatic.com. This includes client pages, so your clients' browsers contact Google too. Google receives their IP address, user agent and the referring origin. The site's referrer policy is strict-origin-when-cross-origin, so only https://brickdocket.com is sent and never the full client-page URL with its token in it.

Three pages also load one script from cdn.jsdelivr.net (the fallback authentication SDK), which receives IP address and user agent: the homepage, the sign-in page and the app. The homepage is on that list, so simply visiting brickdocket.com contacts jsDelivr, whether or not you ever sign in. Client pages deliberately do not load it, so a client's browser never contacts jsDelivr, and neither this page nor the Terms loads it.

8. Your Discord avatar

If you signed in with Discord, your avatar is stored as a cdn.discordapp.com URL, so your browser fetches the image from Discord's CDN every time it paints your name and picture. Discord sees your IP address and user agent, as any host does. Nothing about your commissions is sent.

9. Images you attached by URL

Reference images and your link-preview thumbnail are loaded from wherever you hosted them. If you paste an Imgur or Discord CDN address, your client's browser contacts that host directly and it sees their IP address and user agent. I do not choose those hosts — you do — and I cannot list them here, because the list is whatever you paste. The referrer policy means only https://brickdocket.com is sent, never the client-page URL with its token.

10. Connection metadata

Every request any browser makes to any website discloses the connection itself. For brickdocket.com and for the storage service, Cloudflare — my hosting provider, acting as my processor — receives your IP address, user agent, requested path, timestamp, referrer and TLS metadata, and keeps them in its own edge logs for security, abuse prevention and error diagnosis. I add no logging of my own, I build no profiles from these logs, and I never join them to your account records. Cloudflare retains them under its own schedule; I do not export, aggregate or archive any of it, so no longer-lived copy exists on my side. The same unavoidable metadata reaches Google Fonts, jsDelivr, Coinbase, Discord's CDN and any image host you pasted, for the requests described above — including from your clients' browsers.

That is the complete list

Nothing else is transmitted. Beyond the connection metadata above, your client contact details, your private notes, your inbox, your activity log, your backup file and your watermark logo are uploaded nowhere. Prices are the one item with an exception: the prices on a commission you publish a client link for are inside that link's snapshot, because the client has to see them.

Client links, and what a link exposes

A client link is a capability URL. Anyone who has the link can open the page. It is unlisted, not secret. Forward it, paste it in a Discord channel, or let it end up in a screenshot, and whoever has it can see what you chose to show. Search engines are kept out with a noindex, nofollow header on client, app, sign-in and /p/* pages — that keeps the link out of search results, it does not make it confidential.

A link can carry a passcode. It is stored only as a PBKDF2-SHA256 record — salt, hash, and 120,000 iterations. The plaintext passcode is never stored anywhere, by anyone. A copy of that salt-and-hash record is uploaded with the grant so the storage service can reject a wrong passcode without the client's page ever holding the hash, which means the hash cannot be taken away and attacked offline. Before a correct passcode is entered, the only thing served is your studio name.

What a client can do back: approve, request changes, or send a message — free text up to 2,000 characters. They cannot reach your records directly. What they do is written to a short queue on the storage service (maximum 100 entries per link, oldest dropped), and your app collects it and applies it on your own device. Applying is automatic, not a request you approve one by one: a client approving something marks it approved in your records, and a client requesting changes moves the commission to "revisions", spends one of that commission's revision rounds, and adds their message to its history. Your app re-checks the revision ceiling against your own data, so a client cannot spend more rounds than you allowed. Collecting the queue deletes it from the server. There is no public intake form and no endpoint that accepts an inbound commission request — commission requests are typed in by you.

Link previews. Discord's and Slack's crawlers do not run JavaScript, so a per-link card would have to be in the HTML at request time. The /p/<token> route can do that, but the data source it would need is not published: the button that would have exported all link previews to one file was removed, because that file was keyed by link token and publishing it would have handed away every client page at once. So no per-link title, description or image is uploaded or stored anywhere by BrickDocket today — a shared link unfurls with BrickDocket's generic card. The token in the URL is pattern-validated before it is used, and the route is served noindex.

On the client's own device, BrickDocket writes one thing: their light/dark choice plus a copy of your theme id and accent colour, so the page paints branded before scripts run. It is keyed per link, so one client's preference cannot leak into another client's page on the same device, and the page tells them in plain words that you cannot see it. You cannot.

No analytics, no tracking, no advertising

I checked this myself against every source file in BrickDocket, and the claim holds:

• No Google Analytics, Tag Manager, Mixpanel, Amplitude, Segment, PostHog, Plausible, Fathom, Hotjar, Clarity or Matomo
• No Sentry, Bugsnag, Datadog or any error-reporting service
• No advertising, no retargeting, no beacons, no sendBeacon
• No fingerprinting of any kind — nothing in BrickDocket reads your user agent, language, platform, CPU cores, device memory, plugins, connection, screen dimensions, timezone offset, AudioContext, WebGL, or canvas readback
• I do not sell your personal data, rent it, share it for cross-context behavioural advertising, or use it to train any AI or language model. I have never done any of these things, and I will not.

The only counters that exist are views on a link, a timer's fire count, and the last error text. The fire count and the error text never leave your browser. The view count is the one exception: it is copied into the client-link snapshot described above, so it sits on the storage service and is visible to whoever opens that link. None of these is sent to me as analytics, and none is aggregated across accounts.

Storage on your device

Cookies, localStorage, sessionStorage and IndexedDB are all treated the same way here, because that is how the law treats them. Everything BrickDocket stores on a device is listed below.

| Name | Kind | What it holds | Lifetime | Strictly necessary? | |---|---|---|---|---| | bd_sess | Cookie (HttpOnly, Secure, SameSite=Lax) | Your signed session token: provider user id, provider name, email, verified flag, name, avatar URL, issue and expiry times | 30 days | Yes — it is your login | | bd_flow | Cookie (signed, short-lived) | The CSRF state, the PKCE verifier, which provider you picked, and where to send you afterwards | 15 minutes | Yes — it is what stops sign-in being hijacked | | brickdocket:v1 | localStorage | Your whole workspace, your local account records, and your local session pointer | Until you delete it or clear the browser (local session pointer expires after 30 days) | Yes — it is the app | | brickdocket:theme, brickdocket:mode | localStorage | Theme id and light/dark choice | Until cleared | Yes — read before first paint so the page does not flash | | brickdocket:boardmode | localStorage | Board or list layout | Until cleared | Yes — a setting you chose | | brickdocket:signedin | localStorage | The literal string 1, meaning "someone was signed in on this browser". Never an identity | Until cleared | Yes — the real credential is an HttpOnly cookie a script cannot read, so this stops the nav flashing "Sign in" at someone already signed in | | brickdocket:sharefp | sessionStorage | Fingerprints of what each link last published, so an identical snapshot is not re-uploaded on every render. Contains live link tokens | Until the tab closes | Yes — without it every task tick fired an upload per live link | | brickdocket:crypto-rates:v1 | sessionStorage | Cached exchange rates and when they were read | Until the tab closes | Yes — one market reading instead of fifty requests | | brickdocket-files | IndexedDB | File bytes and metadata — only when cloud storage is not configured. Not used on brickdocket.com | Until deleted | Yes, where used | | brickdocket-backup | IndexedDB | A pointer to the one backup file you chose on your own disk | Until you disconnect it | Yes — you asked for scheduled backups | | brickdocket:portalprefs:<token> | localStorage, on a client's device | That client's light/dark choice and a copy of your theme and accent | Until cleared | Yes — so the page paints correctly | | sb-…-auth-token | localStorage | A fallback authentication session, written by the Supabase SDK, only when first-party sign-in is unconfigured | Managed by that SDK | Yes, where used |

These are the only cookies BrickDocket sets: bd_sess and bd_flow. Both are first-party, both are set by the server, both are unreadable by any script, and no client script anywhere in BrickDocket touches document.cookie. There are no analytics, advertising or tracking cookies. Under ePrivacy and PECR rules everything above is strictly necessary to provide the service you explicitly asked for, which is why there is no consent banner. If that ever stops being true, a banner appears before the thing that needed it does.

The things that are not strictly necessary — the Discord webhook, ntfy push and away-delivery — are features you switch on yourself, and switching them on is the consent.

Google Fonts and the jsDelivr script are not strictly necessary either, and I do not ask for consent before loading them, because they are page assets rather than storage on your device. That means every visit hands Google an IP address, and your clients' visits do too. I rely on legitimate interests for it: rendering the site legibly, and loading a fallback sign-in library so a misconfigured deploy cannot lock everyone out. Nothing but the metadata inherent in fetching a file is sent. Self-hosting the fonts and the script would end it entirely. Until then, you can object at any time, and a browser extension that blocks both will not break BrickDocket's function.

Why I process each thing, and on what basis

One basis per purpose, not a blanket line. Three words do the work in the last column. Contract means I have to do this or BrickDocket cannot give you the thing you asked for. Legitimate interests means I do it to keep the tool running and stop it being abused, and I have kept it to the smallest version of that. Consent means nothing happens until you switch it on, and it stops when you switch it off.

| Purpose | What is processed | Basis | |---|---|---| | Creating your account and signing you in | Provider user id, username/display name, email where given, avatar URL, account creation date | Contract — you cannot use BrickDocket without an account | | Serving the app and keeping you signed in | The two cookies, your local session pointer | Contract | | Storing and serving files you upload | File bytes and their metadata | Contract | | Publishing a client link you asked for | The snapshot, the grant, the passcode record | Contract | | Collecting your client's approvals and messages | The queued action text | Contract | | Keeping the service working and stopping abuse — quota checks, refusing executables, rejecting bad tokens, capping links and actions | User ids, object sizes and counts, request origins | Legitimate interests. The interest is keeping a free tool running and preventing one account from breaking it for everyone. It is minimal, it is not used to profile anyone, and it processes no more than the counters and identifiers required to enforce a limit — so it does not override your interests | | Loading page assets — web fonts, the fallback sign-in library | IP address and user agent, disclosed to Google and to jsDelivr by the act of fetching a file | Legitimate interests — presenting the site and keeping sign-in available. No identifier is attached and no profile is built | | Away-delivery of timers | Your schedule, webhook URL, ntfy server/topic/token | Consent — off by default, on only if you switch it on | | Discord and ntfy notifications | Whatever the message carries, listed above | Consent — only if you configure them | | Showing an indicative USD value beside crypto amounts | An unauthenticated request to Coinbase carrying no user data; Coinbase sees the requesting browser's IP address and user agent, including a client's | Legitimate interests. I cannot honestly call this consent: you never flip a switch for it, and on a client page the client chose nothing — the request fires in their browser because you priced the job in crypto. Amounts still display in their original currency without it | | Answering a valid legal order, and establishing or defending a legal claim | Whatever the order or claim names, drawn from the server-held data listed above | Legal obligation, and legitimate interests in defending a claim. Where I am legally permitted to tell you, I will, and I will tell you what I handed over |

You can withdraw consent for the consent-based features — away-delivery, the Discord webhook and ntfy — at any time by switching them off, and withdrawing does not make anything that already happened unlawful. For the items based on legitimate interests you can object instead, and I will stop unless I can show compelling grounds that override your objection.

Where the data comes from

• From you, when you sign in and when you type.
• From your sign-in provider, for the account fields listed above.
• From your clients, only through the client page's approve / request-changes / message actions.
• From you, about other people. The client names, handles, contact strings and notes in BrickDocket were not given to me by those clients. You typed them. That has consequences, and they are set out below.

Who receives data, and what each one gets

| Recipient | What they get | |---|---| | Cloudflare (Pages, Workers, R2, KV) — my own infrastructure | Site hosting; the sign-in exchange; uploaded file bytes and their metadata; client-link snapshots, grants and action queues; the per-account link index; pending-upload records; and, only when away-delivery is on, your timer schedule with your webhook URL and ntfy token. Cloudflare also sees request IP addresses, user agents, timestamps and paths as any host does | | Google (identity provider) | That you signed in to BrickDocket, plus the OAuth client id, redirect URI, PKCE challenge and state. No BrickDocket data is sent to them | | Discord (identity provider) | The same, for Discord sign-in | | Roblox (identity provider) | That you signed in to BrickDocket, plus the OAuth parameters. No BrickDocket data is sent to Roblox, ever | | Supabase (fallback authentication only) | Nothing in normal operation. First-party sign-in is preferred and selected automatically; Supabase is kept only because a deploy must never be able to lock everyone out while first-party secrets are missing. In that fallback state Supabase would hold your provider id, email and provider metadata in its own auth store, and the SDK would keep a session in your browser. The storage service will also check a bearer token against Supabase, but only if first-party verification did not already succeed. Only a public key exists in browser code | | Discord (webhooks) | Only if you configured one: studio name, accent colour, thumbnail URL, progress percentage, outstanding balance, the client link URL including its token, and the event title and body — which can contain a commission title, a task title, an amount, your client's name and text your client typed | | ntfy (ntfy.sh or a server you name) | Only if you configured it: the same title and body, a tag, your bearer token if you set one, and the client link URL including its token. Also the per-link client topic, if you set one on a link | | Coinbase | An unauthenticated request with no user data. Coinbase sees the IP address and user agent of whoever's browser made it, including your clients' | | Google Fonts | IP address, user agent and the referring origin, from every visitor including your clients | | jsDelivr | IP address and user agent, from the homepage, the sign-in page and the app — not from client pages, and not from this page or the Terms | | Discord's CDN | IP address and user agent, when your browser paints your Discord avatar | | Any image host you pasted a URL for | IP address and user agent of whoever's browser loads the image, including your clients' |

Nobody else. No data broker, no advertiser, no analytics vendor, no AI training set.

I would disclose data if a valid legal order required it — but for records held in your browser there is nothing to disclose, because I do not have them.

International transfers

These providers run servers all over the world, so your data is processed outside the country you live in. The safeguard relied on is each provider's own data processing terms, which incorporate the EU Standard Contractual Clauses and, where relevant, the UK International Data Transfer Addendum. Each provider publishes its data processing agreement on its website; if you want the specific references, email me and I will send them.

How long things are kept

Deleted automatically:

• Client-link grants always expire. The storage service forces a ceiling of 30 days from the moment it is written, and it fails closed if the expiry is missing or zero. An abandoned link dies on its own. A link you are actively using keeps refreshing its own window, because the app republishes as you work.
• A client's action queue is destroyed on read. When you collect it, the object is deleted.
• Pending-upload records are deleted the moment the bytes land, and are treated as expired after 10 minutes.
• Away-timer schedules stop sending 14 days after their last republish, and conditional reminders expire 3 days after they were due, because nothing on the server can re-check whether a balance is still unpaid. The send log keeps 60 entries, the schedule 120 jobs, and 6 sends go out per sweep — the sweep being the once-a-minute check that looks for timers that are due.

Deleted by you, in the app:

• Revoking a client link deletes all three objects together — grant, snapshot and action queue. Leaving the snapshot behind would let a revoked link keep showing prices, progress and updates the client is no longer entitled to.
• Switching away-delivery off deletes the whole schedule, including the uploaded webhook URL and ntfy token.
• Deleting a file deletes the object. Deleting a commission deletes every file under it.
• "Clear this workspace from this browser" removes the account record and its entire workspace from local storage and signs you out. It is a local action only — see below.
• Clearing browser data destroys everything local — records, any locally held file bytes, and the backup file pointer. Which is exactly why the on-disk backup exists.

What deletion does not reach. These are limitations, stated rather than glossed over:

1. Deleting a commission, deleting a client, or clearing the workspace from this browser does not withdraw the published grant and snapshot. The link rows are removed locally, and because the link token is erased at the same moment, the app can no longer revoke them either. Those links keep serving the client page — prices, updates, your payment destinations — until the 30-day grant ceiling runs out. Revoke every client link first, then delete. If a link needs to be gone sooner than that, email me and I will remove it by hand.
2. Clearing your workspace does not touch my servers at all. There is no one-button account purge: uploaded files, published links and snapshots, the link index, and any away-timer schedule with its credentials all have to be withdrawn separately, in the app, before you clear the workspace. If you have already cleared it, email me from the address on the account and I will remove what is left.
3. A grant that merely expires, rather than being revoked, is not erased. The snapshot stops being served — the endpoint returns "not found" — but neither object is removed from storage by expiry alone. Only revoking, or republishing over it, rewrites it. This is a defect, not a design choice, and the fix is a storage lifecycle rule that erases every _shares/ object shortly after its 30-day life; this paragraph goes when that ships. Until then, revoke a link you want gone now rather than letting it expire.
4. An away-timer schedule whose delete failed persists too. It goes quiet after 14 days, but the file, with your webhook URL and ntfy token in it, is not erased by that. Switch away-delivery off again, or email me.
5. A link created under a pre-cutover account id cannot be revoked or republished at all. The app tells you this plainly when it happens, and such a link stops working on its own within 30 days.
6. Uploaded file bytes have no expiry. They persist until you delete the file, delete the commission, or ask me to remove the account's storage. The per-account link index persists too. Your local records persist until you clear the browser or delete the workspace; the local session pointer and the bd_sess cookie both last 30 days.

One exception to immediate deletion. If I receive a valid legal order, or credible notice of a claim, naming specific server-held data, I will preserve exactly that data for as long as I am required to and no longer, and I will tell you unless the order forbids it. Nothing else is ever withheld from deletion. This can never reach the records in your browser, because I do not have them.

Bounded in place: your workspace self-prunes on every write — 300 activity entries, 150 inbox entries, 200 retained archived commissions, 20 fire-log entries per timer, 200 away-timer "seen" keys, and the notification send log keeps only the last hour. Local storage is capped at about 4.6 MB, with 5 accounts per device, 20 active commissions and 150 clients.

Information about your clients

This is the section most tools of this shape leave out. It matters, because the people in your client list never agreed to anything.

You are responsible for your clients' data. When you type a client's name, handle, contact string and project details into BrickDocket, you decide why and how that information is collected and used. In data protection terms, you are the controller. I am at most a processor, and only for the parts that actually touch my servers.

For records that never leave your browser, I am neither. I cannot read them, search them, back them up, produce them in response to a request, or delete them. Where someone asks me about data I cannot identify or reach, GDPR Article 11 applies: I cannot fulfil an access, correction or deletion request I have no way to locate. I will say so and point the person to you.

**There are three flows where I am a processor and you are the controller:** files you upload, the snapshot behind a client link you publish, and away-timer payloads. Those are the parts I hold.

What you are responsible for

The "personal or household activity" exemption does not cover you. It applies only to activity with no professional or commercial purpose. The moment you take a paid commission and record a client, you are acting professionally.

Your client did not give their data to me or to my software — they gave it to you. That makes GDPR Article 14 your obligation. Where personal data was not obtained from the person themselves, the controller has to tell them: who you are, why you hold it, what categories you hold, where it came from, who receives it, how long you keep it, and what rights they have. The deadline is a reasonable period and at the latest one month — or at your first communication with them, if that comes sooner. In practice, for a commission, your first message to the client is that moment. One sentence does it: "I track this project in a tool called BrickDocket. I record your name, your handle and the project details. Ask me any time and I'll change or delete it." The "disproportionate effort" escape does not apply here; it is aimed at archives and research, not at a handful of named people you are already talking to.

Record only what you need. A handle and a project note is usually enough. Never record a client's health information, religion, sexual orientation, biometrics, political views, government ID number, home address, school, photograph, phone number, or payment card details. BrickDocket's Terms of Service prohibit all of it.

Your clients may be children. Roblox commissioning is full of minors. The same duties apply, and the right response is to record less, not more.

Delete client records when the project is done and there is no reason to keep them.

Answer your clients' requests yourself. Access, correction, deletion — you hold the data, so you handle it. I cannot do it for you and I will tell them so.

Never post a client link publicly. It is a capability URL. Anyone who has it can open it.

Keep your own backup. You cannot meet a client's access or correction request out of records you have lost.

What I commit to

I process client data only to run the features you switched on, never for my own purposes. I do not sell it, share it, mine it, or feed it to any model. My sub-processors are Cloudflare (hosting, Workers and R2 storage), Supabase (the fallback sign-in path only), ntfy.sh (only if you turn on push and use the default server) and Discord (only if you set up a webhook). I will name any new or replacement sub-processor here — in advance where that is practical, and otherwise as soon as I reasonably can, without committing to a fixed notice period, because a provider can change or withdraw its service on its own timetable. People handling data on my behalf — which today is nobody but me — are bound to confidentiality. I take the security measures described below. I will help you if a client asks you something and you need the server-held part, and I will help you if there is a breach. I delete server-held data when you delete it or ask me to close your account, and I will not keep a copy. If an instruction of yours looked unlawful, I would tell you rather than follow it.

The full processor terms — subject matter, duration, sub-processor notice and objection, audit, transfers, return-or-delete at the end — are section 16 of the Terms of Service, and they are binding. They are written out once, there, rather than half in each document.

If you are a client and you found your information in someone's BrickDocket: email otrontv@gmail.com. I will tell you honestly what I can and cannot reach, point you to the creator who holds it, and act on anything server-held that I can identify — an uploaded file or a published snapshot.

Your rights

These are granted to everyone who uses BrickDocket, wherever you live, whether or not the law where you are requires it of me. I am not claiming a compliance badge; I am telling you what you can do.

| Right | How to use it | |---|---| | Access — see what is held | For your records: the in-app export gives you the whole thing as a machine-readable file, instantly, without asking me. For server-held data: email me | | Correction | Edit it in the app. For account fields that came from your provider, change them at the provider and sign in again | | Deletion | Delete items in the app; revoke links; delete files; switch away-delivery off to delete the schedule; use "clear this workspace from this browser" to wipe the local side. Then email me if you want the server side and the account removed entirely | | Portability | The in-app export gives you the whole browser-held workspace as a JSON file you own and can take anywhere, instantly. For the server-held parts — your uploaded files, your published snapshots and grants — email me and I will send you the files themselves plus a JSON copy of the snapshot and grant records for your account, within one month, free | | Restriction of processing | Email me. In practice, switching a feature off restricts it immediately | | Objection, including to anything based on legitimate interests | Email me and say what you object to | | Withdraw consent | Switch the feature off. Past processing stays lawful; nothing further happens | | Not be subject to automated decisions | Nothing to exercise — see below |

The catch: for records in your browser you exercise these rights yourself, inside the app, because I cannot see or reach that data. That is not me dodging the request. It is the same fact that makes the product private in the first place.

How I check a request is really yours. For server-held data I have to be sure before I disclose or delete anything, because acting on an impostor's email would itself be a breach. Write from the email address attached to your sign-in provider, and be signed in to BrickDocket in the same browser when you write, so you can quote back the account id the app shows you. If I still have reasonable doubt I will ask for one further thing only you and I would both know — the label of a client link you published, for instance. I will never ask for identity documents, a photograph, a date of birth, or anything I do not already hold; collecting more data to answer a privacy request would be absurd. If I cannot verify you I will refuse, say why, and tell you how to complain about the refusal.

Authorised agents. You may use an agent. Send me written permission signed by you, and I will confirm with you directly before acting on it.

If I say no. If I refuse a request or grant only part of it, reply with the word APPEAL. I will review it myself and answer with written reasons as promptly as I reasonably can, and if I still say no I will tell you exactly how to take it to your data protection authority or attorney general. I am not setting a fixed appeal deadline here — one person answering these by hand cannot guarantee one — but nothing about an appeal pauses, shortens or waives any statutory deadline that applies to the underlying request.

For server-held data I will respond within one month, extendable by two more for genuinely complex requests, and I will tell you if I need the extension. It is free. I will not treat you worse for asking.

If I delete your data at your request, here is exactly what that reaches: your uploaded files, your client-link grants, snapshots and action queues, your link index, your away-timer schedule and its send log, and your session. It does not reach the records in your browser, because I cannot see them. You delete those yourself with the in-app control, or by clearing site data for brickdocket.com in your browser settings. Saying both halves is what makes the promise real.

Complaints. Tell me first — otrontv@gmail.com — and I will try to fix it. You can also complain to the data protection authority for your country or region regardless. In the EU, the members list is at edpb.europa.eu. In the UK, it is ico.org.uk.

US state privacy rights

Granted voluntarily to everyone. I am not claiming to be a covered "business" — the thresholds are tens of millions in revenue or the data of a hundred thousand people, and an individual running a free tool is nowhere near any of them.

Categories collected: identifiers (provider user id, username, display name, email, avatar URL, IP address); internet or network activity (request logs held by Cloudflare); commercial information, in the sense that your own commission records exist — though almost all of it never leaves your device. Coarse location can be inferred from an IP address by any host; no precise geolocation is collected, and nothing is used for prolonged or active location tracking.

Sensitive personal information: none is collected about anyone by design, with one exception you switch on yourself. If you enable away-delivery, the schedule holds your Discord webhook URL and your ntfy access token — credentials that California law counts as sensitive personal information. They are used for exactly one purpose, sending the reminders you scheduled, and never to infer anything about you, so there is nothing for the right to limit the use of sensitive personal information to restrict. Switching away-delivery off deletes them. Do not enter sensitive personal information about anyone else — see the client-data section above for the list.

Sources: you, your sign-in provider, your clients through the client-page actions.

Purposes: the ones in the table above, and no others.

Disclosed to service providers and contractors: Cloudflare, Supabase (fallback only), and ntfy.sh where you configured it — each processes only on my instructions. Disclosed to third parties: Discord and ntfy where you configured them, and the identity providers, all at your direction.

I do not sell personal information, and I do not share it for cross-context behavioural advertising. I have not done either in the preceding twelve months, or ever. There are no financial incentives and no loyalty programme.

Do Not Track and Global Privacy Control. BrickDocket does not track you across sites or over time, so there is nothing for an opt-out signal to switch off — no sale, no sharing for cross-context behavioural advertising, no advertising of any kind, no cross-site profiling. Sending a Do Not Track header or a Global Privacy Control signal therefore changes nothing about how BrickDocket behaves, because BrickDocket already behaves as though every visitor had sent one. California law asks sites to state how they respond to these signals; that is my answer.

Your rights to know, delete, correct, opt out of sale or sharing (there is nothing to opt out of), limit the use of sensitive information, non-retaliation, appeal a refusal, and rights regarding automated decision-making are all covered by the section above.

Automated decision-making

BrickDocket performs no profiling and no automated decision-making, and nothing it does produces legal or similarly significant effects on anyone. No scoring, no ranking of people, no algorithmic judgements. The only automatic things in it are a once-a-minute timer sweep and quota arithmetic.

Is providing any of this required?

An OAuth identity is required to sign in — there is no email-and-password alternative and no anonymous mode, so without it you cannot use BrickDocket. Everything else is optional. Uploading files is optional. Client links are optional. Notifications and away-delivery are optional and off by default. BrickDocket works as a commission tracker with none of them switched on.

Children

You must be at least 13 to use BrickDocket. If you are under the age of majority where you live, or the law where you live sets a higher age for agreeing to online terms, you may use BrickDocket only with a parent or guardian's permission, and they agree to the terms on your behalf.

BrickDocket is not directed to children under 13 and I do not knowingly collect personal information from anyone under 13. If I learn that an account belongs to someone under 13, I will close it and delete everything held on my servers for it — the account record, uploaded files, published snapshots and grants, and any away-timer schedule with its credentials. A parent or guardian who believes a child under 13 has an account can email otrontv@gmail.com and I will act promptly, and explain what sits only in that child's own browser, which I cannot touch, and how to clear it.

There is no age gate on the site. I am not describing one, because describing a control that does not exist is exactly the kind of inaccuracy this policy is trying to avoid. Roblox's own rule is that you need a 13+ account to authorise an OAuth app.

A wrinkle worth stating: in the EU, where processing rests on consent, the age at which you can consent for yourself is 16 unless your country has lowered it, and some have, as far as 13. That affects BrickDocket's consent-based features — the Discord webhook, ntfy and away-delivery. If you are under the age at which you can consent for yourself in your country, a parent or guardian must approve those features. The core service does not rest on consent, so it is unaffected.

Some places impose extra duties for anyone under 18. Rather than claim compliance with each of them, here is my actual position: no analytics, no advertising, no profiling, nothing sold, and every optional feature off until you turn it on. That is a stronger statement than a list of regime names.

And the point specific to this product: the people you record as clients may themselves be children. Record only what you genuinely need. A handle and a project note is usually enough. Never record a child's real name, home address, school, photograph, phone number, or any government or payment identifier.

Security

What is actually in place:

• HTTPS everywhere.
• The sign-in code exchange happens server-side, so a provider's client secret never reaches a browser.
• PKCE and a signed CSRF state cookie on every sign-in, so an intercepted callback is useless.
• The session is an HttpOnly, Secure, SameSite=Lax cookie. No script can read it, which means a cross-site-scripting bug cannot steal a durable login.
• File paths are derived from the verified user id, never from anything a page claims, so one account cannot address another account's objects.
• A client link grant names exactly which files it may read. A file you have not released is simply absent from the grant, so an old URL stops working the moment the grant is republished.
• Snapshots and grants are stored under the SHA-256 hash of the link token, never the token, so listing the bucket reveals no working links.
• Passcodes are PBKDF2-SHA256 with 120,000 iterations, verified server-side; the client's page never receives the hash, so it cannot be taken away and cracked offline.
• Executables are refused, on both sides.
• The /p/<token> route validates the token format before it is used anywhere.
• Quotas — 100 MB per file, 100 MB and 40 files per commission, 2 GB and 500 objects per account, 500 links per account, 10 live links per client, 100 queued actions per link, 512 KB per snapshot, 120 timer jobs, 30 notifications an hour.
• Private pages carry noindex, nofollow so search engines do not publish them.

The real limits, stated as limits:

• A client link token is the credential. Anyone holding the link can open the page. Notifications route that link into Discord and ntfy on purpose. Treat it accordingly.
• A passcode protects the link, not the URL. Before it is entered, the studio name is still returned.
• Browser storage is not encrypted by BrickDocket. Anyone with access to your browser profile can read your records.
• The away-timer schedule holds your webhook URL and ntfy token in plain form on the server, because they must be usable when your browser is closed. That is the cost of the feature and it is why the feature is off by default.
• Deleting things locally does not always reach the server. The six items under "What deletion does not reach" are security-relevant, not just housekeeping.
• No online service can be guaranteed completely secure. I will not tell you this one is. There is no "military-grade" or "bank-level" anything here — just the list above, which you can check.

If something goes wrong

If there is a breach of personal data, I will notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to anyone. Being one person is not an exemption, and the clock starts when I reasonably become aware, not when I fully understand it.

Where a breach is likely to result in a high risk to you, I will tell you without undue delay. Because there is no account database, I usually hold no email address for you — so notice is given by a banner on brickdocket.com, an in-app notice shown the next time you open the app, and a dated entry in the change log of this policy. Where I do happen to hold a working address for you, for example because you have written to me, I will email you as well. I am not promising email to everyone, because I could not keep that promise.

Where a breach affects data I hold as your processor — your uploaded files, your published snapshots, grants and action queues, your away-timer schedules — I will notify you, the controller, without undue delay after becoming aware of it, with enough detail for you to make your own notifications to your clients and to your regulator, and I will help you make them.

If BrickDocket stops, or changes hands

One person runs this, so it is fair to ask what happens if I stop.

If I shut BrickDocket down, I will post notice in the app, on brickdocket.com, and here, and the export keeps working for as long as the site is up. I aim to give around 30 days, but I am not guaranteeing a notice period — a hosting provider, an identity provider or a legal requirement can end a service faster than one person can manage an orderly wind-down, and I would rather say that than publish a number I might not be able to honour. Your records are in your browser, so the app going away does not delete them — but client links, uploaded files and away-timers will stop working, so keep an exported backup and download your files rather than relying on notice from me. When the shutdown completes I delete all server-held data: files, snapshots, grants, action queues, link indexes, timer schedules and send logs.

If BrickDocket ever changes hands — sold, merged, or transferred to someone else to keep running — I will say so here and in the app before it takes effect, and give you a reasonable period to export your records and revoke your links first. The recipient is bound by this policy until they publish their own. Server-held data is never sold as a standalone asset to anyone, for any purpose; it moves with the service or it is deleted. Server-held data is never sold as a standalone asset to anyone, for any purpose; it moves with the service or it is deleted.

Changes to this policy

The effective date and version number are at the top, and the version published here is always the current one. I do not keep an archive of superseded versions and I am not undertaking to supply one — this is a free tool with one person behind it, and that is housekeeping I would rather spend on the product.

Material changes are announced in the app and on brickdocket.com before they take effect, not after. There is no fixed notice period. Because I keep no mailing list and hold no email address for you on a server, I cannot email you — so if you have not opened BrickDocket since a material change, the notice is shown to you the next time you do, before you carry on. What does not change: alterations are not applied retroactively, and if a change would mean doing something new with information you have already given me, I will ask first rather than assume the new wording covers it. There will be no quiet rewrites.

Contact

otrontv@gmail.com

That is the address for privacy questions, rights requests, complaints, abuse reports, takedown requests, and for a client who has found their information in someone's BrickDocket and wants it dealt with. I aim to reply within a few days and, for a formal rights request, within one month.

If you are not satisfied with my answer, you can raise it with the data protection authority for your country or region.