Re: renamed iconUrl to icon

On Tue, Jul 10, 2012 at 9:14 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 10 Jul 2012, Jonas Sicking wrote:
> >
> > 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.
>
> The ideal permission UI, IMHO, is one where the first time a site pops up
> a notification, it is constrained to appearing within its own frame (i.e.
> can't do anything more than it could do anyway with a positioned <div>),
> and somewhere on that notification is a button that "pops out" the
> notification to the system level, after which notifications from that
> origin can go to the system level (and similarly a button on the popped
> out notifications can revoke this permission).
>

We've discussed this approach in the past, and my concern continues to be
that this really makes for a sub-optimal user experience for things like
Gmail. In the case of gmail, we don't want to display notifications until
new emails come in, so you have this clumsy experience where you either
have to generate a dummy "click here to pop out this notification"
notification when the user enables the notification feature, or else when
the first email notification comes in, the user won't see it because it's
displayed in-frame. In the Gmail case, the site *already* has user
affordance to let the user know that new mail has arrived - also providing
a redundant in-frame notification is actively harmful to the user
experience.


>
> We could solve the spoofing icon problem by making this permission be
> scoped to the specific icon being displayed -- whenever the icon changes,
> either because its URL changed or because the image at that URL changed,
> then you implicitly cancel the permissions grant.
>

IMO, it's a mistake to rely on an icon to identify the source of a
notification for a huge number of reasons - as mentioned previously, sites
want to use multiple icons for things like "who sent me this chat message"
or "what type of notification is this - email, chat, calendar reminder,
etc". Also it's not clear to me that icons for different sites are
different enough to reliably differentiate between the sources for all
users (this is even leaving aside the accessibility issue for users with
visual impairments or devices who can't support visual icons). The point of
the icon is not authentication of the source, so let's please not try to
make it serve that purpose.


> (With this model there's no point having a requestPermission() method, of
> course. In general I would consider any API that has an explicit "request
> permission" step to be rather fundamentally missing the point of the Web's
> security model.)
>

Perhaps. Personally, I'm of the opinion that as we extend the capabilities
of web apps to support new functionality like registerProtocolHandler() and
notifications, we are finding that a one-size-fits-all implicit permissions
model is no longer sufficient.


>
> Regarding the multiple icons issue, I recommend an approach similar to
> image-set() in CSS, srcset="" in HTML, or <link rel=icon sizes> in HTML,
> depending on what the exact requirements are.
>

Is there currently a JS API that accomplishes something similar whose form
we could mimic?


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>