DEV Community: Alain Picard

ChromeFlash

Alain Picard — Tue, 07 Apr 2026 18:37:29 +0000

I built a Chrome extension to track where Chrome's RAM actually goes.
Chrome uses a lot of memory. We all know this. But when I actually tried to figure out which tabs were eating my RAM, I realized Chrome doesn't make it easy.

Task Manager gives you raw process IDs. chrome://memory-internals is a wall of text. Neither tells you "your 12 active tabs are using ~960 MB and your 2 YouTube tabs are using ~300 MB."

So I built ChromeFlash — a Manifest V3 extension that estimates Chrome's memory by category and gives you tools to reclaim it.

What it looks like

The popup shows a breakdown of Chrome's estimated RAM:

Browser Core — ~250 MB for Chrome's internal processes
Active Tabs — ~80 MB each
Pinned Tabs — ~50 MB each (lighter footprint)
Media Tabs — ~150 MB each (audio/video)
Suspended Tabs — ~1 MB each
Extensions — estimated overhead

A stacked color bar visualizes the proportions at a glance.

The honest caveat

Chrome's extension APIs in Manifest V3 don't expose per-tab memory. The chrome.processes API exists but is limited to dev channel. So these are estimates based on real-world averages — not exact measurements.

If you know a better approach, I'd genuinely love to hear it.

Tab suspension

The biggest win. Calling chrome.tabs.discard() on an inactive tab drops it from ~80 MB to ~1 MB. The tab stays in your tab bar, and when you click it, Chrome reloads it.

ChromeFlash lets you:

Suspend inactive tabs manually or on a timer (1–120 min)
Protect pinned tabs and tabs playing audio
Detect and close duplicate tabs

The auto-suspend runs via chrome.alarms since MV3 service workers can't use setInterval.

// The core of tab suspension
chrome.alarms.create('tab-audit', { periodInMinutes: 5 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'tab-audit') {
    const tabs = await chrome.tabs.query({});
    for (const tab of tabs) {
      if (shouldDiscard(tab)) {
        await chrome.tabs.discard(tab.id);
      }
    }
  }
});

Optimization profiles

Four presets that configure tab suspension + Chrome settings in one click:

Profile	Suspend	Services Off	Est. RAM Saved
Gaming	1 min	5 (DNS, spell, translate, autofill, search)	~500–2000 MB
Productivity	15 min	0	~200–600 MB
Battery Saver	5 min	4 (DNS, spell, translate, search)	~400–1500 MB
Privacy	30 min	7 (+ Topics, FLEDGE, Do Not Track ON)	~150–400 MB

Each profile shows the exact numbers and what changes — no vague "optimizes your browser" marketing.

Hidden settings via chrome.privacy

Chrome exposes several settings through the chrome.privacy API that most users never touch:

// Toggle DNS prefetching
chrome.privacy.network.networkPredictionEnabled.set({ value: false });

// Disable cloud spell check
chrome.privacy.services.spellingServiceEnabled.set({ value: false });

// Disable Topics API (ad tracking)
chrome.privacy.websites.topicsEnabled.set({ value: false });

// Disable FLEDGE / Protected Audiences
chrome.privacy.websites.fledgeEnabled.set({ value: false });

The extension exposes 8 of these as toggle switches. Disabling background services like spell check and translation reduces both network calls and CPU usage — not dramatically, but it adds up.

Chrome Flags guide

Chrome flags (chrome://flags) can meaningfully improve performance, but extensions can't modify them programmatically — Chrome blocks this for security reasons.

So ChromeFlash includes a curated database of 21 performance-relevant flags:

Rendering — GPU Rasterization, Zero-Copy, Skia Graphite
Network — QUIC Protocol, WebSocket over HTTP/2
Memory — Automatic Tab Discarding, High Efficiency Mode
JavaScript — V8 Sparkplug, V8 Maglev compilers
Loading — Back/Forward Cache, Parallel Downloads

Each flag shows a risk level, impact rating, and a button that opens it directly in chrome://flags/#flag-name.

Architecture

ChromeFlash/
  manifest.json
  src/
    background/service-worker.js    # Alarms, tab audit, memory pressure
    modules/
      tab-manager.js                # Suspend, discard, duplicates
      memory-optimizer.js           # Chrome RAM breakdown
      network-optimizer.js          # DNS prefetch toggle
      privacy-optimizer.js          # 8 privacy setting toggles
      performance-monitor.js        # CPU/memory stats, score
      profiles.js                   # 4 profiles with detailed stats
      flags-database.js             # 21 curated flags
      settings.js / storage.js      # Persistence
    popup/                          # Main UI
    pages/                          # Dashboard + Flags Guide

No build step. No framework. No bundler. ES modules loaded natively by Chrome. The entire extension is under 50 KB.

What I learned

MV3 service workers are stateless. Every alarm fires into a fresh context. You can't store state in module-level variables — it has to go in chrome.storage. This tripped me up early.

chrome.tabs.discard() is underrated. It's the single highest-impact thing an extension can do for memory. 85–92% reduction per tab with zero user friction — the tab just reloads when you click it.

chrome.privacy is powerful but underdiscovered. Most developers don't know you can programmatically toggle DNS prefetching, Topics API, or FLEDGE from an extension. The API surface is small but useful.

Flags can't be automated. I spent time looking for workarounds before accepting that chrome://flags is intentionally walled off. The guide approach works well enough.

Try it

ChromeFlash is free, open source, and collects zero data. No analytics, no remote servers, no tracking. Everything stays in chrome.storage.local

Why I Built a PGP Encryption Layer for Gmail (And Open-Sourced the Chrome Extension)

Alain Picard — Sun, 29 Mar 2026 21:43:22 +0000

Why I Built a PGP Encryption Layer for Gmail (And Open-Sourced the Chrome Extension)
I sent a contract over Gmail last year. Nothing fancy — just a freelance agreement with a client's banking details for direct deposit. Hit send, moved on with my day.

Three weeks later, that client got a phishing email referencing exact dollar amounts from our agreement. Someone had scraped it. Maybe from a compromised inbox, maybe from a server breach, maybe from something else entirely. The point is: the email sat on Google's servers in plaintext the entire time.

That's the moment I stopped assuming Gmail "encryption" meant what I thought it meant.

What Gmail Actually Encrypts (And What It Doesn't)
Here's the thing most developers don't realize until they dig into it. Gmail uses TLS — Transport Layer Security. Your email is encrypted while it's moving between servers. The little padlock icon in your browser? That's TLS doing its job.

But once your email lands on Google's servers, it's stored in a format Google can read. Their systems scan it for spam filtering. Smart Reply reads it to suggest responses. Ads used to be targeted based on email content (Google says they stopped, but the infrastructure to do it never went away).

TLS protects your email from a man-in-the-middle attack during transit. It does absolutely nothing if Google's servers get breached, if a government subpoena demands your data, or if a rogue employee decides to peek.

TLS encryption:
  You  ──[encrypted]──>  Google Server  ──[encrypted]──>  Recipient
                              │
                         [plaintext]
                         Google can read it here.

End-to-end encryption (PGP):
  You  ──[encrypted]──>  Google Server  ──[encrypted]──>  Recipient
                              │
                         [still encrypted]
                         Nobody reads it. Not even Google.

That gap between "encrypted in transit" and "actually private" is what kept bugging me.

So I Built GmailKrypt
GmailKrypt is a Chrome extension that bolts PGP encryption directly onto Gmail's interface. No separate app. No copy-pasting into a terminal. You compose your email like you normally would, click encrypt, and send.

The whole thing runs on OpenPGP.js — the same standard that's been protecting communications since Phil Zimmermann released PGP back in 1991. Except now you don't need to touch a command line to use it.

How It Actually Works in Practice
You install the extension. It generates a key pair for you — a public key and a private key. Your private key stays in Chrome's local storage. It never hits a server. Not mine. Not Google's. Nobody's.

When you want to send an encrypted email:

Compose your email in Gmail like normal
Click the GmailKrypt encrypt button in the toolbar
The extension encrypts the message body using the recipient's public key
Gmail sends what looks like a block of gibberish
What your recipient sees before decryption:

-----BEGIN PGP MESSAGE-----

hQEMA7Vj8+t5rZ7aAQf+N2M7j8K2vF9xD3nE1yP4mR6sQ
8tA5bC7dF0gH3iK6lN9oR2sU5vX8yB1cE4fG7hJ0kL3mO
6pS9tW2xA5zC8dF1gI4jL7nQ0rU3vY6aD9eH2iK5lN8oR1
=x7Fp
-----END PGP MESSAGE-----

If the recipient has GmailKrypt installed, the extension detects the PGP block and decrypts it automatically. If they use any other PGP tool — Thunderbird, GPG Suite, Kleopatra — it works just the same. That's the beauty of open standards.

The Architecture (For the Nerds)
I know this is dev.to, so let's get into the guts of it.

Zero-knowledge design. The extension uses chrome.storage.local for private keys. They're sandboxed by Chrome's extension security model. The API server I run at api.gmailkrypt.com handles licensing and Stripe subscriptions — it never touches keys, never sees message content, never stores anything it shouldn't.

Content script injection. GmailKrypt injects into Gmail's DOM to add the encrypt/decrypt toolbar. It listens for compose window events and intercepts the message body before send. All the crypto happens client-side through OpenPGP.js.

Key exchange. This was the UX challenge. PGP has always been powerful but painful to set up. GmailKrypt lets you attach your public key to any email with a single button click. The recipient imports it, sends theirs back, and you're set. First exchange takes maybe 30 seconds.

// Simplified flow
const { privateKey, publicKey } = await openpgp.generateKey({
  type: 'ecc',
  curve: 'curve25519',
  userIDs: [{ email: 'you@gmail.com' }]
});

// Encrypt
const encrypted = await openpgp.encrypt({
  message: await openpgp.createMessage({ text: emailBody }),
  encryptionKeys: recipientPublicKey,
  signingKeys: myPrivateKey  // also signs it
});

Digital signatures come free with PGP. Every encrypted email is also signed, so the recipient can verify it actually came from you and wasn't tampered with in transit. Authentication, integrity, and non-repudiation — all in one operation.

Who Is This Actually For?
I built this scratching my own itch, but it turns out a lot of people have the same itch.

Freelancers and contractors sending invoices with bank details over email. Lawyers who have attorney-client privilege to protect but keep using Gmail because their firm is on Google Workspace. Journalists communicating with sources — Snowden used PGP with Glenn Greenwald for a reason. Healthcare folks who technically violate HIPAA every time they email patient info through standard Gmail. Developers who want to practice what they preach about security.

Or honestly? Anyone who's ever sent a password, a credit card number, or a social security number over email and felt that little twinge of "I probably shouldn't have done that."

The Google Workspace Elephant in the Room
Google does offer something called S/MIME encryption for Workspace Enterprise customers. It costs significantly more than standard Workspace, requires your IT admin to manage certificates, and only works between users whose organizations have both set up S/MIME correctly.

For the other 1.8 billion Gmail users? Nothing.

That's not an oversight. Google's business model fundamentally conflicts with end-to-end encryption. If they can't read your emails, they can't power Smart Compose, can't filter spam as effectively, can't build the profile that drives their ad ecosystem. I'm not saying that's evil — it's just the reality of a free product.

GmailKrypt sidesteps all of that. It works with free Gmail, Google Workspace, any plan. You're adding encryption on top of Gmail, not asking Google to provide it.

Free Tier, Pro Tier, No BS
The extension is free to use — you get 5 encryptions per day, which covers most people's needs. If you're sending encrypted emails all day (lawyers, journalists, security teams), the Pro plan is $4.99/month for unlimited everything.

I thought long and hard about pricing. I wanted it accessible enough that a student or activist could use it without paying, but sustainable enough that I can keep maintaining it. Five free encryptions felt like the right balance.

Try It, Break It, Tell Me What's Wrong
You can grab GmailKrypt from the Chrome Web Store or check out the landing page at gmailkrypt.com.

If you're the type who reads source code before installing extensions (and you should be), the extension runs entirely client-side for all crypto operations. The only network calls are to the license API for Pro features.

I'm genuinely curious what this community thinks. Is PGP email encryption still relevant in 2026? Are there UX improvements that would make you actually use this? Did I miss something obvious in the architecture?

Drop a comment. I read all of them.

I built Google Keep for Developers — here's why

Alain Picard — Tue, 24 Mar 2026 21:31:40 +0000

Every developer I know has the same problem: code snippets scattered across 15 different places.

A regex you wrote six months ago? Somewhere in a Slack DM. That Docker Compose template you always reuse? Maybe in a Notion page. The SQL query that saved you three hours last quarter? Lost in a .txt file called notes_final_v2.txt.

I tried everything — GitHub Gists, Notion, Apple Notes, random text files, bookmarked Stack Overflow answers. None of them felt right. Gists are too heavy for a quick snippet. Notion doesn't understand code. Google Keep is perfect for quick capture, but try pasting a 20-line function in there — no syntax highlighting, no Markdown, no structure.

So I built CodesKeep — Google Keep, but designed from the ground up for developers.

What it does

CodesKeep is a web app for saving, organizing, and finding your code snippets and Markdown notes. Think of it as the simplicity of Google Keep meets the developer-awareness of a code editor.

Here's what makes it different:

Markdown & code-first — full Markdown support with syntax highlighting out of the box. Your notes look like they belong in a README, not a sticky note.
Instant capture — open it, paste your snippet, tag it, done. No friction, no folder hierarchies to navigate.
Search that actually works — find that snippet by language, tag, keyword, or content. No more digging through 50 untitled notes.
Built for reuse — snippets are meant to be grabbed and dropped into your project. Copy with one click.

Why I built it

I'm an Android developer by day. I work in Kotlin, Jetpack Compose, and a bunch of other tools — and I was constantly losing useful code. Not big libraries or modules, but the small stuff:

A Compose modifier chain I always forget
Environment variable configs for different projects
Bash one-liners for Docker cleanup
API response formats I reference weekly

These are too small for a repo, too important for a sticky note, and too code-heavy for a regular notes app.

I realized what I actually wanted was Google Keep with syntax highlighting and Markdown. That's it. Not a full IDE, not a documentation platform, not a second brain. Just a fast, clean place to keep code notes.

The stack

For those curious about the technical side:

Frontend: Modern web app, responsive and fast
Focus: Speed of capture and retrieval — the two things that matter most for a snippet tool

I intentionally kept the feature set tight. Every snippet manager I tried suffered from feature bloat — team workspaces, presentation modes, social sharing, marketplace integrations. Those are fine for some products, but they slow down the one thing I actually need: save this code now, find it later.

What's next

I'm actively building and would love feedback from the community. Some things on the roadmap:

Browser extension — snip code blocks directly from Stack Overflow, GitHub, or docs
VS Code / JetBrains integration — save and insert snippets without leaving your editor
Team sharing — share collections with your team (without the bloat)
API access — for the automation-minded among us

Try it out

👉 www.codeskeep.com

It's live and ready to use. I'd genuinely appreciate any feedback — what works, what's missing, what would make you switch from your current setup.

Drop a comment below or reach out — I read everything.

If you've ever lost a code snippet you spent 30 minutes writing, this is for you.