Hi Alissa,
At 09:10 23-02-2013, Alissa Cooper wrote:
I'm not quite sure what you are recommending here, but we have had
conversations in the IAB privacy program about moving the guidance
part up, or otherwise trying to make the focus on the guidance piece
more prominent. The difficulty is that there is a broad range in the
extent to which potential readers are familiar with privacy
concepts, so jumping straight into the guidance would not be
appropriate for some portion of the audience. If you have concrete
suggestions for how to simplify, those would be helpful.
From Section 1:
"Privacy is a complicated concept with a rich history that spans many
disciplines."
The draft starts by saying that it is a complicated concept. It then
tries to fit in "data and "personal data". It then goes into data
and analysis, identifiability and then communication models. I think
that the problem stems from trying to cover the major points of all
the authors.
The threat model is too broad, or rather, it tries to be exhaustive.
I suggest removing:
"[RFC3552] provides detailed guidance to protocol designers about both
how to consider security as part of protocol design and how to inform
readers of protocol specifications about security issues. This
document intends to provide a similar set of guidance for considering
privacy in protocol design."
Start with the Introduction. Move Section 6 after by introducing the
reader to scope. In Section 6:
"Transparency of data collection and use -- often effectuated through
user interface design -- is normally a key factor in determining the
privacy impact of a system. Although most IETF activities do not
involve standardizing user interfaces or user-facing communications,
in some cases understanding expected user interactions can be
important for protocol design. Unexpected user behavior may have an
adverse impact on security and/or privacy."
User interface is out of scope. :-) I suggest not saying anything
about it. Transparency of data collection takes us into issues which
are generally discussed outside the IETF. I'll say remove this for now.
Section 3 is about the communication model.
"To understand attacks in the privacy-harm sense, it is helpful to
consider the overall communication architecture and different actors'
roles within it."
It's not an attack on privacy. To say it differently, anything "I do
not like can be classified as an attack.
The draft discusses the communication model (second paragraph). The
model is supposed to, by default, "protect" privacy. The goal is
privacy protection.
'As [RFC3552] explains, "we assume that the end-systems engaging in a
protocol exchange have not However, by its nature privacy
analysis requires questioning this assumption since systems are often
compromised for the purpose of obtaining personal data.'
This might have to be discussed one of these days. For now, some
basic assumptions are needed. Either we trust the end or else there
is one more problem to solve.
Section 4 is about privacy threats. I would leave it there or else I
have to figure out what to do about the mitigation section.
"Data minimization mitigates the following threats: surveillance,
stored data compromise, correlation, identification, secondary use,
disclosure."
You have some major points here. Thinking aloud, the existing
Section 4.2 can come after that.
There is the concept of anonymity after that. I suggest keeping it
as it fits within the subject. Don't spend too much time on it as it
is well-known that most people would block
anonymous@anonymous.invalid. I guess that you could use "property of
an individual" and identity to discuss about this.
"By providing proper security protection the following threats can be
mitigated: surveillance, stored data compromise, misattribution,
secondary use, disclosure, intrusion"
The draft repeats some points from a security perspective. The commonality is:
(a) stored data compromise
(b) surveillance
(c) disclosure
(d) secondary use
There is already a BCP for security. It's easier to let that BCP fix
what it can. This is where I would look into how all this fits
within the communication model. If the network isn't providing data
storage that point is out of scope. You are already doing data
minimization. That's the most you can do.
Section 7 is about guidelines. It fits in the flow (of text). In Section 7.4:
"Does the protocol make trade-offs between privacy
and usability, privacy and efficiency, privacy and
implementability, or privacy and other design goals?"
It's not a good idea to get into that. :-) The following was from
draft-ietf-appsawg-webfinger-09:
"WebFinger server MUST NOT be used to provide any personal information
to any party unless explicitly or implicitly authorized by the person
whose information is being shared. Implicit authorization can be
determined by the user's voluntary utilization of a service as
defined by that service's relevant terms of use or published privacy
policy."
That's where privacy will end once "we" get into trade-offs. You may
have noticed that the "MUST NOT" is violated.
Section 8 could be moved to an appendix.
If you decide to do the above you still have to do an overall pass of
the draft for consistency. I would have to generate an I-D and go
through the text to see whether what I suggested makes any sense.
BTW, the draft has the following:
"the thinking that should go into the design of a protocol when considering
privacy as a first principle"
It's an interesting point. You could use that to get to "privacy
analysis". You can then drop "privacy threats". Basically, you are
advising the reader analysis whether he/she has followed that
principle to protect privacy.
Regards,
-sm
_______________________________________________
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
