Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a Last Call Working Draft of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web SQL Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ This CfC satisfies the group's requirement to record the group's decision to request advancement to LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: Opera is not convinced that webdatabase is sufficiently clear and supported to be a last call draft. However we support the publication of the other drafts mentioned as last call working drafts. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
Charles McCathieNevile wrote: On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a Last Call Working Draft of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web SQL Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ This CfC satisfies the group's requirement to record the group's decision to request advancement to LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: Opera is not convinced that webdatabase is sufficiently clear and supported to be a last call draft. However we support the publication of the other drafts mentioned as last call working drafts. My personal position is the same as the above. While I support all the other specifications proceeding to LC, I think that more work needs to be done in order for webdatabase to proceed to the next step. Punting to a particular implementation (in this case, a version of SQLite) as a normative part of a specification is unprecedented in standards that this WG has released. -- A*
Re: CORS versus Uniform Messaging?
On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow art.bars...@nokia.com wrote: Ideally, the group would agree on a single model and this could be achieved by converging CORS + UM, abandoning one model in deference to the other, etc. Can we all rally behind a single model? I'm not sure that we want to. My impression is that both models have their advantages and risks. They basically implement two different security design philosophies, and I'm not confident that there is a winner, or that we can correctly pick one. I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. CORS seems easier in the simpler cases when no website acts as a deputy. UM seems less likely to cause confused deputy problems when a website acts as a deputy and receives urls from third parties (either by fetching them over the network, or by having third party code running in their domain using something like caja). I also agree with Jonas on these points. What might make the most sense is to let the marketplace decide which model is most useful. The most likely outcome (in my mind) is that they are optimized for different use cases and will each find their own niche. Adam
Re: CORS versus Uniform Messaging?
On Dec 12, 2009, at 7:17 PM, Adam Barth wrote: On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow art.bars...@nokia.com wrote: Ideally, the group would agree on a single model and this could be achieved by converging CORS + UM, abandoning one model in deference to the other, etc. Can we all rally behind a single model? I'm not sure that we want to. My impression is that both models have their advantages and risks. They basically implement two different security design philosophies, and I'm not confident that there is a winner, or that we can correctly pick one. I agree with Jonas. It seems unlikely we'll be able to design-by-commitee around a difference in security philosophy dating back to the 70s. CORS seems easier in the simpler cases when no website acts as a deputy. UM seems less likely to cause confused deputy problems when a website acts as a deputy and receives urls from third parties (either by fetching them over the network, or by having third party code running in their domain using something like caja). I also agree with Jonas on these points. What might make the most sense is to let the marketplace decide which model is most useful. The most likely outcome (in my mind) is that they are optimized for different use cases and will each find their own niche. I agree with Jonas and Adam as well. I think both models have their use cases. A few specific additional thoughts: - Something like UM seems pretty important, probably essential, for running guest code if you are relying on origin-based security at all to protect some of your resources. - UM may be sufficient for some patterns of cross-domain messaging, but is not necessarily the most convenient. - UM isn't strictly necessary for multi-party messaging interactions; CORS works fine too, as long as you don't rely on the Origin header as the sole security mechanism. - Building a shared-secret-based defense for the kinds of semi- public resources that Hixie has been discussing is likely to be overkill for the level of security actually required, to the point that the risk of making complexity-induced implementation mistakes may be greater than the risks you face from basing your security on origin checks. - In many cases (not including guest code running in something like Caja, but including one-party form submission, simple two-party cross- domain communication, and complex multi-party communication) combining a secret token / shared secret based defense with an Origin check is likely to be more secure than either alone. I would even go so far as to make the following claims: (a) Given a reasonably secure shared-secret-based system, then other things being equal, adding Origin checks will not make your system less secure. (b) In many cases, adding Origin checks to such a system may make it more secure, in the sense that it is robust against more kinds of unexpected failures. I'd be happy to expand on the last point in a separate email if anyone cares to see some more detail and some examples. Regards, Maciej
