Re: [whatwg] Potenial Security Problem in Global Storage Specification
Jerason Banes wrote: That effectively restricts the storage to a single domain and is in line with how cookies work today. Yes, it does. But I don't think I have been insufficiently clear. My issue is not with the idea of DOM Storage as a whole, but with the idea of sharing information across sites - which requires this global storage. I wasn't able to find any docs that describe the Storage security model used in Gecko, so I ran a few tests. What I found was that any attempt to access globalStorage[''] or globalStorage['com'] from the context of a website resulted in a security error. You can try the test for yourself here: http://java.dnsalias.com/temp/storage.html I suspect it might use, or be planning to use, the Effective TLD service, which provides information necessary to implement the scheme you referenced above. Is there a document somewhere outlining the actual benefits of this feature, even as potentially restricted? The specification has this explanation: Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the clientside for performance reasons. To restate more clearly: Is there a document somewhere outlining the actual benefits of being able to share data across domains? Gerv
Re: [whatwg] Potenial Security Problem in Global Storage Specification
Ian Hickson 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? Gerv
Re: [whatwg] Potenial Security Problem in Global Storage Specification
On 6/1/07, Gervase Markham [EMAIL PROTECTED] wrote: Ian Hickson 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. I disagree. The third item in the list describes the solution which I had in mind: Blocking access to the top-level domain (publichttp://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 globalStoragehttp://www.whatwg.org/specs/web-apps/current-work/#globalstorageobject. 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. Have any browser makers expressed opinions on which of them they are planning to implement? That's a good question, but I'm not sure if it's one that the WHATWG can answer? I do know that Firefox 2 already implements the Storage spec. Info on that here: http://developer.mozilla.org/en/docs/DOM:Storage I wasn't able to find any docs that describe the Storage security model used in Gecko, so I ran a few tests. What I found was that any attempt to access globalStorage[''] or globalStorage['com'] from the context of a website resulted in a security error. You can try the test for yourself here: http://java.dnsalias.com/temp/storage.html After loading the page, open the Javascript Error console. You should see a security exception listed. I presume that the restrictions are relaxed for signed pages as well as those that are run at a higher privilege level. (e.g. XULRunner apps.) Is there a document somewhere outlining the actual benefits of this feature, even as potentially restricted? The specification has this explanation: Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the clientside for performance reasons. And it's not just performance reasons. If I wanted to work on a Google Spreadsheet on a plane, for example, offline caching of the data would allow me to continue my work without an internet connection. Then when I reconnect to the internet and load the document, the client would sync its stored changes with the server. My understanding is that this is Google's justification for their new Gears product. Which is basically the same as the WHATWG Storage + Database specifications, but with auto-sync and an incompatible API. Thanks, Jerason
[whatwg] Potenial Security Problem in Global Storage Specification
Hello All!
This is my first post here, so apologies in advance if I'm not quite up on
the list etiquette.
I was just comparing the Storage API with that of the Google
Gearshttp://gears.google.com,
and something jumped out at me. According to the spec, browsers should allow
a webapp to store data in the globalStorage object with no domain attached.
(i.e. globalStorage['']) This is intended to allow data to be shared across
all webpages.
My concern is that this poses a problem for the user's privacy. Let's say
that I'm an Evil Advertisement site. It is in my interest to penetrate the
user's veil of privacy and determine which pages they visit. I've
traditionally used cookies for this, but the browser makers foiled my
attempts by allowing cookies to only be accepted from the originating site.
But thanks to the new globalStorage API, I can store a Unique ID in the
user's browser, then use Javascript to retrieve it every time they download
one of my ads.
Here's some rough psuedo-js to demonstrate how it might work:
script
if(!gloabalStorage[''].evilbit) gloabalStorage[''].evilbit = createUUID();
var createUUID()
{
//return a unique identifier using a random algorithm.
}
var displayEvilAd(type)
{
document.write('img src=http://www.eviladagency.com' +
'/getAdvertisement.asp' +
'?type=' + type +
'tracking=' + gloabalStorage[''].evilbit+'');
}
/script
...
scriptdisplayEvilAd(banner);/script
Is there something I'm missing that would prevent this?
Thanks,
Jerason Banes
Re: [whatwg] Potenial Security Problem in Global Storage Specification
On Thu, 31 May 2007, Jerason Banes wrote: I was just comparing the Storage API with that of the Google Gearshttp://gears.google.com, and something jumped out at me. According to the spec, browsers should allow a webapp to store data in the globalStorage object with no domain attached. (i.e. globalStorage['']) This is intended to allow data to be shared across all webpages. My concern is that this poses a problem for the user's privacy. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
