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.

I agree, not intractable but there are meaningful differences:

* A native app can be installed once. A browser app is effectively downloaded fresh each time you use it. That give more exposure to attack. * A native app is downloaded, then run. A browser app does both in one step. Separation gives the user a chance to verify using hashes, signatures, etc, ideally cross checked from multiple different domains incase only the download server/primary domain is hacked. If there are sensitive user cookies, malicious javascript can steal them immediately on page load.

Native apps that update themselves can be a mess, but OS or package manager updates are generally carefully managed (I.E. apt).

For the CDN concern, sub resource integrity should work well (of course you need to verify that the version you hash is actually safe, which people sometimes skip). I think browser support is good these days.

But I agree, not intractable.

As a website it's trivial to serve different content to different users. Each page load can or cannot contain a compromised payload. And since the website also identifies the users it's also easy to target specific users.

To reduce that risk, and temptation, we want to be in a model where the likelihood of detecting a compromised payload is increased. This is why software distributions like Debian are important, because they serve the same content to all their users, and there is a chain of verification that is established. One vigilant user is enough to detect that breach.

An even better solution is if the source code is available because it makes it easier for vigilant users to find those undesirable changes. This, paired with reproducible builds also allow to independently verify that the compiled output is indeed produced from that given source code.

Somewhere on that line we also have App stores which don't gives much more guarantees than the website but transfer that trust from the publishers to the application distribution platform. A compromised user still has the opportunity to capture the binary and submit it for analysis.

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.

Others have said it's open-source. Build it yourself, inspect what your browser downloads, hash and compare like normal.

How do you hash your browser downloads? Also you need to perform that on every request. It should be possible with additional addons, but definitely not out of the box.

You can easily open the dev tools, view the payloads, and copy them locally. It would be trickier to prevent evaluation before you've done so, but all you have to do is not enter anything sensitive until you've checked

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.

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.

You can certainly do it, but the rest of the users will stay vulnerable.

> In any E2E context you have to trust the client code.

You have to trust it not to exfiltrate your local plaintext data, sure; but encryption and key management in a native app might be outsourced to a TPM chip, in a way where the native app can't steal the keys, nor decrypt anything "behind your back", in practical terms meaning there's a smaller surface-area of code to audit.

It differs from a native app in that every time they change the JS code behind the website, you would not know. You could have thoroughly inspected the source, and then when you go to use it tomorrow, that one line of spyware could be inserted.

For native apps, you can install a particular version from source and not change it.

>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.

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?

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.

dat:// can give you that.

Could you elaborate? Some quick Googling didn't turn up anything.

I’m guessing it’s the Dat Protocol → https://www.datprotocol.com

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.)

> 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.

AFAIK Google Play serves apk signed by a developer. So it can't just serve another apk without possessing developer private key. So this attack is possible but would require coordinating few parties. On the contrary, Apple AppStore signs the binary with its own key, so they can serve whatever they want to whoever they want and nobody will notice.

> 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. So suddenly Google, Apple, etc. have to be in on the attack...

With the Android ecosystem specifically, because the OS base-image is customized by the device OEM, an interested state actor can inject a rootkit into devices in their own local market merely by suborning their domestic OEMs, and then manipulating trade tariffs to ensure that domestic citizens are incentivized to buy domestic OEM phone brands.

(Thankfully, this doesn't apply to devices sold into foreign markets, as nobody can predict what brand of phone an arbitrary foreign-citizen person-of-interest is going to choose to buy. Even if they contain the rootkit, there's low likelihood of there being a foreign surveillance system set up specifically with the hopes of seeing what foreign buyers of domestic-OEM devices are up to.)

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.

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.

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

> 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.

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.

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.

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.

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.

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.

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 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).

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.

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/Subres...

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`.

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.

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).

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).

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?

Why encrypt passwords? E2E encryption is similar in that as it is much for the website owner as the client. Data is a liability

LastPass has the same problem.