End-to-End Encryption in the Browser and how we did it in Excalidraw
blog.excalidraw.com
End-to-End Encryption in the Browser and how we did it in Excalidraw
1–5 of 5 posts
Re: End-to-End Encryption in the Browser and how we did it in Excalidraw
#2Nice 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
Re: End-to-End Encryption in the Browser and how we did it in Excalidraw
#3Nice 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
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...
Re: End-to-End Encryption in the Browser and how we did it in Excalidraw
#4Nice 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
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...
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)
Re: End-to-End Encryption in the Browser and how we did it in Excalidraw
#5Earlier quoted context omitted.
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...
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…
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.