- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 24 Oct 2014 09:46:44 -0700
- To: John Mellor <johnme@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
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