W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2012

Re: Guidance, I mentioned on the call

From: David Singer <singer@apple.com>
Date: Thu, 23 Aug 2012 11:13:03 -0700
Cc: Rigo Wenning Wenning <rigo@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-id: <E9EE600A-6D08-4DB4-BE5D-268DBFE00FC7@apple.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:23 UTC