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

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?

> Anne has raised an issue on beacon 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.

It's worse than just leaking the user's rough location (via their IP
address) to the origin.  It also potentially provides fingerprintable
traffic to a network observer when a user connects to a network, without
the user initiating any action with their browser.

> 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?

> 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?

> 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?

> If not, are there obvious restrictions that could be put in place that
> retain the intent of the APIs?

if the intent of the API is silent network access that is not tied to
any user-discernable browser activity, i don't see a safe way to
approach it, but maybe other people have better imaginations than i do.

         --dkg

Received on Wednesday, 11 November 2015 22:35:55 UTC