Forem: V G P

We Keep Building Bigger Walls Around the Wrong Thing

V G P — Fri, 15 May 2026 22:34:14 +0000

There's a species of tree in dense forests that grows toward whatever gap in the canopy lets light through. It doesn't ask permission. It doesn't register with the other trees. It just moves toward what it needs, and the forest works because of that — not in spite of it.

We don't build software that way anymore.

At some point we decided that before a user can do anything — read a note, save a preference, pick up where they left off — they need to announce themselves to a server, wait for a response, get issued a token, and carry that token everywhere like a passport in a country that checks papers at every door.

And when that system gets too heavy, we don't question the system. We add another layer to it.

There are entire job functions dedicated to managing this. Entire platforms — some charging by the login — whose whole purpose is to sit between your user and your app and say: prove yourself first. The infrastructure behind a simple "remember my theme preference" can span multiple availability zones, three third-party vendors, and a compliance audit.

Nobody stops to ask whether this was the only way.

I'm not arguing against security. I'm asking about proportion.

A river doesn't move water by building a bigger pump. It follows the path of least resistance, deposits what it carries at the delta, and keeps moving. The water arrives. Nothing registers. Nothing authenticates. The delta doesn't care where the water came from — it cares what the water does when it gets there.

The session token model is the opposite of this. It says: water cannot flow until we verify it's water, issue it a credential, log that it arrived, and stand ready to revoke its water-ness at any time. Then we wonder why everything feels sluggish.

What I've been working on with tessera starts from a different assumption.

The user already has the device. The device already has the browser. The browser already has a crypto engine sitting idle — AES-256-GCM, PBKDF2, Web Crypto — powerful enough to handle what most apps actually need to protect. The passcode stays local. The key never leaves the device. The server never enters the picture.

const vault = await Tessera.unlock('abc123');
await vault.local.setItem('preferences', JSON.stringify(prefs));

No round-trip. No token. No registration. The user's data is encrypted with their own passcode, in their own browser, and only they can read it.

That's not a compromise. For a significant class of problems, that's strictly better — because there's no central store to breach, no credential database to leak, no session to hijack in transit.

There's a concept in structural design called the minimum viable structure — the least amount of material you can use while still holding the load. Bridges built this way are elegant. They carry weight precisely because they don't carry anything extra. Every beam earns its place.

Most auth infrastructure fails this test badly. It carries weight that exists to justify itself: the logging layer that feeds the dashboard nobody checks, the token refresh cycle that prevents a session timeout nobody would have noticed, the password complexity rules enforced by a system that hashes the password anyway.

tessera tries to be the minimum viable structure for what it actually does. Encrypt the data. Derive the key locally. Let the value expire when it should. Notice when something looks wrong.

vault.local.setItem('one_time_code', value, {
  ttl: 30_000,
  maxReads: 1,
});

That's it. The code is gone after one read. No server involved in that transaction. No revocation request. It just ceases to exist.

The immune system doesn't keep a registry of every pathogen it's ever seen stored on a central server somewhere. It carries the memory in the cells themselves — distributed, local, present at the point of contact. When something unfamiliar shows up, the response comes from within, not from a round-trip to headquarters.

tessera does something similar with honey keys — decoys planted inside storage that look identical to real entries. Real code never touches them. Anything enumerating storage and guessing will.

vault.on('honey-hit', (event) => {
  // something is probing your storage
});

The detection lives where the data lives. No external service needed.

I'm not trying to kill authentication. There are things that genuinely require a server, a verified identity, a shared secret negotiated between two parties. I'm not pretending otherwise.

But I think we've spent so long inside one way of thinking about identity and access that we've stopped noticing the assumptions embedded in it. That every interaction needs a server to bless it. That local state is inherently less trustworthy than remote state. That the right response to a security problem is always more infrastructure.

Some problems don't need a bigger wall. They need a different shape entirely.

tessera is small. It's a start. But it's built on the premise that the device in your user's hand is already powerful enough to protect their data — if you give it the right tools and get out of the way.

npm install @mrtinkz/tessera

GitHub — I'd genuinely like to know where you think this line of thinking breaks down.

@mrtinkz/tessera v0.1.2 — I Wasn't Done Yet

V G P — Fri, 15 May 2026 22:19:49 +0000

After shipping v0.1.0 I did what most developers do after a release — I opened my own app and started poking around.

The values were ciphertext. Good. But the keys were sitting right there in plain English. auth_state. cart_items. pending_payment. Anyone who opened DevTools knew exactly what I was keeping track of, even if they couldn't read the contents. That shouldn't have bothered me as much as it did. But I couldn't let it go.

So I kept going.

Your keys now mean nothing to anyone but you

tessera now runs every key name through HMAC-SHA-256 before it touches storage. What you call cart_items, tessera stores as t_3a9f7c2e. Close DevTools, reopen it, and all you see is:

t_3a9f7c2e  →  <ciphertext>
t_b2d4f110  →  <ciphertext>
t_03e8a5cc  →  <ciphertext>

The mapping only exists in memory, derived from your passcode. Lock the vault — it's gone.

Some of those entries are fake

Here's the thing I'm most pleased with: not all of those entries are real. tessera automatically plants honey keys — decoys that look exactly like real values. Same key format, same ciphertext format. Completely indistinguishable.

Real code never touches them. Only something enumerating your storage and guessing would. That's the tripwire.

vault.on('honey-hit', (event) => {
  // something is probing your storage
});

Values that delete themselves

Some data shouldn't outlive its purpose. A one-time code. A recovery token. A payment session. v0.1.2 lets values carry their own expiry:

vault.local.setItem('one_time_code', value, {
  ttl: 30_000,   // gone after 30 seconds
  maxReads: 1,   // gone after first read
});

There's no background timer running. The check happens at read time — the moment something requests the value, tessera looks at the write timestamp and acts. If it's expired, it wipes before returning anything. A timer can be cleared by an attacker. A check on read cannot.

Don't want to configure every key manually? Sensitivity presets have you covered:

vault.local.setItem('recovery_code', value, { sensitivity: 'critical' });
// 5 minute TTL, 3 max reads, wiped at first sign of trouble

It notices things that shouldn't be happening

The last thing I added was a suspicion engine. If reads start coming in faster than any human could trigger them, tessera notices. If an HMAC check fails on a read — meaning the value was touched outside the API — tessera notices that too.

You decide what happens:

Tessera.unlock('123456', {
  suspicion: {
    rateLimit: { callsPerSecond: 10 },
    onSuspicion: 'lock',
  },
});

lock, wipe, or throw. tessera just makes sure something happens.

The encryption in v0.1.0 was the obvious part. v0.1.1 is all the stuff I couldn't stop thinking about after — the layers that make it hard to learn anything useful from your storage even when someone already has full read access.

npm install @mrtinkz/tessera

GitHub — feedback always welcome.

I Built a Zero-Dependency Browser Storage Encryption Library — Here's Why

V G P — Thu, 14 May 2026 05:21:55 +0000

A few months ago I found myself auditing a side project and noticed something uncomfortable: I was storing sensitive user preferences, cart data, and session tokens in localStorage — completely in plaintext. Anyone with DevTools open could read it in two seconds.

The obvious fix is "just encrypt it." But when I went looking for a library that actually did this well, I kept running into the same problems: heavy dependencies, weak key derivation, or APIs that felt bolted on as an afterthought. So I built tessera.

What tessera does

One passcode. All your browser storage — localStorage, sessionStorage, IndexedDB, and cookies — encrypted with AES-256-GCM. The key is derived from PBKDF2-SHA-256 at ≥ 310,000 iterations (the OWASP 2024 minimum), and it never leaves the Web Crypto engine as raw bytes.

The API is a drop-in replacement for the storage APIs you already use:

import { Tessera } from '@mrtinkz/tessera';

const vault = await Tessera.unlock('abc123');
await vault.local.setItem('cart', JSON.stringify(cartData));
const cart = await vault.local.getItem('cart'); // plaintext back
vault.lock(); // zeroes the in-memory key

No server round-trips. No cloud keys. No dependencies.

The threat model I was actually designing against

Most encryption libraries stop at "we encrypt the data." tessera is built against the OWASP browser storage threat model, so let me be specific about what it protects and what it doesn't.

What it protects against:

Passive observer in DevTools — storage values are ciphertext. Useless without the key.
XSS reading storage — same deal. The attacker gets ciphertext.
Offline brute force — PBKDF2 at 310k iterations costs roughly 1 second per attempt on modern hardware.
Key exfiltration via heap dump — extractable: false means the raw key bytes never exist in JavaScript memory.
On-device brute force — configurable lockout: wipe all storage, apply exponential backoff, or throw immediately after N failed attempts.

What it doesn't protect against:

tessera protects your data at rest — when the vault is locked, everything in storage is ciphertext. Unlocking doesn't decrypt everything at once; it just derives the key and holds it in memory. Individual values only decrypt on demand when you call getItem.

The one scenario where this breaks down is if your page already has an XSS vulnerability. An attacker running code on your page has the same access you do — they can call vault.local.getItem() while the vault is unlocked and get plaintext back, one value at a time. They can't steal the raw key bytes (extractable: false blocks that), but they don't need to. Fix XSS first; tessera handles the rest. The threat model docs go deeper on this.

The crypto internals

Each stored value gets its own salt and IV. The stored format is:

salt(16) ‖ iv(12) ‖ ciphertext ‖ tag(16)

The vault salt lives in localStorage so the same passcode re-derives the same key across sessions — you unlock once per session, not once per page load.

Key derivation:

PBKDF2(passcode, vaultSalt, 310_000 iterations, SHA-256) → AES-256-GCM key

The CryptoKey is created with extractable: false. The Web Crypto engine holds the key material; your JavaScript never sees the raw bytes.

The PIN pad problem

I wanted to mitigate keyloggers and click-sequence recording. The naive approach — an HTML grid of buttons with digit labels — fails because:

Keyloggers read keydown events
Click-sequence recording reads which DOM element was clicked
The digit labels on buttons reveal the sequence

tessera ships a Canvas-based PIN pad. Digit positions are randomised on every render. No DOM element carries a digit value. A click recorder sees coordinates, not digits.

import { renderPinPad } from '@mrtinkz/tessera';

renderPinPad(document.getElementById('pin'), {
  onUnlock: async (passcode) => {
    const vault = await Tessera.unlock(passcode);
  },
  randomize: true,
  length: 6,
});

You can style it with CSS custom properties:

.tessera-pin-pad {
  --tessera-pad-bg: #1a1a2e;
  --tessera-btn-bg: #16213e;
  --tessera-btn-color: #e2e8f0;
  --tessera-btn-hover: #0f3460;
  --tessera-btn-size: 64px;
  --tessera-indicator-color: #4ade80;
}

Framework support

tessera ships ESM, CJS, and IIFE builds. There are native adapters for React, Vue 3, Svelte, and Angular so you get a hook/store/service rather than managing vault state yourself.

React:

'use client';
import { useTessera } from '@mrtinkz/tessera/react';

function SecureApp() {
  const { vault, isLocked, unlock, lock } = useTessera({ idleTimeout: 600_000 });

  if (isLocked) return <PinPad onUnlock={unlock} />;
  return <Dashboard vault={vault} onLock={lock} />;
}

Vue 3:

<script setup lang="ts">
import { useTessera } from '@mrtinkz/tessera/vue';
const { vault, isLocked, unlock, lock } = useTessera({ idleTimeout: 600_000 });
</script>

Svelte:

<script lang="ts">
  import { tesseraStore } from '@mrtinkz/tessera/svelte';
  const { vault, isLocked, unlock, lock } = tesseraStore({ idleTimeout: 600_000 });
</script>

There's also an Angular TesseraModule and TesseraService if that's your stack.

Idle timeout and cross-tab sync

The vault auto-locks after a configurable idle period. When it locks, it broadcasts over BroadcastChannel so every open tab locks simultaneously. No stale unlocked tabs sitting in the background.

const vault = await Tessera.unlock('abc123', {
  idleTimeout: 900_000,    // 15 minutes
  lockoutAttempts: 5,
  lockoutAction: 'wipe',   // nuclear option
});

Install

npm install @mrtinkz/tessera

CDN:

<script src="https://cdn.jsdelivr.net/npm/@mrtinkz/tessera/dist/index.global.global.js"></script>
<script>
  const { Tessera } = TesseraLib;
  Tessera.unlock('abc123').then((vault) => {
    vault.local.setItem('theme', 'dark');
  });
</script>

Browser support: Chrome/Edge 89+, Firefox 86+, Safari 15+. Also works in Deno, Bun, and Cloudflare Workers.

I'd love feedback — especially from anyone who's thought hard about browser storage security. What's missing? What would you do differently? Drop it in the comments or open an issue on GitHub.

Docker Desktop Won't Start After a BIOS Update? Check This First

V G P — Tue, 12 May 2026 02:36:29 +0000

I spent way too long troubleshooting this. Reinstalled Docker Desktop multiple times, wiped config folders, checked WSL, verified Hyper-V — nothing worked. Turns out the fix was two PowerShell commands.

Here's what happened and how to fix it fast if you run into the same thing.

The Situation

My ThinkPad T480 got a BIOS and firmware update. After rebooting, Docker Desktop stopped launching. No error dialog, no crash message — it just silently died every time. The whale icon would never show up in the system tray.

Running wsl --list showed no docker-desktop distro. The logs had nothing useful — just Docker initializing and then abruptly stopping. Looked like a WSL problem, a virtualization problem, or a busted installation. It was none of those.

What Was Actually Wrong

The BIOS update disrupted Windows service configurations. The Docker Desktop backend service — com.docker.service — got flipped to Manual startup, so it was no longer running when Windows booted.

Docker Desktop's UI process depends entirely on that backend service. If the service isn't running, the UI launches, finds nothing to connect to, and kills itself immediately. No warning, no useful error — just gone.

The Fix

Open PowerShell as Administrator and run:

Start-Service com.docker.service
Get-Service com.docker.service

You should see Status: Running. Then lock it in so it survives future reboots:

Set-Service com.docker.service -StartupType Automatic

Then launch Docker Desktop normally from the Start Menu (or via PowerShell):

Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"

That's it. Whale icon appears, engine starts, everything works.

Save This for Next Time

If Docker Desktop ever silently dies on you again, run this before doing anything else:

Get-Service com.docker.service

If the status is Stopped, just start it. You'll save yourself an hour of unnecessary reinstalls.

And if the service is running but Docker still won't start, then check the actual log for a real error:

Get-Content "$env:LOCALAPPDATA\Docker\log\host\com.docker.backend.exe.log" -Tail 50 | Select-String -Pattern "error|fatal|panic|fail" -CaseSensitive:$false

Tested on ThinkPad T480, Windows 11, WSL2 with Debian. Hope this saves someone the hour I lost.