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. _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
