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
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
but that seems inherent to the general model of the web
Agreed, I'm suggesting that model can be improved upon.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Sam, I think you are right here. I'm convinced that applications should be
specific about what permissions they are asking for.
I also believe that from a UX standpoint, we will probably want to provide
the user with a single dialog that enumerates the permissions being granted,
although a given
I would prefer we limit the scope to notifications, since this is an
experimental feature at the moment. Perhaps something along the lines of
window.notifications.requestTrust(), or window.notifications.requestUse() (I
am not a huge fan of either of those function names, but you get the general
I think that makes sense for now as well.
I expect we'll get to this sort of generic permissions system in the future,
but for the time being I am adding to my current patch some methods:
// internal methods implemented by the embedder
int
Has John sufficiently addressed people's concerns about this issue? Perhaps
some of the people who previously expressed concerns in the bug could chime
in here saying whether or not they are bought in now.
We'd like to move forward on getting a reviewer on this change, but we're
not certain what
On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak m...@apple.com wrote:
On May 22, 2009, at 10:19 AM, John Gregg wrote:
Sure. We have the following plan for how to handle opt-in:
- Use of the feature by script, if permission isn't granted to the origin,
should throw an exception, not
To give the list some insight into the discussions we've had with the Chrome
UX folks:
1) We want to associate some set of enhanced permissions with a given origin
(e.g. https://mail.yahoo.com), and we want the user to be presented with a
single do you want to grant permissions to
On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.com wrote:
To give the list some insight into the discussions we've had with the
Chrome UX folks:
1) We want to associate some set of enhanced permissions with a given
origin (e.g. https://mail.yahoo.com), and we want the user to
On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.com wrote:
On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.com wrote:
To give the list some insight into the discussions we've had with the
On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.com wrote:
On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.comwrote:
On Tue, May 26, 2009 at 9:18 PM, David Levin le...@chromium.org wrote:
On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.com wrote:
On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.comwrote:
I circulated a proposal several weeks ago which specified a notifications
API for workers (desktop toasts), and the feedback was that (a) persistent
workers are still far away, (b) is a notifications api necessary given it's
basically a new window?, and (c) have we thought through the security
On Thu, 21 May 2009, John Gregg wrote:
On the security question, a substantial amount of thought has gone into
how to prevent unwanted popups (and in general how to control access to
HTML5 application features). We think user opt-in on an origin-basis is
the best policy and it's what we
Sure. We have the following plan for how to handle opt-in:
- Use of the feature by script, if permission isn't granted to the origin,
should throw an exception, not present permissions UI. So your insistent
porn site would have no effect on the user.
- A dialog box asking for permission should
Thanks Maciej for the feedback.
We are definitely concerned with making this feature resistant to abuse,
since everyone agrees we don't want to create another class of annoying or
insecure pop-ups. A good amount of thought has preceded the code, although
I probably didn't coordinate the
I'm pretty concerned about the security/spamming implications of
notifications from Workers. A lot of thought has been put into how to
make them a good feature for thoughtful, competent Web developers like
those at Google. But it seems to me that not as much thought has been
put into
Thanks for the thoughtful response. We're also concerned about many of the
same issues you've brought up below, and we've engaged in a number of
discussions with the Chrome UX team and our internal Security folks to
determine how we can best expose this functionality to the user and prevent
Hi WebKit,
I'm working on a Notifications API for Web Workers, with the idea that a
user agent could receive these from script and route them in a
platform-appropriate user-configurable way (desktop HTML toasts, Growl
calls, status bar on mobile browsers, etc.). Permission controls would be
20 matches
Mail list logo
