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.
well, not the whole url, obviously, otherwise the router wouldn't know where to send the request
End-to-end encryption in the browser
31–40 of 112 posts
Re: End-to-end encryption in the browser
#32Earlier quoted context omitted.
And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.
In theory you can generate the code locally and compare it with the deployed version to see that it's one to one.. But maybe we could do something in order to improve the said security check.
Not even in theory: the version you download to "check" and the version served to your web browser may not be the same content, as the webserver can respond with different content for the same URL, on a per request basis, for example serving the exploit code only to a specific ip + user-agent header combination, so that it steals your keys in your browser but shows the safe version to `curl`.
Re: End-to-end encryption in the browser
#33Earlier quoted context omitted.
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 th…
yeah, this. Having the key in the url seems insanely insecure to me.
Why? It makes it easy to share a sketch with someone else while still preventing the server from decrypting the data. Anything stored in a location hash (after the # symbol) does not get passed to the server.
The threat model the author tried to work around is not the user dumbly compromising their own work. The author wants to prevent proprietary and PII data from being stored on their own server. End-to-end encryption significantly reduces the author's potential liability hosting something like this in case something goes wrong.
Re: End-to-end encryption in the browser
#34JavaScript "encryption" is like sending someone a letter in a package with a TSA lock on it, asking them to communicate secretly with you. They send you back the package with the lock, and instructions on how to communicate securely. You send the package back with the lock and your message encrypted according to the instructions.
It doesn't matter what your encryption scheme is. The TSA lock means the TSA can control the content. But the user assumes their communication isn't controlled by the TSA, because they are receiving instructions that appear normal.
Re: End-to-end encryption in the browser
#35From one of HN's own stars:
Javascript Cryptography Considered Harmful: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
There are some out of date bits, but the core of the post is still as true as it was back in 2011.
Re: End-to-end encryption in the browser
#36I 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.
How does that differ from a native app? In any E2E context you have to trust the client code.
Sure, there are a couple extra steps needed here:
- The website author needs to avoid casually throwing in dependencies (unlike perhaps the average JS project)
- HTTPS for loading code resources is crucial; maybe even CDNs need to be avoided
- The user needs to avoid having browser extensions enabled
But the fundamental problem doesn't seem different nor intractable.
Re: End-to-end encryption in the browser
#37Earlier quoted context omitted.
It's open source :)
And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.
If browsers supported it, then it could be done much the way Linux distro packages work: include a signature from a trusted party together with the code, as a guarantee of being verified to match some standard (e.g. same as CI, or not malicious).
Re: End-to-end encryption in the browser
#38Looks neat!
End-to-end encryption in the browser is not perfect security, as other comments are saying, but it’s significantly better than having user data in clear on a MySQL database somewhere.
PS. I’m the founder of Userbase.com — an open source service to help you build end-to-end encrypted web apps like this.
Re: End-to-end encryption in the browser
#39I 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.
Right. "Javascript cryptography considered harmful" is a trope at this point, but that doesn't make it an axiom. The author is using this to _not store users' private data_ on their own infrastructure.
Even if Excalidraw _was_ compromised and someone put malicious JS code in the app, the total scope of the breach would be very limited. Records could only be exfiltrated on an individual basis, and only if the users opened their URLs and exposed the decryption key to the malicious Javascript payload.
This is a smart way to offer a free service without worrying too much about liability or compliance with the ever-expanding set of regional privacy laws.
Re: End-to-end encryption in the browser
#40I 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.
How does that differ from a native app? In any E2E context you have to trust the client code. Sure, there are a couple extra steps needed here: - The website author needs to avoid casually throwing in dependencies (unlike perhaps the average JS project) - HTTPS for loading code resources is crucial; maybe even CDNs need to be avoided - The user needs to avoid having browser extensions enabled But the fundamental prob…
I can build a native app from the codebase myself. I can be sure that a native up won't change in-between launches.
> In any E2E context you have to trust the client code.
I don't have to trust code which is continuously being delievered from the server. This is an intractable problem.