DEV Community: Ethan

Threat Modeling Isn’t Just for Big Apps (And That’s a Problem)

Ethan — Mon, 26 Jan 2026 04:21:33 +0000

When people hear “threat modeling,” they often picture large systems, distributed architectures, or enterprise security reviews.

Small tools—especially desktop utilities—rarely get the same treatment. I used to think that made sense. Now I’m not so sure.

Building smaller, local-first tools has convinced me that threat modeling matters just as much at small scale, if not more.

Small Tools Handle Big Secrets

A surprising number of “simple” apps regularly touch sensitive data:

Clipboard managers
Password utilities
Note-taking apps
Developer tools
File converters

The difference isn’t what data they handle—it’s how casually that responsibility is treated.

Because these tools feel small, their threat surface is often ignored.

A Simple Threat Model Goes a Long Way

Threat modeling doesn’t need to be formal or heavyweight. For small tools, I’ve found a few basic questions cover most of the risk:

What data does this tool ever see?
Where is that data stored?
How long does it live there?
When is it decrypted?
What happens if the app crashes?
What happens if the system sleeps or locks?

Answering these early tends to expose design flaws fast.

Local-First Doesn’t Mean Risk-Free

One misconception I had early on was that avoiding the cloud automatically made things “safe.”

Local-first shifts the threat model, but it doesn’t eliminate it.

New risks appear instead:

Disk access by other processes
Memory persistence
Crash dumps
Backups you didn’t intend to create
OS-level indexing or search

If you don’t think about these explicitly, you end up with a false sense of security.

Trust Is About Failure Modes

Most apps behave well when everything works.

Trust is built when things don’t:

Unexpected shutdowns
Power loss
App crashes
User walks away mid-task

Designing for failure—clear locking behavior, predictable state resets, minimal data leakage—is one of the fastest ways to increase user trust.

Why I Start With “What Could Go Wrong?”

I’ve started approaching new features with a different first question:

“What’s the worst reasonable thing that could happen if this fails?”

That single question has:

Killed features early (in a good way)
Simplified designs
Reduced hidden state
Made security tradeoffs explicit

It’s much easier to remove a risky idea early than to bolt safeguards on later.

Small Projects Are Where Good Habits Form

If anything, small tools are the best place to practice disciplined security thinking.

There’s less inertia.
There are fewer stakeholders.
You can afford to be deliberate.

Those habits carry forward.

Closing Thought

Threat modeling doesn’t have to be formal, scary, or academic.

For small tools, it can be as simple as caring enough to ask uncomfortable questions early—and being willing to simplify when the answers aren’t great.

If you’re building utilities that touch user data, even briefly, it’s worth slowing down and thinking about failure and misuse before shipping the next feature.

Open Questions

Do you explicitly think about threat models when building small tools?
Have you ever removed a feature because it felt too risky?
Where do you think most “small app” security failures come from?

Interested to hear how others approach this.

Building a Clipboard Manager Taught Me More About Trust Than UX Ever Did

Ethan — Sun, 25 Jan 2026 06:57:01 +0000

When I started building a clipboard manager, I assumed the hardest parts would be UI polish or performance tuning. I was wrong.

The real challenge turned out to be trust how data is handled, where it lives, and how predictable the tool is when things go wrong.

This post walks through a few lessons that surprised me while building a privacy-first, offline clipboard tool.

The Clipboard Is More Sensitive Than It Looks

A clipboard isn’t just text.

In real usage, it often contains:

Passwords
API keys
Access tokens
Internal URLs
Personal or client data

Yet many clipboard tools treat this data as low-risk, storing it indefinitely or syncing it by default.

Once I framed the clipboard as high risk transient data, most design decisions became obvious.

Local Storage Changes the Threat Model

By committing to local only storage, a few things changed immediately:

No assumptions about network availability
No silent sync failures
No ambiguity about where data lives

But it also forced explicit answers to uncomfortable questions:

How long should clipboard history persist?
Should sensitive entries expire automatically?
What happens if the app crashes mid-write?

Offline first doesn’t remove complexity it relocates it.

Encryption Isn’t Enough on Its Own

It’s tempting to say “just encrypt it” and move on.

In practice, encryption raises more questions:

When is data decrypted?
How long does it stay in memory?
What happens on lock, sleep, or crash?
Who controls the key lifecycle?

I learned quickly that encryption without lifecycle discipline is mostly theater. The hard part is deciding when not to decrypt at all.

UX vs Safety Is a False Dichotomy

One assumption I had going in was that strong security would make the tool less pleasant to use.

What I found instead:

Predictable behavior feels safer and faster
Explicit controls reduce user anxiety
Fewer “smart” automations mean fewer surprises

Power users, especially, seem willing to trade a bit of convenience for clarity.

Small Tools Expose Big Design Mistakes

Clipboard managers are deceptively simple.

There’s nowhere to hide bad decisions:

Startup time matters
Memory usage matters
Edge cases show up fast
Bugs erode trust immediately

This made the project an excellent forcing function for better engineering discipline.

What I’d Do Differently Next Time

If I were starting over:

I’d design the threat model before the UI
I’d document security assumptions earlier
I’d test failure scenarios sooner
I’d spend more time on data lifecycle diagrams

Most importantly, I’d ask “what would break user trust here?” before asking “what feature should I add?”

Closing Thoughts

Building small, local tools has been a reminder that trust is cumulative and fragile.

You don’t earn it with features.

You earn it by being predictable, transparent, and boring in the right places.

If you’re building utilities that handle sensitive data even briefly—I’d encourage you to think about trust as a first-class design constraint.

Open Questions

Do you treat clipboard data as sensitive by default?
Would you accept fewer features in exchange for stronger guarantees?
Are there tools you stopped using because they became too smart?

Curious to hear how others approach this.

Why I Started Building Offline First, Privacy Focused Tools.

Ethan — Sun, 25 Jan 2026 06:39:35 +0000

Most software today assumes connectivity, telemetry, and cloud sync by default. For many use cases, that’s convenient. For others—especially productivity and developer tools it introduces unnecessary risk, complexity, and friction.

This post explains why I’ve been deliberately building offline-first, privacy focused tools, and what tradeoffs that choice comes with.

The Problem With “Cloud by Default”

Over the years, I noticed a recurring pattern in tools I relied on daily:

Features tightly coupled to external services
Data stored remotely without clear guarantees
Security models that assume trust instead of enforcing it
Apps that stop working or degrade badly when offline

For things like note taking, clipboard management, or developer utilities, this felt backwards. These tools often handle sensitive data, yet are frequently treated as disposable frontends to a backend you don’t control.

What “Offline First” Actually Means (To Me)

Offline first doesn’t mean “never networked.” It means:

The tool works fully without an internet connection
Core functionality does not depend on third-party services
Data is stored locally by default
Sync, if it exists, is optional and explicit

This approach forces better engineering discipline:

Clear data ownership
Fewer hidden dependencies
Easier debugging
Predictable performance

Privacy Is a Design Constraint, Not a Feature

A mistake I see often is treating privacy as a checkbox at the end of development.

Instead, I treat it as a constraint from day one:

No analytics unless absolutely necessary
No background network calls
Minimal data retention
Encryption where it actually matters

This simplifies architecture. When you remove the assumption that “we can always phone home,” the design gets leaner and more intentional.

Tradeoffs (Because There Are Always Tradeoffs)

This approach isn’t free:

No effortless multi-device sync
More responsibility on the user
Fewer growth shortcuts
Slower initial adoption

But the upside is trust. Users understand where their data lives, how it’s handled, and what the tool does and doesn’t do.

For the kinds of tools I care about, that tradeoff is worth it.

What I’m Building Toward

I’m particularly interested in:

Desktop utilities
Developer tools
Productivity software that stays out of the way
Self-hosted or local-only systems

I plan to write more about:

Architecture decisions
Security tradeoffs
UX for power users
Shipping and maintaining small tools long-term

Open Questions

I’m curious how others here think about this:

Do you actively avoid cloud-dependent tools?
Where do you draw the line between convenience and control?
Are there tools you’ve replaced specifically for privacy or offline reasons?

Looking forward to learning from the community.