[webkit-dev] Notifications API
Drew Wilson
atwilson at google.com
Thu May 28 12:21:22 PDT 2009
The problem I have with defining permissions on top of anything other than
origin, is that every other aspect of HTML security seems to hang on the
venerable same-origin policy.
Allowing an "application" under "foobar.com/trusted" to have different
permissions from an application under "foobar.com/untrusted" seems
dangerous, given that pages under foobar.com/untrusted can:
1) Share storage, cookies, and workers with foobar.com/trusted
2) Load foobar.com/trusted in an iframe and call into its javascript, inject
its own script, etc.
I agree that it has implications for things like geocities where pages from
different authors share the same domain, but that seems inherent to the
general model of the web - you can't, in general, do anything interesting on
the client if you don't trust all of the content served from your origin.
-atw
On Thu, May 28, 2009 at 12:03 PM, Michael Nordman <michaeln at google.com>wrote:
> Its a comfortable notion that an origin == application, but the
> reality is that a single site can host multiple applications, and that
> an individual application can span multiple origins.
>
> We can probably do better than imposing the origin == application
> model on everybody.
>
> The only organizing principles we have for web permission granting are
> at the page level or at the origin level. Neither of these is
> particularly satisfying.
>
> I think end users would like to see things in terms of "applications".
> The web provides no means of identifying which pages/origins should be
> considered part of an application. If there was a sense of
> "application'ness", we could apply permissions to them... which is a
> desirable goal i think.
>
> So how to establish a sense of application'ness?
> <html application = urlToAppIdentifyingFile>
>
> If a page that doesn't identify itself start requesting permissions...
> fallback on the origin = application model.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090528/e769b1a3/attachment.html>
More information about the webkit-dev
mailing list