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

On Wed, 11 Nov 2015 at 22:35 Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> On Wed 2015-11-11 05:11:53 -0500, Jake Archibald wrote:
> > Some new web APIs allow for data to be transmitted and/or JavaScript to
> be
> > executed beyond the life of a window. Specifically:
>  [...]
> > Neither of these features require up-front user permission
>
> Why would this new network behavior be added to a browser without the
> user's knowledge or explicit permission?
>

I can't speak for beacon, but the aim of background sync is to complete a
single task that was initiated during the user's interaction with the page.
In terms of user expectation, if I write an email and hit send, it wouldn't
be unexpected for that email to send, even if I don't have connectivity
right now, or lock my phone straight after hitting send.


> > Anne's suggested solution is to cancel beacons if the network changes
> > from the point of registration. This would diminish the usefulness of
> > beacon,
>
> Who is beacon useful to?  for analytics purposes, it seems to be useful
> to the operator of the origin server, and presents a privacy risk to the
> operator of the web browser.  The risks are not borne by the party who
> benefits.  The browser itself is supposed to act as an agent of the
> user, right?
>

As far as I can tell, analytics is the main use of beacon. Background sync
however is more aimed at completing actions initiated by the user, so in
your terms, the risks are borne by the party that benefits.


> > and scupper one of the primary use-cases of background sync (queuing
> > things to send while offline).
>
> queuing something to send while offline is (or should be?) an explicit
> action taken by the user, with clear intent; isn't that effectively an
> "opt-in"?  Why would this be an action/state/permission that is hidden
> from the user?
>

Without background sync:

Perfect connectivity: User hits "send email", email sends quickly.

Lie-fi (as in, phone thinks it has connectivity but connections hang): User
hits "send email", they get a spinner for however long it takes to timeout,
then failure. They have to observe this.

The goal here is to remove the failures of the lie-fi (and offline) case
without impacting the perfect connectivity case. Requiring an opt-in
browser level permission to let a user send an email would be a big user
experience regression in the perfect connection case.

In the perfect connection case, it's highly unlikely that background
activity would take place, so asking for permission is redundant. But by
the time you've determined the user doesn't have perfect connectivity,
you're likely detached from the initiating action, so asking for permission
isn't useful. Additionally you may be unable to ask permission at the
pertinent moment, eg the user hits "send" then navigates the page.


> > 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.
>
> Presumably "single" refers only to a specific origin -- the browser as a
> whole could store and trigger multiple such actions, right?  If i
> control a subtree of the DNS, can i make multiple origins, and then send
> requests back to each of them?
>

Right, by "single" I mean that you cannot set up periodic background
actions. It's a single action that was initiated when the user was on the
page. You could set up 100s of these, but they're still going to run during
the life of the page if the user has connectivity.