Hi Med,
At 04:56 17-09-2013, [email protected] wrote:
One comment I have when reading this reco from your draft:
It is recommended that an identifier be used at the layer at which
its functionality is necessary for communication to be
established.
is, from a privacy perspective, there is no justification for it. If
the information is present in the packet, does it really matter if
it is used in other layers? Why reusing that info will impact the
privacy? Take the example of TCP that use the IP address for the
pseudo header checksum, SIP, SDP, etc. If you have in mind
particular identifiers, it would be valuable to explicit them rather
than having a generic statement.
The problem is secondary use (see RFC 6973 Section 5.2.3) and consent
[1]. The draft argues that consent is implicit if the information is
necessary for communication. If it is necessary to send out the IP
address in the TCP session, that does not mean that the protocol at a
higher layer can take it and put it in a header field. As an
example, please see Section 8.2 and 8.2 of
draft-ietf-appsawg-http-forwarded-10.
From a privacy perspective I can find out your approximate location
the source IP address used for your SIP call. There are times when
that can be embarrassing, e.g. you told your manager that you are
calling from work while the source IP address points to another
location. Let's say that we have to document the privacy
implications in our document. The reuse cases will be more work for
us as we have to think of more possibilities. The way to avoid that
is apply some form of layering when we tackle privacy.
The examples in Section 4 (of the draft) were chosen as the related
specifications explain what these identifiers are above. There isn't
any explanation in plain English for identifiers used in other
specifications. I could take the RFC 6973 approach and write a long
document. My guess is that people won't read it. :-) The approach I
adopted was to keep it simple. A generic statement can be argued
both ways. For example, you can argue that the identifier is
necessary at the higher layer without having to ask the user for
consent. I used "recommendation" instead of "requirement" so as not
to impose constraints.
If we take the example of an IP address as an identifier, even if it
is revealed in various layers, this does not mean that one single
individual/user is associated with that identifier. Take the example
of multiple machines behind the same CPE, or multiple subscribers
behind the same CGN, etc. Nevertheless:
* the configuration of a browser may be used easily to track user
(e.g., https://panopticlick.eff.org/)
* some application headers (e.g., referer) may contribute to ease
the correlation between many pieces of information (e.g., a web
email account and a social networking account for instance)
Discussing issues related to correlating information leaked by
applications would be useful to record in this document.
I commented about a draft recently (see
http://www.ietf.org/mail-archive/web/homenet/current/msg03100.html
). In a NAT scenario we cannot say that there is only one person
behind the CPE. The same applies to CGN. In an IPv6 scenario we can
narrow down (or might assume) that it is one person or device using
the IPv6 address. When the legislator writes the law the questions
that he or she will ask is:
(a) Does the IP address identify one person?
(b) Does the IP address identify the location from which the call was made?
Note that there is some ambiguity in the questions. The legislator
would like to have easy answers. This is where someone explains that
the IP address can be used to identify the person. For (b) the
explanation might be that the IP address can be used to identify the
location. It can be lead to events such as
http://www.tmz.com/2013/04/05/selena-gomez-swatted/
The browser sends a lot of information (re. the link you
provided). There are already some good questions in RFC 6973. I
chose not to discuss it in the draft to keep the discussion
simple. What I would like to see, for example, is what you did. You
mentioned that correlation can be a problem and you thought about
some other problems. I don't have the answers. However, it is a
step forward if you and I can talk about privacy and try and
understand how the identifiers can be used.
Regards,
S. Moonesamy
1.
http://www.cnil.fr/les-themes/internet-telephonie/fiche-pratique/article/ce-que-le-paquet-telecom-change-pour-les-cookies/
_______________________________________________
ietf-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
