Is E2EE encryption a foolish idea for a LiveView app?

Whatsapp is a good example of an end to end encrypted chat app that is powered by the BEAM, the Erlang VM that Elixir runs us, so I don’t see any issue in building an end to end encrypted application in Elixir.

Sure! But I’m thinking that a lot of what you do with the data happens on server. If that is an intentional black box created on the client with encryption, then maybe having all the server side goodies are (to some degree) wasted.

Idk

If your records are all encrypted blobs, you can basically ignore anything to do with forms, possibly any kind of “delete child record” actions too depending. You will have to either write custom hooks to decode and encode the (“dead”) form data before transport, or write the form in vue/react/svelt/whatever (and still decode/encode). Hydrating/dehydrating data into and out of the form wont be hard, but rapidly you’ll need some validations etc, which you’d end up building yourself vs using a framework.

It also depends on how sensitive your data is. Can you store the list of vendor clients, and render those via liveview only loading your whateveract-form when editing some records, or is the existence of a client alone sensitive? If everything is sensitive then like you say, you wont get much from liveview when your state is opaque_blob_a → opaque_blob_b, but maybe most of the time your just writing liveviews and only have a few select black boxes around the place.

So disregarding any sensitive interactions, what do you have left? Do you want to push notifications around? Still use a websocket for transport speed? Is it better to just have a/many regular phoenix channels for these? Do you just prefer heex over jsx? If most of your elements are phx-update="ignore" then you wont get much quick dom diffing.

You can embed js frameworks inside LV and use hooks as an adapter layer, but you will hit some friction vs using one ecosystem alone.

see @jstimps’s implementation for an example: GitHub - jessestimpson/livesecret: Share end-to-end-encrypted data · GitHub

Thanks for the mention! The answer by soup above hit the nail on the head.

For LiveSecret, we’re only maintaining E2EE for a single form field, and everything else has encryption terminated at the server via TLS like a typical Phoenix app. With this model, we can still take advantage of the power of LiveView and Elixir for the manipulation of the metadata. I’m happy to answer any questions about the implementation details.

On CRDTs, it depends on the data type. For example you would not be able to have full E2EE on a “increasing counter” CRDT because the server inherently knows the value, but a “last write wins” CRDT is just a binary blob so it can store your encrypted data without issue.

In general, you may find value in 2 exercises. (1) Mapping out all of your desired data flows and then figure out where you must apply E2EE and/or CRDTs. If you find you can manage most of your data via traditional means you’ll have more flexibility down the road. And (2) implementing a proof of concept in LiveView and perhaps some other JS framework.

Thank you @soup for elaborating and sharing your thoughts.

Well, I would like to say that, yes, the nature of the industry is indeed such that the mere fact that a client is a client should warrant having it a “blob of silliness”. Then, there is reality. I’m pretty sure that a review of the data model, field by field, would result in only a select group being black-boxed.

A big part of the application is also document management, where the documents themselves wouldn’t be affected but obviously all data required to manage said documents.

I hope that more people have some kind of utility of, or interest in, these discussions.

Again, thanks.

Thanks for taking the time @jstimps! You can bet that I have reviewed your LiveSecret project – terrific job there

I’m especially grateful that you elaborated on the CRDT part of the issue.

I’ll sit down with the plans tomorrow and draw this up, looking at the data flows as you mention.

The end product will thankfully be open sourced. I’m afraid the initial MVP won’t be due to [redacted]. Will try to share as much as possible.

Hope more people than I are interested in the E2EE space. Especially now with the epic misstep that is the so-called Chat Control 2.0 proposed legislation