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 versions
Re: [whatwg] href on any element
On Sat, 26 Aug 2006, Keryx webb wrote: Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? It's been mentioned, mostly in passing. The biggest problem with this feature is that some UA vendors have indicated that they are strongly opposed to overloading every element as being a link. It isn't always clear what it would mean, either (consider col href=, or optgroup href=). Generally, overloading a single element to do multiple tasks leads to bugs. Consider, for instance, object, which has been overloaded to do a wide variety of different things (plugins, images, subdocuments, etc). It is one of the most poorly implemented parts of HTML4. Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. Turning a href=http://www.whatwg.org/;abbr title=Web Hypertext Application Technology Working GroupWHATWG/abbr/a into abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. It's arguably a very minor improvement, but probably not worth the huge specification and implementation cost. Certainly there are bigger bang for the buck improvements that can be made. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] href on any element
Keryx webb wrote: Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. What are the perceived benefits that make it such a killer feature? abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. Theoretically, for XHTML, you could use XLink and write this (assuming the appropriate namespace is declared) abbr xl:type=simple xl:href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr But my tests with Firefox showed that, even though it supports simple XLink links for generic XML, that doesn't work for XHTML elements. -- Lachlan Hunt http://lachy.id.au/
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] href on any element
Ian Hickson wrote: It isn't always clear what it would mean, either (consider col href=, or optgroup href=). If the feature were to be added to Web Apps 2.0 (or other future spec) I think it would be sensible to limit it to inline, non-interactive, non-empty elements (e.g. abbr, em, strong, etc.) and a few other selected elements (e.g. li and td). It should not apply to elements like col, br, hr, input, select, etc. It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
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 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 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. 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. They can use it if they want. It just won't be secure. This is true regardless of how we design the API, since the Web server can insert arbitary content into their site. 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? I'm just stating a fact of life. If you want a secure data storage mechanism, you don't host your site on a system where you don't trust the hosting provider. 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. I think we should change the spec once the list is ready, yes. This isn't yet the case, though. In the meantime, I don't think it's wise for us to restrict the possible security solutions; a UA vendor might come up with a better (and more scalable) solution. 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. 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
Re: [whatwg] href on any element
On Mon, 28 Aug 2006, Anne van Kesteren wrote: On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ...or the currently non-conforming: a href= h2.../h2 p.../p /a We could make it conforming, I guess. The parser already supports it to some extent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
