3 ms·

I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a c

I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a compromised provider to serve you a malicious version of the application. I suppose it's the difference between TOFU (Trust On First Use) and BEEF (Beware Each & Every Fetch). Okay, I made up that second acronym, but it seems like a reasonable name for that threat model. Anyway, as the sibling comment points out, the distinction is fairly moot if you have an auto-updating native application. To improve the situation for native applications, it would make sense to use a tamper-evident log like Trillian[0] so that a package manager or auto-updater can be sure that it is receiving the same binary as every other user (and possibly after a sufficient delay to allow reviewers to raise the alarm about the corresponding reproducibly-buildable source code). Applying this to web applications is more tricky, but can be done using the bookmarklet-dataURI trick[1] which effectively allows the user to freeze a copy of a web app "bootloader" that pulls in the remaining resources after checking their signatures against a hardcoded public key (as well as against a Trillian log). [0] https://transparency.dev/application/add-tamper-checking-to-a-package-manager/ https://transparency.dev/application/add-tamper-checking-to-... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456

feross 6y ago
Thanks for the pointer to bookmarklet data uri trick - that's clever. I posted this elsewhere in the thread, but just wanted to mention it again in this context. Hyperboot [1] uses AppCache to give users the benefits of explicit, immutable versioning with control over upgrades using the html-version-spec while preserving the simplicity of passing around a URL. It offered the usability benefits of web apps – you can give someone a URL and they can immediately load the app – with the security of installed apps – doesn't change without warning. Unfortunately, AppCache is being removed from the web platform and there's no way to use ServiceWorker to accomplish the same thing. [1]: https://github.com/substack/hyperboot https://github.com/substack/hyperboot
- dane-pgp 6y ago
  Yes, it's a pity that AppCache and ServiceWorkers won't be able to support this use case. Also, the data URI trick comes with its own limitations, such as the fact that the address bar won't present an actual domain name or padlock, so it has a slightly worse user experience than normal websites. One simple way that the web platform could be improved, then, would be to adopt something like the Hashlink proposal[0], which would allow the hash of the initial "bootloader" to be stored in the query string. If this were possible then a simple bookmark would suffice, or a URL sent in an email, as your comment suggests. [0] https://w3c-ccg.github.io/hashlink/ https://w3c-ccg.github.io/hashlink/
josephg 6y ago
> I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a compromised provider to serve you a malicious version of the application. Maybe. Lets imagine Google Chrome's update servers were compromised for a day, and the servers hosting a somehow equally popular e2e web based chat app were compromised for a day. For chrome, it will effect fewer users (most people only update chrome every month, so it only hits 1/30 users). Whereas every user who opened the chat app would be compromised. The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user. Everyone gets the same bad code. An infected version of chrome would do a lot more damage than a website (because native desktop apps aren't sandboxed at all). And when the website clears the infection the next day, all infected users of the chat app would have the malicious code removed from their system[1]. But unfortunately, an infected copy of chrome would presumably have its update mechanism stripped out, so it would stay evil much longer. Though maybe this is a wash, because Microsoft and Apple have malicious software detection and removal built into their OSes. I don't see this as a slam dunk for native software. > To improve the situation for native applications, it would make sense to use a tamper-evident log like Trillian This is a fantastic idea. I'd love to see this explored more, and I wonder if we could do something similar some day built into browsers for web apps. Interestingly it also makes a strong case for apps (like chrome) not having their own binary responsible for updates. Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores. And of course, we need better system level application sandboxing in order to reduce the impact of this sort of attack. Its crazy that a malicious binary on my computer can download and modify all data on my computer (owned by any app), and access network shares using my credentials. [1] I think - there might be ways to prevent this with evil service workers. Does anyone know?
- dane-pgp 6y ago
  > (most people only update chrome every month, so it only hits 1/30 users). What do you base that on? My understanding is that a system with Chrome installed will check for updates every 5 hours[0], and I assume most people accept the update on the day that they see it is available. > The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user. I'm also not clear what you mean here. An attacker could decide to target a victim by their IP address, or any detail about their computer which is available to Chrome. I agree with you though about native applications being able to do more damage, and possibly persisting on a machine for longer. > Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores. On the other hand, the user isn't secure against threats from the app stores themselves, not least the threat to Availability when an app store uses a kill switch to delete an app without warning.[1] [0] https://support.google.com/chrome/a/answer/6350036?hl=en https://support.google.com/chrome/a/answer/6350036?hl=en [1] https://www.macworld.com/article/191897/iphone_killswitch.html https://www.macworld.com/article/191897/iphone_killswitch.ht...

feross 6y ago

Thanks for the pointer to bookmarklet data uri trick - that's clever. I posted this elsewhere in the thread, but just wanted to mention it again in this context. Hyperboot [1] uses AppCache to give users the benefits of explicit, immutable versioning with control over upgrades using the html-version-spec while preserving the simplicity of passing around a URL. It offered the usability benefits of web apps – you can give someone a URL and they can immediately load the app – with the security of installed apps – doesn't change without warning. Unfortunately, AppCache is being removed from the web platform and there's no way to use ServiceWorker to accomplish the same thing. [1]: https://github.com/substack/hyperboot https://github.com/substack/hyperboot

dane-pgp 6y ago
Yes, it's a pity that AppCache and ServiceWorkers won't be able to support this use case. Also, the data URI trick comes with its own limitations, such as the fact that the address bar won't present an actual domain name or padlock, so it has a slightly worse user experience than normal websites. One simple way that the web platform could be improved, then, would be to adopt something like the Hashlink proposal[0], which would allow the hash of the initial "bootloader" to be stored in the query string. If this were possible then a simple bookmark would suffice, or a URL sent in an email, as your comment suggests. [0] https://w3c-ccg.github.io/hashlink/ https://w3c-ccg.github.io/hashlink/

josephg 6y ago

> I think the argument against web-based software is that because you effectively re-download the application on every visit, there are more opportunities for a compromised provider to serve you a malicious version of the application. Maybe. Lets imagine Google Chrome's update servers were compromised for a day, and the servers hosting a somehow equally popular e2e web based chat app were compromised for a day. For chrome, it will effect fewer users (most people only update chrome every month, so it only hits 1/30 users). Whereas every user who opened the chat app would be compromised. The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user. Everyone gets the same bad code. An infected version of chrome would do a lot more damage than a website (because native desktop apps aren't sandboxed at all). And when the website clears the infection the next day, all infected users of the chat app would have the malicious code removed from their system[1]. But unfortunately, an infected copy of chrome would presumably have its update mechanism stripped out, so it would stay evil much longer. Though maybe this is a wash, because Microsoft and Apple have malicious software detection and removal built into their OSes. I don't see this as a slam dunk for native software. > To improve the situation for native applications, it would make sense to use a tamper-evident log like Trillian This is a fantastic idea. I'd love to see this explored more, and I wonder if we could do something similar some day built into browsers for web apps. Interestingly it also makes a strong case for apps (like chrome) not having their own binary responsible for updates. Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores. And of course, we need better system level application sandboxing in order to reduce the impact of this sort of attack. Its crazy that a malicious binary on my computer can download and modify all data on my computer (owned by any app), and access network shares using my credentials. [1] I think - there might be ways to prevent this with evil service workers. Does anyone know?

dane-pgp 6y ago
> (most people only update chrome every month, so it only hits 1/30 users). What do you base that on? My understanding is that a system with Chrome installed will check for updates every 5 hours[0], and I assume most people accept the update on the day that they see it is available. > The problem on google chrome would be easier to detect, because it wouldn't be able to pinpoint a specific user. I'm also not clear what you mean here. An attacker could decide to target a victim by their IP address, or any detail about their computer which is available to Chrome. I agree with you though about native applications being able to do more damage, and possibly persisting on a machine for longer. > Apps on phones are more secure because a malicious binary can't stop itself being removed via Apple / Google's app stores. On the other hand, the user isn't secure against threats from the app stores themselves, not least the threat to Availability when an app store uses a kill switch to delete an app without warning.[1] [0] https://support.google.com/chrome/a/answer/6350036?hl=en https://support.google.com/chrome/a/answer/6350036?hl=en [1] https://www.macworld.com/article/191897/iphone_killswitch.html https://www.macworld.com/article/191897/iphone_killswitch.ht...