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

On Tue, Oct 9, 2012 at 1:35 PM, David Dahl <ddahl@mozilla.com> wrote:
> Perhaps I should not use "SysApps" in this context, but rather a cryptographically signed "Open WebApp" which is delivered to the browser via a "trusted" AppStore. Extensions can also be signed and verified.
>
> Firefox OS (and Firefox itself) will have signed zipfile-based "webapps" that are installed locally, the signature verified, the apps' cache is its own along with cookies and web storage. This environment is more a "trustworthy" one in which to allow the use of a Web Crypto API.
>
> The concerns I have are the same old story, malleable DOM, XSS, application script changes that can happen between reloads of the page, etc. An Open Web App will be much more static and the source verifiable.
>
> Cheers,
>
> David

It sounds like your solution offers nothing more than a signature on
the (initial) code, which is the same as offered by a number of
existing extension mechanisms (eg: Both Firefox and Chromium)

Again, you make reference to a more "trustworthy" environment, but
it's unclear what your concerns are that you feel are mitigated here.
An extension/Open Web App/SysApp that say, calls eval on the result of
an XHR over HTTP, is just as likely to get owned as a web page.

While I appreciate the security concern, I feel like there's some
handwaving here that it's better, and I'm trying to understand the
concrete concerns here. Is it just that the (initial) code is signed
(since it can always change later)? That the user explicitly installed
the extension (which seems wholly unrelated to malleability or any of
the other security concerns raised)

What I'm trying to tease out here is what security properties are
*unique* to what you're proposing that are not already available to
the web platform, AND why you feel those security properties are
essential to the API.

To put it differently, if the API required CSP and an HTTPS origin,
what concerns do you have that fundamentally non-applicable to your
Extension/"Open Web App" scenario?

>
> ----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: "David Rogers" <david.rogers@copperhorses.com>, public-webcrypto@w3.org, hhalpin@w3.org
> Sent: Tuesday, October 9, 2012 3:18:40 PM
> Subject: Re: Was: Draft Blog Post on Cryptography API, Now: Potential API recommendation caveats
>
> David (Dahl),
>
> Could you please explain what security properties you see as being
> available to SysApps/Extensions that are not available to generic web
> applications?
>
> Extensions can just as well be compromised via things like XSS, as has
> been demonstrated by a number of novel attacks. For reasons like this,
> Chrom[e/ium] has started to require Content-Security-Policy for
> extensions, and supplying a default one.
>
> At this time, the security model of SysApps has not been discussed in
> the W3C. So your statements that SysApps improve security is without
> empirical evidence. I'd like to understand how "SSL only + CSP"
> fundamentally differs from SysApps, and what concerns with the API you
> think are addressed.
>
> On Tue, Oct 9, 2012 at 1:14 PM, David Dahl <ddahl@mozilla.com> wrote:
>> Wow. I am actually talking about preffing *off* the Web Crypto API and adding hindrances for use in the content DOM of web browsers and now you are concerned about the well being of millions of users? Perhaps you have not read the whole thread? You do understand that I think that this API should not be used in production web applications, only in more trusted environments like Open WebApps or extensions?
>>
>>
>> ----- Original Message -----
>> From: "David Rogers" <david.rogers@copperhorses.com>
>> To: ddahl@mozilla.com
>> Cc: public-webcrypto@w3.org, hhalpin@w3.org, sleevi@google.com
>> Sent: Tuesday, October 9, 2012 2:34:19 PM
>> Subject: Re: Was: Draft Blog Post on Cryptography API, Now: Potential API
>>     recommendation caveats
>>
>> 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 MobileDavid 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:41:50 UTC