
End-to-End Encryption in the Browser and how we did it in Excalidraw - lipis
https://blog.excalidraw.com/end-to-end-encryption/
======
ubramlago
Nice approach to sharing the key! I didn't know the the part after # in a URL
doesn't get send to the server. Everything makes much more sense now. :D

~~~
_pius
_I didn’t know the part after # in a URL doesn’t get sent to the server._

While that is technically true, please know that it is not true in a way that
is meaningful for many threat models. The JavaScript running on the page can
trivially detect, inspect, and log changes to the location hash.

More information here:

[https://developer.mozilla.org/en-
US/docs/Web/API/WindowEvent...](https://developer.mozilla.org/en-
US/docs/Web/API/WindowEventHandlers/onhashchange)

~~~
j-f1
Isn’t this true of any client side site? If the client side JS has access to
some information, it’s always possible for the server to inject custom JS that
returns the data. Theoretically this setup provides little additional security
but it does allow (for example) people to use a client pinned to a version
they’ve verified to not leak information and collaborate without worrying
about leakage. (Excalidraw developer here)

~~~
_pius
Thanks for the interesting post. This isn’t a critique or evaluation of your
work and you did mention that the client side JS can read the location hash.

I agree with your comment. I just don’t want anyone to think that a key stored
in the location hash is somehow truly protected from ever getting back to the
server, which was how the comment to which I responded sounded to me.

