Hi Hannes,
At 11:13 24-02-2013, Hannes Tschofenig wrote:
In order to address this comment we could either
To keep matters easy I'll say that my comments have been addressed.
a) change the meaning of the sentence. For example, we could come to
the conclusion that privacy is not that complicated after all.
b) we could delete the sentence, or
c) explain a bit more why it is complicated.
I just googled for "privacy complicated concept" and found this link
from Stanford: http://plato.stanford.edu/entries/privacy/
There it says:
'
Discussion of the concept is complicated by the fact that privacy
appears to be something we value to provide a sphere within which we
can be free from interference by others, and yet it also appears to
function negatively, as the cloak under which one can hide
domination, degradation, or physical harm to women and others.
"
When I look at the Google search results it seems that it is also a
complicated concept for others. One additional reason why it is even
more complicated for us is since there is not such a rich experience
in the technical community with designing privacy into protocols.
That does not mean that I think other disciplines are easy.
I agree that it is complicated. As you mentioned above, there isn't
a rich experience in the technical community. Another reason why it
is complicated for us is that we don't usually deal with social issues.
I get the written version of "blank stares" when I ask whether a
draft raises privacy concerns. Frankly, it is unfair to ask an
author to address such concerns when there is very little material to
work from. How can "we" make that easier? Well, there is this IAB
document. The problem (as I see it) is that if I tell people that it
is a complicated concept, they will gloss over the concerns. I am
not telling them that it is easy. What I can say is that the topic
has been made accessible through an IAB document (the draft).
Why is this structure a problem?
I'll use RFC 6574 as an example. The document is easy to read. In
my opinion it should be accessible to the average reader. The design
considerations are clearly laid out. I read RFC 5218 and I came to
the same conclusion.
It's somewhat difficult for me to follow the flow of ideas. I would
not have noticed that if I didn't step back from the previous
revisions before reading the latest revision. It's not that the
draft is bad; it can be improved. Three of the authors are familiar
with the IAB style. I suggest using that style. It's better than
the IETF style. :-)
These are core concept in privacy and they have to be explained
somewhere. For example, whether something is personal data or not
determines whether the guidelines apply. Not all protocols deal with
personal data. You can essentially stop reading if you find out that
your protocol has nothing to do with personal data.
When we talk about personal data then the concept of identifiability
is certainly something that jumps into a discussion next.
Yes.
I don't want the reader to stop reading as he/she will ignore
stuff. I don't want the reader to jump to the guidelines section
without understanding the explanations in the draft. I cannot stop
anyone from doing that. However, if I make it easier, some people
might not do that.
Now, the problem is that the core concept has to be explained. The
linkage with the protocol aspect has to be crisp and clear.
In general, the threat model is an extension of RFC 3552.
The list of threats we have added after feedback from others that we
need to be a bit more specific about the threats in the Internet
protocol context. The available literature often talks about privacy
threats without making the distinction between the real of Internet
protocol engineering and what deployments impact.
So, what threats should be skipped in your opinion?
Difficult question. :-)
Thinking aloud, there isn't a compelling reason for privacy to be an
extension of RFC 3552. Maybe that's what making the work more
complicated. If there is a concern about confidentiality
(protocol-wise) it is up to the security folks to resolve that. The
privacy angle is different. Data minimalization, for example, is
applied even if there isn't an adversary to intercept the information.
I'll react quickly to the question. Surveillance, for example, is
something for the security folks to resolve. :-) The IETF already
has a policy about wiretapping. Stored data compromise is out of scope.
From the Misattribution Section:
"This threat can be mitigated by using identity management mechanisms
with proper forms of authentication (ideally with cryptographic
properties) so that actions can be attributed uniquely to an
individual to provide the basis for accountability without generating
false-positives."
You end up having to reconcile accountability and anonymity. From a
security point of view, you want to fingerprint everybody so that you
can identify the person you dislike and send him/her to jail. From a
privacy point of view, you want a person to be able to communicate freely.
I'll use NEA as an example. RFC 5209 has some material about
privacy. There is even an implementer considerations section. In
the IETF "we" talk about end-points. The user aspect (privacy) is
one step after that. It's not a technological issue.
It is not that simple. Just because we do not standardize user
interfaces does not mean they are not important.
Yes.
I guess we both agree that the interaction of the user with the
system is important (not only for privacy reasons). Just as an
example from an IETF working group charter:
"
7. Descriptions of usability and user-interface concerns related to this
work (informational).
"
The reason it is there is because of the subtle impact of the AAA
architecture on the user interaction. If you, for example, use a Web
SSO mechanism then you get a permission dialog presented from the
IdP before you release your personal data to the relying party. The
AAA architecture is, however, different in the type of communication
interaction and therefore such interaction between the IdP and the
user is relayed through the RP only through a standardized protocol
(EAP; not HTTP/HTML/JavaScript).
Ok, you'll need the user interface angle then.
While we cannot present super-long stories for every aspect in the
document we are still planning to write a few long example documents
(IPv6, for example, is one of them).
Ok.
I believe there is value in outlining what is typically part of the
work in the IETF and what isn't. Not everyone who reads our document
is familiar with the detailed scope of our work (which btw changes over time).
The problem is that there is value in keeping most, if not all, of
the draft. And that takes us back to complicated concept.
I do believe it is important to say where the boundaries of the IETF
work are and to state them because otherwise the next person shows
up and says that you have forgotten X, Y, and Z just because we
deleted it earlier due to your comments.
This is interesting. Maybe you could have the X, Y, and Z together
in a section.
Regards,
-sm
_______________________________________________
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy
