W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25721] extractable keys should be disabled by default

From: <bugzilla@jessica.w3.org>
Date: Fri, 16 May 2014 22:25:39 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25721-7213-BKD80BNcw3@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

--- Comment #10 from Ryan Sleevi <sleevi@google.com> ---
(In reply to elijah from comment #8)
> > Codesigning can be implemented (with weak CSP). However, code signing as a 
> > first class is explicitly NOT part of our charter. That remains the realm of
> > WebAppSec.
> > ... Look, it remains quite simple: You either trust the source of the code you
> >  are running, or you do not.
> 
> The point is that entirely trusting the code is not necessarily the the only
> way js apps will be run in the future, but WebCrypto API should not
> undermine this now.

Yes, it is. It's part of the way Javascript works.

When you change Javascript, then we can revisit this.

> 
> > If you do not trust it, they can lie to you a million different ways, or access
> > your plaintext a million different ways.
> 
> Again, this argument ignores (a) the important of past and future data, (b)
> that ciphertext <> plaintext is only one of many possible cryptographic
> functions, (c) the threats are not just in the browser (cloud service get
> hacked all the time) and I shouldn't be forced to give origin my keys.
> 
> > Please read http://tonyarcieri.com/whats-wrong-with-webcrypto to understand
> > why the security model being argued for here is entirely broken.
> 
> Yep, WebCrypto is not going to make web crypto that much better, but always
> allowing extractable keys only makes it worse.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 16 May 2014 22:25:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC