- From: David Dahl <ddahl@mozilla.com>
- Date: Fri, 10 Jun 2011 12:24:34 -0700 (PDT)
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: Nico Williams <nico@cryptonector.com>, public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>
----- Original Message ----- > From: "Anders Rundgren" <anders.rundgren@telia.com> > To: "David Dahl" <ddahl@mozilla.com> > Cc: "Nico Williams" <nico@cryptonector.com>, public-web-security@w3.org, "Jarred Nicholls" <jarred@sencha.com> > Sent: Friday, June 10, 2011 1:17:21 PM > Subject: Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal > On 2011-06-09 23:17, David Dahl wrote: > <snip> > > > The client does all crypto operations and the server is only given > > cipher text to store > > IMHO, this is a rather odd value proposition: > The server is supposed > to provide JS-code for the client to encrypt data so that the server > can't > see it. Yes, cloud-storage services do this but they provide a lot > more than just a crypto API. > On the contrary. The point is that the crypto is performed by your browser on the local machine - not by minimized server script or closed client apps of dubious value. Also, developers can write apps that use third-party APIs and services, but the plain text beomes cipher text, with the 3rd party having zero knowledge of the conversation, which is a main point of this API. Conversation, in general, has moved from email to web. In which case, a third-party always has a copy of your conversation. > > - and, yes, key management is still a problem, > > which I know is a huge problem that will have a solution at some > > point. > > The S/MIME people haven't got this ball running in 15 years so there's > not a surefire victory in sight :-( I think this is now a job for web engineers to figure out an elegant set of solutions. It will take time, but I also think the time is right, the emphasis and interest in privacy and user control is only going to grow. Not to mention that web developers want "webby" tools to work with, not complicated systems whose docs make your eyes bleed. All of this can be simplified. > I'm sure we will get a JS-API, primarily because it is simple to > implement and will have a very limited impact on browser "footprint". > When it comes to *usage* I remain a bit skeptical. That's ok, I happen to think that this kind of API has a huge number of consumers just waiting to get their hands on it. Regards, David
Received on Friday, 10 June 2011 19:25:03 UTC