[whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

On Tue, Aug 17, 2010 at 4:00 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Tue, Aug 17, 2010 at 12:31 AM, Dirk Pranke <dpranke at chromium.org> wrote:
>>
>> On Mon, Aug 16, 2010 at 3:58 PM, Ian Hickson <ian at hixie.ch> 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