W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2014

summary of informal PING working meeting last Friday...

From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Tue, 11 Mar 2014 10:03:12 -0400
Message-ID: <531F17A0.9050404@cdt.org>
To: "public-privacy@w3.org" <public-privacy@w3.org>
CC: Runa Sandvik <runa@cdt.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hello PING, this is a summary of last Friday's meeting here at CDT.
Others that were here can correct me or amend this, of course!

best, Joe

- ----

(this document authored in Markdown format; the HTML version is
[here][1].)

# PING informal workshop at CDT

20140307 - 13:30-16:30 EST

**Attending:** Joe Hall (CDT), Frank Dawson (Nokia), Jari Alvinen
  (Nokia), JC Cannon (Microsoft), Aleecia McDonald (Stanford)

**(Purported) Goal**: attempt to perform a systematic privacy
  evaluation on a candidate specification.

## Intro

Joe started off the discussion with some words about the goal of this
informal working meeting; notably, that it would be good to get some
working experience with performing more comprehensive privacy
evaluations of web specifications.

At the informal PING meeting at IETF 89 in London the same week, PING
participants had described a few candidate specifications that would
be good to take a shot at:

* Encrypted Media Extensions's (EME) GetUserMedia
* Content Security Policy (CSP)
* WebRTC
   * (WebRTC is an aspirational goal for PING as WebRTC is exceedingly
     complex. It is a key example of cross-IETF/w3c work and somewhat
     of a worst case for an evaluation)

The important question for the work at hand was what kind of method to
apply for a privacy review of  a web specification. There seemed to be
a few options:

* Frank and Nokia's [Specification Privacy Assessment][2] (SPA)
* The Guidelines section of [RFC 6973][3] at IETF
* Other types of checklists that might lie somewhere in the middle

Some of the considerations Joe wanted to keep in mind:

* Whatever the method, it should be relatively light and not too complex
* It should be usable by WG Chairs who might not have a deep
  background in privacy
* To the extent we can exploit similarities across specifications
  (e.g., reusable text) or across IETF/w3c boundaries, we should do so

As is the case with many good plans, little of this actually
happened. Instead we discussed a set of issues that we wanted to bring
back to PING:

* Systematic vs. point evaluations
* W3C staff/management committment to privacy/security
* Incremental steps

## Systematic vs. one-time (point) evaluations

The guidelines in RFC 6973 are in no way systematic; they are probably
better characterized as a point or one-time evaluation. They are meant
to be a set of considerations that IETF specifications should respond
to before Area Director review, and the AD can require specification
editors to include text addressing those issues.

Due to (what I understand) the different structure of standardization
at w3c, this kind of one-time evaluation isn't feasible. That is, by
the time a w3c specification makes it past being a Working Draft to a
Candidate Recommendation, no changes to the text are allowed without
going back to the Working Draft stage. This means privacy input at the
CR stage is likely to be resisted by WGs and spec editors as they will
want to minimize the chances that they'll have to restart that
process.

Instead, it seems much more important for the w3c to more
systematically incorporate privacy issues over time during the
lifecycle of a specification.

### Chartering

When a WG is developing its charter, this is more than likely where
the first indications of possible privacy concerns will arise. A
number of things relevant to privacy can and probably should happen at
this stage:

* In the WG Chairs' Manual, there could be a helpful section on
  privacy considerations and a pointer to PING and an explanation of
  what PING can help out with.
* If a specification clearly raises privacy issues, w3c staff could
  point out that PING will need to be involved.
* As the charter is refined, specific wording as to privacy
  considerations could be added. It will be very powerful if the WG
  Charter itself ensures that privacy is part of the spec deliverable,
  so to speak.
* The WG Chairs and interested parites may be able to do a somewhat
  basic and easy-to-understand privacy pre-assessment (see below in
  "Incremental steps"), that might indicate the need for more ongoing
  review of privacy considerations.
* WG Chairs or specification contributors could receive some basic
  "privacy training" that PING members could develop and deliver to
  better sensitize spec authors to privacy considerations for web
  specifications.
* PING could work to ensure that a "privacy champ" is identified for a
  given WG at or near charter stage. This would be someone who
  understands privacy is important, but need not be someone like a
  PING member that is presumably steeped in privacy knowledge. This
  person could identify privacy issues and work from inside WGs to
  help deal with them early, instead of when they may be more
  problematic to change or fundamental to the specification.

## W3C committment to privacy/security

We thought it would be particularly important for w3c management and
staff to make an public and strong commitment to privacy and
security. Similar to the open web principles (JLH: not sure if these
are components of those), a clear vision as to the importance and
instrumentality of privacy and security in web standards would ensure
that privacy is not easily disregarded in standards efforts.

This could also encompass some guidance on where to go to learn more
about privacy and, if needed, administrative processes for matching
privacy knowledge to specification contributors. At some point, there
may need to be elements of privacy and security review formalized into
the standards development process. (baby steps are important)

## Incremental steps

There seems to be some room for incremental steps that wouldn't saddle
the w3c standards development process immediately with deep and
ubiquitous privacy consideration or review.

For example, there is a relatively simple three-part decision tree
that Frank has developed at Nokia to decide when, if at all, a privacy
assessment need be performed:

<https://github.com/yrlesru/SPA/blob/master/WhenToConductSPA.jpg>

JC Cannon pointed out at Microsoft they have something like this but
that it also includes an additional question: "Does it change privacy
settings?" which can be important in terms of privacy leakage. Aleecia
and JC both pointed out that there may need to be a question about
handling particularly sensitive data (finance, health, kids) as
well. I myself wonder if the second question "Will std or spec
generate data?" might be answered "yes" for all w3c specs?

[1]: https://josephhall.org/PING/ping-meeting-20140307.html
[2]: https://github.com/yrlesru/SPA
[3]: https://tools.ietf.org/html/rfc6973

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTHxegAAoJEF+GaYdAqahxtv8P/1SfQKLS2w0kndV3GshwxC13
GZG2FlGGG7dMkTNVBiDhnOPDEe7UQHiOPy8nCRJpfna4do+hrBTldFWVbwM6qmYA
BdIP4DFT6zMYDxJLtTMb8dHdc1K4JOldCVv8GbZu8n5DHmXbJluGFAtSdDV8GcnK
ATHheesbp+G1x69JnvmTfqY1/XNTRASYUMoZydUO8/dvhUzcZYVuAcS0gxrxRZrU
XL5I/ypsAg85dyUvCEVqnPj7fgcUGNf2XkwfHNBW0Lgr05PTPBYqcf0YoYwML5NE
oTofWlxlZ8WXuG2D7XHbmm+rB9BumiPFRyZ2+QQ0MdT6pKOc2RGyA5mWKFOXVe6N
Ofx+mQAdZEkBaQPlOpqpba8CIIFUGXDP531SnaI3xQ44X+qAXfjY3b6d2EsHUjRs
wYOJgYqHIrnusbNGgj9DdWXw8YaAGatxb9Ly6J4Rwcn1yFsmXJSpqmYZUHDPWmnP
Bwvvwwb3HRgv1q3q+Ij3wIO3Qdn8gO/Ko1/BQ/ucOzsIybUXsgtNQ+gRr1Bn7ioB
das9a5AMlNvXWnkBdqyEIscbKWo0YlBMsto8lVJlCHM07HZ+/RaXhax9EJ4cF28w
fOUKjAmnkDHJGVYi1fpglJEoOKOUZeR/vbz+ijCuwU0kJ+qdDBdhx89Xs0ZLvVGN
3E2Ozr/jTVrzdG12hUl6
=90QP
-----END PGP SIGNATURE-----
Received on Tuesday, 11 March 2014 14:03:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 March 2014 14:03:46 UTC