DEV Community: Almost Brilliant Ideas

Windows 11 in Virt-Manager on Ubuntu, Why I Switched from UEFI to BIOS

Almost Brilliant Ideas — Sat, 04 Apr 2026 01:15:14 +0000

Setting up a Windows 11 VM in Virt-Manager on Ubuntu sounds easy enough until you discover:

· clipboard sharing does not work
· shared folders do not mount
· the SPICE guest agent crashes over and over

I burned a lot more time on this than I should have, and the problem turned out not to be one more missing guest tool.

It was the firmware choice.

The gotcha

Virt-Manager wants to use UEFI for Windows 11 by default, which makes sense on paper because Windows 11 expects TPM and Secure Boot. In practice, for this setup, UEFI was the thing that broke integration for me.

The fix was to rebuild the VM as a BIOS-based VM, then bypass the Windows 11 TPM and Secure Boot checks during setup. Once I did that, clipboard sharing and shared folders started behaving normally after the rest of the pieces were installed in the right order.

What finally worked

Here is the working order:

Create the VM in Virt-Manager
Before installation, switch firmware from UEFI to BIOS
Install Windows 11 using the usual LabConfig registry bypass
Install SPICE guest tools
Confirm vdservice is running
Add the memoryBacking block to the VM XML
Add a shared filesystem using virtiofs
Install VirtIO guest tools in the Windows VM
Install WinFSP
Set VirtioFsSvc to Automatic

That order mattered a lot more than I expected.

The Windows 11 bypass

If you install on a BIOS VM, Windows 11 will complain about unsupported hardware.

At the first setup screen:

· Press Shift + F10
· Run regedit
· Go to HKEY_LOCAL_MACHINE\SYSTEM\Setup
· Create a key named LabConfig
· Inside it, create these DWORD values and set each to 1:
BypassTPMCheck
BypassSecureBootCheck
BypassRAMCheck

After that, installation continues normally.

SPICE clipboard sharing

Once Windows 11 is installed, install the SPICE guest tools and reboot. Then check whether vdservice is running in an elevated PowerShell window:

Get-Service | Where-Object {$_.DisplayName -match "spice|vdagent"}

If needed:
Start-Service -Name "vdservice"
Set-Service -Name "vdservice" -StartupType Automatic

If your clipboard still does not work and vdservice keeps crashing in a loop, check the firmware choice first. In my case, UEFI was the real issue.

Shared folders with virtiofs

Shared folders took a few moving parts:

· host-side shared memory config
· virtiofs hardware added to the VM
· VirtIO guest tools in Windows
· WinFSP installed in Windows
· VirtioFsSvc switched to Automatic

On the host, I also had to add this block to the VM XML after the

section:

Then I added a Filesystem device in Virt-Manager using:

· Driver:virtiofs
· Source path: your shared folder
· Target path: a mount tag like vmshare

Inside the Windows VM, after installing VirtIO guest tools and WinFSP, I checked services again:

Get-Service | Where-Object {$_.DisplayName -match "virtio|winfsp|virtiofs"}

And then forced the VirtIO FS service to persist across reboots:

Start-Service -Name "VirtioFsSvc"
Set-Service -Name "VirtioFsSvc" -StartupType Automatic

That last step matters. If you skip it, the share may disappear again after reboot.

The main lesson

The biggest trap here was assuming the default UEFI path was the correct path just because Windows 11 prefers it.
For me, that was exactly what caused the clipboard and shared-folder headaches.

Once I rebuilt the VM using BIOS, then installed everything in the right order, the setup became stable.

I put the full write-up here, including the exact XML edit, the install order, and the troubleshooting notes:
How to Set Up a Windows 11 VM in Virt-Manager on Ubuntu

Why I Chose Not to Add Password Reset to an Offline Vault App

Almost Brilliant Ideas — Sat, 28 Mar 2026 19:36:31 +0000

I saw somebody on Reddit this morning basically arguing that a vault app without password recovery is not very useful.

I understand why people feel that way. We have all been trained by modern software to expect a reset link, an email, a backup code, some kind of escape hatch. If you forget a password, the system is supposed to help you. That is just normal now.

But that expectation starts to break down when the whole point of the app is that it is not built around accounts, cloud services, or somebody else holding onto part of the trust model for you.

That was one of the design choices behind Vaelri Vault™. No account. No cloud dependency. No server somewhere keeping tabs on you. And once you make those choices, password reset stops being some harmless convenience feature and starts becoming a contradiction you have to explain away.

Because what exactly is doing the resetting? That is the part people tend to skip over.

In a normal app, password recovery works because the company knows who you are, or at least knows enough to offer another route back in. Maybe that means email. Maybe it means text message. Maybe it means some recovery workflow tied to an account. Whatever the mechanism is, there is another path.

That is fine for a lot of software. It makes perfect sense for banking, shopping, social media, cloud storage, and all the other systems people use every day.

But if I am building an offline vault app, I do not really want there to be "another path."

I do not want a side door. I do not want a hidden little asterisk where the marketing says your files are under your control, but in practice there is still some recovery mechanism floating around in the background that has to be trusted too.

To me, that changes the product.

It might make it friendlier. It might make it easier to live with. It might even make it a better fit for a lot of people. But it is not the same trust model anymore.

And that is really what this comes down to.

People hear "no password reset" and think missing feature. I hear "password reset" and think, okay, what extra system are we adding, and who is responsible for securing it?

Because recovery is not magic. Recovery is access. It is just access through a second route. Maybe that route is well designed. Maybe it is encrypted. Maybe it is only there for emergencies. But it is still another route, and if your whole pitch is local-only control, that matters.

Now, none of this means people who want password recovery are wrong.

Honestly, for a lot of users, they are making the practical choice. Plenty of people would rather accept a little more dependency in exchange for a safety net. I get that. Most people are not trying to make some philosophical point about trust boundaries. They just do not want to lose their files because they had a bad week and forgot a password.

That is reasonable.

But I do think there is a difference between saying "this tradeoff is not for me" and saying "this kind of app is not useful."

For some users, the lack of password reset is exactly the point.

They do not want their encrypted files tied to an email address. They do not want account recovery. They do not want to depend on a server being there later. They do not want the company behind the app to have any role at all in whether access can be restored.

They want the responsibility, even though responsibility is annoying.

And that is the part modern software has trained people to dislike. Responsibility is not a fun feature. There is no warm fuzzy UX around it. There is just the reality that if you are serious about local-only encryption, some conveniences go away.

That does not make the app broken. It just means the design is honest about what it is.

I would rather be upfront and say, if you forget the password, there may be no way back in, than pretend there is some perfectly safe recovery flow that does not change the basic trust model.

There probably are ways to build softer edges around this. Backup keys, recovery files, other systems. But every one of those comes with its own tradeoffs, and I did not want to quietly smuggle those tradeoffs into a product whose whole point was keeping things on-device and under the user's control.

So no, I do not think a vault app without password recovery is useless.

I think it is a specific kind of tool, built for people who care more about control than convenience, and who understand that those two things do not always get along.

I wrote a more plain-English version of that tradeoff here: When There Is No Password Reset

How Android Actually Protects Data Stored on Your Device

Almost Brilliant Ideas — Wed, 11 Mar 2026 23:32:01 +0000

When people talk about mobile security, the conversation usually jumps straight to encryption algorithms.

AES
Key lengths
Military-grade encryption

But on modern Android devices, the real story is less about algorithms and more about architecture.

Android has quietly evolved into a platform with several layers of protection designed specifically to secure data stored locally on the device.

If you're building privacy-focused applications, understanding these layers is important.

Let’s look at what’s actually happening under the hood.

1. Android File-Based Encryption

Modern Android versions use file-based encryption (FBE).

Instead of encrypting the entire disk with a single key, Android encrypts individual files using keys tied to the user profile.

This allows Android to do things like:

Boot the device before the user unlocks it
Allow limited services to run before login
Keep user data encrypted until authentication

In practical terms, it means the operating system can start normally while sensitive files remain inaccessible.

2. The Android Keystore

One of the most important security components for developers is the Android Keystore system.

The Keystore allows apps to generate and store cryptographic keys in a way that prevents those keys from ever being extracted.

Instead of retrieving the key directly, an app asks the Keystore to perform operations like:

encryption
decryption
signing

The key never leaves the secure environment.

This dramatically reduces the risk of key theft, even if malware gains some level of system access.

3. Hardware Security Modules

On many modern phones, the Keystore is backed by dedicated hardware.

These may be implemented as:

Trusted Execution Environments (TEE)
Secure Enclaves
Hardware Security Modules

These components run separate from the main operating system and are designed to isolate sensitive cryptographic operations.

Even if Android itself were compromised, extracting keys from this hardware is extremely difficult.

4. App Sandboxing

Android isolates every application using a sandbox model.

Each app runs under its own Linux user ID, meaning:

Apps cannot access other apps' files
Memory spaces are separated
Permissions must be explicitly granted

For security apps and encrypted vaults, this isolation is essential.

It ensures that even if another app becomes compromised, it cannot automatically read protected data from your app’s storage.

5. Biometric Gatekeeping

Android also allows apps to integrate biometric authentication such as:

fingerprint
face unlock

Importantly, biometric data itself is not exposed to apps.

Instead, the operating system simply returns a yes/no result confirming that the user authenticated successfully.

This allows apps to protect sensitive data without ever handling biometric information directly.

Why This Matters for Privacy-Focused Apps

Taken together, these systems create a strong foundation for local-first security applications.

Apps can encrypt sensitive data using keys protected by the Android Keystore while relying on hardware-backed protections and sandboxing.

This is one reason some developers are exploring privacy tools that store encrypted data entirely on the device rather than syncing it to cloud services.

If you're curious what that architecture looks like in practice, this article explains how an offline encrypted vault for Android can keep sensitive data fully local:

Offline Encrypted Vault for Android

The idea is simple: treat the phone like a secure container rather than a cloud client.

Final Thought

Security isn’t just about choosing a strong cipher.

It’s about designing systems that reduce the number of places sensitive data can exist.

Android’s modern security architecture makes it possible to build applications where encrypted data never leaves the device at all.

For many privacy-focused use cases, that’s a powerful design choice.

Why Offline Encryption Still Matters on Android

Almost Brilliant Ideas — Tue, 10 Mar 2026 23:10:36 +0000

For the last decade, most consumer security products have moved toward the cloud.

Cloud password managers.
Cloud backups.
Cloud-synced secure notes.

Convenience is great, but it also introduces a fundamental trade-off: data that leaves your device can be copied, logged, or breached somewhere else.

That’s why a growing number of privacy-focused developers and security professionals are revisiting an older concept that never actually went away:

Offline encryption.

Instead of assuming the network is safe, offline encryption assumes the opposite.

Your data stays on your device. The encryption happens locally. And nothing is transmitted unless you explicitly export it.

Let’s talk about why that approach still matters in 2026.

The Cloud Convenience Problem

Cloud storage solves a real problem: synchronization.

But it also creates new risks.

When sensitive information is stored in a cloud-linked vault, several things happen behind the scenes:

Encrypted blobs are uploaded to remote servers
Metadata about accounts and devices may be logged
Authentication infrastructure becomes part of the security model
Recovery mechanisms introduce additional attack surfaces

Even if encryption is strong, the overall system becomes larger and more complex.

And complex systems fail in complex ways.

Many large security incidents over the past few years didn’t break encryption at all.

They exploited:

Account recovery systems
API misconfigurations
Token leaks
Server-side logging

None of those require breaking AES.

They just require data to exist somewhere other than your device.

What Offline Encryption Does Differently

Offline encryption flips the model.

Instead of assuming remote infrastructure is trustworthy, it assumes the device is the only trusted environment.

That means:

Encryption happens locally
Data never leaves the device unless exported
No accounts are required
No remote servers store encrypted copies
No subscription infrastructure exists

The security model becomes dramatically simpler.

And simplicity is often the most underrated security feature.

Why Android Is an Interesting Platform for This

Android has quietly become a very strong platform for local encryption.

Modern Android devices include:

Hardware-backed keystores
Secure enclaves
File-based encryption
Biometric authentication APIs
Strong sandboxing between apps

Developers can build vault systems that never require internet access at all.

That creates an interesting design space for privacy-first apps that behave more like digital safes than cloud services.

When Offline Storage Makes Sense

Offline encryption isn’t for everything.

If you need real-time synchronization across devices, cloud infrastructure is unavoidable.

But there are plenty of cases where local storage is actually the better model:

Sensitive documents

Private notes

Emergency contact information

Backup passwords

Financial details

Personal records

In those cases, the goal isn’t collaboration.

The goal is control.

And the easiest way to control data is to keep it in one place.

A Real Example: Offline Vault Apps

Some newer Android security tools are exploring this approach again.

For example, offline encrypted vault apps store everything locally and never connect to external servers.

If you're curious what that architecture looks like in practice, this breakdown of an offline encrypted vault for Android explains the design choices behind keeping sensitive data fully on-device:

Offline encrypted vault for Android

It walks through the core idea: treating a phone like a secure container, not a cloud client.

The Return of Local-First Security

Over the last few years, we’ve seen a broader movement toward local-first software.

Applications where:

Data lives on the device
Encryption happens locally
Servers are optional rather than required

Offline encryption fits naturally into that philosophy.

Instead of trusting infrastructure you don’t control, you rely on hardware that’s already in your pocket.

For many privacy-minded users, that trade-off is worth it.

Final Thought

Security isn’t just about algorithms.

It’s about architecture.

A system that never sends data anywhere has an advantage that no encryption algorithm can replicate.

Sometimes the safest data is simply the data that never leaves your device.

Walking Into an Unknown Network: The First Thing I Check

Almost Brilliant Ideas — Sat, 07 Mar 2026 23:35:12 +0000

When I walk into a client network for the first time, I usually don’t know much about it.

Sometimes the client thinks they know what’s on the network. Sometimes they don’t. Either way, the first problem isn’t troubleshooting.

The first problem is situational awareness.

Before I can diagnose anything, I need to understand what’s actually there.

What devices exist on the network?
What IP addresses are active?
Is anything new?
Did something disappear since the last scan?

Without that context, you’re basically working blind.

The Reality of Most Network Scanners

Most mobile network scanners work the same way.

You run a scan and you get a list like this:

192.168.1.10  DESKTOP-9F2A
192.168.1.12  ESP-4D21
192.168.1.15  android-71bf
192.168.1.18  UNKNOWN

Technically that’s useful. It tells you which IPs respond.

But when you're standing in an office trying to figure out what changed after you just rebooted a device or unplugged something, it doesn’t really answer the question you care about.

The real question is:

What changed?

Did a new device appear?

Did a device disappear?

Did something that was offline come back?

That kind of information is much more useful when you're troubleshooting.

The Problem With Single Snapshots

Most scanners give you a snapshot of the network at that moment.

That’s useful, but in the field you usually need something slightly different.

A typical workflow looks more like this:

Walk into the environment and run a scan
Look at what devices are present
Make a change (restart something, unplug something, fix something)
Scan the network again

Now you want to see what changed between those two scans.

Maybe a device disappeared.

Maybe something came back online.

Maybe a new device showed up after a reboot.

For example, the first scan might look like this:

Router
Printer
Lucy's Workstation
Conference Tablet
Security Camera

Then after you restart a device or reconnect hardware, the second scan might look like this:

Router
Printer
Lucy's Workstation
Conference Tablet
Security Camera
Unknown Device

That difference is often the clue you need.

In many troubleshooting situations, the two scans are only minutes apart. The goal is simply to make changes visible so you don’t have to manually compare two long device lists.

Situational Awareness

In the field, situational awareness is everything.

If something strange is happening on a network, it’s often because something changed:

a new device appeared
a device dropped off the network
an IoT device reconnected
someone plugged in a random piece of hardware

Being able to quickly see those changes makes troubleshooting much easier.

Instead of guessing, you start with a clear map of the environment.

What I Actually Check First

When I connect to a network, the first thing I want is a quick scan of the subnet.

From that scan I’m looking for three things:

New devices
Missing devices
Devices that came back online

If I’ve just made a change to the network, those differences usually jump out immediately.

That gives me context for whatever problem I was called to solve.

Making Scan Results Readable

Another small but important thing is naming devices.

Hostnames on real networks are often useless:

DESKTOP-4F12
ESP-71B3
UNKNOWN

When you rename devices, the scan becomes much more readable:

Front Desk Printer
Lucy's Workstation
Security Camera
Conference Tablet

Now the scan becomes something closer to documentation.

The Tool I Ended Up Building

After doing this kind of work for years, I eventually built a small Android tool that focuses on situational awareness instead of just listing IP addresses.

One of the most useful features turned out to be very simple: highlighting what changed between scans.

Blue shows a device that just appeared on the network
Red shows a device that disappeared
Green shows a device that came back online
White/gray shows devices that are still present

Instead of manually comparing two device lists, the differences jump out immediately.

The tool also:

automatically detects the subnet
scans the network quickly
allows devices to be renamed so results make sense

It supports scanning larger networks (up to /22) and includes a few optional port scan modes when you want a little more detail.

The goal wasn’t to replace full network analysis tools.

It was to make the first step of troubleshooting fast and clear.

If you're curious, the tool is called EasyIP Scan™.

https://easyipscan.app

Simple Android Encryption With No Accounts or Subscriptions

Almost Brilliant Ideas — Tue, 03 Mar 2026 18:47:14 +0000

Most people building an Android encryption app start with a familiar checklist: strong crypto, easy UX, maybe a cloud backup, password reset, and an account system to support recovery.

But if your goal is true offline encryption, that checklist breaks. You cannot have password reset or account login without a cloud backend. And that’s the point.

In this post I’ll explain why eliminating accounts and server-side recovery isn’t a missing feature, it’s a deliberate security design.

Why Most Apps Include Accounts and Recovery

In traditional apps, a “password reset” exists because the system:

Knows who you are (you have an account),
Has a trusted channel to verify you (email, SMS),
And stores enough state to allow resets.

This model works because the company controls infrastructure.
Your encrypted data is either stored on their servers or synced through them.

If you forget your password, a reset is possible only because a second party holds the keys.

For many products that’s fine. Convenience matters. Support kits exist to fix forgotten passwords.

But this convenience has a trade-off: someone else has control.

What True Offline Encryption Actually Means

An offline encryption app operates fully locally:

No accounts,
No servers,
No cloud backup,
No central authority that can intervene.

Encryption keys are derived locally, on the device, from your password. There’s no account database. No master reset.

That means:

If you forget your password, there’s no reset
If you want cloud recovery, you’re giving someone else control
If you want strong protection without server trust, you accept responsibility

This isn’t a flaw or missing feature. It’s a consequence of the security model.

The Trade-Off

There are two basic architectural choices:

With accounts and cloud servers:

You get password reset and convenience
You give up independence and absolute control

With fully offline encryption:

You get independence and control
You give up password reset and server-side recovery

Neither is inherently better. They are different trade-offs. But when the goal is local encryption that does not rely on third parties, you must choose independence.

Why No Reset Is a Security Feature

If password resets are possible, they introduce another attack surface.

Consider:

If an attacker controls your email, they can trigger resets
If a company stores escrowed keys, they can be coerced
If servers are breached, recovery mechanisms can be abused

If there is no server to reset your password, there’s no recovery channel to exploit.

This is the structural reality of local encryption:

Only the correct password unlocks the data.

Practical Implications

Before building offline encryption, understand:

You must choose a strong password
Forgetting it means losing access
That responsibility shifts from cloud to user

This sounds harsh, but it’s honest. True cryptography doesn’t negotiate with identity documents, support tickets, or reset links. It responds only to the correct key.

Calm Trade-Offs

There’s no need for dramatic language. The trade-off is straightforward:

With accounts

You gain recovery. You lose control.

Offline encryption

You gain control. You lose recovery.

Both are legitimate choices. For Vaelri Vault, the choice was independence and local control.

Designing for the Long Term

Offline encryption also decouples your data from external business lifecycles.

Cloud services can:

Change policies
Be acquired
Shut down
Change APIs

Offline encryption stored locally isn’t dependent on any of that. As long as the app runs and you have the password, the data is accessible.

Independence costs recovery.
That is not a flaw. It’s the point.