Re: [whatwg] Persistent storage is critically flawed.
Ian Hickson 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. Compared to cookies storage seems less safe: the default cookie access is to the setting host only, a case that does not even exist with global storage. To publish a cookie to a wider family of hosts the setting host must explicitly set a domain on the cookie. (Ditto path, but that turns out to be illusory protection due to the DOM same-origin policy). Web-app developers aren't complaining they can't read cookies they need from sub-domains, they're complaining when private cookies leak or when they're fooled by a cookie injected at a higher domain (e.g. .co.uk cookies). Let me throw out two alternatives for providing "private" persistent storage, neither of which complicates the API (though may complicate the implementation). The first piggy-backs on the domain vs host cookie concept as applied to entire storage objects. Each host would have a private persistent storage object that could only be accessed by that host; shared objects would need to be explicitly named. There should be a difference in how the two types are named a) using the cookie domain nomenclature to indicate the similar concepts "www.foo.com" could represent the host storage only accessible to that host, and a leading '.' in ".www.foo.com" would represent a shared storage area. You could argue that people will forget the dot as they do with cookie domains, but they only do with cookies because UA's let them get away with it. b) another choice would be to make globalStorage[''] magic and mean the private storage for the current host. No one is going to implement universally accessible storage (the spec even recommends against it), you could just take that out of the spec and reuse it for this. All other named areas would be shared as described by the spec. The second alternative would be to have private and shared storage items within a single storage area. I know you weren't keen on adding another attribute like "secure", what if instead there was a convention such as "keys which start with an underscore are private and can only be accessed if the current host matches the storage area domain". My personal preference is for 1b -- use globalStorage[''] as the non-shared storage area. -Dan Veditz
Re: [whatwg] Persistent storage is critically flawed.
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
Re: [whatwg] Persistent storage is critically flawed.
On Mon, 28 Aug 2006, Shannon Baker wrote: > > > > This is mentioned in the "Security and privacy" section; the third > > bullet point here for example suggests blocking access to "public" > > storage areas: > > > > http://whatwg.org/specs/web-apps/current-work/#user-tracking > > I did read the suggestions and I know the authors have given these > issues thought. However, my concern is that the solutions are all > 'suggestions' rather than rules. I believe the standard should be more > definitive to eliminate the potential for browser inconsistencies. The problem is that the solution is to use a list that doesn't exist yet. If the list existed and was firmly established and proved usable, then we could require its use, but since it is still being developed (by the people trying to implement the Storage APIs), we can't really require it. > > Basically, for the few cases where an author doesn't control his > > subdomain space, he should be careful. But this goes without saying. > > The same requirement (that authors be responsible) applies to all Web > > technologies, for example CGI script authors must be careful not to > > allow SQL injection attacks, must check Referer headers, must ensure > > POST/GET requests are handled appropriately, and so forth. > > As I pointed out this only gives control to the parent domain, not the > child without regard for the real-world political relationship between > the two. Also the implication here is that the 'parent' domain is more > trustworthy and important than the child - that it should always be able > to read a subdomains private user data. The spec doesn't give the > developer a chance to be responsible when it hands out user data to > anybody in the domain hierarchy without regard for whether they are a > single, trusted entity or not. Don't blame the programmer when the spec > dictates who can read and write the data with no regard for the authors > preferences. CGI scripts generally do not have this limitation so your > analogy is irrelevant. 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
Re: [whatwg] Persistent storage is critically flawed.
On 8/28/06, Jim Ley <[EMAIL PROTECTED]> wrote: On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote: > I accept tracking is inevitable but we > shouldn't be making it easier either. You have to remember that the WHAT-WG individual is a Google employee, a company that now relies on accurate tracking of details, so don't be surprised that any proposal makes tracking easier and harder to circumvent. Well, if the WHAT-WG individual wasn't a Google employee, but an employee from Microsoft or Mozilla or Opera or any random government, would that change the above text? I don't think so. So I don't think that text is implying much, otherwise than there aren't very much 'neutral' organizations involved in writing specifications for the web. It's probably a design requirement, of course like all WHAT-WG stuff, there is no explanation of the problems that are attempting to be solved with any of the stuff, so it's impossible to really know. From: http://www.whatwg.org/specs/web-apps/current-work/#introduction2 " The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time. Cookies don't really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing. " and: " The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, 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. Again, cookies do not handle this case well, because they are transmitted with every request. " That seem to me two use cases of problems that are attempting to be solved, not? Regards, Martijn Jim.
Re: [whatwg] Persistent storage is critically flawed.
On 28/08/06, Shannon Baker <[EMAIL PROTECTED]> wrote: I accept tracking is inevitable but we shouldn't be making it easier either. You have to remember that the WHAT-WG individual is a Google employee, a company that now relies on accurate tracking of details, so don't be surprised that any proposal makes tracking easier and harder to circumvent. It's probably a design requirement, of course like all WHAT-WG stuff, there is no explanation of the problems that are attempting to be solved with any of the stuff, so it's impossible to really know. Jim.
Re: [whatwg] Persistent storage is critically flawed.
Ian Hickson wrote: This is mentioned in the "Security and privacy" section; the third bullet point here for example suggests blocking access to "public" storage areas: http://whatwg.org/specs/web-apps/current-work/#user-tracking I did read the suggestions and I know the authors have given these issues thought. However, my concern is that the solutions are all 'suggestions' rather than rules. I believe the standard should be more definitive to eliminate the potential for browser inconsistencies. Yes, there's an entire section of the spec discussing this in detail, with suggested solutions. Again, the key word here is 'suggest'. Indeed, the spec suggests blocking such access. Suggest. See where I'm going with this. The spec is too loose. There generally is; but for the two cases where there are not, see: http://whatwg.org/specs/web-apps/current-work/#storage ...and: http://whatwg.org/specs/web-apps/current-work/#storage0 Basically, for the few cases where an author doesn't control his subdomain space, he should be careful. But this goes without saying. The same requirement (that authors be responsible) applies to all Web technologies, for example CGI script authors must be careful not to allow SQL injection attacks, must check Referer headers, must ensure POST/GET requests are handled appropriately, and so forth. As I pointed out this only gives control to the parent domain, not the child without regard for the real-world political relationship between the two. Also the implication here is that the 'parent' domain is more trustworthy and important than the child - that it should always be able to read a subdomains private user data. The spec doesn't give the developer a chance to be responsible when it hands out user data to anybody in the domain hierarchy without regard for whether they are a single, trusted entity or not. Don't blame the programmer when the spec dictates who can read and write the data with no regard for the authors preferences. CGI scripts generally do not have this limitation so your analogy is irrelevant. Indeed; users are geocities.com shouldn't be using this service, and geocities themselves should put their data (if any) in a private subdomain space. Geocities and other free-hosting sites generally have a low server-side storage allowance. This means these sites have a _greater_ need for persistent storage than 'real' domains. It doesn't. The solution for mysite.geocities.com is to get their own domain. That's a bit presumptuous. In fact it's downright offensive. The user may have valid reasons for not buying a domain. Is it the whatcg's role to dictate hosting requirements in a web standard? The spec was written in conjunction with UA vendors. It is realistic for UA vendors to provide a hardcoded list of TLDs; in fact, there is significant work underway to create such a list (and have it be regualrly updated). That work was originally started for use for HTTP Cookie implementations, which have similar problems, but would be very useful for Storage API implementations (although, again as noted in the draft, not imperative for a secure implementation if the author is responsible. I accept that such a list is probably the answer, however I believe the list should itself be standardised before becoming part of a web standard - otherwise more UA inconsistency. One could create much more complex APIs, naturally, but I do not see that this would solve the problems. It wouldn't solve the issue of authors who don't understand the security implications of their code, for instance. It also wouldn't prevent the security issue you mentioned -- why couldn't all *.geocities.com sites cooperate to violate the user's privacy? Or *.co.uk sites, for that matter? (Note that it is already possible today to do such tracking with cookies; in fact it's already possible today even without cookies if you use Referer tracking, and even without Referer tracking one can use IP and User-Agent fingerprinting combined with log analysis to perform quite thorough tracking.) None of those techniques are reliable. My own weblogs show most users have the referer field turned off. Cookies can be safely deleted after every session without a major impact on site function (I may have to login again). IP tracking is mitigated by proxies and NAT's. The trouble with this proposal is that it would allow important data to get lumped in with tracking data when the spec suggests that UA's should only delete the storage when explicitly asked to do so. I don't have a solution to this other than to revoke this proposal or prevent the sharing of storage between sites. I accept tracking is inevitable but we shouldn't be making it easier either. Certainly one could add a .readonly field or some such to storage data items, or even fully fledged ACL APIs, but I don't think that should be available in a first version, and I'm not sure it's really useful in later version
Re: [whatwg] Persistent storage is critically flawed.
On 8/27/06, Shannon Baker <[EMAIL PROTECTED]> wrote: == 1: Authors failure to handle the implications of "global" storage. == First lets talk about the global store (|globalStorage['']) which is accessible from ALL domains. This is mentioned in the "Security and privacy" section; the third bullet point here for example suggests blocking access to "public" storage areas: http://whatwg.org/specs/web-apps/current-work/#user-tracking Did anyone stop to really consider the implications of this? I mean, sure the standard implies that UA's should deal with the security implications of this themselves, but what if they don't? Let's say a UA does allow access to this global storage, what would we expect to find in this storage space? Does the author really believe that this will be only used for sharing preferences between domains for the benefit of the user? Hell no! It's going to look like this: KEY VALUE adsense3wd4ghgtut9jhn kjh234kj23u4y2j34234hkj234hkj23h4k234k234 <-- Advertiser user tracking johnyizcool I Kickerz Azz!! <-- Attention freak USconspiracy 911 was an inside job. Tell everybody! <-- Political activist UScitID kh546jkh45856456h45iu6y46j45j6h54kj6h45k6 <-- Government spying GodsLove.com Warning! This user supports abortion. <-- Vigilantie user tracking Yes, there's an entire section of the spec discussing this in detail, with suggested solutions. |What possible use could this storage region ever have to a legitimate site? Especially when sensible UA's will just block it anyway? I for one do not want my browser becoming some sort of global 'grafitti wall' written on by every website I visit. Truthfully I cannot come up with a single legitimate use for the 'global' or 'com' regions that cannot be handled by per-domain storage or global storage with ACLs (see next point). Indeed, the spec suggests blocking such access. == 2: Naive access controls which will result in guaranteed privacy violations. == The standard advocates the two-way sharing of data between domains and subdomains - Namely that host.example.com should share data with the servers at 'www.host.example.com', 'example.com', and all servers rooted at '.com'. In its own words: "Each domain and each subdomain has its own separate storage area. Subdomains can access the storage areas of parent domains, and domains can access the storage areas of subdomains." My objection to this is similar to my objection to the 'global' storage space - It's totally naive. The whole scheme is based on the unfounded belief that there is a guaranteed trust relationship available between the parties controlling each of these domains. There generally is; but for the two cases where there are not, see: http://whatwg.org/specs/web-apps/current-work/#storage ...and: http://whatwg.org/specs/web-apps/current-work/#storage0 Basically, for the few cases where an author doesn't control his subdomain space, he should be careful. But this goes without saying. The same requirement (that authors be responsible) applies to all Web technologies, for example CGI script authors must be careful not to allow SQL injection attacks, must check Referer headers, must ensure POST/GET requests are handled appropriately, and so forth. Sure, one may be reliant on another for DNS redirection but that hardly implies that one wishes to share potentially confidential data with the other. As the author themselves stated there is no guarantee that users of geocities.com sub-domains wish their users data to be shared with GeoCities. Indeed; users are geocities.com shouldn't be using this service, and geocities themselves should put their data (if any) in a private subdomain space. The author states that geocities could mitigate this risk with a fake sub-domain but how does that help the owner of mysite.geocities.com? It doesn't. The solution for mysite.geocities.com is to get their own domain. The author implies that UA's should deal with this themselves and fails to provide any REALISTIC guidelines for them to do so (sure lets hardcode all the TLD's and free hosting providers). The spec was written in conjunction with UA vendors. It is realistic for UA vendors to provide a hardcoded list of TLDs; in fact, there is significant work underway to create such a list (and have it be regualrly updated). That work was originally started for use for HTTP Cookie implementations, which have similar problems, but would be very useful for Storage API implementations (although, again as noted in the draft, not imperative for a secure implementation if the author is responsible. What annoys me is that the author acknowledges the issue and then passes the buck to browser manufacturers as though it's their problem and they should solve it in any (incompatible or non-compliant) way they like. Any solution must be compliant, by definition; regarding compatib
Re: [whatwg] Persistent storage is critically flawed.
On Sun, 27 Aug 2006 19:11:17 +0700, Shannon Baker <[EMAIL PROTECTED]> wrote: > But why bother? This whole problem is easily solved by allowing data to > be stored with an access control list (ACL). For example the site > developer should be able to specify that a data object be available to > '*.example.com' and 'fred.geocities.com' only. How this is done (as a > string or array) is irrelevant to this post but it must be done rather > than relying on implicit trust where none exists. While there are serious risks associated with global storage, I don't see how replacing the global storage with arbitrary ACLs on data items will help reduce them. All those advertisers etc can store a data item accessible to "*", can't they? -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
