- From: David Singer <singer@apple.com>
- Date: Thu, 23 Aug 2012 11:13:03 -0700
- To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
- Cc: Rigo Wenning Wenning <rigo@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Cool, this is nice when writing specifications, I guess we could have similar questions: * what elements of the system or protocol have real-time access to data about the user, user agent, or device? * where does the protocol propagate that data 'in normal operation'? * do the elements exposed to the data also have avenues to store it persistently? * can they combine the data with data from previous sessions for the same user, or other activity by the same user? * is the data likely sufficiently precise to identify an actual person? * if data is stored persistently, what elements have access to that store? … and so on On Aug 23, 2012, at 9:25 , Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote: > Hi Rigo, > > in the call today we discussed about the way guidance (to specification authors) could be given. > > Here is what we have done with the IAB privacy considerations document: > > -------- > > 6. Guidelines > > This section provides guidance for document authors in the form of a > questionnaire about a protocol being designed. The questionnaire may > be useful at any point in the design process, particularly after > document authors have developed a high-level protocol model as > described in [RFC4101]. > > Note that the guidance does not recommend specific practices. The > range of protocols developed in the IETF is too broad to make > recommendations about particular uses of data or how privacy might be > balanced against other design goals. However, by carefully > considering the answers to each question, document authors should be > able to produce a comprehensive analysis that can serve as the basis > for discussion of whether the protocol adequately protects against > privacy threats. > > The framework is divided into four sections that address each of the > mitigation classes from Section 5, plus a general section. Security > is not fully elaborated since substantial guidance already exists in > [RFC3552]. > > > 6.1. General > > a. Trade-offs. Does the protocol make trade-offs between privacy > and usability, privacy and efficiency, privacy and > implementability, or privacy and other design goals? Describe the > trade-offs and the rationale for the design chosen. > > > 6.2. Data Minimization > > > a. Identifiers. What identifiers does the protocol use for > distinguishing initiators of communications? Does the protocol > use identifiers that allow different protocol interactions to be > correlated? > > b. Data. What information does the protocol expose about > individuals, their devices, and/or their device usage (other than > the identifiers discussed in (a))? To what extent is this > information linked to the identities of the individuals? How does > the protocol combine personal data with the identifiers discussed > in (a)? > > c. Observers. Which information discussed in (a) and (b) is > exposed to each other protocol entity (i.e., recipients, > intermediaries, and enablers)? Are there ways for protocol > implementers to choose to limit the information shared with each > entity? Are there operational controls available to limit the > information shared with each entity? > > d. Fingerprinting. In many cases the specific ordering and/or > occurrences of information elements in a protocol allow users, > devices, or software using the protocol to be fingerprinted. Is > this protocol vulnerable to fingerprinting? If so, how? > > e. Persistence of identifiers. What assumptions are made in the > protocol design about the lifetime of the identifiers discussed in > (a)? Does the protocol allow implementers or users to delete or > replace identifiers? How often does the specification recommend > to delete or replace identifiers by default? > > f. Correlation. Does the protocol allow for correlation of > identifiers? Are there expected ways that information exposed by > the protocol will be combined or correlated with information > obtained outside the protocol? How will such combination or > correlation facilitate fingerprinting of a user, device, or > application? Are there expected combinations or correlations with > outside data that will make users of the protocol more > identifiable? > > g. Retention. Do the protocol or its anticipated uses require > that the information discussed in (a) or (b) be retained by > recipients, intermediaries, or enablers? Is the retention > expected to be persistent or temporary? > > > 6.3. User Participation > > > > a. User control. What controls or consent mechanisms does the > protocol define or require before personal data or identifiers are > shared or exposed via the protocol? If no such mechanisms are > specified, is it expected that control and consent will be handled > outside of the protocol? > > b. Control over sharing with individual recipients. Does the > protocol provide ways for initiators to share different > information with different recipients? If not, are there > mechanisms that exist outside of the protocol to provide > initiators with such control? > > c. Control over sharing with intermediaries. Does the protocol > provide ways for initiators to limit which information is shared > with intermediaries? If not, are there mechanisms that exist > outside of the protocol to provide users with such control? Is it > expected that users will have relationships (contractual or > otherwise) with intermediaries that govern the use of the > information? > > d. Preference expression. Does the protocol provide ways for > initiators to express individuals' preferences to recipients or > intermediaries with regard to the collection, use, or disclosure > of their personal data? > > > 6.4. Security > > > > a. Surveillance. How do the protocol's security considerations > prevent surveillance, including eavesdropping and traffic > analysis? > > b. Stored data compromise. How do the protocol's security > considerations prevent or mitigate stored data compromise? > > c. Intrusion. How do the protocol's security considerations > prevent or mitigate intrusion, including denial-of-service attacks > and unsolicited communications more generally? > > d. Misattribution. How do the protocol's mechanisms for > identifying and/or authenticating individuals prevent > misattribution? > > -------- > > > Ciao > Hannes > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Thursday, 23 August 2012 18:13:34 UTC