Subject: [ietf-privacy] Comments on draft-iab-privacy-considerations-03

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Jul 2012 07:37:30 -0700

I note this is information and not BCP and comments are sent in that context. 

Overall I like this - particularly section 6 which if far more actionable than many things I have read in the privacy space. 

Few comments ...

Should this explicitly mention the example of communication from women's shelters - I find this example a good one for thinking about many privacy problems. 

I realize that everyones time is limited, but it someone got motivated to provide a second example, I think OAuth would make a great example. 

Small comments ….

In "A natural person." the word natural seems really weird.Would "A human" be better?

The definition of 
     Personal Data:   Any information relating to an identified
      individual or an individual who can be identified, directly or
      indirectly.

made me read it several times before I got it. Does it mean 
     Any information relating to an individual who can be identified, directly or
      indirectly.

Might want to add "anonymity set" to section 3.1 

Typo "intermediairies" should be "intermediaries" ?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Jul 2012 17:20:55 +0100

My comments on this below.

Cheers,
S.

General:

1. I like sections 5 & 6, which by themselves make the
document useful enough to publish IMO. Perhaps consider if
that text with a lot less surrounding text might be a more
useful standalone document?

2. I wonder if "threats and countermeasures" is the right way
to think about privacy. Perhaps we're inheriting too much from
security there. It might be that it'd be better to consider
the extent to which things (e.g. I-Ds, protocols) are
privacy-friendly or privacy-unfriendly, rather than consider
specific sets of circumstances and good/bad actors to be
"threats to privacy." Put another way, perhaps the correct
form of risk analysis to apply here differs a lot from that
best applied when considering security. I'm not saying I know
for sure, but this struck me strongly when reading this draft.
Changing that might be too much for this document, but is
worth disussion I think.

3. Ought we bite the bullet and formulate an unambiguous and
easily understood statement (as a BCP) to the effect that the
IETF wants the Internet to be (more) privacy friendly?  We
(the IETF) do have participants who are sponsored by
organisations that are privacy-unfriendly and so without such
a consensus position the effect of this IAB draft may be
minimal. I'd be willing to AD sponsor such a BCP, and happy to
do so if the consensus were that the IETF does want to be more
privacy-friendly. I'm thinking of something along the lines
of RFC 2804 for privacy, and of course that would need a
possibly long separate discussion, but this list seems like
a good place for that.

Details:

- Abstract: this should make it clear if the goal is that all
RFCs will in future have privacy considerations or if the goal
is that only those that need it will have such a section (I
hope the goal is the latter).

- intro, 2nd para: FIPs needs a reference, and it conflicts
with the US Govt. standards for federal information
processing, e.g. FIPS-180, so if you've a different acronym
you could use that'd be better.

- intro, suggest adding a new 3rd para that says that
different people also have radically different conceptions of
what privacy means, both in general, and as it relates to them
personally. There seems to be quite a broad spectrum, with an
unknown distribution of attitudes. (Though there may be
referenceable work on that - if there is, it'd be good to
refer to from the putative new para.)

- intro, current 3rd para: I think you ought admit that some
documents just don't need any privacy considerations, e.g. RFC
2104, just to take an example.

- s2, para 1: s/building protocols/something else/ we're often
at our worst when we design by committee so stating this as
our core function seems like a bad plan to me. (The rest of
the para is fine.)

- s2, p2: I don't accept this is the correct first thing to
tell protocol designers: "the extent to which protocol
designers can foresee all of the privacy implications of a
particular protocol at design time is significantly limited."
I think its far more common that designers just don't think
about privacy at all, or else benefit from privacy-unfriendly
designs (e.g.  via advertising). The first thing we should
tell them is that they need to think about privacy because if
they don't, that may come back to bite them, their protocols,
products and systems.

- s2: transparency of collection is surely subbordinate to
minimising the data collected to that necessary? The simplest
way to be privacy friendly IMO is to not have the data, or to
forget it if you need to have it for a short while.
Transparency only comes into it after you're going to keep
some data long enough for it to be potentially problematic.

- 3.1 is laden with risk analysis concepts, e.g.  attacker,
eavesdropper. As I stated before I'm not at all sure that's
the right model. (So I've not commented in detail on the rest
of s3.)

- 4.1: The 3552 assumption that end-systems are ok is fine
there, but not here. Social network servers (or web servers
generally) are some of the most privacy-unfriendly machines on
the Internet, and quite deliberately so.

- 6.2: This should ask "What identifiers could you omit, or
make less identifying, but still fulfill your protocol's
goals?"

- 7: This section really ought also say which of the various
protocols/approaches is widely used or not and whether the
privacy related features actually get deployed/used or not.
While the IETF can't force someone to use a feature of a
protocol, we ought learn from the ways in which our protoocls
are actually used. I suspect (but don't know) when it comes to
privacy, the less privacy-friendly deployment choices are far
more common.

---

From: SM <[email-masked]>
Date: Fri, 27 Jul 2012 07:48:40 -0700

>Changing that might be too much for this document, but is

There was a comment about "natural person".  That term is well-known 
in legal circles to distinguish between people and entities which may 
have the same rights as people.  I would say that "risks" is more of 
a people issue instead of the usual security issue.  Looking at 
privacy in terms of threats and counterthreats provides a limited 
view of the problem space; e.g. see previous comment about "natural person".

>IETF wants the Internet to be (more) privacy friendly?  We

If we were to look at the "blue sheet" discussion, the answer to the 
above would be yes.  The "position" on privacy is fuzzy though; what 
we choose for ourselves and what we argue for in specifications can be at odds.

Regards,
-sm