Password protect a static HTML page
github.com
github.com
I was _extremely_ happy to see this posted.
However when I click the link I am taken to the library I had initially tried and had to reject. Without getting into the crypto side of things (which very well may resolve to "just make it tough enough for most folks") I crashed and burned using this tool once my page reached certain sizes. (I was cramming everything I needed into one page and I had a big hunk of bytes that I didn't want hanging out on the filesystem)
As I understand it, this is a known issue in V8. V8 limits the number of properties/collection members an object can have. There's a flag you can use with node to get a little more headspace, I believe it's something like "--max-old-space-size=8192" but it's a V8 problem, not a node problem. The staticrypt coders could also switch to a streaming cryptography instead of block, but that's far too much to ask of the casual user who only wants to lock up a page or two.
This is a really cool tool, and I wished I could have used it. Good luck to the team going forward. I've gotta find something else as this doesn't work for me.
I don't get it.
Great UI, though. But I still don't get it.
[0] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem [1] https://mprimi.github.io/portable-secret
- run encryption locally
- do not upload anything
You may not realize that’s the case because it’s a web form
This isn't the use-case I had in mind.
My personal one: I want to build a small utility web app for a very specific task, and it would be used by me and by some of my friends (less than 10 users total). The entire thing can easily be front-end code, which is nice, because I can just host it on Netlify and not bother with hosting, managing it, etc., thus making the complexity of it all much lower.
But there is one catch - the web app uses an external API, and, along with it, the API access key. This puts a big stop sign for making it front-end only. And I don't want to up the level of complexity by managing the back-end just for the API access key retrieval (for a webapp used by less than 10 people). Exposing the API key in the front-end code on a publicly accessible website is one of the worst ideas I can think of.
I haven't done the evaluation on how well the solution in the OP would serve my specific purpose, but it looks promising.
https://ithemes.com/blog/what-is-the-htaccess-file/#password...
> This allows encrypting multiple page on a single domain with the same password
This might still work for you if putting everything on one page isn't a requirement. Using the "remember me" checkbox means the user only has to input this password once.
Curious. Can you say more about your use case, even if only in general terms?
https://security.stackexchange.com/questions/184305/why-woul...
(also, use the built-in WebCrypto API instead of the crypto-js package)
I bet that most programmers cannot implement a Galois Field in Javascript. Meanwhile, CBC is just "encrypt then xor".
So now what?
https://cryptojs.gitbook.io/docs/
Because CBC mode is easier to implement, you'll find it in far more libraries. And honestly, if your underlying block-cipher is secure (that's the hard part: where your side-channels all exist), then CBC mode is really the easy part and can be safely implemented yourself. It really is that simple.
-----------------
CBC doesn't have authentication. So add on an HMAC. Done. It takes up a few more bytes but that's not a big deal these days.
If you are serving out an encrypted HTML page insecurely, your users are already hosed, because someone on the path could inject a script that sends the password to evil[.]com when they type it in.
Literally one of the most common things to fuck up when doing crypto yourself.
The things you are describing are difficult and dangerous for developers to build.
HTML uses some Javascript to encrypt a file. Then later, the Javascript decrypts the file and returns it to normal.
This is a "beginner level" cryptography situation. Yes, I know there's all sorts of traps all around the field of cryptography. But I also know that this particular use case is simple enough that beginners can try their hand at it, and probably make something useful. And with low-probability of a critical error.
-------------
Don't write your own AES-GCM implementation. Don't write your own TLS1.2 implementation. Etc. etc. There's all kinds of subtle errors involved. IVs, Padding, side-channels, man-in-the-middle... more than I can count and very subtle to think about.
The fact that this subthread has gone down a rabbit-hole of hypotheticals that are _COMPLETELY IRRELEVANT_ to the use-case discussed in this github is proof enough. The community is a bit rabid over its "advice" on this subject.
I see what you’re saying, but the fact is that these hypotheticals are not irrelevant. They’re important intricacies and potential trip mines associated with implementing your own encryption.
In any case, I think reimplementing CBC is absolutely beginner level as far as implementation is concerned. Yes, you can be tripped up by various _uses_ of CBC, but the failure modes are extremely well studied at this point.
Of course, a proper AEAD implementation would avoid that. But AEAD is commonly established today with GCM, which is not beginner level. So now we're trapped. What am I supposed to tell a young programmer who is interested in playing around with encryption on their own?
Perhaps you wish to stop anyone from studying that subject. But on the contrary, I think the only way a programmer can truly learn this stuff is to implement the easiest stuff and try it out themselves from the ground up.
--------
The _proper_ advice, is... don't write your own production encryption. But... if you have to, stick with the simplest implementation that avoids the most common errors (side channels, timing attacks, etc. etc.), and focus on the simplest use cases that have the largest amount of history.
Of course, there's an entire class of crypto-bugs these days are found at the higher levels, in the "use of encryption" (ex: SSL3.0, TLS1.0, TLS1.1, etc. etc.). Nonce reuse, IV generation, in-advertent side channels due to padding oracles, etc. etc.
Even a "perfect" implementation of CBC will come across these crypto-bugs (and is why modern algorithms do focus on AEAD from the ground up these days, which largely avoids the problem).
So yes, there are a lot of traps and footguns in the world of encryption. But that's true of programming in general. Eventually, someone will want to make their own encryption, maybe the library doesn't work out just right (as is in this case: the Crypto-library doesn't have GCM mode implemented), and other modes need to be used. The use of CBC seems to be done properly here for static-HTML encryption.
Tell them to stop if they’re trying to do it for anything real, or do it as a toy protect that never sees the light of day. And if they select the latter, then they may as well try GCM.
Tell them to leave encryption writing to the professionals.
We're well deep into a "professional" discussion about the pros and cons of particular implementation details of cryptography.
------------
Go back to the top. Look at the Github code. See that it uses a crypto-library. What should have the original writer have done differently?
The answer is absolutely not "write their own implementation of GCM". They chose correctly: using a well known, well supported CBC mode of operation with AES. (And IMO, _IF_ CBC mode were unsupported, the correct move would have been to write CBC themselves, as it is far less complex than GCM, which includes GHASH and other such side-channel issues).
There's context to everything. From my understanding of this current situation, the CBC choice was perfectly valid.
I too loved playing with crypto - read a ton of books, attended some crypto classes in University, implemented some crypto systems which I thought were secure, etc. - but nowadays I wouldn't dare use anything that isn't considered secure by a large audience unless I had extremely good reason to do so.
Never implement your own cryptography.
Edit:
In fact an incorrect implementation of CBC mode famously caused a vulnerability in Microsoft's ASP.NET in 2010 (https://learn.microsoft.com/en-us/security-updates/securityb...). The margin for error is small and even subtle mistakes or incorrect design can cripple security. Even Microsoft got it wrong once (although they handled remediation very well).
The reason you don't implement your own block ciphers is because side-channel attacks are damn near impossible for normal programmers to understand. Especially timing attacks.
But block-modes of operation? Some of them are really easy. I've ever heard of a bad implementation of CBC causing a security bug.
-------
I'd say you shouldn't implement your own GCM mode. GCM is quite complex, and the Galois Field's authentication bits could be side-channeled if you don't know what you're doing.
CBC? Where's the flaw? Its so stupid simple I don't think that even a novice would make a critical error.
Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it!
You're kidding, right? You've never looked at how GCM-mode works? The entire set of math is inside of the GF(2^128) field. That's why its called a Galois Counter Mode.
I don't think anyone should be implementing their own GCM mode. Its very subtle and potentially full of traps. CBC on the other hand is pretty dumb and simple, and surprisingly secure and robust
> Vulnerabilities in CBC systems were for a long time during the 2000s the most common crypto vulnerabilities on the Internet. There are more things that go wrong with CBC mode than just forgetting to authenticate it!
If they're so common, you shouldn't have much of an issue naming one such vulnerability.
Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
[1] https://doc.libsodium.org/secret-key_cryptography/secretbox
> Regardless there's no good reason not to use a vetted open source implementation instead, preferably with an even higher level of abstraction so your not having to worry about ciphers or modes of operation at all[1].
I think that's generally the preferred solution, yes.
The nuanced viewpoint is never implement your own cryptography.
> Its so stupid simple I don't think that even a novice would make a critical error.
Ask Microsoft about that one: https://learn.microsoft.com/en-us/security-updates/securityb...
I’m not sure why you’re ferociously defending the practice of implementing your own cryptography. It’s well known that this is a horrible idea for good reason.
... if the API provided is correctly designed, and either the language made it practical to design the API in a misuse-resistant way /or/ the programmer was actually careful and used it properly.
We both know it's way more likely the problem in your actual system is "Oops, we use the bogus plaintext here despite the validation error" than "Dastardly enemy cryptographers have made a breakthrough in cryptanalysis to attack our product".
The 1000 rounds only of pbkdf2 on something that's essentially going to be available without any access control (since the encryption is the access control here) might be more annoying as the password can be human generated.
It seems that the hmac validation makes the GCM unnecessary in their thread model
I think you might be referencing that the incorrect use of CBC leads to chosen-plaintext attacks, chosen-ciphertext attacks, or padding oracle attacks. GCM is AEAD, providing ciphertext authentication. [1]
For those reasons that you mention, use of encryption should always have a design review.
[1] https://en.wikipedia.org/wiki/Authenticated_encryption#Authe...
Relevant comment here: https://github.com/robinmoisson/staticrypt/issues/19#issueco...
[1] https://github.com/robinmoisson/staticrypt#alternatives-to-s...
I wouldn't personally put anything you want secure behind this.
[1]: https://github.com/robinmoisson/staticrypt/blob/5dac008ba644... [2]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
We put a lot of effort into teaching people to do better stretching, but it feels like the result was they put even more passwords on things, rather than using the breathing room to get off passwords. If your project for 2023 is "Use a fancier password hash" instead of "Get rid of passwords" you are Doing It Wrong™.
If you wanted to do something like this seriously, consider hmac-secret extension to FIDO, which means Security Keys (so the things you'd use to log in to say Google or Facebook) can present an arbitrary always-identical secret value which would be more than adequate to secure such a thing unlike a human memorable password. Today hmac-secret is mostly used to authenticate to an off-line laptop PC or similar.
TLDR: No. In fact, theoretically stretching the password is more effective than increasing iterations. However, I don't see him citing the fact some password hashing functions have limited input size, which means at some point having a larger password doesn't really change anything.
But in practise nobody uses 100 character long strings. Security is the intersection of real users with systems, not imaginary ones.
Multiple websites I use daily have that length of password or longer.
The 100 characters password would be in the password manager but the secrets I would work with fit into the password manager, so I have no need to use a separate channel. I could upload the db, download it and just remember the master password.
The only use case for this technology is when the secret is the file itself and it can't fit in the password manager. An image, a file, etc.
I'll answer some of the comments here and address the newly opened issues during the day. To answer a few questions that seem common skimming this thread:
* CBC vs GCM: we had a conversation regarding this topic where it seemed CBC weaknesses do not apply in StatiCrypt context. I'd love to hear your thoughts if you have any - issue is here[1].
* WebCrypto: I've been wanting to use WebCrypto instead of crypto-js for years now. It's been in my "Important but not urgent" bucket (since crypto-js should be secure too), the interface is different so I want to make sure I do it correctly and life happened, so I never got farther than drafts. Thank you for the PRs, I hope to get to it soon!
* "static" means no server-side logic (not no JS): I first made StatiCrypt to solve my own issue of wanting to password protect an html page I could host on a static file host (Netlify, Github pages...). The whole point is to not have a server or DB, so we can't use Basic auth etc.
* Iteration count for PBKDF2: will increase today
As I write in the FAQ[2] I do my best to implement things correctly but I'm not a cryptographer - any feedback to make the tool better or more secure is very welcome!
[1] https://github.com/robinmoisson/staticrypt/issues/19#issueco...
And it’s superior in many ways, since the file is never delivered until authentication has been completed.
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!
//<user>:<pass>@<url>[:<port>][/<location>]/
It doesn’t work on IE classic, but should still be perfectly valid on Chrome, Safari, Firefox, 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.
It’s just weird how many people are jumping on this as some new technique when Basic Auth is fully usable in many other cases.
https://github.com/robinmoisson/staticrypt/blob/5dac008ba644...
https://github.com/yjs/y-webrtc/blob/master/src/crypto.js#L2...
Here, the encrypted document is encouraged to be hosted publicly. There isn't any authentication before the encrypted document is downloaded. If the document remains sensitive long term, then we need to protect it from attack using computers that will exist >10 years from now.
Since this tool doesn't have layered security, and the contents likely remain sensitive long term the single security layer should be stronger.
We can hand wave this and say that the user should pick a strong password or only store minimally sensitive documents but most won't and there's nothing here to inform or encourage them to do so. (Even single character passwords are allowed...)
1. Don’t implement the underlying crypto yourself
2. CBC is hard to get right
3. There are a lot of esoteric attacks and if you have a nation state attacking you they could exploit them, but they won’t because they will just put some crap on your systems and do it easier.
Also this is a very simple use case to get authenticated CBC correct with. So, the real answer is “don’t do this, but it is probably okay in this one use case, assuming they didn’t implement all of this themselves (e.g the crypto algorithms themselves)
You should still listen to tptacek though. Use an authenticated crypto mode :)
If it's really sensitive I wouldn't put it on an accessible page and then have to worry about password sharing, server-side security/possible spoofing, etc etc
So if I can share the password securely and/or have it somewhere safe, why don't I use that system for the content itself? because of html formatting, storage, etc? seems like a much easier problem to solve than the threat model of sensitive stuff shared on the web.
I'm trying to imagine concrete situations that I'd go for something like this and I cannot quite think of any. Silo-ing stuff behind a login is so much more versatile. Generally not putting sensitive stuff on the web works so well when you can send essentially anything point-to-point using so many widely used protocols including Signal, LINE or Whatsapp, or a simple email, which you can use to send encrypted 7z files for good measure.
By the way, I don't advocate for this idea. But still, I find it a pretty ingenious way to store encrypted data portably. Essentially what is happening is the file contains the encrypted data and the algorithm to decrypt it with the correct passphrase/key.
that's just a self-extracting archive, which is a very common idea and easily created as well (very popular with both shareware distribution).
The problem is that you have to trust the extracting code to not install anything else malicious. The browser provides the perfect sandbox - you cannot install malware into the system via javascript in the browser, and thus you can trust it to run.
https://docs.nginx.com/nginx/admin-guide/security-controls/c...
The page prompted the user for the password, and then used the password to generate the URL for the hidden page and redirected the user there. Of course this wasn’t over HTTPS, and you got a 404 if you entered the wrong password, but it was still a neat hobbyist trick for the era. I think the author even wagered that readers couldn’t defeat it.
- Password in plaintext in the source e.g. "if(password=='hunter2') ..."
- No correlation between password and page contents (either the content is merely hidden and shown when the password check succeeds, or lightly obfuscated/encrypted using key independent of knowing the password)
- Hiding content by using "display:none" or similar
why not? this could be served on a server which does not have any dynamic execution capabilities, and does not require the server to handle any other request other than just the HTML.
It works with a GPG-encrypted file. I figured that was safer than developing my own encryption format. As it is, any vulnerability in the decryption process is equivalent to a vulnerability in GPG.
Whether using pbkdf2, argon2 or something else, along with what the work factor is, is critical to security in this application.
Currently it’s just for plaintext, but might allow for more complex things like the website.
The password is stored in the url after the # so it’s never sent to the server.
I was going to post this project after I build some more utilities.
An approach I've played around with, but never sat down to actually build, was to use service workers to be able to encrypt large sites -- the entire site would be encrypted locally from the command line using libsodium's `crypto_secretbox_easy`[0], and all of the data would be concatenated into a series of padded files to try and somewhat hide the number of files/size of the site. That key would be merged with a lookup table that would also be encrypted with a separate key, that would be stuck in the url hash. Then once the site was decrypted (ie, the secretbox key was sent to the service worker from the url) the service worker would intercept any requests the the front-end made and decrypt the original map that would tell it which file chunks to fetch, and then it would decrypt them on the fly and cache them for the duration of the session. Whenever you updated the site, the files would be re-encrypted with another key, but the "user facing" key in the URL would stay the same.
The linked project (and other projects people have linked) are a lot more portable, but I was thinking less about being able to have a single file that I carried around and more about being able to put up a full website where I could have something approximating user accounts (ie, possibly having multiple lookup tables that could be decrypted separately per-user), and where I could build full-featured projects that could fetch their own resources.
But, I haven't ever gotten around to actually building it, I only ever built some tests to make sure that it would technically work, and I got nervous about rolling my own solution even though I was just going through the libsodium APIs.
----
[0]: I've seen a couple of people recommend using Web Crypto instead, which I've avoided because I thought libsodium ported to the browser was harder to shoot myself in the foot with; is that a bad instinct?
windows.location = hash(password);
Also now all intermediate things that have access to the hashed url would suddenly have access to a secure piece of information.
Don’t be clever with security
No JavaScript required a d highly efficient
Considering it's been around longer than that, yes I think it will be around in 15 years
Why html though? They do have some js and interactive functionality in there. I can slice and dice my monthly report within the single html page they send which is actually quite handy (and there’s the default “show me my transactions in a list with opening and closing balance” option as well).
2) The code calls back home in xhr.open('POST', 'https://zlgpaemmniviswibzuwt.supabase.co/rest/v1/rpc/increme...', true); i don't want YOU to know when i open a file, or encrypt a file.
3) The surface attack of the browser is HUGE, there are many escape the sandbox vulns, same origin bypass, zero day exploits that can be exploited, take a look at the cve database of chromium, using the browser the way it is proposed is a big mistake.
Finally, the code is not audited, may have cryptographic weakness as pointed in other comments. The solution you made could be good for a class assignment, or to learn how to use cryptojs, but from the security standpoint is a mistake to use it for anything serious.
If you are security conscious, you should use VeraCrypt/bitlocker, a simple rar/zip with password, even a pdf/.docx with password, or use a secure server with SSL, sftp?.
https://github.com/dav1app/sasha.html
The idea is to export any file as an HTML file with the data as an encrypted string hard coded within the HTML. This way, no specific software is required to decrypt the file, just open it on the browser, type the password and download or view your file.
I built this to have a easy way to send encrypted files to any device and open it without having to install external tools.
With the OP system the attacker gets potentially way more attempts to access the page and gets to try in the future with whatever tech comes out. On the plus side it is E2E encrypted!
With a traditional server they can rate limit attempts on the password. But they probably don’t encrypt it using YOUR password (unless it is a password manager etc.) so an attacker could get the plaintext if there is a breach.
Also sorry for the long link. Is there any accepted way to post a shorted URL?
Edit: added a corrected version [2]
[1]: https://www.typescriptlang.org/play?#code/DYUwLgBAbiDGYHsBOE...
[2]: https://www.typescriptlang.org/play?#code/FAiGGcE8DsGMAIBmBX...
Would "salting" the key safely tackle the problem?
Put explicitly;
send <- nonce || salt || ciphertext
recv -> decrypt(ciphertext, nonce, pbkdf(pass) || salt)
Here I thought GCM was some modern foolproof/footgunless design.
1: https://csrc.nist.gov/csrc/media/Projects/crypto-publication...
Web Crypto is faster and has many more devs working in the different implementations between all the companies and doesn't require any includes.
Just levels of trust. I'd happily use the former if the latter didn't exist.
I note down two other possible methods in the post. Would love to hear about more info.
Edit: I wouldn’t recommend this for anything serious, but for some blog posts of my wife’s that we wanted to be relatively private, it was good enough.
The user experience with basic auth is not so good. The dialogs give little way to customize and providing information for user. No support for logout or any form of password changes.
And well, my experience there is about 20 years old, but back then sending 401 wasn't enough. You had to send a different auth request, which then would pop up a new password dialog first. Indoubt 401 is enough today as well, as the browser can't distinguish whether a specific resource is restricted or whether the whole session should be invalidated.
Apache actually also has an OpenID Connect module (it's certified and everything), which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc
Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/
I'd say that Keycloak is a pretty good solution in general, because it does some of the heavy lifting for you, maybe its shorter release cycle not being the best thing ever, though. I think IdentityServer also tried to fill this niche, but they went full on commercial recently, without OSS offerings.
As a sidenote, I also use mTLS for some personal resources and basicauth is still wonderfully easy to setup without a single point of failure for handling the authentication. A caveat might be that in practice people who try to use mTLS for app development shoot themselves in the foot, because that doesn't play nicely with reverse proxies etc.
Oh and also, to reduce needless disk IO, using a single config file approach as opposed to .htaccess can make Apache a bit more performant and easier to reason about: https://httpd.apache.org/docs/current/mod/core.html#allowove...
However it's the kind of license that's gated behind a manual signup:
> If you would like to request a Community Edition license, please provide:
> Confirmation that you understood the qualifying criteria
> Your category (for-profit, non-profit, charity)
> Your (company) name
> Your address
> Your contact email
This seems to be reflected in that you cannot find any official Docker images, for example: https://hub.docker.com/search?q=identityserver
Contrast that to: https://hub.docker.com/r/keycloak/keycloak (admittedly, the Bitnami containers are better, since those provide good documentation right in Docker Hub, instead of being lazy like Keycloak did and just putting it on their site)
Overall, the licensing situation with IdentityServer seems interesting, perhaps a bit more restrictive than Keycloak or other competitors: https://leastprivilege.com/2020/10/01/the-future-of-identity...
Regardless, to me being able to download software without messing about with signups and justifying why I need it feels like a good litmus test for some of the culture and community behind it. Regardless, I don't think that there are any truly excellent solutions in this space out there.
Then again, you see basically the same with the likes of OpenLDAP, FreeIPA and others that still don't quite compete with Microsoft's AD. There's a lot of problems (identity and device management, authentication/authorization gateways etc.) that could have great OSS solutions for them, if at the end of the day everything didn't circle back to money. Oh well.
Like domain.com/user1 and domain.com/user2 each are encrypted but with their own passwords. So user 1 can only visit his own page and not other users.
(I know there would be much easier to just do a traditional webapp but as a concept it is super cool).
It should take you no less than 10 minutes ;)
Sigh.
Here's an example of protected page saved with SingleFileZ: https://gildas-lormeau.github.io/private/ (password: thisisapage)
Your local browser will be saving your 'password' unencrypted in the cache and history, and maybe syncing to other devices.
Any workplace security system will probably be keeping records of your 'password'.
Any mistake on the web server could turn on directory listing, revealing the password.
Some other user of the web server, even a sandboxed low privilege process, will often have the ability to list directories.
"The 'Basic' HTTP Authentication Scheme"
* https://www.rfc-editor.org/rfc/rfc7617
or
You can store the hashed-passphrase in local storage. This means you can auto-decrypt again. You don't need the original passphrase.
If bad guys get your computer, they can read the file. However, they cannot trivially work out what your original passphrase was, so it protects you a little if you reused your passphrase elsewhere.
This could be useful if you want to allow making edits and publishing this to a server, but keep authentication entirely client-side.
Not sure I'd trust it myself, but it definitely seems like a good option for those with limited hosting options (like GitHub pages or Neocities) and a need to secure some content.
It deters automated sandbox analysis by asking the user to use a password in the email body. For zip,pdf,etc... you can easily tell when they're encrypted and block/alert on them but not so with non-standard methods like this.
Then could use basic auth to protect access from outside and a tool like this to protect access from inside.
I just configured it in my CapRover instance for a deployed app to have my db GUI
Some obvious limitations:
-requires users to re-authenticate for every protected file on your site
-assets loaded by the page not password protected
-uses a single password globally shared by everyone who wants to read the doc
-archiving the page itself is useless unless you also archive the password, which must be done out of band
-this doesn’t compose or integrate with the web: none of the common tools you would use to download, spider, archive, spindle, mutilate web pages know how to deal with this
It’s certainly one solution. The http basic auth built into every popular webserver is another, with none of the above limitations. But I guess that would require spending 5 minutes learning and implementing some server config, and why do that when you can further ruin the web by shoving yet more user hostile complexity into client side JavaScript.
Sorry to sound bitter I just feel this is a really bad idea if you think about it for any length of time.
The obvious advantage of OP's approach is that one doesn't need to control the server that serves the HTML (e.g., static site served via GitHub pages would be enough)
This also works without a webserver. It can be a local file that is opened in a browser.
Bad idea. Your browser comes with web crypto, including AES256 and PBKDF2. See MDN.
Using a dynamic script or application to generate a static html page that requires no JS execution is a static page.
Using a static HTML page and then hiding it behind javascript execution is explicitly not a static HTML page.
Use .htaccess. And if you can't, reconsider the choices you made that restrict your abilities so significantly.
For example, I have a perl script that generates a set of .html files every night to show new additions to my library. They are static .html files on disk and never modified before the user views them. Just because a perl script (not connected to the web server in any way) made it does not "taint" the HTML so it is not static. The program, or the person, that wrote the HTML does not matter. All that matters is that it's just static unchanging HTML.
If your perl script is saving the HTML to the disk, then yeah, your website is static. If it's generating HTML on the fly, it's dynamic. That's the widely agreed upon meaning, and that's it.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Websit...
> You can use Amazon S3 to host a static website. On a static website, individual webpages include static content. They might also contain client-side scripts.
By contrast, a dynamic website relies on server-side processing, including server-side scripts, such as PHP, JSP, or ASP.NET. Amazon S3 does not support server-side scripting, but AWS has other resources for hosting dynamic websites. To learn more about website hosting on AWS, see Web Hosting.
I don't think this has been the common meaning of "static page" for at least 10 years.
From Wikipedia [0]:
>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored
Static refers to the fact the files are served without any application-level processing on the server side beyond simple file serving. A page can depend on CSS/JS/WASM and still be a static page.
Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script. The point is that there's an html file sitting on disk and the server delivers it without modification and it's viewable in the browser as it. It's just the webserver sending the contents of the file.
Whereas this "Password protected a static HTML page" cannot be viewed in the browser without a "web application", the javascript, dynamically changing the file. It's pretty clear cut. So it fails the test of the very link you posted:
>in contrast to dynamic web pages which are generated by a web application
> Any personalization or interactivity has to run client-side, which is restricting.
>Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script.
Yes, agree.
>The point is that there's an html file sitting on disk and the server delivers it without modification and it's viewable in the browser as it.
No, I don't think that's the widely understood interpretation of "static web page."
Even the definition you agree with just says the file is delivered as-is. It says nothing about how the browser renders the page.
JavaScript is not HTML.
https://en.wikipedia.org/wiki/Dynamic_HTML
"DHTML allows scripting languages to change variables in a web page's definition language, which in turn affects the look and function of otherwise "static" HTML page content after the page has been fully loaded and during the viewing process. Thus the dynamic characteristic of DHTML is the way it functions while a page is viewed, not in its ability to generate a unique page with each page load.
By contrast, a dynamic web page is a broader concept, covering any web page generated differently for each user, load occurrence, or specific variable values. This includes pages created by client-side scripting and ones created by server-side scripting (such as PHP, Python, JSP or ASP.NET) where the web server generates content before sending it to the client."
In my head, a static page is something that's served verbatim, without some backend generating it or inserting things into a template.
Wikipedia seems to agree with that view: https://en.wikipedia.org/wiki/Static_web_page
Otherwise, all of the React server side rendering is static HTML.
If you pre-compile the HTML using something like Jekyll, so that the webserver is just serving HTML files without any dynamic/on-the-fly processing at request time, then it's considered static.
React on the client side: static, as you still got the same files served, how they dynamically alter the page runtime doesn't count.
The issue is whether they are being generated dynamically by a server. This project isn't. You run a build-tool once and then can post the .html page anywhere. It's static.
CSS and JavaScript and images are also static, it doesn't have to be just HTML
If you have a perl or bash or c backend generating html in response to http requests it's not static
'Static' means it's only made of static files that can be served by just a vanilla Web server (i.e. just by serving static files).
The combination of all of these direct a browser in how to render a page.
Traditionally, a static site or static page is one whose data can be delivered to the client directly as stored, with no server-side alterations or generation.
This is/was a meaningful distinction because a server that can stream stored data is fundamentally much simpler than one that executes programs. Such a server can run in different contexts, be optimized in different ways, and satisfies constraints that allow further optimizations downstream.
As far back as I remember (and I played with JavaScript when it was first introduced in beta for Netscape), a “static web page server” always meant that there was no backend server generating pages on the fly.
If you want to just have a free small private static page which is easily updated by public CI offerings this is a great solution, and the title transports this clearly.
The expression "dynamic" was trending a decade or two ago to vaguely refer to javascript+HTML5. It was never the opposite of "static" in this domain.
I understand static pages as files sent to a browser without having to be generated server-side.
Yes, "Dynamic HTML" vs "Static HTML" to refer to JS-dependent and JS-free pages respectively has been around since the dawn of javascript, but my copy of the 1996 O'Reilly CGI Programming on the World Wide Web by Gundavaram contains sentences like
"Virtual, or dynamic, document creation is at the heart of CGI" (p.4)
"A common use for [server redirection] is to return a generic document that contains static information. [...] Suppose you have an HTML file (thanks.html) like the one below, that you want to display after the user fills out one of your forms: [...] You could use the programs discussed earlier to return static documents, but [...] it is much quicker and simpler to [redirect with a "Location" header]." (pp.44-45)
...without mentioning javascript anywhere.
The solution (with a server) is: https://oauth2-proxy.github.io/oauth2-proxy/