- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 4 Jan 2011 23:51:13 -0500
On Tue, Jan 4, 2011 at 10:53 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Note that you keep comparing websites to desktop software, but desktop > software typically doesn't change out from under the user (possibly in ways > the original software developer didn't intend). ?The desktop apps that do > update themselves have a lot of checks on the process precisely to avoid > issues like MITM injection of trojaned updates and whatnot. ?So in practice, > they have a setup where you make a trust decision once, and then the code > that you already trusted verifies signatures on every change to itself. HTTPS already prevents MITM attacks and most others; the major attack vector they don't prevent is a compromised server. I thnik the main difference is that the private keys needed to sign with HTTPS are normally located on the server delivering the scripts, whereas signed updates can keep their private keys offline. That's not a model web apps can mimic: all ways to execute scripts, in both Javascript files and inline in HTML, would need to be signed, which is impossible with templated HTML. > Perhaps we need infrastructure like that for websites; I'm not quite sure > how to make it work, though, since the code that the user trusted once is > not known to still be ok, unlike the desktop app case. You don't really know that an installer you download from a server is valid, either. Most of the time--for most users and most software--you have to take it on faith that the file on the server hasn't been compromised. But, yes, you only have to do that once with auto-updating systems, not on every update. -- Glenn Maynard
Received on Tuesday, 4 January 2011 20:51:13 UTC