All work is performed by the client web-browser; the web host merely serves the files.
Warning: This is only proof-of-concept! Both base-64 encoding and encryption inflate the size of data (by ~35% each). Files larger than 1 megabyte are likely to crash your browser.
Output: Will appear between the rules:
Obviously: when using this tool in earnest, do not prepare your URI with the shared secret as a query ¶meter=argument pair. Transmit it to the recipient by some other means.
/script /components ... /rollups ...
As with everything in the security and privacy domain, trust changes everything. Don't do it. Don't fall into that trap. Do what you do because you have gathered empirical proof sufficient to convince yourself your confidence is well-placed; not because you have naïvely gambled your trust on some anecdotal claims. Learn from a consensus of reputable sources how the algorithm works; download open-source implementations and verify they do what they claim to; encrypt your own user-supplied test string and then come here to validate that this site produces matching output for matching input. No amount of this website claiming it passes unit-testing checks on the specific values I have carefully selected can convince you the algorithm is authentic. Do it yourself.
This site is transported to you via HTTPS. HTTPS is almost always a bad idea because the traffic conveyed is opaque to intermediaries which prevents the entire web caching proxy infrastructure integral to their ISP, your ISP, your router, and your local browser from being able to optimise repeat requests by re-serving from the cache. If you quit your browser, fire it up again and navigate back to this URI, the page will need to be re-transmitted all the way from the origin host. Even though you just had it up a moment ago locally and nothing's changed. That's horribly inefficient. If you ever see websites obstructing access to content with banners and pop-ups justifying the webadmin's choice to spam all their visitors with promotional advertising just to cover the fees for bandwidth service, now you know why. The other problem with HTTPS is that many hosts recently transitioned from SSL to TLS. When this happened, all the embedded devices running a web browser from firmware that cannot be upgraded abruptly lost the ability to communicate with those sites, and due to heavy HTTPS Everywhere promotion, that's just about every site these days. It's a disempowering precedent to set; handing over the keys to an entire generation of smart devices to industry giants to remotely obsolete the moment they have a new line-up to sell.
Be that as it may, the fact that HTTPS obstructs any optimising mechanisms attempting to cache content is a perk in this specific circumstance because cyphers decrypted within the page are likewise opaque to caching mechanisms. The user can of course right-click the decrypted content and Save Link As or Save Image As to persist a non-volatile copy of the content. But the browser is unlikely to do that all by itself. Of course, you never know what closed-source software is doing behind the closed doors of its black box implementation. It could be doing anything in parallel with the main effect you expect. Electing to trust intentionally opaque algorithms is entirely optional.