RE: Adding another permission? A guide

There is a difference between describing UX in detail and making sure the data needed to inform exists. Triggering a permission usually ends up in a user prompt, at least identifying a url of either the top level site or an embedded third-party.
We can ask that the data is there so user can be informed e.g. who is asking for the permission and what for (purpose). We do not have to define what the UX looks like, just that the parties involved declare the necessary information somewhere.
The UX might be implemented by the UA or a JS library, or the top level site in whatever way works, but the data it is based on has to be accessable.

Mike




-----Original Message-----
From: Nick Doty <npdoty@ischool.berkeley.edu> 
Sent: 28 June 2019 21:58
To: Pete Snyder <psnyder@brave.com>
Cc: Mike O'Neill <michael.oneill@baycloud.com>; public-privacy (W3C mailing list) <public-privacy@w3.org>; Christine Runnegar <runnegar@isoc.org>; Samuel Weiler <weiler@w3.org>
Subject: Re: Adding another permission? A guide

Thanks for the comments and ideas, Pete.

> On Jun 22, 2019, at 11:27 AM, Pete Snyder <psnyder@brave.com> wrote:
> 
> Hi Nick,
> 
> Thanks for writing this up!  A couple of broader questions / thoughts though:
> 
> 1) Are the bulleted items intended to be necessary conditions for PING approval?

The bulleted items in the second section are suggestions for Web authors, not for the designers of new features or the authors of their specifications. Asking for permission in context and explaining implications before prompting a user are conditions that have to be set by the consumer of an API, as they control the content on a web page and the flow that the user is going through. (Of course, we can design APIs that are better for asking just-in-time and in-context and providing explanation when prompting.)

The numbered questions in the first section aren’t intended as conditions for PING approval. As we discussed some yesterday, I’m not especially eager or capable of deciding everything that is or isn’t acceptable for approval. But more to the point for now, I think, these are questions to think through, and the answers — and the designs that will use permissions in a way that supports user privacy — will depend on the details of a particular feature. I do think we could maybe build on this (post blog-post) to identify more specific requirements that could apply in certain conditions, like secure contexts being necessary for new device access permissions, or top-level-browsing-contexts only for capabilities that could apply in the background.

> 2) In general, I feel nervous about giving specifics about UX flows like this, unless we’re willing to make them into bright lines.  I feel much more comfortable giving specifics about the privacy implications of new features (e.g. what sites can learn, what state sites can set / read, etc), and treat those as the hard rules, and leave permissions as one tool (among many) that standards authors can use to meet those requirements.
> 
> In general the UI / UX / HCI / etc aspects of permissions is its own HUGE ball of wax that I don’t think PING has expertise on, and so I don’t think we should do anything that looks like we’re making decisions on these areas.

Yeah, the UX challenges are significant when it comes to permissions, and that makes it harder to normatively standardize. In tension with that, I think the workshop and ongoing discussions about permissions have emphasized that we need to consider some of these UX topics when we’re designing and standardizing new features, though.

I think the most direct overlap there is the question about including site-provided description/explanation as part of a browser-mediated prompt. That’s definitely a UA UI/UX design question (and not an area where I can provide the user research data or expertise), but it’s also one where we have to design APIs to include or not include that capability. Because it’s such an important/challenging topic, I think many people in the room came down on the conclusion of “this is worth getting specific research/input on”. I hope the PING list can be a place to get more discussion on that. (And I’m encouraged to have heard some thoughts about that offlist already.)

In other areas of the post I’m not intending to give specific UI/UX advice, but maybe you can remind me or suggest alternatives where I’ve done that. This does include setting out desirable properties (like transparency and revocability) and does have suggestions on asynchronous or ambient notice, though I’d be happy to remove those last two if it seems distracting.

> I think the content and points raised are great, but framing this as a guide for spec authors seems like the wrong tactic.  Could it be reframed as a “lessons and suggestions for spec authors about permissions” post (which might take only slight wording changes)?

I think my audience/goal is described with: "Specification authors and feature designers may find this list of questions useful to think through.”

Maybe “guide” has a particular connotation for people that I’m not picking up on. Does “guide” seem too prescriptive to you, or not prescriptive enough? I like “lessons and suggestions” although some of these are questions that might not have specific recommendations to go with them. Maybe “Adding another permission? Some questions and suggestions”.

Cheers,
Nick

Received on Saturday, 29 June 2019 17:16:06 UTC