DEV Community: k-wada

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.