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 present permissions UI. So
your insistent porn site would have no effect on the user.
- A dialog box asking for permission should only appear in response
to a user gesture like a click. So in the normal case, an
application will present a user with a link "New: Desktop Calendar
Notifications available! Click here to setup." And that link will
present a prompt from the user-agent "Do you trust calendar.com?
The site wants to display notifications on your desktop. [Yes/No]"
If the user says yes, script running under that origin will have
permission to show desktop notifications.
To expose this flow, wouldn't you need a method in the API exposed to
JavaScript that requests permission for notifications, rather than
actually posting a notification? I don't see such a method in the
submitted patch. It would not make sense for a link labeled "New:
Desktop Calendar Notifications available! Click here to setup" to
actually display a notification itself, I wouldn't think.
Having a JavaScript API to request permissions, along with plumbing
through the WebKit layer to allow a WebKit embedder to suitably prompt
the user, would address most of my concerns.
- Permission should be removable through a menu which is accessible
from the notification UI itself.
Seems like this part would indeed be outside WebKit.
As proposed the permissions policy is somewhat external to WebKit,
which contains the Javascript API layer but not the actual user-
visible parts of the system including UI, permissions flow, and
filtering by origin which will be in Chromium or another user agent.
I think it implies a requirement for API that's not in the patch.
Regards,
Maciej
-John
On Thu, May 21, 2009 at 11:39 PM, Ian Hickson <[email protected]> wrote:
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 plan to do in Chromium; the WebKit
> interfaces are structured so that the policy is up to the user
agent via
> a NotificationProvider interface.
Could you elaborate on what you mean by "user opt-in"? A prompt or
"installation" step seems like a poor user experience given that any
site
could start asking for this, and we don't want users to click "yes" to
make the message go away (consider a porn site that just does "while
notifications are not allowed, try to notify").
--
Ian Hickson U+1047E )
\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _
\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--
(,_..'`-.;.'
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
