DEV Community: Dhardingsea Developer

I built a local-first Dota 2 companion as a Chrome extension — and learned what "minimum permissions" actually means

Dhardingsea Developer — Tue, 04 Aug 2026 10:45:03 +0000

Building a no-account, no-API-key Dota 2 stats extension, and three Chrome/Steam lessons that cost me a Web Store rejection.
https://dhseadev.online/projects/dota-companion/

Most Dota 2 stat sites answer "how did that game go?" I wanted one that answers a harder question: am I actually getting better?

So I built Dota Companion — a Chrome extension that lives in your toolbar. No account, no API key, no signup. Paste a Steam profile URL and it works.

The build taught me three things worth passing on, one of which got the extension flagged by the Chrome Web Store.

The feature I actually cared about: improvement streak

Win streaks measure luck as much as skill. In a five-player team game, you can play well and lose.

So the headline metric isn't wins — it's an improvement streak: consecutive games where your GPM beat your own 20-game baseline. It's a metric you control, and it moves when you improve rather than when your team cooperates.

Same idea drives goals. Pick GPM, KDA, last hits, or win rate; the baseline snapshots your current 20-game average when you set the goal. You compete with past-you.

The rest is the between-games layer: today's W/L, a GPM trend sparkline, recent matches with hero, K/D/A, duration and how long ago, most-played heroes, and private notes and tags on players you run into — stored on your device, never uploaded.

Lesson 1: `chrome.tabs.create()` does not need the `tabs` permission

This one cost me a rejection email.

I had one tabs call — opening a bundled inventory page:

chrome.tabs.create({ url: chrome.runtime.getURL('inventory.html') });

So "tabs" went in the manifest. Reasonable, right?

Wrong. Google flagged it under their minimum-permissions policy:

The following permission(s) need not be requested for the methods/properties implemented by the item: tabs

chrome.tabs.create() has never required the tabs permission. No tab-creation API does. That permission gates exactly one thing: reading sensitive tab metadata — url, pendingUrl, title, favIconUrl — off Tab objects.

I passed a URL in and ignored the returned object. I was declaring a capability I never used.

I verified the fix rather than trusting the docs — loaded the extension with tabs removed and called the API in a real browser:

runtime granted permissions: {"permissions":["storage"],"origins":["https://api.opendota.com/*"]}
chrome.tabs.create -> {"ok":true,"tabId":210614909}
pages before/after: 2 / 3
errors: NONE

Tab opened. Zero errors. The permission was pure liability.

Takeaway: grep your actual call sites before declaring anything. "This API sounds tab-related, so I need tabs" is exactly the reasoning the policy exists to catch. Ask instead: do I read the returned object's sensitive fields? If no, you don't need it.

Lesson 2: rate limits you share with the user are a design constraint, not an error case

The extension can estimate your Dota 2 inventory value from Steam Community Market prices. Steam rate-limits those endpoints hard — and critically, the limit applies to the whole IP, not to your extension.

Blow through it and you don't just break your feature. You break the user's normal Steam browsing. That reframes the problem: you're not optimizing your own throughput, you're spending a budget that isn't yours.

So the design is deliberately timid:

Nothing fetches automatically. Every request traces back to a button the user pressed.
A visible request budget, capped well short of the real limit, shown in the UI.
Hard backoff. If Steam pushes back, it stops for hours rather than retrying.
No Steam login cookies are sent. Public data only.

Slower than technically possible, on purpose. A tool that degrades the rest of your browsing isn't a good tool.

Lesson 3: optional permissions are worth the extra state

The inventory feature needs steamcommunity.com access. Most users never open it.

Requesting that host at install time means every user sees a scary permission prompt for a feature they may never touch. So it's an optional host permission, requested at the moment of use:

chrome.permissions.contains({ origins: [ORIGIN] }, cb);  // gate the UI
chrome.permissions.request({ origins: [ORIGIN] }, cb);   // only on click

Cost: a real permission-state machine — gated UI, a grant screen, a declined path. Benefit: the install prompt asks for nothing surprising, and the request arrives with obvious context.

Worth it. Install-time friction is where extensions die.

Testing logic that lives in a popup

Extension code resists testing — everything wants chrome.* or the DOM. The fix was a hard boundary: all pure logic (streaks, baselines, formatting, aggregation) sits in modules that touch nothing — no chrome.*, no DOM, no fetch, not even the clock. Current time is passed in as an argument.

Those modules dual-export: a global for the extension, module.exports for Node. The whole stat layer runs headless with zero browser mocks.

That caught a genuinely nasty one. OpenDota returns start_time in epoch seconds. new Date(start_time) expects milliseconds — so every match silently renders as 1970. There's now a regression test asserting exactly that.

Try it

Chrome Web Store: Dota Companion
Project page: dhseadev.online/projects/dota-companion

Data comes from the OpenDota API — you'll need "Expose Public Match Data" enabled in Dota 2 settings for matches to show up. English and Simplified Chinese.

Not affiliated with Valve.

Twelve gradients, one id - DHSeaDev

Dhardingsea Developer — Mon, 03 Aug 2026 22:51:32 +0000

A markup defect with no visual symptom, the audit that missed it five times, and the guard that stopped the fix from being worse than the bug.

The page in question: dhseadev.online/play

MARKUP · A DEFECT WITH NO SYMPTOM

Twelve gradients, one id

Eleven of them were dead. The page looked exactly right, and that was the problem.

A site scan flagged nothing. My own audit reported zero defects across forty-six pages.
The page rendered precisely as designed. Eleven of its twelve gradients had never been
used by anything.

THE DEFECT ————————————

What twelve copies of one emblem actually produces

I had an SVG emblem I liked, so I pasted it into a page twelve times. Each copy brought
its own gradient definition along with it.

<svg viewBox="0 0 40 40">
  <defs>
    <linearGradient id="pg">
      <stop stop-color="#C4B5FD"/>
      <stop stop-color="#93C5FD"/>
      <stop stop-color="#F0ABFC"/>
    </linearGradient>
  </defs>
  <path fill="url(#pg)" d="..."/>
</svg>

Twelve <svg> blocks. Twelve elements carrying id="pg". Duplicate ids are invalid
HTML, and url(#pg) resolves to the first match in the document — so every emblem on
the page was painted by gradient number one, and the remaining eleven were parsed, held
in memory, and referenced by nothing.

The reason it stayed invisible is almost insulting: all twelve definitions held
identical stops. There was no visual symptom because there was nothing to see. A bug
like this waits patiently for the day you change one gradient and the change lands on
the wrong element, or on none of them.

THE AUDIT ————————————

Why five passes of my own tooling missed it

My checks looked for missing alt attributes, broken links, absent structured data.
"Are any ids duplicated" was not among them, because it had never yet cost me anything.

It costs four lines to add.

const ids = {};
for (const el of document.querySelectorAll('[id]')) {
  ids[el.id] = (ids[el.id] || 0) + 1;
}
console.log(Object.keys(ids).filter(k => ids[k] > 1));

THE FIX ————————————

The trap sitting inside the repair

The obvious remedy is a unique id per gradient. My first attempt renamed sequentially
across the whole document, and I put a count assertion in front of it out of habit
rather than suspicion.

let n = 0;
html = html.replace(/id="pg"/g,    () => `id="pg${++n}"`);
let m = 0;
html = html.replace(/url\(#pg\)/g, () => `url(#pg${++m})`);

The assertion failed.

defs = 12 · refs = 115

Each emblem defined one gradient and referenced it roughly ten times. A sequential
rename would have paired the second definition with the second reference — which
belonged to the first emblem. It would have converted an invisible defect into a
visibly broken page, and it would have done so while reporting success.

The correct repair scopes the rename to each <svg> block, so a definition can only
ever be paired with references from its own subtree.

let n = 0;
html = html.replace(/<svg[\s\S]*?<\/svg>/g, (block) => {
  if ((block.match(/id="pg"/g) || []).length !== 1) return block;
  const id = `pg${++n}`;
  return block
    .split('id="pg"').join(`id="${id}"`)
    .split('url(#pg)').join(`url(#${id})`);
});

Twelve blocks renamed. Zero leftover definitions, zero leftover references, twelve
distinct ids, and no duplicate id anywhere on the page.

WHAT IT LEAVES BEHIND ————————————

Inline SVG pasted more than once duplicates every internal id it carries — not only
gradients, but filters, masks, clipPaths, patterns, and every aria-labelledby target.
A duplicate-id check belongs in the audit precisely because this class of bug produces
nothing to look at.

And a bulk find-and-replace that assumes definitions and references pair up should be
made to prove it before it writes a single byte. Mine was guarded by habit rather than
foresight, and habit was the only reason a twelve-against-one-hundred-and-fifteen
mismatch never shipped.

Found while auditing dhseadev.online, August 2026.

I built a shared wall that can't be spammed, by removing the text box

Dhardingsea Developer — Mon, 03 Aug 2026 19:38:06 +0000

Why the Positivity Wall has no text field, no accounts and no likes — and what subtraction has to do with building alongside AI.

https://dhseadev.online/2026/08/01/joy-is-what-is-left/

I spent a day making a website easier for search engines to find, and finished it by
building a page that has nothing to do with search engines. Nine panels. You click one,
you leave a stamp, and the stamp is still yours the next time you come back.

The interesting part isn't the feature. It's the three things I took out.

The first version was worse

The original idea was a 3×3 grid of embedded videos from people who make cheerful
things — reposted on my site. I talked myself out of it in about ten minutes, for a
reason that turned out to matter: embedding someone else's video sends my visitor to
their platform. It borrows nothing and gives away the only thing I have.

So the content had to come from the visitor. And the moment content comes from
visitors, you're running a moderation problem whether you meant to or not.

Why there's no text box

The obvious design is a text field. Leave a nice message. I didn't build that.

Three characters is enough for a slur. Any free-text field on a public page is a
commitment to moderate it forever, and I'm one person who won't always be paying
attention. A field I can't supervise is a field I shouldn't ship.

What I built instead is a stamp generated from a random seed in your browser:

// seed -> shape, glyph, hue. no assets, no storage, no input.
function rnd(s) { s = (s * 9301 + 49297) % 233280; return { s, v: s / 233280 }; }

function stamp(seed) {
  const r = seq(seed, 4);
  return {
    hue:   Math.floor(r[0] * 360),
    sides: 3 + Math.floor(r[1] * 5),   // triangle .. heptagon
    rot:   Math.floor(r[2] * 360),
    glyph: Math.floor(r[3] * 4)
  };
}

You can't type anything. You can't be obscene with a hexagon. And the stamp is more
personal than initials would have been, because it's yours and you didn't choose it.

Identity without accounts

No sign-up. No name. The page doesn't know who you are and has no way to find out.

What it has is one integer in localStorage. That's enough to say this mark is yours
and welcome back, and nothing else. Clear your browser and you become a new person,
which feels correct.

Shared state runs on playhtml, which is CRDT-backed — two people
stamping at the same moment both land, with no server I run and no database I have to
secure. The less I store, the less there is to leak.

What this has to do with AI

I build alongside AI constantly. What I notice is that the tools are very good at
producing more — more pages, more features, more words — and the discipline I keep
having to apply is subtraction.

The wall could have had comments, likes, leaderboards, streaks, a login. Every one was
available and cheap. Every one would have made it worse: more surface to moderate, more
data to hold, more reasons to visit out of obligation instead of pleasure.

Joy in software isn't a feature you add. It's what's left when you stop adding things
that create obligation.

Credit

The premise isn't mine. It came from Amanda Gore and The Joy
Project, whose work is about
helping people reconnect with themselves and each other. Her version happens in rooms
full of people. Mine is nine rectangles and some SVG — but the mechanism is the same
one she's pointing at: a person feels better when they're briefly, specifically seen.

You can leave a stamp here.