DEV Community: k-wada

My Chrome Extensions Can Read the Page — So I Designed Them Not to Send It Anywhere

k-wada — Sat, 12 Sep 2026 12:21:19 +0000

Some of my Chrome extensions need access to the page you are looking at.

That sounds uncomfortable.

And it should.

If an extension can inspect a page before you submit a form, check a link before you open it, or look for personal information before you paste text into an AI chat, it needs enough access to do that job.

The interesting question is not:

“Can this extension read the page?”

It is:

“What happens to the data after it reads it?”

For Legacy Tools, I made that distinction a design rule.

The extensions may need to inspect page content.

They should not need to send that content to my server.

Permission is capability, not data flow

Chrome host permissions define what an extension is allowed to interact with.

For example, a content script may need access to a page so it can inspect a form field or intercept a click.

That permission tells you something important:

the extension has the capability to access that page.

But it does not tell you where the data goes afterward.

Two extensions can request similar page access and have completely different architectures.

One might:

Page
  ↓
Extension
  ↓
Remote API
  ↓
Analysis
  ↓
Result

Another can do:

Page
  ↓
Extension
  ↓
Local analysis
  ↓
Result

Legacy Tools tries to use the second shape whenever the task allows it.

A small example

Consider a tool that checks text before it is sent to an AI service.

It may need to see the text currently entered in the page.

The simplest server-based architecture would be:

Read the text.
Send it to an API.
Analyze it on a server.
Return detected personal information.
Show the result.

That architecture can support powerful models.

But it creates a strange situation for a privacy tool:

to warn you about sending sensitive text somewhere, the tool first sends that text somewhere else.

So I chose a more limited architecture.

Text in the browser
        ↓
Local detection
        ↓
Show possible matches
        ↓
User decides what to do

No cloud model is required for that path.

The trade-off is real: local rules cannot understand every form of personal information.

That is acceptable.

The goal is not to promise perfect detection.

The goal is to provide one more chance to notice something before sending it.

I still try to reduce the permission itself

“Everything stays local” is not a reason to request unlimited permissions.

These are separate questions:

What pages can the extension access?
What does it do with the data it can access?

Both should be minimized.

Across the extensions I built, I ended up using several patterns.

Some tools genuinely need to work on many websites.

Some only need a fixed list of sites.

Some can request additional sites only when the user asks.

And one of my extensions can use activeTab, meaning it gets access only after the user explicitly invokes it on the current page.

I wrote about those permission patterns separately because choosing the smallest workable permission is part of the product design.

Local processing does not excuse broad access.

“No server” is a useful constraint

Not having a backend removes several things I would otherwise need to think about.

There is no database of user input to protect.

There is no API endpoint receiving page contents.

There is no retention policy for text that was never collected.

There is no account containing a history of what someone checked.

That does not make an extension automatically safe.

A local extension can still contain bugs.

It can request too much access.

A future update could change its behavior.

Another dependency could introduce a problem.

So I avoid saying:

“Local means safe.”

The more accurate statement is:

Local processing removes some classes of risk by removing unnecessary data movement.

That is a much smaller claim, but I think it is a more useful one.

AI-assisted development makes this rule more important

I use AI coding tools heavily.

That creates another failure mode.

An agent trying to solve a problem may reasonably decide that adding an API call, analytics package, external library, or broader host permission is the easiest implementation.

Technically, it may even be a good solution.

Architecturally, it may violate the product.

So I treat some things as boundaries rather than implementation details:

Do not broaden host permissions without an explicit reason.
Do not add external transmission just because it makes detection easier.
Do not add telemetry by default.
Do not replace a local implementation with a hosted service without reviewing the privacy change.

AI makes producing code cheaper.

It does not make architecture decisions cheaper.

If anything, those boundaries need to become more explicit.

Trust should come from constraints, not promises

A privacy policy can say:

“We respect your privacy.”

That is useful, but it is still a promise.

I prefer being able to say something more concrete:

“This feature does not require your text to leave the browser.”

That is an architectural property.

Users still have to trust the extension package and its updates, of course.

But every dependency or server you remove is one less thing they need to trust.

For small browser tools, that matters.

The uncomfortable permission warning is still useful

I used to think broad-looking Chrome permission warnings were mostly a UX problem.

Now I think the discomfort is healthy.

If an extension can read a page, users should know that.

The developer's job is not to make that capability sound harmless.

The job is to:

request only the access the feature actually needs,
explain why it needs that access,
minimize what happens after access is granted,
and avoid moving user data unless moving it provides enough value to justify the new risk.

So yes:

some of my Chrome extensions can read the page.

That is how they can help before you send, click, or submit something.

But being able to read the page does not mean the page needs to leave the browser.

For the kind of small safety tools I am building, that distinction has become one of the most important architectural decisions.

I build Legacy Tools, a small collection of browser tools designed to give people one more chance to check something before they act.

Previous article: 8 Shipped Chrome Extensions, 4 Ways to Declare Host Permissions

chromeextension #privacy #webdev #indiedev

I Can Build Software Faster Than Ever. Getting One Person to Use It Is Still Hard.

k-wada — Sat, 05 Sep 2026 14:35:01 +0000

I published the extension.

It passed review.

The store page was live.

The website was ready.

And then, almost nothing happened.

That was harder for me than any bug I had fixed while building it.

I thought shipping was the hard part

Over the past few months, I've been building small browser tools.

AI-assisted development changed what felt possible.

An idea could become a prototype quickly.

A rough prototype could become a real Chrome extension.

I could ask an AI coding agent to help inspect the implementation, find edge cases, review permissions, write tests, and prepare a release.

The whole process became much faster than I was used to.

So naturally, I focused on shipping.

Build it.

Fix it.

Submit it.

Pass review.

Publish it.

I thought that was the difficult part.

It wasn't.

The difficult part was getting another person to care.

The silence after publishing feels strange

There is something satisfying about software development.

When the code works, you know it works.

Tests pass.

The build succeeds.

A review is approved.

The extension appears in the store.

There is a clear result.

But after publishing, the feedback becomes much less clear.

You refresh the page.

You check the numbers.

You improve the description.

You write another explanation.

Maybe you submit the product to a directory.

Maybe you publish an article.

Maybe you change the screenshots.

Maybe you rewrite the landing page because perhaps the problem is simply that people don't understand it yet.

Then you wait again.

Often, nothing obvious happens.

There is no error message to fix.

No stack trace.

No failed test.

Just silence.

I found that much harder than I expected.

"That sounds useful" is not the same as "I'll install it"

This may be the biggest thing I've learned.

People can understand a product and still not use it.

Someone may say:

That sounds useful.

They may even agree that the problem is real.

But that is still very far from:

I'll install it.

For me, clicking the install button looks trivial.

For the person on the other side, it isn't.

They have to decide:

Is this actually useful for me?
Is this developer trustworthy?
Why does the extension need these permissions?
Will it interfere with something?
Will I remember why I installed it?
Do I really need one more thing in my browser?

One click contains many decisions.

As a developer, I had underestimated almost all of them.

Safety tools make this even harder

Some of the tools I'm building are meant to help people notice small risks before they act.

For example, before sending text, before following a link, or before trusting information on a page.

From my side, the idea feels simple.

A small tool notices something worth checking.

The user makes the final decision.

But there is an uncomfortable contradiction.

I am effectively saying:

Install software from a developer you don't know so that your browsing can be a little safer.

The product is asking for trust before it has had any chance to earn trust.

That realization changed how I looked at the whole project.

At first, I thought my problem was distribution.

Maybe I needed better SEO.

More directories.

Better copy.

A clearer landing page.

More screenshots.

I kept rewriting the website

For a while, I kept changing the site.

I rewrote explanations.

Added use cases.

Made privacy details clearer.

Explained what the tools do.

Then explained what they do not do.

I created pages for families.

Pages for organizations.

More examples.

More context.

Part of that work genuinely improved the product.

But at some point I noticed what I was really doing.

I was trying to answer an invisible question from a person I had never met.

Who are you, and why should I believe you?

That question is much harder than:

What does this extension do?

The second question can be answered with documentation.

The first one can only really be answered over time.

AI made building faster. It did not make trust faster.

For a solo builder like me, writing the code is no longer always the slowest part.

That is a huge change.

AI can help me build another feature.

It can help me review code.

It can help me write documentation.

It can help me improve a page.

It can even help me think through why a product is not working.

But it cannot make a stranger care.

It cannot make someone believe my claims.

It cannot create a history of reliable behavior.

It cannot replace the time required to earn trust.

That part still seems stubbornly human.

Maybe shipping is only the halfway point

I used to think a product looked like this:

Idea
  ↓
Build
  ↓
Test
  ↓
Ship
  ↓
Done

Now I think it looks more like this:

Idea
  ↓
Build
  ↓
Test
  ↓
Ship
  ↓
Explain
  ↓
Listen
  ↓
Improve
  ↓
Earn trust
  ↓
Repeat

The second half is much slower.

It is also harder to measure.

There is no compiler telling you what is wrong.

Sometimes you change something and nothing happens.

Sometimes one person finds the product weeks later.

Sometimes the right improvement is not another feature at all.

Maybe it is a better explanation.

Maybe it is fewer claims.

Maybe it is more transparency.

Maybe it is simply staying around long enough to become credible.

One user feels different to me now

When building products, it is easy to think in numbers.

Downloads.

Traffic.

Conversion.

Search impressions.

Users.

But lately, I have started thinking differently about a single install.

One person installing something I made means they crossed a surprisingly large gap.

They noticed it.

They understood it.

They decided the problem mattered.

They decided my solution might help.

And finally, they trusted it enough to put it inside a browser they use every day.

That does not feel like a small number anymore.

It feels like a significant decision made by another human being.

I'm still figuring this out

I don't have a growth formula to end with.

I'm still changing things.

Still writing.

Still improving the products.

Still learning which tools deserve more attention and which ones probably should not exist.

And I still have moments when building something new feels much easier than getting one person to use what I've already built.

But I no longer think that means the real work has not started yet.

I think this is the real work.

I used to think publishing software meant I had finished making it.

Now I'm starting to think a product is not really finished when the code works.

It starts becoming real when someone trusts it enough to use it.

My Mother Became a Licensed Cook at 70. It Changed How I Design for Older Users.

k-wada — Mon, 31 Aug 2026 13:21:54 +0000

My mother became a licensed cook at the age of 70.

She studied, prepared for the exam, took it — and passed.

At the same time, she sometimes asks me questions about smartphones and the internet.

“How do I do this?”

“Is it okay to click this?”

That contrast made me question something we often assume when designing software:

Are older users really “bad at technology”?

I don't think that's a very useful way to think about it anymore.

Capability is not the same as familiarity

Getting a professional qualification at 70 isn't easy.

You have to learn new things, remember rules, understand procedures, and pass an exam.

Clearly, the ability to learn is still there.

But technology presents a different problem.

When cooking, experience helps you predict what will happen.

If you heat something too long, it burns.

If you add too much salt, you know what the result will be.

The relationship between an action and its consequence is relatively visible.

On the internet, it often isn't.

What happens if I click this link?

Who actually operates this website?

Is it okay to enter my phone number here?

What exactly am I agreeing to when I click “Allow”?

The action itself may be easy.

Understanding the consequence is the difficult part.

“Make it simpler” isn't always the answer

When we talk about designing software for older users, the discussion often goes in a predictable direction:

Bigger text
Larger buttons
Fewer options
Simpler navigation

These are important accessibility considerations.

But I think there's another problem that receives less attention.

A UI can be extremely easy to operate while still being difficult to judge.

A giant “Continue” button is easy to press.

The harder question is:

Should I press it?

That's a completely different design problem.

Maybe software should support judgment

This changed how I think about some of the small browser tools I've been building.

Originally, my instinct was straightforward:

Detect something dangerous and stop the user.

But that creates another problem.

The software starts deciding what is correct.

And real-world situations are rarely that clean.

So I've gradually moved toward a different model:

Don't make the decision for the user.
Give them a better moment to make the decision themselves.

For example:

Before sending personal information.

Before opening an unfamiliar link.

Before trusting a website.

Before submitting something that may contain sensitive information.

The software doesn't necessarily need to say:

“You cannot do this.”

Sometimes it only needs to say:

“You may want to check this once.”

That small difference matters.

Friction isn't always bad UX

Developers spend a lot of time removing friction.

Fewer clicks.

Faster checkout.

Automatic completion.

One-tap actions.

And most of the time, that's good engineering.

But I don't think friction is universally bad.

There are moments where a tiny amount of friction creates useful thinking time.

A confirmation before sending sensitive information isn't necessarily an obstacle.

It can be a decision boundary.

That has become one of the ideas behind my small project, Legacy Tools.

I'm experimenting with browser extensions that add small checks at these boundaries — without uploading the user's data somewhere else and without trying to replace their judgment.

The goal isn't to make the internet “simple enough for older people.”

It's something different.

Don't remove capability. Add context.

My mother doesn't need technology to treat her as incapable.

Someone who studies for and passes a professional exam at 70 clearly isn't incapable.

What she sometimes lacks online is the same thing many of us lack:

enough context to understand what an action will cause.

And that isn't really an “older people” problem.

Developers click suspicious links.

Employees accidentally paste confidential data.

Experienced users approve permissions they haven't really inspected.

We've all learned to operate software faster than we've learned to evaluate every consequence.

So perhaps the broader design principle is this:

Don't simplify users. Simplify the decision they need to make.

That is a very different way to think about accessibility, safety, and UX.

And watching my 70-year-old mother study for a new qualification was what finally made that obvious to me.

I Went to Numazu and Found an Old Food Technology

k-wada — Mon, 24 Aug 2026 14:29:59 +0000

Today, no AI.
No code.

Just fish.

A few days ago, I took a short trip to Numazu, a coastal city in Shizuoka, Japan.

Numazu is one of those places where fish feels very close to everyday life.

You walk around, see the harbor, seafood restaurants, fish shops — and eventually, you get hungry.

So I did what seemed like the obvious thing.

I ate fish.

More specifically:

Aji no himono — dried horse mackerel.

It looked very simple.

A grilled fish, opened flat, with rice and grated daikon radish.

But while eating it, I started thinking:

This is actually technology.

What is himono?

“Himono” literally means dried food, but in everyday Japanese it often refers to dried fish.

For aji no himono, the fish is usually opened, salted, dried, and then grilled before eating.

That's basically it.

No complicated sauce.

No long list of ingredients.

Fish.
Salt.
Air.
Time.

But that simplicity hides a surprisingly clever process.

The original problem: fish doesn't keep well

Fresh fish contains a lot of water.

That's one of the reasons it tastes good.

It's also one of the reasons it spoils quickly.

Today, we have refrigerators and freezers.

People in the past didn't.

So they needed another solution.

One answer was simple:

Remove some of the water.

Drying lowers the amount of water available for microorganisms and slows deterioration.

In modern food science, this is related to the concept of water activity.

So himono is not just “fish left outside.”

It is a method of controlling water.

And that changes everything.

It's really a tuning problem

The interesting part is that you don't want to remove all the water.

Dry too little, and preservation doesn't improve enough.

Dry too much, and the fish becomes hard and unpleasant.

So you're balancing several things at once:

preservation
moisture
texture
saltiness
flavor

That sounds familiar.

It's a trade-off.

You could almost describe himono as an old optimization problem.

Preserve the fish, but keep it delicious.

People solved that problem hundreds of years before anyone called it engineering.

Salt isn't just seasoning

Salt also plays more than one role.

Of course it makes the fish taste good.

But it also helps draw water from the fish and changes the environment in which microorganisms can grow.

So salt is not just a topping.

It's part of the process.

The recipe is closer to this:

Fish + salt + controlled drying + time

And after that process, the fish is no longer quite the same food.

The texture changes.

The aroma changes.

And the flavor changes.

Then there is umami

This is where Japanese food gets especially interesting.

The Japanese word umami is now widely used around the world.

It is generally described as the fifth basic taste, alongside sweet, sour, salty, and bitter.

Fish naturally contains compounds connected to umami, including glutamate and nucleotides such as inosinate.

And an important point is this:

Drying doesn't magically create umami from nothing.

It's more subtle than that.

By reducing water, adding salt, changing texture, and allowing biochemical changes during processing, the experience of the flavor becomes different.

The taste feels deeper.

More concentrated.

More satisfying.

And that's one of the things I noticed while eating the fish in Numazu.

There wasn't much on the plate.

But it didn't feel simple at all.

Maybe that's why I like Japanese food

When people think of Japanese food, they often think of sushi.

Or ramen.

Those are great.

But some of the foods I like most are much less spectacular.

Grilled fish.

Rice.

Miso soup.

Pickles.

A little grated daikon.

Nothing flashy.

And yet, behind something as ordinary as a piece of dried fish is a long history of people experimenting with:

water, salt, time, temperature, texture, and taste.

That's engineering.

Just not the kind we usually write about on DEV.

A small discovery in Numazu

I went to Numazu just expecting a short trip and some good food.

I came back thinking about dehydration, preservation, and umami.

That might be an occupational hazard of being an engineer.

But I like finding technology in ordinary things.

And himono is a good example.

It looks like a simple grilled fish.

But behind it is an old idea:

Control water, and you can control preservation.

Then keep improving the process until preservation and deliciousness can coexist.

Humans have been optimizing systems for a very long time.

Some of them just happen to be edible.

So if you ever visit Japan, try sushi.

Try ramen.

But if you find yourself somewhere like Numazu, look for something simpler.

Aji no himono.

You might be eating a small piece of Japanese food engineering.

8 Shipped Chrome Extensions, 4 Ways to Declare Host Permissions

k-wada — Fri, 21 Aug 2026 17:16:55 +0000

I ship eight small Chrome extensions under Legacy Tools. They are all
Manifest V3, and they all need some form of access to the pages you
visit — that is what tools that check things before you send them do.

I have written before about the rules I give AI agents
so they never broaden permissions on their own. This post is about the
other side of that: the shapes the declarations themselves take.
Recently I put all eight manifests side by side (the versions shipped to
the Chrome Web Store as of 2026-08-22) and realized they ended up using
four different shapes to declare that access. None of this was planned
up front; each shape fell out of what the tool is. Here is the survey.

The four shapes

1. Everywhere, all the time — five extensions.
Safe Privacy Gate, Safe Attachment Check, Safe Mail Link Check, Site
Operator Check, Find My Age. These step in right before a send or a
click, and there is no way to know in advance which site that will
happen on. Interesting detail: only two of the five actually write
<all_urls> into host_permissions. The other three get the same
breadth from content_scripts.matches alone.

2. One fixed site — one extension.
Safe Night Check is a Gmail-only tool, so the whole declaration is a
single pattern: https://mail.google.com/*.

3. A fixed list plus optional grants — one extension.
Safe Privacy Mask enumerates thirty matches patterns for the AI chat
sites it supports, and puts <all_urls> into
optional_host_permissions so that any other site is granted only when
the user adds it, one prompt at a time.

4. activeTab only — one extension.
Copy & Prep ships no content script at all. It touches only the tab
where you just ran its context-menu action. Standing access: zero.

The part that surprised me

While checking what these declarations look like from the user's side
(on chrome://extensions, with the extensions side-loaded into
Chromium), two things stood out:

The Permissions section came up empty every time. I measured seven of the eight this way. Between them they use storage, scripting, contextMenus and activeTab — none of those produces a line in that box. "The permissions list is blank, so it must be harmless" is not a read you can make.
matches counts as a host permission. Safe Attachment Check declares no host_permissions at all, and its site-access wording was character-for-character identical to Safe Privacy Gate, which declares <all_urls> explicitly. You cannot shrink the warning by moving breadth out of host_permissions and into content_scripts.
Bonus: the list shown to users is deduplicated. Mask declares thirty patterns; the screen shows fifteen. A short list does not mean narrow coverage.

What I take from this

Permission declarations are not configuration. They are UI — shown to
the user, in their words, at install time and on the details page. The
shape you choose is a product decision: <all_urls> is honest for a
tool that must work everywhere, a fixed list is honest for a
single-site tool, and activeTab is worth the extra design work when
"only when I ask" is the actual contract.

I wrote up the longer versions of both halves of this:

The structure side — what runs where in a Manifest V3 extension, and how the manifest keys relate: https://legacy-tools.dev/en/notes/how-a-chrome-extension-works-manifest-v3/
The display side — what the Permissions and Site access sections actually show, measured against our own manifests: https://legacy-tools.dev/en/notes/reading-chrome-extension-permissions/

Running LM Studio Locally Doesn't Mean It Never Connects Out

k-wada — Thu, 20 Aug 2026 07:01:51 +0000

When we say “local LLM,” it is easy to mentally translate that into:

Everything stays inside the PC.

For inference, that can be true.

But the application running the model is still an application with network-capable features.

LM Studio, for example, may need connectivity for things such as:

searching for models
downloading models
downloading runtimes
checking for application updates

It can also expose a local API server, connect to MCP servers, enable CORS, or serve the API to other devices on the LAN.

None of those features are inherently bad.

But I wanted a much narrower environment:

one approved model, local inference, and as little external connectivity as possible.

So I treated “local execution” and “network isolation” as two separate problems.

My target state

For normal use, I wanted this:

LM Studio
   |
   +---- 127.0.0.1 / localhost ---- allowed
   |
   +---- LAN ----------------------- blocked
   |
   +---- Internet ------------------ blocked

The important part is the loopback connection.

Blocking everything blindly can also break communication that stays entirely inside the machine.

So the rule became:

deny external communication, but deliberately preserve loopback.

Configuration is not the security boundary

LM Studio already provides useful settings.

For my baseline I disable features I do not need:

Serve on Local Network
CORS
per-request MCP
MCP servers from mcp.json
cloud features / web search
automatic model switching or unexpected model loading

I also keep the API server off because I do not need it for this evaluation.

And my mcp.json is intentionally boring:

{
  "mcpServers": {}
}

But I do not want the security of the environment to depend entirely on application settings.

Settings can be changed.

Their internal representation can also change between versions.

So I use two layers:

LM Studio settings
        +
OS network controls

The first expresses the intended configuration.

The second enforces the boundary.

Separate setup from normal use

This was probably the most useful design decision.

LM Studio needs the network while preparing the machine.

So I split operation into two phases.

Setup phase

Network access is temporarily available for things that genuinely require it:

Install LM Studio
        ↓
Download the approved runtime
        ↓
Download the approved model
        ↓
Verify the files

After that, normal use does not need model discovery or downloads.

Normal-use phase

The environment becomes much smaller:

Start LM Studio
        ↓
Restore the hardened configuration
        ↓
Check MCP configuration
        ↓
Check network restrictions
        ↓
Unload previously loaded models
        ↓
Load only the approved model
        ↓
Run locally

This avoids trying to make installation and daily operation obey the same network policy.

They are different states.

Pin the model at startup

Another thing I did not want was:

“LM Studio is approved, therefore any model inside LM Studio is approved.”

Those are two different decisions.

At startup I first unload existing models:

lms unload --all

Then I load the model selected for the evaluation:

lms load <approved-model> \
  --context-length 8192 \
  --identifier approved-model

The actual startup wrapper also verifies that the expected model is available before continuing.

If the expected state cannot be established, startup should fail rather than quietly falling back to something else.

That is a small change, but it makes the environment much more reproducible.

If you need the API server

My current use case does not require it, so I leave it off.

But LM Studio's CLI supports explicitly binding the server to loopback:

lms server start \
  --bind 127.0.0.1 \
  --port 1234

That is very different from:

lms server start --bind 0.0.0.0

The first stays on localhost.

The second makes the server reachable beyond localhost and changes the security boundary significantly.

For a controlled local evaluation, I would not expose it unless there is a concrete reason to do so.

I also verify the result

A configuration file saying “disabled” is not enough.

I want to observe what actually happens.

So the evaluation includes checks such as:

which processes are listening on ports
whether unexpected external connections appear
whether the API server is running
whether MCP configuration changed
which model is actually loaded
whether unexpected GGUF files appeared
whether firewall rules are still present

The distinction matters:

configuration → what should happen
verification  → what actually happened

For this kind of environment, I want both.

“Local” describes where inference happens

This experiment changed how I think about the word local.

A local LLM tells me where the model inference runs.

It does not automatically define every network behavior of the application surrounding that model.

So my final model is:

Local inference
      ≠
Network isolation

If I care about both, I need to design for both.

LM Studio already works well offline once the required model and runtime are available.

What I added was a smaller operational boundary around it:

prepare while connected, then run with the outside closed and only the communication that must stay inside the machine deliberately preserved.

The full implementation and notes are available in the original Legacy Tools article.

I Asked AI for Chrome Extension Ideas. It Kept Saying “AI Can Already Do That.”

k-wada — Mon, 17 Aug 2026 13:52:08 +0000

I Asked AI for Chrome Extension Ideas. It Kept Saying “AI Can Already Do That.”

I’ve been building small Chrome extensions lately.

And, like many developers, I often ask AI for ideas.

Something like:

What small browser problems are still worth solving?

The answers are usually reasonable.

But there’s one response I keep running into.

“You can already do that with AI.”

Need to summarize some text?
AI can do it.

Need to clean up copied text?
AI can do it.

Need to compare information from several pages?
AI can do it.

Need to rewrite something before sending it?
AI can do it.

Technically, that’s true.

But after building several small tools, I think it’s also the wrong question.

“Can AI do it?” is a very low bar

Almost anything involving text can now be done with an AI chat.

But that often means:

Copy something
Open an AI tool
Paste it
Explain what you want
Check the result
Copy it again
Go back to what you were doing

That works.

But it’s still a workflow.

Sometimes a tiny browser extension can turn that into:

select → click → done

That difference matters more than I expected.

A small example

One of the extensions I built is called Copy & Prep.

It lets me collect text from multiple pages, reorder it, clean it up, and copy everything together.

Could I do that with ChatGPT?

Of course.

But I don’t actually want to explain the same task to ChatGPT every time.

I just want the text.

That made me realize something.

AI capability is not the same as product UX

When I ask AI whether an idea is useful, it tends to think in terms of capability.

“This task can already be performed.”

Users often think differently.

“How many steps does this take?”

Those are not the same question.

And I think this creates a small opportunity for browser extensions.

Not to compete with AI.

But to remove the need to ask AI in the first place.

The question I use now

So when I think about small tool ideas, I’ve stopped asking:

Can AI do this?

Instead, I ask:

Should the user have to ask AI to do this every time?

If the answer is no, there may still be a useful little tool hiding there.

And honestly, I find those small tools much more interesting to build.

Chrome Web Store Rejected My Extension for “Keyword Spam” — Here’s What I Changed

k-wada — Thu, 13 Aug 2026 12:45:08 +0000

I recently submitted a Chrome extension to the Chrome Web Store and got a rejection I wasn't expecting:

Keyword Spam.

The extension itself worked.

Its permissions were intentionally limited.

It didn't send user data to an external server.

The problem wasn't the code.

It was the store listing.

I Was Trying to Make the Extension Easy to Find

When you publish a Chrome extension, you have to write several pieces of text:

the extension name
a short description
a detailed description
feature explanations
privacy-related information

Naturally, you want people to understand what the extension does.

And you also want them to find it.

That's where I made a mistake.

I had repeated similar words and phrases across the listing because they accurately described the extension.

From my perspective, I was being explicit.

From the Chrome Web Store's perspective, the listing apparently looked too much like keyword stuffing.

The submission was rejected.

More Description Is Not Always Better

This was useful because it changed how I think about Chrome Web Store listings.

A product page is not a normal SEO article.

When writing an article, it can make sense to explain a topic using several related terms.

A store listing has a different job.

It needs to explain:

What does this extension do?

It does not need to contain every phrase someone might search for.

Trying to optimize too aggressively can actually make the listing worse.

What I Changed

I went back through the listing and removed wording that existed mainly for discoverability.

Instead of repeating multiple variations of the same concept, I tried to describe each function once, in plain language.

The basic rule became:

Describe the product, not the search queries you want to rank for.

I also checked whether each sentence helped a person understand the extension.

If removing a phrase didn't make the product harder to understand, I removed it.

That made the listing shorter and clearer.

The Difficult Part: There Is No Perfect Keyword Density

The rejection also exposed a practical problem.

There isn't a simple rule like:

Use a keyword no more than three times.

At least, that isn't a useful way to think about it.

A description can contain repeated terminology for legitimate reasons. Chrome extensions are often built around a very small number of concepts, so some repetition is unavoidable.

The better question is:

Would I still write this phrase if search ranking didn't exist?

If the answer is no, it probably deserves another look.

Store Optimization and SEO Are Different Problems

Before this rejection, I treated the Chrome Web Store listing partly like a small landing page.

Now I separate the two.

On my own website, I can write detailed articles around problems users may search for.

For example:

how to check information before sending it
how to inspect PDF metadata
how to build a Chrome extension
mistakes I made during Chrome Web Store review

Those pages can provide context and answer broader questions.

The Chrome Web Store listing can stay focused on the extension itself.

That division is much cleaner.

What I Learned

Publishing a Chrome extension involves more than getting manifest.json right.

The listing itself is part of the product.

After this rejection, my approach is now:

Explain exactly what the extension does.
Avoid unnecessary synonyms and repeated search phrases.
Keep the description readable for humans.
Put broader explanatory and search-oriented content on my own site.
Treat Chrome Web Store review feedback as product feedback, not just a hurdle to get past.

It was a small rejection, but a useful one.

Building the extension was not the part that caused the problem.

Trying too hard to help people find it was.

I Published a Chrome Extension — Then Found My Home Address on the Store Page

k-wada — Tue, 11 Aug 2026 06:50:16 +0000

After publishing one of my Chrome extensions, I opened its Chrome Web Store page to check how everything looked.

The description was there.
The screenshots looked fine.
The listing was live.

Then I scrolled down.

And saw an address I recognized immediately.

It was my home address.

I had been thinking about the user's privacy, not mine

For the extensions I build under Legacy Tools, I pay a lot of attention to privacy.

I try to:

keep processing inside the browser
avoid unnecessary permissions
avoid external network requests where possible
avoid collecting user input or detection results

I had reviewed permissions, data handling, and Chrome Web Store disclosures carefully.

But I had completely missed another category of information:

the developer's own information.

I had spent so much time thinking about what my extension might expose that I never seriously checked what publishing the extension might expose about me.

The reason was my trader status

Chrome Web Store asks developers to declare whether they are acting as a trader or a non-trader.

When I first completed the registration, I selected the trader option.

Here, "trader" does not mean someone trading stocks.

It refers to whether you are acting for purposes related to your trade, business, craft, or profession.

When I reviewed the information again, I realized that verified contact information associated with a trader can be displayed on the Chrome Web Store.

I had treated the address as information I was providing to Google for verification.

I had not understood that it could become information visible to users.

By the time I noticed, the extension was already public.

"Just choose non-trader" is not the lesson

My first reaction was obvious:

Then I should just switch to non-trader.

But that is not really the right way to think about it.

Trader status is not a privacy toggle.

You should not choose non-trader simply because you do not want your address to appear.

The declaration needs to match how you actually operate.

In my case, I reviewed the description and my current way of publishing Legacy Tools extensions, which are currently offered for free, and concluded that non-trader better matched my situation.

After I changed the setting, the address was no longer displayed on the store page.

But the important lesson was not the setting itself.

Developer identity is part of product design

Before this happened, I thought of developer registration as an administrative step at the end of the publishing process.

Build the extension.

Prepare the screenshots.

Write the description.

Pass the review.

Publish.

Done.

That was too simple.

If you plan to publish extensions as an independent developer, you should think about things like:

whose name will appear as the publisher
which address is associated with the developer account
which email address users will see
whether you should separate personal and public contact information
how your trader status affects the information shown to users

None of these questions change your JavaScript.

But they absolutely affect what it means to publish software publicly.

Check your own store page after publishing

Once an extension passes review, it is easy to feel that the job is finished.

I now think there is one more step.

Open the public Chrome Web Store listing exactly as a user would.

Scroll from top to bottom.

Do not only check the screenshots and description.

Check what information about you is being published alongside the extension.

I learned this only after finding my own home address on the page.

Publishing a browser extension is not only about deciding what your software reveals.

It is also about deciding what you, as the developer, reveal with it.

After Shipping 8 Chrome Extensions, These Are the 5 Rules I Always Give AI Agents

k-wada — Sat, 08 Aug 2026 17:01:20 +0000

AI agents can build Chrome extensions surprisingly fast.

After shipping eight extensions, though, I found that the biggest risks usually do not come from whether the code runs.

They come from what the agent quietly adds while trying to be helpful:

another permission
an external request
a new dependency
a refactor I did not ask for
a change in what user data is read or stored

All of those can affect security, privacy, maintenance, and Chrome Web Store review.

So before I ask an AI agent to implement anything, I now give it a small set of rules.

These are the five I use most often.

1. Do not add or broaden permissions without asking

Chrome extension permissions are part of the product.

If the agent adds:

"permissions": [
  "storage",
  "tabs"
]

or expands host_permissions, that is not just an implementation detail.

It changes what the extension is allowed to access and may change what users see during installation or what I need to explain during review.

So I explicitly tell the agent:

Do not add or broaden permissions without asking me first.

If a new permission is necessary, I want the agent to stop and explain:

which permission is needed
why it is needed
what feature requires it
whether there is a narrower alternative

The default should be minimum permissions, not “whatever makes implementation easier.”

2. Do not add network communication

A small local extension can easily become something very different if an agent introduces:

an external API
analytics
telemetry
a CDN
remote configuration
cloud storage

Sometimes these are useful.

But they should never appear accidentally.

For many of my extensions, I deliberately keep the design simple:

Web page
   ↓
Chrome extension
   ↓
chrome.storage.local

No server.

No account.

No external transmission.

That makes both the implementation and the privacy story easier to understand.

So my second rule is:

Do not add external network requests, analytics, telemetry, or CDN dependencies.

If network access is truly required, I want that to become a design decision before it becomes code.

3. Do not modify unrelated files or features

This one became more important as I started using coding agents for larger changes.

Suppose I ask:

Add a function that stores selected text in chrome.storage.local.

An agent may notice nearby code and decide to improve it too.

The result might work.

But now one small task has changed five files.

That makes review harder.

It also becomes difficult to answer a simple question:

What exactly changed because of this request?

So I usually add:

Do not modify unrelated files, features, or architecture.

For small Chrome extensions, I prefer changes that are easy to understand and easy to reverse.

I would rather make five small changes than one clever change that touches the entire project.

4. Do not add dependencies unless they are really necessary

AI agents are very good at finding packages.

That does not mean I want them.

If a 20-line utility function can solve the problem, adding another npm dependency may not be worth it.

Every dependency creates more things to understand:

supply-chain risk
updates
licenses
bundle size
build complexity
future maintenance

My rule is:

Do not add new dependencies unless they are necessary. If you think one is needed, explain why before adding it.

This is especially useful for browser extensions because many features can be implemented with the browser APIs and plain JavaScript.

Small tools benefit from staying small.

5. Stop before changing the data flow

This is the most important rule.

If an implementation changes:

what data is read
where data is stored
how long it is stored
whether data leaves the browser
which pages the extension can access

I do not want the agent to decide that silently.

I tell it:

If your change affects what data is read, stored, or transmitted, stop and explain the change before implementing it.

This turns data flow into an explicit design decision.

For example:

Selected text
    ↓
Content script
    ↓
chrome.storage.local
    ↓
Extension UI

If the agent wants to change that into:

Selected text
    ↓
Content script
    ↓
External API
    ↓
Extension UI

that is not a small implementation change.

It is a different product architecture.

I want to know before the code changes.

The prompt I actually reuse

Here is the short version I give coding agents:

When modifying this Chrome extension:

- Do not add or broaden permissions without asking me first.
- Do not add external network requests, analytics, telemetry, or CDN dependencies.
- Do not modify unrelated files or features.
- Do not add new dependencies unless they are necessary.
- If your change affects what data is read, stored, or transmitted, stop and explain the change before implementing it.
- Keep the implementation compatible with Manifest V3.

I usually add the task itself underneath this block.

For example:

Task:

Add the ability to save selected text to chrome.storage.local.

Do not change the list UI or reordering behavior.

The important part is that the agent receives both:

what I want it to do

and

what it is not allowed to decide on its own.

I still verify everything myself

These rules reduce surprises.

They do not replace review.

Before publishing, I still check:

[ ] Are all permissions necessary?
[ ] Did any host permissions become broader?
[ ] Are there unexpected network requests?
[ ] Did the agent add a dependency?
[ ] Do I know exactly what data is read?
[ ] Do I know exactly what data is stored?
[ ] Does any data leave the browser?
[ ] Does the Chrome Web Store declaration match the implementation?

I also load the extension through:

chrome://extensions

and use it on real pages before submitting it.

An extension can pass tests and still feel annoying, request too much access, or behave differently from the store description.

What changed after eight extensions

AI has definitely made implementation faster for me.

But after shipping eight Chrome extensions, I spend less time asking:

Can the agent build this?

and more time asking:

What decisions should the agent not be allowed to make?

That distinction has become one of the most useful parts of my workflow.

AI agents are good at completing tasks.

My job is to define the boundaries around those tasks.

For Chrome extensions, those boundaries are especially important because permissions, network access, dependencies, and data handling affect not only the code, but also what users are being asked to trust.

I am building and documenting these experiments as part of Legacy Tools, a collection of small browser tools.

The full development workflow I use — from choosing an idea to Chrome Web Store review — is also available on the Legacy Tools site.