Re: Adding another permission? A guide

Hello,

Sounds great, and I am happy you had a productive and entertaining time.

One question: who is to ultimately decide/etc as to whether a permission is
justified and/or makes sense? Consensus? Permissions WG? TAG? A dedicated
'elders of permissions' group?

wt., 2 paź 2018 o 00:47 Nick Doty <npdoty@ischool.berkeley.edu> napisał(a):

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