Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

----- Original Message -----
> From: "Brian Smith" <bsmith@mozilla.com>
> To: "Nico Williams" <nico@cryptonector.com>
> Cc: public-web-security@w3.org, "Jarred Nicholls" <jarred@sencha.com>, "David Dahl" <ddahl@mozilla.com>
> Sent: Friday, June 10, 2011 2:54:27 PM
> Subject: Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

> The goals of the high-level crypto-related APIs are not clear. One
> ambitious goal would be to support use cases like a an HTML5 email app
> (like GMail) with S/MIME support. When you open up an encrypted S/MIME
> message, the browser can automatically decrypt it after the user has
> agreed to let it do so for this service. The browser allows HTML5 code
> (HTML+JS+CSS) from the provider to interact with the decrypted
> content, but it prevents any of the decrypted information from
> leaking--including leaking back to the email provider. When you reply
> or forward a message, somehow the web app can determine which keys to
> use for the recipients, without leaking unnecessary information about
> your social network back to the email provider.
> 
> To support this kind of use case, many things would have to change,
> besides supporting a crypto API and besides providing some kind of
> safe access to the user's keys. For example, the browser would have to
> limit the communication capability of the HTML5 code that is
> interacting with the decrypted data. And, it would have to prevent the
> contents of the decrypted data from affecting the layout of the part
> of the page that is observable to the HTML5 code that hasn't been
> trusted to have access to the decrypted data, because that would
> create a side channel. It would have to prevent prefetching of network
> resources linked from the decrypted content, and avoid it would have
> to avoid sending the referer header for links in the decrypted content
> that are clicked, for the same reasons. Etc., etc.
> 
Less is more when it comes to browser adoption and being able to focus on a reasonable amount of functionality at a time. Beginning with a high-level API that allows developers to do things correctly without trying too hard is a great start. We cannot quash every attack vector here - that is unfortunate.
An API like this will empower people with good, fast browser side crypto. Trying to control what developers do with the decrypted data in the apps they write is asking way too much at this point. (However, I understand the concern you have for people not using these tools properly or using them for fraud or abuse).
For the kind of control you have described above, I think at the very least browsers will have to adopt a new widget for reading sensitive material that might display content, but not allow click events, remote loading of resources and perhaps only allowing 'copy to clipboard'. 
That would be a huge undertaking that will take quite some time and really is a later step in improving browser security capabilities. This is the kind of tool that will be fun to model in an extension and use it in conjunction with a crypto API.

> How much of all of that would be the responsibility of the browser?
> How much of this responsibility can/should the browser pass off to the
> web app? Should we be focused on the browser enforcing a particular
> security model, or should we focus on the browser enabling web apps to
> enforce their own security models?

I think web developers will design some pretty cool apps that create new concepts for the browser to use as a model going forward. This is already the case when it comes to content-accessible crypto APIs in the first place, which is really great. Browser vendors learned a lot from the jQuery project, and I feel the same will be true here.  A "jQuery of client crypto" will emerge and teach us new concepts to move forward with.

We have to start somewhere, and an elegant high-level API is it - for now.

Cheers,

David

Received on Friday, 10 June 2011 20:17:18 UTC