RE: In what circumstances is "delayed execution" acceptable on the web?

There have been a few examples lately (Media Streams, Beacons, Geofencing, Presentation etc.) where  the Permissions API was raised as a good place to address privacy concerns in a generic way. They all seem to revolve around combining the need  for privacy/security with simplicity and ease of use. Also, I attended a meeting at Mozfest in London at the weekend where the was a deal of agreement about the need for an expiry on permissions and having a more universally recognisable UI for it. Where would be the best forum to discuss this, given that many people with other than security concerns might want to put their oar in? Maybe the PING could have a role here?

 

From: Jake Archibald [mailto:jakearchibald@google.com] 
Sent: 11 November 2015 10:12
To: WebAppSec WG <public-webappsec@w3.org>
Cc: Anne van Kesteren <annevk@annevk.nl>
Subject: In what circumstances is "delayed execution" acceptable on the web?

 

Some new web APIs allow for data to be transmitted and/or JavaScript to be executed beyond the life of a window. Specifically:

 

 <http://w3c.github.io/beacon/> http://w3c.github.io/beacon/ - allows the POSTing of data and "The User Agent should make a best effort attempt to eventually transmit the data", "including making multiple attempts to transmit the data in presence of transient network or server errors".

 

The intent here is to allow things like analytics pings to succeed even if the tab is closed before completion, or the user has zero connectivity at the time.

 

 <https://wicg.github.io/BackgroundSync/spec/> https://wicg.github.io/BackgroundSync/spec/ - which is a lower-level version of the above, providing a "sync" event in the service worker when the user has connectivity (either now, or later). The sync event is allowed to fire when the user has no windows open to the origin. The "sync" event will only fire once per registration, the exception being if the developer indicates failure of a sync, meaning the user agent may reschedule the sync with some form of delay, or abandon the sync altogether.

 

The intent here is for all non-optional server communication to be done as part of the sync event, so it survives navigation & connectivity issues. Communication includes sending an email or chat message, or updating preferences on a site.

 

Neither of these features require up-front user permission, although we intend on giving background sync a default-on permission that can be revoked. In ideal situations, both of these APIs will do what they need to do during the lifetime of the page. Background sync places limitations on execution time and retries of sync events, to prevent an evil developer creating infinite background execution.

 

Anne has raised an issue on beacon  <https://github.com/w3c/beacon/issues/14> https://github.com/w3c/beacon/issues/14 - given the potentially long delay between the user interacting with the origin, and the data sending, does this reveal information about the user they may not expect, eg rough location from their ip. Anne's suggested solution is to cancel beacons if the network changes from the point of registration. This would diminish the usefulness of beacon, and scupper one of the primary use-cases of background sync (queuing things to send while offline).

 

So we're looking for some advice. Is it reasonable to allow beacon/background sync to perform a single, restricted background action after the user has interacted with the origin. If not, are there obvious restrictions that could be put in place that retain the intent of the APIs?