One-time secret links are the usual fix: encrypt the secret, send a link, and the link dies after the first read. I built B1 Drop to do exactly that. When I started, though, I found that "one-time" is surprisingly easy to get wrong. Two failure modes kept coming up:

1. The server can read the secret. If the key lives next to the ciphertext, "one-time" only describes the UI. The operator, a log pipeline, or a database backup can still read it.
2. Link preview bots burn the link. Paste a link into Slack, iMessage, Teams or WhatsApp and a bot fetches it to build a preview card. If a plain GET consumes the secret, the bot reads it first and your recipient sees "already opened".

There's also a third, quieter problem: two requests racing to read the same secret. Here's how B1 Drop handles all three, with excerpts from the actual code.

Keeping the key off the server

Everything is encrypted in the browser with WebCrypto. For each drop, the client generates 32 random bytes with crypto.getRandomValues, plus a 16-byte salt and a 12-byte IV. Those 32 bytes never become the AES key directly. They go through HKDF-SHA256 with the salt and a fixed context string. If the sender sets a passphrase, PBKDF2-SHA256 with 600,000 iterations stretches it, and the result is concatenated with the random key before HKDF:

async function deriveKey(rawKey: Bytes, salt: Bytes, passphrase?: string): Promise<CryptoKey> {
  let ikm = rawKey;
  if (passphrase) {
    const pk = await subtle.importKey("raw", new TextEncoder().encode(passphrase.normalize("NFC")), "PBKDF2", false, ["deriveBits"]);
    const bits = new Uint8Array(await subtle.deriveBits({ name: "PBKDF2", hash: "SHA-256", salt, iterations: PBKDF2_ITERATIONS }, pk, 256));
    ikm = new Uint8Array(rawKey.length + bits.length);
    ikm.set(rawKey, 0);
    ikm.set(bits, rawKey.length);
  }
  const hk = await subtle.importKey("raw", ikm, "HKDF", false, ["deriveKey"]);
  return subtle.deriveKey({ name: "HKDF", hash: "SHA-256", salt, info: INFO }, hk, { name: "AES-GCM", length: 256 }, false, ["encrypt", "decrypt"]);
}

With this design the passphrase is an extra factor, not a replacement. Without the 32 bytes from the link, the passphrase alone gets you nothing, and there's a unit test for exactly that case.

The data is then encrypted with AES-256-GCM. The envelope starts with a 30-byte header (version, flags, salt, IV), and that header is passed as additional authenticated data. Flip a salt byte or the passphrase flag and decryption fails instead of quietly doing something odd. The tests tamper with both the ciphertext and the header to check this.

The server only ever sees header || ciphertext. The browser then builds the link as ${location.origin}/${j.id}#${key}. The key is base64url-encoded into 43 characters and sits after the #. Browsers don't send the fragment in HTTP requests, so it never shows up in our server's request line or logs. The server only knows the 8-character ID. IDs are drawn from base-62 using rejection sampling (bytes of 248 and above are discarded), so they aren't biased toward some characters.

Two small details on the receiving side. Once the secret is decrypted, the page calls history.replaceState to strip the key out of the address bar and the history entry. Pages and API responses also send Referrer-Policy: no-referrer.

GET never consumes

This was the most important design decision, and it's almost boring: a GET request never changes state. The router makes that explicit:

if (!m[2] && req.method === "GET") return await status(req, env, m[1], now);
if (m[2] && req.method === "POST") return await reveal(req, env, url, m[1], now);
// ...
// Short link page. Serving it never touches the database, so link-preview bots cannot burn a drop.
if (ID_RE.test(p.slice(1))) return asset("/open.html", 200, true, false)!; // never frameable

When a preview bot fetches https://b1.gg/AbCd1234, it gets a static HTML shell. Serving it doesn't run a single database query. The response is marked no-store and noindex, and it can't be framed (frame-ancestors 'none' plus X-Frame-Options: DENY), so another page can't clickjack the reveal button. When a real person opens the page, its script calls GET /api/drops/:id. That endpoint runs a SELECT that only reports whether the drop exists, whether it needs a passphrase, and when it expires. It never reads the ciphertext.

To actually reveal, you press Reveal and delete. That sends a POST to /api/drops/:id/reveal with a custom X-B1-Drop: 1 header, and the server refuses the request without it. Preview bots don't send POSTs with made-up headers. A malicious page can't make your browser do it cross-origin either, because the custom header triggers a CORS preflight that our server never approves. If an Origin header is present and doesn't match, the request is refused too. The test suite checks this directly. It fetches the share page five times with a Slackbot-LinkExpanding user agent and then confirms the drop can still be revealed. Another test confirms that a reveal without the header, or with a foreign Origin, returns 403 and doesn't consume the drop.

Reveal is one atomic read-and-delete

The naive version of "read once" looks like this: SELECT the row, return it, then DELETE it. Between those two statements, a second request can read the same row. Two tabs, a double-click, or a retrying proxy is enough to get two reads of a "one-time" secret.

B1 Drop collapses the read and the delete into a single SQL statement:

const row = await env.DB.prepare("DELETE FROM drops WHERE id = ? RETURNING expires_at, chunks").bind(id).first<{ expires_at: number; chunks: number }>();
if (!row) return null;
const [sel] = await env.DB.batch([
  env.DB.prepare("SELECT data FROM chunks WHERE drop_id = ? ORDER BY n").bind(id),
  env.DB.prepare("DELETE FROM chunks WHERE drop_id = ?").bind(id),
]);
if (row.expires_at <= now) return null;

DELETE ... RETURNING is the gate. Only one request can delete a given row, so only one gets a non-null result. Every other request sees nothing and gets a 404 "gone". Only the winner reads the ciphertext chunks, and it deletes them in the same batch. Files are split into chunks of under 2 MB for storage, and a drop row is only inserted in the same transaction as all of its chunks.

Expiry is checked after the delete. That way, revealing an expired drop also removes it instead of leaving it for the cleanup job.

I didn't want to just trust this, so there's a test that fires 12 concurrent reveals at the same drop:

const res = await Promise.all(Array.from({ length: 12 }, (_, i) => reveal(id, `192.0.2.${i}`)));
const codes = res.map((r) => r.status).sort();
expect(codes.filter((c) => c === 200).length).toBe(1);
expect(codes.filter((c) => c === 404).length).toBe(11);

Exactly one 200 and eleven 404s.

The other limits are deliberately simple. Expiry is one of three fixed values (1 hour, 1 day, 7 days), and the server rejects anything else. Files and messages are capped at 5 MB, checked in the browser and again on the server. Creates are limited to 20 per hour and lookups to 30 per minute per network. The rate limiter stores only a salted hash of the network, not the IP. A scheduled job purges expired drops.

What this doesn't protect against

I'd rather be precise about the limits than oversell. This list also appears on the security page:

• Whoever opens the link first wins. The link is the key. If it leaks through chat history, a screenshot or a shared clipboard before the recipient opens it, the attacker reads it. The recipient then sees "gone" and knows something is wrong, but it can't be undone.
• A passphrase doesn't stop burning. The reveal POST deletes the drop before the passphrase is checked in the browser. Someone with the link but not the passphrase can destroy the drop, even though they can't read it. Also, a wrong passphrase doesn't restore the drop. The ciphertext stays in that tab so you can retry, and it's gone once the tab closes.
• Weak passphrases can be guessed offline by anyone who has both the link and the ciphertext. PBKDF2 slows that down. It doesn't prevent it.
• You trust the JavaScript we serve. As with every browser-based encryption tool, a compromised server could ship code that leaks the key. A strict Content-Security-Policy and zero third-party scripts reduce the risk but don't remove that trust.
• Compromised endpoints, malicious browser extensions, or a recipient who simply keeps a copy.
• Metadata. The server stores the ciphertext size, creation and expiry times, and the salted network hash for rate limiting. Anyone holding a valid ID can also see whether a drop exists and when it expires.
• Database backups. The database keeps point-in-time recovery snapshots for about 7 days. Any copy there is ciphertext without a key.
• Sender identity. Drops are anonymous. Confirm who sent one through another channel.

If you're building something similar, these are the three rules I'd keep: put the key in the fragment, never let a GET change state, and make "read" and "delete" the same SQL statement.

Try it: https://b1.gg

That small idea turned out to need some careful engineering. Here is how it works, taken straight from the source.

Why a writing app should end

A goal that never ends isn't really a goal. A fixed daily target makes starting cheap: you know how much is "enough" before you write the first word. So the app has one constant, GOAL = 1000, and one moment that matters, when the count crosses it. Completion is recorded once (completedAt) and stays recorded. If you delete a sentence afterwards, the day doesn't become unfinished.

That puts all the pressure on one function. If the count is wrong or easy to game, the full stop means nothing.

Counting correctly

"Characters" sounds simple until you remember what string.length actually returns: UTF-16 code units. '🙂'.length is 2, a flag is 4, and 'cafe\u0301' (an e plus a combining accent) is 5. For a writer, each of those should count as what they see on screen.

There's a second problem: whitespace. If spaces count, someone can hold down the space bar and "finish". If spaces don't count, ordinary prose is penalised, because the spaces between words are part of writing. The rule I settled on:

• every user-perceived character counts: letters, digits, punctuation, emoji, CJK ideographs, and the spaces between words;
• a run of whitespace (spaces, tabs, line breaks) counts as one character;
• leading and trailing whitespace counts nothing.

Honestly, I didn't get there in one go. The git history has a commit that made every whitespace character count separately, followed about an hour later by a revert to "runs count once". The revert message gives the reasons: it matched the copy on the site, and it kept the drawing of the page (more on that below) consistent.

Here is the counter, slightly trimmed:

const segmenter = (() => {
  try {
    return Intl.Segmenter
      ? new Intl.Segmenter(undefined, { granularity: 'grapheme' })
      : null;
  } catch { return null; }
})();

const PRINTABLE_ASCII = /^[\x21-\x7e]*$/;

export function graphemeCount(s: string): number {
  if (PRINTABLE_ASCII.test(s)) return s.length; // fast path
  if (segmenter) { let n = 0; for (const _ of segmenter.segment(s)) n++; return n; }
  return [...s].length; // fallback: code points
}

export function charRuns(text: string): number[] {
  if (!text) return [];
  const out: number[] = [];
  for (const run of text.split(/\s+/u)) if (run) out.push(graphemeCount(run));
  return out;
}

export function countChars(text: string): number {
  const runs = charRuns(text);
  let n = runs.length ? runs.length - 1 : 0; // one counted space between runs
  for (const r of runs) n += r;
  return n;
}

A few details worth pointing out:

• Grapheme clusters come from Intl.Segmenter. Where it's missing, the code falls back to code points ([...s]), which still handles astral characters like 𝒜, though not ZWJ sequences.
• The ASCII fast path. Most runs in English text are plain printable ASCII, where one code unit is one character, so the code skips the segmenter for them. This matters because the count runs on every input event.
• Splitting on /\s+/u gives you the whitespace rule for free. Empty strings at the edges are dropped, so leading and trailing whitespace disappears. Each gap between runs adds exactly one.

That gives a useful invariant: countChars(t) === sum(charRuns(t)) + max(0, runs - 1). The unit tests check it, along with the cases I worried about most:

expect(countChars('cafe\u0301')).toBe(4);   // e + combining acute
expect(countChars('👩‍💻')).toBe(1);          // ZWJ sequence
expect(countChars('🇸🇦')).toBe(1);           // flag
expect(countChars('a' + ' '.repeat(500) + 'b')).toBe(3);
expect(countChars('   \n\n ')).toBe(0);     // can't pad your way to 1,000

Local-first: no account, and export

The writing never leaves the device. Storage sits behind a small Store interface with three implementations. It prefers IndexedDB (one object store, entries, keyed by day). If that fails, as it does in some private browsing modes, it falls back to localStorage. If that's blocked too, it uses an in-memory map, and the Data page tells you plainly: "memory only (this browser blocks storage; export before closing)".

export async function openStore(name: string): Promise<Store> {
  try {
    if (typeof indexedDB !== 'undefined') return await openIdb(name);
  } catch { /* fall through */ }
  try {
    localStorage.setItem('1k:probe', '1'); localStorage.removeItem('1k:probe');
    return kvStore(name, localStorage);
  } catch { return kvStore(name, null); } // memory only
}

Writes are debounced by 400 ms. The pending save is flushed when the tab is hidden or closing, and saved immediately at the moment you cross 1,000. An end-to-end test types 600 characters, waits, and asserts that zero network requests were made. The Content-Security-Policy (default-src 'self'; connect-src 'self') backs that up at the browser level.

With no account, export is the backup plan, so there are three formats:

• Markdown: every page, oldest first, each with its date, count and a "done" marker;
• JSON: a versioned backup (format: '1k.gg/backup', version: 2) that can be imported again;
• TXT: today's page exactly as written.

Import never trusts the numbers in the file. parseBackup validates each entry, rejects oversized pages, and recomputes every count with countChars. That's how older word-count backups still import cleanly after the switch to characters. When the same day appears in both the backup and your current data, the merge keeps the copy edited most recently, and completion stays sticky.

The share card that never shows your words

People want to share that they finished. I didn't want them to share what they wrote, and I didn't want a share button that leaks a private journal by accident.

The answer is "the Thousand": today's page drawn as strokes. Each run of non-space characters becomes one rounded stroke, as long as the run, and each gap is the one counted space. Because of the invariant above, ink plus gaps adds up exactly to the day's count, and a vermilion dot lands right after the stroke holding the 1,000th character. Anything written after that is drawn fainter. The layout is a pure function of number[]. It never receives the text.

The share card paints that layout onto a 1080×1080 canvas, adds the line "my 1k of the day", the date and the character count, and exports a PNG. The drawing function only needs a small subset of CanvasRenderingContext2D, so I can unit-test it with a recording fake and assert that no word from the page ever reaches fillText:

drawShareCard(r.ctx, { runs: charRuns(page), chars: 1049, dateLabel: 'Tuesday 13 October' });
expect(all).toContain('my 1k of the day');
expect(all.join(' ')).not.toMatch(/w\drd/); // the writing itself is never drawn

Sharing goes through the Web Share API when the browser can share files, and falls back to a download otherwise:

if (typeof File === 'function' && typeof nav.share === 'function' && typeof nav.canShare === 'function') {
  const file = new File([blob], name, { type: 'image/png' });
  if (nav.canShare({ files: [file] })) {
    try { await nav.share({ files: [file], title: SHARE_LINE }); return 'shared'; }
    catch (e) { if (e.name === 'AbortError') return 'cancelled'; }
  }
}
downloadBlob(blob, name);
return 'downloaded';

One practical trick: navigator.share() needs a user gesture, and rendering a PNG is async. So the app pre-renders the card while idle once the day is complete and caches it by day and count. The click can then call share() right away.

Testing a tiny static app

The whole thing is a Vite build of plain TypeScript with no framework, and the test suite is far bigger than the app:

• 44 Vitest unit tests covering counting, the Thousand layout and its invariant, export/import (including old backups), dates and streaks, storage (with fake-indexeddb), and the share card;
• 127 Playwright tests across Chromium, Firefox, WebKit, a Pixel 7 and an iPhone 14 profile. They cover the 999 → 1,000 transition, a check that the downloaded PNG really is 1080×1080 with a PNG signature, Web Share (stubbed) and the download fallback, axe accessibility scans, and every page loaded under the production CSP.

The lesson I'd pass on: keep the interesting logic in pure functions (countChars, thousandLayout, drawShareCard, parseBackup). Then the browser tests only have to prove the wiring.

Try it: https://1k.gg