Re: Push API change for permissions UX

On 24 October 2014 09:09, John Mellor <johnme@google.com> wrote:
> For background sync[1], such a throttling approach would be ideal, as there
> is no expectation of timeliness. But push is different: users can come to
> depend on timely delivery of push notifications, and sufficiently
> heavy-handed throttling would introduce unreliability/inconsistency -
> especially if the goal is to mitigate geoip tracking, since only a handful
> of push messages might be enough to locate e.g. your home and work.

Isn't that a perfect disincentive?  Apps learn that abusing push leads
to a terrible user experience.  And we can mitigate that by using the
prioritization mechanisms that push provides, allowing apps to
identify less important messages that can be dropped first.  The rules
need not be complex, for example: one high priority message per user
interaction or per hour (whichever is shorter), 3 medium priority
messages in the same time, and 5 low priority messages; more may be
permitted but not guaranteed.

I don't share your concern with respect to geoip tracking; or at least
I don't give it the same amount of weight you seem to.  If you permit
an application to run in the background, then this is one of the many
things the app will be able to do.  The same sort of tracking is
enabled by having tabs left open.

> app to just always show a notification of its choice (which will at least be slightly useful)

I can think of nothing worse than something that forces the creation
of a notification.  Notifications consume user attention, of which
there is (qualitatively) far less of than battery Joules or network
bytes.

Received on Friday, 24 October 2014 16:47:20 UTC