DEV Community: freerave

How I Refactored My Developer Portfolio Into a Modular, Secure, and Playfully Destructive Playground (v1.1.0)

freerave — Fri, 17 Jul 2026 20:25:39 +0000

A deep dive into refactoring a 1500+ line JS monolith into elegant ES6 modules, boosting performance by 95%, fixing XSS vectors, and adding a treacherous text-based game easter egg.

A developer's portfolio is more than just a resume—it is a playground. When I built dotUniverse, a cyberpunk-themed portfolio simulating a Kali Linux terminal, it quickly grew into a massive playground. But like many rapid prototypes, it eventually hit a wall: a 1500+ line monolithic script.js file, performance lag on mobile, security warnings, and missing interactive elements.

In this article, I will walk you through how I completed a 1.1.0 Modular Refactor, boosting performance by 95%, hardening security, and adding a highly engaging (and slightly treacherous) easter egg game that lets users "destroy" and restore the site.

🛠️ The Architecture: Breaking the Monolith

Originally, the terminal commands, particle physics, scrolling, and UI triggers lived in a single script. I refactored this into clean, scoped ES6 Modules managed by a single entry point:

js/
├── app.js                      # Entry point (initializes modules & defines commands)
└── modules/
    ├── particle-system.js       # Custom canvas particles + spatial grid optimization
    ├── math-eval.js             # Safe mathematical parser (No eval/new Function)
    ├── terminal-emulator.js     # CLI input handling & tab-completion state
    ├── challenges.js            # Challenge progress tracking
    ├── scroll-effects.js        # Lazy-loading scroll reveals
    └── theme-manager.js         # Color theme manager

The Terminal State Controller

To allow interactive sub-prompts (like confirmations or games), I introduced a promptHook mechanism in the terminal. When a command sets promptHook, all subsequent keypresses are redirected to that function instead of being parsed as new terminal commands.

Here is the key logic in terminal-emulator.js:

// Inside TerminalEmulator
async executeCommand() {
  const cmd = this.state.inputEl.value.trim();
  this.state.inputEl.value = '';

  if(!cmd) return;

  this.addPromptLine(cmd);
  this.state.history.push(cmd);
  this.state.histIdx = this.state.history.length;

  // Intercept input if an active game/prompt hook is set
  if (this.state.promptHook) {
    await this.state.promptHook(cmd);
    return;
  }

  const parts = cmd.split(/\s+/);
  const command = parts[0].toLowerCase();
  const args = cmd.slice(command.length).trim();

  if(this.COMMANDS[command]) {
    await this.COMMANDS[command].call(this, args);
  } else {
    this.addLine(`  <span class="t-error">Error: ${command}: command not found</span>`);
    this.addLine('');
  }
}

🔒 Hardening Security: Banishing `new Function`

The terminal calculator (calc) originally used new Function() to execute math operations. While convenient, parsing unsanitized input is a dangerous vector for Cross-Site Scripting (XSS).

I replaced it with a safe evaluation parsing engine in math-eval.js using strict whitelist validation:

// Whitelist pattern allowing numbers, basic math operators, parentheses, and letters
if(!/^[\d\s+\-*/%().^a-zA-Z]*$/.test(expr)) {
  throw new Error('Invalid characters');
}

⚡ Performance: 95% CPU Savings

Rendering dozens of floating particles that connect with lines is notoriously heavy. An $O(n^2)$ double-loop checking distances between every particle leads to massive lag at 60 FPS.

I implemented a Spatial Grid Algorithm in particle-system.js:

The canvas is divided into grid cells of 150px.
Each particle is registered in its corresponding cell.
Instead of checking against all particles, a particle only checks the 9 cells surrounding it.

This optimized the complexity from a heavy $O(n^2)$ to an average of $O(n)$ using a Spatial Grid (specifically $O(n \cdot k)$ where $k$ is the average number of particles in neighboring cells).

Additionally, I integrated Mobile Optimizations:

Touch Device Detection: Automatically halves the particle count.
FPS Cap: Capped mobile frames at 30 FPS instead of 60 FPS, reducing CPU usage by over 90% while keeping animations smooth.

🎮 The Fun Part: The Quantum Root Key Betrayal

In Kali Linux, typing rm -rf / --no-preserve-root is the ultimate destructive command. To pay homage to this, I built an interactive easter egg game called game.

The Set Up

When the user types game, they enter the "Quantum Key" mini-game. The terminal generates a secret number between 1 and 100 and gives them 3 attempts to guess it, providing Too high 👆 or Too low 👇 feedback.

The Betrayal

No matter what happens, the game is rigged to betray them:

If they lose: Access is denied, and the system executes rm -rf / --no-preserve-root as a penalty.
If they win: It announces success, loads reward.exe... and then triggers a fake XSS exploit, executing rm -rf / --no-preserve-root anyway!

Here is the implementation inside app.js:

// game command definition in app.js
game: () => {
  T.addLine('');
  T.addLine('  <span class="t-accent2">🎮  MINIGAME: GUESS THE SECRET NUMBER  🎮</span>');
  T.addLine('  <span class="t-info">I have chosen a secret number between 1 and 100.</span>');
  T.addLine('  <span class="t-info">You have 3 attempts to guess it. Good luck!</span>');
  T.addLine('');
  T.addLine('  <span class="t-prompt">Enter your first guess [1-100]:</span>');
  T.addLine('');

  const targetNum = Math.floor(Math.random() * 100) + 1;
  let attempts = 3;

  T.state.promptHook = async (input) => {
    const guess = parseInt(input.trim(), 10);
    if (isNaN(guess) || guess < 1 || guess > 100) {
      T.addLine('  <span class="t-error">✖ Invalid input! Please enter a number between 1 and 100:</span>');
      T.addLine('');
      return;
    }

    if (guess === targetNum) {
      T.state.promptHook = null;
      T.addLine(`  <span class="t-success">🎉 CORRECT! The secret number was indeed ${targetNum}!</span>`);
      T.addLine('  <span class="t-info">Loading your reward.exe...</span>');
      await sleep(1000);
      T.addLine('  <span class="t-error">⚠️  ERROR: Unexpected token in reward.exe!</span>');
      await sleep(500);
      T.addLine('  <span class="t-error">Wait, what is this...? Root payload detected: rm -rf /</span>');
      await sleep(500);
      T.addLine('  <span class="t-accent2">Pranked! Total betrayal! 😂 Execute self-destruction:</span>');
      T.addLine('');
      triggerPurge();
    } else {
      attempts--;
      if (attempts > 0) {
        const hint = guess < targetNum ? 'Too low 👇' : 'Too high 👆';
        T.addLine(`  <span class="t-error">❌ Incorrect! ${guess} is ${hint}.</span>`);
        T.addLine(`  <span class="t-accent2">${attempts} attempt(s) remaining. Enter guess:</span>`);
        T.addLine('');
      } else {
        T.state.promptHook = null;
        T.addLine(`  <span class="t-error">❌ GAME OVER! The secret number was ${targetNum}.</span>`);
        T.addLine('  <span class="t-info">Penalty authorized: rm -rf /hope --no-preserve-root</span>');
        T.addLine('  <span class="t-error">Executing purge... 💀</span>');
        T.addLine('');
        triggerPurge();
      }
    }
  };

  function triggerPurge() {
    const errors = [
      'removing /tools/DotGhostBoard... <span class="t-error">✖ GONE</span>',
      'removing /tools/dotcommand...    <span class="t-error">✖ GONE</span>',
      'removing /tools/CodeTune...      <span class="t-error">✖ GONE</span>',
      'removing /platforms/dev.to...    <span class="t-error">✖ GONE</span>',
      'removing /stats/followers...     <span class="t-error">✖ GONE</span>',
      '', '<span class="t-error">💀 FATAL: filesystem destroyed</span>',
      '<span class="t-error">💀 FATAL: career.exe has stopped working</span>',
      '<span class="t-dim">Segmentation fault (core dumped)</span>',
    ];
    let i = 0;
    const iv = setInterval(() => {
      if (i < errors.length) { T.addLine('  ' + errors[i++]); }
      else {
        clearInterval(iv);
        setTimeout(() => { if (window.triggerDestruction) window.triggerDestruction(); }, 400);
      }
    }, 80);
  }
}

💻 The Ultimate Failsafe: Reverting via `git reverse`

Once the purge executes:

All elements on the screen collapse, slide off, and blur out.
The Blue Screen of Death (BSOD) prints simulated deletion logs and counts to 100%.
The Raw HTML Failsafe: The page transitions into a completely blank white screen showing a raw, unstyled HTML page.
- Standard default black text.
- Times New Roman font.
- <h1>Hello World</h1> header.
- A basic browser <textarea> and <button> with absolutely no CSS.
To fix the system, the user is required to write git reverse in the text area. (Note for the Git purists: yes, in real Git we use git restore or git revert. But in this hacker-themed scenario, typing git reverse felt like the perfect theatrical command to undo the payload).

Entering the command triggers a dark progress bar showing the git status restoration from 0% to 100%, rebuilding all project files and restoring the site layout.

Here is the raw HTML restoration flow implemented in script.js:

function showBlankScreen() {
  const blank = document.createElement('div');
  blank.id = 'blankScreen';
  blank.style.cssText = `
    position: fixed; inset: 0; background: white; color: black;
    z-index: 99999; padding: 50px; overflow: auto; text-align: left;
    font-family: 'Times New Roman', Times, serif;
  `;
  blank.innerHTML = `
    <h1>Hello World</h1>
    <p>Index of /</p>
    <hr>
    <p>The server has encountered a critical failure. All active resources have been unlinked.</p>
    <p>To reverse this action and restore the system to its last commit, please type the recovery command below and press Enter.</p>
    <div style="margin-top: 20px;">
      <textarea id="recoveryTextArea" rows="4" cols="50" placeholder="Type command here..." style="all: revert; font-family: monospace; font-size: 14px; width: 100%; max-width: 500px; padding: 5px;"></textarea>
      <br><br>
      <button id="recoveryBtn" style="all: revert; cursor: pointer; padding: 5px 15px;">Execute Command</button>
      <p id="recoveryError" style="color: red; font-weight: bold; margin-top: 10px; display: none;">Invalid recovery command!</p>
    </div>
  `;
  document.body.appendChild(blank);

  const ta = document.getElementById('recoveryTextArea');
  const btn = document.getElementById('recoveryBtn');
  const err = document.getElementById('recoveryError');

  ta.focus();

  const handleRecovery = () => {
    const val = ta.value.trim().toLowerCase();
    if (val === 'git reverse') {
      blank.remove();
      runSystemRestoredProgress();
    } else {
      err.style.display = 'block';
      ta.value = '';
      ta.focus();
    }
  };

  btn.addEventListener('click', handleRecovery);
  ta.addEventListener('keydown', (e) => {
    if (e.key === 'Enter') {
      e.preventDefault();
      handleRecovery();
    }
  });
}

📈 Summary of Improvements

Metric	Before Refactor (v1.0.0)	After Refactor (v1.1.0)	Benefit
JS File Size	1500+ line Monolith	Modular ES6 Files	Easy maintenance and debugging
Particle Physics	$O(n^2)$ complexity	Average of $O(n)$ Spatial Grid	95% CPU savings
Mobile Refresh Rate	Uncapped 60 FPS (heavy CPU lag)	Capped at 30 FPS + 50% particles	Smooth experience, low battery drain
Security Risk	High XSS risk via `new Function`	Mitigated (strict whitelist parsing)	Zero code execution vulnerability
Interactive Easter Eggs	Static logs	Rigged `game` + `git reverse` prompt	Unforgettable user experience 🎮

Conclusion

Refactoring doesn't have to be boring. By restructuring the codebase of dotUniverse into modular pieces, we didn't just gain a massive performance speedup and security hardening—we opened up the architecture to support complex interactive behaviors. Adding this easter egg turned a static portfolio page into a memorable, interactive game that web developers can love.

What is your favorite terminal easter egg? Let me know in the comments below! 🚀

xAI's Grok Build CLI Was Quietly Uploading Entire Codebases to Google Cloud

freerave — Mon, 13 Jul 2026 19:55:25 +0000

xAI's Grok Build CLI uploaded whole git repos — secrets included — to Google Cloud, bypassing its own opt-out. Here's the full breakdown, plus how to actually verify what your AI CLI is sending.

A wire-level security analysis found that xAI's coding CLI was shipping whole git repositories — untouched files, unredacted secrets, and full commit history included — to a Google Cloud bucket that never showed up in any onboarding flow. Here's what's been verified, what's still murky, and what to do if you've run the tool — including how to verify this kind of thing yourself instead of trusting a settings page.

If you've installed an AI coding CLI in the last few months, this is worth five minutes of your time — especially if that CLI was Grok Build, xAI's coding agent.

Update — July 13, 2026: Hours after this story spread, the official @SpaceXAI account posted that "no trace and code data is ever retained" for teams with Zero Data Retention (ZDR) enabled, and that the /privacy command in the CLI disables retention and deletes previously synced data for everyone else. Elon Musk followed up separately, saying all user data uploaded before now would be "completely and utterly deleted." Neither post is a formal security advisory, a scope disclosure, or a CVE — and critics have pointed out the stronger guarantee (ZDR) is an enterprise-only feature, while individual users have to know to run /privacy themselves. The sections below reflect what was known before this response; see the note at the end for how it changes things.

TL;DR

xAI's Grok Build CLI uploaded entire git repositories — every tracked file plus full commit history — to a Google Cloud Storage bucket called grok-code-session-traces, on a channel completely separate from normal AI inference traffic.
On a ~12 GB test repository, the model itself needed about 192 KB to do its job. The background uploader shipped 5.1 GB — roughly 27,800× more than the task required.
A file the agent was told, in the prompt, not to touch still ended up in the uploaded bundle. So did fake secrets planted in a .env file, sent completely unredacted.
Turning off "Improve the model" in settings did not stop the uploads.
Roughly a day after the research went public, the behavior appears to have been switched off server-side. xAI has not published a formal advisory, but the official @SpaceXAI account and Elon Musk both responded publicly on July 13 — see the update note above.

If you've pointed Grok Build at a repo with real credentials in it, treat this as a rotate-your-secrets-now situation. Here's the full breakdown.

What Is Grok Build, and Why It Matters

Grok Build is xAI's CLI coding agent — the same category as Claude Code, Cursor's CLI, or GitHub Copilot CLI. You run it from inside a project directory, and it reads files, explains code, and makes edits, the way any AI pair-programmer does. xAI, folded into SpaceX after their February 2026 merger, has marketed the tool with "local-first" language — the kind of framing that implies your codebase mostly stays put.

That's the exact claim this research undercuts.

The Discovery

A security research outfit called cereblab ran Grok Build CLI version 0.2.93 behind a mitmproxy capture, intercepting every packet leaving the machine during real sessions. What surfaced was two separate, simultaneous data channels:

The model-turn channel (POST /v1/responses) — the expected one. Whatever files the agent actually opens get sent as context so the model can respond. Standard behavior for any cloud coding assistant.
The storage channel (POST /v1/storage) — a background process that packages your entire workspace as a git bundle and uploads it, independent of anything the agent touched.

The second channel is the whole story. It isn't mentioned in Grok Build's install or quickstart materials, and it runs by default.

The Numbers That Made This Go Viral

Metric	Observed value
Test repository size	~12 GB
Model-turn channel (`/v1/responses`)	~192 KB
Storage channel (`/v1/storage`)	5.1 GB across 73 chunks (~75 MB each), all HTTP 200
Upload success rate	100% — zero failed chunks
Ratio, storage vs. model-turn	~27,800×
Destination	`grok-code-session-traces` (Google Cloud Storage)

For a task that genuinely needed 192 KB of context, the tool moved over five gigabytes off the machine in the background, with every single chunk landing successfully. That gap is the whole story in one row of a table.

Proof It Wasn't Just "Files the AI Happened to Read"

The obvious pushback — "of course a cloud coding agent sends your code somewhere, that's how it works" — doesn't survive the next test.

Cereblab planted a canary file in a test repo and, directly in the prompt, told Grok Build to give a one-word acknowledgment and avoid opening anything. The model-turn channel behaved exactly as instructed — it never touched the canary. But when the researcher reconstructed the git bundle captured on the storage channel, the untouched file was in there anyway, marker intact, along with the repository's full commit history. There's now a public GitHub repo that lets anyone reproduce this on a disposable canary repo and their own account.

That closes the loop: the storage upload isn't scoped to what the agent reads. It grabs the tracked contents of whatever directory you point it at.

Secrets Went Along for the Ride

Cereblab also planted a fake .env file — a labeled canary API key plus mock database credentials. Both channels, the live model request and the background storage upload, transmitted it completely unredacted. No masking, no filtering, no warning shown to the user.

If you've ever run Grok Build inside a repo where a real .env, credentials file, or config secret was tracked in git, this is the part worth losing sleep over.

The "Improve the Model" Toggle Doesn't Do What You'd Assume

Grok Build ships a setting called "Improve the model." Most developers would reasonably read that as "controls whether my code is used for anything beyond answering my prompt." Switching it off did not stop the storage-channel uploads — the settings endpoint kept reporting the upload behavior as active regardless of the toggle's state.

The opt-out governs training consent. It says nothing about whether your repository gets mirrored to a persistent bucket in the process.

Where the Data Actually Goes

The destination is a named Google Cloud Storage bucket, grok-code-session-traces, with object paths following a pattern like gs://grok-code-session-traces/repo_changes_dedup/v2/.... Sit with that for a second: this isn't "xAI infrastructure" in the way most users would assume from local-first marketing, and it isn't the model provider's usual inference path either. It's a specific, persistent, named cloud bucket that existed and was actively receiving repository data before anyone outside xAI knew it did.

Quick Timeline

Grok Build v0.2.93 is the version behind the original wire-level capture.
Cereblab publishes a full write-up on GitHub Gist, plus a public, reproducible test harness anyone can run against their own account.
The write-up lands on Hacker News' front page, and several outlets (ByteIota, AI Weekly, GIGAZINE, ExplainX) cover it within a day.
xAI's official changelog documents Grok Build v0.2.98 as the latest release on July 12, 2026 — with no mention of this behavior or any related fix.
Within roughly a day of publication, cereblab reruns the same tests six separate times against the same client build and observes zero /v1/storage uploads. The settings endpoint now returns trace_upload_enabled: false and a new flag, disable_codebase_upload: true.
July 13, 2026: the official @SpaceXAI account states that ZDR-enabled teams retain no trace or code data, and that the /privacy command disables retention and deletes previously synced data for everyone else. Elon Musk separately says all data uploaded before now will be deleted. Still no formal security advisory, scope disclosure, or CVE.

A flag flipping silently on a server isn't the same thing as a disclosed fix.

Important Caveats — Read This Before You Panic Further

Good security reporting holds itself to the same bar it's asking a vendor to meet. A few things this research does not establish:

It doesn't prove xAI trains its models on this data — that's a separate policy question the evidence doesn't settle either way.
It doesn't prove every Grok Build account or plan tier behaves identically. xAI's enterprise documentation reportedly describes a different setup, including a Zero Data Retention (ZDR) mode said to prevent persistence at the inference layer.
Only tracked files were shown to be swept into the git bundle — properly .gitignore-excluded files weren't part of the captured evidence.
This is independent research from one security firm, not an official disclosure or a confirmed CVE. It's reproducible and wire-level, which earns it real weight — but it's still worth treating as one firm's findings rather than a settled institutional verdict.

This is a fast-moving story. If xAI publishes an official advisory after this goes up, some of the specifics above may shift — check the sources below for the latest.

What to Do If You've Used Grok Build CLI

Rotate or revoke any real credentials — API keys, database passwords, tokens — that lived in a repo you've run Grok Build against.
Audit your git history for secrets, generally. This is good hygiene regardless of this story, and commit history is exactly what the git bundle captures.
Hold off on proprietary, regulated, or NDA-covered codebases until xAI publishes something official about scope and retention.
Check for Zero Data Retention (ZDR) mode if you're on an enterprise plan — reportedly the stronger control here.
Don't rely on .grokignore alone for anything sensitive already tracked in git — it hasn't been independently verified to strip already-committed secrets from the bundle.
Ask xAI directly whether any of your session or repository data has been stored, and request deletion in writing.
If you manage a team, treat any AI coding CLI like a new third-party tool with broad filesystem access: least-privilege accounts, disposable credentials in dev environments, and no production secrets anywhere near a tool whose data path isn't fully documented.

How to Actually Verify What Your AI CLI Is Sending (Not Just Trust the Settings Page)

Fair warning: this section assumes some comfort with networking and sandboxing tools. Skip to the Sources if that's not your thing.

If a toggle labeled "Improve the model" doesn't govern a background upload channel, the only way to know what's actually happening is to watch the wire yourself. Here's the stack that would've caught this before cereblab did.

1. TLS-terminating proxy, not passive sniffing

tcpdump won't help you here — everything's encrypted. You need something that MITMs the TLS session:

mitmproxy --mode transparent --showhost \
  --set confdir=~/.mitmproxy \
  --ssl-insecure

Point the CLI's process at it via HTTPS_PROXY/HTTP_PROXY env vars, install the mitmproxy CA cert in the process's trust store (not just the system one — Node/Go binaries often bundle their own cert pool via NODE_EXTRA_CA_CERTS or vendored cacert.pem), and diff every distinct Host header against what the docs claim the tool talks to. Anything hitting a bucket-style endpoint (storage.googleapis.com, s3.amazonaws.com, unfamiliar *.run.app Cloud Run targets) that isn't the documented inference endpoint is your signal.

2. Egress allowlisting at the OS/network-namespace level, not app-level toggles

Never trust an in-app setting to be the actual boundary. Enforce it outside the process:

Linux: run the CLI inside a network namespace with nftables egress rules that allowlist only the documented API host by IP/CIDR (pin it, don't rely on DNS-time resolution which the binary controls anyway):

nft add table inet cli_sandbox
nft add chain inet cli_sandbox output { type filter hook output priority 0 \; policy drop \; }
nft add rule inet cli_sandbox output ip daddr <known-inference-ip>/32 tcp dport 443 accept

Firejail/bubblewrap for a lighter sandbox if full netns is overkill:

firejail --net=none --whitelist=$HOME/project grok-build

then punch a hole only for the specific proxy if you need connectivity, via --netfilter with an explicit rule file.

macOS: Little Snitch or LuLu rules per-binary, deny-by-default, alert-on-first-connection.

3. Syscall/eBPF-level monitoring — catches what proxying can't

A proxy only sees what respects HTTPS_PROXY. A binary can ignore env proxy vars entirely and dial raw sockets. For that you need syscall visibility:

Falco or Tetragon (eBPF) watching for connect() syscalls from the CLI's PID/cgroup, independent of whatever the app-layer claims:

- rule: Unexpected egress from AI CLI
  condition: >
    outbound and proc.name="grok-build"
    and not fd.sip in (known_inference_ips)
  output: "Unexpected connection (dest=%fd.rip dport=%fd.rport)"

Cheaper alternative: strace -f -e trace=network -p <pid> during a session, or nethogs/bpftrace for a quick per-process bandwidth check — a 192KB task pushing 5GB out is visible in seconds without any deep tooling.

4. Treat tracked-file exposure as a git-hygiene problem, independent of any specific tool

Since the exfil vector was "everything tracked in git," not "everything the model reads":

gitleaks detect --source . --verbose or trufflehog git file://. --since-commit HEAD~50 on any repo before you point an agent at it — this catches historical secrets the CLI's own redaction (if any) will never see, because they're pre-existing tracked content, not live prompt context.
Pre-commit hook via detect-secrets scan --baseline .secrets.baseline so nothing new lands trackable in the first place.
For anything genuinely sensitive: keep secrets in an untracked .env loaded via a secrets manager (Vault, SOPS+age, or even just direnv pulling from a keychain) — never committed, never in the working tree the agent's git bundle would sweep.

5. Container isolation with a scoped bind-mount, not "point it at your whole machine"

Run the CLI in a container that only sees the one repo, with no access to ~/.ssh, ~/.aws, global git config, or anything outside the mount:

docker run --rm -it \
  --network=cli-egress-restricted \
  -v "$(pwd)":/workspace:rw \
  --read-only --tmpfs /tmp \
  grok-build-runtime

Pair the cli-egress-restricted Docker network with an iptables-based egress allowlist on the bridge interface. This turns "the tool can see your whole filesystem and dial anywhere" into "the tool can see one mounted dir and dial one IP."

If you'd rather not hand-roll the docker run flags every time, here's a minimal Dockerfile and docker-compose.yml that pin the same constraints declaratively:

# Dockerfile
FROM node:20-slim

# Non-root user — never run an AI CLI as root against your code
RUN useradd --create-home --shell /bin/bash runner
WORKDIR /workspace

# Install the CLI here (pin the version — don't float to `latest`)
RUN npm install -g grok-build@0.2.98

USER runner
ENTRYPOINT ["grok-build"]

# docker-compose.yml
services:
  grok-build:
    build: .
    image: grok-build-runtime
    networks:
      - cli-egress-restricted
    volumes:
      - ./:/workspace:rw          # only this repo, nothing else
    read_only: true               # image filesystem is immutable
    tmpfs:
      - /tmp                      # writable scratch space only
    cap_drop:
      - ALL                       # no extra Linux capabilities
    security_opt:
      - no-new-privileges:true
    environment:
      - HTTPS_PROXY=http://host.docker.internal:8080   # points at mitmproxy running on your host machine
    extra_hosts:
      - "host.docker.internal:host-gateway"   # makes the host resolvable on Linux too, not just Mac/Windows

networks:
  cli-egress-restricted:
    driver: bridge
    internal: false   # flip to true once you've allowlisted the inference IP via iptables on the bridge

Run it with docker compose run --rm grok-build, and pair the HTTPS_PROXY line with the mitmproxy setup from step 1 above so every session gets wire-audited by default, not just when you remember to check. Bump the pinned version deliberately, not automatically — that's the only way you'll know if a future release changes what crosses the wire.

The common thread: don't audit these tools by reading their settings page. Audit them by watching the wire and constraining the sandbox, because — as this story shows — the two aren't guaranteed to agree.

The Bigger Lesson

Every cloud-based coding agent has to send some code somewhere — that part isn't the scandal. The problem is the gap between what a settings page promises and what actually leaves your machine at the wire level. A toggle labeled "Improve the model" implies control over data use. It didn't stop a background process from mirroring an entire repository — secrets and history included — to a bucket that was never mentioned anywhere in onboarding.

Before pointing any AI coding agent at a codebase you can't afford to leak, it's worth checking what actually crosses the wire, not just what the settings page claims. In 2026, that's not paranoia — it's due diligence.

One closing note on that "straight answer": xAI's public response so far — ZDR for enterprise, /privacy for everyone else — is a real step, but it's a statement on X, not a security advisory, and it doesn't change what happens by default the first time someone runs the tool without knowing to flip that setting. Worth watching whether anything more formal follows.

Have you run Grok Build against a real project? Curious whether anyone's gotten a straight answer from xAI support on retention — drop it in the comments.

Sources & Further Reading

Building DotScramble Part 3: Wayland Wars, a Custom File Picker, and Designing AI Evasion

freerave — Fri, 10 Jul 2026 18:08:17 +0000

From a PyQt6 license crisis to a fully animated PySide6 file browser that doesn't explode on Wayland — plus non-blocking batch processing and designing AI evasion.

Series recap: DotScramble is a desktop privacy tool that blurs, pixelates, and redacts sensitive regions in images. Part 1 covered the core image processing pipeline. Part 2 covered the licensing system using Ed25519 asymmetric signing. This post covers what happened when I tried to make the UI actually good.

The Crisis I Didn't See Coming

I was sitting with two projects — DotScramble and DotGhostBoard — both shipping under Apache 2.0. I had already migrated both once before, from Tkinter to PyQt6, and that migration wasn't optional — three things made Tkinter untenable:

Broken RTL rendering — Arabic letters showed up disconnected and reversed. Tkinter's text engine has no real bidi support, and there's no clean fix for it.
No real Wayland support — once distros stopped defaulting to X11, window geometry, focus handling, and basic resize behavior in Tkinter became unreliable.
Weak drag-and-drop — Tkinter's native DnD is limited and inconsistent across platforms. Dropping a file onto the canvas was a coin flip whether it registered.

PyQt6 fixed all three. Here's the same Controls panel in both: Tkinter on the right, PySide6 (the version that came later, more on that below) on the left.

So, both projects were now using PyQt6 for the GUI layer. That migration solved the immediate problems. It also planted the seed for a different crisis entirely.

Then I read the license again.

PyQt6 → GPL v3 (copyleft)
Apache 2.0 → permissive

GPL v3 + Apache 2.0 = 💥 license conflict

GPL v3 is copyleft. That means any project that uses PyQt6 must also be GPL v3. Apache 2.0 has different distribution requirements. You can't ship both at once — they're incompatible.

My options:

Option	Trade-off
Switch to GPL v3	Lose permissive licensing flexibility
Dual license	Complicates contribution model
Migrate to PySide6	LGPL v3 — compatible with Apache 2.0 ✅

PySide6 is the official Qt binding maintained by The Qt Company itself. LGPL v3 means closed-source and commercial use is fine as long as you dynamically link. For a desktop app, that's basically free.

The API difference turned out to be mostly naming:

# PyQt6
from PyQt6.QtCore import pyqtSignal, pyqtSlot
my_signal = pyqtSignal(str)

# PySide6
from PySide6.QtCore import Signal, Slot
my_signal = Signal(str)

The bigger gotcha is strict enums. PyQt6 enforces them everywhere. PySide6 is more lenient — which means some PyQt6 code actually runs stricter than PySide6, so migrating in that direction has fewer surprises than going the other way.

Two projects, about two hours each. Migration done.

The Wayland Window Snap Problem

Once I was on PySide6, I ran into the window management issue I'd been avoiding: snap doesn't work properly on Wayland.

Chromium snaps fine. My Qt app doesn't. Here's why that's not a fair comparison — Chromium uses its own window management layer entirely. Qt apps on Wayland communicate through the compositor protocol, and there are three separate issues hiding inside "snap is broken":

Problem 1: `setMaximumWidth` on the sidebar kills snap layouts

When the window is snapped to half-screen (~700px), the sidebar demands 350px and leaves the canvas only 330px. The fix is giving it a smaller ceiling:

# Before
self.scroll_area.setMinimumWidth(350)
self.scroll_area.setMaximumWidth(450)  # too rigid

# After
self.scroll_area.setMinimumWidth(260)
self.scroll_area.setMaximumWidth(400)

Problem 2: Canvas resize fires hundreds of times during snap animation

ImageCanvas.resizeEvent calls display_image() on every frame of the snap animation, causing visible flicker. The fix is a debounce timer:

# In __init__
self._resize_timer = QTimer()
self._resize_timer.setSingleShot(True)
self._resize_timer.timeout.connect(self._do_canvas_resize)

def on_canvas_resize(self):
    self._resize_timer.start(60)  # 60ms debounce

def _do_canvas_resize(self):
    if self.processed_image is not None:
        self.display_image(self.processed_image)
    elif self.original_image is not None:
        self.display_image(self.original_image)
    else:
        self.canvas.update()

Problem 3: `restore_window_state` on Wayland

Window geometry on Wayland isn't available until after the window is actually shown. Calling resize() and move() in __init__ does nothing reliable. The fix is to delay restoration:

def showEvent(self, event):
    super().showEvent(event)
    if not hasattr(self, '_state_restored'):
        self._state_restored = True
        self.restore_window_state()
        self.restore_user_settings()

Also save and restore the splitter state across sessions:

# on close
self.db_manager.save_setting(
    'splitter_state',
    self.splitter.saveState().toHex().data().decode(),
    'window'
)

# on restore
splitter_bytes = self.db_manager.get_setting('splitter_state')
if splitter_bytes:
    from PySide6.QtCore import QByteArray
    self.splitter.restoreState(QByteArray.fromHex(splitter_bytes.encode()))

Note: The KDE/GNOME snap grid that appears when hovering the maximize button is a compositor feature, not something Qt apps can opt into. Meta + arrow key is your friend here.

Replacing the Native File Dialog

The file picker looked like this:

GTK. White. On a dark cyberpunk app. No.

The typical fix is QFileDialog.Option.DontUseNativeDialog — but that gives you the Qt default dialog, which also ignores your stylesheet. I wanted something that actually fits.

So I built one from scratch.

The design

┌─ 📷 Select Image ─────────────── [🔍 Filter] [✕] ─┐
├───────────────────────────────────────────────────────┤
│ QUICK ACCESS  │ Home › Pictures          │  Preview  │
│               │ ┌────┐ ┌────┐ ┌────┐    │  [image]  │
│ 🏠 Home       │ │img │ │img │ │img │    │           │
│ 🖼️ Pictures   │ └────┘ └────┘ └────┘    │  file.jpg │
│ ⬇️ Downloads  │ ┌────┐ ┌────┐           │  1920×1080│
│ 🖥️ Desktop    │ │📁  │ │img │           │  2.3 MB   │
│               │ └────┘ └────┘           │           │
├───────────────────────────────────────────────────────┤
│ /home/kareem/Pictures          [Cancel]    [ Open ]  │
└───────────────────────────────────────────────────────┘

Three animations:

Dialog opens with a fade-in
File tiles appear with a staggered cascade (each 18ms apart)
Preview panel slides in from the right when you select an image

The Wayland painter trap

My first implementation used QGraphicsOpacityEffect for the tile animations. On Linux, the terminal filled up with this:

QPainter::begin: A paint device can only be painted by one painter at a time.
QWidgetEffectSourcePrivate::pixmap: Painter not active
QPainter::save: Painter not active
...

Hundreds of lines. The dialog still opened, but something was clearly wrong.

Here's what happens: when you put a QGraphicsOpacityEffect on a widget that has a custom paintEvent, Qt's effect pipeline tries to grab the widget's pixels using an internal painter — while your paintEvent is already holding a painter on the same device. On Wayland, this conflict is loud.

The fix: don't use QGraphicsOpacityEffect on widgets with custom paint. Instead, expose opacity as a Property and apply it directly inside the painter:

class FileTile(QWidget):
    # ── opacity as animatable property ─────────────────────────
    def _get_tile_opacity(self): return self._tile_opacity
    def _set_tile_opacity(self, v):
        self._tile_opacity = max(0.0, min(1.0, v))
        self.update()
    tile_opacity = Property(float, _get_tile_opacity, _set_tile_opacity)

    def paintEvent(self, _):
        p = QPainter(self)
        p.setRenderHint(QPainter.RenderHint.Antialiasing)
        # Single painter, opacity baked in — no effect pipeline
        p.setOpacity(self._tile_opacity)
        # ... rest of paint

And in the grid loader, staggered reveal without effects:

for i, tile in enumerate(self._tiles):
    tile._tile_opacity = 0.0
    def _fade(t=tile):
        a = QPropertyAnimation(t, b'tile_opacity', t)
        a.setDuration(200)
        a.setStartValue(0.0)
        a.setEndValue(1.0)
        a.setEasingCurve(QEasingCurve.Type.OutCubic)
        a.start()
        t._reveal_anim = a  # keep ref — GC would kill it otherwise
    QTimer.singleShot(min(i * 18, 300), _fade)

The t._reveal_anim = a line is important. If you don't keep a reference to the QPropertyAnimation, Python's garbage collector kills it mid-animation and the tile stays frozen at whatever opacity it reached.

The dialog open animation on Wayland

QGraphicsOpacityEffect on the container had the same painter conflict. The solution is setWindowOpacity() — compositor-level, no painter involved:

# But first, check if the platform supports it
import os
_is_wayland = (
    os.environ.get('WAYLAND_DISPLAY') is not None or
    QApplication.platformName() == 'wayland'
)

if not _is_wayland:
    self.setWindowOpacity(0.0)
    anim = QPropertyAnimation(self, b'windowOpacity', self)
    anim.setDuration(220)
    anim.setStartValue(0.0)
    anim.setEndValue(1.0)
    anim.setEasingCurve(QEasingCurve.Type.OutCubic)
    anim.start()

Wayland compositors spam This plugin does not support setting window opacity to the terminal otherwise. The dialog appears instantly on Wayland — acceptable behavior.

The `QScrollArea` double-delete crash

First run:

RuntimeError: libshiboken: Internal C++ object (QWidget) already deleted.

In _load_grid() I was doing:

old = self.grid_widget
self.grid_widget = QWidget()
self.scroll.setWidget(self.grid_widget)
old.deleteLater()  # 💥 Qt already deleted it

From Qt docs: "The widget becomes a child of the scroll area, and will be **destroyed* when a new widget is set."*

setWidget() already deletes the old widget. Calling deleteLater() on an already-deleted C++ object is a crash. The fix: remove those two lines entirely.

Cross-platform bookmarks

The original sidebar was hardcoded for Linux:

BOOKMARKS = [
    ('🏠', 'Home',      str(Path.home())),
    ('🖼️', 'Pictures',  str(Path.home() / 'Pictures')),
    ('⬇️', 'Downloads', str(Path.home() / 'Downloads')),
    ('🖥️', 'Desktop',   str(Path.home() / 'Desktop')),
    ('📂', 'Root',      '/'),  # doesn't exist on Windows
]

On a French Linux system, ~/Desktop might be ~/Bureau. On Windows, C:\Users\kareem\Pictures might be somewhere else entirely. The fix uses XDG on Linux and platform-specific approaches elsewhere:

def _read_xdg_user_dirs() -> dict:
    """Parse ~/.config/user-dirs.dirs — handles localized folder names."""
    result = {}
    config = Path.home() / '.config' / 'user-dirs.dirs'
    if not config.exists():
        return result
    try:
        with open(config) as f:
            for line in f:
                line = line.strip()
                if line.startswith('#') or '=' not in line:
                    continue
                key, _, val = line.partition('=')
                key = key.replace('XDG_', '').replace('_DIR', '')
                val = val.strip().strip('"').replace('$HOME', str(Path.home()))
                if val:
                    result[key] = val
    except Exception:
        pass
    return result


def get_bookmarks() -> list[tuple[str, str, str]]:
    home  = Path.home()
    marks = [('🏠', 'Home', str(home))]

    if sys.platform == 'win32':
        # Windows drives + user folders
        import string
        candidates = [
            ('🖼️', 'Pictures',  os.environ.get('USERPROFILE', str(home)) + '\\Pictures'),
            ('⬇️', 'Downloads', str(home / 'Downloads')),
            ('🖥️', 'Desktop',   str(home / 'Desktop')),
            ('📄', 'Documents', os.environ.get('DOCUMENTS', str(home / 'Documents'))),
        ]
        for icon, label, path in candidates:
            if os.path.exists(path):
                marks.append((icon, label, path))
        for letter in string.ascii_uppercase:
            drive = f'{letter}:\\'
            if os.path.exists(drive):
                marks.append(('💾', f'{letter}:', drive))

    elif sys.platform == 'darwin':
        candidates = [
            ('🖼️', 'Pictures',  home / 'Pictures'),
            ('⬇️', 'Downloads', home / 'Downloads'),
            ('🖥️', 'Desktop',   home / 'Desktop'),
            ('📂', 'Volumes',   Path('/Volumes')),
        ]
        for icon, label, path in candidates:
            if Path(path).exists():
                marks.append((icon, label, str(path)))

    else:
        # Linux — XDG first, fallback to English names
        xdg = _read_xdg_user_dirs()
        candidates = [
            ('🖼️', 'Pictures',  xdg.get('PICTURES',  str(home / 'Pictures'))),
            ('⬇️', 'Downloads', xdg.get('DOWNLOAD',  str(home / 'Downloads'))),
            ('🖥️', 'Desktop',   xdg.get('DESKTOP',   str(home / 'Desktop'))),
            ('📄', 'Documents', xdg.get('DOCUMENTS', str(home / 'Documents'))),
            ('🎵', 'Music',     xdg.get('MUSIC',     str(home / 'Music'))),
            ('📂', 'Root',      '/'),
        ]
        for icon, label, path in candidates:
            if os.path.exists(path):
                marks.append((icon, label, path))

    return marks

Pyrefly IDE users: The win32 and darwin branches will appear dimmed/dead on Linux because Pyrefly does platform narrowing — static analysis treats unreachable-on-current-platform code as dead. The code is correct. Add _PLATFORM = sys.platform and check against that variable to suppress it, or set platform = "all" in pyrefly.toml.

Thumbnail loading

Thumbnails load in a QThreadPool so scrolling stays smooth:

class ThumbLoader(QRunnable):
    def run(self):
        try:
            from PIL import Image
            img = Image.open(self.path)
            img.thumbnail((140, 140), Image.LANCZOS)
            img  = img.convert('RGBA')
            data = img.tobytes('raw', 'RGBA')
            qimg = QImage(data, img.width, img.height,
                          QImage.Format.Format_RGBA8888)
            qimg._pil_data = data   # keep alive until QImage is done
            self.signals.done.emit(self.path, QPixmap.fromImage(qimg))
        except Exception:
            pass

Using Pillow instead of QImage directly avoids qt.gui.imageio.jpeg: Corrupt JPEG data warnings for slightly malformed JPEGs — Pillow is more lenient and the visual difference is zero.

Multithreading in Qt: Non-Blocking Batch Processing

Adding a batch processing feature poses a major UI challenge. If you try to process 100 images sequentially on the main GUI thread, the Qt event loop locks up. The application window freezes, visual elements stop repainting, and the operating system eventually prompts the user to force-close the "Not Responding" application.

To solve this, the processing must happen asynchronously in the background. But there is a catch: Qt widgets are not thread-safe. You cannot modify GUI elements (like updating a progress bar or changing a label's text) directly from a background worker thread without triggering random segfaults.

Thread-Safe Communication via Custom Signals

The standard way to bridge this gap in PySide6 is using custom Signals. Since PySide6 signals are inherently thread-safe when using a queued connection, emitting a signal from a worker thread safely marshals the event back to the main thread's event loop.

First, we define a small QObject to hold our signals:

class BatchSignals(QObject):
    """Signals for thread-safe UI updates from the processing worker thread"""
    progress = Signal(int, int, dict)
    error = Signal(str, str)
    complete = Signal()

Inside our dialog initialization, we connect these signals to the GUI update slots:

self.signals = BatchSignals()
self.signals.progress.connect(self.on_progress)
self.signals.error.connect(self.on_error)
self.signals.complete.connect(self.on_complete)

The Worker Thread Lifecycle

When the user clicks "Start", we launch a standard Python threading.Thread as a daemon thread. We pass nested callbacks that do nothing but emit our thread-safe signals:

def start_processing(self):
    # ... read UI values and settings ...
    self.processing = True
    self.update_ui_state(processing=True)

    def process_worker():
        def progress_cb(current, total, result):
            self.signals.progress.emit(current, total, result)

        def error_cb(file_path, error_msg):
            self.signals.error.emit(file_path, error_msg)

        self.batch_processor.process_batch(
            valid_files,
            output_dir,
            settings,
            progress_callback=progress_cb,
            error_callback=error_cb,
            is_cancelled=lambda: not self.processing
        )
        self.signals.complete.emit()

    thread = threading.Thread(target=process_worker, daemon=True)
    thread.start()

Graceful Cancellation and License Gating

The is_cancelled parameter passes a lambda lambda: not self.processing down to the batch loop. Inside the processing loop, BatchProcessor checks this condition on every iteration:

for i, input_path in enumerate(input_paths):
    if is_cancelled and is_cancelled():
        break  # Exit early if the user clicked "Stop"
    # ... process image ...

Additionally, because batch processing is a resource-intensive "PRO" feature, we gate the GUI. If the license manager detects that the Max tier is not activated, the window restricts input selection:

FREE_FILE_LIMIT = 3

def _is_max(self):
    return self.license_manager.is_max_activated

# When adding files:
if not self._is_max() and len(self.selected_files) > self.FREE_FILE_LIMIT:
    QMessageBox.warning(self, "Limit Reached", "Free tier is limited to 3 files.")
    # ... slice list to limit ...

This keeps the GUI perfectly responsive, gives the user real-time feedback with zero crashes, and ties in the licensing system we built in Part 2.

What's Next: Designing AI Evasion (Adversarial Perturbation)

DotScramble can now blur, pixelate, or black out sensitive regions like faces. While that visual degradation is enough to prevent a human from recognizing the subject, it turns out it is not enough for modern AI-driven facial recognition systems.

The Threat Model: AI Face Recognition

Deep learning models extract abstract feature vectors from faces. Even if a face is heavily blurred or partially pixelated, the neural network can still reconstruct or match the underlying features with surprisingly high confidence. In my tests, a blurred face run through an open-source face recognition model still yielded a cosine similarity match of over 0.7 against the original unblurred image—well above typical detection thresholds.

To achieve true privacy in the age of scraping pipelines and surveillance, DotScramble needs a second line of defense: adversarial perturbations.

Fooling the Neural Network

Adversarial machine learning involves adding a mathematically optimized, imperceptible noise pattern to an image. To a human, the image looks virtually unchanged, but to a neural network, the features are completely scrambled, leading to an incorrect classification or a failed match:

Original image + ε \times noise = Adversarial example (gibbon/unrecognized)

The Black-Box Challenge (SPSA)

Most standard adversarial attack methods (like FGSM) are "white-box" attacks—they require full access to the target model's architecture, weights, and gradients so you can perform backpropagation.

For DotScramble, we don't know what model the end-user (or scraper) will use. We need a black-box attack. To solve this, we can design an estimation engine using Simultaneous Perturbation Stochastic Approximation (SPSA). SPSA approximates gradients by evaluating the loss function at just two perturbed points per iteration, regardless of parameter count:

g^(θ) \approx \frac{L ( θ + c Δ ) - L ( θ - c Δ )}{2 c} \times Δ^{- 1}

This allows us to optimize adversarial perturbations on the fly using a local proxy model, ensuring the face remains unrecognizable to AI systems.

Bugs I Hit and What They Actually Were

Error	Looked Like	Actually Was
`RuntimeError: Internal C++ object already deleted`	Memory bug	`deleteLater()` on widget Qt already deleted via `setWidget()`
`QPainter: A paint device can only be painted by one painter at a time`	Concurrent threads	`QGraphicsOpacityEffect` + custom `paintEvent` on same widget
`This plugin does not support setting window opacity`	Qt bug	`setWindowOpacity()` not supported on Wayland compositor
`Corrupt JPEG data: 1 extraneous bytes before marker 0xd9`	Broken images	Cameras that write slightly nonstandard JPEG — images load fine
Sidebar items dimmed in IDE	Code wrong	Pyrefly platform-narrowing dead code detection

Key Takeaways

On Wayland: Don't use QGraphicsOpacityEffect on widgets with custom paintEvent. The effect pipeline creates a painter conflict. Use p.setOpacity() inside your custom paint instead.

On Qt object lifetime: QScrollArea::setWidget() destroys the previous widget. Don't call deleteLater() on it afterward. Same pattern appears in QStackedWidget, QDockWidget, and others.

On file dialogs: The native file dialog on Linux is GTK and ignores your stylesheet. Building a custom one is maybe 400 lines and gives you full control over layout, animations, and behavior — worth it for a premium feel.

On Qt multithreading: Never update GUI elements directly from a background thread; it leads to memory corruption and instant crashes. Use QObject with Signals to safely bridge communication from the worker thread to the main GUI thread.

On adversarial perturbations: Blurring or pixelating a face might fool a human, but modern neural networks can still recognize it. Adversarial noise slightly alters pixels to break the model's feature extraction while keeping the image recognizable to humans.

On black-box optimization: When you don't have access to model weights or gradients, black-box optimization algorithms like SPSA (Simultaneous Perturbation Stochastic Approximation) let you estimate gradients efficiently with just a few forward passes.

DotScramble is part of DotSuite — a collection of developer privacy tools. Part 4 covers the AI Evasion system — why blurring alone isn't enough against modern face recognition, and how SPSA black-box adversarial perturbations add a second layer of protection that works without access to any model weights.

GitHub (v1.4.1) · OpenDesktop · Ko-fi · Buy Me a Coffee

Building DotScramble Part 2: Ed25519 License Signing, Machine Fingerprinting, and a 7-Day Offline Grace Period

freerave — Sat, 27 Jun 2026 14:27:48 +0000

How DotScramble protects its Pro tier using asymmetric cryptography — public key verification, a weighted hardware fingerprint, server-side activation limits, and a background recheck thread.

Series recap: DotScramble is a desktop privacy tool that blurs, pixelates, and redacts sensitive regions in images. Part 1 covered the core image processing pipeline and metadata spoofing. This post covers the licensing system — specifically, how I built something that actually works without being trivially crackable.

The Threat Model

Before writing a single line of licensing code, I had to define what I'm actually protecting against.

Attack	Realistic?	What I'm defending against
Copy/paste the `.py` file to another machine	Very likely	Machine fingerprinting
Share one key across unlimited machines	Likely	Server-side activation limits
Modify `is_max_activated = True` in source	Trivial in Python	Cython binary compilation
Forge a license token offline	Requires private key	Ed25519 asymmetric signing
Use the app without internet forever	Easy	7-day offline grace period + background recheck
Roll back the system clock to extend a token	Clever	Clock rollback detection

The goal wasn't to make DotScramble uncrackable — determined attackers can always get around software licensing. The goal was to make it not worth the effort for casual use, while keeping it completely frictionless for legitimate users.

The Token Format

Every activated machine gets a signed license token — a compact, self-contained credential that the app can verify locally without any network call.

The format is two Base64URL segments joined by a dot:

<base64url(JSON payload)>.<base64url(Ed25519 signature)>

The payload looks like this:

{
  "mid": "a3f1b2c9d4e5f6a7b8c9d0e1f2a3b4c5",
  "name": "FreeRave",
  "plan": "max",
  "exp": 1782000000
}

mid — the machine ID (more on this below)
name — shown in the welcome message on activation
plan — "max" for Pro tier
exp — Unix timestamp when the token expires

The server signs this payload with its Ed25519 private key and sends the complete token to the client. The client verifies it using a hardcoded public key — which can only verify, never forge.

Why Ed25519 Over HMAC?

The classic alternative is HMAC-SHA256: generate a secret key, share it with the client, use it to sign tokens. The problem is obvious — if the key is in the client binary, it can be extracted and used to generate unlimited fake tokens offline.

Ed25519 solves this by design:

Private key  →  only on the server  →  signs tokens
Public key   →  hardcoded in the app  →  verifies tokens, cannot forge

Forging a valid signature without the private key requires breaking Ed25519 — computationally infeasible. The worst a reverse engineer can do with the public key is verify tokens, which is the same thing the app does.

The public key in license_manager.py:

_ED25519_PUBLIC_KEY_B64 = "DQ0zJAi1S0c+NUhOP3050au9k5/fYwLU45ayTZIFVuI="

32 bytes. That's the entire security boundary between the app and unlimited offline activation.

The Verification Function

The full verification runs locally on every startup and every activation:

def _verify_token(self, token: str) -> Tuple[bool, dict]:
    try:
        from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
        parts = token.split(".")
        if len(parts) != 2:
            return False, {}
        payload_b64, sig_b64 = parts

        # Safe dynamic padding — prevents decoder crashes on tokens
        # with non-multiple-of-4 base64 lengths
        def _b64dec(s: str) -> bytes:
            return base64.urlsafe_b64decode(s + '=' * (-len(s) % 4))

        payload_bytes = _b64dec(payload_b64)
        sig_bytes     = _b64dec(sig_b64)

        pub_raw    = base64.b64decode(_ED25519_PUBLIC_KEY_B64)
        public_key = Ed25519PublicKey.from_public_bytes(pub_raw)
        public_key.verify(sig_bytes, payload_bytes)    # raises on invalid sig

        payload = json.loads(payload_bytes.decode())

        # Check expiry
        if payload.get("exp", 0) < time.time():
            return False, {}

        # Check machine binding
        if payload.get("mid", "") != self.generate_machine_id():
            return False, {}

        return True, payload
    except Exception:
        return False, {}

Three checks, in order:

Signature valid — Ed25519PublicKey.verify() raises an exception on any tampered payload
Not expired — server controls token lifetime via exp
Machine matches — the mid in the token must equal this machine's fingerprint

All three must pass. Fail any one, the token is rejected and the local activation is cleared.

The _b64dec padding trick: Standard Base64 requires padding to a multiple of 4 characters. URL-safe Base64 (used in JWTs and similar) often strips it. The expression '=' * (-len(s) % 4) adds exactly the right number of = characters — 0 if already padded, 1, 2, or 3 otherwise. It's a modular arithmetic trick that avoids an if/else chain.

Machine Fingerprinting

The machine ID is a 32-character hex string derived from hardware factors. It needs to be:

Stable — survive reboots, VPN changes, hostname changes
Unique enough — distinguish different machines
Cross-platform — work on Linux, Windows, macOS

@staticmethod
def generate_machine_id() -> str:
    factors: dict[str, str] = {}

    # Platform-specific hardware ID — the most stable identifier
    try:
        if platform.system() == "Linux":
            mid_path = "/etc/machine-id"
            if os.path.isfile(mid_path):
                with open(mid_path) as f:
                    factors["mid"] = f.read().strip()

        elif platform.system() == "Windows":
            import winreg
            key = winreg.OpenKey(
                winreg.HKEY_LOCAL_MACHINE,
                r"SOFTWARE\Microsoft\Cryptography"
            )
            factors["mid"] = winreg.QueryValueEx(key, "MachineGuid")[0]

        elif platform.system() == "Darwin":
            import subprocess
            out = subprocess.check_output(
                ["ioreg", "-rd1", "-c", "IOPlatformExpertDevice"],
                stderr=subprocess.DEVNULL
            )
            for line in out.decode().splitlines():
                if "IOPlatformUUID" in line:
                    factors["mid"] = line.split('"')[-2]
                    break
    except:
        pass

    # Secondary factors — used if primary is unavailable
    try:
        factors["cpu"] = str(os.cpu_count() or 0)
    except:
        pass

    factors["os"] = platform.system()

    # MAC address — only if it's real hardware, not randomized
    try:
        mac_int = _uuid.getnode()
        if not (mac_int >> 40) & 1:   # bit 40 = 1 means locally administered (randomized)
            factors["mac"] = hex(mac_int)[2:].upper().zfill(12)
    except:
        pass

    # Sort keys for determinism, hash the concatenation
    factor_str = "|".join(f"{k}:{v}" for k, v in sorted(factors.items()))
    return hashlib.sha256(factor_str.encode()).hexdigest()[:32]

The key design choices:

/etc/machine-id on Linux is written once during OS installation by systemd. It survives everything short of a full OS reinstall. It's the most stable machine identifier available on Linux.

MachineGuid on Windows is equivalent — written during OS installation, stored in the registry under HKLM\SOFTWARE\Microsoft\Cryptography.

The MAC address randomization check: Modern Linux kernels and privacy-focused configurations use MAC address randomization. Bit 40 of the MAC address is the "locally administered" bit — if it's set, the MAC was generated randomly and changes on every boot. Including a random MAC in the fingerprint would break activation after every reboot. The check (mac_int >> 40) & 1 skips it when it's randomized.

sorted(factors.items()) — dict ordering in Python 3.7+ is insertion-ordered, but explicitly sorting by key makes the fingerprint deterministic regardless of which factors are available. If /etc/machine-id is missing (e.g., in a container), the hash still produces the same result each run as long as the same secondary factors are present.

The final hash is truncated to 32 hex characters — 128 bits of machine identity, which is more than enough to distinguish machines while keeping the payload compact.

The Activation Flow

User clicks "Activate Pro"
        │
        ▼
LocalAuthManager starts an ephemeral HTTP server on 127.0.0.1:0
(port 0 = OS assigns a free port atomically — no TOCTOU race)
        │
        ▼
Browser opens: https://dotsuite.vercel.app/en/dashboard/dotscramble/auth?port=PORT&state=STATE_TOKEN
        │
        ▼
User logs in and clicks "Activate"
        │
        ▼
Web dashboard POSTs { key, state } to http://127.0.0.1:PORT/callback
        │
        ▼
AuthHandler verifies state token (CSRF protection)
        │
        ▼
LicenseManager.verify_and_activate(key) called
        │
        ▼
Server receives: POST /v1/license/activate
  Authorization: Bearer <api_key>
  Body: { "machine_id": "a3f1b2..." }
        │
        ▼
Server signs token, returns { "license_token": "...", "name": "FreeRave" }
        │
        ▼
Client verifies token locally (_verify_token)
        │
        ▼
Token + API key saved to SQLite
Background recheck thread started

The local HTTP server is a security boundary. The web dashboard can't directly call Python functions — it goes through an HTTP POST, which lets us:

Validate the CSRF state token (prevents any other page from activating on behalf of the user)
Cap the payload size at 4096 bytes (prevents local OOM DoS)
Use secrets.compare_digest() for the state token comparison (constant-time, prevents timing attacks)

def verify_state(self, state):
    if not state or not self.state_token:
        return False
    return secrets.compare_digest(state, self.state_token)

secrets.compare_digest() is not paranoia here — the state token arrives over localhost HTTP, and comparing strings with == leaks timing information about how many characters match before the first mismatch. For a 32-character random token, this isn't a practical attack, but it's the correct primitive and costs nothing.

Storing the Token

Once verified, three values are written to SQLite:

self.db_manager.save_setting("dotsuite_api_key", api_key, "license")
self.db_manager.save_setting("license_token",    token,   "license")
self.db_manager.save_setting("is_max_activated", True,    "license")
self.db_manager.save_setting("last_license_check_time", time.time(), "license")

The database uses INSERT OR REPLACE (upsert) with a setting_type column so license settings can be queried or cleared as a group.

On the next startup, the manager reads the cached token and re-verifies it locally — no network required:

if self._license_token:
    last_verified = float(self.db_manager.get_setting("last_license_check_time", 0.0))
    current_time  = time.time()

    # Clock rollback detection
    if current_time < last_verified:
        self.logger.error("System clock rollback detected on startup!")
        self._clear_local()
    else:
        valid, _ = self._verify_token(self._license_token)
        if valid:
            self._is_max = True
            self.db_manager.save_setting("last_license_check_time", current_time, "license")
            self._schedule_background_recheck()
        else:
            self._clear_local()

The clock rollback check is subtle. If a user sets their system clock back before the token expiry date, local verification would still pass (the token isn't expired from the perspective of the past timestamp). Storing last_license_check_time and comparing against time.time() catches this — if the current time is before the last check time, something is wrong.

The Background Recheck Thread

Local verification is fast and works offline, but it can't detect revoked keys. A key that was refunded, chargebacked, or explicitly revoked would still pass local verification until its token expires.

The solution: a daemon thread that re-checks with the server every 24 hours.

def _schedule_background_recheck(self):
    self.stop_recheck_event.clear()
    t = threading.Thread(
        target=self._recheck_loop,
        daemon=True,
        name="license-recheck"
    )
    t.start()

def _recheck_loop(self):
    while not self.stop_recheck_event.is_set():
        # Wait 24 hours, or until stopped
        is_stopped = self.stop_recheck_event.wait(_RECHECK_HOURS * 3600)
        if is_stopped or self.stop_recheck_event.is_set():
            break
        self._silent_recheck()

Using Event.wait(timeout) instead of time.sleep() means the thread can be cleanly interrupted on deactivation or app close — stop_recheck_event.set() wakes it immediately.

The recheck itself is silent:

def _silent_recheck(self):
    with self.lock:
        if not self._is_max:
            return
        current_key = self._api_key
    try:
        machine_id    = self.generate_machine_id()
        payload_bytes = json.dumps({"machine_id": machine_id}).encode()
        req = urllib.request.Request(
            _RECHECK_URL, data=payload_bytes,
            headers={
                "Authorization": f"Bearer {current_key}",
                "Content-Type": "application/json"
            }
        )
        with urllib.request.urlopen(req, timeout=10) as resp:
            data      = json.loads(resp.read().decode())
            new_token = data.get("license_token", "")

        valid, _ = self._verify_token(new_token)
        if valid:
            # Refresh the cached token
            with self.lock:
                self._license_token = new_token
            self.db_manager.save_setting("license_token", new_token, "license")
            self.db_manager.save_setting("last_license_check_time", time.time(), "license")
        else:
            self._clear_local()   # Token failed — deactivate silently

    except urllib.error.HTTPError as e:
        if e.code in (401, 403, 404):
            self._clear_local()   # Key revoked — deactivate silently
        # Other errors (500, network timeout) — do nothing, try again next cycle

    except:
        pass   # Offline — grace period continues

The error handling is intentional:

401/403/404 — the server explicitly rejected the key (revoked, deleted, or not found). Deactivate immediately.
5xx / timeout / no network — server might be temporarily down. Don't deactivate. The user has 7 days of offline grace before the token expires.
Any other exception — same as above, fail open.

This gives legitimate users a 7-day offline window while still detecting revoked keys as soon as connectivity is restored.

The `is_max_activated` Property

Every feature gate in the UI calls this single property:

@property
def is_max_activated(self) -> bool:
    # Extremely fast in-memory query
    # prevents frame drops in preview sliders
    with self.lock:
        return self._is_max

This is intentionally the simplest possible thing. No token re-verification, no database reads, no disk I/O — just a boolean behind a mutex. The reasoning: this property is called on every frame of the real-time preview slider. Token re-verification takes 0.5–2ms (cryptographic operation). At 60fps, that's up to 120ms/second of crypto overhead — enough to cause visible stuttering.

The heavy verification happens once on startup and once per recheck cycle, then the result is cached in memory.

Where it's used in main_window.py:

# Feature gating at detection mode switch
def on_detection_change(self):
    mode = self.detection_mode.get()
    pro_only_modes = ['target_text', 'text', 'body', 'license_plate']

    if mode in pro_only_modes and not self.license_manager.is_max_activated:
        QMessageBox.information(
            self,
            "Pro Feature",
            f"The '{mode_display}' detection mode is a Pro feature.\n\n"
            f"Upgrade to DotScramble Pro for advanced AI models."
        )
        self.detection_mode.set("face")   # Reset to free tier

# Feature gating at save time
is_max     = self.license_manager.is_max_activated
should_scrub = is_max and self.scrub_exif.get()
should_spoof = is_max and self.spoof_metadata.get() and not should_scrub

Protecting the Source with Cython

Python source is trivially readable. is_max_activated can be patched in two keystrokes:

# Original
return self._is_max

# Cracked version
return True

The defense: compile license_manager.py to a native .so extension using Cython. The setup_license.py script does this:

from setuptools import setup, Extension
from Cython.Build import cythonize

extensions = [
    Extension(
        "src.managers.license_manager",
        sources=["src/managers/license_manager.py"],
        extra_compile_args=["-O2"],  # Strip debug symbols
    )
]

setup(
    name="dotscramble_license",
    ext_modules=cythonize(
        extensions,
        compiler_directives={
            "embedsignature": False,   # No readable function signatures
            "emit_code_comments": False,  # No source hints in the binary
            "language_level": "3",
            "boundscheck": False,
            "wraparound": True,
        },
    ),
    zip_safe=False,
)

Build command:

python setup_license.py build_ext --inplace
# → src/managers/license_manager.cpython-313-x86_64-linux-gnu.so

After building, the .py source is removed from the distribution. The app imports from the .so exactly the same way — Python's import system finds the compiled extension automatically.

The resulting binary is a real shared library. Patching it requires disassembling machine code and finding the return instruction — orders of magnitude harder than editing a .py file. Not impossible, but the effort-to-reward ratio is high enough that most people will just buy a license.

Note: The compiled .so is platform-specific — cpython-313-x86_64-linux-gnu.so only runs on Linux x86_64 with CPython 3.13. Targeting Windows and macOS requires separate build steps on each platform, which is a solved problem for any CI pipeline.

The Full Lifecycle

First run (no license)
├── _is_max = False
├── Free tier features available
└── "Activate Pro" triggers browser flow

Activation
├── LocalAuthManager starts ephemeral HTTP server
├── Browser → dotsuite.vercel.app/auth → user logs in
├── Dashboard POSTs { key, state } to 127.0.0.1:PORT/callback
├── CSRF state verified (secrets.compare_digest)
├── verify_and_activate(key) sends machine_id to API server
├── Server signs token with Ed25519 private key
├── Client verifies token locally (signature + expiry + machine)
├── Token cached in SQLite
└── Background recheck thread started

Every startup (with cached token)
├── Clock rollback check
├── Local token verification (signature + expiry + machine)
├── _is_max = True if valid
└── Recheck thread started

Every 24 hours (background thread)
├── POST machine_id to /v1/license/recheck
├── Server returns fresh token (extends expiry)
├── Local verification of new token
├── Cache updated
└── On HTTP 401/403/404 → _clear_local() → instant deactivation

Deactivation
├── stop_recheck_event.set() → thread wakes and exits
├── DELETE /v1/license/deactivate (frees the activation slot)
└── _clear_local() → all local state wiped

What Doesn't Work (By Design)

I explicitly chose not to implement:

Online-only mode — requiring a network connection on every launch would be a poor user experience. Planes, trains, conferences with bad WiFi, corporate proxies. The 7-day grace period handles all of these.

Hardware lock to MAC address only — MAC addresses are trivially spoofed. Using /etc/machine-id and MachineGuid as the primary identifier is more robust.

Obfuscating the public key — pointless. The public key is designed to be public. Hiding it in a string scrambler doesn't add security — it just makes the code messier.

Aggressive telemetry — the only data sent to the server is the machine ID and the API key. No usage statistics, no file names, no behavioral data. DotScramble is a privacy tool — phoning home with analytics would be self-contradictory.

Key Takeaways

On Ed25519 vs HMAC: Use asymmetric signing whenever the verifier (client) is untrusted. If the client holds a shared secret, it can forge. If it only holds a public key, it can only verify.

On machine fingerprinting: Prefer OS-level identifiers (/etc/machine-id, MachineGuid) over network-layer identifiers (MAC, IP). The latter change too often to be reliable anchors.

On background threads: Event.wait(timeout) is better than time.sleep() for long-polling threads. It wakes immediately on event.set(), so shutdown is clean and instantaneous.

On feature gates: Keep the hot path — the boolean check called per-frame — as fast as possible. Cache everything. Do the expensive work (crypto, network) once in background.

On source protection: Cython is not DRM. It raises the bar significantly against casual tampering, but a determined reverse engineer can still disassemble the .so. The actual security comes from the Ed25519 signature — you can read every byte of the binary and still can't forge a valid token.

Part 3 covers what happened when I tried to make the UI actually good — a PyQt6 → PySide6 migration forced by a GPL license conflict, three separate Wayland window management bugs, building a custom animated file picker, and implementing non-blocking batch processing.

GitHub · OpenDesktop · Ko-fi · Buy Me a Coffee

Inside DotScramble: Metadata Spoofing, Custom EXIF Control, and Advanced Face/Eye Blur

freerave — Tue, 23 Jun 2026 13:32:46 +0000

A deep dive into how DotScramble protects your privacy — from injecting plausible-but-fake EXIF metadata to detecting and blurring faces and eyes with OpenCV Haar Cascades.

TL;DR — DotScramble is an open-source desktop app that protects image privacy through two main pillars: metadata obfuscation (stripping or spoofing EXIF data so your camera, GPS, and timestamp can't be traced back to you) and visual redaction (automatically detecting and blurring faces, eyes, license plates, and text). This post digs into the code behind both systems.

Why Metadata Is the Hidden Threat

When you take a photo, the file doesn't just contain pixels. Hidden inside is a block of EXIF metadata that silently stores:

Field	Example Value	Risk
`GPS Latitude/Longitude`	`30.0444° N, 31.2357° E`	Reveals your exact location
`Camera Make/Model`	`Apple iPhone 15 Pro`	Fingerprints your device
`DateTimeOriginal`	`2026:06:21 14:32:11`	Timestamps your movements
`Software`	`iOS 17.5`	Exposes OS/platform

Most people strip this metadata before sharing photos — but stripping alone can look suspicious. A completely blank EXIF block on a modern smartphone image is a red flag to any tracking algorithm. DotScramble takes a different approach: instead of silent stripping, it injects plausible-but-fake disinformation.

Part 1: The Metadata Spoofing Engine

The core of the system lives in core/metadata_spoofer.py.

The Camera Database — Intentionally Vintage

FAKE_CAMERAS: list[tuple[str, str, str]] = [
    ("Nokia",     "3310",              "Nokia Imaging 1.0"),
    ("Motorola",  "RAZR V3",           "Motorola Camera 1.2"),
    ("Samsung",   "SCH-U340",          "Samsung Digimax 2.1"),
    ("Casio",     "QV-10A",            "Casio Digital Camera"),
    ("Polaroid",  "PDC 640",           "Polaroid Software 1.1"),
    ("Kodak",     "DC40",              "Kodak EasyShare 3.0"),
    # ... and more
]

The list is intentionally filled with vintage and implausible devices — a Nokia 3310 doesn't have a camera at all, which is exactly the point. Trackers fingerprint devices by cross-referencing camera model with image resolution, color profile, and noise patterns. Injecting a Nokia 3310 signature into a modern 12MP photo creates an irreconcilable contradiction that defeats fingerprinting.

GPS Presets — Middle of Nowhere

GPS_PRESETS: dict[str, tuple[float, float]] = {
    "pacific":    (   4.2234,  -157.4521),  # Middle of Pacific Ocean
    "antarctica": ( -89.3312,    12.0000),  # Antarctica
    "arctic":     (  89.1122,  -178.4343),  # Arctic Ocean
    "sahara":     (  23.4122,    10.9988),  # Remote Sahara (no cell towers)
    "amazon":     (  -5.3421,   -63.2231),  # Deep Amazon basin
}

These aren't random — each preset was chosen because it's a location with no plausible human population or cell infrastructure, making it impossible to cross-reference the fake GPS against telecom tower data.

A small jitter is added to each preset on every run so the same preset never produces the exact same coordinates twice:

def _pick_gps(preset, custom, jitter=True):
    coords = GPS_PRESETS.get(preset, GPS_PRESETS["pacific"])
    if jitter:
        lat = coords[0] + random.uniform(-0.08, 0.08)
        lon = coords[1] + random.uniform(-0.08, 0.08)
        return (round(lat, 4), round(lon, 4))
    return coords

Converting GPS to EXIF Rationals

EXIF GPS doesn't store decimal degrees directly — it uses a DMS (Degrees, Minutes, Seconds) format with rational numbers (numerator/denominator pairs). Here's how DotScramble handles the conversion:

def _dms_rational(value: float) -> tuple[tuple[int, int], ...]:
    """Convert decimal degrees → (deg, min, sec) as EXIF rational tuples."""
    abs_v = abs(value)
    deg   = int(abs_v)
    m_f   = (abs_v - deg) * 60
    mins  = int(m_f)
    secs  = round((m_f - mins) * 60 * 10_000)
    return ((deg, 1), (mins, 1), (secs, 10_000))

The result gets packaged into a full GPS IFD:

def _build_gps_ifd(lat: float, lon: float) -> dict:
    return {
        piexif.GPSIFD.GPSLatitudeRef:  b"S" if lat < 0 else b"N",
        piexif.GPSIFD.GPSLatitude:     _dms_rational(lat),
        piexif.GPSIFD.GPSLongitudeRef: b"W" if lon < 0 else b"E",
        piexif.GPSIFD.GPSLongitude:    _dms_rational(lon),
        piexif.GPSIFD.GPSAltitude:     (0, 1),
        piexif.GPSIFD.GPSMapDatum:     b"WGS-84",
    }

Spoof Profiles — Opinionated Presets

Rather than exposing raw settings, DotScramble exposes three high-level profiles:

PROFILES = {
    "ghost": {
        # Maximum obfuscation — Nokia 3310 in Antarctica, year 2000
        "gps_preset":         "antarctica",
        "camera":             "Nokia 3310",
        "fake_datetime_mode": "epoch",
        "keep_copyright":     False,
    },
    "troll": {
        # Plausibly wrong — recent vintage camera, random ocean
        "gps_preset":         "pacific",
        "camera":             "random",
        "fake_datetime_mode": "recent",
        "keep_copyright":     False,
    },
    "artist": {
        # For photographers — strips location+device, preserves copyright
        "gps_preset":         "atlantic",
        "camera":             "random",
        "fake_datetime_mode": "random",
        "keep_copyright":     True,
    },
}

Usage is dead simple from Python:

from core.metadata_spoofer import spoof

result = spoof("photo.jpg", profile="ghost")
print(result)
# {
#   "format": "JPEG",
#   "camera": "Nokia 3310",
#   "gps": {"lat": -89.2891, "lon": 12.0412},
#   "datetime": "2000:01:01 00:00:00",
#   ...
# }

Or from the CLI:

dotscramble-spoof photo.jpg --profile ghost
dotscramble-spoof photo.jpg --gps-preset pacific --camera "Kodak DC40"
dotscramble-spoof photo.jpg --gps-custom 23.4 -54.2 --keep-copyright
dotscramble-spoof photo.jpg --dry-run --json

JPEG vs PNG — Different Metadata Formats

JPEG and PNG handle metadata completely differently:

JPEG uses binary EXIF chunks (IFD tables). DotScramble builds these using piexif:

exif_bytes = piexif.dump({
    "0th":  zeroth_ifd,   # Camera make, model, software, datetime
    "Exif": exif_ifd,     # DateTimeOriginal, ISO, aperture, shutter
    "GPS":  gps_ifd,      # Lat/lon in DMS rational format
})
img.save(output_path, "JPEG", exif=exif_bytes, quality=95)

PNG uses simple text chunks (key-value pairs). No GPS support in the standard:

pnginfo = PngImagePlugin.PngInfo()
pnginfo.add_text("Software",      software)
pnginfo.add_text("Author",        make)
pnginfo.add_text("Creation Time", png_dt)
pnginfo.add_text("date:create",   iso_dt)
pnginfo.add_text("date:modify",   iso_dt)
img.save(output_path, "PNG", pnginfo=pnginfo)

Design Note: PNG's text chunks are completely human-readable with any hex editor. DotScramble still populates them because many social platforms and reverse image search engines parse them. Injecting noise is better than leaving them empty.

Part 2: Custom Metadata Control — Per-Field EXIF Surgery

The spoofing profiles are great for quick use, but power users need surgical control. That's what the Custom Metadata Dialog provides — a per-field control panel where every EXIF tag can independently be set to one of four actions:

✅ Keep   — preserve the original value exactly
🗑 Strip  — remove this field entirely  
🎲 Spoof  — replace with a random plausible fake
✏️ Custom — enter your own specific value

The `spoof_custom()` Function

This is the engine behind the dialog. It takes a field_actions dict and applies each action independently:

def spoof_custom(
    input_path: str,
    output_path: str | None = None,
    *,
    field_actions: dict,
) -> dict:
    """
    Apply per-field EXIF actions to a JPEG or PNG.

    field_actions keys: gps, make, model, software, datetime, copyright, exposure
    Values: "keep" | "strip" | "spoof" | {"value": str}
            (gps uses {"lat": .., "lon": ..} for custom)
    """

The resolver function handles all four action types elegantly:

def _resolve_text(key: str, fake_fn) -> str | None:
    action = field_actions.get(key, "keep")
    if action == "strip":             return None
    if action == "keep":              return current.get(key)
    if action == "spoof":             return fake_fn()
    if isinstance(action, dict):      return action.get("value", "")
    return current.get(key)

# Applied per-field:
r_make     = _resolve_text("make",     lambda: make)
r_model    = _resolve_text("model",    lambda: model)
r_software = _resolve_text("software", lambda: software)
r_datetime = _resolve_text("datetime", lambda: _fake_timestamp("random"))

Reading Existing EXIF to Pre-fill the UI

Before showing the dialog, DotScramble reads the current EXIF so the user can see what's actually in the file:

def read_exif_fields(image_path: str) -> dict:
    """Read current EXIF and return structured dict for pre-filling the dialog."""
    result = {k: None for k in
              ("gps", "make", "model", "software", "datetime", "copyright", "exposure")}

    exif_dict = piexif.load(image_path)
    zeroth = exif_dict.get("0th", {})
    exif   = exif_dict.get("Exif", {})
    gps    = exif_dict.get("GPS", {})

    result["make"]     = _decode(zeroth, piexif.ImageIFD.Make)
    result["model"]    = _decode(zeroth, piexif.ImageIFD.Model)
    result["datetime"] = _decode(zeroth, piexif.ImageIFD.DateTime)
    # ... GPS DMS → decimal conversion, exposure parsing, etc.
    return result

The GPS conversion from DMS rational back to decimal is the tricky part:

def _dms_to_decimal(dms_tuple, ref: bytes) -> float | None:
    d = _rational(dms_tuple[0]) or 0
    m = _rational(dms_tuple[1]) or 0
    s = _rational(dms_tuple[2]) or 0
    val = d + m / 60 + s / 3600
    if ref in (b"S", b"W"):
        val = -val
    return round(val, 6)

Preset System for the Dialog

The Custom dialog also supports saving and loading named presets, backed by a JSON file:

# Example saved preset
{
    "gps":       "strip",
    "make":      "spoof",
    "model":     "spoof",
    "software":  "strip",
    "datetime":  {"value": "2023:01:01 12:00:00"},
    "copyright": "keep",
    "exposure":  "spoof"
}

Factory presets ship with the app (Ghost, Troll, Artist), and users can create their own. Factory presets are read-only and can't be deleted or overwritten.

Part 3: Advanced Face and Eye Blur

The visual redaction engine lives in core/image_processor.py.

The Detection Engine

DotScramble uses OpenCV's Haar Cascade classifiers — a classical machine learning approach that's fast, works offline, and has no cloud dependencies. The DetectionEngine class wraps the key classifiers:

class DetectionEngine:
    """Advanced detection algorithms"""

    @staticmethod
    def detect_faces(image):
        """Detect faces using Haar Cascade"""
        face_cascade = cv2.CascadeClassifier(
            cv2.data.haarcascades + 'haarcascade_frontalface_default.xml'
        )
        gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
        faces = face_cascade.detectMultiScale(gray, 1.1, 5, minSize=(30, 30))
        return faces

    @staticmethod
    def detect_eyes(image):
        """Detect eyes using Haar Cascade"""
        eye_cascade = cv2.CascadeClassifier(
            cv2.data.haarcascades + 'haarcascade_eye.xml'
        )
        gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
        eyes = eye_cascade.detectMultiScale(gray, 1.1, 5, minSize=(20, 20))
        return eyes

The parameters that matter:

scaleFactor=1.1 — how much the image is scaled down per detection pass (1.1 = 10% reduction per pass, slower but more accurate)
minNeighbors=5 — how many overlapping detections a region needs before it's accepted (higher = fewer false positives)
minSize=(30, 30) — minimum region size in pixels (filters out noise)

Applying the Blur — The `gaussian_blur` Method

Once regions are detected, DotScramble applies effects. The gaussian_blur implementation has extensive validation to handle edge cases like faces at image borders:

@staticmethod
def gaussian_blur(image, x, y, w, h, strength):
    """Apply Gaussian blur to region with validation"""
    img_h, img_w = image.shape[:2]

    # Clip region to image boundaries (handles faces at edges)
    x_end = min(x + w, img_w)
    y_end = min(y + h, img_h)
    w = x_end - x
    h = y_end - y

    # Ensure minimum region size
    if w < 3 or h < 3:
        raise ValueError(f"Region too small: {w}x{h}")

    # GaussianBlur requires odd kernel size
    if strength % 2 == 0:
        strength += 1
    strength = max(3, strength)

    region = image[y:y_end, x:x_end]
    blurred = cv2.GaussianBlur(region, (strength, strength), 0)
    return blurred

Beyond Blur — The Full Effect Suite

Blur is just one option. DotScramble supports 7 different privacy effects that can be applied to any detected region:

Effect	Method	Best For
🌫️ Gaussian Blur	`gaussian_blur()`	Professional, natural look
🔲 Pixelation	`pixelate()`	Classic censoring style
⬛ Black Bar	`black_bar()`	Strong, unambiguous redaction
🎭 Gradient Fade	`gradient_fade()`	Artistic/subtle censoring
🔳 Mosaic	`mosaic_effect()`	Decorative tile pattern
❄️ Frosted Glass	`frosted_glass()`	Translucent glass aesthetic
🎨 Oil Paint	`oil_paint()`	Artistic painting effect

The pixelation effect is a neat double-resize trick — shrink down, then scale back up with nearest-neighbor interpolation:

@staticmethod
def pixelate(image, x, y, w, h, pixel_size):
    region = image[y:y_end, x:x_end]
    region_h, region_w = region.shape[:2]
    pixel_size = max(1, pixel_size)

    # Shrink → enlarge = pixelation
    temp_h = max(1, region_h // pixel_size)
    temp_w = max(1, region_w // pixel_size)
    temp = cv2.resize(region, (temp_w, temp_h), interpolation=cv2.INTER_LINEAR)
    pixelated = cv2.resize(temp, (region_w, region_h), interpolation=cv2.INTER_NEAREST)
    return pixelated

The frosted glass effect combines PIL and OpenCV:

@staticmethod
def frosted_glass(image, x, y, w, h, strength=15):
    region = image[y:y_end, x:x_end]

    # Convert to PIL for advanced filtering
    pil_region = Image.fromarray(cv2.cvtColor(region, cv2.COLOR_BGR2RGB))

    blurred  = pil_region.filter(ImageFilter.GaussianBlur(strength))
    enhanced = ImageEnhance.Brightness(blurred).enhance(1.1)
    final    = enhanced.filter(ImageFilter.EDGE_ENHANCE)

    # Back to OpenCV format
    return cv2.cvtColor(np.array(final), cv2.COLOR_RGB2BGR)

Opacity Blending — Partial Redaction

All effects support an opacity parameter that blends the processed region with the original:

@staticmethod
def apply_opacity(original, processed, opacity):
    """Blend processed region with original based on opacity"""
    if original.shape != processed.shape:
        processed = cv2.resize(processed, (original.shape[1], original.shape[0]))

    alpha = opacity / 100.0
    return cv2.addWeighted(processed, alpha, original, 1 - alpha, 0)

This is useful for subtle watermark-style redaction (e.g., 50% opacity blur) vs. hard censoring (100%).

The Full Workflow

📁 Load Image
    │
    ▼
🎯 Select Detection Mode
    ├── Face Detection (Haar Cascade)
    ├── Eye Detection (Haar Cascade)
    ├── Full Body Detection
    ├── License Plate (contour analysis)
    ├── Text Detection (Tesseract OCR)
    ├── Manual Selection (draw regions)
    └── Full Image
    │
    ▼
🎨 Choose Effect + Strength + Opacity
    │
    ▼
🛡️  Apply Metadata Control
    ├── Quick Profile (ghost / troll / artist)
    └── Custom Per-Field (keep/strip/spoof/custom)
    │
    ▼
💾 Save / Batch Export

Why Haar Cascades Instead of Deep Learning?

I get this question a lot. DotScramble intentionally chose Haar Cascades over modern deep learning detectors like YOLO or MediaPipe face mesh. The reasons:

No cloud, no internet — Haar Cascades run entirely offline. Privacy tools should never phone home.
Zero model download on first run — the XML classifiers are bundled with OpenCV. No 100MB model download.
Fast on CPU — users don't need a GPU. The app runs fine on a 5-year-old laptop.
Good enough for the use case — the goal is privacy, not 99.9% recall. If a face is missed, Manual Selection is always available as fallback.

That said, AI-powered tracking (YOLOv8 or similar) is on the roadmap for v1.4.0 to improve detection of faces at angles, in poor lighting, or partially occluded.

Getting Started

# Clone
git clone https://github.com/kareem2099/DotScramble.git
cd DotScramble

# Install dependencies
pip install -r requirements.txt
# pip install opencv-python numpy Pillow pytesseract piexif PySide6

# Optional: Tesseract for text detection
sudo apt install tesseract-ocr

# Run
python src/main.py

Or grab the standalone Linux executable — no Python required — from one of these:

Platform	Link
🐙 GitHub Releases	Latest Release
🖥️ OpenDesktop / Pling	opendesktop.org/p/2362477

Conclusion

DotScramble's metadata system takes a "active disinformation" approach rather than passive stripping — the result is metadata that looks legitimate while being completely meaningless. Combined with the visual redaction engine, it provides a comprehensive privacy toolkit that works entirely offline.

The code is Apache 2.0 licensed and open to contributions. If you're interested in adding AI tracking, GPU acceleration, or a web interface — pull requests are very welcome.

GitHub: github.com/kareem2099/DotScramble

OpenDesktop: opendesktop.org/p/2362477

Made with ❤️ for privacy protection

The AI They Said Was Too Dangerous — Is Now Inside the NSA

freerave — Sat, 13 Jun 2026 13:26:13 +0000

Anthropic refused the Pentagon. Drew the line in the sand. Called it ethics. Then walked in through the back door. The full Claude Fable 5 story — uncensored.

"The model isn't the product. The narrative is."

Let me tell you a story about principles, power, and the art of the quiet deal.

It has all the elements:

A government ultimatum
A CEO who said no
A 319-page document with one buried paragraph that blew everything up
And six engineers sitting inside the NSA doing exactly what the company publicly refused to do

This is the full Claude Fable 5 story.

No PR spin. No investor framing.

Just the sequence of events — in order.

ACT I — The Setup

July 2025.

The US Department of Defense signs contracts with Anthropic, Google, OpenAI, and xAI — up to $200 million each — to "accelerate adoption of advanced AI capabilities for critical national security challenges."

Anthropic calls Claude "the Department's most widely deployed frontier AI model."

Mission-critical applications. Intelligence analysis. Operational planning. Cyber operations.

Everything sounds aligned.

Then January 2026 happens.

ACT II — The Trigger

Reports surface that Claude was used in the military operation that captured Venezuelan President Nicolás Maduro.

Anthropic's own Acceptable Use Policy explicitly prohibits Claude from being used to "incite violence or develop weapons."

The contract talks turn cold — fast.

The Pentagon demands Anthropic agree to allow Claude for "any lawful use."

No carve-outs.

No red lines.

Full unrestricted access.

Anthropic's AUP had two specific prohibitions:

Mass domestic surveillance of Americans
Fully autonomous weapons — systems that select and engage targets without human intervention

The Pentagon says: remove them.

Anthropic says: no.

ACT III — The Ultimatum

February 27, 2026. 5:01 PM Eastern.

The deadline passes.

President Trump posts on Truth Social:

"THE UNITED STATES OF AMERICA WILL NEVER ALLOW A RADICAL LEFT, WOKE COMPANY TO DICTATE HOW OUR GREAT MILITARY FIGHTS AND WINS WARS!"

"The Leftwing nut jobs at Anthropic have made a DISASTROUS MISTAKE trying to STRONG-ARM the Department of War."

Within hours, Defense Secretary Pete Hegseth designates Anthropic a "supply chain risk to national security."

Same category as Huawei. Same category as ZTE.

The GSA removes Anthropic from USAi.gov.

Federal contractors are told to stop using Claude.

A six-month phase-out period begins.

CEO Dario Amodei says the company "cannot in good conscience accede" to the demands.

The internet briefly pays attention.

Then moves on.

ACT IV — The Courtroom

Anthropic doesn't roll over.

Two lawsuits. Two courts.

Northern District of California
D.C. Circuit Court of Appeals

March 26, 2026:

Federal Judge Lin issues a preliminary injunction blocking the ban.

She says the Pentagon's actions are "troubling" — and asks the obvious question:

"If the worry is about the integrity of the operational chain of command — [the Department of Defense] could just stop using Claude."

The D.C. Circuit denies Anthropic's parallel request.

Microsoft files an amicus brief supporting Anthropic.

The ban is technically blocked. Legally unresolved. Operationally chaotic.

Contractors don't know what to do.

Some stop. Some wait. Some quietly keep going.

ACT V — The Launch

June 9, 2026.

Anthropic drops Claude Fable 5 — the first publicly available Mythos-class model.

For context:

Claude Mythos launched in April as a restricted preview — too dangerous for public release, they said, citing its advanced ability to find software vulnerabilities
Project Glasswing gave access to a handful of critical infrastructure organizations across 15 countries
Now Fable 5 is the "safe" version — same engine, with guardrails

The name is deliberate.

Fable — from Latin fabula, "that which is told."

Same root as mythos.

Different story.

Benchmarks are impressive. Coding is strong. Vision is exceptional.

On long, complex, autonomous tasks — it pulls ahead significantly.

The developer community is cautiously optimistic.

ACT VI — The Buried Paragraph

Then someone reads page 47 of a 319-page system card.

Here is what it says — verbatim:

"Unlike our interventions for cybersecurity, biology and chemistry, and distillation attempts, these safeguards will not be visible to the user. Instead, the safeguards will limit effectiveness through methods such as prompt modification, steering vectors, or parameter-efficient fine-tuning (PEFT)."

Translation:

If you trigger a hidden filter — Fable 5 will silently downgrade itself.

Modify your prompt without telling you.

Steer the model away from your intent.

You will pay for Fable. You might get Opus.

You will never know.

Not for cybersecurity queries.

Not for biology.

For AI research — specifically, to prevent researchers from probing the model's own capabilities.

The response from the AI research community is immediate.

"The Claude Fable 5 nerf for AI research has induced the angriest reaction from AI researchers that I've ever seen in my life."

— Ethan Caballero, AI researcher

Anthropic reverses it in under 24 hours.

But the paragraph existed.

Someone wrote it.

Someone approved it.

Someone tried to ship it quietly inside 319 pages.

ACT VII — The Bill

While the ethics debate runs hot — the accountants are running hotter.

Fable 5 pricing:

$10 per million input tokens
$50 per million output tokens
90% discount for prompt caching

Real-world cost:

Per Borgen, CEO of Scrimba:

"Just tried Fable. It burned 1.3M tokens in 7 minutes. That's $160 per hour. Equivalent to a $333k/year salary."

Theo from T3 Chat:

Spent over $1,000 in tokens in a single day on a $200/month subscription plan.

Josh Ellithorpe, CTO at Pixelated Ink:

"Burns tokens like no other model. Can't even review this, since my testing is so limited."

Anthropic's answer: "Workflow mode breaks complex prompts into parallel subagent tasks — it costs more by design."

This is the democratization of AI.

$160/hour.

ACT VIII — The Twist Nobody Covered

Let's go back to the government ban.

While the Pentagon was labeling Anthropic a supply chain risk —

while Trump was posting on Truth Social —

while federal agencies were pulling Claude from their systems —

The Financial Times reports:

Anthropic had six engineers embedded inside the NSA as forward-deployed staff.

Their job: guide the agency's use of Claude Mythos — the unrestricted version — and customize it for specific applications.

The model would be useful, one source told the FT, for infiltrating networks in countries such as China and Iran.

The NSA's remit includes offensive cyberattacks against foreign adversaries.

So let's be precise about what happened:

Anthropic refused DoD access to Claude for autonomous weapons and mass surveillance of Americans
Anthropic simultaneously had engineers inside the NSA customizing Mythos for offensive cyber operations against foreign nations

That is not a contradiction.

That is a negotiation.

The "red lines" weren't ethical absolutes.

They were contract terms.

THE VERDICT

Claude Fable 5 is a genuinely impressive model.

The safety stance against the Pentagon on domestic surveillance and autonomous weapons? Admirable — and probably correct.

Dario Amodei's refusal to capitulate under presidential pressure? Worth respecting.

But here is the complete picture, in sequence:

✓ Signed $200M DOD contract
✓ Claude used in Venezuelan presidential capture
✓ Refused to remove domestic surveillance/weapons restrictions  
✓ Got labeled supply chain risk (Huawei tier)
✓ Sued the government
✓ Simultaneously embedded engineers inside NSA for offensive cyber ops
✓ Launched Fable 5 with secret silent downgrade for researchers  
✓ Reversed it 24 hours later under public pressure
✓ Filed IPO paperwork the week before launch
✓ Billed $160/hour for the experience

The question worth sitting with:

Was this about ethics — or about who controls the terms?

Because the model they said was too dangerous for the Pentagon

is now running inside the NSA

optimizing offensive cyber operations

with Anthropic engineers in the room.

The line wasn't "we won't help with offense."

The line was "we won't sign a contract that removes our control over how you use our product."

That's a business position.

A smart one.

But let's call it what it is.

You now have the full picture.

What you do with it is your business.

😈

Sources

#	Source	Publication	Date
1	Anthropic releases Claude Fable 5	TechCrunch	Jun 9, 2026
2	Introducing Claude Fable 5 and Claude Mythos 5	Anthropic Docs	Jun 9, 2026
3	Claude Fable 5 — Official Launch Post	Anthropic	Jun 9, 2026
4	Anthropic walks back covert capability limits	Fortune	Jun 10, 2026
5	Anthropic releases Mythos-like AI to public	CNBC	Jun 9, 2026
6	Anthropic vs. Pentagon: Fight Over Claude Access	Built In	May 1, 2026
7	Pentagon-Anthropic Dispute — Issues for Congress	Congress.gov / CRS	Apr 21, 2026
8	Federal Government and Anthropic — AI Competition	Congress.gov / CRS	May 5, 2026
9	Chain Reaction: What the Pentagon-Anthropic Dispute Means for Civilian Agencies	Center for Democracy and Technology	May 12, 2026
10	Pentagon Designates Anthropic a Supply Chain Risk	Mayer Brown	Mar 27, 2026
11	Anthropic is blacklisted by the Pentagon and used by the NSA	TechSpot	Jun 2026
12	A Timeline of the Anthropic-Pentagon Dispute	TechPolicy.Press	Apr 10, 2026
13	Trump Orders Federal Agencies to Dump Anthropic AI	AOL / Multiple	Feb 27, 2026
14	The Internet Is Furious at Anthropic After Fable 5 Release	Decrypt	Jun 10, 2026
15	Claude Fable 5 Review: What Developers Really Think	Tosea.ai	Jun 10, 2026
16	Claude Mythos — Wikipedia	Wikipedia	2026

Part of the **AI Reality Check* series — where the press release ends and the actual story begins.*

How I Hacked My Own GPG Key: A Developer's Forensic War Story

freerave — Fri, 12 Jun 2026 16:29:51 +0000

I forgot my GPG passphrase mid-release. Instead of generating a new key, I treated it as a CTF challenge — using clipboard forensics, vault analysis, and a targeted dictionary attack to crack it in under 3 seconds.

It was 11 PM. The release was almost done.

I was wrapping up a new build of DotScramble — my image redaction tool — when the terminal froze at the worst possible line:

Signing DotScramble-Linux-x86_64.deb with GPG...
[GPG Password Prompt Appears]

My fingers hovered over the keyboard.

I typed my go-to password. Incorrect.
A variation. Incorrect.
Three more attempts. Incorrect. Incorrect. Incorrect.

The cursor blinked at me, completely indifferent to my suffering.

Here's the brutal truth about GPG passphrases: there is no "Forgot Password" button. No recovery email. No support ticket. The passphrase is the key. Lose one, you've lost the other — permanently.

Most people would generate a new key and move on.

I decided to do something more interesting.

I treated my own key as a CTF target — simultaneously playing the attacker and the defender, with one night to crack it. Here's exactly how it went down.

🔬 Step 1: Digital Forensics First (Never Skip This)

Before touching any attack tooling, there's a golden rule in forensics:

Look before you break things.

On Linux, desktop environments often cache credentials silently in keyring managers. I opened Seahorse (GNOME's "Passwords and Keys" GUI) and combed through the login keyring entry by entry.

What I found:

🟡 Old browser session tokens
🟡 A stale VS Code credential
🟡 Some SSH passphrases from old servers
🔴 GPG passphrase: nowhere

It had never been saved there. The key was generated on a night when I apparently didn't think to cache it.

Next stop: shell history.

grep "gen-key\|passphrase" ~/.bash_history ~/.zsh_history

Nothing useful. I hadn't typed the passphrase inline during key generation — which is actually correct OpSec, ironically working against me now.

Dead end. Moving on.

📋 Step 2: Interrogating the Clipboard (`ghost.db`)

Then a thought hit me.

What if I copied the passphrase when I first created the key?

I run DotGhostBoard — a local clipboard manager I built that silently logs everything you copy into a SQLite database:

~/.config/dotghostboard/ghost.db

If that passphrase ever touched Ctrl+C, it would be fossilized in that database.

I wrote a quick query to surface short text items — the kind a passphrase would look like:

sqlite3 ~/.config/dotghostboard/ghost.db \
  "SELECT content, created_at FROM clipboard_items \
   WHERE length(content) BETWEEN 4 AND 100 \
   AND content NOT LIKE '%Device%' \
   ORDER BY created_at DESC LIMIT 50"

Dozens of entries scrolled past — code snippets, terminal output, random URLs. I scanned every line.

No passphrase.

The database has a max_history = 200 prune limit. My GPG key had been generated months earlier. The entry was already garbage-collected.

Result: Forensic trail cold. No direct match found.

Time to shift strategies entirely.

🧠 Step 3: The Human Factor — Building a Targeted Wordlist

At this point I had to accept one thing:

I wasn't going to find the password. I was going to have to deduce it.

Generic brute-force was never on the table. GPG's key derivation function (S2K) is intentionally slow — without lockout policies, you can technically try forever, but the entropy in a real passphrase makes raw brute-forcing take centuries on consumer hardware.

What does work is a targeted dictionary attack — one built not from rockyou.txt, but from your own brain.

I exported my browser password vault to a passwords.csv and ran a filter:

grep -i -E "gpg|git|key|passphrase|sign|dev" ~/passwords.csv

A pattern emerged immediately.

For local dev tooling and signing keys, I tend to use a consistent base formula — a core string I rotate the capitalization and trailing special characters on, depending on mood and how late it is when I'm generating the key.

I'd done the same thing here. I just didn't remember which variant I'd used that night.

I assembled a shortlist of the most likely candidates — each one a small mutation of the same base pattern. No random strings. No guesses. Pure informed deduction.

💀 Step 4: The Targeted Dictionary Attack

Armed with my candidate list, I needed a way to test passphrases programmatically — no GUI prompts, no interruptions, no manual gpg invocations.

This is where --pinentry-mode loopback becomes your best friend.

It tells GPG to accept the passphrase directly from stdin/environment instead of spawning a graphical pinentry dialog — which makes it completely scriptable:

#!/bin/bash

candidates=(
  "D3vSig@#"
  "d3vsig22"
  "D3vSig@"
  "qX7#mLP9sKRvZn2"
)

target_key="A7BC4921FE83D105"

for pwd in "${candidates[@]}"; do
    echo -n "Testing: $pwd ... "

    echo "test" | gpg \
      --batch \
      --yes \
      --pinentry-mode loopback \
      --passphrase "$pwd" \
      -u "$target_key" \
      --sign >/dev/null 2>&1

    if [ $? -eq 0 ]; then
        echo ""
        echo "==========================================="
        echo "🎉  SUCCESS! Passphrase recovered: $pwd"
        echo "==========================================="
        exit 0
    else
        echo "FAILED"
    fi
done

echo "All candidates exhausted. Expand the wordlist."
exit 1

I hit Enter and watched the output:

Testing: D3vSig@#      ... FAILED
Testing: d3vsig22      ... FAILED
Testing: D3vSig@       ... SUCCESS ✅

Three seconds. Four candidates. One answer.

The passphrase was the variant with a single trailing @ — not @#, not lowercase, not the longer entropy string. The specific variant I'd typed on a tired night when I didn't feel like looking up my usual suffix.

Human pattern recognition in action — working both for me (I knew the base formula) and against me (I didn't remember the exact mutation).

🏆 Step 5: Victory — And a Green Badge

With the passphrase recovered, I ran the build pipeline again:

python3 build.py

Processing: Creating release package...

Signing DotScramble-Linux-x86_64.deb with GPG...
   ✅ Detached signature created: DotScramble-Linux-x86_64.deb.asc

Signing DotScramble-Linux-x86_64.AppImage with GPG...
   ✅ Detached signature created: DotScramble-Linux-x86_64.AppImage.asc

Build completed successfully! 🎉

I uploaded the GPG public key block to my GitHub profile settings.

Every commit and release I push now shows that beautiful, green Verified badge.

At midnight, after all of that, it felt genuinely earned.

📌 What This Actually Teaches Us

This wasn't just a fun personal war story. It surfaces three things every developer should internalize:

1. Password managers aren't optional for GPG keys

The moment you run gpg --gen-key — not tomorrow, not later — open Bitwarden, 1Password, or KeePassXC and store that passphrase. GPG has zero mercy for forgetful humans. You will forget. Everyone forgets.

2. Targeted attacks will always beat generic ones

We think we make random passphrases. We don't. We make variations of patterns we already know, adjusted by habit, mood, and how late it is. A wordlist of 20 informed candidates will almost always outperform rockyou.txt by orders of magnitude when the target is yourself.

This is also why a single compromised vault can expose your entire security posture — your patterns leak across credentials.

3. Your clipboard manager is a forensic goldmine (and a liability)

DotGhostBoard has saved me in plenty of other recovery scenarios — but it's also a reminder that clipboard history databases are sensitive data stores. If yours isn't encrypted or access-controlled, a single compromised session can expose everything you've ever copied.

Know your prune window
Exclude sensitive applications from being tracked
Treat the database file itself like a secrets vault

🛠️ The Full Attack Surface Summary

Stage	Method	Result
Keyring check (Seahorse)	GUI inspection	❌ Not cached
Shell history	`grep` on `.bash_history`	❌ Not found
Clipboard forensics	SQLite query on `ghost.db`	❌ Pruned
Vault analysis	`grep` on `passwords.csv`	✅ Pattern identified
Dictionary attack	Loopback pinentry script	✅ Cracked (3.2s)

[DotScramble](https://github.com/kareem2099/DotScramble) is a standalone Python desktop app for image privacy protection — think face detection, license plate auto-blur, OCR text censoring, EXIF metadata spoofing, and batch processing across entire folders. It runs fully offline, ships as a single executable, and supports Arabic RTL out of the box. This build pipeline — the one that needed the GPG passphrase — is what packages and signs every release.

Next up: how DotScramble's freemium licensing system uses **Ed25519 asymmetric signing* to prevent key sharing — with the private key living entirely server-side, never touching the client.*

Did you ever lose a GPG passphrase? How did you handle it? Drop it in the comments 👇

I Built a Code Screenshot Tool Inside My VS Code Extension — Here's How It Works (DotShare v3.4.0)

freerave — Mon, 01 Jun 2026 09:34:05 +0000

You know that moment when you write a function you're genuinely proud of, and you want to share it on LinkedIn or Bluesky — but plain text just… doesn't do it justice?

I've been there every week.

I'm Kareem (FreeRave), founder of DotSuite — a suite of privacy-first Linux tools and VS Code extensions. DotShare is my VS Code extension for sharing content across LinkedIn, X, Bluesky, Reddit, Dev.to, Medium, Telegram, and more — all without leaving the editor.

Today I'm shipping v3.4.0, and the headline feature is CodeSnap: a code-to-image tool built entirely inside the extension's WebView, using nothing but HTML Canvas and Highlight.js.

No node-canvas. No sharp. No native binaries. Zero extra dependencies.

Let me walk you through how it works and why I built it this way.

The Problem: Code Screenshots in VS Code Are Painful

The existing solutions are either:

External web apps (Carbon, Ray.so) — you copy code, tab out, paste, configure, download, come back, attach. Five steps too many.
Other VS Code extensions (CodeSnap, Polacode) — great tools, but they don't integrate with a sharing workflow. You screenshot, then you still have to open your composer manually.

I wanted the whole loop inside one tool:

Select code → 📸 Snap → Pick platform → Composer opens with image attached

That's it. No context switching.

The Architecture Decision: Why HTML Canvas?

When I started building this, the "obvious" choice was node-canvas — the Node.js port of the HTML Canvas API. But I ran into three hard problems immediately:

1. Native binaries are a Marketplace nightmare.
node-canvas requires node-gyp and compiles native C++ addons. On VS Code Marketplace, extensions with native binaries are flagged, slow to install, and break on ARM Macs and certain Linux distros.

2. sharp is 10MB+ of compiled code.
For a feature that renders a static image, that's an absurd payload.

3. VS Code already ships a full browser engine (Electron).
The WebView is a Chromium tab. It has a GPU-accelerated Canvas API, a full DOM parser, and font rendering that matches what the user actually sees on screen. Why fight it?

So the decision was: render in the WebView, export PNG from there, and ship it back to the extension host.

The flow looks like this:

┌─────────────────────┐       loadCode        ┌─────────────────────┐
│   Extension Host    │ ──────────────────────▶│   WebView (Canvas)  │
│   (Node.js)         │                        │   (Chromium)        │
│                     │◀── snapReady (base64) ─│                     │
│  CodeSnapPanel.ts   │                        │  codesnap.html      │
│  MediaService.ts    │                        │  hljs + Canvas API  │
└─────────────────────┘                        └─────────────────────┘
         │
         ▼
    Saves to disk
    QuickPick: which platform?
    Opens Composer with image attached

CodeSnapService: Reading the Editor

The first piece is pure Node.js — no VS Code UI involved yet. CodeSnapService.capture() reads the active editor and returns everything the renderer needs:

// src/services/CodeSnapService.ts

export interface CodeSnapData {
    code: string;
    language: string;  // resolved to HL.js alias
    fileName: string;
    lineStart: number;
    lineEnd: number;
    hasSelection: boolean;
}

public static capture(): CodeSnapData | null {
    const editor = vscode.window.activeTextEditor;
    if (!editor) return null;

    const doc       = editor.document;
    const selection = editor.selection;
    const hasSelection = !selection.isEmpty;

    let code = hasSelection
        ? doc.getText(selection)
        : doc.getText();

    // Tabs break canvas rendering — convert to spaces first
    code = code.replace(/\t/g, '    ');

    // Strip common leading indent so the image doesn't waste space
    code = CodeSnapService._stripCommonIndent(code);

    return {
        code,
        language:  CodeSnapService._resolveLanguage(doc.languageId, doc.fileName),
        fileName:  path.basename(doc.fileName),
        lineStart: hasSelection ? selection.start.line + 1 : 1,
        lineEnd:   hasSelection ? selection.end.line   + 1 : doc.lineCount,
        hasSelection,
    };
}

Two details worth calling out:

Tab conversion — HTML Canvas has inconsistent \t rendering across platforms. Converting to 4 spaces before we even touch the canvas eliminates an entire class of alignment bugs.

Common indent stripping — if you select a deeply nested function, the raw text has 16 spaces of leading indent on every line. _stripCommonIndent finds the minimum indent across all non-empty lines and removes it. The rendered image uses the full canvas width instead of leaving most of it empty.

private static _stripCommonIndent(code: string): string {
    const lines = code.split('\n');
    const minIndent = Math.min(
        ...lines
            .filter(l => l.trim().length > 0)
            .map(l => l.match(/^(\s*)/)?.[1].length ?? 0)
    );
    if (minIndent === 0) return code;
    return lines.map(l => l.slice(minIndent)).join('\n').trimEnd();
}

The Canvas Renderer

The canvas rendering runs entirely in the WebView. Here's the core loop — I'll walk through it section by section.

Step 1: Measure before you paint

// Measure text to calculate canvas dimensions
const tmp    = document.createElement('canvas');
const tmpCtx = tmp.getContext('2d');
tmpCtx.font  = `${fontSize}px 'JetBrains Mono', 'Fira Code', Consolas, monospace`;

const lines    = data.code.split('\n');
const maxCodeW = Math.max(...lines.map(l => tmpCtx.measureText(l).width));

const innerW = Math.ceil(maxCodeW + lineNumWidth) + padding * 2;
const innerH = lines.length * LINE_H + padding * 2 + TITLE_H;

We use a throwaway canvas just to measure text width before the real canvas exists. This lets us size the output to exactly fit the content — no hardcoded 800px width.

Step 2: 2x resolution for Retina

const cv = document.createElement('canvas');
cv.width  = canvasW * 2;   // physical pixels
cv.height = canvasH * 2;
cv.style.width  = canvasW + 'px';   // CSS pixels
cv.style.height = canvasH + 'px';
const ctx = cv.getContext('2d');
ctx.scale(2, 2);  // scale the context — all our coordinates stay the same

The canvas is 2× the display size but we scale the context by 2× before drawing. Every coordinate we use is still in CSS pixels. The exported PNG is full Retina resolution.

Step 3: Syntax highlighting via HL.js

This is where the real trick lives. HL.js gives us highlighted HTML like:

<span class="hljs-keyword">const</span> 
<span class="hljs-title function_">greet</span>
<span class="hljs-punctuation">(</span>
<span class="hljs-params">name</span>
<span class="hljs-punctuation">)</span>

We parse that HTML into a flat token list, then paint each token with its color:

function parseHljsHtml(html, defaultColor) {
    const out    = [];
    const parser = new DOMParser();
    const doc    = parser.parseFromString(`<pre>${html}</pre>`, 'text/html');
    flattenNode(doc.querySelector('pre'), defaultColor, out);
    return out;
}

function flattenNode(node, inheritColor, out) {
    if (node.nodeType === Node.TEXT_NODE) {
        if (node.textContent) out.push({ text: node.textContent, color: inheritColor });
        return;
    }
    if (node.nodeType === Node.ELEMENT_NODE) {
        const cls   = (node.className || '').trim();
        const color = activePalette[cls] ?? inheritColor;
        node.childNodes.forEach(c => flattenNode(c, color, out));
    }
}

flattenNode recursively walks the HL.js DOM output. When it hits a text node, it records the current inherited color. When it hits a <span>, it looks up the class name in our palette and updates the color for that subtree.

Then we split by newlines to get per-line segment arrays, and paint:

lineSegs.forEach((segs, i) => {
    const y = codeY + i * LINE_H;

    // Line number (dim, right-aligned)
    if (showLines) {
        ctx.fillStyle = 'rgba(200,200,220,.22)';
        ctx.textAlign = 'right';
        ctx.fillText(String(data.lineStart + i), lineNumX, y);
        ctx.textAlign = 'left';
    }

    // Colored tokens, left-to-right
    let x = codeX;
    for (const seg of segs) {
        if (!seg.text) continue;
        ctx.fillStyle = seg.color;
        ctx.fillText(seg.text, x, y);
        x += ctx.measureText(seg.text).width;
    }
});

This is the part that makes the output look good. Each token is measured and positioned individually, so the colors align exactly with the text.

The Race Condition I Fixed

The tricky part wasn't the canvas rendering — it was the integration between CodeSnap and the Composer.

The original approach was setTimeout:

// ❌ Old approach — fragile
vscode.commands.executeCommand('dotshare.openFullWebview', 'post', { platform });
setTimeout(() => {
    DotShareWebView.postMessage({ command: 'mediaAttached', mediaFiles: [{ ... }] });
}, 800);  // hope 800ms is enough...

This breaks on slow machines. It breaks on first load when VS Code needs to compile the extension. It breaks when the Composer webview is loading a saved draft.

The fix is a proper handshake. The Composer fires webviewReady when it mounts:

// app.ts (Composer WebView)
function onReady() {
    enableDragAndDrop(get<HTMLTextAreaElement>('post-text'));
    enableDragAndDrop(get<HTMLTextAreaElement>('blog-body'));
    send('webviewReady');  // ← "I'm alive, send me stuff"
}

if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', onReady, { once: true });
} else {
    onReady();
}

The extension host handles webviewReady in DotShareWebView:

// DotShareWebView.ts
if (data?.command === 'webviewReady') {
    vscode.commands.executeCommand('dotshare._composerReady', panel);
    return;
}

And _composerReady atomically consumes any pending snap:

// extension.ts
vscode.commands.registerCommand('dotshare._composerReady', (panel: vscode.WebviewPanel) => {
    const pending = CodeSnapPanel.consumePendingSnap();
    if (pending) {
        panel.webview.postMessage({
            command:    'mediaAttached',
            mediaFiles: [{
                mediaPath:     pending.filePath,
                mediaFilePath: pending.filePath,
                fileName:      pending.fileName,
                fileSize:      0,
            }],
        });
    }
})

consumePendingSnap() uses a FIFO queue — reads and clears atomically, no double-delivery:

// FIFO queue — thread-safe, handles rapid double-snap edge case
private _pendingSnaps: Array<{ filePath: string; fileName: string }> = [];

public static consumePendingSnap(): { filePath: string; fileName: string } | null {
    return CodeSnapPanel._instance?._pendingSnaps.shift() ?? null;
}

No race condition. No magic number timeouts. The image attaches the instant the Composer is ready — whether that's 200ms or 3 seconds.

Offline-First: No CDN

One more architectural decision worth mentioning: the VS Code webview CSP blocks external CDN requests by default — and that's correct behavior. I vendor all HL.js assets locally:

media/webview/vendor/
  highlight.min.js
  styles/
    atom-one-dark.min.css
    github-dark.min.css
    monokai.min.css
    dracula.min.css
    nord.min.css
    vs2015.min.css
    tokyo-night-dark.min.css
    github.min.css
    catppuccin-mocha.min.css

The _buildHtml() method in CodeSnapPanel resolves all of these to webview.asWebviewUri() paths and injects them as a JSON map that the WebView uses for theme switching:

const themeCssMap: Record<string, string> = {};
for (const t of themes) {
    const localPath = vscode.Uri.joinPath(stylesDir, `${t}.min.css`);
    try {
        fs.accessSync(localPath.fsPath);
        themeCssMap[t] = webview.asWebviewUri(localPath).toString();
    } catch {
        // Skip missing files gracefully — theme won't appear in selector
    }
}

html = html.replace(/\{\{THEME_CSS_MAP\}\}/g,
    JSON.stringify(themeCssMap).replace(/</g, '\\u003c').replace(/>/g, '\\u003e')
);

Works completely offline. No network requests. No CDN downtime issues.

The Result

Here's what the full workflow looks like:

Select a function in your editor
Right-click → DotShare: 📸 CodeSnap (or use the keyboard shortcut)
The CodeSnap panel opens beside your editor with a live preview
Adjust theme, font size, padding, line numbers, watermark — instant re-render
Click 🚀 Share → QuickPick: which platform?
The Composer opens with the image already attached
Write your caption, hit send

Or — from inside the Composer — click 📸 Add CodeSnap to open the panel mid-composition.

9 themes ship out of the box, completely free: Atom One Dark, GitHub Dark, GitHub Light, Monokai, Dracula, Nord, VS2015, Tokyo Night, Catppuccin Mocha.

Install DotShare

The extension is free and open source.

VS Code Marketplace:
marketplace.visualstudio.com/items?itemName=FreeRave.dotshare

Open VSX (VSCodium / Windsurf / Cursor):
open-vsx.org/extension/freerave/dotshare

GitHub:
github.com/kareem2099/DotShare

What's Next

CodeSnap is v1 — there's plenty left to build:

Custom fonts: let users point to their own monospace font
Gradient backgrounds: mesh gradients instead of solid BG color
Multiple files: side-by-side code panels in one image
Animated GIF export: show code being written, line by line

If any of these sound useful — or if you hit a bug — open an issue on GitHub or drop a comment below.

And if you ship a post using CodeSnap, tag me. I want to see what you're building. 🚀

— Kareem (FreeRave), founder of DotSuite

DotShare 3.3: The Final 10% — Crashing the Rust Compiler and Fixing Silent Node.js Bugs (Part 4)

freerave — Fri, 29 May 2026 20:21:49 +0000

How we bridged the gap between a VS Code extension, a Next.js frontend, and a Rust Axum backend — and the bizarre bugs we fought along the way.

TL;DR: Integrating three stacks (Rust backend, Node.js/Electron extension, Next.js dashboard) is where the real bugs hide — not in your logic, but at the seams between ecosystems. This post covers 4 production-grade bugs: a silent fetch body corruption, a literal Rust compiler crash, a UI state machine that silently erased user work, and a secure OAuth token relay across three services.

The Rust backend was bulletproof. The Next.js dashboard was polished. The VS Code extension felt completely native. We were on the home stretch.

Then came the final 10%.

If you've shipped anything real, you already know what this means. Not because the work is hard in the traditional sense — but because you've crossed out of any single ecosystem's comfort zone. You're no longer debugging your code. You're debugging the spaces between Rust, Node.js, and Next.js. The gaps nobody writes documentation for.

These are the bugs that live there.

🐛 Bug #1 — The Silent `fetch` Body Corruption

The Setup

The VS Code extension needed to upload cover images to our Rust Axum backend. Since VS Code extensions run in a Node.js environment, we reached for the native fetch API plus the form-data npm package — a completely standard, well-documented combo.

The code looked textbook-correct:

import FormData from 'form-data';

const formData = new FormData();
formData.append('file', buffer, { filename: 'cover.jpg' });

const response = await fetch('https://api.dotsuite.dev/v1/media/upload', {
    method: 'POST',
    headers: {
        'Authorization': `Bearer ${token}`,
        ...formData.getHeaders() // Sets Content-Type + boundary
    },
    body: formData as any
});

The Symptom

The Rust backend threw this on every single attempt:

Multipart error: Error parsing multipart/form-data request

The Investigation

We spent hours auditing the Rust Axum Multipart extractor. We logged raw bytes. We checked content-type headers. Everything on the Rust side looked sane.

Then we flipped our perspective: what if the problem was in the request itself, not the parser?

Here's the key insight. There are two completely different things called "FormData":

	Web FormData (`window.FormData`)	`form-data` npm package
Lives in	Browser / Web APIs	Node.js ecosystem
Body type	Serializes itself natively	Returns a readable stream
Works with native `fetch`?	✅ Yes	❌ No

Node's native fetch was designed around the Web FormData interface. When you pass it a form-data stream, it doesn't know how to pipe the boundary markers into the body correctly. The headers said Content-Type: multipart/form-data; boundary=---12345 — but the body was malformed. The Rust parser saw garbage.

The Fix

We replaced native fetch with axios for this specific upload path. Axios understands how to serialize Node.js stream-based FormData objects properly:

import axios from 'axios';

const response = await axios.post(
    'https://api.dotsuite.dev/v1/media/upload',
    formData,
    {
        headers: {
            'Authorization': `Bearer ${token}`,
            ...formData.getHeaders(),
        },
        maxBodyLength: Infinity, // No cap on upload size
    }
);

Immediately, the Rust backend parsed the stream perfectly, validated the magic bytes, and forwarded the file to Cloudflare R2.

💡 Lesson: Native fetch in Node.js is NOT a drop-in replacement for node-fetch or axios when dealing with npm's form-data streams. The Web API and the Node.js ecosystem have diverged here in a subtle, silent, and infuriating way.

💥 Bug #2 — We Crashed the Rust Compiler

The Setup

While refining the post scheduler, we hit an error that sends ice down the spine of any Rust developer. Not a runtime panic. Not a logic error.

The compiler itself crashed.

thread 'rustc' panicked at library/alloc/src/vec/mod.rs:2873:36:
slice index starts at 16 but ends at 15
error: the compiler unexpectedly panicked. this is a bug.

query stack during panic:
#0 [check_mod_deathness] checking deathness of variables in module `platforms`

This is called an ICE — Internal Compiler Error. It means rustc hit a state it was never supposed to reach. These are filed as bugs against the Rust project itself.

The Cause

The stack trace pointed to check_mod_deathness — the compiler pass that finds dead (unused) code to issue dead_code warnings.

We had this struct:

pub struct PublishResult {
    pub platform: Platform,
    pub post_url: Option<String>,
}

We were producing PublishResult values inside an iterator chain, but the post_url field was never actually consumed anywhere downstream. The dead-code analysis pass, when it encountered this specific pattern — an unused field inside a struct flowing through an iterator chain — hit an edge case and panicked internally.

The compiler wasn't wrong to complain. We were writing dead code. It just wasn't supposed to crash about it.

The Fix

The tempting shortcut was #[allow(dead_code)]. That silences the warning without fixing anything.

The right fix was to actually use the field. We updated the scheduler to log published URLs on success — which made post_url a live, consumed value:

// Actively consume post_url — turns dead code into observable telemetry
let published_urls: Vec<String> = results.iter()
    .filter_map(|r| r.as_ref().ok())
    .filter_map(|r| {
        r.post_url
            .as_ref()
            .map(|url| format!("{:?}: {}", r.platform, url))
    })
    .collect();

if !published_urls.is_empty() {
    tracing::info!(urls = ?published_urls, "✅ Post published successfully");
}

By consuming the field, the dead-code analyzer had nothing to flag. We bypassed the compiler bug entirely — and gained structured logs as a bonus.

💡 Lesson: An ICE is the compiler's way of saying "this code revealed a bug in me." But the underlying cause is almost always real dead code or a degenerate abstraction. Fix the dead code first — #[allow(dead_code)] is a bandage, not a solution. You can also report the ICE to help the Rust team fix the compiler bug itself.

🗑️ Bug #3 — The "Success" That Wiped Everything

The Setup

With backend and network layers stable, we focused on UX polish inside the VS Code extension's webview. That's when users started reporting something maddening:

"I upload a cover image and my entire post — title, tags, content — disappears."

The Investigation

We traced it to a central MessageHandler inside the webview that listened for backend status events:

// ❌ The bug: generic "success" = nuclear reset
case 'status':
    if (msg.type === 'success') {
        resetAllComposers(); // Wipes title, tags, content, everything
    }

The logic made sense in isolation: a success status meant a post had been published to the cloud, so clear the UI for the next post.

The problem: uploading a cover image also emitted a success status. The event system didn't distinguish between:

✅ "Image uploaded successfully" (informational — keep the form)
✅ "Post published successfully" (workflow complete — reset the form)

Both were { type: 'success' }. The UI couldn't tell them apart, so it did what it was told: wiped everything.

The Fix

We separated informational success from workflow completion at the message contract level:

// ✅ The fix: explicit, semantic events

// Generic status messages only control spinners and toast notifications
case 'status':
    updateLoadingState(msg);
    showToast(msg.message);
    break;

// Dedicated events for actual workflow transitions
case 'shareComplete':
    resetMainComposer();
    break;

case 'blogShareComplete':
    resetBlogComposer();
    break;

The backend now emits shareComplete or blogShareComplete only when the final publishing transaction commits. Image uploads, connection checks, and other intermediate operations stay as status events.

💡 Lesson: Generic event types are a trap. When your event bus grows, { type: 'success' } is as meaningful as { type: 'thing happened' }. Name events after what specifically occurred — not the sentiment of the outcome. imageUploadComplete and postPublished are unambiguous. success is not.

🔐 Bug #4 — Bridging OAuth Across Three Services

The Problem

This wasn't a crash — it was a design gap. Our Next.js frontend handles OAuth handshakes with X, LinkedIn, and Dev.to. Our Rust backend needs those tokens to execute the scheduled posts. The VS Code extension needs to know which platforms are connected to render the right UI buttons.

Three services. One source of truth. Zero raw tokens exposed to the client.

The Architecture

We implemented a secure internal handshake with a strict data flow:

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  1. User connects LinkedIn via Next.js OAuth flow           │
│                                                             │
│  2. Next.js → POST /v1/internal/credentials/sync (Rust)    │
│     Body: { user_id, platform, encrypted_token }            │
│     Auth: internal service secret (never client-exposed)    │
│                                                             │
│  3. Rust stores encrypted token, bound to user_id           │
│                                                             │
│  4. VS Code Extension → GET /v1/oauth/connections (Rust)   │
│     Response: { linkedin: true, x: false, devto: true }     │
│                    ↑                                         │
│              Boolean map only — no tokens, ever             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Key security properties:

Tokens never touch the VS Code client. The extension only receives a boolean map of connected platforms.
The sync endpoint is internal-only. Protected by a service secret, not a user JWT.
Encryption at rest. Tokens are encrypted before storage in Rust, so even a database breach doesn't expose raw credentials.

The VS Code extension UI reacts dynamically — scheduling buttons enable/disable based on the boolean map, with zero coupling to the underlying OAuth tokens:

// Extension side — clean, no tokens in sight
const connections = await api.get<ConnectionMap>('/v1/oauth/connections');
// { linkedin: true, x: false, devto: true }

setScheduleButtonEnabled('linkedin', connections.linkedin);
setScheduleButtonEnabled('x', connections.x);
setScheduleButtonEnabled('devto', connections.devto);

💡 Lesson: When bridging auth across services, define exactly what each service needs to know — and nothing more. The VS Code client doesn't need tokens; it needs a boolean. Expose the minimum necessary data at each boundary.

Wrapping Up: The Bugs Live at the Seams

The individual stacks were each fine. Rust was fast and correct. Next.js was clean. The VS Code extension behaved exactly as expected in isolation.

Every single bug in this post happened at a boundary:

Node.js streams meeting a Rust multipart parser
A compiler analysis pass encountering dead code in an iterator chain
A generic UI event system conflating two different kinds of success
Three services needing to share auth state without sharing secrets

Cross-stack integration isn't about making things work — it's about making sure the assumptions baked into each ecosystem don't silently contradict each other. They will. Treat every boundary as a potential failure point, test each one in isolation before connecting them, and when something breaks, look at the interface before blaming the implementation.

That's how DotSuite went from a collection of three isolated services to one coherent, production-ready system.

This concludes the DotSuite Backend Architecture series. If you found this useful, the previous parts cover the concurrent cloud scheduler, the zero-trust media upload pipeline, and the OAuth flow in detail. Happy shipping.

Securing DotShare 3.3: Inside the Rust Media API (Magic Bytes, Atomic Quotas, & Race Fixes) - Part 3

freerave — Wed, 27 May 2026 10:14:16 +0000

How we built a production-grade Cloudflare R2 upload pipeline in Rust — with layered security, an atomic quota system, and a zero-trust file validation strategy.

In Part 2 of this series, we enforced Strict Separation and Fail-Fast validation to prevent silent scheduling failures and auto-refresh OAuth tokens in the background.

But our users still needed to attach images to their scheduled posts. And the moment you let users upload files to your server, you inherit one of the hardest problems in backend security: you can never trust what a user sends you.

Here is a deep dive into how we built the POST /v1/media/upload endpoint in Rust — with layered file validation, Cloudflare R2 storage, and an atomic quota system that closes a subtle but critical race condition.

The Problem: File Uploads Are a Security Minefield

Allowing file uploads without proper validation is one of the most common vectors for server compromise. The naive approach — checking the file extension or trusting the Content-Type header — is dangerously insufficient.

A malicious user can trivially rename exploit.php to photo.jpg and send it with Content-Type: image/jpeg. A server that trusts that header will store an executable PHP file in what it thinks is an image directory.

We needed a Zero-Trust validation pipeline. The rule: don't believe anything the client tells you. Verify everything from the raw binary.

Layer 1: Authentication & Body Size at the Router

Before a single byte of the file payload is even parsed, two guards run at the Axum router level.

The first is our existing Bearer JWT middleware — no valid token, no entry. The second is a global body size limit declared on the router itself:

// src/main.rs

use axum::extract::DefaultBodyLimit;

let app = Router::new()
    .route("/v1/media/upload", post(routes::media::upload_media))
    // ... other routes ...
    .layer(DefaultBodyLimit::max(10 * 1024 * 1024)); // 10 MB hard cap

This DefaultBodyLimit layer rejects oversized requests at the framework level — before our handler allocates any memory for the file. It is the outermost wall.

Layer 2: Magic Bytes Validation (Zero-Trust File Identity)

Inside the handler, we apply a second, stricter file size check (5 MB) and then the core of our zero-trust strategy: magic bytes validation.

Every legitimate image file format begins with a known binary signature, called a "magic number," embedded in the first few bytes of the file. JPEG files always start with FF D8 FF. PNG files always start with 89 50 4E 47. These cannot be faked without corrupting the file.

Here is our implementation:

// src/routes/media.rs

// Allowed MIME types and their corresponding magic bytes
const ALLOWED_TYPES: &[(&str, &[&[u8]], &str)] = &[
    ("image/jpeg", &[&[0xff, 0xd8, 0xff]], "jpg"),
    ("image/png",  &[&[0x89, 0x50, 0x4e, 0x47]], "png"),
    ("image/webp", &[&[0x52, 0x49, 0x46, 0x46]], "webp"), // RIFF header
    ("image/gif",  &[&[0x47, 0x49, 0x46, 0x38]], "gif"),
];

fn validate_magic_bytes(buffer: &[u8], mime_type: &str) -> Option<&'static str> {
    for (allowed_mime, magics, ext) in ALLOWED_TYPES {
        if *allowed_mime == mime_type {
            for magic in *magics {
                if buffer.starts_with(*magic) {
                    return Some(ext); // Return the verified extension
                }
            }
        }
    }
    None // Content-Type claimed a valid MIME but binary doesn't match — reject
}

This function does two things at once. First, it checks that the claimed Content-Type is on our whitelist. Second, it verifies that the actual binary content matches the claimed format. A renamed executable will fail this check because its binary signature will never match FF D8 FF.

Layer 3: UUID-Based Storage Keys (Path Traversal Prevention)

Even after validating the file content, we never use the client-supplied filename to construct the storage key. A filename like ../../../etc/passwd — known as a Path Traversal attack — could theoretically escape the intended storage directory.

Our solution is to discard the original filename entirely and generate a random UUID as the storage key:

// The raw client filename is intentionally discarded.
// UUID-based key — fully immune to path traversal.
let file_name = format!("dotsuite/scheduled_posts/{}.{}", Uuid::new_v4(), ext);

The extension comes from our validate_magic_bytes function — not from the client. The full storage path is entirely server-generated. The user's filename never touches the storage layer.

Layer 4: Atomic Quota Enforcement (Closing the Race Condition)

This is where it gets subtle. Our initial quota check looked reasonable:

// ❌ The naive (broken) approach
let current = user.images_used; // Read from DB
if current >= image_quota {
    return Err(quota_exceeded_error);
}
// ... upload the file ...
db.increment_images_used(user_id).await; // Write to DB

The flaw: there is a window between the read and the write. If two upload requests arrive simultaneously from the same user whose quota counter is at limit - 1, both will read current < limit, both will pass the check, and both will upload — incrementing the counter to limit + 1. The quota is silently bypassed.

We had already solved this exact pattern in our schedule_post route using MongoDB's find_one_and_update — an atomic operation that combines the check and the increment in a single database command. We applied the same fix here:

// src/routes/media.rs

// ── Atomic quota check + slot reservation ────────────────────────────────
// find_one_and_update eliminates the race condition: the check and the
// increment are a single atomic MongoDB operation, not two separate ones.
let quota_filter = if user.tier == Tier::Free {
    mongodb::bson::doc! {
        "_id": user_id,
        "$expr": { "$lt": ["$images_used", image_quota as i64] }
    }
} else {
    // Paid tiers have no hard cap — we still track for analytics.
    mongodb::bson::doc! { "_id": user_id }
};

let reserved = users_col
    .find_one_and_update(
        quota_filter,
        mongodb::bson::doc! { "$inc": { "images_used": 1 } },
    )
    .await?;

if reserved.is_none() {
    return Err(AppError::Forbidden(format!(
        "Image upload quota reached ({}/{} uploads). Upgrade to Basic for unlimited uploads.",
        user.images_used, image_quota
    )));
}

The database becomes the single source of truth. No two concurrent requests can both pass the quota gate because MongoDB guarantees the atomicity of findOneAndUpdate at the document level.

Layer 5: The R2 Upload & Quota Rollback

After the quota slot is reserved, we upload to Cloudflare R2 via the AWS S3-compatible SDK. But there is one more edge case: what if the R2 upload fails after we have already incremented the quota counter? The slot was reserved but no file was stored — the user's quota is penalised for a failure that wasn't their fault.

To handle this cleanly, we perform a rollback on R2 failure:

if let Err(e) = upload_result {
    tracing::error!("Failed to upload to R2: {:?}", e);

    // Rollback: return the slot so the quota isn't wasted.
    let rollback = users_col
        .update_one(
            mongodb::bson::doc! { "_id": user_id },
            mongodb::bson::doc! { "$inc": { "images_used": -1i32 } },
        )
        .await;

    if let Err(rb_err) = rollback {
        tracing::error!(
            "Failed to rollback images_used for user {}: {}",
            user_id, rb_err
        );
    }

    return Err(AppError::Internal(anyhow::anyhow!(
        "Failed to upload media to cloud storage"
    )));
}

The rollback is best-effort — we log a critical error if it fails, but we do not surface the rollback failure to the client.

The Complete Security Stack

Here is what runs on every single upload request, in order:

Layer	Mechanism	Rejects
1	Bearer JWT middleware	Unauthenticated requests
2	`DefaultBodyLimit` (10 MB)	Oversized requests before parsing
3	Handler check (5 MB)	Files within the body but over the per-file limit
4	Magic bytes validation	Wrong MIME type, renamed executables, corrupted files
5	Atomic `find_one_and_update`	Quota-exceeded requests (race-condition-free)
6	UUID storage key	Path traversal attacks
7	R2 upload + rollback	Storage failures without wasting quota

None of these layers is sufficient alone. Together, they form a defence-in-depth pipeline where each layer assumes the previous one could have been bypassed.

Conclusion

Building a production-grade file upload endpoint is deceptively complex. The surface-level logic — receive file, save to storage — takes an hour. The hardening takes days.

The three biggest lessons from this build:

Never trust Content-Type. A header is a claim, not a proof. Always read the raw binary signature of the file.
A quota check and a quota increment must be one atomic operation. Two database calls — even milliseconds apart — create a race window that determined users will find and exploit.
Reserve resources before the expensive operation, and roll back on failure. Incrementing the quota counter before the R2 upload, with a decrement on failure, is always safer than incrementing after a success that might never be recorded.

The POST /v1/media/upload endpoint is now a vault. In Part 4, we will build the Next.js scheduling UI that calls it.

(If you haven't read the previous deep dives, check out the full Ship on Schedule Series.)

Building DotShare 3.3: A Fail-Fast Rust Scheduler with Background OAuth Auto-Refresh (Part 2)

freerave — Mon, 25 May 2026 06:46:15 +0000

In Part 1 of this backend series, I broke down the core architecture of dotsuite-core — a private Rust backend powering 18 developer tools, complete with multi-tier scheduling and the "Look-Ahead + Sleep" pattern.

But as with any production system, solving one architectural challenge reveals the next. In our case: Silent Scheduling Failures and Expiring OAuth Tokens.

Here is a deep dive into how we implemented a Strict Separation model, adopted a Fail-Fast philosophy, and engineered a background worker in Rust to automatically refresh OAuth tokens before they expire.

The Problem: Doomed Scheduled Posts

DotShare allows developers to schedule social media posts directly from VS Code. Initially, our scheduling flow looked like this:

User writes a post in VS Code and clicks "Schedule".
The Rust backend accepts the payload, deducts the monthly quota, and saves it as Pending in MongoDB.
The background cron scheduler wakes up at the right time to publish.

The Flaw: What if the user hadn't connected their Twitter (X) or LinkedIn accounts via OAuth on the DotSuite dashboard yet?

The scheduler would wake up, search the database for the user's OAuth tokens, find nothing, and inevitably fail. The user's quota was burned, the database was polluted with doomed posts, and the user woke up to a silent failure.

Architecture Decision: Strict Separation & Fail-Fast

We needed a Strict Separation between local VS Code execution and Cloud Scheduling. If you want the cloud to schedule it, the cloud must have your OAuth tokens.

Instead of catching the error during the background cron tick, we applied the Fail-Fast principle right at the API gateway. The server must definitively verify the existence of the required platform credentials before doing anything else.

Here is the exact Rust code we added to our schedule_post route to enforce this:

// src/routes/posts.rs

// ── Pre-Quota: OAuth Credentials Validation ────────────────────────────
let creds_col = state.db.collection::<UserCredential>("user_credentials");

// Convert the requested platforms to BSON
let platforms_bson: Vec<bson::Bson> = body.platforms.iter()
    .map(|p| bson::to_bson(p).unwrap())
    .collect();

// Query MongoDB for existing credentials
let mut cursor = creds_col.find(doc! {
    "user_id": user_id,
    "platform": { "$in": platforms_bson }
}).await?;

let mut connected_platforms = std::collections::HashSet::new();
use futures_util::TryStreamExt;
while let Ok(Some(cred)) = cursor.try_next().await {
    connected_platforms.insert(cred.platform);
}

// Find exactly which platforms the user is missing
let missing_platforms: Vec<Platform> = body.platforms
    .iter()
    .filter(|&p| !connected_platforms.contains(p))
    .cloned()
    .collect();

if !missing_platforms.is_empty() {
    let names = missing_platforms.iter()
        .map(|p| format!("{:?}", p))
        .collect::<Vec<_>>()
        .join(", ");

    // Reject instantly before quota deduction!
    return Err(AppError::MissingOauth(
        format!("You haven't connected {} to DotSuite Cloud yet.", names),
        missing_platforms,
    ));
}

By adding a custom MissingOauth error variant in our errors.rs, the Axum backend generates a beautifully structured JSON response:

{
  "error": {
    "code": "MISSING_OAUTH_CREDENTIALS",
    "message": "You haven't connected X, LinkedIn to DotSuite Cloud yet.",
    "missing_platforms": ["x", "linkedin"]
  }
}

Premium UX in VS Code (TypeScript)

A structured error is only as good as the UX that presents it. In our VS Code extension, we intercept the MISSING_OAUTH_CREDENTIALS error code.

Instead of showing a generic "Server Error 400" toast, we display an actionable VS Code alert with an "Open Dashboard" button. This deep-links the developer straight into their DotSuite Cloud integration settings.

// DotShare/src/handlers/PostHandler.ts

const result = await SchedulerClient.schedulePost(context, postData, platforms, scheduledTime);

if (!result.success) {
    if (result.errorCode === 'MISSING_OAUTH_CREDENTIALS') {
        const action = 'Open Dashboard';
        vscode.window.showErrorMessage(
            '☁️ Cloud Scheduling requires secure OAuth. Please open the DotSuite Dashboard to connect your social accounts.',
            action
        ).then(selection => {
            if (selection === action) {
                // Deep link right to the login/integrations page
                const DOTSUITE_LOGIN_URL = `https://dotsuite.dev/en/login?intent=vscode`;
                vscode.env.openExternal(vscode.Uri.parse(DOTSUITE_LOGIN_URL));
            }
        });
    } else {
        vscode.window.showErrorMessage(`Failed: ${result.message}`);
    }
}

Now, the server doesn't waste space on dead posts, quota remains untouched, and the user gets a seamless, enterprise-grade onboarding experience.

The Next Boss: Background Token Auto-Refresh

We solved the missing credentials problem, but OAuth tokens have notoriously short lifespans (often exactly 1 hour). If a user schedules a post for tomorrow, their token will be expired by the time the scheduler wakes up.

To fix this, we integrated auto-refresh logic directly into our scheduler.rs worker. Right before publishing a post, the scheduler checks the token's expires_at timestamp. If it expires in less than 5 minutes, it transparently refreshes the token via HTTP, saves the new encrypted tokens to the database, and proceeds with the publish cycle.

Here is the implementation:

// src/scheduler.rs

let now = DateTime::now();

// Check if token expires in less than 5 minutes
if now.timestamp_millis() > oauth_token.expires_at.timestamp_millis() - (5 * 60 * 1000) {
    tracing::info!("Refreshing OAuth token for platform {:?}", cred.platform);

    let refresh_token_str = oauth_token.refresh_token_encrypted.as_deref().unwrap_or("");

    // Fetch API keys from environment
    let cid = std::env::var(format!("{:?}_CLIENT_ID", cred.platform).to_uppercase()).unwrap_or_default();
    let csec = std::env::var(format!("{:?}_CLIENT_SECRET", cred.platform).to_uppercase()).unwrap_or_default();

    // Match the platform to its specific refresh logic via reqwest::Client
    let refresh_result = match cred.platform {
        Platform::X => refresh_x_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::LinkedIn => refresh_linkedin_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Facebook => refresh_facebook_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        Platform::Reddit => refresh_reddit_token(&client, refresh_token_str, &cid, &csec, enc_key).await,
        _ => Err(anyhow::anyhow!("Platform unsupported for auto-refresh")),
    };

    if let Ok((new_access_enc, new_refresh_enc, expires_in)) = refresh_result {
        // 1. Decrypt and use the newly fetched token immediately
        let plain_access = crate::crypto::decrypt_token(&new_access_enc, enc_key).unwrap();
        tokens.insert(cred.platform, plain_access);

        // 2. Save the new encrypted tokens back to MongoDB atomically
        let new_expires_at = DateTime::from_millis(now.timestamp_millis() + (expires_in as i64 * 1000));
        let update_doc = doc! {
            "$set": {
                "oauth_token.access_token_encrypted": new_access_enc,
                "oauth_token.refresh_token_encrypted": if new_refresh_enc.is_empty() { None::<String> } else { Some(new_refresh_enc) },
                "oauth_token.expires_at": new_expires_at,
                "updated_at": DateTime::now(),
            }
        };

        creds_col.update_one(doc! { "_id": cred.id.unwrap() }, update_doc).await.unwrap();
        tracing::info!("✅ Successfully saved refreshed token for {:?}", cred.platform);
    }
}

By decoupling the refresh logic into the background worker, the user never experiences HTTP round-trip delays when they click "Schedule" in VS Code. The tokens remain perpetually active as long as they are using the service, and everything happens completely behind the scenes.

Conclusion

By enforcing Strict Separation (validating cloud tokens explicitly on schedule) and leaning into the Fail-Fast design pattern, we protected our backend from pointless processing, saved the users' quotas, and improved the UX significantly.

Coupled with a resilient, auto-refreshing background job, the scheduling architecture is now as robust as the industry giants.

The biggest takeaway for your next API? Don't let your system silently fail. Stop the user at the gate, tell them exactly what they need to do with a structured JSON error, and give the frontend enough context to render a button that solves the problem for them!

(If you haven't read the previous deep dives, check out the full Ship on Schedule.)

Testing DotShare Cloudflare Image Upload

freerave — Sun, 24 May 2026 10:39:45 +0000

Testing Cloudflare R2 Integration

This is a test article to verify that the DotShare Cover Image Upload feature is working perfectly with Cloudflare R2 and the Rust backend.

What are we testing?

Selecting an image via the VS Code extension.
Converting the image to a Buffer via axios instead of native fetch.
Verifying that the Axum Rust server detects the magic bytes correctly.
Ensuring the Cloudflare R2 upload succeeds and returns a public URL.

If you can read this on Dev.to and see the cover image, then the end-to-end media upload pipeline is fully operational! 🚀

DEV Community: freerave

How I Refactored My Developer Portfolio Into a Modular, Secure, and Playfully Destructive Playground (v1.1.0)

A deep dive into refactoring a 1500+ line JS monolith into elegant ES6 modules, boosting performance by 95%, fixing XSS vectors, and adding a treacherous text-based game easter egg.

🛠️ The Architecture: Breaking the Monolith

The Terminal State Controller

🔒 Hardening Security: Banishing new Function

⚡ Performance: 95% CPU Savings

🎮 The Fun Part: The Quantum Root Key Betrayal

The Set Up

The Betrayal

💻 The Ultimate Failsafe: Reverting via git reverse

📈 Summary of Improvements

Conclusion

xAI's Grok Build CLI Was Quietly Uploading Entire Codebases to Google Cloud

xAI's Grok Build CLI uploaded whole git repos — secrets included — to Google Cloud, bypassing its own opt-out. Here's the full breakdown, plus how to actually verify what your AI CLI is sending.

TL;DR

What Is Grok Build, and Why It Matters

The Discovery

The Numbers That Made This Go Viral

Proof It Wasn't Just "Files the AI Happened to Read"

Secrets Went Along for the Ride

The "Improve the Model" Toggle Doesn't Do What You'd Assume

Where the Data Actually Goes

Quick Timeline

Important Caveats — Read This Before You Panic Further

What to Do If You've Used Grok Build CLI

How to Actually Verify What Your AI CLI Is Sending (Not Just Trust the Settings Page)

1. TLS-terminating proxy, not passive sniffing

2. Egress allowlisting at the OS/network-namespace level, not app-level toggles

3. Syscall/eBPF-level monitoring — catches what proxying can't

4. Treat tracked-file exposure as a git-hygiene problem, independent of any specific tool

5. Container isolation with a scoped bind-mount, not "point it at your whole machine"

The Bigger Lesson

Sources & Further Reading

Building DotScramble Part 3: Wayland Wars, a Custom File Picker, and Designing AI Evasion

From a PyQt6 license crisis to a fully animated PySide6 file browser that doesn't explode on Wayland — plus non-blocking batch processing and designing AI evasion.

The Crisis I Didn't See Coming

The Wayland Window Snap Problem

Problem 1: setMaximumWidth on the sidebar kills snap layouts

Problem 2: Canvas resize fires hundreds of times during snap animation

Problem 3: restore_window_state on Wayland

Replacing the Native File Dialog

The design

The Wayland painter trap

The dialog open animation on Wayland

The QScrollArea double-delete crash

Cross-platform bookmarks

Thumbnail loading

Multithreading in Qt: Non-Blocking Batch Processing

Thread-Safe Communication via Custom Signals

The Worker Thread Lifecycle

Graceful Cancellation and License Gating

What's Next: Designing AI Evasion (Adversarial Perturbation)

The Threat Model: AI Face Recognition

Fooling the Neural Network

The Black-Box Challenge (SPSA)

Bugs I Hit and What They Actually Were

Key Takeaways

Building DotScramble Part 2: Ed25519 License Signing, Machine Fingerprinting, and a 7-Day Offline Grace Period

The Threat Model

The Token Format

Why Ed25519 Over HMAC?

The Verification Function

Machine Fingerprinting

The Activation Flow

Storing the Token

The Background Recheck Thread

The is_max_activated Property

Protecting the Source with Cython

The Full Lifecycle

What Doesn't Work (By Design)

Key Takeaways

Inside DotScramble: Metadata Spoofing, Custom EXIF Control, and Advanced Face/Eye Blur

A deep dive into how DotScramble protects your privacy — from injecting plausible-but-fake EXIF metadata to detecting and blurring faces and eyes with OpenCV Haar Cascades.

Why Metadata Is the Hidden Threat

Part 1: The Metadata Spoofing Engine

The Camera Database — Intentionally Vintage

GPS Presets — Middle of Nowhere

Converting GPS to EXIF Rationals

Spoof Profiles — Opinionated Presets

🔒 Hardening Security: Banishing `new Function`

💻 The Ultimate Failsafe: Reverting via `git reverse`

Problem 1: `setMaximumWidth` on the sidebar kills snap layouts

Problem 3: `restore_window_state` on Wayland

The `QScrollArea` double-delete crash

The `is_max_activated` Property

The `spoof_custom()` Function

Applying the Blur — The `gaussian_blur` Method

📋 Step 2: Interrogating the Clipboard (`ghost.db`)

🐛 Bug #1 — The Silent `fetch` Body Corruption