Re: renamed iconUrl to icon

On Tue, Jul 10, 2012 at 2:05 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

Why is this a problem?  The API provides a "show" event for the website to
know that the notification has been displayed, so the information is
already there.

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?
>

I agree this is a concern.  However I don't think we want to restrict a
website to using a single icon for all their notifications, which would be
too limiting.  For example Gmail chat notifications use the profile photo
of the person you are chatting with as the icon for each notification -- an
unlimited number of icons for one site.

Rather than being a problem with the icon, it's a problem with not making
clear the source of notifications.  With the experimental Chromium
implementation, this was one of the main reasons we created our own
notification display system: so that the true origin of the notification
could be shown in a part of the display that's not controlled by the
website.

We could change the spec to at least describe this problem -- user agents
could include the origin in the message in a way that is appropriate for
the platform.  For some platforms, this might mean appending "(from
www.xyzsite.com)" at the end of the body, although it's not as reliable as
putting that information in browser-controlled UI.


>
> / Jonas
>
>