On Tue, Aug 17, 2010 at 4:00 AM, Jeremy Orlow <[email protected]> wrote: > On Tue, Aug 17, 2010 at 12:31 AM, Dirk Pranke <[email protected]> wrote: >> >> On Mon, Aug 16, 2010 at 3:58 PM, Ian Hickson <[email protected]> wrote: >> > On Tue, 30 Mar 2010, Dirk Pranke wrote: >> >> >> >> Nicholas is almost certainly discussing the case where the service >> >> provider requires any data stored on a customer's computer to be >> >> encrypted, not the provider's own computers. (e.g., this could be a >> >> Yahoo! policy that data stored on Yahoo! users' computers must be >> >> encrypted). >> >> >> >> Hence they cannot enforce anything like "use FileVault". >> > >> > If you can't enforce whole disk encryption, but you are concerned that >> > an >> > attacker could have access to your machine, it seems that there is no >> > solution, since an attacker could just install a rootkit and then carry >> > out arbitrary attacks remotely, including simply replacing the browser >> > with one that intercepts all the user's data as it is written. >> > >> >> While it is true that it would not defend against all attacks, it will >> still defend against some classes of attacks (e.g. casual snooping), >> and may still be valuable. > > Adding API surface area to defend against "casual snooping" seems a > bit ridiculous/overkill to me. Especially when web apps can do this in JS > today if they really wish.
I was not intending to suggest that it was a reason for adding an API, simply to point out that not being able to defend against a rootkit is not a good reason *not* to do it. Especially since full disk encryption won't save you if you've been rooted, either :) I continue to think that the best approach to start with would be to implement a library in JS that did crypto on top of the Platform APIs (and having a native crypto API would be nice as well), and if it turned out to be useful we could roll it into the platform. -- Dirk
