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: Ryan Sleevi <sleevi@google.com>
Date: Tue, 9 Oct 2012 14:02:05 -0700
Message-ID: <CACvaWvYWkfEkfSt8WLtcLLj=nGkdxSWafHCZ6Rr5W2WTiSM54Q@mail.gmail.com>
To: David Rogers <david.rogers@copperhorses.com>
Cc: ddahl@mozilla.com, public-webcrypto@w3.org, hhalpin@w3.org
On Tue, Oct 9, 2012 at 1:52 PM, David Rogers
<david.rogers@copperhorses.com> wrote:
> 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.

Apologies, but I fail to see how this represents an actionable concern.

What risks - unintended or malicious - exists from allowing access to
a per-origin, in-memory key store? How are these risks any different
than cookies?

If you had concrete concerns - eg: "If this shares the same RNG with
the system, there could be entropy depletion" - then that's absolutely
something that can be evaluated and discussed. However, your concerns
simply seem to be (respectfully) "I'm not sure I understand it, so I
don't trust it", which does not provide any assistance for this WG to
evaluate.

If the concern is "People can write insecure software," then
respectfully, I have to suggest that's an explicit non-goal of this
WG. People can write insecure software without any use of this API,
and while cryptography certainly has an element of presumed security
"magic", I firmly believe it does not make it any easier or harder to
write bad code.

It seems that you're opposed to this API entirely, and without
concerns that we can respond to, which makes it very hard to
appreciate and understand your position.

>
> Thanks,
>
>
> David.
>
> -----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 21:02:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 October 2012 21:02:33 GMT