7 ms·

I 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

• lipis 7y ago
  It's open source :)
  • m1el 7y ago
    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.
    • lipis 7y ago
      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.
      • deleted 7y ago
        [deleted]
      • sneak 7y ago
        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`.
    • franky47 7y ago
      If the JavaScript bundle that is being served is built on a public CI/CD service, it could be possible to do the following, for transparency and verification: - Include in a header comment: the build URL, Git SHA-1 of the commit, and other metadata - Sign the bundle using public/secret key cryptography Having the build URL and sources URL help with discoverability and transparency, while integrity can be verified with the signature. Adversary models now shift from the bundle provider to the CI/CD platform that runs the build, and any PKI used for the public key for signature verification. If the public key is versioned with the code, it can help reduce trust to a single entity (where the code is stored).
      • rcxdude 7y ago
        Yes, but there's no provision in the browser to do these kinds of integrity checks. If the browser isn't verifying it there's no point in adding any of this info, because it can be substituted covertly. In principle such 'version-pinning' could be added to the browser, but no-one has done so yet.
        • franky47 7y ago
          Agreed. Even subresource integrity [1] does not help here, because if the HTML is compromised, then everything else can be too. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
    • rhn_mk1 7y ago
      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).
    • maple3142 7y ago
      Don't this still apply to a native client? You can be sure unless you build the client from source, but you can also build the website from source too right?
    • kybernetikos 7y ago
      Subresource Integrity allows the HTML file to insist that the js file hasn't changed. I guess it would be possible to download and run the html file from your own machine. Alternatively, it would be possible to create a service worker that uses a local copy and makes much more of a deal about files changing - it could always confirm changes with the user before allowing a change. Security sensitive apps should probably be doing this.
      • tatersolid 7y ago
        JS allows overriding overriding any object or method with separately loaded code. So even your “trusted” code could be compromised by separate “trusted” code. Even native app packagers and languages can suffer from this when loading libraries dynamically (from search-path or symlink manipulation for example).
• dylkil 7y ago
  >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.
  • henriquez 7y ago
    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.
• MaxBarraclough 7y ago
  LastPass has the same problem.
• _bxg1 7y ago
  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.
  • m1el 7y ago
    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.
    • _bxg1 7y ago
      Others have said it's open-source. Build it yourself, inspect what your browser downloads, hash and compare like normal.
      • dependenttypes 7y ago
        You can certainly do it, but the rest of the users will stay vulnerable.
      • nwsm 7y ago
        It doesn't even have to be open-source. Any JS that will get run is handed to your browser and you are able to inspect it.
        • gary-kim 7y ago
          Have fun trying to inspect Javascript code after it has gone through Webpack, Babel or anything else that may have been used for transpiling. Not saying it's impossible but it's still really annoying to do. To add on to that, when there's an update, you usually can't diff it properly because large parts of the transpiled Javascript may change because of a one line change in the actual source code. This is all assuming the website isn't actively trying to make it difficult for you to analyze their code. At least if it's open source, you can inspect the source code then verify that the output is the same.
• smolder 7y ago
  Modifying source to extract keys runs a risk of detection; it is overt. So it's preferable to passively snoop. If someone has a way to passively snoop TLS contents, the extra encryption protects data from them.
• dwheeler 7y ago
  Agreed. If it stored data on a different server (allowed via CORS) then there could be some additional security, since then as a long as the JavaScript isn't subverted on the same site, you're storing encrypted data on a different server. But yes, if you run JavaScript, you're always trusting that site to not do a "quiet update" of the code to something malicious. I don't see any obvious way to counter that, short of downloading the JavaScript code & running it yourself.
• geofft 7y ago
  It's using end-to-end encryption to address a slightly different threat model than the usual one: the website operator doesn't want the liability/danger of holding cleartext data. E2E does solve this even in the browser scenario. Now an attacker who dumps the server's disks doesn't compromise user data, they'd have to activate modify the website. This raises the bar of a successful targeted attack and aldosterone basically eliminates risk from untargeted attacks, which is well worth doing. (Also now warrants that can compel disclosure have nothing they can target, eliminating Lavabit-style attacks. There's still the possibility of court orders making you write software like the proposed use of the All Writs Act against Apple, but that's on much less certain legal ground.) It's true that this doesn't let you avoid trusting the provider, but you're not going to get that anyway - and this scheme is certainly no worse. (Arguably you're not going to get that on native apps either these days, thanks to closed-source app stores and automatic updates, and automatic updates are a very good thing.)
  • est31 7y ago
    > It's true that this doesn't let you avoid trusting the provider, but you're not going to get that anyway - and this scheme is certainly no worse. (Arguably you're not going to get that on native apps either these days, thanks to closed-source app stores and automatic updates, and automatic updates are a very good thing.) There is no guarantee, but security researchers often check the contents of apps like WhatsApp, Threema, etc. However, that doesn't help you if you specifically get a special version of the app that sends your content to the app writers. For websites, how hard this is depends on your infrastructure, but it is more or less trivial. For app stores like Google Play or apple app store, there is no such feature to push a special version to a subset of the population specified by name. You can only push it to entire classes of devices. So suddenly Google, Apple, etc. have to be in on the attack which drastically reduces the number of people who can pull off supply chain attacks. Maybe you should be still worried about the US government, but while Saudi princes can bribe the Threema creator, they can't compel Apple to push a malicious update the Threema creator signed to select people only. So they'll have to hack the device via other means.
    • derefr 7y ago
• bconnorwhite 7y ago
  Why encrypt passwords? E2E encryption is similar in that as it is much for the website owner as the client. Data is a liability
• thanksforfish 7y ago
  > there isn't much security added by encryption Compared to just using HTTPS? While there are ways the encryption can be removed or subverted that's a far cry from adding no benefit. Compared to just using HTTPS for client to server encryption, this protects the user from a bunch of server-based attacks. Certainly not all, but it does meaningfully raise the bar. Keep in mind that security needs to be usable, and needs to exist in tools users actually use. If I'm a user if a web app, then browser based e2e encryption helps me. Downloading the diagram, installing PGP tools, figuring out how to use it, sending the file via a different mechanism... probably not something an average user wants to try.
• xvector 7y ago
  Are there any current browser standards for validating that the served JS is ‘safe’? I can see such a thing being also useful for applications like ProtonMail, for example? What about something like a browser extension that queries an audit server for a list of signed hashes of ‘safe’ JS? - Well-known code auditors could perform reviews of JS - They could sign JS they find safe with their PGP keys and upload it to some server - Users could choose to trust certain auditors - Every time you visit a site that you choose to require this kind of validation, you could check that the hashed JS matches the key I guess we’re going the way of PKI+SHA hashes of distributed binaries all over again though. Also, if the website updates JS, you’d need to wait for auditors to review it, and there’s a whole mess there (websites would probably have to serve beta versions of their code ahead of release so auditors could have time to review them). Finally, JS would have to be static across all users and I’m not sure how feasible this is. There is some benefit, though? Now you are distributing the trust over ProtonMail and your trusted auditors. This could be useful if we find ProtonMail to be compromised one day. This might even spawn businesses aimed solely at reviewing websites’ code. There has to be a better way to do this. How can we bring ‘code review’ to web applications?
  • vbezhenar 7y ago
    You need to sign an entire chain of HTML+JS+CSS+everything else, as you can build keylogger with CSS. Web if weird. I wouldn't be surprised to find out that one can build keylogger with some tricky font file. But it definitely should be possible to build an addon like that. Although it would require some good cryptographers as not to make a mistakes. I don't think there are any browser standards for that. I guess that such a webapp is too niche and this threat is extremely niche, so very few people would care for it to be a general purpose standard.
  • cxr 7y ago
    dat:// can give you that.
    • xvector 7y ago
      Could you elaborate? Some quick Googling didn't turn up anything.
• duxup 7y ago
  I'm not refuting your point here but it feels like on HN everytime we hit any web topic there are the kind of comments about "wait but this could happen / what if the website owner is malicious / included some wonky code he doesn't know about, etc". They're not wrong, but also not the point of the article. >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. This seems to be the point of the article, and valid IMO. Yet on HN more and more we get dragged off on these larger state of the web topics. They're not wrong either, but I feel like the volume sort of drown out the point / valid topics too.
• nwsm 7y ago
  All JS is executed in the browser. If the malicious site wanted to steal the data, it must send the key to the server. With enough inspecting, debugging, and network watching you would be able to see what they're doing and how. While I agree you can obfuscate this in the JS payload, it doesn't make e2e encryption in web apps "meaningless". It would just take one user doing some due diligence to expose the malice.
  • vbezhenar 7y ago
    It does not work this way if this attack is targeted on a very few users and it's trivial to serve a different scripts to a different users.
• thekyle 7y ago
  So just load the JS locally from a browser extension. I know MEGA (end-to-end encrypted cloud storage) has an extension for that. I'm sure other end-to-end encrypted web apps (ProtonMail, Bitwarden, etc) could do the same. https://mega.nz/extensions https://mega.nz/extensions
• jstanley 7y ago
  I like this kind of design in conjunction with delivering the code over IPFS. That way you know the code has not been tampered with, as long as you trust your IPFS gateway.
• rixtox 7y ago
  I think the key problem here is where and how do we establish a root of trust for Web applications. Currently we have some form of root of trust for HTTPS/TLS, code signing, trusted execution, that the OS or browser or chipsets distribute a set of "trusted" root certificates. For the consumers, they are implicitly backed by the big companies that manage the screening, auditing, and distribution of these certificates. But of course, these certificates have limited use cases that not yet covering the end-to-end encryption application for Web. One way or another, we have to start our root of trust at some layer, either it's hardware, OS, drivers, or applications. But in general, the lower the layer gets, the lower the risk would be. Because it's easier for an evil actor to target specific user in higher layers. There are more to be solved than just the root of trust for E2E on Web. For example, even if we can use trusted execution environment on a Web application to ensure secure key generation and key escore, we still have to face the problem of how to input or present the cleartext data with the user. If we still let the JS code to handle the cleartext in any way, there could still be a chance that the distributor of the JS code might steal them. With that said, not only should we have a root of trust, but we also have to trust the UI provider that operates on the sensitive data for user input or display. The lowest UI layer is usually the OS, so even we have hardware root of trust, but if the trusted UI is in the OS layer, we would still be throttled at the level of trust on the OS layer.