<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
code
{font-family:"Courier New";}
pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:431434514;
mso-list-template-ids:-22931316;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I believe what I’m proposing is an
incremental change to the already-existing data storage API and not and doesn’t
drastically increase the API surface area. Where the encryption key comes from
I think is an interesting question, which is why I didn’t address that. I
think there will be (can be) a variety of places from where a key can
originate. I don’t think it’s necessarily important that a key
originated from a server be passed securely to the client. A lot of web
applications pass tokens back to the client for security purposes right now. As
long as there is a relationship between the signed-in user and the key, you’re
generally covered. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>In any event, I think everyone has agreed
that a JS crypto API would be a good thing, yet no one has stepped forth with a
proposal to move the discussion forward. So here:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<pre><code><font size=2 face="Courier New"><span style='font-size:10.0pt'>[Supplemental, NoInterfaceObject]<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'>interface WindowCrypto {<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'> const unsigned short AES_128 = 1;<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'> const unsigned short AES_192 = 2;<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'> const unsigned short AES_256 = 3;<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p> </o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'> DOMString encrypt(in DOMString valueToEncrypt, in unsigned short cipher, in DOMString key);<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'> DOMString decrypt(in DOMString valueToDecrypt, in unsigned short cipher, in DOMString key);<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'>}<o:p></o:p></span></font></code></pre><pre><code><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Windows implements WindowCrypto<o:p></o:p></span></font></code></pre>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Thoughts?<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>-Nicholas</span></font><font color=navy><span
style='color:navy'><o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'> <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>______________________________________________</span></font><font
color=navy><span style='color:navy'><o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Commander Lock: "Damnit Morpheus, not
everyone believes what you believe!"</span></font><font color=navy><span
style='color:navy'><o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Morpheus: "My beliefs do not require
them to."</span></font><o:p></o:p></p>
</div>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Jeremy Orlow<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, April 08, 2010
7:49 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Paul Kinlan<br>
<b><span style='font-weight:bold'>Cc:</span></b> whatwg@lists.whatwg.org; Dirk
Pranke; <st1:PersonName w:st="on">Nicholas Zakas</st1:PersonName>; Jonas
Sicking; Eric Uhrhane<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [whatwg] Proposal for
secure key-value data stores</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>This is getting fairly tiresome. If you're interested in
continuing this thread, please actually read the replies thus far and directly
respond to the points rather than re-stating what's already been rebutted.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan <<a
href="mailto:paulkinlan@google.com">paulkinlan@google.com</a>> wrote:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Hi,<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I have a specific use-case where encryption is required, and currently
the only solution is to find a JS library that can encrypt the data on the way
in or way out of storage.<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>The main cases I have:<o:p></o:p></span></font></p>
</div>
<div>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Storage needs to be encrypted on disk, device
etc.<o:p></o:p></span></font></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Data needs to be in decrypted form for
the shortest amount of time possible while in use in an application.<o:p></o:p></span></font></li>
</ol>
</div>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>These are not use cases. Can you please describe some specific examples
applications and their requirements for encrypted data? To be honest, I'm
pretty certain you're not going to come up with any that aren't solved by what
you can do today with JS, made better with a JS crypto API, and made easier on
the developer by integrating crypto into the storage APIs. (Though as I
explain below, the last part is pretty much a non-goal.)<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>My gut, general feeling is that encryption of information to and from
storage is moot, because introspection of a running app is so unbelievably easy.
However, on disk storage *must* be encrypted and sandboxed. i.e,
data needs to be only available to the domain running the code, and it cannot
be peaked at by examining the disk.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I have only followed this thread a little while, and as dev who uses JS
a lot, explicitly having to encrypt data is bad and a pain and open to
mistakes.<o:p></o:p></span></font></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Then someone should make a library to do this. Expanding the
surface areas of APIs should not be taken lightly. As I've explained, we
only expand API surface areas when something is impossible to accomplish or
when there are performance reasons. And then we still try to keep things
minimal. Dirk explained well why a generic JS crypto library would solve
more use cases than adding crypto to a particular storage API. I really
don't know why we're still discussing this.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I don't want to be handling encryption of my data, I don't do anything
special to communicate over https, and I look at storage the same way.<o:p></o:p></span></font></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>What's been proposed so far will NOT work as seamlessly as HTTPS.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>If you want it to happen magically, then the UA should encrypt all data
transparently to the user or web developer. I actually think this is
ideal, but the problem is that it's not clear where the key should come from.
After all, if you store it on disk, then you're still at the mercy of the
file system/OS keeping you secure. If you store it remotely (as has been
mentioned in this thread) then we need to come up with an API to pass that key
in or we need to somehow add the key to HTTPS connections.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Maybe what we should really be doing is looking at adding a HTML
attribute, HTTP header, or something like that that gives the browser a private
key to be used to encrypt _everything_ associated with the web page.
Including history, any storage APIs, etc. I suppose the file API
would need some way to opt-out (per what Jonas pointed out).<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>In summary, this is something I expect of the UA and not any specific
JS API.<o:p></o:p></span></font></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Although ease of use of JS APIs is great and should be a goal, it is
not the primary goal by any stretch of the imagination. Keeping API
surface area down is much more important.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<div>
<div>
<div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow <<a
href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>>
wrote:<o:p></o:p></span></font></p>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking <jonas@sicking.cc>
wrote:<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow <<a
href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>>
wrote:<br>
>> I don't think this is enough of a<br>
>> problem to kill the feature though.<br>
><br>
> I think this is a good feature to try and integrate into existing APIs if<br>
> it's possible to do so cleanly. I don't think it's worth creating
yet<br>
> another persistent storage API over, though.<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>...<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>> For<br>
> localStorage, we could add a origin-wide setting or add an optional param
to<br>
> setItem.<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Well, it seems harsh to require that *all* data on a domain is either<br>
security sensitive, and thus need expiration, or not security<br>
sensitive and thus need none. I think it makes a lot of sense to be<br>
able to let the page have several storage areas, some which expire and<br>
some which don't.<br>
<br>
Think <a href="http://mail.google.com" target="_blank">mail.google.com</a>
where storing my emails would count as sensitive<br>
and should have expiration, but storing my drafts might be worth doing<br>
longer to prevent dataloss.<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Local storage is not a good API for more complex applications like
gmail. That's why I suggested integrating into IndexedDB and
WebSQLDatabase (which is what I meant when I said "databases").
Note that I also suggested that it could be an optional parameter to
setItem which would make it a per-item setting and still be backwards
compatible with LocalStorage. (Like I said, creating another
LocalStorage-like API just for this feature is really not an option.)<o:p></o:p></span></font></p>
</div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I just thought of an alternative approach to this whole situation<br>
though. We could add crypto and expiration functionality to IndexDB. I<br>
know the crypto stuff has come up before and there was some hesitation<br>
though. (Though I guess the same thing could be said for<br>
crypto+localStorage)<o:p></o:p></span></font></p>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Nikunj has already said no more major features for v1 of IndexedDB.
I think we might be able to sneak in an expiration parameter, but
encryption 1) is not practical for v1 and 2) we're really jumping the gun
on this encryption thing. One person proposed it. We haven't seen
any evidence this is a widely sought after feature. If _anything_ the
right way to go is to make encryption fast and allow developers and authors of
libraries to layer the two. If there's compelling demand, THEN we should
talk about adding it to individual APIs.<o:p></o:p></span></font></p>
</div>
<div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>> It seems as though
expiration policies could be added to the creation of<br>
> databases and the new FileWriter/FileSystem APIs pretty easily.<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I don't understand the usecase of expiring files. Isn't the whole<br>
point of saving to the file system so that the user gets better access<br>
to it and so that things like iPhoto can index any stored images?<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><br>
> But still....we need some use cases. :-)<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I'm all for use cases. Though Nicholas did say that he'd want<br>
encryption and expiration on essentially all privacy sensitive<br>
information stored. Which I think I can understand.<o:p></o:p></span></font></p>
</blockquote>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>As stated, a more general purpose crypto API should be enough
to satisfy this use case and others (like someone wanting to encrypt it client
side before sending it to the server). That is the direction these
discussions should be headed, not taking one particular persistent storage
API and finding a way to tack encryption onto it.<o:p></o:p></span></font></p>
</div>
</div>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>