W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2011

Comments on TAG Minimization draft

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 31 May 2011 21:33:50 +0000
To: <Daniel.Appelquist@vodafone.com>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <3E602140-8008-4CEF-BA1E-113978FA9220@nokia.com>

Thanks for sharing the TAG Minimization draft and referencing previous DAP work in this area.

I have proposed changes, to the draft ( http://www.w3.org/2001/tag/doc/APIMinimization.html ) as follows

1) Abstract


The purpose of this TAG finding is to highlight the importance of the Data Minimization architectural principle  to all W3C Working Groups and to promote consideration of data minimization from the outset during the creation of deliverables. Doing so can contribute to Privacy by Design and  reduce privacy and confidentiality risks associated with API and protocol designs.

2) Section 2, Introducing API Minimization

Change title to "Introducing Data Minimization"

Replace "In their paper 1975" with "In their 1975 paper"

3) Section 3, What Does API Minimization Protect Us From?

I would suggest replacing the contents of this section with the following (I introduce the "secondary attacks"  phrase):

Minimization of data returned by API calls protects the end user from the potential misuse of information that was not necessary to the application or method invocation. By not including this information, it is not subject to inappropriate retention, sharing or use.
Although simple in principle, this can have a large impact when considered over the potential quantity of information that could be returned unnecessarily. Considering both the large number of contacts and the amount of personal information that could be contained in each one, this is important. In addition, this reduces the opportunity for correlating information from different sources.

Data minimization in the context of APIs offers some (but not much) protection against  Malicious Web applications by making the work harder to obtain information. More importantly, it makes "secondary attacks" less likely, when information that is retained by a the service that used the API is then subsequently obtained by a malicious party that has attacked the server or service. This can include Web applications that are manipulated into divulging personal information, e.g. through cross-site scripting attacks, or servers that are attacked by other means.

Limiting the amount of information shared also enhances confidentiality by reducing the amount of information at risk, say from  network sniffers seeking to extract personal information from HTTP traffic going over the clear (e.g. Firesheep).
In this context, the reason is that the Web application in question will only have access to the minimum information it needs to perform its duties.

4)  Section 4,  Conclusions

Replace contents with

Privacy is increasingly  important to all stakeholders of the web, including end-users, browser vendors and service providers.  It is important to consider privacy from the beginning, to consider "Privacy by Design".  One aspect is the architectural principle of data minimization, designing interfaces and protocols to convey the minimum information necessary to accomplish a task. Doing so reduces the amount of information at risk for confidentiality and privacy reasons by reducing the potential attack surface. The purpose of this TAG finding is to highlight this concern to all Working Groups and to promote consideration of data minimization from the outset of standardization.

5) I suggest using ReSpec citations, e.g [[DAP-PRIVACY-REQS]] etc

This should help fix the  broken citations, e.g.

	• http://www.w3.org/2001/tag/doc/APIMinimization.html#dapcontact (line 606)
	• http://www.w3.org/2001/tag/doc/APIMinimization.html#AWWW (line 479)
	• http://www.w3.org/2001/tag/doc/APIMinimization.html#minimizationietf (line 539)

 Line: 702 view-source:http://dev.w3.org/2009/dap/contacts/

This should also help with referencing the latest versions of the docs, e.g. the published Device API Privacy Requirements Note is later than the one currently referenced  (29 June 2010), http://www.w3.org/TR/dap-privacy-reqs/

6) There appear to be some validation errors, probably cascaded.


7) Comments on the "Notes" at the end of the document:

What to say about other API types besides javascript API?

 fjh - focus on data minimization as the principle

What is the overall document collection?
	• “W3C Approach to Privacy”?
	• “W3C Architectural Principles on Enhancing User Privacy”

fjh - I think it would be simpler to link to this document from the "Guidelines on W3C specifications editing" on the W3C editors page,  as a start - http://www.w3.org/2003/Editors/

fjh - more ambitious would be to create  "Privacy by Design" guidance 

Should the umbrella document be bounded or unbounded?

fjh having bounds enables  planning, review and determining completion of specific items...

regards, Frederick

Frederick Hirsch
Received on Tuesday, 31 May 2011 21:34:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:28 UTC