[whatwg] Significant changes to globalStorage

I just checked in a change to make globalStorage far simpler -- I dropped 
all the domain manipulation stuff, and made it same-origin instead. I also 
dropped StorageItem and just made the Storage stuff return strings.

For more complex operations, we now have the SQL database APIs.

This makes a number of issues moot.

On Thu, 29 Jun 2006, Hallvord R M Steen wrote:
> > On Mon, 26 Jun 2006, Gervase Markham wrote:
> > > >
> > > > interface StorageItem {
> > > >            attribute boolean secure;
> > > >            attribute DOMString value;
> > > > };
> > >
> > > I would like to suggest the the "secure" attribute be an integer 
> > > rather than a boolean, initially with 0 meaning insecure, and 1 
> > > meaning secure.
> > >
> > > So, for example, you could have StorageItems which were only 
> > > returned if the page on the site was secured with a new EV cert, and 
> > > was not accessible to pages which had an ordinary cert or no cert.
> > 
> > Is it ever possible to get an "ordinary cert" which claims to identify 
> > some domain, but which was not purchased by the owners of that domain?
> 
> Depends on your definition of "ordinary" - what about self-signed 
> certificates, or certificate chains that do not resolve to a known root 
> certificate? A very security conscious application author might want to 
> be able to limit access to stored data only to certificates that are 
> 100% kosher, so that even if the UA warns the user about a certificate 
> problem and the user accepts it, stored information isn't made 
> available.

This is moot now as I have dropped StorageItem. You can only ever get 
access to a storage item if you are in the same origin that it was created 
in. (We could make the type of cert part of the definition of "origin", if 
desired; this would address this problem for a number of other cases and 
not just make it work for storage.)


On Tue, 29 Aug 2006, Shannon Baker wrote:
> >
> > 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.

This is now moot since it's all based on origin instead of domain parts.


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

This isn't what I did; instead I simply reduced the security model of the 
globalStorage stuff to the same-origin model used everywhere else in HTML.


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

It's not clear to me exactly how this would work. You mean you want to 
require some sort of out-of-band site authentication before doing any 
globalStorage access?

Could you elaborate on exactly how this would work?


On Mon, 4 Sep 2006, Daniel Veditz wrote:
> >
> > Note that the problems you raise also exist (and have long existed) 
> > with cookies; at least the storage APIs default to a safe state in the 
> > general case instead of defaulting to an unsafe state.
> 
> In what way do the storage API's default to a "safe state"? What "unsafe 
> state" is the alternative? You've lost me.

This is now moot with the security model changes.


> My personal preference is for 1b -- use globalStorage[''] as the 
> non-shared storage area.

I've removed all shared storage. We can use cross-domain communication for 
shared storage needs (using the postMessage() stuff on iframes).


On Mon, 11 Dec 2006, Zac Spitzer wrote:
>
> how does adding a flag for a storage item which indicates this item can 
> be flushed from the session storage (ie cache) if the allocated space 
> for client side storage is full.
> 
> This would allow developers to use the storage more efficently and 
> simply

With the removal of StorageItem, we dropped all the flags as well. I think 
if authors want to add metadata to their storage items, it would make 
sense to encourage them to use the more comprehensive database API.


On Fri, 1 Jun 2007, Gervase Markham wrote:
> >
> > Yeah, this is mentioned in the security section:
> > 
> >    http://www.whatwg.org/specs/web-apps/current-work/#security5
> > 
> > ...along with recommended solutions to mitigate it.
> 
> All of those mitigation measures seem to be non-ideal.
> 
> Have any browser makers expressed opinions on which of them they are 
> planning to implement?
> 
> Is there a document somewhere outlining the actual benefits of this 
> feature, even as potentially restricted?

Do the new changes address your concerns?


On Fri, 1 Jun 2007, Jerason Banes wrote:
> 
> I disagree. The third item in the list describes the solution which I 
> had in mind:
> 
> "Blocking access to the top-level domain 
> ("public<http://www.whatwg.org/specs/web-apps/current-work/#public0>") 
> storage areas: user agents may prevent domains from storing data in and 
> reading data from the top-level domain entries in the 
> globalStorage<http://www.whatwg.org/specs/web-apps/current-work/#globalstorage>object. 
> For example, content at the domain www.example.com would be allowed to 
> access example.com data but not comdata."
> 
> That effectively restricts the storage to a single domain and is in line 
> with how cookies work today.

Sadly it's complicated to implement. It's now moot, anyway.


On Mon, 4 Jun 2007, Gervase Markham wrote:
> 
> To restate more clearly: "Is there a document somewhere outlining the 
> actual benefits of being able to share data across domains?"

I don't think there is, but this is now moot in this context. Sharing 
across sites is now only possible with an active approach of running code 
from that site as a proxy.

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

Received on Monday, 10 December 2007 17:46:50 UTC