In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less useful))

The encryption itself is solid (assuming it is implemented correctly and as described, I've not inspected the code) but as mentioned a short pass phrase combined with predictable plain text format would make this quite easy to brute force.

The pass phrase also can't be changed, without reencryping the entire page. Once leaked, the contents are effectively publicly available.

Also, you can't revoke access (again, without site-wide re-encryption).

An interesting POC, but not something that is really practical for broader use.

I considered both these points when I was composing my answer but came to the conclusion that this is true for basically any encryption strategy, if I've transmitted contents signed with your public key then when your private key becomes known so does the contents.

Even when you manage to keep the key secret I can't revoke your access to the material or prevent you re-transmitting it to others.

True, but if there's one shared key for each page, the chances of that key getting loose are higher. There are alsomethods of encrypting a message where you can specify multiple recipients (i.e. multiple keys), letting you remove one key without affecting the viewership of the page for people with the other keys.

It's a hard problem, and this is certainly a novel solution to that problem, but I still don't really see myself using it.

you could just do the encryption on the server side, in which case you just change the key and done.

/s

Doesn't the GitHub pages content itself live in a repository visible to all? One could just look up the password. Or is it possible to have pages for private repos as well?

The passphrase wouldn't be included in the repo; that's the purpose of using client-side encryption.

What Darphe said in their reply. But yeah, you can setup pages for private repos. That's mainly what I was thinking. I currently do that for a few projects. You can have a private repo and still use github-pages, it just obviously exposes the pages to the public technically (but not the repo code).

Not an encryption expert, and would likely use it myself.

My guess is it's about as secure as putting an encrypted file on the internet. Except this has almost all the information you need to know how it was encrypted. Plus it has a useful guess-the-password form. There is no attempt-limiting or rate-limiting if you can download the file.

I'm no expert but I think if they use a cryptographic function that requires a lot of CPU cycles, such as bcrypt, it will still be hard to brute force as long as you use a secure password. It looks, however, like they might have used something like sha256. I don't think that requires a lot of CPU and so it's much easier to brute forced.

It's probably good enough for stuff like an informational product that you want to put behind a password but not good enough for storing your credit card details.

short answer: no, it's not secure

longer answer: look at the last script tag in the demo page, it exposes the encrypted HMAC string, the encrypted HTML text, the encryption method and even the library used to decrypt. You can easily brute force the passphrase

...or better yet embed some code in a popular web page and have the netizens brute force it for you (distributed computing).

In general, client side obfuscation is difficult to perform securely as it shares too much information to be secure.