Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
Urls are encrypted.
End-to-end encryption in the browser
11–20 of 112 posts
Re: End-to-end encryption in the browser
#12Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
URLs are encrypted. Hostnames aren't encrypted in HTTPS, unless TLS SNI is encrypted.
The problem with URLs is that a lot of products will log the URL to disk, and many operators forget or aren't aware they might need to have security plans around data in the logs.
Re: End-to-end encryption in the browser
#13Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
Anything after the hash isn't sent to the server (it's mentioned in the article).
Re: End-to-end encryption in the browser
#14Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
The article explained how the fragment part of the URL (everything after the #) isn't sent to the server. It's only client-side.
So even if the URL isn't encrypted in HTTPS (it is though), it wouldn't matter.
Re: End-to-end encryption in the browser
#15Is this going to be legal in the US under EARN IT?
Re: End-to-end encryption in the browser
#16As with every in-browser encryption deployment - what's the threat model here ?
> I now sleep much better at night. If the hosting service gets compromised, it doesn’t really matter as none of the content can be decrypted without the key.
Which can be easily exfiltrated by the compromiser as they are now in a position to deliver and run arbitrary javascript in your users browser where the keys reside
Also, why can't I draw an actual non-flawed circle ?
Re: End-to-end encryption in the browser
#17I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption.
If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
Re: End-to-end encryption in the browser
#18Wait, so you're sending the key in the url? I thought urls weren't encrypted in HTTPS? Am I missing something?
URLs are encrypted. Hostnames aren't encrypted in HTTPS, unless TLS SNI is encrypted. The problem with URLs is that a lot of products will log the URL to disk, and many operators forget or aren't aware they might need to have security plans around data in the logs.
A worse and impossible to mitigate problem in other scenarios is that user agents will cheerfully "bookmark" or "favourite" a URL or just let you "share" it and it's often not obvious to the end user that this shares their current state which they probably don't want not just the thing they're looking at. Example: you try to share the forum help link but instead give the recipient your logged in account...
This is the reason not to put authentication tokens into URLs for example.
When the state users want to bookmark or share literally is the state that's encrypted anyway this mismatch isn't a threat. If I send you the URL for this drawing of a cat and then I'm astonished you can now see the drawing of the cat I've got real problems technology can't fix.
Re: End-to-end encryption in the browser
#19I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
It's open source :)
Re: End-to-end encryption in the browser
#20I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.
>As the maintainer of Excalidraw, I now sleep much better at night. If the hosting service gets compromised, it doesn’t really matter as none of the content can be decrypted without the key.
Seems the maintainer maded the point of protecting himself more than anything.