Re: Adding another permission? A guide

Thank you Nick, Mike and Pete.

On timing - yes, this is something we would like to publish as soon as we are ready.

If anyone has an idea for another blog post, we would really like to turn these two blog posts into some sort of series.

My own views on on Pete’s questions - 1) this is a great way to socialise our thinking (perhaps we could consider a future group note); 2) good observation, but maybe we can give some general approaches that would be helpful; 3) although it would make the title a bit wordy, perhaps it would be useful to tweak the language for better clarity

Christine

> On 22Jun2019, 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?
> 
> 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.
> 
> 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)?
> 
> 
> 
> 
> Pete Snyder
> {pes,psnyder}@brave.com
> Brave Software
> Privacy Researcher
> 
>> On Jun 22, 2019, at 6:56 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
>> 
>> This is really good Nick. I added a couple suggestions in a PR mainly that permissions should be limited duration and the user needs to know who they have given permission to.
>> 
>> Mike
>> 
>> From: Nick Doty <npdoty@ischool.berkeley.edu> 
>> Sent: 21 June 2019 21:07
>> To: public-privacy (W3C mailing list) <public-privacy@w3.org>
>> Cc: Christine Runnegar <runnegar@isoc.org>; Samuel Weiler <weiler@w3.org>
>> Subject: Adding another permission? A guide
>> 
>> Hi PING folks,
>> 
>> Christine asked me whether we could develop the question/walkthrough below into a W3C blog post that might build on the anti-patterns discussion that Pete posted last week.
>> 
>> I’ve posted a draft to the w3cping blog-posts repo:
>> https://github.com/w3cping/blog-posts/blob/master/adding-permissions.md

>> 
>> The contents are similar to my initial email below, but written with explanation of the context of the workshop and report and a little more like a blog post. I could probably add more links to related research, etc.
>> 
>> I’d appreciate PING feedback: whether this works as a blog post, whether it should be written from an individual perspective or the interest group as a whole, whether there are obvious things missing or questions that shouldn’t be there. 
>> 
>> Christine and Sam might have more specific ideas on schedule, but I think the interest was in publishing something next week, so that we have privacy-related blog posts more regularly on the W3C blog.
>> 
>> Cheers,
>> Nick
>> 
>> 
>>> On Oct 1, 2018, at 6:47 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
>>> 
>>> Hi all,
>>> 
>>> I tried to write up some of my workshop notes on the train ride home, in the form of:
>>> * questions to think through when considering a new permission for the Web platform, and
>>> * principles for using Web permissions (that might also guide how we design permissioned features).
>>> 
>>> If this sounds of interest to anyone else let me know: I can put it in a Github repo and we can make it into a draft or Note or something. If not, it can just be another input to our workshop report or for our personal notes.
>>> 
>>> Nice talking with you all,
>>> Nick
>>> 
>>> 
>>> # Adding another permission? A guide
>>> 
>>> ## Designing Web features with permissions
>>> 
>>> _So, you're thinking of adding a new permission prompt to the Web platform? Specification authors and feature designers may find this list of questions useful._
>>> 
>>> 1. Is this feature important for the Web platform?
>>> 
>>> Specifically, is this feature important functionality that is consistent with the Web's model of privacy, security, accessibility and permissionless innovation? The Web need not be identical to every other software platform, and the distinctive features of the Web -- that software doesn't need to be vetted to operate, that documents and software co-exist, that users can be free from danger and intrusion when visiting a page, that interoperability is available among a wide range of devices and agents -- are essential to its ongoing success.
>>> 
>>> 2. Does this feature require explicit permission?
>>> 
>>> Access to data, sensors and capabilities can be designed in a way that permissions are implicit. For example, drag-and-drop doesn't require interrupting the user to confirm whether they want to share a particular file -- instead, the user's action shows that they already want to provide access to a file onto a specific page/function. Can your feature be designed in this way?
>>> 
>>> (What about a "location picker" rather than a geolocation permission? User agents could implement an input type where the user selects either her current location or a named location that she has saved and often wants to search about.)
>>> 
>>> Follow @felt's diagram to determine whether an explicit permission is required. If this feature can be designed to have accountability and mitigations without prior permissions, that can reduce user fatigue without incurring irreparable harm.
>>> 
>>> ![Flowchart on permissions from Adrienne Porter Felt.](/path/to/diagram.png)
>>> 
>>> 3. What capabilities are implicated by the resource, sensor or functionality that you're adding?
>>> 
>>> Asking users to give permission to a piece of data they don't understand is not helpful. (Acronyms and various identifiers definitely fall into this category.) If the resource provides the site with a capability similar to some other resource or sensor, then there are reasons to consider this the same permission.
>>> 
>>> Consider also what can be inferred by access to a sensor or piece of personal data that may not be generally obvious. In the past, research has shown that accelerometer data might reveal typing, light sensors might reveal activity on other devices, photo files often include geolocation metadata.
>>> 
>>> 4. What is the duration and persistence of your permission?
>>> 
>>> Different user agents may handle persisting permission in different ways. Considering duration and persistence ahead of time are useful, though. If a permission is requested for some future, ongoing or recurring functionality, then additional features are typically necessary for *accountability*, specifically:
>>> 
>>> * transparency: notice for ongoing, background or not-just-in-time actions can be challenging, but ambient notice and asynchronous notice are some options. Without that notice, a user who granted permission in the past and forgot (or someone else granted the permission on their device, or a device had multiple users, or the user previously made a decision in a different context) will not have effective means to update their choices.
>>> 
>>> * revocability: easy access to withdraw permission is generally useful but especially important in cases of ongoing permission.
>>> 
>>> 5. How will users understand how collected personal data will be used, who has access to it, how long it will be retained and how they can access or delete it?
>>> 
>>> In the past, we have sometimes included in specifications the requirement that sites use their own expressive HTML to explain how a capability will be used and their choices regarding it prior to making a browser-mediated permission request. Our experience has shown this option to be very frequently ignored by sites, even when sites may be required by local laws to get such informed and specific consent.
>>> 
>>> _We believe ongoing research on this problem could help explore whether some purpose specification within permission-granting UI could be managed in a way that doesn't violate trust boundaries. For an example, see iOS._
>>> 
>>> 6. What conditions are necessary for this new permission?
>>> 
>>> Typically, secure contexts are necessary in order for a user to know who is asking for a permission (otherwise, _who_ would also contain any set of network attackers).
>>> 
>>> Is this functionality only for top-level browsing contexts, or also for embedded third-party frames?
>>> 
>>> Does a permission grant background access or only when a tab is active/visible?
>>> 
>>> ## How to ask for permission on the Web
>>> 
>>> _Web site authors using permissioned features should keep these principles in mind._
>>> 
>>> * Ask for permission in context and just in time.
>>> 
>>> * Progressive enhancement: ask for only the permission needed and prepare to gracefully handle cases where a capability is not available.
>>> 
>>> * Explain the implications of a permission before prompting the user, in a way that is accessible and localized.
>>> 
>>>   * _who_ is asking, _what_ are they asking for, _why_ do they need it?
>>> 
>>> * Users can and will change their minds. Don't assume that a permission granted once guarantees permanent access; nor that a permission refused means a user will never choose to accept some functionality.
>

Received on Monday, 24 June 2019 18:22:43 UTC