Re: [whatwg] Proposal for secure key-value data stores

[Mikko Rantalainen]

2010-12-01 21:43 EEST: Aryeh Gregor:
 On Tue, Nov 30, 2010 at 6:15 PM, Ian Hickson i...@hixie.ch wrote:
 It cannot, and should not. It's a user concern. If as a user I want all
 data that you send me to be printed unencrypted and dropped out of my
 office window for anyone to read, then I should be allowed to do that. :-)
 
 It's legitimate for an organization to require people to handle data
 in a certain way if they want web access to it.  For instance, a
 company could reasonably require that if users want to work from home,
 they have to obey certain security practices to avoid leaking private
 data -- e.g., information about the company's clients or users that
 might be protected by privacy laws or company privacy policies. [...]

If a company or any other entity deals with data that must not be
leaked, they definitely should not allow any random (home or other)
workstation to access the data. Either the user using the workstation is
able to decide by himself that the workstation is secure enough or the
user cannot use the workstation for secure stuff at all.

Even, if we had a hypothetical secure workstation that is based on
signed binary executed by BIOS (or some other firmware boot method) and
only that binary will only execute other signed binaries, the
workstation cannot be guaranteed to be safe. If the user cannot inspect
that the hardware has not been temped with, there's no way to make sure
that the environment is safe. (There could be an extra hardware
component that makes the hardware unsafe - for example, a hardware
keylogger inserted between keyboard and keyboard connector, extra
hardware soldered on the motherboard that interferes with the memory bus
to hack the hardware or something more obscure. See Xbox 360 hacking for
an example.) In addition to these major issues, there's still the
minor(?) issue of bugs in the software. See security vulnerabilities in
software for examples.

In the end, my point is that there's absolutely nothing an UA could do
to verify that the environment is safe. If somebody claims to do
anything else, beware, he's trying to sell you some snake oil.

-- 
Mikko



signature.asc
Description: OpenPGP digital signature

Re: [whatwg] Proposal for secure key-value data stores

[Aryeh Gregor]

On Tue, Nov 30, 2010 at 6:15 PM, Ian Hickson i...@hixie.ch wrote:
 It cannot, and should not. It's a user concern. If as a user I want all
 data that you send me to be printed unencrypted and dropped out of my
 office window for anyone to read, then I should be allowed to do that. :-)

It's legitimate for an organization to require people to handle data
in a certain way if they want web access to it.  For instance, a
company could reasonably require that if users want to work from home,
they have to obey certain security practices to avoid leaking private
data -- e.g., information about the company's clients or users that
might be protected by privacy laws or company privacy policies.  This
might include using full-disk encryption to prevent physical theft, as
well as other measures.

However, as with DRM, I don't think such requirements can be checked
in a standard way.  If it's openly specified, users can evade it
easily -- it only takes one person to write a browser extension to
disable the check for everyone's workplace.  Barring a
down-to-the-metal chain of trust, you can never avoid this completely,
but it's a lot harder to break an obfuscated company-specific binary
blob than something standardized.  So I think non-standard programs
(plus perhaps physical inspection) will remain the only way to even
attempt this kind of checking.

Re: [whatwg] Proposal for secure key-value data stores

[Ian Hickson]

On Tue, 17 Aug 2010, Evan Ireland wrote:

 I might wish to build an offline web application which will refuse to 
 operate if the browser cannot guarantee that the database is encrypted.
 Now full-disk encryption would be fine (if the O/S has a power-on 
 password), but how can my web application author detect (using a JS API) 
 if any data stored in a browser's database is in fact encrypted (or 
 not)?

It cannot, and should not. It's a user concern. If as a user I want all 
data that you send me to be printed unencrypted and dropped out of my 
office window for anyone to read, then I should be allowed to do that. :-)


 Such uncertainty might force us (as a vendor) to have to develop 
 platform/browser-specific plugins to providew an alternative 
 implemantation of the database API so we can be confident that database 
 storage is secure.

Secure from what?


On Tue, 17 Aug 2010, Dirk Pranke wrote:
 
 I continue to think that the best approach to start with would be to 
 implement a library in JS that did crypto on top of the Platform APIs 
 (and having a native crypto API would be nice as well), and if it turned 
 out to be useful we could roll it into the platform.

That is generally the best way forward for any feature, indeed.


On Sun, 22 Aug 2010, Brian Campbell wrote:
 
 Note that there are several different types of attack you might want to 
 defend against. While it's true that there's no real defense against 
 someone taking physical control of the machine, installing a keylogger, 
 putting the machine back in the users control, and then either uploading 
 the data somewhere or retrieving the data physically at a later time, 
 that attack works against almost all security mechanisms in the web 
 platform (password authentication, HTTPS, cookies, etc). That is a very 
 expensive type of attack, with a high risk of discovery (several 
 opportunities for physical discovery, and the keylogger may be 
 discovered too).

It's probably the most wide-spread attack in the real world.


 There are several attacks that are much cheaper and easier which 
 encryption of data on disk can prevent. I think one of the biggest risks 
 is simply the discarded hard drives. While most places which deal in 
 sensitive data require that hard drives are erased or destroyed before 
 being disposed of, in practice, that's something that's very easy to 
 overlook when discarding an old computer. There is considerable risk of 
 someone just doing dumpster diving being able to recover sensitive data, 
 which can be prevented (with no risk of the password being sniffed) by 
 just encrypting all potentially sensitive data before writing it to the 
 disk.

In practice, people having their data read from their discarded disks is 
far less of a problem than people getting malware installed on their 
active systems.

Also, unless the data is encrypted behind a password prompt and the 
password is very secure, encryption isn't particularly helpful. I think 
it's optimistic to hope that browsers will ask all users to enter a secure 
passphrase before being able to use local storage.


 The stolen laptop attack is similar; encryption will prevent sensitive 
 data from being leaked, and stealing a laptop is a lot easier than 
 stealing a laptop, installing a keylogger, returning it unnoticed, and 
 then collecting the data from the keylogger unnoticed.

Stolen (or lost) laptops are a common problem (though nothing on the scale 
of malware/keylogger attacks), but that problem is solved by disk-wide 
encryption with a secure system-wide passphrase, not by a password for 
local storage. The former, assuming the laptop is stolen while turned off 
rather than suspended, is a pretty good defence. The latter is almost 
certainly a worthless defence since the data or key are likely to be found 
elsewhere in the system (e.g. in the pagefile).


 So, there are real security benefits to ensuring that sensitive data is 
 stored encrypted. One way to do this is to require the platform to 
 encrypt the data, either the browser itself or the browser ensuring that 
 the operating system has some sort of full-disk encryption. The web app 
 could then require the browser report that data will be encrypted before 
 sending the data down. The problem with this is that browsers may lie, 
 or be mistaken about full-disk encryption. Microsoft Exchange has a flag 
 that notifies the server whether data is stored encrypted, and some 
 companies have policies of not allowing clients that don't support 
 encryption. Of course, this means that several clients just lie, 
 claiming to encrypt the data while not actually doing so (I believe the 
 initial version of the iPhone Exchange client did this, though my memory 
 may be hazy).

Indeed.


 Anyhow, I think most of the reasonable ideas have been suggested in this 
 thread (allow the browser to report whether data will be stored 
 encrypted, provide a JS crypto API to allow web apps to more easily 
 encrypt 

Re: [whatwg] Proposal for secure key-value data stores

[Brian Campbell]

On Aug 16, 2010, at 6:58 PM, Ian Hickson wrote:

 On Tue, 30 Mar 2010, Nicholas Zakas wrote:
 
 In attempting to use localStorage at work, we ran into some major 
 security issues. Primary among those are the guidelines we have in place 
 regarding personalized user data. The short story is that personalized 
 data cannot be stored on disk unless it's encrypted using a 
 company-validated encryption mechanism and key. So if we actually wanted 
 to use localStorage, we'd be forced to encrypt each value as it was 
 being written and then decrypt each value being read. Because of this 
 tediousness, we opted not to use it.
 
 Doing that wouldn't actually help, either, since anyone attacking the user 
 could simply intercept the key and then decrypt it all offline. (In this 
 scenario, I'm assuming the attack being defeated is that of an attacker 
 obtaining the data, and I'm assuming that the attacker has physical access 
 to the computer, since otherwise the Web's security model would be 
 sufficient to block the attack, and that the computer is logged in, since 
 otherwise whole-disk encryption would be sufficient to block this attack.)

Note that there are several different types of attack you might want to defend 
against. While it's true that there's no real defense against someone taking 
physical control of the machine, installing a keylogger, putting the machine 
back in the users control, and then either uploading the data somewhere or 
retrieving the data physically at a later time, that attack works against 
almost all security mechanisms in the web platform (password authentication, 
HTTPS, cookies, etc). That is a very expensive type of attack, with a high risk 
of discovery (several opportunities for physical discovery, and the keylogger 
may be discovered too).

There are several attacks that are much cheaper and easier which encryption of 
data on disk can prevent. I think one of the biggest risks is simply the 
discarded hard drives. While most places which deal in sensitive data require 
that hard drives are erased or destroyed before being disposed of, in practice, 
that's something that's very easy to overlook when discarding an old computer. 
There is considerable risk of someone just doing dumpster diving being able to 
recover sensitive data, which can be prevented (with no risk of the password 
being sniffed) by just encrypting all potentially sensitive data before writing 
it to the disk.

The stolen laptop attack is similar; encryption will prevent sensitive data 
from being leaked, and stealing a laptop is a lot easier than stealing a 
laptop, installing a keylogger, returning it unnoticed, and then collecting the 
data from the keylogger unnoticed.

So, there are real security benefits to ensuring that sensitive data is stored 
encrypted. One way to do this is to require the platform to encrypt the data, 
either the browser itself or the browser ensuring that the operating system has 
some sort of full-disk encryption. The web app could then require the browser 
report that data will be encrypted before sending the data down. The problem 
with this is that browsers may lie, or be mistaken about full-disk encryption. 
Microsoft Exchange has a flag that notifies the server whether data is stored 
encrypted, and some companies have policies of not allowing clients that don't 
support encryption. Of course, this means that several clients just lie, 
claiming to encrypt the data while not actually doing so (I believe the initial 
version of the iPhone Exchange client did this, though my memory may be hazy).

Anyhow, I think most of the reasonable ideas have been suggested in this thread 
(allow the browser to report whether data will be stored encrypted, provide a 
JS crypto API to allow web apps to more easily encrypt and decrypt data 
piecemeal on the client side). The one thing I'd add is that if you really want 
to make sure that private data will be encrypted, it's probably best not to 
allow users to have access to that data unless they are known (by some out of 
band means, such as IT department policy and limiting access to the data to 
certain machines) to be on managed machines that have full-disk encryption, or 
that they have read and agreed to a policy that states that they must use 
full-disk encryption. This way, it's the user or the IT department's 
responsibility to ensure that the disk is encrypted securely, not the browser 
vendor which may or may not know.


-- Brian

Re: [whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

On Tue, Aug 17, 2010 at 4:00 AM, Jeremy Orlow jor...@chromium.org wrote:
 On Tue, Aug 17, 2010 at 12:31 AM, Dirk Pranke dpra...@chromium.org wrote:

 On Mon, Aug 16, 2010 at 3:58 PM, Ian Hickson i...@hixie.ch wrote:
  On Tue, 30 Mar 2010, Dirk Pranke wrote:
 
  Nicholas is almost certainly discussing the case where the service
  provider requires any data stored on a customer's computer to be
  encrypted, not the provider's own computers. (e.g., this could be a
  Yahoo! policy that data stored on Yahoo! users' computers must be
  encrypted).
 
  Hence they cannot enforce anything like use FileVault.
 
  If you can't enforce whole disk encryption, but you are concerned that
  an
  attacker could have access to your machine, it seems that there is no
  solution, since an attacker could just install a rootkit and then carry
  out arbitrary attacks remotely, including simply replacing the browser
  with one that intercepts all the user's data as it is written.
 

 While it is true that it would not defend against all attacks, it will
 still defend against some classes of attacks (e.g. casual snooping),
 and may still be valuable.

 Adding API surface area to defend against casual snooping seems a
 bit ridiculous/overkill to me.  Especially when web apps can do this in JS
 today if they really wish.

I was not intending to suggest that it was a reason for adding an API,
simply to point out that not being able to defend against a rootkit is
not a good reason *not* to do it. Especially since full disk
encryption won't save you if you've been rooted, either :)

I continue to think that the best approach to start with would be to
implement a library in JS that did crypto on top of the Platform APIs
(and having a native crypto API would be nice as well), and if it
turned out to be useful we could roll it into the platform.

-- Dirk

[whatwg] Proposal for secure key-value data stores

[Ian Hickson]

On Tue, 30 Mar 2010, Nicholas Zakas wrote:
 
 In attempting to use localStorage at work, we ran into some major 
 security issues. Primary among those are the guidelines we have in place 
 regarding personalized user data. The short story is that personalized 
 data cannot be stored on disk unless it's encrypted using a 
 company-validated encryption mechanism and key. So if we actually wanted 
 to use localStorage, we'd be forced to encrypt each value as it was 
 being written and then decrypt each value being read. Because of this 
 tediousness, we opted not to use it.

Doing that wouldn't actually help, either, since anyone attacking the user 
could simply intercept the key and then decrypt it all offline. (In this 
scenario, I'm assuming the attack being defeated is that of an attacker 
obtaining the data, and I'm assuming that the attacker has physical access 
to the computer, since otherwise the Web's security model would be 
sufficient to block the attack, and that the computer is logged in, since 
otherwise whole-disk encryption would be sufficient to block this attack.)


 Another major issue also relates to the persistence of the data in 
 localStorage. Whereas cookies allow you to specify a time at which the 
 data will be removed, localStorage is there more or less forever.

Right, it's there for as long as the data that would be saved by the user 
if the user viewed your page and chose File  Save As -- that is, until 
the user deletes it. (Or until he visits your page again and your page 
deletes it.)


 It seems like any company that takes the security of its data seriously 
 would run into the same issues, and rather than forcing every company to 
 implement their own version of the same approach, a common native 
 approach would be incredibly useful.

Why isn't whole-disk encryption sufficient? It seems like if the user is 
concerned about his disk being stolen, he'd be concerned about all data on 
the disk, including his HTTP cache, his cookies, his saved usernames and 
passwords, etc, not just the data in the Web page's localStorage area.


On Tue, 30 Mar 2010, Dirk Pranke wrote:

 Nicholas is almost certainly discussing the case where the service 
 provider requires any data stored on a customer's computer to be 
 encrypted, not the provider's own computers. (e.g., this could be a 
 Yahoo! policy that data stored on Yahoo! users' computers must be 
 encrypted).
 
 Hence they cannot enforce anything like use FileVault.

If you can't enforce whole disk encryption, but you are concerned that an 
attacker could have access to your machine, it seems that there is no 
solution, since an attacker could just install a rootkit and then carry 
out arbitrary attacks remotely, including simply replacing the browser 
with one that intercepts all the user's data as it is written.


On Tue, 30 Mar 2010, Dirk Pranke wrote:
 
 Perhaps we should instead focus on a set of JS Crypto APIs, since that
 is largely orthogonal to the storage APIs?

That would make more sense, I think. It would be useful in other scenarios 
too (such as replacing keygen). I would encourage people interested in 
such an approach to get vendors together and write a spec.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal for secure key-value data stores

[Evan Ireland]

One of our key concerns is with Web SQL Database API (which we prefer) or
Indexed Database API.

I might wish to build an offline web application which will refuse to
operate if the browser cannot guarantee that the database is encrypted. Now
full-disk encryption would be fine (if the O/S has a power-on password), but
how can my web application author detect (using a JS API) if any data stored
in a browser's database is in fact encrypted (or not)?

Such uncertainty might force us (as a vendor) to have to develop
platform/browser-specific plugins to providew an alternative implemantation
of the database API so we can be confident that database storage is secure.

 -Original Message-
 From: Ian Hickson [mailto:i...@hixie.ch] 
 Sent: Tuesday, 17 August 2010 10:58 a.m.
 To: whatwg@lists.whatwg.org
 Subject: [whatwg] Proposal for secure key-value data stores
 
 On Tue, 30 Mar 2010, Nicholas Zakas wrote:
  
  In attempting to use localStorage at work, we ran into some major 
  security issues. Primary among those are the guidelines we 
 have in place 
  regarding personalized user data. The short story is that 
 personalized 
  data cannot be stored on disk unless it's encrypted using a 
  company-validated encryption mechanism and key. So if we 
 actually wanted 
  to use localStorage, we'd be forced to encrypt each value as it was 
  being written and then decrypt each value being read. 
 Because of this 
  tediousness, we opted not to use it.
 
 Doing that wouldn't actually help, either, since anyone 
 attacking the user 
 could simply intercept the key and then decrypt it all 
 offline. (In this 
 scenario, I'm assuming the attack being defeated is that of 
 an attacker 
 obtaining the data, and I'm assuming that the attacker has 
 physical access 
 to the computer, since otherwise the Web's security model would be 
 sufficient to block the attack, and that the computer is 
 logged in, since 
 otherwise whole-disk encryption would be sufficient to block 
 this attack.)
 
 
  Another major issue also relates to the persistence of the data in 
  localStorage. Whereas cookies allow you to specify a time 
 at which the 
  data will be removed, localStorage is there more or less forever.
 
 Right, it's there for as long as the data that would be saved 
 by the user 
 if the user viewed your page and chose File  Save As -- 
 that is, until 
 the user deletes it. (Or until he visits your page again and 
 your page 
 deletes it.)
 
 
  It seems like any company that takes the security of its 
 data seriously 
  would run into the same issues, and rather than forcing 
 every company to 
  implement their own version of the same approach, a common native 
  approach would be incredibly useful.
 
 Why isn't whole-disk encryption sufficient? It seems like if 
 the user is 
 concerned about his disk being stolen, he'd be concerned 
 about all data on 
 the disk, including his HTTP cache, his cookies, his saved 
 usernames and 
 passwords, etc, not just the data in the Web page's localStorage area.
 
 
 On Tue, 30 Mar 2010, Dirk Pranke wrote:
 
  Nicholas is almost certainly discussing the case where the service 
  provider requires any data stored on a customer's computer to be 
  encrypted, not the provider's own computers. (e.g., this could be a 
  Yahoo! policy that data stored on Yahoo! users' computers must be 
  encrypted).
  
  Hence they cannot enforce anything like use FileVault.
 
 If you can't enforce whole disk encryption, but you are 
 concerned that an 
 attacker could have access to your machine, it seems that there is no 
 solution, since an attacker could just install a rootkit and 
 then carry 
 out arbitrary attacks remotely, including simply replacing 
 the browser 
 with one that intercepts all the user's data as it is written.
 
 
 On Tue, 30 Mar 2010, Dirk Pranke wrote:
  
  Perhaps we should instead focus on a set of JS Crypto APIs, 
 since that
  is largely orthogonal to the storage APIs?
 
 That would make more sense, I think. It would be useful in 
 other scenarios 
 too (such as replacing keygen). I would encourage people 
 interested in 
 such an approach to get vendors together and write a spec.
 
 -- 
 Ian Hickson   U+1047E
 )\._.,--,'``.fL
 http://ln.hixie.ch/   U+263A/,   _.. \   
 _\  ;`._ ,.
 Things that are impossible just take longer.   
 `._.-(,_..'--(,_..'`-.;.'
 

Re: [whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

On Mon, Aug 16, 2010 at 3:58 PM, Ian Hickson i...@hixie.ch wrote:
 On Tue, 30 Mar 2010, Dirk Pranke wrote:

 Nicholas is almost certainly discussing the case where the service
 provider requires any data stored on a customer's computer to be
 encrypted, not the provider's own computers. (e.g., this could be a
 Yahoo! policy that data stored on Yahoo! users' computers must be
 encrypted).

 Hence they cannot enforce anything like use FileVault.

 If you can't enforce whole disk encryption, but you are concerned that an
 attacker could have access to your machine, it seems that there is no
 solution, since an attacker could just install a rootkit and then carry
 out arbitrary attacks remotely, including simply replacing the browser
 with one that intercepts all the user's data as it is written.


While it is true that it would not defend against all attacks, it will
still defend against some classes of attacks (e.g. casual snooping),
and may still be valuable.

-- Dirk


 On Tue, 30 Mar 2010, Dirk Pranke wrote:

 Perhaps we should instead focus on a set of JS Crypto APIs, since that
 is largely orthogonal to the storage APIs?

 That would make more sense, I think. It would be useful in other scenarios
 too (such as replacing keygen). I would encourage people interested in
 such an approach to get vendors together and write a spec.

 --
 Ian Hickson               U+1047E                )\._.,--,'``.    fL
 http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal for secure key-value data stores

[Ian Hickson]

On Tue, 6 Apr 2010, Jeremy Orlow wrote:
 On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas wrote:
  
  It would be really nice if, in addition to having access to crypto 
  functions, there was an area where I could stick data that would get 
  encrypted automatically (and of course, where I could be sure the data 
  would be eliminated after a set amount of time).
 
 It seems to me that Dirk is right that crypto in the browser is a more 
 general problem and that a general crypto API would be much more 
 valuable than creating new APIs with similar/duplicate functionality + 
 crypto.

I encourage anyone who would like a general crypto API to write one.


On Wed, 7 Apr 2010, Nicholas Zakas wrote:

 I've actually already seen a very common repeated pattern as it comes to 
 client-side data storage:
 
 1. Hey let's try using localStorage to improve our user experience.

 2. Sounds great, but the data can't be stored in plain text if its user 
 data.

Why not?

If you trust the client, then it's safe (by definition). If you don't, 
then you've pretty much lost anyway (the client could just intercept all 
communication as it happens).

If you're worried about cached data falling into the wrong hands but can 
guarantee that:

 - the client is secure until it falls into the wrong hands

 - the client will have expired data securely before it falls into the 
   wrong hands

 - the client has no stored passwords

 - the client leaves no compromising data in RAM or in temporary 
   locations (e.g. the swapfile) on disk.

...then encrypting the data with a server-provided key in JS seems 
reasonable, but is this really a situation that we can seriously expect to 
happen?


 Again I'll say I'm all for adding crypto into JavaScript. I think in 
 addition to that, there should be affordances for what will likely be 
 common usage patterns. To me, any and all mechanisms for client-side 
 storage should have some basic crypto built-in, so why not start here?

It's not clear to me what problem it solves. In most cases, it would not 
increase security at all.


 In regards to data expiration, part of ensuring the security of data is 
 knowing how long it will be stored on disk. If I let someone borrow my 
 computer to check their email, and the email client happens to save some 
 data onto the client, then that person's data will now be on my disk for 
 who knows how long. That represents a data security issue.

For them or for you? For them, if they don't trust you, then they 
shouldn't be relying on your computer in the first place. You could just 
save their password, or their session cookie, or be logging all network 
traffic and TLS keys as they're generated (and thus be able to read any of 
the e-mails they saw even if they aren't stored locally), etc.


 By allowing an expiration date to be tied to the data, you can have 
 reasonable assurance that the data isn't just going to be sitting around 
 waiting for someone to try and use it.

We could add per-key metadata to localStorage relatively easily (basically 
by having a parallel API that returns an object with the metadata instead 
of the value). I recommend we wait until more of the new features are 
implemented before adding more new features, though... we don't even have 
a test suite for localStorage yet!

Having said that, it's not clear to me that expiry dates are especially 
compelling, even from a security standpoint.


On Wed, 7 Apr 2010, Jonas Sicking wrote:
 
 Think mail.google.com where storing my emails would count as sensitive 
 and should have expiration, but storing my drafts might be worth doing 
 longer to prevent dataloss.

If you're worried about data loss to that extent, I'd recommend whole disk 
encryption and never suspending your laptop. Expiry dates aren't going to 
save you much, especially for something like e-mail since you're 
presumably going to always be using the mail client.


On Thu, 8 Apr 2010, Paul Kinlan wrote:
 
 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.

What is the use case? Why is a JS library insufficent?


 The main cases I have:
 
1. Storage needs to be encrypted on disk, device etc.
2. Data needs to be in decrypted form for the shortest amount of time
possible while in use in an application.
 
 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.

If it's made available to any page running on that domain, that means it's 
available to any code on the machine, since the browser has to do the 
decryption and isn't from the domain. So that doesn't seem safe.

You'd need at a minimum to have the 

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

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.   

 

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:

 

[Supplemental, NoInterfaceObject]
interface WindowCrypto {
const unsigned short AES_128 = 1;
const unsigned short AES_192 = 2;
const unsigned short AES_256 = 3;
 
DOMString encrypt(in DOMString valueToEncrypt, in unsigned short
cipher, in DOMString key);
DOMString decrypt(in DOMString valueToDecrypt, in unsigned short
cipher, in DOMString key);
}
Windows implements WindowCrypto

 

Thoughts?

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 7:49 AM
To: Paul Kinlan
Cc: whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Jonas Sicking;
Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

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.

 

 

On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan paulkin...@google.com
wrote:

Hi,

 

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.

 

The main cases I have:

1.  Storage needs to be encrypted on disk, device etc.
2.  Data needs to be in decrypted form for the shortest amount of
time possible while in use in an application.

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.)

 

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.

 

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.

 

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.

 

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.

 

What's been proposed so far will NOT work as seamlessly as HTTPS.

 

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.

 

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

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I tried to articulate some of my thoughts as to why a generate purpose
crypto isn't enough to be useful and why trying to tack onto local
storage could get messy:

http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side
-data-storage/

 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 3:14 AM
To: Jonas Sicking
Cc: whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org
wrote:
 I don't think this is enough of a
 problem to kill the feature though.

 I think this is a good feature to try and integrate into existing APIs
if
 it's possible to do so cleanly.  I don't think it's worth creating yet
 another persistent storage API over, though.

...

 For
 localStorage, we could add a origin-wide setting or add an optional
param to
 setItem.

Well, it seems harsh to require that *all* data on a domain is either
security sensitive, and thus need expiration, or not security
sensitive and thus need none. I think it makes a lot of sense to be
able to let the page have several storage areas, some which expire and
some which don't.

Think mail.google.com where storing my emails would count as sensitive
and should have expiration, but storing my drafts might be worth doing
longer to prevent dataloss.

 

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.)

 

I just thought of an alternative approach to this whole
situation
though. We could add crypto and expiration functionality to
IndexDB. I
know the crypto stuff has come up before and there was some
hesitation
though. (Though I guess the same thing could be said for
crypto+localStorage)

 

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.

 

 It seems as though expiration policies could be added to the
creation of
 databases and the new FileWriter/FileSystem APIs pretty
easily.

I don't understand the usecase of expiring files. Isn't the
whole
point of saving to the file system so that the user gets better
access
to it and so that things like iPhoto can index any stored
images?


 But stillwe need some use cases.  :-)

I'm all for use cases. Though Nicholas did say that he'd want
encryption and expiration on essentially all privacy sensitive
information stored. Which I think I can understand.

 

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.

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

Yes, |localStorage.setItem(AES.encrypt(username, key),
AES.encrypt(Nicholas, key));| is a bit ugly, but many things in the web
platform are.  And honestly, it's not _that_ ugly or _that_ many extra
characters.  And this is the type of problem JS libraries often solve.

I'd suggest you talk to various libraries (or write your own) about adding
a compatibility layer that includes JS crypto and in parallel talk to
browser vendors about adding a crypto API.

Anyhow, I can say with a fairly high level of certainty that we (Chromium)
are not interested in implementing this.  But maybe others (Mozilla?) are.
 So I'm going to withdraw myself from this discussion since I don't seem to
be adding any new information to it and I think everyone knows where I
stand.  :-)

J

On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:

  I tried to articulate some of my thoughts as to why a generate purpose
 crypto isn’t enough to be useful and why trying to tack onto local storage
 could get messy:


 http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side-data-storage/





 -Nicholas



 __

 Commander Lock: Damnit Morpheus, not everyone believes what you believe!

 Morpheus: My beliefs do not require them to.
   --

 *From:* whatwg-boun...@lists.whatwg.org [mailto:
 whatwg-boun...@lists.whatwg.org] *On Behalf Of *Jeremy Orlow
 *Sent:* Thursday, April 08, 2010 3:14 AM
 *To:* Jonas Sicking
 *Cc:* whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane

 *Subject:* Re: [whatwg] Proposal for secure key-value data stores



 On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org wrote:
  I don't think this is enough of a
  problem to kill the feature though.
 
  I think this is a good feature to try and integrate into existing APIs if
  it's possible to do so cleanly.  I don't think it's worth creating yet
  another persistent storage API over, though.

 ...

  For
  localStorage, we could add a origin-wide setting or add an optional param
 to
  setItem.

 Well, it seems harsh to require that *all* data on a domain is either
 security sensitive, and thus need expiration, or not security
 sensitive and thus need none. I think it makes a lot of sense to be
 able to let the page have several storage areas, some which expire and
 some which don't.

 Think mail.google.com where storing my emails would count as sensitive
 and should have expiration, but storing my drafts might be worth doing
 longer to prevent dataloss.



 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.)



 I just thought of an alternative approach to this whole situation
 though. We could add crypto and expiration functionality to IndexDB. I
 know the crypto stuff has come up before and there was some hesitation
 though. (Though I guess the same thing could be said for
 crypto+localStorage)



 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.



   It seems as though expiration policies could be added to the creation
 of
  databases and the new FileWriter/FileSystem APIs pretty easily.

 I don't understand the usecase of expiring files. Isn't the whole
 point of saving to the file system so that the user gets better access
 to it and so that things like iPhoto can index any stored images?


  But stillwe need some use cases.  :-)

 I'm all for use cases. Though Nicholas did say that he'd want
 encryption and expiration on essentially all privacy sensitive
 information stored. Which I think I can understand.



 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.

Re: [whatwg] Proposal for secure key-value data stores

[Scott Hess]

On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 I tried to articulate some of my thoughts as to why a generate purpose
 crypto isn’t enough to be useful and why trying to tack onto local storage
 could get messy:

 http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side-data-storage/

I guess I don't understand why you think trying to tack it onto local
storage could get messy.  As you present it it would be messy, but
AFAICT it wouldn't be all that hard to write a JavaScript wrapper
which implements substantially the secure-storage interface you
propose using local-storage as a backend.  Doing it native would be
faster and perhaps more secure, but in terms of proving out the
interface itself those aren't really relevant.

-scott

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org wrote:
  I don't think this is enough of a
  problem to kill the feature though.
 
  I think this is a good feature to try and integrate into existing APIs if
  it's possible to do so cleanly.  I don't think it's worth creating yet
  another persistent storage API over, though.
 ...
  For
  localStorage, we could add a origin-wide setting or add an optional param
 to
  setItem.

 Well, it seems harsh to require that *all* data on a domain is either
 security sensitive, and thus need expiration, or not security
 sensitive and thus need none. I think it makes a lot of sense to be
 able to let the page have several storage areas, some which expire and
 some which don't.

 Think mail.google.com where storing my emails would count as sensitive
 and should have expiration, but storing my drafts might be worth doing
 longer to prevent dataloss.


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.)

I just thought of an alternative approach to this whole situation
 though. We could add crypto and expiration functionality to IndexDB. I
 know the crypto stuff has come up before and there was some hesitation
 though. (Though I guess the same thing could be said for
 crypto+localStorage)


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.


  It seems as though expiration policies could be added to the creation of
  databases and the new FileWriter/FileSystem APIs pretty easily.

 I don't understand the usecase of expiring files. Isn't the whole
 point of saving to the file system so that the user gets better access
 to it and so that things like iPhoto can index any stored images?

  But stillwe need some use cases.  :-)

 I'm all for use cases. Though Nicholas did say that he'd want
 encryption and expiration on essentially all privacy sensitive
 information stored. Which I think I can understand.


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.

Re: [whatwg] Proposal for secure key-value data stores

[Paul Kinlan]

Hi,

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.

The main cases I have:

   1. Storage needs to be encrypted on disk, device etc.
   2. Data needs to be in decrypted form for the shortest amount of time
   possible while in use in an application.

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.

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.  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.

In summary, this is something I expect of the UA and not any specific JS
API.

P

On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org wrote:
  I don't think this is enough of a
  problem to kill the feature though.
 
  I think this is a good feature to try and integrate into existing APIs
 if
  it's possible to do so cleanly.  I don't think it's worth creating yet
  another persistent storage API over, though.
 ...
  For
  localStorage, we could add a origin-wide setting or add an optional
 param to
  setItem.

 Well, it seems harsh to require that *all* data on a domain is either
 security sensitive, and thus need expiration, or not security
 sensitive and thus need none. I think it makes a lot of sense to be
 able to let the page have several storage areas, some which expire and
 some which don't.

 Think mail.google.com where storing my emails would count as sensitive
 and should have expiration, but storing my drafts might be worth doing
 longer to prevent dataloss.


 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.)

 I just thought of an alternative approach to this whole situation
 though. We could add crypto and expiration functionality to IndexDB. I
 know the crypto stuff has come up before and there was some hesitation
 though. (Though I guess the same thing could be said for
 crypto+localStorage)


 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.


  It seems as though expiration policies could be added to the creation of
  databases and the new FileWriter/FileSystem APIs pretty easily.

 I don't understand the usecase of expiring files. Isn't the whole
 point of saving to the file system so that the user gets better access
 to it and so that things like iPhoto can index any stored images?

  But stillwe need some use cases.  :-)

 I'm all for use cases. Though Nicholas did say that he'd want
 encryption and expiration on essentially all privacy sensitive
 information stored. Which I think I can understand.


 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.

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

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.


On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan paulkin...@google.com wrote:

 Hi,

 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.

 The main cases I have:

1. Storage needs to be encrypted on disk, device etc.
2. Data needs to be in decrypted form for the shortest amount of time
possible while in use in an application.

 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.)


 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.

 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.


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.


 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.


What's been proposed so far will NOT work as seamlessly as HTTPS.

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.

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).

In summary, this is something I expect of the UA and not any specific JS
 API.


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.


On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org
 wrote:
  I don't think this is enough of a
  problem to kill the feature though.
 
  I think this is a good feature to try and integrate into existing APIs
 if
  it's possible to do so cleanly.  I don't think it's worth creating yet
  another persistent storage API over, though.
 ...
  For
  localStorage, we could add a origin-wide setting or add an optional
 param to
  setItem.

 Well, it seems harsh to require that *all* data on a domain is either
 security sensitive, and thus need expiration, or not security
 sensitive and thus need none. I think it makes a lot of sense to be
 able to let the page have several storage areas, some which expire and
 some which don't.

 Think mail.google.com where storing my emails would count as sensitive
 and should have expiration, but storing my drafts might be worth doing
 longer to prevent dataloss.


 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.)

 I just thought of an alternative approach 

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I've actually already seen a very common repeated pattern as it comes to 
client-side data storage:

 

1. Hey let's try using localStorage to improve our user experience.

2. Sounds great, but the data can't be stored in plain text if its user data.

3. That's okay, we'll just use the XYZ JavaScript encryption library.

4. And then use it on every read and every write?

5. Ugh, you're right, nevermind.

 

I've had, or participated in, this conversation multiple times. I also know, 
from speaking with others about this proposal, that this conversation isn't 
uncommon.

 

Again I'll say I'm all for adding crypto into JavaScript. I think in addition 
to that, there should be affordances for what will likely be common usage 
patterns. To me, any and all mechanisms for client-side storage should have 
some basic crypto built-in, so why not start here?

 

In regards to data expiration, part of ensuring the security of data is knowing 
how long it will be stored on disk. If I let someone borrow my computer to 
check their email, and the email client happens to save some data onto the 
client, then that person's data will now be on my disk for who knows how long. 
That represents a data security issue. By allowing an expiration date to be 
tied to the data, you can have reasonable assurance that the data isn't just 
going to be sitting around waiting for someone to try and use it. 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Jeremy Orlow
Sent: Tuesday, April 06, 2010 6:55 AM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Dirk Pranke
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

Sorry for misunderstanding your original suggestion.

On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is 
eliminate what I believe will be a repeated pattern for developers in the 
future. It would be really nice if, in addition to having access to crypto 
functions, there was an area where I could stick data that would get encrypted 
automatically (and of course, where I could be sure the data would be 
eliminated after a set amount of time).

 

It seems to me that Dirk is right that crypto in the browser is a more general 
problem and that a general crypto API would be much more valuable than creating 
new APIs with similar/duplicate functionality + crypto.  Optimizing for 
repeated patterns probably should wait until we see what patterns are 
actually common.  :-)

 

My proposal is less about encryption and more about providing better 
control over how data is stored and for how long.

 

Can you provide some concrete use cases for expiration of content?  They'd 
probably have to be pretty dramatic to warrant creating yet another storage 
mechanism.

 

Maybe this can somehow be integrated into IndexedDB?  There's very little 
chance of it being a v1 feature, but maybe we could make sure it's possible to 
add in future versions.

 


-Nicholas

__
Commander Lock: Damnit Morpheus, not everyone believes what you 
believe!
Morpheus: My beliefs do not require them to.

-Original Message-

From: whatwg-boun...@lists.whatwg.org 
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com 
wrote:
 Yes, that's precisely what I'm talking about. It seems to me that 
this will end up being a pretty common pattern (encrypting/decrypting data 
stored locally).

 The idea behind letting the key to be defined by the developer is to 
allow any usage that developers deem appropriate for the situation. For 
example, one might want to only use a server-generated key to access the data, 
in which case this data won't be available offline but will be used to 
supplement the online behavior. Another might determine the key based on some 
information in a cookie, which is less secure but does allow offline access 
while also ensuring that if the cookie changes or is deleted, the data remains 
secure.

 The idea behind the expiration date is to allow developers to be sure 
the data won't stay around on disk indefinitely. Think about the Internet café 
use case where people are repeatedly logging in and out - we don't want 
everyone's data living on that computer for however many years it's in use.

 One

Re: [whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

On Wed, Apr 7, 2010 at 2:14 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 I’ve actually already seen a very common repeated pattern as it comes to
 client-side data storage:

 1. “Hey let’s try using localStorage to improve our user experience.”

 2. “Sounds great, but the data can’t be stored in plain text if its user
 data.”

 3. “That’s okay, we’ll just use the XYZ JavaScript encryption library.”

 4. “And then use it on every read and every write?”

 5. “Ugh, you’re right, nevermind.”


Presumably the ugh is a reaction to the perceived slowness of doing
the crypto in JS? Has anyone
benchmarked JS crypto performance compared to what the imagined C/C++
perf would be?


 I’ve had, or participated in, this conversation multiple times. I also know,
 from speaking with others about this proposal, that this conversation isn’t
 uncommon.



 Again I’ll say I’m all for adding crypto into JavaScript. I think in
 addition to that, there should be affordances for what will likely be common
 usage patterns. To me, any and all mechanisms for client-side storage should
 have some basic crypto built-in, so why not start here?



 In regards to data expiration, part of ensuring the security of data is
 knowing how long it will be stored on disk. If I let someone borrow my
 computer to check their email, and the email client happens to save some
 data onto the client, then that person’s data will now be on my disk for who
 knows how long. That represents a data security issue. By allowing an
 expiration date to be tied to the data, you can have reasonable assurance
 that the data isn’t just going to be sitting around waiting for someone to
 try and use it.


It is true that not having control over your data could be an issue, but simply
embedding expiry into the data may not buy you much to protect it. Insofar
as the crypto wouldn't be running in a TPM, it would be easy to reverse engineer
it and extract the data; it would also be fairly easy to reset the
clock on the device
to keep data from being deleted.

I continue to think that the requirements for a secure storage API
that fit a wide
range of use cases are not particularly clear (and it would be easy to see this
balloon into a wide API designed for lots of different corner cases).
I think the ideal
approach for this would be to build a JS-based implementation on top
of the existing
libraries and, if such a library sees wide adoption, push for it to be
implemented natively.

If there are fundamental missing primitives, then by all means we
should look at adding
them, but I'm not sure that we are missing anything.

-- Dirk



 -Nicholas



 __

 Commander Lock: Damnit Morpheus, not everyone believes what you believe!

 Morpheus: My beliefs do not require them to.

 

 From: whatwg-boun...@lists.whatwg.org
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
 Sent: Tuesday, April 06, 2010 6:55 AM
 To: Nicholas Zakas
 Cc: whatwg@lists.whatwg.org; Dirk Pranke

 Subject: Re: [whatwg] Proposal for secure key-value data stores



 Sorry for misunderstanding your original suggestion.

 On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:

 I certainly can't argue against a focus on JS crypto. :) What I'd like to do
 is eliminate what I believe will be a repeated pattern for developers in the
 future. It would be really nice if, in addition to having access to crypto
 functions, there was an area where I could stick data that would get
 encrypted automatically (and of course, where I could be sure the data would
 be eliminated after a set amount of time).



 It seems to me that Dirk is right that crypto in the browser is a more
 general problem and that a general crypto API would be much more valuable
 than creating new APIs with similar/duplicate functionality + crypto.
  Optimizing for repeated patterns probably should wait until we see what
 patterns are actually common.  :-)



 My proposal is less about encryption and more about providing better control
 over how data is stored and for how long.



 Can you provide some concrete use cases for expiration of content?  They'd
 probably have to be pretty dramatic to warrant creating yet another storage
 mechanism.



 Maybe this can somehow be integrated into IndexedDB?  There's very little
 chance of it being a v1 feature, but maybe we could make sure it's possible
 to add in future versions.



 -Nicholas

 __
 Commander Lock: Damnit Morpheus, not everyone believes what you believe!
 Morpheus: My beliefs do not require them to.

 -Original Message-

 From: whatwg-boun...@lists.whatwg.org
 [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke
 Sent: Tuesday, March 30, 2010 3:09 PM
 To: Nicholas Zakas
 Cc: whatwg@lists.whatwg.org; Jeremy Orlow
 Subject: Re: [whatwg] Proposal for secure key-value data stores

 On Tue, Mar 30, 2010 at 2:06 PM

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

On Wed, Apr 7, 2010 at 10:26 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, Apr 7, 2010 at 2:14 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:
  I’ve actually already seen a very common repeated pattern as it comes to
  client-side data storage:
 
  1. “Hey let’s try using localStorage to improve our user experience.”
 
  2. “Sounds great, but the data can’t be stored in plain text if its user
  data.”
 
  3. “That’s okay, we’ll just use the XYZ JavaScript encryption library.”
 
  4. “And then use it on every read and every write?”
 
  5. “Ugh, you’re right, nevermind.”
 

 Presumably the ugh is a reaction to the perceived slowness of doing
 the crypto in JS? Has anyone
 benchmarked JS crypto performance compared to what the imagined C/C++
 perf would be?


Or are there any actual examples of where someone was going to use JS crypto
but abandoned it because it was too slow?  If the issue is that it's too
hard but yet no one's bothered to make a library to make things easier,
then honestly I find it hard to believe this is a super important issue to
more than a handful of web developers.


 
  I’ve had, or participated in, this conversation multiple times. I also
 know,
  from speaking with others about this proposal, that this conversation
 isn’t
  uncommon.
 
 
 
  Again I’ll say I’m all for adding crypto into JavaScript. I think in
  addition to that, there should be affordances for what will likely be
 common
  usage patterns. To me, any and all mechanisms for client-side storage
 should
  have some basic crypto built-in, so why not start here?
 
 
 
  In regards to data expiration, part of ensuring the security of data is
  knowing how long it will be stored on disk. If I let someone borrow my
  computer to check their email, and the email client happens to save some
  data onto the client, then that person’s data will now be on my disk for
 who
  knows how long. That represents a data security issue. By allowing an
  expiration date to be tied to the data, you can have reasonable assurance
  that the data isn’t just going to be sitting around waiting for someone
 to
  try and use it.
 

 It is true that not having control over your data could be an issue, but
 simply
 embedding expiry into the data may not buy you much to protect it. Insofar
 as the crypto wouldn't be running in a TPM, it would be easy to reverse
 engineer
 it and extract the data; it would also be fairly easy to reset the
 clock on the device
 to keep data from being deleted.


One thing that might be interesting is a way to cache large amounts of data
that are deleted when the browser and/or tab closes.  This might be
something for the new file system API to consider (hence adding ericu to the
thread).  But time based controls aren't going to do anything more than give
perceived security.  (In your use case, expiration doesn't add much actual
security for the reasons Dirk mentioned.)


 I continue to think that the requirements for a secure storage API
 that fit a wide
 range of use cases are not particularly clear (and it would be easy to see
 this
 balloon into a wide API designed for lots of different corner cases).
 I think the ideal
 approach for this would be to build a JS-based implementation on top
 of the existing
 libraries and, if such a library sees wide adoption, push for it to be
 implemented natively.

 If there are fundamental missing primitives, then by all means we
 should look at adding
 them, but I'm not sure that we are missing anything.


Yes.  We generally only add surface area to APIs (let alone APIs themselves)
for use cases that are either not possible or performance problems.  Doing
crypto in JS certainly seems as though it could be the latter.  Expiration
is the former.  But for both, we need clear use cases that are not
possible/practical today.

Despite me asking several times, you haven't given any clear use cases.  If
you search the list archives, you'll find that whenever we talk about new
APIs, they're very rooted in specific use cases.



 -- Dirk

 
 
  -Nicholas
 
 
 
  __
 
  Commander Lock: Damnit Morpheus, not everyone believes what you
 believe!
 
  Morpheus: My beliefs do not require them to.
 
  
 
  From: whatwg-boun...@lists.whatwg.org
  [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
  Sent: Tuesday, April 06, 2010 6:55 AM
  To: Nicholas Zakas
  Cc: whatwg@lists.whatwg.org; Dirk Pranke
 
  Subject: Re: [whatwg] Proposal for secure key-value data stores
 
 
 
  Sorry for misunderstanding your original suggestion.
 
  On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.com
  wrote:
 
  I certainly can't argue against a focus on JS crypto. :) What I'd like to
 do
  is eliminate what I believe will be a repeated pattern for developers in
 the
  future. It would be really nice if, in addition to having access to
 crypto
  functions, there was an area where I could stick data

Re: [whatwg] Proposal for secure key-value data stores

[Jonas Sicking]

On Wed, Apr 7, 2010 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote:
  In regards to data expiration, part of ensuring the security of data is
  knowing how long it will be stored on disk. If I let someone borrow my
  computer to check their email, and the email client happens to save some
  data onto the client, then that person’s data will now be on my disk for
  who
  knows how long. That represents a data security issue. By allowing an
  expiration date to be tied to the data, you can have reasonable
  assurance
  that the data isn’t just going to be sitting around waiting for someone
  to
  try and use it.
 

 It is true that not having control over your data could be an issue, but
 simply
 embedding expiry into the data may not buy you much to protect it. Insofar
 as the crypto wouldn't be running in a TPM, it would be easy to reverse
 engineer
 it and extract the data; it would also be fairly easy to reset the
 clock on the device
 to keep data from being deleted.

 One thing that might be interesting is a way to cache large amounts of data
 that are deleted when the browser and/or tab closes.  This might be
 something for the new file system API to consider (hence adding ericu to the
 thread).  But time based controls aren't going to do anything more than give
 perceived security.  (In your use case, expiration doesn't add much actual
 security for the reasons Dirk mentioned.)

I disagree. Having data time out is a good additional layer of
security. For example if your laptop gets stolen, then it's much
better if the thief only gets access to the sites you've used the last
24h, than any site you've ever used.

This is why people do things like enforce password changes every X
weeks. Yes, password changing has social downsides, like people
writing down passwords on post-its etc. However those problems do not
seem to apply here.

So I don't think anyone is arguing that expiration is good security in
and of itself. But it is a good (and low cost) way of getting
additional security.

/ Jonas

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

On Thu, Apr 8, 2010 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote:
   In regards to data expiration, part of ensuring the security of data
 is
   knowing how long it will be stored on disk. If I let someone borrow my
   computer to check their email, and the email client happens to save
 some
   data onto the client, then that person’s data will now be on my disk
 for
   who
   knows how long. That represents a data security issue. By allowing an
   expiration date to be tied to the data, you can have reasonable
   assurance
   that the data isn’t just going to be sitting around waiting for
 someone
   to
   try and use it.
  
 
  It is true that not having control over your data could be an issue, but
  simply
  embedding expiry into the data may not buy you much to protect it.
 Insofar
  as the crypto wouldn't be running in a TPM, it would be easy to reverse
  engineer
  it and extract the data; it would also be fairly easy to reset the
  clock on the device
  to keep data from being deleted.
 
  One thing that might be interesting is a way to cache large amounts of
 data
  that are deleted when the browser and/or tab closes.  This might be
  something for the new file system API to consider (hence adding ericu to
 the
  thread).  But time based controls aren't going to do anything more than
 give
  perceived security.  (In your use case, expiration doesn't add much
 actual
  security for the reasons Dirk mentioned.)

 I disagree. Having data time out is a good additional layer of
 security. For example if your laptop gets stolen, then it's much
 better if the thief only gets access to the sites you've used the last
 24h, than any site you've ever used.

 This is why people do things like enforce password changes every X
 weeks. Yes, password changing has social downsides, like people
 writing down passwords on post-its etc. However those problems do not
 seem to apply here.

 So I don't think anyone is arguing that expiration is good security in
 and of itself. But it is a good (and low cost) way of getting
 additional security.


Sure, but it should not be thought of as anything more than a hint.  If I go
to a site that says expire the data in 24 hours and then I turn it off and
don't use it for a year, that data is still there.

Anything that has the outward appearance of adding more security than it
actually does worries me.  (I'm obviously worried a lot. :-)

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

On Thu, Apr 8, 2010 at 1:09 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 7, 2010 at 4:54 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Thu, Apr 8, 2010 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Apr 7, 2010 at 4:29 PM, Jeremy Orlow jor...@chromium.org
 wrote:
In regards to data expiration, part of ensuring the security of
 data
is
knowing how long it will be stored on disk. If I let someone borrow
my
computer to check their email, and the email client happens to save
some
data onto the client, then that person’s data will now be on my
 disk
for
who
knows how long. That represents a data security issue. By allowing
 an
expiration date to be tied to the data, you can have reasonable
assurance
that the data isn’t just going to be sitting around waiting for
someone
to
try and use it.
   
  
   It is true that not having control over your data could be an issue,
   but
   simply
   embedding expiry into the data may not buy you much to protect it.
   Insofar
   as the crypto wouldn't be running in a TPM, it would be easy to
 reverse
   engineer
   it and extract the data; it would also be fairly easy to reset the
   clock on the device
   to keep data from being deleted.
  
   One thing that might be interesting is a way to cache large amounts of
   data
   that are deleted when the browser and/or tab closes.  This might be
   something for the new file system API to consider (hence adding ericu
 to
   the
   thread).  But time based controls aren't going to do anything more
 than
   give
   perceived security.  (In your use case, expiration doesn't add much
   actual
   security for the reasons Dirk mentioned.)
 
  I disagree. Having data time out is a good additional layer of
  security. For example if your laptop gets stolen, then it's much
  better if the thief only gets access to the sites you've used the last
  24h, than any site you've ever used.
 
  This is why people do things like enforce password changes every X
  weeks. Yes, password changing has social downsides, like people
  writing down passwords on post-its etc. However those problems do not
  seem to apply here.
 
  So I don't think anyone is arguing that expiration is good security in
  and of itself. But it is a good (and low cost) way of getting
  additional security.
 
  Sure, but it should not be thought of as anything more than a hint.  If I
 go
  to a site that says expire the data in 24 hours and then I turn it off
 and
  don't use it for a year, that data is still there.

 This is true, and important.

  Anything that has the outward appearance of adding more security than it
  actually does worries me.  (I'm obviously worried a lot. :-)

 I think it's pretty obvious though that expiring the data X seconds in
 the future doesn't in and of itself give any protection what so ever
 until the data has actually been expired.

 I guess it could be argued that it isn't obvious that the data is only
 expired if the browser is running.


It's possible UAs can be a bit more smart about this as well.  For example,
many OSs have a way to schedule things to run in the future.  (And could
have a helper program that does the deleting.)


 I don't think this is enough of a
 problem to kill the feature though.


I think this is a good feature to try and integrate into existing APIs if
it's possible to do so cleanly.  I don't think it's worth creating yet
another persistent storage API over, though.

It seems as though expiration policies could be added to the creation of
databases and the new FileWriter/FileSystem APIs pretty easily.  For
localStorage, we could add a origin-wide setting or add an optional param to
setItem.

But stillwe need some use cases.  :-)

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

Sorry for misunderstanding your original suggestion.

On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.comwrote:

 I certainly can't argue against a focus on JS crypto. :) What I'd like to
 do is eliminate what I believe will be a repeated pattern for developers in
 the future. It would be really nice if, in addition to having access to
 crypto functions, there was an area where I could stick data that would get
 encrypted automatically (and of course, where I could be sure the data would
 be eliminated after a set amount of time).


It seems to me that Dirk is right that crypto in the browser is a more
general problem and that a general crypto API would be much more valuable
than creating new APIs with similar/duplicate functionality + crypto.
 Optimizing for repeated patterns probably should wait until we see what
patterns are actually common.  :-)


 My proposal is less about encryption and more about providing better
 control over how data is stored and for how long.


Can you provide some concrete use cases for expiration of content?  They'd
probably have to be pretty dramatic to warrant creating yet another storage
mechanism.

Maybe this can somehow be integrated into IndexedDB?  There's very little
chance of it being a v1 feature, but maybe we could make sure it's possible
to add in future versions.



 -Nicholas

 __
 Commander Lock: Damnit Morpheus, not everyone believes what you believe!
 Morpheus: My beliefs do not require them to.

 -Original Message-
 From: whatwg-boun...@lists.whatwg.org [mailto:
 whatwg-boun...@lists.whatwg.org] On Behalf Of Dirk Pranke
 Sent: Tuesday, March 30, 2010 3:09 PM
 To: Nicholas Zakas
 Cc: whatwg@lists.whatwg.org; Jeremy Orlow
 Subject: Re: [whatwg] Proposal for secure key-value data stores

 On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:
  Yes, that's precisely what I'm talking about. It seems to me that this
 will end up being a pretty common pattern (encrypting/decrypting data stored
 locally).
 
  The idea behind letting the key to be defined by the developer is to
 allow any usage that developers deem appropriate for the situation. For
 example, one might want to only use a server-generated key to access the
 data, in which case this data won't be available offline but will be used to
 supplement the online behavior. Another might determine the key based on
 some information in a cookie, which is less secure but does allow offline
 access while also ensuring that if the cookie changes or is deleted, the
 data remains secure.
 
  The idea behind the expiration date is to allow developers to be sure the
 data won't stay around on disk indefinitely. Think about the Internet café
 use case where people are repeatedly logging in and out - we don't want
 everyone's data living on that computer for however many years it's in use.
 
  One way or another, I think JavaScript crypto is going to be important in
 the next few years.

 Perhaps we should instead focus on a set of JS Crypto APIs, since that
 is largely orthogonal to the storage APIs?

 -- Dirk

[whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

Hi everyone,

 

In attempting to use localStorage at work, we ran into some major
security issues. Primary among those are the guidelines we have in place
regarding personalized user data. The short story is that personalized
data cannot be stored on disk unless it's encrypted using a
company-validated encryption mechanism and key. So if we actually wanted
to use localStorage, we'd be forced to encrypt each value as it was
being written and then decrypt each value being read. Because of this
tediousness, we opted not to use it. 

 

Another major issue also relates to the persistence of the data in
localStorage. Whereas cookies allow you to specify a time at which the
data will be removed, localStorage is there more or less forever.

 

It seems like any company that takes the security of its data seriously
would run into the same issues, and rather than forcing every company to
implement their own version of the same approach, a common native
approach would be incredibly useful.

 

With these problems in mind, and talking with a few other interested
parties, I came up with a draft proposal for a client-side data storage
mechanism that automatically handles encryption, decryption, and data
expiration. I'd love to hear what people think:

 

http://www.nczonline.net/blog/securestore-proposal/

 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.

 

Re: [whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

Most companies that have such policies enforce them with software that
encrypts your home directory (or entire hard drive).  Since most (all?)
browsers store such data within a users home directory, that should be
sufficient for the specific case you're mentioning.  (Well, except
for expiration.)  Note that home directory encryption is easy and free on
some Linux distros and Mac OS.  (I don't know either way about Windows.)

To be honest, if someone can get at _any_ of your browser data (LocalStorage
included) you have a pretty major problem.  So tacking something onto other
storage APIs doesn't really make that much sense.  If someone can get at
even just your cookies, they can probably do a lot of damage.

What are the use cases around expiration of data?

Lastly, we really should not be creating new APIs that are synchronous that
involve multiple top level windows (like LocalStorage and this API you're
proposing).  It makes it very difficult to achieve isolation and parallelism
between multiple sites.

J

On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:

  Hi everyone,



 In attempting to use localStorage at work, we ran into some major security
 issues. Primary among those are the guidelines we have in place regarding
 personalized user data. The short story is that personalized data cannot be
 stored on disk unless it’s encrypted using a company-validated encryption
 mechanism and key. So if we actually wanted to use localStorage, we’d be
 forced to encrypt each value as it was being written and then decrypt each
 value being read. Because of this tediousness, we opted not to use it.



 Another major issue also relates to the persistence of the data in
 localStorage. Whereas cookies allow you to specify a time at which the data
 will be removed, localStorage is there more or less forever.



 It seems like any company that takes the security of its data seriously
 would run into the same issues, and rather than forcing every company to
 implement their own version of the same approach, a common native approach
 would be incredibly useful.



 With these problems in mind, and talking with a few other interested
 parties, I came up with a draft proposal for a client-side data storage
 mechanism that automatically handles encryption, decryption, and data
 expiration. I’d love to hear what people think:



 http://www.nczonline.net/blog/securestore-proposal/





 -Nicholas



 __

 Commander Lock: Damnit Morpheus, not everyone believes what you believe!

 Morpheus: My beliefs do not require them to.

Re: [whatwg] Proposal for secure key-value data stores

[Jonas Sicking]

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow jor...@chromium.org wrote:
 Lastly, we really should not be creating new APIs that are synchronous that
 involve multiple top level windows (like LocalStorage and this API you're
 proposing).  It makes it very difficult to achieve isolation and parallelism
 between multiple sites.

For what it's worth, this API uses an asynchronous getter to get hold
of the storage object. So the problem that you are describing, and
which does exist with localStorage, does not exist with this new API.

/ Jonas

Re: [whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
encrypted).

Hence they cannot enforce anything like use FileVault.

If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.

Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
We can implement the required crypto in JavaScript, but should we have
to?

-- Dirk

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow jor...@chromium.org wrote:
 Most companies that have such policies enforce them with software that
 encrypts your home directory (or entire hard drive).  Since most (all?)
 browsers store such data within a users home directory, that should be
 sufficient for the specific case you're mentioning.  (Well, except
 for expiration.)  Note that home directory encryption is easy and free on
 some Linux distros and Mac OS.  (I don't know either way about Windows.)
 To be honest, if someone can get at _any_ of your browser data (LocalStorage
 included) you have a pretty major problem.  So tacking something onto other
 storage APIs doesn't really make that much sense.  If someone can get at
 even just your cookies, they can probably do a lot of damage.
 What are the use cases around expiration of data?
 Lastly, we really should not be creating new APIs that are synchronous that
 involve multiple top level windows (like LocalStorage and this API you're
 proposing).  It makes it very difficult to achieve isolation and parallelism
 between multiple sites.
 J
 On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:

 Hi everyone,



 In attempting to use localStorage at work, we ran into some major security
 issues. Primary among those are the guidelines we have in place regarding
 personalized user data. The short story is that personalized data cannot be
 stored on disk unless it’s encrypted using a company-validated encryption
 mechanism and key. So if we actually wanted to use localStorage, we’d be
 forced to encrypt each value as it was being written and then decrypt each
 value being read. Because of this tediousness, we opted not to use it.



 Another major issue also relates to the persistence of the data in
 localStorage. Whereas cookies allow you to specify a time at which the data
 will be removed, localStorage is there more or less forever.



 It seems like any company that takes the security of its data seriously
 would run into the same issues, and rather than forcing every company to
 implement their own version of the same approach, a common native approach
 would be incredibly useful.



 With these problems in mind, and talking with a few other interested
 parties, I came up with a draft proposal for a client-side data storage
 mechanism that automatically handles encryption, decryption, and data
 expiration. I’d love to hear what people think:



 http://www.nczonline.net/blog/securestore-proposal/





 -Nicholas



 __

 Commander Lock: Damnit Morpheus, not everyone believes what you believe!

 Morpheus: My beliefs do not require them to.

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

Yes, that's precisely what I'm talking about. It seems to me that this will end 
up being a pretty common pattern (encrypting/decrypting data stored locally).

The idea behind letting the key to be defined by the developer is to allow any 
usage that developers deem appropriate for the situation. For example, one 
might want to only use a server-generated key to access the data, in which case 
this data won't be available offline but will be used to supplement the online 
behavior. Another might determine the key based on some information in a 
cookie, which is less secure but does allow offline access while also ensuring 
that if the cookie changes or is deleted, the data remains secure.

The idea behind the expiration date is to allow developers to be sure the data 
won't stay around on disk indefinitely. Think about the Internet café use case 
where people are repeatedly logging in and out - we don't want everyone's data 
living on that computer for however many years it's in use.

One way or another, I think JavaScript crypto is going to be important in the 
next few years. 


-Nicholas
 
__
Commander Lock: Damnit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

-Original Message-
From: dpra...@google.com [mailto:dpra...@google.com] On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 1:24 PM
To: Jeremy Orlow
Cc: Nicholas Zakas; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for secure key-value data stores

Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
encrypted).

Hence they cannot enforce anything like use FileVault.

If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.

Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
We can implement the required crypto in JavaScript, but should we have
to?

-- Dirk

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow jor...@chromium.org wrote:
 Most companies that have such policies enforce them with software that
 encrypts your home directory (or entire hard drive).  Since most (all?)
 browsers store such data within a users home directory, that should be
 sufficient for the specific case you're mentioning.  (Well, except
 for expiration.)  Note that home directory encryption is easy and free on
 some Linux distros and Mac OS.  (I don't know either way about Windows.)
 To be honest, if someone can get at _any_ of your browser data (LocalStorage
 included) you have a pretty major problem.  So tacking something onto other
 storage APIs doesn't really make that much sense.  If someone can get at
 even just your cookies, they can probably do a lot of damage.
 What are the use cases around expiration of data?
 Lastly, we really should not be creating new APIs that are synchronous that
 involve multiple top level windows (like LocalStorage and this API you're
 proposing).  It makes it very difficult to achieve isolation and parallelism
 between multiple sites.
 J
 On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:

 Hi everyone,



 In attempting to use localStorage at work, we ran into some major security
 issues. Primary among those are the guidelines we have in place regarding
 personalized user data. The short story is that personalized data cannot be
 stored on disk unless it's encrypted using a company-validated encryption
 mechanism and key. So if we actually wanted to use localStorage, we'd be
 forced to encrypt each value as it was being written and then decrypt each
 value being read. Because of this tediousness, we opted not to use it.



 Another major issue also relates to the persistence of the data in
 localStorage. Whereas cookies allow you to specify a time at which the data
 will be removed, localStorage is there more or less forever.



 It seems like any company that takes the security of its data seriously
 would run into the same issues, and rather than forcing every company to
 implement their own version of the same approach, a common native approach
 would be incredibly useful.



 With these problems in mind, and talking with a few other interested
 parties, I came up with a draft proposal for a client-side data storage
 mechanism that automatically handles encryption, decryption, and data
 expiration. I'd love to hear what people think:



 http://www.nczonline.net/blog/securestore-proposal/





 -Nicholas

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is 
eliminate what I believe will be a repeated pattern for developers in the 
future. It would be really nice if, in addition to having access to crypto 
functions, there was an area where I could stick data that would get encrypted 
automatically (and of course, where I could be sure the data would be 
eliminated after a set amount of time).

My proposal is less about encryption and more about providing better control 
over how data is stored and for how long.

-Nicholas
 
__
Commander Lock: Damnit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 Yes, that's precisely what I'm talking about. It seems to me that this will 
 end up being a pretty common pattern (encrypting/decrypting data stored 
 locally).

 The idea behind letting the key to be defined by the developer is to allow 
 any usage that developers deem appropriate for the situation. For example, 
 one might want to only use a server-generated key to access the data, in 
 which case this data won't be available offline but will be used to 
 supplement the online behavior. Another might determine the key based on some 
 information in a cookie, which is less secure but does allow offline access 
 while also ensuring that if the cookie changes or is deleted, the data 
 remains secure.

 The idea behind the expiration date is to allow developers to be sure the 
 data won't stay around on disk indefinitely. Think about the Internet café 
 use case where people are repeatedly logging in and out - we don't want 
 everyone's data living on that computer for however many years it's in use.

 One way or another, I think JavaScript crypto is going to be important in the 
 next few years.

Perhaps we should instead focus on a set of JS Crypto APIs, since that
is largely orthogonal to the storage APIs?

-- Dirk