[whatwg] Persistent storage is critically flawed.

[Shannon Baker]

Ian Hickson said (among other things):
> It seems that what you are suggesting is that foo.example.com cannot trust 
> example.com, because example.com could then steal data from 
> foo.example.com. But there's a much simpler attack scenario for 
> example.com: it can just take over foo.example.com directly. For example, 
> it could insert new HTML code containing <script> tags (which is exactly 
> what geocities.com does today, for example!), or it could change the DNS 
> entries (which is what, e.g., dyndns.org could do).
>
> There is an implicit trust relationship here already. There is no point 
> making the storage APIs more secure than the DNS and Web servers they rely 
> on. That would be like putting a $500 padlock on a paper screen.

I interpret this comment as: "since there is already a hole in the hull 
of our boat, it doesn't matter if we drill some more". The proposal and 
your justification make too many assumptions about the [site owner / 
server owner / DNS provider] relationships and/or security that are 
unverifiable. If I run a server at books.jump.to then I accept that they 
COULD redirect my domain or even insert code but I also expect that I 
could DETECT IT and possibly sue for breach of contract. That's the key 
flaw in your argument - all of the exploits above are easy to detect - 
but no hacking or tampering is required for an untrusted party to access 
shared global storage. All that's required is a single page anywhere on 
jump.to at any time to perform a simple walk over the storage array - 
something which could easily be disguised as a legitimate action. That 
is the crux of my concern - not that the proposal allows new forms of 
abuse - but that it makes existing abuses easier to implement and harder 
to detect and remove.

I'm not going to respond to all your points individually since most 
amount to 'Sure there are problems but UAs will fix them for us' or 
'we'll fix it later'. I can only take your word for that. Besides most 
of the proposals' flaws can be resolved with something like the following:

== THE 'RIGHT' WAY TO STORE PRIVATE USER DATA ==
Remove ALL trust assumptions based on the domain name and use 
public/private certificates to sign data in and out of storage. This 
would also allow IP based hosts to use storage. Remember, our objectives 
for persistent storage are simply:

To store an object on a client and retrieve it later, even if the 
'session' has since been closed.
Allow trusted site(s) access to a previously stored client-side data 
object (such as a user document)

It's quite a simple requirement that is only complicated by the 
standards' lame definition of what a 'trusted' site is. I absolutely 
insist that trust can never be inferred from DNS or IP information. In 
fact even the site authors own domain is somewhat suspect since it can 
change ownership if not renewed (it happened to me when a registrar 
screwed me over). Therefore we need a system of credentials based on the 
site owner. Fortunately this is similar to the problem that SSL site 
certificates solve. Since we already have a way of obtaining and 
verifying certificates it should not be a big stretch to extend this to 
private storage. It wouldn't even need to be as complex as an SSL cert 
since we are only trying to establish that the site trying to access the 
key possesses the same private or group certificate as the site setting 
it. Provided each site can have multiple certs then all the requirements 
of the spec can be met without bleeding out data to abitrary 
third-parties and dodgy ISPs. Sure your hosting service _could_ steal 
your private keys but that is unlikely to go undetected for long and 
would qualify as a crime in most countries (forgery,theft,fraud - take 
your pick).

Anyway that's just a basic outline but it is FUNDAMENTALLY better than 
the one the draft proposes. It requires nothing from the UA except the 
ability to perform certificate validation and nothing from the site 
author other than a way to generate and protect private certificates and 
send signed data. I could go into more detail and even draft a sample 
implementation should anyone be serious about persuing this idea.

On the other hand if Jim is right and the authors of the storage 
proposal are really just pushing for a better user-tracking system under 
the guise of a user feature then this argument is already over. Do 
whatever you like and I'll make sure it's turned off in my browser.

Shannon
Web Developer