- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 8 Jun 2010 13:17:32 -0700
On Tue, Jun 8, 2010 at 12:26 PM, Atul Varma <avarma at mozilla.com> wrote: > On 6/8/10 10:47 AM, Adam Barth wrote: > On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen <hsivonen at iki.fi> wrote: > "Aaron Boodman (?)" <aa at google.com> wrote: > If we add paths to the mix, we can do this. Applications on the same > origin can circumvent it if they want, but why would they? SOP > already > guarantees that apps on the same origin are friendly and cooperate > with each other. That doesn't mean it isn't useful for the UA to know > which one is which. > > I have to wonder why Google needs the browser team to solve this instead of > having the Reader team relocate their stuff to reader.google.com (like > maps.google.com is located already). > > Last time I asked about this, the answer I got was that there were > performance and branding considerations around whether to host an app > on www or on a dedicated subdomain. For security, putting each app on > a separate subdomain is a win. > > Adam > > For what it's worth, I think that giving developers tools to easily define > more granular security mechanisms without resorting to subdomains is a win > in terms of usability, as it's quite difficult to figure out how to create > subdomains and do virtual hosting--to say nothing of doing it over SSL. > > That said, introducing a brand new mechanism for security on top of SOP does > seem like it might make the security landscape more complex as a whole, and > thereby potentially more vulnerable. Yes, doing this correctly is quite subtle. I'd pitch the feature more as developer connivence rather than for security. Apps that are hosted in the same origin need to trust each other. One analogy is cookie paths, which provide no additional security but are quite useful for developers. Adam
Received on Tuesday, 8 June 2010 13:17:32 UTC