Hi SM,
On Sep 3, 2012, at 1:33 PM, S Moonesamy wrote: > Hi Hannes, > At 23:39 02-09-2012, Hannes Tschofenig wrote: >> A few comments: > > Thanks for the feedback. > >> * You cite RFC 3365 with regard to what privacy means. RFC 3365 has a very >> limited view on that topic. > > Yes. > >> * PII and personal data: In >> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 we try to use >> the term "personal data" and define it as >> >> 'Any information relating to an identified >> individual or an individual who can be identified, directly or >> indirectly.' >> >> We did that to avoid having refer to back to some laws where the >> interpretation changes from context to context and also over time. > > There is the "USDC" reference in the draft about a (legal) ruling which is an > interpretation of the law in one jurisdiction. I found it difficult to > develop an argument from there for reason you mentioned above. Some > questions which came to mind are how or whether PII and "personal data" fit > together and which term to use. There are more documents that exist making this statement. In the technical community there is no need to convince anyone that an IP address can be used to indirectly identify a person (typically through various database resolution steps). As such, I don't think there is a need to cite anything here. > >> * Section 3 and 4: I guess that these two sections have the goal to point >> out that these identifiers may, depending on the context, allow individuals >> to be identified. > > Yes. > > From a protocol perspective, the question an author might have to answer is > whether usage of an identifier triggers privacy concerns. The author might > ask whether an identifier can be used. If I say: > > "Any information relating to an identified individual or an individual > who can be identified, directly or indirectly." > > there may be blank stares. That's not to say that the definition is > incorrect or that it can be improved. Interesting. I thought that this is already fairly good. > >> * Section 5: The right amount of information >> >> I believe what this section should say is that there are situations where >> one would like to provided information to the recipient so that a response >> can be provided and in other cases that's not desired. For example, in >> today's telephone system you can hide your phone number. Similarly, in SIP >> there are ways to prevent all information to reach the recipient. > > I will see how to fit in the following sentence in Section 5: > > There are situations where one would like to provided information to the > recipient so that a response can be provided and in other cases that's > not desired." > > I read about several identifiers, including the phone number for SIP, when I > wrote the draft. I decided to avoid SIP as I could not find a definition > similar to "where" or "to whom" which the average person might grasp easily. The typical reader of an IETF draft is certainly not an average person. In fact it is probably a good thing that they do not read them... > I'll comment on the telephone system as an example. Let's say that you call > me and you hide your phone number. We can still have a conversation; a > response can be provided. Now, why can't I hide my IP address when I go to a > web site? We both know the argument. That gets you to: why does the > Internet work like that? Well. You can hide your IP address to a certain text. What gets hidden with the IP address depends whether you use systems like Tor, VPNs, NATs, IPv4 / IPv6, etc. > >> So, the question isn't really about all or nothing but it is about the >> ability for the user to decide about the context when they want to reveal >> information and when they don't. > > That's another way to look at it. Let me put it differently. We don't ask > for consent to reveal the IP address. That's the all-or-nothing proposition > for communication over the Internet. You may not ask "Do you want to reveal your IP address? YES / NO". However, what a user may want to do is to get a software it has confidence in that it preserves a certain degree of anonymity. They may, for example, download Tor (or a similar software from other groups). Then, these software developers should still be given the option to provide those users who care about their privacy to set the options correctly so that they get what they want (potentially with an impact on the service quality). > We could argue about having a "trusted" middle so that the user does not > have to reveal the IP address. We end up putting into question an > architectural choice on which the Internet is based. I used the following as > the argument: I don't think that we are questioning the Internet architecture as such. For example, with onion routing you essentially have various forms of trusted intermediaries. With IPv6 and with MAC address generated interface identifiers you have a much stronger form of re-identification in IETF protocols than you had before and so it is OK to think about the privacy implications. > > "There is an implicit assumption that the underlying protocols are > transmitting the right amount of information needed for the > protocols to work." That's true. The idea is that the open standardization process in the IETF leads to technologies that exercise data minimization because different stakeholder with different interests participate in the standardization activity and therefore avoid excessive and unnecessary sharing of data. This of course assumes that there is some understanding of what privacy is and what goals we may want to accomplish. > > The "amount of information needed for the protocol to work" is debatable. Definitely. The contextual nature makes it very difficult for certain protocols to make a clear cut. Then, there are other ways to deal with this situation - as we had been trying to do in Geopriv with user preference indications. > It comes down to a technical choice where we may decide that it is necessary > to transmit the IP address at a different layer to address a performance > issue. The question I might ask the user is: > > Do you want to share your IP address to make your communication faster? It is true that there is a performance difference when you compare Tor with direct IP communication. It really depends on the specific case (the type of privacy threats you want to prevent) whether direct communication is better than not. In the VoIP case, for example, it may be better to have a trusted intermediary to hide your SIP URI etc. but media should not traverse the same infrastructure. > > The usual answer would be yes. I'll reword your comment as follows: > > it is about the ability for the user to decide about the context when > they want to reveal information and when they don't, in all fairness. For many cases that's correct. If the technical basis is not there that allows the user to enable/disable privacy protection as they switch from context to context then it becomes difficult. > > There are too many tangents to that. There is also the question of whether > the average person can take an informed decision. Many of the privacy laws a build on the basis that someone is able to make that decision - either it is the end user or someone on his / her behalf. Think about children. Typically, you would assume that their parents make that decision. Then, in many cases we (you and me) also use tools to outsource some of the decision making and to delegate it to people we trust. For example, if you download Ghostery or Adblocker for usage with your browser you decide to rely on specific companies to decide what to block and what not. > >> There is no doubt that it is difficult to decide about the right amount of >> information disclosure. But should this be the justification to always >> reveal everything? > > That's the hard question. > >> I agree that there is an asymmetry of power between the user and the entity >> offering services (which makes the situation worse). > > Instead of answering the previous question I would tackle the matter from the > asymmetry angle to equalize the two ends. It would be described as an > admirable and ludicrous goal. > > There is something interesting, for me at least, in RFC 3365. Section 6 of > that document is about the Danvers doctrine. The IETF community has not > taken a position on "must avoid privacy concerns in all protocols". That > makes it more difficult to tackle the question. That's a good point. We had been discussing this issue while working on the privacy considerations document and we said that we wouldn't mandate anything (particularly since the enforcement would only come through the community and through the IESG - not the IAB). Particularly at the early phase of our work on the privacy guidelines we weren't quite sure whether the level of privacy understanding is actually mature enough. However, some time has passed and the privacy guidelines document is stable now. So, it might be interesting to hear what the community thinks. Ciao Hannes > > Regards, > S. Moonesamy _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
