W3C home > Mailing lists > Public > public-web-notification@w3.org > July 2012

Re: renamed iconUrl to icon

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Jul 2012 02:05:47 -0700
Message-ID: <CA+c2ei9BmeoKn1NKakzCc_Gq7UMiBYmq6h=m9=W0tKW1cfvMUQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Web Notification WG <public-web-notification@w3.org>
On Mon, Jul 9, 2012 at 3:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Since implementations are still somewhat flexible I renamed iconUrl to
> icon so we can reuse it in a future version for passing e.g.
> HTMLCanvasElement objects.

While looking at implementing notifications we have run in to a pretty
serious issue, specifically around icons.

1. It's not possible to specify icons of different sizes. For example
specify 32x32, 64x64 and 128x128 icons. This would be nice in order to
use the same notification API on large desktop screens as well as
small mobile screens.

2. A website can see if the user is displaying the notifications by
checking if the server is pinged when the notification API is called.

3. The fact that icons and titles can be set on a per-notification
basis makes it very easy to trick the user into thinking that a
notification is coming from someplace other than where it's coming.
For example it's very easy for a website to create a notification with
the facebook icon and a "Facebook" title to trick the user into
navigating to a phishing website. This is especially true once
facebook starts using the notification API. Hence as things stand,
this creates a disincentive for websites to start using notifications.
We can somewhat easily fold the title into the body by making the
notification body something like "title + ': ' + body". However we
can't do the same thing with the icon.

Some of these issues has become worst once we started experimenting
with server-side push messages
(https://wiki.mozilla.org/WebAPI/PushAPI), but they are definitely
present even in the current notification API.

One way to address all of the above problems is to require that an
icon URL is specified when the requestPermission function is called.
That way multiple URLs, and the implementation can display the icon
when the permission is requested, meaning that the user can review the
icon that will be used at the same time as the permission grant is
happening. It also allows the implementation to download all icons up
front, meaning that no network requests has to happen when a
notification is displayed.

However this is a pretty big change to the API which we realize is problematic.

How have other implementations dealt with the problems described above?

/ Jonas
Received on Tuesday, 10 July 2012 09:06:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:14 UTC