There is a point in almost every security project where you realize:
The cryptography isn't the whole security model.
When I started building ATLOCK, I initially thought the interesting problems would be encryption, authentication, file protection, and intrusion detection.
They were.
But the deeper I went, the more I realized that the hardest questions were actually:
Where does the secret live?
Who can access the evidence?
What happens when detection is wrong?
Which security mechanisms should I build—and which should I leave to Windows?
That became the philosophy behind ATLOCK v4.
🚀 What is ATLOCK?
ATLOCK is a portable Windows security suite I've been developing as an independent project.
The goal isn't to replace Windows Security, BitLocker, enterprise EDR, or established password managers.
Instead, I wanted to explore something more specific:
What does a practical, local-first Windows security application look like when several security utilities are brought together?
The current architecture includes:
ATLOCK v4
│
┌────────────┼────────────┐
│ │ │
File Security Credential Intrusion
│ Security Ops
│ │ │
NTFS/ACL Password Detection
Vault │
│
Local Evidence
│
Security Alerts
The entire concept revolves around keeping the core security workflow on the Windows machine.
🛡️ 1. NTFS/ACL Instead of Reinventing Windows
One of the decisions I'm happiest with was using Windows' existing NTFS security model and ACLs rather than trying to recreate a lower-level permissions system.
This sounds obvious.
It isn't always.
When you're building a security application, there's a temptation to create your own primitive because it feels more technically impressive.
But rebuilding a battle-tested operating-system security mechanism isn't automatically better engineering.
Sometimes the better decision is:
Use the security mechanism the operating system already understands, and build useful functionality around it.
That means ATLOCK can work with Windows' existing permission model rather than inventing another one.
🔑 2. The Password Vault
The password vault uses:
Fernet for authenticated encryption and PBKDF2-HMAC-SHA256 for deriving the encryption key from the user's master passphrase.
But there's an important distinction here.
Saying:
“My passwords are AES encrypted.”
doesn't tell you much about the actual security model.
The real questions are:
How is the key derived?
How long is the derivation?
Where does the master secret come from?
Is the secret persisted?
What happens when the application closes?
What happens if the local machine is compromised?
Those questions are much more interesting than simply naming the cipher.
And they're areas I'm continuing to scrutinize in ATLOCK.
📸 3. Intruder Ops
This is probably the most visually interesting feature.
ATLOCK can react to repeated unauthorized access attempts with local security responses, including webcam-based evidence capture, video recording, and alerts.
Conceptually:
Authentication Attempt
│
▼
Failed Attempt
│
▼
Attempt Threshold
│
▼
Intrusion Event
│
┌────┼────────────┐
▼ ▼ ▼
Photo Video Alert
│ │ │
└────┴──────┬─────┘
▼
Local Evidence
But this feature also introduced one of the biggest privacy questions in the project.
What if the detection is wrong?
A webcam feature can capture the wrong person.
A local evidence system can become sensitive data storage.
So “the footage stays local” isn't the end of the security discussion.
You still have to think about:
false positives
access permissions
evidence storage
retention
unauthorized access to captured media
That's an important lesson I've learned while developing ATLOCK:
A security feature can create a new security problem if its surrounding controls aren't designed carefully.
🔔 4. Local Security Events
ATLOCK also provides local notifications and alerts around security events.
The objective is to make security activity visible without requiring a cloud dashboard.
That fits the larger architecture:
Security Event
│
├── Detection
│
├── Local Response
│
└── Local Notification
The application doesn't need a remote server just to tell you that something happened on your own computer.
⚙️ 5. Why Portable?
ATLOCK is distributed as a portable Windows application.
The basic workflow is intentionally simple:
Download
↓
Run
↓
Configure
↓
Protect
No account creation is required for the core application.
The goal was to make the security utility feel like something you can run when you need it rather than another service permanently tied to an online account.
🧠 The Biggest Lesson
Here's the thing I didn't expect when I started:
Security engineering is mostly about trade-offs.
You can add encryption.
You can add authentication.
You can add intrusion detection.
You can add logging.
You can add telemetry.
You can add cloud synchronization.
You can add AI.
But every addition creates another question.
More features
↓
More code
↓
More dependencies
↓
More attack surface
↓
More things to secure
So I've started asking a different question:
“Do we actually need this?”
rather than:
“Can I build this?”
That mindset has changed how I develop ATLOCK.
🔒 Why Local-First?
I'm not claiming that cloud software is inherently insecure.
That's an oversimplification.
Cloud architectures can be extremely secure when designed properly.
But a local-first architecture has one interesting property:
Data that never leaves the machine doesn't need a network transmission path.
And data you never collect doesn't become another database you have to protect.
That's the philosophy I'm experimenting with.
🧪 ATLOCK Is Still an Experiment
ATLOCK isn't a finished answer to Windows security.
It's a project I'm actively developing.
And that's exactly why I'm publishing the technical decisions publicly.
I want developers to question them.
Tell me where the threat model is weak.
Tell me where the architecture could be better.
Tell me what I overlooked.
Because security software shouldn't be evaluated only by how impressive its feature list looks.
It should survive questions.
🚀 Try ATLOCK v4
If you're interested in Windows security, privacy-first software, Python development, or independent software projects, I'd genuinely appreciate you testing it.
👉 ATLOCK v4 — [https://github.com/Akhouri-Anmol-Kumar/ATLOCK]
And here's the question I'd most like to hear from other developers:
If you were reviewing ATLOCK's threat model, what would you attack first?
Not the UI.
Not the feature list.
The architecture.
ATLOCK
"We Build What Others Forgot To Fix"
Top comments (0)