I was digging through the comments for someone to point this out. I’m honestly curious why people are using these overly complex options when a solution has been built into the HTTP standard for decades (and, in fact, is heavily abused for many APIs).
And it’s superior in many ways, since the file is never delivered until authentication has been completed.
with basic authentication, you cannot embed the decryption key into the url via a hash fragment.
This means you must have a secondary channel to communicate to the user about the password, and the server must also know the password.
So depending on your use-case, the basic auth isn't suitable. For example, mega : https://en.wikipedia.org/wiki/Mega_(service) , in which you want to ensure that the decrypted data is _not_ accessible to the server, so the key is not stored nor sent to the server!
Person A doesn't know about basic auth - primarily because it isn't a hip way to solve the problem - so person A spends a bunch of time understanding, installing, and using something unnecessarily convoluted. When presented with evidence of a simpler solution, they balk because humans value things they have spent time on especially when it is their own solution, their own "discovery".
Author here - the specific use case is when you _don't_ have or want server-side logic or a DB. For example on static hosting (hence the name StatiCrypt) like Github pages, Netlify, etc.
That means nothing to maintain, no server cost, no serverless functions to rely on, etc.
But when that's not a constraint there are many different options that might make more sense.
And it’s superior in many ways, since the file is never delivered until authentication has been completed.