- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Fri, 22 Oct 2010 10:38:01 +0200
- To: public-web-perf@w3.org
On Fri, 22 Oct 2010 09:59:07 +0200, Zhiheng Wang <zhihengw@google.com> wrote: > On Fri, Oct 22, 2010 at 12:29 AM, Sigbjørn Vik <sigbjorn@opera.com> > wrote: > >> My thought is that using a cookie domain will be of great benefit to >> developers, and that it has little real-life negative impact on >> websites. Do >> you foresee any practical problems doing this? >> > Different sub-domain is only part of the story. > Origin<http://www.w3.org/TR/html5/origin-0.html> refers > to (schem, host, port), so different ports and schemes could be potential > risk as well. True, conceptually and security wise, we can consider them as subdomains to make things easier. > It's a good point that they are sharing the same cookie already, so the > additional negative impact by relaxing the SOP is at most incremental. Note that cookies can be shared, but that does not happen automatically, and it is possible to take extra care to create safe cookies even on such a subdomain (some extra code is needed). It is not possible to have safe cookies across ports though, and only in one direction between schemes (using the secure flag). So cookies are somewhat more safe than Timing information would be, but also carry a lot more information. > I actually have a bit more thought after the previous email... The SOP > doesn't seem to guarantee absolute safety either, e.g., some web services > are already hosting UGC on the same domain but a user-specific path like > some.domain.com/mystuff. Arguably though, some.domain.com *should* > cover any potential security issues. This model is typically used to separate documents, not web applications. The User Generated Content is typically limited to whitelisted HTML and CSS, rarely server side scripting. Universities and companies often use this model too, and sometimes do allow scripting - though such accounts are rarely used for full fledged applications. Cookies has a security model for this too, though practically unused in the wild. > Don't make me wrong. Cookie domain is also my favorite and I tend to > agree that its benefit is greater than other concerns. :-) I just feel > like bringing > up the point for discussion. And if we all agree on using the cookie > domain, > we will go with it. Agreed, this would need explicit approval from all before deciding for it. In some ways, deciding to use cookie domain is equivalent to taking the another step towards declaring that "For Web applications to get full security from browsers, they need to run in a trusted cookie domain." Browsers have already taken several steps towards this apart from cookies and document.domain, the cookie domain might be highlighted in the address bar and domain sorting in lists might be based on the cookie domain. -- Sigbjørn Vik Quality Assurance Opera Software
Received on Friday, 22 October 2010 08:38:21 UTC