DEV Community: glensum

Your screenshot tool is the leak — doing redaction entirely client-side

glensum — Fri, 16 Oct 2026 08:23:32 +0000

The most common way people redact a screenshot is still this:

Take the screenshot.
Search "blur image online".
Upload it to the first result.
Blur the part that matters, download, paste into Slack.

Step 3 is the problem. You just handed an unredacted screenshot — session tokens, customer emails, API keys, production data — to a website you found ninety seconds ago. The blur happens after the upload, and the "delete" button on that page deletes your copy, not theirs.

It's a small, boring leak, and it happens thousands of times a day, because the tool that solves the aesthetic problem (make this text unreadable) creates a security problem (it made a copy first).

The rule I'd propose

Redaction must happen on the machine the screenshot was taken on, before the image goes anywhere. If the pixels reaching any network request are already covered, the rest of the pipeline stops mattering — you can paste it into a chat, a ticket, a bug report, and the sensitive part isn't in the file.

That's the whole design constraint. Everything below falls out of taking it seriously.

Anatomy of a leak, in the browser

A screenshot in a browser is a compositor output. The extension API is chrome.tabs.captureVisibleTab, which returns a data URL of the visible viewport:

const dataUrl = await chrome.tabs.captureVisibleTab({ format: 'png' });

At this point you hold a faithful copy of everything on screen, including the parts nobody wants in a public issue: the token in the address bar, the Authorization header value in some debug panel, the customer list scrolled halfway down.

The naive version of a redaction feature is a UI on top of that image. The important version redacts before you decide to keep the file — i.e. the extension should never write the raw capture anywhere durable.

What "covered" should actually mean

Two choices worth being deliberate about:

Blur vs solid fill. Blur looks more polite, but for text it's a lossy encoding, not a one-way function. Low-radius blurs of high-contrast text (a monospace token on a dark terminal, for instance) have been reconstructed with deconvolution, and text heights are highly constrained, which shrinks the search space. For secrets, use an opaque fill. Blur is for faces and plates, where the content is continuous, not discrete.

Redraw vs overlay. Overlaying a rectangle in an HTML layer is easy and completely useless — the underlying pixels are still in the export. You need to composite (draw the image, then draw the fill on top) and export the re-encoded result:

const off = new OffscreenCanvas(w, h);
const ctx = off.getContext('2d');
ctx.drawImage(imgBitmap, 0, 0);                 // the capture
ctx.fillStyle = '#111';
ctx.fillRect(x, y, w0, h0);                     // irreversible at this point
const blob = await off.convertToBlob({ type: 'image/png' });

Everything downstream operates on that blob. If a cover is wrong, the user redraws; there is no "uncover" and no original in the payload.

The part that actually reduces user error: pre-detection

Manual redaction fails the same way manual everything fails — people miss one spot, usually the boring one. So the useful feature isn't a nicer brush; it's candidate detection before the user looks:

DOM-matched regions. Elements with type="password", autocomplete="cc-number", inputmode="numeric", or a name/id matching /token|secret|api[-_]?key|otp|ssn/i. The element's bounding box maps directly to image coordinates via getBoundingClientRect() plus scroll offsets.
Text-pattern regions. Run a small regex set over the visible text nodes and highlight matches: JWT shape (eyJ[A-Za-z0-9_-]{10,}\.), sk-/ghp_/AKIA prefixes, IBAN-ish and card-number-ish digit runs, private-key headers.
Structural guesses. Terminal/console panes, .env-looking blocks, admin tables — worth flagging, not auto-covering.

The output should be a proposed set of covers the user can delete in one click. Auto-covering without review is its own failure mode: over-covering quietly destroys the screenshot's purpose, and the user then posts a useless image or, worse, turns the feature off.

Where detection honestly fails

I'd rather list the limits than imply a guarantee:

Canvas / WebGL / video. If the secret is rendered into a canvas or a <video> frame, there is no DOM node and no text node. Regex detection sees nothing. Only a manual cover catches these.
Images of text. A screenshot of a screenshot, a scanned invoice, a chart with labelled series. No OCR, no detection.
Anything virtualised. Table cells recycled by a virtual list can be measured before or after they exist in the DOM, depending on scroll timing. Off-by-one-row covers are a real bug class.
Shadow DOM. Closed shadow roots are invisible to the traversal; you get a bounding box with no children to inspect.

So the honest product claim is "detection reduces misses; the manual cover is still the guarantee." Any tool claiming otherwise is describing a best case.

What this means for the architecture

Client-side redaction has one more consequence, and it's the reason I'd pick this shape again: there's nothing to operate. No upload endpoint, no object storage, no retention policy to write, no "we delete after 24h" claim to make and be audited on. The security property is structural rather than promised.

For a small tool that's the difference between a feature you can ship and a small compliance project. The trade is that you can't do the heavy stuff on a server — no models, no OCR on the secret-detection step, no history sync. In exchange, the failure mode of your infrastructure is "nothing happens," which is the failure mode I want.

I built this into a small extension — Veilshot. Pricing, stated plainly: the free tier does the manual covers (no account, no network requests at all — that's checked in CI on every build, not just promised in a policy); Pro is a one-off $19 for pattern detection, keyword rules and per-site rules, no subscription. It's a paid product and I'm not going to pretend otherwise. But the pattern is the more useful takeaway, and it generalises well past screenshots: if the data is sensitive, transform it before it moves, not after. Blur tools on the web got the order wrong, and that's the entire bug.

Turning what you read into Anki cards without the typing

glensum — Tue, 13 Oct 2026 04:12:21 +0000

Turning what you read into Anki cards without the typing

Here's a workflow that fails quietly, every day, for a lot of people:

You read something good — a paper, a lecture PDF, a long article, a YouTube lecture.
You think "this belongs in Anki."
You open Anki, create a deck, and start typing cards by hand.
You make six cards, it's been twenty minutes, and you close the window.

The material never makes it in. Not because spaced repetition doesn't work — it obviously does — but because the input step is manual while the review step is automated. Anki's scheduler is a piece of software. Your card creation is you, typing.

The bottleneck is card creation, not review

Most "I fell off Anki" stories I've heard are really "I stopped making cards" stories. Reviewing thirty cards takes a few minutes and has an algorithm pushing you along. Writing thirty cards takes an hour of undifferentiated typing, and nothing pushes you along at all.

That asymmetry is worth naming, because it tells you where a tool can actually help. Nobody needs help being nagged to review. What's missing is a low-friction path from "the thing I just read" to "a card in my deck."

Three ways to close the gap — and what each one costs

If you look at how people have tried to solve this, there are basically three shapes.

CSV / export pipelines. Generate cards somewhere, export to a file, import into Anki. This works, and it's the most common DIY approach. The costs show up later: field mapping breaks when your template changes, the import dialog steals focus, and there's no deduplication — run it twice on the same article and you get two copies of every card. In a deck you'll keep for years, duplicate cards are worse than missing cards, because they double your review load silently.

Anki add-ons. Running inside Anki is convenient if that's where you already are. But by definition an add-on starts after the text exists somewhere — it can't see the PDF you have open in a browser tab, and it can't see the article you're reading. It also only runs on desktop Anki, and it breaks on Anki version bumps.

A browser extension. This is the shape I ended up building. The argument for it: the content arrives in the browser first — pages, PDFs, YouTube transcripts. If you intercept it there, you're working at the actual point of friction, and you don't need the user to leave what they're doing to go make cards.

Writing through AnkiConnect instead of exporting files

The technical decision that mattered most was to write cards into the collection through AnkiConnect rather than generating an import file.

AnkiConnect is a local HTTP server exposed by an Anki add-on (code 2055492159, free). Because it can query the collection, you can do two things a file export fundamentally cannot:

// ask the collection what already exists before writing
{ action: "findNotes", version: 6, params: { query: 'deck:"Reading" "{{text}}"' } }

// then write only the notes that aren't there yet
{ action: "addNotes", version: 6, params: { notes: [...] } }

The first call is the interesting one. A dedupe check against the live collection turns "generate 40 cards" into "generate 40 cards, 12 of which you already have" — and the second group never gets written. It also means cards land with the right note type and tags, in the deck you chose, with no import dialog and no field remapping.

The honest cost of this approach: it requires desktop Anki running locally. That's a real constraint — no AnkiWeb-only setup, no mobile. I took the trade because a card that lands in the wrong deck with the wrong template isn't really a card.

On-device inference, or your own key

The second decision was where inference runs. The default is Chrome's built-in on-device model, which means the selected text never leaves the machine — no upload, no account, no telemetry. If you want a stronger model, you paste your own API key (OpenAI / Anthropic / Google) and the request goes browser → provider directly.

Two things fall out of that architecture, and I'd rather state them plainly than let them be discovered later:

Because inference runs on the user's machine or the user's key, there's no per-generation cost sitting on a server of mine. That's why a one-time price is possible instead of a subscription — not a marketing stance.
The only outbound request the extension makes is license activation. Nothing in the pipeline requires a server I operate.

What generation gets wrong (and why "prune" is the real feature)

LLMs will happily produce forty mediocre cards from a page of prose. Forty mediocre cards are worse than twelve good ones: they're more review load, lower retention per minute, and they train you to skim.

So the workflow the tool is built around is generate → prune → write, not generate-and-accept. Cards come back in a side panel where you edit or delete them before any of them touch the collection. The list-splitting template exists for the same reason: an enumeration in the source ("five causes of X") is a place where one card per item beats one card asking for all five.

If there's one habit I'd recommend regardless of tooling: cap what you write per reading session. Twenty cards from an article you understood beats eighty from an article you skimmed.

Full disclosure, and a question

I'm the developer of AnkiMate — a Chrome/Edge extension that does the above. Pricing, stated plainly: free tier is 3 generations a day and writing cards into Anki is always free and unlimited; Pro is $19.9 one-time (Cloze, batch generation, future templates), no subscription. It's a paid product and I'm not going to pretend otherwise.

I'm not claiming it's better than what you use — I don't have the user base to make that claim honestly. What I'd genuinely like to know is where your own pipeline breaks:

Is the friction in capturing the source, in generating the cards, or in the pruning/editing step afterwards?

My assumption while building was that pruning is the part people underrate. If you're a heavy Cloze user and that assumption is wrong, I'd rather find out now.

Why most cookie-banner blockers don't actually work

glensum — Thu, 08 Oct 2026 14:58:51 +0000

Why most cookie-banner blockers don't actually work

Install a typical cookie-banner blocker, then watch the network tab while you visit a site. Here is what actually happens:

The page loads. The consent management platform (CMP) script executes and builds the banner.
The blocker's CSS sets display: none on the banner element.
The banner disappears from your screen.
The CMP never receives a "reject" signal. Non-essential scripts keep loading exactly as before.

That fourth step is the part almost nobody talks about.

Hiding is a cosmetic operation

A cookie banner is not a decorative overlay you're allowed to delete. It's the UI of a consent platform — a script that is supposed to record a decision and hand that decision to the tag manager, which then decides whether to fire analytics, ads, session replay, and so on.

If you remove the banner with CSS, you have removed the UI and left the machinery untouched. The page has no idea what you wanted, so it defaults to its own default, which is usually "everything on until told otherwise."

The visible result is identical. The legal and technical result is the opposite of what the user intended.

What a real opt-out actually requires

Consent platforms are designed to accept a decision from a few specific entry points. To genuinely reject, a tool has to use one of them:

Trigger the platform's own reject control — the same element a human would click, selected per platform (#onetrust-reject-all-handler, [data-testid="reject-all"], button[aria-label*="reject"], …). It has to be the actual control, not a look-alike button the tool injects.
Call the platform's public API, e.g. OneTrust's OneTrust.RejectAll(), or Cookiebot's consent submit methods. These write the consent record that the tag manager reads.
Post a proper TCF v2 string for IAB-compliant platforms, so downstream vendors see a "no consent for purposes 1–10" state.

There is a reason most blockers skip this: it's platform-specific, the DOM changes constantly, and each CMP has its own naming. A CSS rule works on every site forever. An API call breaks next Tuesday. So the ecosystem settled on the version that's easy to maintain instead of the one that works.

The signal almost nobody sends: GPC

Global Privacy Control is a legally recognised opt-out preference signal under the CCPA/CPRA and several US state privacy laws. It has two parts:

1. A request header, Sec-GPC: 1 — trivial to add from an MV3 extension via a declarative rule:

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [
      { "header": "Sec-GPC", "operation": "set", "value": "1" }
    ]
  },
  "condition": {
    "urlFilter": "*",
    "resourceTypes": ["main_frame", "sub_frame"]
  }
}

2. The JS property navigator.globalPrivacyControl, which sites can read directly. Chrome doesn't ship it (yet), so an extension has to define it in a content script running before page scripts:

try {
  Object.defineProperty(navigator, "globalPrivacyControl", {
    get: () => true,
    configurable: false
  });
} catch (e) { /* already defined */ }

Because it's a legal signal in some jurisdictions, a site that receives it is supposed to stop selling or sharing your data even without a banner interaction. Yet a quick audit of the popular CSS-hiding blockers shows most of them never send it. Hiding a banner is easy to demo; sending a header that no screenshot can show isn't.

Why this category went stale

Here's the part that made me actually build something.

The extension with the largest install base in this category was acquired a few years ago and — as of this writing — has not shipped an update since mid-2024. The store reviews have shifted accordingly: a large share of the nearly 1,900 ratings are now one star, and the top-voted comments read like "stopped working on many sites" and "breaks scrolling". Meanwhile a community fork that just keeps the rules updated has picked up a couple hundred thousand users.

That tells you two things:

Users in this category do switch tools — the switching cost people assume exists isn't really there.
The category's problem is maintenance, not novelty. Consent platforms change their DOM; a blocker that isn't updated decays into "hides some banners, silently fails on others."

The three constraints I built around

Full disclosure: I'm the developer of a blocker in this space, CookieGuard. I'm not going to claim it's "better" — I have too few users to make that claim honestly. What I can describe is the shape of the problem I constrained myself to, because each constraint comes straight from what the reviews complain about:

Press the real button. Identifies the CMP by name (27 of them), triggers its genuine reject action or calls its own API; unknown banners fall back to a phrase library (224 don't-sell phrases across 35 languages); verifies the banner is actually gone rather than assuming.
Don't break the page. The rejection is scoped to the banner it dismissed. No page rewriting, and it never clicks "Accept" on your behalf — a consent tool that accepts on your behalf is worse than no tool.
Nothing leaves the machine. No account, no analytics, no telemetry. The optional per-site memory stores a hostname and the action you took, and clears in one click.

It's a manifest V3 extension, rules ship as a versioned JSON file (because that's the part that has to stay current), and the only outbound requests it makes are an optional daily rules fetch and licence activation.

The question I'd actually like answered

Treat the tool as irrelevant to this post. The design question is:

Should a consent tool be judged by whether the opt-out legally registers, or is hiding the banner good enough?

If the answer is "hiding is fine," then the entire GPC layer and the CMP-specific API calls are wasted complexity, and the whole category can stay six lines of CSS. If the answer is "it should actually register," then most of the popular tools are shipping the cosmetic version of a legal feature — and that's worth saying out loud.

Either way: if you've hit banners that neither approach handles, the shape of the failure is more useful to me than a rating. Tell me what the site was and what happened.

From web page to Anki deck in one click: a flashcard workflow that stays in your browser

glensum — Wed, 30 Sep 2026 02:09:21 +0000

If you use Anki seriously, you already know the workflow: read an article, spot a fact worth remembering, switch windows, paste it into a note template, reformat it, repeat. The reading and the card-making happen in two different worlds, and the friction quietly kills half the cards you intended to make.

This post walks through a workflow that keeps everything in the browser tab: select text, generate flashcards, review them, and write them straight into your Anki decks. It uses AnkiMate, a Chrome and Edge extension my team built — but the setup (AnkiConnect + a capture habit) works with other tools too, so most of this post applies even if you use something else.

The 60-second setup

Install the AnkiMate extension (also on Edge).
In desktop Anki, install the AnkiConnect add-on (code 2055492159) and restart Anki.
That's it. The extension talks to your local Anki over AnkiConnect — there is no account, no cloud sync step, no middleman.

The workflow: select → generate → review → write

Select any text on an article, lecture note, or documentation page (or use full page / PDF / YouTube transcript as input).
Right-click → Generate flashcards. A side panel opens with draft cards.
Edit or delete anything you don't like. Nothing is final here — every card is editable, removable, and draft-saved.
Pick a deck and hit Write to Anki. Cards land in your collection tagged and deduplicated.

The last step is the one that saves the most time. Cards are written directly into the deck you choose, deduplicated by content hash — and if the source page changed, the card gets updated instead of duplicated. No more discovering three near-identical cards about the same fact a month later.

Templates tuned by subject, not one generic prompt

A generic "make flashcards from this text" prompt produces generic cards. AnkiMate ships nine templates, each tuned for a subject:

Medicine (USMLE) — expects clinical detail, not trivia
GRE vocabulary — word, definition, usage
Language learning — front/back with context, plus a reversed-vocabulary variant
Law — element-based structure
Programming — concept and code-focused cards
List breakdown — turns enumerations into atomic cards (the classic "one fact per card" rule, enforced for you)
General — everything else

Eight templates are free. Pro adds Cloze deletions (fill-in-the-blank), which is the right format for definitions, dates, and anatomy.

Privacy: on-device AI by default, BYOK if you want more

This matters to us, so it's the design center: on-device AI handles generation by default, and your selected text never leaves the browser. If you want a stronger cloud model, you plug in your own API key — and then your text goes directly from the extension to that provider, not through our servers. We never see your selections, your cards, or your key. (We wrote up why this matters in more detail — most "AI readers" proxy every page you visit through their own backend.)

Pricing, honestly

Free, every day, no card required: 3 generations per day (roughly 45–90 cards), all 8 non-Pro templates, all input types, unlimited writes to Anki. For most students this is genuinely enough.
Pro · Lifetime $19.9 (launch price, $29.9 after): unlimited generations, batch generation of 20+ cards from long pages, and the Cloze template. One payment, no subscription — the price of two coffees for the tool you'll use every study session.

Honest limitations

Desktop Anki (with AnkiConnect) needs to be running when you write cards — AnkiMobile/AnkiDroid alone won't receive them.
Generation quality tracks source quality: a well-structured page produces great cards; a rambling forum thread needs more editing.
It makes cards, not understanding. Spaced repetition still requires you to actually do the reviews.

Try it

Install from the Chrome Web Store or Edge Add-ons, or read more at glenkit.com/ankimate. If you have questions about the AnkiConnect setup or template design, leave a comment — I reply to all of them.

How to summarize 2-hour videos and 50-page articles without leaving the browser tab

glensum — Tue, 29 Sep 2026 07:39:22 +0000

A 40-minute conference talk. A 90-minute podcast. A 12-minute tutorial that could have been a blog post. Most of what's valuable in a video is its content — and content can be read.

I've been building GlenSum, a browser extension that summarizes long videos and articles directly in the tab. This post covers the three working approaches to media summarization in a browser, the privacy trade-off most people don't notice they're making, and what "long content" actually means for an LLM.

Three ways to summarize a YouTube video (slowest to fastest)

1. The transcript, by hand

Every video with captions has a transcript: expand the description → Show transcript → select all → paste into any AI chat.

Cost: free
Time: 3–5 minutes of fiddly copying, and raw transcripts are messy — no punctuation, no speaker labels, timestamps everywhere
Best for: one-off use when you can't install anything

2. Paste the URL into an AI chat

Some assistants accept a YouTube URL directly and fetch the transcript themselves. Paste the link, ask for key points.

Cost: often limited by your plan's usage quota
Caveat: availability varies by model and region — and now the video passes through yet another service
Best for: occasional videos when you already pay for an assistant

3. A browser extension, one click

Extensions built for this read the transcript from the page you already have open and generate a structured summary in a side panel. The workflow becomes: open the video → click the extension → read the summary. No copying, no tab-switching.

The extras that matter: adjustable summary length, follow-up questions about the content ("what did they say about X?"), bilingual output when the talk isn't in your first language, and Markdown/PDF export so the summary lands in your notes.

The privacy trade-off most people miss

Here's the part that motivated building this in the first place. When you paste a URL or transcript into a hosted summarizer, your reading and watching history becomes someone's dataset. Article by article, video by video, a profile of what you consume accumulates on a server you don't control. That's a real cost that never shows up on the pricing page.

The alternative is BYOK — bring your own key:

You paste an API key from your own AI provider (OpenAI, Google, a local gateway, anything OpenAI-compatible) into the extension once.
The extension reads the page content in your browser and sends it directly to the provider you chose.
There is no middleman server. No account. No logs on my side, because there is no "my side" — the extension ships as static code, and the network calls go from your browser to your provider.

The trade-off is honest: you manage your own key, and free-tier users can still use built-in free models without one. But nobody in the middle ever sees what you read.

What "long" actually means for an LLM

Summarizing a 2-hour talk isn't just "paste transcript into prompt". A two-hour transcript is roughly 25,000–40,000 words — technically it may fit a modern context window, but quality degrades: the model skims, drops the middle, and blends sections together.

The approach that works is map-reduce over chunks:

Map: split the transcript (or article) into overlapping chunks at natural boundaries — chapters, speaker turns, section headings — and summarize each chunk separately.
Reduce: merge the chunk summaries into a final structured summary, keeping section-level detail instead of a mushy average.

This is also why page-native tools beat copy-paste: the extension already knows the page structure, so it can split at real boundaries instead of arbitrary token counts.

When a summary is the wrong tool

Summaries are ideal for inverted-pyramid content: talks, podcasts, news analysis, tutorials — where information density is low and predictable. They're poor substitutes for demonstration content: if someone is showing you how to do a three-point turn, no summary captures the steering.

A good rule: summarize first to decide whether to watch — not to avoid watching things worth watching.

Try it

GlenSum is free to install and works out of the box (built-in free models, or your own key for unlimited use):

🌐 Site & docs: glenkit.com/glensum
🧩 Edge Add-ons · Chrome Web Store

Questions about the architecture — especially around BYOK flows or chunking strategies for long transcripts — happy to answer in the comments.