Hah, this is another thing I've been thinking about recently :) It's cool to see tools like this popping up.
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?
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?