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

On Thu 2015-11-12 13:55:29 -0500, Jeffrey Yasskin wrote:
> As Jake said, for background sync, it usually will be based on an
> explicit gesture the user makes on a page. However, the browser
> doesn't know the difference between a "send later" gesture and a
> "click link" gesture, so if the browser wants to make sure the user's
> aware they're granting permission, the browser would need to pop up an
> explicit question. Then we have 2 problems: 1) if a user almost always
> accepts permission prompts, they may stop reading the prompts before
> saying 'yes', hurting privacy overall, and 2) the question needs to be
> phrased in a way the user understands. e.g. "Can this site interact
> with the network later?" will miss users who a) don't know what a
> network is, b) don't know that your network reveals your location, c)
> don't know that a network can figure out what sites you're using over
> it, d) don't understand what "later" could mean, etc.
>
> Overall, "get the user's explicit permission" is much more complicated
> than it sounds, and folks who ask for it need to try to answer the
> questions it raises.

I'm well aware of the problems with informed consent within this space,
and i agree with you that it's extremely problematic :)

I also understand your concerns about unnecessarily prompting the user
(assuming we can imagine a good prompt, which might be a leap too far).

So, the browser can't distinguish between a "send later" gesture and a
"click link" gesture, but (we think) it can distinguish between a
network action that relates to a foregrounded, user-visible connection
and one that is actually being retried/executed later.  right?

it sounds like it's possible to solve the "when should we prompt"
concern at least -- you don't prompt if the message is being sent now,
and if the message send fails and is queued for later, then when the UA
decides it might want to try again, *that's* when it prompts.

As for the messaging -- i agree that most users don't understand these
risks or many of the concepts involved, so we'd like to make sure they
see these actions as closely analogous to existing metaphors that
they're already exposed to.

The "Downloads" menu/dialog/window in most browsers strikes me as
something that is similar to what we're talking about here.  It
indicates to users that things are pending, they can see which things
are pending, and they can even cancel downloads, restart failed
downloads, or inspect them (e.g. via "copy download link").  As a straw
man: what if there was a similar UI element for "uploads"?  A network
access could enroll itself as an upload, and if it failed, it would be
queued in the browser's "pending uploads..." section, with a visual
notice to the user, with an option for the user to re-try it.

wdyt?

        --dkg

Received on Thursday, 12 November 2015 22:56:01 UTC