Category: Tools & Setup

A few weeks ago I watched a teammate generate a “secure” password with a little snippet he’d written years ago. It looked fine — 16 characters, mixed case, symbols. Then I asked him what was seeding it. He shrugged: Math.random(). That password had far less real randomness than it looked like, and neither of us could tell by staring at it. That’s the whole problem with password strength — the weakness is invisible.

So I want to walk through what actually makes a generated password strong, using PassForge, a browser-only password generator I use. It runs entirely client-side, and because the whole thing is a single HTML file with the logic in plain view, it’s a good way to show the math instead of hand-waving about it.

Why Math.random() is quietly broken for passwords

JavaScript’s Math.random() is a pseudo-random number generator. It’s fast, it’s fine for shuffling a card animation, and it is not cryptographically secure. The output is deterministic given the internal state, and in V8 that state is only 128 bits seeded in a way that was never meant to resist an attacker. If someone can observe a few outputs, they can predict the rest.

The fix is the Web Crypto API. Here’s exactly how PassForge pulls a random integer — no library, just the browser’s CSPRNG:

function cryptoRandInt(max) {
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return arr[0] % max;
}

crypto.getRandomValues is backed by the operating system’s secure random source. That’s the same class of entropy your TLS handshakes use. The % max introduces a tiny modulo bias when max doesn’t evenly divide 2³², but for a 26- or 33-character pool that bias is negligible — we’re talking a fraction of a fraction of a bit. For a password generator, this is the correct baseline, and it’s the first thing I check before trusting any generator.

Entropy is the only number that matters

“Strong password” is a marketing phrase. Entropy in bits is the actual measurement. It answers one question: how many guesses, on average, before an attacker lands on your password?

For a random character password, entropy is length × log2(poolSize). PassForge computes the pool the honest way — by inspecting which character classes are actually present:

function calcEntropy(password) {
  let poolSize = 0;
  if (/[a-z]/.test(password)) poolSize += 26;
  if (/[A-Z]/.test(password)) poolSize += 26;
  if (/[0-9]/.test(password)) poolSize += 10;
  if (/[^a-zA-Z0-9]/.test(password)) poolSize += 33;
  return Math.floor(password.length * Math.log2(poolSize));
}

So a 16-character password using all four classes has a pool of 95, and log2(95) ≈ 6.57 bits per character — about 105 bits total. Drop the symbols and you’re at a pool of 62, roughly 95 bits. That 10-bit gap is a factor of 1,024 in guessing difficulty, from one design choice most people never think about.

Passphrases: fewer characters, more entropy per word

Here’s the part that surprises people. A four-word passphrase like correct-horse-battery-staple feels weaker than Kx9$mQ2!, but it usually isn’t. PassForge uses the EFF short wordlist — 1,296 words — and each randomly chosen word contributes log2(1296) ≈ 10.34 bits:

function passphraseEntropy(wordCount, addNumber, addSymbol) {
  let bits = wordCount * Math.log2(WORDS.length);
  if (addNumber) bits += Math.log2(100);
  if (addSymbol) bits += Math.log2(8);
  return Math.floor(bits);
}

Six words gives you about 62 bits before any decoration — and it’s a string you can actually retype from memory when a password manager isn’t handy. The key word is randomly. If you pick the words yourself, the entropy math collapses, because human word choice is predictable. The security comes entirely from crypto.getRandomValues picking the index for you.

The crack-time number, and its honest assumptions

PassForge turns entropy into a human-readable estimate, and I like that it states its threat model in the code instead of hiding it:

function crackTimeStr(bits) {
  // Assume 10 billion guesses/sec (modern GPU cluster)
  const guesses = Math.pow(2, bits);
  const seconds = guesses / 1e10;
  ...
}

Ten billion guesses per second is a reasonable stand-in for an offline attack against a fast hash. That assumption matters. Against a properly slow hash like bcrypt or Argon2, the attacker’s rate drops by orders of magnitude, so the tool is being conservative — it’s modeling the worst realistic case, not the best. I trust a calculator that’s pessimistic on my behalf more than one that shows “3 trillion years” for a mediocre password.

At 10 billion guesses/sec, a 60-bit password falls in a few years, an 80-bit password holds for millions of years, and once you clear 128 bits you’re past “longer than the age of the universe.” That’s why the target isn’t a length — it’s a bit count.

The small touches that show someone thought about it

Two details I appreciated. First, the ambiguous-character filter: O0lI1| get stripped when you ask for it, so you never squint at a password wondering if that’s a one or a lowercase L. Second, the generator guarantees at least one character from each selected class and then shuffles the result with a crypto-backed Fisher-Yates, so the guaranteed characters don’t always land in front. Skipping that shuffle is a classic subtle bug that leaks a little entropy and makes output patterns predictable.

Why browser-only is the right call here

A password generator that sends anything over the network is a contradiction. PassForge is one static HTML file — you can open the page, hit “save,” disconnect from Wi-Fi, and it keeps working. Nothing to install, nothing phoning home, and you can read the entire source before you trust it. That’s the same reason I use its siblings for other one-off tasks: HashForge for hashing and Base64Lab for encoding, all client-side. I wrote separately about why I stopped uploading files to free online tools — the logic applies double to secrets.

If you’d rather not trust any web page with generation at all, a hardware option is the cleanest boundary: I keep a YubiKey 5 NFC for the accounts that matter, and for storing what I generate a manager like 1Password is worth the price. Full disclosure: those are affiliate links.

The takeaway is simpler than the math looks: check that your generator uses crypto.getRandomValues, aim for 80+ bits of entropy, and let the tool pick the randomness — never your own brain. Try PassForge here and watch the entropy number move as you change the settings.

---

Join https://t.me/alphasignal822 for free market intelligence.

A friend sent me a photo of their new apartment last year and asked me to guess the neighborhood. I opened the JPEG in a terminal, ran exiftool, and read back their street address to two decimal places of latitude. They had never posted the location. The phone did it for them.

That is the whole problem PixelStrip exists to fix. Most photos coming off a modern phone carry a GPS block inside the file — the exact coordinates where the shutter fired, down to a few meters. Share that JPEG anywhere that doesn’t re-encode it, and you’re publishing your home, your kid’s school, your office desk. This post is about what’s actually in that metadata, which platforms strip it and which don’t, and why I built a browser-only tool instead of telling people to install desktop software.

What’s actually inside the file

EXIF (Exchangeable Image File Format) is a block of tags glued into the JPEG right after the start-of-image marker. It was designed for camera settings — shutter speed, ISO, focal length. Useful stuff. But the spec also carries an entire GPS sub-directory, and phones fill it in by default.

Here’s what a single photo off an iPhone typically hands over:

GPS Latitude    : 37 deg 46' 29.88" N
GPS Longitude   : 122 deg 25' 9.84" W
GPS Altitude    : 14.2 m Above Sea Level
Create Date     : 2026:07:04 18:32:11
Make            : Apple
Model           : iPhone 15 Pro
Software        : 17.5.1

That latitude/longitude pair drops a pin within about 5 meters. The timestamp tells anyone reading it when you were standing there. The device model and OS version are a nice bonus for anyone building a fingerprint of you. None of it is visible when you look at the picture. It rides along silently.

If you want the gory byte-level details of how those coordinates get packed into IFD structures, I wrote a separate teardown: How EXIF GPS Data Is Stored in a JPEG. The short version: GPS coordinates are stored as three rational numbers (degrees, minutes, seconds), each a pair of 32-bit integers, referenced by an offset pointer in the main tag table. It’s a tidy little format, which is exactly why it’s easy to both read and remove.

The “but platforms strip it” myth

The common reassurance is that social networks scrub metadata on upload. Some do. Many don’t, and the behavior is inconsistent enough that I don’t trust any of it:

• Facebook, Instagram, Twitter/X: re-encode images and drop EXIF. Generally safe — but they replace it with their own tracking, and the re-encode wrecks quality.
• Discord: keeps full EXIF on direct image attachments. That coordinate block ships straight through.
• Slack: preserves the original file for downloads.
• Email attachments: untouched. Whatever your camera wrote is what lands in the recipient’s inbox.
• Your own website / self-hosted gallery: serves the raw file unless you strip it yourself.
• Cloud storage share links (Dropbox, Drive): hand over the original bytes.

The failure mode that bit my friend was a real-estate listing tool that just re-served the uploaded JPEGs. Coordinates intact. So “the platform handles it” is not a plan. Stripping at the source is.

Why browser-only, and why that matters here

The obvious fix is exiftool, which is excellent. But telling a non-technical person to install a Perl utility and run exiftool -all= photo.jpg from a terminal is a non-starter. The alternatives most people reach for are worse:

• Online EXIF removers: you upload your geotagged photo to some stranger’s server to have the location removed. Read that sentence again. You just handed the coordinates to exactly the party you were hiding them from.
• Desktop apps: fine, but overkill for “clean these 8 photos before I text them.”
• Phone share-sheet toggles: iOS has a “Remove Location” option buried in the share sheet’s Options menu. It works, but only for location, only on Apple’s terms, and most people never find it.

PixelStrip runs entirely in your browser. The photo never leaves your device — there’s no upload, no server round-trip, no log file with your coordinates in it. When you drop a JPEG in, the JavaScript reads the file with the FileReader API, walks the EXIF markers, and rewrites the file without the metadata block, all client-side. You can literally pull your network cable and it still works.

The mechanism is simple enough to describe in a paragraph. A JPEG is a series of segments, each marked by 0xFF followed by a marker byte. EXIF lives in the APP1 segment (0xFFE1). To strip it, you parse the segment list, drop APP1 (and optionally APP0, XMP, and any color-profile junk you don’t need), and re-concatenate the rest. The image pixels sit in the scan data, untouched — so unlike the social-network approach, there’s zero quality loss. No re-encode, no recompression artifacts. Same pixels, minus the tracking.

How I actually use it

Three cases come up for me weekly:

1. Before texting photos of anything at home. Package on the porch, a receipt, my desk setup — all geotagged with my address. Drop, strip, send.
2. Before uploading to my own blog. WordPress will happily serve the original file. I strip first so a right-click-save doesn’t leak where I live.
3. Selling stuff online. Marketplace photos of your living room, tagged with your home coordinates, sent to strangers. Strip every one.

You can try it here: PixelStrip. Drag a photo in, download the clean copy, verify with exiftool if you’re paranoid (I was — the GPS block is gone, the pixels are byte-identical in the scan segment).

If you shoot a lot, fix it at the camera

Stripping after the fact works, but the cleaner move for anything sensitive is to not write the coordinates in the first place. On iOS: Settings > Privacy & Security > Location Services > Camera > set to Never. On Android it’s under the camera app’s own settings, usually “Location tags” or “Save location.” You lose the nice “photos on a map” feature, which is the tradeoff.

For anyone doing serious photography who still wants a reliable offline scrub across hundreds of files, a small NAS or even a Raspberry Pi running a scheduled exiftool job on an import folder is the setup I’d build. If you’re speccing a cheap always-on box for that kind of home-automation chore, the Raspberry Pi 5 (8GB) is what I’d grab, paired with a decent Samsung microSD card so the write-heavy batch jobs don’t chew through cheap flash. Full disclosure: those are affiliate links — I only link gear I actually run.

But for the 90% case — a few photos, right now, before you hit send — a browser tab that never phones home is the right tool. That’s the whole pitch.

---

Related reading on this site: the byte-level EXIF teardown and why I stopped pasting JWTs into online decoders — same browser-only, nothing-leaves-your-machine principle.

Join https://t.me/alphasignal822 for free market intelligence.

A single line of validation code once took down half of Cloudflare. On July 2, 2019, a regular expression pushed to their WAF spiked CPU to 100% across their global network and knocked a chunk of the internet offline for about 27 minutes. The regex looked harmless. It contained a pattern that backtracks exponentially, and one crafted request was enough to melt a core.

I keep RegexLab open in a pinned tab specifically to catch this class of bug before it ships. It’s a browser-only regex tester, which matters here for a reason most people miss: when you’re testing a pattern that can hang for 13 seconds, you really don’t want that pattern running on someone else’s server. In RegexLab it runs on your machine, in the same V8 engine your Node backend uses, so the timing you see is the timing you’ll get in production.

What catastrophic backtracking actually is

Most regex engines (JavaScript, Python’s re, Java, PCRE) use backtracking. When a pattern can match the same input more than one way, the engine tries one path, and if that fails, it walks back and tries another. Usually that’s fine. The problem starts when the number of possible paths grows exponentially with input length.

The textbook example is a quantifier inside a quantifier:

/^(a+)+$/

Feed it a string of a characters followed by one b. The b guarantees the match fails at the end, but before the engine gives up, it tries every way to split those as between the inner a+ and the outer +. That’s 2^n splits. Each extra character doubles the work.

I benchmarked it on my machine (Node 24, plain V8 — same engine Chrome runs) with /^(a+)+$/ against n copies of “a” plus a trailing “b”:

n=15   0.39 ms
n=20   10.6 ms
n=22   42.3 ms
n=24   169 ms
n=26   585 ms
n=28   2,516 ms

Read that again. Going from 26 to 28 characters — two bytes — took the match from half a second to two and a half seconds. At n=32 you’re looking at ~40 seconds for one call. An attacker doesn’t need a botnet. They need one text field and a 32-character string.

The version that bites real apps

Nobody writes /^(a+)+$/ on purpose. The dangerous ones look reasonable. Here’s a pattern shaped like a thousand email and username validators I’ve seen in the wild:

/^([a-zA-Z0-9]+)*@/

Looks like it’s checking for alphanumeric characters before an @. It also has a + nested inside a *, which is the same exponential trap wearing a nicer suit. I fed it a long run of letters with no @ so the match fails:

n=20   13 ms
n=25   434 ms
n=28   3,303 ms
n=30   13,225 ms

Thirty characters. Thirteen seconds. If that regex sits on a login or signup endpoint, one request ties up a worker for 13 seconds. Send twenty of them and your event loop is done. This is a denial-of-service that ships as “input validation.”

Spotting it before it ships

The tell is any place where two quantifiers can fight over the same characters. Watch for these shapes:

• (x+)+ — nested quantifiers, the classic
• (x*)* — same idea
• (x+)* and (x*)+ — mixed, still exponential
• (a|a)+ or (a|ab)+ — alternation where branches overlap
• (\s+)+, (\w+)* — the real-world disguises

The fix is almost always to remove the redundancy. The outer quantifier in ([a-zA-Z0-9]+)* does nothing the inner one can’t — [a-zA-Z0-9]+ already matches one or more characters. Drop the wrapper:

/^[a-zA-Z0-9]+@/

I reran the safe rewrite /^a+$/ against inputs up to 100,000 characters:

n=28       0.066 ms
n=1,000    0.010 ms
n=100,000  0.216 ms

Linear time. A hundred thousand characters finishes faster than the evil version handles 20. That’s the whole point — the pattern that looks more permissive is thousands of times faster because there’s only one way to match.

Why I test these in the browser, not on a server

Here’s the part that ties back to how RegexLab is built. To confirm a regex is vulnerable, you have to actually run it against a malicious input and watch it hang. If you do that in an online tester that processes patterns server-side, you’re either (a) DoS-ing their box, which is rude, or (b) hitting a timeout that hides the problem from you.

RegexLab runs the match with the native RegExp engine right in your tab. Nothing is uploaded. Your patterns — which for a lot of us encode business logic, internal formats, sometimes secrets baked into validation rules — never leave the machine. When a match hangs, it hangs your tab, which is exactly the feedback you want. You can feel the 3-second pause and know you found something. I wrote more about why I stopped trusting server-side dev tools with sensitive input in this piece on pasting data into online tools.

My workflow in RegexLab is simple:

1. Paste the pattern.
2. Add a normal test case — confirm it matches what it should.
3. Add an evil case: a long run of the character class the pattern repeats, ending with something that forces a failed match.
4. If the result is instant, you’re probably fine. If the tab stalls, you have a ReDoS.

The multi-case runner is handy here because you can keep the “good” input and the “attack” input side by side and re-run both after every edit to the pattern. I keep a small library of attack strings — 30 identical chars plus a mismatch — for exactly this. For a broader take on using the tool for security work, I wrote up regex patterns that catch real security bugs.

The structural fixes worth knowing

Rewriting to remove nested quantifiers covers most cases, but two other tools help:

Atomic groups and possessive quantifiers. These tell the engine “match this and never give it back,” which kills the backtracking. JavaScript didn’t support them for years, but modern V8 (Node 18+ / recent Chrome) does via (?>...) and a++. So /^(?>a+)+$/ won’t blow up. Check your runtime before relying on it — if you’re on an older engine it’ll throw a syntax error.

Switch engines for untrusted input. Rust’s regex crate and Go’s RE2 use a finite-automaton approach with no backtracking at all, so ReDoS is impossible by construction. The tradeoff is they drop backreferences and lookaround. If you’re validating user input at scale, that tradeoff is usually worth it. Google built RE2 for exactly this reason after backtracking engines kept taking down services.

If you want to go deep on how these engines actually differ, Jeffrey Friedl’s Mastering Regular Expressions is still the reference — it’s the book that made the backtracking-vs-automaton distinction click for me (affiliate link, full disclosure). Russ Cox’s free regexp article series covers the RE2 side if you prefer the theory online.

Test the regex you shipped last month

Pull up your codebase and grep for )+, )*, and any validation regex on an input field. Drop each one into RegexLab, hand it 30 repeated characters ending in a mismatch, and watch the clock. It takes about ten seconds per pattern, it runs entirely in your browser, and it might save you from a 2 AM page when someone finds the same field an attacker would.

The Cloudflare outage cost real money and made global news. The bug was one unbounded quantifier next to another. That’s a five-second check you can run right now.

---

Join https://t.me/alphasignal822 for free market intelligence.

Last week I wanted to prove a point to a friend who insisted his vacation photos were “fine to post.” So I opened one of his JPEGs in a hex editor, scrolled about 40 bytes in, and read his hotel’s GPS coordinates straight off the screen — no tools, no library, just the raw bytes. That’s the thing nobody tells you about EXIF: it isn’t encrypted, hashed, or hidden. It’s sitting near the front of almost every photo your phone takes, in a format you can decode by hand once you know the layout. This post is the byte-level teardown, and at the end I’ll show why PixelStrip removes that data without touching a single pixel.

A JPEG is just a stream of markers

Every JPEG starts with two bytes: FF D8, the Start Of Image marker. After that the file is a sequence of segments, and every segment begins with FF followed by a marker byte. The one we care about is FF E1 — that’s APP1, where EXIF lives.

Here’s the front of a real photo, annotated:

FF D8              SOI (start of image)
FF E1              APP1 marker  <- EXIF starts here
00 84              segment length = 0x0084 = 132 bytes (big-endian, always)
45 78 69 66 00 00  "Exif\0\0"
49 49              "II" = Intel / little-endian byte order
2A 00              42, the TIFF magic number
08 00 00 00        offset to first IFD = 8

Two details trip people up here. First, that segment-length field is always big-endian, because it’s part of the JPEG container, not the EXIF payload. Second, the byte order flag (II for little-endian, MM for big-endian) only applies to everything after the Exif\0\0 header. From that point on, every multi-byte number flips based on those two bytes.

The TIFF header and IFD entries

What follows Exif\0\0 is a tiny TIFF file. All internal offsets are measured from the start of the byte-order mark — not the start of the file. Forget that and every pointer you read lands in the wrong place. I’ve debugged this exact off-by-six error more times than I’d like to admit.

The 4-byte offset (here 08 00 00 00 = 8) points to the first Image File Directory, or IFD0. An IFD is dead simple:

• 2 bytes: how many entries follow
• 12 bytes per entry
• 4 bytes at the end: offset to the next IFD (0 means stop)

Each 12-byte entry breaks down as: a 2-byte tag ID, a 2-byte data type, a 4-byte value count, and a 4-byte field that holds either the value itself (if it fits in 4 bytes) or an offset to where the value actually lives. GPS coordinates don’t fit in 4 bytes, so they’re always stored by offset.

The tag we hunt for in IFD0 is 0x8825 — the GPS IFD pointer. Its value is an offset to a separate sub-directory holding the location tags. Jump there and you find the payload.

Decoding latitude by hand

The GPS sub-IFD uses a handful of tags. The important ones:

• 0x0001 GPSLatitudeRef — ASCII “N” or “S”
• 0x0002 GPSLatitude — three RATIONAL values: degrees, minutes, seconds
• 0x0003 GPSLongitudeRef — “E” or “W”
• 0x0004 GPSLongitude — three more RATIONALs

A RATIONAL is two 4-byte unsigned integers: a numerator followed by a denominator. So latitude is three of them — 24 bytes total. Here’s the actual block from that photo, little-endian:

25 00 00 00  01 00 00 00   ->  37 / 1   = 37 degrees
2E 00 00 00  01 00 00 00   ->  46 / 1   = 46 minutes
C4 0B 00 00  64 00 00 00   ->  3012 / 100 = 30.12 seconds

Convert degrees-minutes-seconds to decimal: 37 + 46/60 + 30.12/3600 = 37.7750° N. Pair that with the longitude block and you have a point accurate to roughly three meters. That’s precise enough to land on a specific building. My friend went quiet after I read his back.

A 40-line parser in the browser

You don’t need a library to do this. Browser DataView reads typed values out of an ArrayBuffer with explicit endianness, which is exactly what EXIF needs. Here’s the core of finding the APP1 segment and its byte order:

function findExif(view) {
  let offset = 2; // skip the FF D8 SOI
  while (offset < view.byteLength) {
    if (view.getUint8(offset) !== 0xFF) break;
    const marker = view.getUint8(offset + 1);
    const size = view.getUint16(offset + 2); // big-endian on purpose
    if (marker === 0xE1) {
      const tiff = offset + 10;            // skip marker, length, "Exif\0\0"
      const le = view.getUint16(tiff) === 0x4949; // "II"
      return { tiff, littleEndian: le, app1Start: offset, size };
    }
    offset += 2 + size; // jump to the next segment
  }
  return null;
}

Note that getUint16 defaults to big-endian, which is correct for the JPEG segment length. Once you have the littleEndian flag, you pass it to every read inside the TIFF block. Reading a RATIONAL is two reads and a divide:

function readRational(view, pos, le) {
  return view.getUint32(pos, le) / view.getUint32(pos + 4, le);
}

That’s the whole trick. Walk the IFD entries, find tag 0x8825, jump to the GPS sub-IFD, pull the latitude and longitude rationals, and apply the N/S/E/W sign. About 40 lines, no dependencies, runs offline.

Two ways to strip it — and why they differ

Now the part that actually matters. There are two ways to remove this metadata, and they are not equal.

Re-encode the whole image. Draw the photo onto a <canvas> and call toBlob(). The new file is built from raw pixels, so it carries no EXIF at all. Clean — but every pixel gets recompressed, which means slight quality loss and a completely different byte layout. That’s the approach my QuickShrink compressor takes, and I wrote up the mechanics in how browser image compression actually works. Good when you also want a smaller file.

Splice out the segment. If all you want is to delete the metadata and keep the image untouched, you cut the APP1 segment out of the byte stream and leave everything else identical:

const out = new Uint8Array(bytes.byteLength - (2 + size));
out.set(bytes.subarray(0, app1Start));
out.set(bytes.subarray(app1Start + 2 + size), app1Start);

The pixels stay bit-for-bit identical. No recompression, no quality loss, no visible change — just the location data gone. That’s what PixelStrip does.

One gotcha worth knowing: a single JPEG can carry more than one metadata block. EXIF lives in APP1, but XMP often rides in a second APP1, Photoshop data sits in APP13, and the EXIF thumbnail in IFD1 can hold its own copy of the GPS tags. A parser that removes only the first APP1 it sees will miss the rest. A real stripper loops over every APPn segment, which is the unglamorous part most “remove EXIF” snippets skip.

What to actually do with this

If you only remember one rule: platforms are inconsistent. Twitter and iMessage scrub metadata on upload; Discord, email attachments, Slack file shares, and most forums pass it through untouched. Assume the worst and clean photos before they leave your machine.

For a one-click clean that keeps your image quality intact, drop the photo into PixelStrip — it runs entirely in your browser, so the file never uploads anywhere, and it surgically removes EXIF, GPS, and XMP without recompressing. If you want the privacy reasoning rather than the byte layout, I covered that in how to strip EXIF data before sharing. The rest of the browser tools follow the same no-upload rule.

If you want to go deeper than a hex editor, file-format forensics books cover exactly this kind of byte-level metadata extraction across image, document, and filesystem formats — a solid digital forensics reference is what I keep on the shelf for the weird edge cases (full disclosure: Amazon affiliate link). It’s the difference between guessing at an offset and knowing why it’s there.

---

Join https://t.me/alphasignal822 for free market intelligence.