[whatwg] Significant changes to globalStorage
Ian Hickson
ian at hixie.ch
Mon Dec 10 17:46:50 PST 2007
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list