W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

RE: Re: Was: Draft Blog Post on Cryptography API, Now: Potential API recommendation caveats

From: David Rogers <david.rogers@copperhorses.com>
Date: Tue, 9 Oct 2012 21:52:52 +0100
To: "'Ryan Sleevi'" <sleevi@google.com>
Cc: <ddahl@mozilla.com>, <public-webcrypto@w3.org>, <hhalpin@w3.org>
Message-ID: <004501cda660$0f2e3490$2d8a9db0$@copperhorses.com>
Hi Ryan and all,

I think the question comes down to deployment for testing. We have some
known concerns around implementation security and David D mentions that
putting some developer security guidelines in the spec and a couple of
prompts may be sufficient to deal with this. I would argue that we have a
professional duty not to deploy anything that will go into the hands of end
users with so many unknowns. There could be some unintended consequences. We
know from previous work that developers don't read the spec and rarely
follow any security guidelines. Users ignore prompts. I think our combined
experience here should dissuade us from such a path.

The question for us all is therefore, how do we find a balance between not
exposing users to unnecessary risk and plain maliciousness and the
alternative which is not getting enough feedback to make things useful?
Apologies if I'm missing something obvious.



-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: 09 October 2012 21:05
To: David Rogers
Cc: ddahl@mozilla.com; public-webcrypto@w3.org; hhalpin@w3.org
Subject: Re: Re: Was: Draft Blog Post on Cryptography API, Now: Potential
API recommendation caveats

Hi David,

Could you please explain your concerns, so that we can evaluate if and how
they should be addressed?

It remains completely opaque to me how simply adding a cryptographic API
(saying nothing about the key storage) presents a risk to millions of users,
innocent or not.

On Tue, Oct 9, 2012 at 12:34 PM, David Rogers
<david.rogers@copperhorses.com> wrote:
> Hi David,
> I have severe reservations about this and I think you are risking the 
> credibility of this entire community by implementing it in this way, 
> not least by putting millions of innocent users at risk.
> Thanks,
> David.
> Sent from Mobile
> David Dahl <ddahl@mozilla.com> wrote:
> ----- Original Message -----
>> From: "David Rogers" <david.rogers@copperhorses.com>
>> To: ddahl@mozilla.com, sleevi@google.com
>> Cc: public-webcrypto@w3.org, hhalpin@w3.org
>> Sent: Tuesday, October 9, 2012 12:25:23 PM
>> Subject: Re: Was: Draft Blog Post on Cryptography API, Now: Potential 
>> API recommendation caveats
>> Hi David,
>> I haven't been able to keep up with all the discussion, but is this a 
>> serious proposal to deploy an experimental crypto api in a production 
>> build? Apologies if I have missed something, but if people want to 
>> experiment that is fine, but don't do it in a shipped product, it 
>> doesn't make sense and will inevitably lead to security issues?
> Yes, of course, people will still use this API unsafely, however, if 
> the spec has security considerations that warn developers about using 
> this API in content DOM as dangerous and browser vendors raise 
> warnings upon use, and even (as horrible as this sounds) a 
> geolocation-like prompt each time the API is first used per origin,
developers and endusers will be warned.
> I think it should be up to the browser vendor exactly how this is 
> handled - the API may even be preffed off in content DOM, only 
> available to an "Open Webapp" or "SysApp".
> Allowing it to be activated one way or another will still have value 
> for developers working on experiments.
> Cheers,
> David
Received on Tuesday, 9 October 2012 20:53:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 October 2012 20:53:27 GMT