ACTION-105: Refine privacy requirements

John and I reviewed the Privacy Requirements document. We suggest a  
number of changes below, some of which are small tweaks, and others of  
which are substantial (i.e., suggesting additional requirements). I've  
also attached an edited version of the spec that reflects these  
changes. I purposely did not post the changes, though, because they  
are quite substantial and I think they deserve some discussion on the  
list before being reflected in the current draft. I'm happy to insert  
these edits into the draft depending on whether people agree with them.

Individual edits are separated by horizontal lines and my commentaries  
are prefaced by "[AC]".


1. Introduction
----------------------------
OLD:

Privacy considerations are important to Device APIs, since misuse of  
information exposed by the APIs can have financial, physical safety,  
and reputation impacts, among others.

NEW:

Privacy considerations are important to Device APIs, since misuse of  
information exposed by the APIs can have potentially harmful  
financial, physical safety, reputational and other impacts.

[AC] This is editorial, but probably important to note that the harms  
are potential (not guaranteed!).


1.1 Architectural Approach
----------------------------
OLD:
How to define APIs in such a way that they are “naturally” privacy- 
friendly

NEW:
Defining APIs in such a way that they are as “naturally” privacy- 
respecting as possible

[AC] We suggest a bunch of edits in this architecture section to  
streamline it a bit.
----------------------------
OLD:
Only require from user-agents what, if anything, they can  
realistically enforce
Understanding how user-agents can help with privacy is important,  
however implementation and adoption considerations are important in  
this area. This can be separated to a large degree from API design  
decisions.

NEW:
Requiring from user agents what they can realistically enforce
User agents are crucial to ensuring that user privacy is protected,  
but this capability must take implementation and adoption  
considerations into account. User agent design decisions can be  
separated to a large degree from API design decisions.

[AC] This puts greater emphasis on the role of UAs, but still notes  
implementation and adoption considerations.
----------------------------
[AC] Education is listed before the "license approach to privacy." I  
would put the license text first, with education at the end. This  
follows the ordering of the chart in 1.2.
----------------------------
OLD:
A License Approach to Privacy

NEW:
Empowering users to express privacy preferences

[AC] Another part of the streamlining of this section.
----------------------------
OLD:
This can be hard to manage technically but might be possible through a  
simpler approach of defining and agreeing upon conditions, similar to  
a Creative Commons license.

NEW:
This can be hard to manage technically but might be possible through a  
simpler approach of defining and agreeing upon a small set of privacy  
preferences, similar to Creative Commons copyright licenses, that  
users can attach to their data.

[AC] This adds some detail about the ruleset approach.
----------------------------
OLD:
Defining a simple vocabulary for privacy could enable a "privacy  
license" that can be referenced by URI.

NEW:
Defining a simple vocabulary for privacy could enable <a href="http://dev.w3.org/2009/dap/privacy-rulesets/ 
">privacy rulesets</a> that can be referenced by URI.

[AC] Inserts a link to the rulesets.
----------------------------
OLD:
Education & Outreach, similar to the accessibility efforts

NEW:
Conducting education and outreach, similar to the accessibility efforts

[AC] Streamlining.
----------------------------
s/while we certainly do not live in a perfect world/while  
implementations are not perfect/
----------------------------
s/(which in some cases can be wide-ranging such as making script  
libraries support the solution directly, or various organizations  
enforce it internally)/
(which in some cases can be wide-ranging, including making script  
libraries support the solution directly, or having various  
organizations enforce it internally)/
----------------------------


1.2 Privacy Principles relevant to APIs
----------------------------
[AC] In the table that summarizes the elements, the consent box is not  
currently checked in the best practices column, but upon further  
consideration, John and I think that it should be. If that's likely to  
be the only thing that developers read, we might as well discuss  
consent there too (although in some cases apps won't have to do much  
to get consent beyond what UAs may provide).
----------------------------
OLD:
getting the user to understand and set rules on sharing their  
information is hard;

NEW:
getting the user to understand and set rules on sharing their  
information, and to understand that limits of those rules, is hard;

[AC] This edit and the next two edits are all tweaks to the first  
issue in this section -- nitpicking, I know, but we thought it needed  
a little clarification.
----------------------------
s/they will expect the user agent to enforce/they may expect the user  
agent to enforce/
----------------------------
OLD:
developers are very likely to ignore policy rules sent along with the  
data they're actually interested in, and may not be in a position to  
act upon these policies even if they wanted to

NEW:
developers may ignore policy rules sent along with the data they're  
actually interested in (at the risk of encountering legal or market  
consequences)
----------------------------
[AC] As has been mentioned on the list, I think we can delete the  
second issue in this section because section 1.1 takes care of it.
----------------------------


2. Requirements for API Definitions
----------------------------
[AC] If the changes suggested below about sections 2 and 3 get  
adopted, the issue at the top of section 2 can likely be removed.
----------------------------
[AC] I think this section could benefit from the following opening  
comment:

Many of the requirements listed here are recommendations (SHOULDs)  
rather than absolute requirements (MUSTs). In many cases this is  
because making a requirement absolute is appropriate for only a subset  
of the APIs, but not every API. As appropriate, individual APIs may  
place stronger normative requirements on user agents than the  
requirements in this document place on APIs.
----------------------------


2.1 Notice
----------------------------
OLD:
Requirements could address: Whether APIs should provide ways for UAs  
to notify users before their data is sent to applications; how that  
notification happens; what that notice should contain

NEW:
Making sure that users understand the implications of using an  
application that relies on a Device API is fundamental to ensuring the  
protection of their data. The following requirements can help to make  
sure that users are properly notified:

-- APIs MUST make it possible for user agents to notify users that  
their data is being collected via the API. This notification MUST  
identify the application (for example, by displaying its document  
origin [[HTML5]]) and the precise data being collected.

-- APIs SHOULD provide support for visual indicator(s) that data is  
being collected via the APIs.

[AC] This replaces the braindump of what notice requirements could  
look like with a little intro text and two possible notice  
requirements. If the second requirement above is added, the second  
issue in this section can be removed. However, the first issue (about  
whether to require support for applications to be able to convey how  
they intend to use the data they're collecting) remains an issue, and  
we haven't discussed it much.


2.2 Consent
----------------------------
OLD:
Such user actions constitute implicit consent, since the user has a  
choice to perform them and doing so implies consent to use the  
associated Device Capabilities. Such implicit consent eliminates the  
need for a security access dialog for that action since it is implicit  
in the application semantics.

NEW:
Such user actions constitute implicit consent to collection of data  
via the API, since the user has a choice to perform these actions and  
doing so implies consent for the application to access the associated  
Device Capabilities. In such situations where it is obvious that  
performing the action involves sharing data with the application and  
the application’s intended use of the data is also obvious, additional  
dialogs that prompt users for consent may not be necessary.

[AC] I added more detail here so as to specify exactly what is being  
consented to and the cases in which implicit consent is acceptable.
----------------------------
OLD:
Device APIs may also be defined such that implicit consent is not  
implied. Examples are a camera API that takes a photograph without  
user involvement, or a messaging API that sends a message without the  
user pressing "send". In these cases policy and/or user dialogs may be  
required.

NEW:
Device APIs may also be defined such that consent must be explicit,  
not implicit. Examples are a camera API that takes a photograph  
without user involvement, or a messaging API that sends a message  
without the user pressing "send". In these cases dialogs may be  
required.

[AC] These are editorial changes for clarity.
----------------------------
[AC] This section currently has no requirements. I would delete the  
first paragraph in the section and insert the following, which  
contains two requirements, at the end of the section:

To ensure that data is not collected without users knowing or  
realizing, APIs should be designed with the presumption that the  
explicit consent model will be used, and should explain the specific  
circumstances under which implicit consent may be acceptable. This  
gives rise to the following requirements:

-- APIs MUST make it possible for user agents to obtain user consent  
before sharing any data via the APIs. 

-- APIs MUST be defined in such a way that explicit consent is  
assumed, and they SHOULD articulate the circumstances under which  
implicit consent is acceptable. 

An important caveat to the consent model supported by Device APIs  
relates to data about other people that the user may have on his or  
her device and be able to share via the APIs (other people’s contact  
or calendar information, for example).  A user should not be able to  
consent through the Device APIs to use of other people’s information  
beyond the original interaction with the API. Thus, for example, a  
user should be able to consent to have an application contact another  
person mentioned in a calendar entry (perhaps to say “I am running  
late”), but the user should not also be able to consent to have the  
application make later use of the person’s contact information  
(perhaps to send marketing messages to that person). This caveat  
should be conveyed where appropriate in the APIs, best practices, and  
other Device APIs documents.

[AC] Note that the last paragraph discusses a privacy issue that is  
somewhat unique to Device APIs, in that they allow easy sharing of  
other people's data.
----------------------------


2.3 Minimization
----------------------------
s/it is helpful to design APIs/it is important to design APIs/
----------------------------
OLD:
Requirements could address: API support for limiting the amount of  
information requested/returned, whether APIs require UAs to allow  
users to change or limit the amount or granularity of data sent to  
applications. Examples of potential requirements include:

NEW:
This gives rise to the following requirements:

[AC] Since this section has requirements, we can cut the braindump of  
potential requirements.
----------------------------
OLD:
APIs SHOULD make it easy to request as little information as required  
for the intended usage.

NEW:
APIs MUST make it easy to request as little information as required  
for the intended usage.

[AC] With all that we've discussed about minimization, it seems like  
this requirement should be a MUST. The APIs all seem to be moving in  
this direction in any event.
----------------------------


2.4 Control
----------------------------
OLD:
Requirements could address: Whether APIs require UAs to provide a  
mechanism for consent to be revoked; what revoking consent means; what  
the default settings are for whether and to whom user data is sent;  
what the default settings are for granularity of data collected;  
whether APIs require UAs to provide a mechanism for users to whitelist  
trusted applications or blacklist untrusted applications

NEW:
Given the sensitivity of the data made available through Device APIs,  
it is important for users to be able to control which applications  
have access to that data. The following requirements ensure that (1)  
users have control over their data even after they have shared it with  
an application, and (2) users have robust controls over which  
applications can obtain their data to begin with:

-- APIs MUST make it possible for user agents to support the  
revokation of user consent to sharing of data via the APIs.
-- APIs SHOULD support the ability for user agents to allow users to  
whitelist trusted applications and blacklist untrusted applications.

[AC] This replaces the braindump of possible requirements with two  
actual requirements.
----------------------------


2.5 Access
----------------------------
OLD:
Requirements could include: Whether APIs require UAs to allow users to  
view the applications with whom they've shared data and at what  
granularity; whether APIs require UAs to allow users to view the  
history of the user's data sharing with each application; whether APIs  
require UAs to allow users to delete history entries or whole histories

NEW:
Notice and control cannot be fully implemented unless users can review  
how they have shared data in the past. The following requirements  
suggest how APIs can support users’ access to this information:

-- APIs SHOULD make it possible for user agents to allow users to view  
the applications with whom they have shared data. 
-- APIs SHOULD make it possible for user agents to allow users to  
view, edit, and delete the history of the user's data sharing with each.

[AC] Same deal -- replacing possibilities for requirements with actual  
requirements.


3. Requirements related to User Expectations of Data Use
----------------------------
[AC] This section does not currently contain any requirements. Because  
retention, secondary use, and sharing are largely out of the control  
of the APIs, it's not entirely clear that it makes sense to have any  
API requirements about these aspects. On the other hand, one can  
envision a requirement that supports the ruleset model, such as:

-- APIs MUST support a mechanism for users to convey their preferences  
about retention, secondary use, and sharing to applications in the  
context of an API interaction.

Likewise, if we wanted the APIs to support applications' ability to  
convey their intended policies about these aspects, we could have a  
requirement like:

-- APIs MUST support a mechanism for applications to convey their  
policies about retention, secondary use, and sharing to users prior to  
or during API interactions.

Are these overly prescriptive, or do they strike the right balance  
between outlining the approach for APIs to take without dictating  
solutions? We've discussed the user rulesets much more than  
applications expressing their policies, so perhaps it makes sense to  
just have something like the first requirement?


Cheers,
Alissa & John