Re: Push API change for permissions UX
On Sat, Oct 25, 2014 at 11:42 PM, Jake Archibald jaffathec...@gmail.com wrote: This discussion is about how often push may be processed silently (without showing a notification), not if a push notification may *only* show a notification. Ok. I think this comes back to the old problem of that different UAs have different UIs and that it's hard to create a single spec to cover them all. The use case sounds reasonable to me, but I'm not sure if mozilla has plans to implement anything similar. I'll defer to other people working on push. / Jonas
Re: Push API change for permissions UX
This discussion is about how often push may be processed silently (without showing a notification), not if a push notification may *only* show a notification. The latter was shown to be insufficient in the other thread. On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore owe...@google.com wrote: I think it might make sense to ask for permission to display notifications/UI at the same time as you ask for permission to run in the background. I hope the above explains why we believe that while some sites may want to ask for both permissions, they should be able to say to the user Hey, I want to send you notifications, without saying Hey, I want to run in the background whenever I want for any reason. I suggest that if we attempt to solve this use case, that we do it by adding the ability to send push messages that directly create a notification, without waking up a SW. There's recently been a separate thread about that. / Jonas
Re: Push API change for permissions UX
Hi All - my name is Owen and I recently joined the Chrome team. Taking a step back, we believe users have control such that they can permit a site to send them notifications (or notify them of an event using other UI) without permitting it to run arbitrarily in the background without their knowledge. The Notification API permission alone isn't sufficient for the I want notifications from this site use case since we want this to work after the page is closed and also because some browsers kill tabs in the background when a user hasn't visited them recently, so this also fails for foreground notifications on mobile. Hence we would like the 'user-visible' permission state so users can grant the permission to receive push notifications independently of background sync push use cases. I think it might make sense to ask for permission to display notifications/UI at the same time as you ask for permission to run in the background. I hope the above explains why we believe that while some sites *may *want to ask for both permissions, they should be able to say to the user Hey, I want to send you notifications, without saying Hey, I want to run in the background whenever I want for any reason. When a developer optionally commits to userVisibleOnly:true we propose to only ask the user about receiving notifications and not full push, which we believe will increase adoption since users are more likely to accept this less scary permission. Browser vendors can then decide exactly how they wish to notify users of sites which violate their commitment. In Chrome's case we are planning to show a notification after the service worker finishes handling the push in the case that it didn't show a notification. That said, due to special cases like loss of network after the push message was received etc, we plan to allow a very small number of pushes to not result in a notification so as to minimize annoyance for users. 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? I hope the problem is now clear. If sites want the unrestricted push they can still ask for it. Also note browser vendors can ask the user for the unrestricted permission when the restricted one is requested if they don't want to use to distinguish between the notification and sync use cases. This change would just let vendors like Chrome allow users to grant permission for push to be used for different use cases independently, increasing user control.
Re: Push API change for permissions UX
On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore owe...@google.com wrote: I think it might make sense to ask for permission to display notifications/UI at the same time as you ask for permission to run in the background. I hope the above explains why we believe that while some sites may want to ask for both permissions, they should be able to say to the user Hey, I want to send you notifications, without saying Hey, I want to run in the background whenever I want for any reason. I suggest that if we attempt to solve this use case, that we do it by adding the ability to send push messages that directly create a notification, without waking up a SW. There's recently been a separate thread about that. / Jonas
Re: Push API change for permissions UX
On 23 October 2014 23:29, Martin Thomson martin.thom...@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 notification). 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 tracking. 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. Thanks, John [1]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
Re: Push API change for permissions UX
On 24 October 2014 09:09, John Mellor joh...@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.
Re: Push API change for permissions UX
On 22 October 2014 20:55, Jonas Sicking jo...@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.thom...@gmail.com wrote: On 22 October 2014 11:02, John Mellor joh...@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
Re: Push API change for permissions UX
On 23 October 2014 04:10, John Mellor joh...@google.com wrote: 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? Yes, it increases the cost in terms of battery consumption and user annoyance for push messages. Both of which we strive to minimize. You might claim that the app needs to take responsibility for this, but I'm less certain. It means that important features that provide these measures (do not disturb, more contextual event filtering) are not available to applications by default. 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. Or good accounting and reporting (see various activity monitors on different operating systems that account for all sorts of resource usage, or you could generate simple notifications like: this app is burning your battery/network, turn it off?)
Push API change for permissions UX
Hi folks,
Based on our UX studies for Chrome, we’ve found the clearest way to do
permissions UX for the Push API will be to have one prompt[1] that grants
both full push messaging and background sync[2], and a separate prompt[3]
that grants notifications plus a restricted form of push where each push
event fired on the SW must trigger user-visible UI. This is because
notifications without push are fairly useless on mobile.
(The precise definition of a user-visible UI change would probably be
something like: show a notification/popup, unless a notification/popup was
already showing or the browser is the foreground app and a same-origin page
is the foreground tab.)
Obviously interop is crucial here: developers should be able to write code
that works across browsers, whether or not those browsers use the same
approach to permissions UX.
Accordingly, we propose adding an optional dictionary to the Push API's
register method:
PromisePushRegistration register(optional PushRegisterOptions options);
dictionary PushRegisterOptions { boolean userVisibleOnly = false; };
If a developer passes {userVisibleOnly: true} they commit to triggering a
user-visible UI change on every push.
Browser vendors that don't want to distinguish between the two policies
would presumably grant the full API anyway at this point. Hence we should
probably also extend PushPermissionStatus with a new grantedUserVisibleOnly
value so developers can use the hasPermission method to detect what state
they are in:
enum PushPermissionStatus { granted, grantedUserVisibleOnly, denied,
default };
Since we're more confident about the permissions UI for user-visible push,
and we think it's a useful standalone subset, we'd likely ship that part
first (initially rejecting any registrations which didn't pass
{userVisibleOnly:
true}).
But we're still very much committed to full push, and shipping that next
would be our top priority.
Thanks,
John et al
[1]: e.g. “origin.com wants to periodically update in the background so it
works better offline”
[2]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
[3]: e.g. “origin.com wants to send notifications after the page is closed”
[4]: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0008.html
