Re: Push API change for permissions UX

On 22 October 2014 20:55, Jonas Sicking <jonas@sicking.cc> wrote:

> However I don't think that it makes sense for apps to commit to
> displaying UI when there's an incoming push. I'm not sure what problem
> that would solve?


It means the user is aware of incoming pushes, which alleviates two
concerns:

1. Geoip tracking: an app that sends silent push messages which trigger
network fetches might be able to infer the user's location history based on
the IP addresses of their WiFi routers, cellular masts, etc. Web pages
loaded in tabs can of course already do this unless you use an anonymizing
proxy, as can native apps on all OSes, and sadly it's very hard to explain
this risk to users; but at least for open tabs the user has some awareness
that these pages are active, and more importantly can close them.

If an app (almost) always shows user-visible UI when handling push
messages, at least the user will have some awareness that stuff is going on
in the background (and unless the UI shown by the app is useful, the user
is likely to revoke its push permission).

2. Resource usage: apps handling silent push messages might expend large
amounts of battery or data (or frequently kick out other apps through high
peak RAM usage), without necessarily being useful to the user.

If instead an app (almost) always shows user-visible UI when handling a
push message, this will inherently limit the frequency of push messages (as
we intend on making it very easy to revoke push permission from
notifications and any future user-visible UI, so that developers are
incentivized not to spam users).


> It seems like in many cases you need to run client
> side code in order to determine if UI should be displayed or not. For
> example the user might be in a "don't disturb me mode" or have
> configured a VoIP app to blocklist a certain caller from calling.
>

Yes, agreed. The idea is that apps which are able to make the commitment
would only trigger one permissions prompt; apps which cannot commit to
userVisibleOnly would still be allowed (except temporarily in Chrome if we
ship userVisibleOnly push before shipping full push), but would simply
trigger an additional doing-stuff-in-the-background permission prompt. In
many cases, triggering the additional permission prompt may well be a
worthwhile trade-off for developers in order to provide a net better user
experience.

On 23 October 2014 04:23, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 22 October 2014 11:02, John Mellor <johnme@google.com> wrote:
> > a restricted form of push where each push event fired on the SW must
> trigger
> > user-visible UI.
>
> How would that work? Is the idea that there would be a default
> notification that the SW could alter the contents of (perhaps), but
> not prevent or indefinitely delay?
>

Exactly. The current thought is that if a site opts in to userVisibleOnly
pushes, then if it doesn't show user-visible UI (initially a notification)
by the end of the event.waitUntil on almost (sporadic errors would be
forgiven) every incoming push message (not counting times where the web app
is in the foreground, or user-visible UI was already showing, or has been
shown recently), then the UA would show a default notification. Developers
would of course be strongly incentivised to show their own UI instead,
since its content would always be more relevant than the default
notification, hence users would be less likely to revoke the site's push
permission.

(We had previously discussed heavy throttling of pushes that don't show
user-visible UI, but discarded that as it would make push
unreliable/inconsistent.)

I'm not convinced of the virtue of something like that.  It attaches a
> specific kind of penalty to the use of push that might discourage its
> use, but I'm not sure that it creates the right sort of disincentive.
>

Can you elaborate? This would attach no penalty to developers who don't opt
in (at the one time cost of an additional permission prompt); and as I
explained above, developers who do opt in would indeed be incentivized to
always show user-visible UI. Are you concerned that this is not the right
thing to be incentivising?

Thanks,
John