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
