W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

Re: Push API change for permissions UX

From: John Mellor <johnme@google.com>
Date: Fri, 24 Oct 2014 17:09:24 +0100
Message-ID: <CAG_kaUaMJoZVqbsA6haGecHKhYN-U-HJ5iD26O_ypryixEBCQw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
On 23 October 2014 23:29, Martin Thomson <martin.thomson@gmail.com> wrote:

> It means that important features that provide
> these measures (do not disturb, more contextual event filtering) are
> not available to applications by default.

System-wide do-not-disturb would still work (for example in Android Lollipop
<http://www.androidcentral.com/android-l-preview-do-not-disturb-mode> any
non-whitelisted notifications shown by apps during do-not-disturb mode are
silent and hidden away behind a single unobtrusive "X notifications hidden"

I agree that app specific contextual event filtering can sometimes provide
a better user experience, and would indeed require full push permission;
these apps should just go ahead and request full push permission (though if
the user grants push notifications [Notification.requestPermission] then
denies silent background execution [pushRegistrationManager.register
without userVisibleOnly], the app might still benefit by being able to fall
back on unfiltered push notifications [pushRegistrationManager.register
with userVisibleOnly].

I'd like to find better ways of dealing with this problem.  This
> approach seems like more of a cop-out to me.  I'm seriously
> jet-lagged, so only two ideas spring to mind, I'm sure you can find
> some more if you set your mind to it: Usage budgets might be applied
> to various resources, after which a SW is activated less often.

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.

Or good accounting and reporting (see various activity monitors on
> different operating systems that account for all sorts of resource
> usage,

Yes, we want clear usage tracking UI as well. But realistically, only power
users monitor such things; on Android and iOS, that still provides a useful
feedback mechanism via app store reviews, but users don't normally visit
websites via an app store. And again, this doesn't really mitigate geoip

> or you could generate simple notifications like: "this app is
> burning your battery/network, turn it off?")

We considered that as well, but to mitigate geoip tracking, we'd have to
show this warning for every few pushes that don't show user-visible UI, and
at that point, it's better for the app to just always show a notification
of its choice (which will at least be slightly useful) than for the UA to
keep showing an annoying warning.


[1]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
Received on Friday, 24 October 2014 16:10:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC