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

On Thu, Nov 12, 2015 at 2:55 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> 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?

Makes sense: if there's an "Uploads" tray like there's a downloads
tray, users would be able to see what's pending, and might be aware of
it when they go to a new network.

Showing "https://foo.com/, https://bar.com/, and https://baz.com/ want
to upload data" when you arrive at a new network could be
non-interrupty enough that users would read it, and the browser could
remember pairings between origins and networks to avoid asking too
often. (Assuming networks are sufficiently identifiable...) The set of
options seems unfortunately large though: "{Yes,No} {this site on this
network, this site on all networks, all sites on this network}".

It might make sense to only do one or the other: if the user's aware
that some data's waiting to be uploaded, they can cancel it before
joining a network they don't want that data attached to, or if they're
going to be prompted, they don't need to be spammed with the fact that
there's a pending upload until the prompt.

Jeffrey

Received on Friday, 13 November 2015 02:32:38 UTC