DEV Community: Akhouri Anmol Kumar

What Actually Happens When ATLOCK Protects a File on Windows?

Akhouri Anmol Kumar — Thu, 13 Aug 2026 10:43:19 +0000

When people hear “file protection”, the first thing they usually think about is encryption.

But encryption isn't the only way to protect a file.

While building ATLOCK v4, I ended up going deeper into a different part of Windows security:

NTFS Access Control Lists (ACLs).

And the more I worked with them, the more interesting the distinction became.

🔐 Two Different Security Problems

Consider these two questions:

Who is allowed to access this file?

and:

What happens if someone obtains the underlying data?

They're different problems.

ATLOCK approaches them differently.

                ATLOCK
                   │
      ┌────────────┴────────────┐
      │                         │
  FILE GUARD               PASSWORD VAULT
      │                         │
   NTFS ACLs                  Fernet
      │                         │

Access control Authenticated encryption

That's an important architectural distinction.

File Guard → NTFS ACLs

Windows already has a sophisticated authorization model.

NTFS permissions can define access for users and groups through an ACL containing access-control entries.

Conceptually:

┌──────────────────────┐
│ PROCESS │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Windows Access Token │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ NTFS ACL / ACEs │
└──────────┬───────────┘
│
┌────┴────┐
▼ ▼
ALLOW DENY

The important part is that the decision isn't purely made by ATLOCK.

Windows participates in the authorization process.

That means ATLOCK can work with an existing operating-system security primitive instead of inventing a completely separate file permission system.

Why Not Encrypt Every Protected File?

Because encryption and authorization have different jobs.

Imagine a file containing:

Project/
├── design.pdf
├── notes.txt
└── source.zip

If I encrypt everything, I introduce a cryptographic data-protection layer.

If I modify access permissions, I'm changing who Windows permits to interact with those objects.

Those are not equivalent.

A useful mental model is:

                DATA
                  │
      ┌───────────┴───────────┐
      │                       │
Confidentiality          Authorization
      │                       │
  Encryption                ACLs
      │                       │
 "Can it be read?"     "Can it be accessed?"

That distinction influenced how I designed ATLOCK.

Password Vault → Cryptography

The Password Vault is a different problem.

Here, encryption is fundamental.

ATLOCK uses Fernet for the vault.

At a high level:

Master Password
│
▼
PBKDF2-HMAC-SHA256
│
▼
Derived Key
│
▼
Fernet
│
▼
Encrypted Vault Data

The Fernet construction provides authenticated encryption using:

AES-128-CBC + HMAC-SHA256

The important point isn't simply saying:

“It's AES.”

A secure design also needs to consider key derivation, authentication, integrity, key handling, and failure behavior.

That's where cryptographic implementations become more than a checkbox.

Intruder Ops → Event Handling

Then there's Intruder Ops.

The interesting engineering problem here isn't simply:

failed attempt → camera

The real workflow is closer to:

Access Event
│
▼
Authentication / Failure Logic
│
▼
Configured Trigger
│
├───────────────┐
▼ ▼
Alert Evidence Capture
│
▼
Local Storage

And hardware makes this considerably more annoying.

A webcam might be:

unavailable
disconnected
already occupied
slow to initialize
returning an error
behaving differently across systems

A security event shouldn't freeze the application's UI while hardware initialization happens.

That forced me to think about the capture process as an asynchronous workflow rather than simply calling a camera operation and waiting.

The Real Security Problem Isn't the Feature

This is probably the biggest thing I've learned while building ATLOCK.

Adding:

🔒 File Protection

doesn't automatically make software secure.

Adding:

🔐 Encryption

doesn't automatically make software secure.

Adding:

📸 Intruder Detection

doesn't automatically make software secure.

The interesting questions come afterward.

What happens when things fail?

For example:

ACL modification fails
↓
Did the application detect it?
↓
Was the previous state preserved?
↓
Was the user informed?
↓
Can the operation be safely retried?

Or:

Camera unavailable
↓
Does Intruder Ops crash?
↓
Does the UI freeze?
↓
Is the event still recorded?
↓
Does the application recover?

Security engineering is often less about the happy path and more about the paths nobody wants to test.

🧠 Threat Modeling Changed How I Think About ATLOCK

The more I build, the less interested I am in asking:

“How many security features does ATLOCK have?”

I'd rather ask:

“What threat is this feature actually addressing?”

For example:

Component Primary purpose
NTFS ACLs Authorization
Fernet Confidentiality + integrity/authentication
PBKDF2 Password-based key derivation
Intruder Ops Local response to configured access failures
Lockdown Restricting interaction with the application/system workflow

This makes feature design much more intentional.

⚠️ And There Are Still Questions

ATLOCK is an independent project, not a replacement for Windows' entire security architecture or enterprise endpoint protection.

There are still things I want to investigate more deeply:

ACL inheritance edge cases
Recovery from failed permission changes
Privilege boundaries
Local evidence protection
Process termination and crash behavior
Camera/device failure handling
Authentication state management
Threat modeling against different local attackers

That's the part I'm enjoying most.

Not adding another button.

Finding the boundary where the button actually matters.

🔥 Why I'm Writing About This

A lot of software development content focuses on:

“Look what I built.”

I'm increasingly interested in:

“Here's why I built it this way.”

Because architecture decisions have consequences.

Choosing an existing OS security primitive instead of inventing one.

Separating authorization from encryption.

Treating hardware operations as failure-prone.

Thinking about the threat model before adding another security feature.

Those decisions matter far more than how impressive a feature list looks on a landing page.

Final Thought

ATLOCK started as an application.

For me, it's becoming something more useful:

a practical laboratory for learning how security software actually behaves in the real world.

Every bug teaches something.

Every failed implementation exposes an assumption.

Every user question reveals a blind spot.

And every technical criticism gives me another angle I hadn't considered.

That's the part of building software I don't want to lose.

Don't just build features.

Understand the system those features are entering.

🔒 ATLOCK v4 — Akhouri Systems

GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

ATLOCK

"We Build What Others Forgot To Fix"

I Didn't Encrypt the Files. I Changed Who Windows Allows to Touch Them.

Akhouri Anmol Kumar — Wed, 12 Aug 2026 11:20:05 +0000

When I started building ATLOCK, I initially thought about file protection as an encryption problem.

Then I realized something:

Encryption and access control solve different problems.

So for ATLOCK's File Guard, I went in a different direction.

Instead of encrypting every protected file, ATLOCK uses Windows NTFS Access Control Lists (ACLs) to control which identities are allowed to access protected files and directories.

That sounds simple.

The implementation isn't.

🔒 Why NTFS ACLs?

Windows already has a permission system capable of controlling access to files and directories.

NTFS ACLs allow permissions to be defined around things such as:

Users
Groups
Read access
Write access
Modify access
Full control
Inheritance
Explicit deny/allow rules

So rather than inventing a completely separate permission layer, ATLOCK can work with a mechanism Windows already understands.

The basic idea becomes:

User
↓
Windows Security Token
↓
NTFS Access Check
↓
ACL Evaluation
↓
Allow / Deny
↓
File System

That gives ATLOCK an interesting property:

The operating system itself participates in the access-control decision.

🧠 Encryption vs. Access Control

This distinction became one of the most important design decisions in ATLOCK.

Encryption asks:

“Can someone read this data without the key?”

Access control asks:

“Is this identity allowed to access this object?”

Those aren't interchangeable.

For example, a protected file can remain completely normal on disk while its NTFS permissions determine who can interact with it.

That's useful for a tool like ATLOCK because I wanted the File Guard feature to integrate with the Windows filesystem rather than creating a completely separate encrypted container format.

🔐 The Password Vault is Different

The Password Vault has a different security requirement.

Here, encryption is the point.

ATLOCK uses Fernet, which provides authenticated encryption based on:

AES-128-CBC + HMAC-SHA256

The encryption key isn't simply derived from a user's password and used directly.

ATLOCK uses:

PBKDF2-HMAC-SHA256

for password-based key derivation.

That gives the architecture two different protection mechanisms:

             ATLOCK
                │
      ┌─────────┴─────────┐
      │                   │
 File Guard          Password Vault
      │                   │
 NTFS ACLs             Fernet
      │                   │
Access control       Encryption +
                     authentication

I actually prefer this separation.

The security mechanism should match the problem.

📸 Then There's Intruder Ops

ATLOCK also has an Intruder Ops module.

The concept is straightforward:

Access attempt
↓
Authentication failure
↓
Configured threshold/event
↓
Intruder Ops
↓
Evidence capture / alert
↓
Local storage

The interesting engineering problem wasn't just capturing an image.

It was making the capture process not interfere with the main application workflow.

Camera initialization can be slow.

A webcam can already be occupied by another application.

Hardware availability can change.

And a security event shouldn't freeze the application's UI while the camera subsystem initializes.

That forced me to think about the feature as an asynchronous workflow rather than:

capture()
wait()
continue()
⚠️ The Part I'm Still Thinking About

Building security software taught me something uncomfortable:

Adding a security feature doesn't automatically make software secure.

Every additional privileged operation creates another place where something can go wrong.

That's why I'm increasingly interested in threat modeling rather than simply counting features.

For ATLOCK, questions like these matter:

What happens if another process already owns the camera?
What happens if ACL modification fails halfway through?
What happens if the application crashes during a protection change?
What happens if permissions are inherited unexpectedly?
What happens if a user loses access to a protected directory?
What happens if the local evidence storage itself is modified?
What security boundary does ATLOCK actually provide?

Those questions are much more interesting to me than:

“How many features does the app have?”

🔒 That's What ATLOCK Is Becoming

Originally, ATLOCK was simply a collection of security utilities.

Now I'm treating it more like a security engineering experiment.

Use Windows' existing security primitives where possible.

Use cryptography where confidentiality actually requires it.

Keep security events local.

And constantly question the threat model.

If you're a Windows developer or security engineer, I'd genuinely like your criticism:

Where would you attack this architecture first?

ATLOCK v4:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

ATLOCK

"We Build What Others Forgot To Fix"

I Don't Need More Compliments. I Need People to Test ATLOCK.

Akhouri Anmol Kumar — Tue, 11 Aug 2026 04:29:46 +0000

That's exciting.

But there's something I've realized while building it:

A download doesn't tell you whether your software is actually good.

Someone can download an application, open it once, and never touch it again.

So I'm changing what I want from the next 100 downloads.

I don't just want people to download ATLOCK.

I want people to test it.

What should you test?

ATLOCK v4 currently includes several local Windows security functions:

🔒 File Guard
🔐 Password Vault
📸 Intruder Ops
🔔 Security Notifications
🖥️ Desktop Lockdown

But don't just look at the feature list.

Actually use them.

Try the workflows.

Look through the settings.

See whether something is confusing.

See whether something feels unnecessary.

And if something breaks, tell me.

Why I'm asking

I'm building ATLOCK independently under Akhouri Systems.

I don't have a large QA department.

I don't have a team of testers sitting around checking every workflow.

The people who actually download and use the application can provide something that automated testing can't:

real-world feedback.

And that's much more valuable to me than someone simply saying:

"Nice project."

🔒 Try ATLOCK v4

GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

If you use Windows, give it a try.

And if you do download it, I have one question:

What was the first thing you tested?

That's the feedback I'm looking for.

532 downloads so far.

Now let's see how many people are willing to actually put it through its paces.

ATLOCK

"We Build What Others Forgot To Fix"

Just Crossed 532 Downloads. Here's Why I'm Asking You to Try It.

Akhouri Anmol Kumar — Mon, 10 Aug 2026 06:52:28 +0000

I didn't build ATLOCK because I thought Windows needed another random utility.

I built it because I wanted to experiment with something different:

How much useful desktop security can you put into one local-first application?

Today, reached 532 downloads.

That's a small number compared with established software.

But for an independently built Windows application, every download means someone decided:

"I'll give this a try."

And that's the part that matters to me.

What is ATLOCK?

ATLOCK v4 currently brings several security functions together:

🔒 NTFS-based File Protection
🔐 Local encrypted Password Vault
📸 Intruder Ops
🖥️ Desktop Lockdown
🔔 Local security notifications
⚙️ Configurable security settings

The password vault uses Fernet with PBKDF2-HMAC-SHA256 for key derivation.

The application is designed around a local-first approach, without requiring a mandatory account or cloud service.

But here's what I actually need now

I don't need another person telling me:

"Nice project."

I need Windows users to download it and actually use it.

Try the File Protection.

Open the Password Vault.

Look through the settings.

Test the workflow.

Then tell me what you don't like.

Because criticism from someone who actually used the software is worth far more than another compliment.

🔒 Try ATLOCK v4

GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

If you download it, I'd genuinely like to know:

What was the first feature you tested?

532 downloads so far.

Let's see what happens when more Windows users actually put it through its paces.

"We Build What Others Forgot To Fix"

I Don't Want 87 More Downloads. I Want 87 More People to Test My Software.

Akhouri Anmol Kumar — Sun, 09 Aug 2026 04:46:45 +0000

Akhouri Systems has reached 513 downloads.

My next milestone is 600.

That means I need 87 more.

But after building ATLOCK for months, I've realized something:

A download by itself doesn't tell me much.

Someone can download an application, open it once, and never touch it again.

What I actually want is feedback.

So I'm changing the goal.

ATLOCK v4 Community Testing Week

Instead of asking people to simply download ATLOCK, I'm asking Windows users to try to break my assumptions about the product.

ATLOCK currently includes:

🔒 NTFS-based File Protection
🔐 Encrypted Password Vault
📸 Intruder Ops
🖥️ Desktop Lockdown
📋 Local Security Logs

I don't want another list of compliments.

I want someone to say:

"This workflow makes no sense."

Or:

"Why doesn't it do this?"

Or:

"I'd completely redesign this part."

That's useful.

Why?

Because when you're an independent developer, you spend so much time inside your own project that you start seeing it the way you designed it, rather than the way a new user experiences it.

That's dangerous for software.

Especially for security software.

A security application can have technically interesting features and still fail if the user doesn't understand what it's doing.

So I'm opening the project to community testing.

The challenge

Current: 513 downloads

Target: 600

Remaining: 87

But I'm measuring more than downloads this time.

I want to know:

What confused you?
What felt unnecessary?
What felt genuinely useful?
What would make you trust the application more?
What feature would you add?

If you're a Windows user, I'd genuinely appreciate 10 minutes of your time.

🔗 ATLOCK v4:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

And if you find something wrong with it, please tell me.

I'd rather fix a real problem than collect another meaningless compliment.

One question for developers:

What's the most valuable criticism you've ever received about something you built?

I'm especially interested in the answers from people who have shipped their own software.

I Have 511 Users and Almost Zero Feedback. Help Me Fix ATLOCK.

Akhouri Anmol Kumar — Sat, 08 Aug 2026 10:55:35 +0000

Akhouri Systems just crossed 511 downloads.

That's nothing next to what major software companies pull in a day. But for an independent developer with no funding, no team, and no marketing budget — 511 people choosing to install something I built alone means a lot.

So instead of asking for more downloads, I'm asking for something harder to get:

Honest feedback.

Community Testing Week

I'm opening ATLOCK v4 up for testing. Not "please try my app" testing — actual "please try to break it" testing.

ATLOCK is a local-first Windows security suite:

🔒 Desktop Lockdown — system-level screen lock with countdown + OS hardening
🛡️ NTFS-Based File Guard — locks files at the Windows permission level, not just an app-level hide
🔐 Encrypted Password Vault — AES (Fernet) encryption, PBKDF2-HMAC-SHA256 with 200k iterations for the master password
📸 Intruder Ops — snaps a photo on the first wrong password, a 10-second video + alarm from the third wrong attempt onward
🔔 Notifications Panel — local activity log of lock events and alerts, no cloud, nothing leaves your machine

I care most about feedback on usability and the overall security workflow:

If something feels confusing — tell me.
If a feature seems unnecessary — tell me.
If something doesn't behave the way you expected — definitely tell me.

I'd rather get honest criticism from 20 people who actually opened the app than 200 downloads from people who never launched it once.

Poke around the Lock, File Guard, and Vault tabs. Try to confuse it. Try to lock yourself out on purpose. Then open an Issue on the repo (or just drop a comment below) with whatever you ran into — bug, confusing UX, a feature you didn't understand, anything.

🔗 Repo: https://github.com/Akhouri-Anmol-Kumar/ATLOCK

The challenge

Current downloads: 511 Goal: 600 Only 89 to go.

But the download count isn't really the point. The point is getting real hands on it and shaping what v5 becomes.

I'm still one person building this with no marketing budget, so if you're a Windows user with ten minutes to spare, I'd genuinely appreciate you giving it a shot.

One question for the devs reading this:

What's the best piece of criticism you've ever received about something you built?

"We Build What Others Forgot To Fix"

I Built a Windows Security Suite in Python That Locks Down Your PC, Vaults Your Passwords, and Photographs Intruders

Akhouri Anmol Kumar — Fri, 07 Aug 2026 15:21:52 +0000

Someone kept snooping on my laptop while I was away. So I did what any dev would do — I overengineered a solution.

Meet ATLOCK v4 — a free, open-source Windows security suite built entirely in Python. One app, five jobs: lock your screen, guard your files at the OS level, vault your passwords with real encryption, and — my favorite part — catch whoever's trying to get in.

What it actually does

ATLOCK isn't a toy screen-locker. It's five tools stitched into one dark, gold-accented desktop app:

🔒 Lockdown System-level screen lock with a countdown timer and OS-level hardening. No alt-tabbing your way out.

🛡️ File Guard This is the part I'm proudest of — it uses Windows NTFS ACL permissions to lock files, not some app-level "hide the file" trick. If ATLOCK guards a file, Windows itself refuses to let anyone read it without unlocking first.

🔑 Password Vault Encrypted storage for your emails, UPI PINs, whatever you don't want lying around in plaintext. Under the hood:

Fernet (AES-128-CBC + HMAC) encryption
PBKDF2-HMAC-SHA256 with 200,000 iterations and a random salt for the master password
No plaintext, anywhere, ever

📸 Intruder Ops Get the password wrong once, ATLOCK silently snaps a photo. Get it wrong three or four times, it records a 10-second video and sounds an alarm — all saved straight to your Pictures/Videos folder. Every failed attempt is masked before it's ever logged, so even ATLOCK itself never stores what was actually typed.

⚙️ Settings Toggle camera capture, sound alerts, and pick your gallery folder.

Why I rebuilt it (v4 changelog)

The earlier build had a password vault that was "encrypted" with XOR — cute, but not actual cryptography. v4 fixes that and more:

Vault moved from XOR to real Fernet AES + HMAC
Master password now goes through PBKDF2-HMAC-SHA256 (200k iterations, random salt) instead of a weak hash
Intruder attempt logging is masked before it touches disk
Alert credentials are encrypted with a machine-bound key
Toast notifications no longer build PowerShell strings via injection-prone concatenation

Built with customtkinter for the UI, opencv-python for the camera, and cryptography for everything that touches your secrets.
grab the packaged build straight from the site:
👉 https://akhouri-anmol-kumar.github.io/Akhouri-systems

It's free. It's open. If you've ever wanted to know exactly who's been trying to get into your laptop, this is that tool.

⭐ If this is useful, a star on the repo genuinely helps more people find it. Bug reports, feature requests, and PRs are all welcome — drop them in the comments or open an issue.

Built by Akhouri Anmol Kumar under Akhouri Systems.

"We Build What Others Forgot To Fix"

I Thought Building the Features Was the Hard Part. I Was Wrong.

Akhouri Anmol Kumar — Fri, 07 Aug 2026 10:47:23 +0000

When I started building APIC (Advanced Image Processing Center), I thought the challenge would be implementing image editing, conversion, and compression.

It wasn't.

The real challenge was preventing the project from collapsing under its own complexity.

Every new feature seemed simple at first.

"I'll just add image compression."

Then came:

New menus
Shared file handling
UI state management
Keyboard shortcuts
Drag & drop behavior
Error handling
Multiple workflows

One feature quietly turned into five.

That's when I realized I wasn't building features anymore—I was building a system.

The Turning Point

Instead of continuing to add code wherever it worked, I stopped and reorganized the application.

APIC became a collection of independent modules:

🖼️ Edit
🔄 Convert
📦 Compress
🔍 Search
🏠 Home

Each module owns its own responsibility.

That single decision made development much more manageable.

What I Learned

A project doesn't become difficult because it has many features.

It becomes difficult when every feature depends on every other feature.

The more independent your components are, the easier it becomes to improve the software without breaking existing functionality.

Building APIC Today

Today, APIC is growing into a modern Windows desktop application that combines image editing, conversion, compression, and search in one workspace.

There's still plenty left on the roadmap, but one thing has changed.

I spend less time fixing old code and more time building new features.

Looking back, I wish I'd thought about architecture much earlier.

It would've saved me countless hours.

If you're building a desktop application—or any software at all—don't underestimate the value of a solid architecture.

Future you will be grateful.

What architectural decision ended up saving your project? I'd love to hear your experience.

Try APIC: https://github.com/Akhouri-Anmol-Kumar/APIC

"We Build What Others Forgot To Fix"

511 Downloads Later... Thank You.

Akhouri Anmol Kumar — Thu, 06 Aug 2026 11:38:07 +0000

When I started building Akhouri Systems, I didn't have funding.

I didn't have a team.

I didn't have investors.

I didn't even have a code-signing certificate.

What I did have was an old idea:

Build software that solves real problems.

Today, 511 people have downloaded software from Akhouri Systems.

That number may not sound huge in a world where apps reach millions of downloads.

But to me...

511 means 511 people trusted an unknown independent developer.

Some of you probably installed my software on expensive laptops.

Some on budget machines.

Some on work computers.

Some just wanted to see what a 13-year-old developer was building.

Whatever your reason...

Thank you.

Every download was a decision.

Every piece of feedback made the project better.

Every suggestion pushed me to improve.

There are a few people I especially want to thank.

The Lazy Girl (Divyanshi Didi) ❤️
Mustafa ERBAY
xuilingfeng
Sudhanshu Burile

Your suggestions, encouragement, technical feedback, and honest opinions helped shape Akhouri Systems far more than you probably realize.

You weren't just commenting on a project.

You were encouraging a young developer to keep going.

I'll never forget that.

And to the other 511 users...

Thank you for taking a chance on software that isn't backed by a big company.

Thank you for trusting an application that isn't even digitally signed yet because, as a young independent developer with zero budget, I simply can't afford everything established companies can.

Trust is something that has to be earned.

I'm still earning it.

One release at a time.

August 31 is coming.

I'll officially turn 13.

I have no idea where this journey will take me.

Maybe one day I'll build something that changes millions of lives.

Maybe I won't.

But one thing I know for certain is this:

I'm not giving up.

I've always admired people who kept building despite criticism and setbacks. If I can carry even a small part of that persistence into my own journey, I'll consider that a success.

At Akhouri Systems, our mission remains the same:

"WE BUILD WHAT OTHERS FORGOT TO FIX."

To everyone who has supported me...

Thank you for believing in a kid with a laptop, an idea, and a dream.

The journey has only just begun. 🚀

"I believe if bill gates can, elon musk can, then why i can't"....

🔗https://akhouri-anmol-kumar.github.io/Akhouri-systems/

I Stopped Building "Another Image Converter" and Started Building an Image Processing Suite

Akhouri Anmol Kumar — Thu, 06 Aug 2026 10:49:43 +0000

Most desktop image tools solve one problem.

Some convert images.
Some compress them.
Some edit them.

I wanted a single application that could handle all of these workflows without forcing users to switch between multiple programs.

That's why I started building APIC (Advanced Image Processing Center).

Current Features
🖼️ Image Editing
🔄 Multi-format Image Conversion
📦 Image Compression
🔍 Image Search
🖱️ Drag & Drop Support
⌨️ Keyboard Shortcuts
🎨 Modern Desktop Interface
Under the Hood

APIC is built with Python and PyQt6, following a modular architecture where every major feature lives in its own module.

That makes the application easier to maintain and much easier to expand as new functionality is added.

Why Desktop?

In a world dominated by web apps, desktop software still matters.

Local processing means:

Better privacy
Faster performance
No upload delays
Full offline functionality

That's exactly the experience I wanted APIC to deliver.

What's Next?

The roadmap includes:

AI-powered image enhancement
Background removal
Batch editing
Additional editing tools
Performance improvements
Smarter workflows

Building software isn't just about shipping features.

It's about creating tools people genuinely enjoy using.

If you're building a desktop application yourself, I'd love to hear what challenges you've faced.

Try It: https://github.com/Akhouri-Anmol-Kumar/APIC

Python #PyQt6 #DesktopDevelopment #SoftwareEngineering #ImageProcessing #BuildInPublic #Windows #Programming

I Stopped Collecting User Data. Here's Why ATLOCK Doesn't Need It.

Akhouri Anmol Kumar — Wed, 05 Aug 2026 11:15:09 +0000

Most desktop applications today ask for something before you can even start:

Create an account
Verify your email
Stay connected to the cloud
Accept telemetry

When I started building ATLOCK, I decided to go in the opposite direction.

No mandatory account.

No telemetry.

No cloud dependency.

No usage tracking.

Every feature—from the encrypted password vault to Intruder Ops and file protection—is designed to work locally on your Windows PC.

It wasn't the easiest decision.

Cloud services make syncing, analytics, and debugging much easier for developers.

But they also increase complexity and expand the attack surface.

For a security application, I wanted users to own their data—not hand it over.

ATLOCK has now crossed 500+ downloads, and every bit of feedback has helped shape the project.

I'm still improving it every week, and I'd genuinely appreciate hearing what Windows users think.

🔗 GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK

If you were building a Windows security application today, what would be your number one priority: privacy, convenience, or cloud integration?

windows #cybersecurity #buildinpublic #github #privacy

"We Build What Others Forgot To Fix"

I Stopped Asking People to Download My App.

Akhouri Anmol Kumar — Tue, 04 Aug 2026 10:38:30 +0000

Instead, I asked them to break it.

That changed everything.

Over the last few months, I've been building ATLOCK v4, a local-first Windows security suite.

I could write another post listing features.

Or I could ask something much more interesting.

If you had 10 minutes...

What would you try first to break a security application?

Would you test the password vault?

Try bypassing file protection?

Look for weak permissions?

Stress test the interface?

That's exactly the kind of feedback I'm looking for.

ATLOCK currently includes
🔒 NTFS-based File Protection
🔐 Encrypted Password Vault
📸 Intruder Ops (Webcam Photo & Video Capture)
🖥️ Desktop Lockdown
📋 Local Security Logs

Akhouri Systems has now crossed 500+ downloads, but I'd rather have 50 honest reviews than another 500 silent installs.

So here's my challenge to the Dev.to community:

👉 Download ATLOCK.

👉 Try to find something wrong.

👉 Tell me what you'd improve.

Whether it's the UI, workflow, usability, or security model—I genuinely want the criticism.

Every serious security product gets better because people question it.

Maybe you'll find something I've missed.

GitHub:

https://github.com/Akhouri-Anmol-Kumar/ATLOCK

Question for you:

What's the first thing you check before trusting a brand-new security application?

I'd love to hear your perspective.

"We Build What Others Forgot To Fix"