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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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"