Hi Dave, Thanks for your response. We discussed it within the privacy program and the full IAB. I've added the following sentence to the end of the intro in section 3 in the pre-publication -09 version: "Examples of several different brief definitions are provided in RFC 4949." I realize this may not fully assuage your concerns, but we thought it might help to point out the brief(er) definitions in 4949. Notably, even that document gives three different definitions of "privacy" and none of them are a single sentence long, reflecting the difficulty of trying to boil down the multiple facets of the concept. To your point about privacy versus security, I'm not sure there is more we can say beyond what is in sections 4 and 7. Thanks for your thorough review. Although we have a few differences of opinion, I'm glad that you seem to think the document has value. Best, Alissa On Apr 17, 2013, at 8:15 PM, Dave Crocker <dcrocker@xxxxxxxx> wrote: > Alissa, > > > On 4/17/2013 10:23 AM, Alissa Cooper wrote: >> Hi Dave, >> >> Just wanted to make sure you saw this. I plan to submit the document >> to the IAB for publication approval next week. > > > hmmm. I did see it, but now I can't find your original response, which > is probably why I didn't followup. So thanks for the re-probe. > > I've left a few snippets from your reply at the end, as basic context, > but I'll just comment in summary, rather than in-line. > > The summary of the summary is pretty simple: I do understand the > history, complexities and even controversy that make it difficult to > document specific choices, such as defining privacy. But I submit that > due diligence for a document like this obligates the IAB to take some > basic, solid positions, in the service of making its guidance useful. > > > 1. Audience > > We often wind up writing documents that work best for people who are > already relatively familiar with a topic. As you know better than most, > writing for those new to a topic is a significantly different task. I > certainly agree that it's challenging but I see it as the essence of > this draft. > > That is, I believe you intend this document primarily for those who > are less familiar with discussion and practice of "privacy" > considerations. But this must begin with an understanding that they > don't really have a reliable, workable definition of the term. > > There are many different definitions and you note that even on the > IAB, for this draft, it has been challenging to settle on a definition. > I'll submit that that should alert you to the increased need for this > document to offer a single, useful definition, rather than to cause you > to shy away from it. > > > 2. Definition. > > The alternative that you've left the reader with is to have a basic > lack of comfort with the topic and a certainty of inconsistent > definition. All the good guidance later in the document will depend > upon an inconsistent sense of when to apply it. > > In addition, the directive that they derive their version of the > definition from the detail later in the document is -- forgive me -- > simply unreasonable extra work. It's the sort of thing done for an > academic texbook, not a guidance document. This draft is an operational > tutorial, as well as a set of guidelines. Tutoring for application > starts with explaining terms and "privacy" is the most essential term to > define. > > The exemplar definition I provided should be modified to cover > 'organization' data as well as personal, but I think it's viable as a > working form. That said, I don't care whether you use it, as long as > the document provides a meaningful definition that gives the /average/, > uninformed reader a pragmatic sense of what is inside the scope of > privacy and what is outside. > > > 3. Privacy vs. Security > > The fact that the two topics overlap or that one can be viewed as a > subset of the other or that... The fact that there is so much confusion > here again requires that the document give concrete guidance that > distinguishes what is security, as we use it for RFCs, and what is > privacy, as you intend to scope it for this draft and for future Privacy > Considerations work. > > My own view is that Security is largely a technical and mechanical > topic, while Privacy is primarily a human and social topic. Within the > IETF, we deal with security issues primarily in terms of algorithms and > component technology. I believe you intend Privacy to take a larger > view and think that's entirely appropriate, but also quite different. > > That privacy often plays heavily on the techniques of security does > present challenges. But, for example, I think that 'confidentiality' is > not 'privacy'. I'll state it differently: If the IAB cannot agree on a > meaningful and simple statement that distinguishes between privacy and > confidentiality, then it ought to reconsider giving expert advice about > the handling of privacy considerations. > > To repeat: In practice within the IETF, confidentiality mechanisms > are just that: mechanisms. They are component techniques for protecting > data against unauthorized viewing. I'd class privacy as a system-level > concern for protecting against leakage and unauthorized viewing. The > latter, of course, sounds like confidentiality. Frankly, I don't know > how to reconcile that. But then, I'm not writing expert guidance... > > d/ > > > > > > >>> Privacy is the concern for protecting information of or about an >>> individual person. >>> >>> Tweak this or replace it entirely, but /please/ provide a concrete, >>> pragmatic definition that explicitly defines what is in scope and >>> what is out, for them to focus their considerations on. >> >> This suggestion has been debated at length within the IAB privacy >> program over the life of this document. Our thinking is that trying >> to define "privacy" in one sentence would be as counterproductive as >> trying to define "security" or "extensibility" in one sentence. > > > >>> The typical writer and reader of RFCs is not experienced in the >>> topic of privacy. They won't know what you mean either: they >>> need very concrete guidance about the word's meaning. >>> >>> Telling me that different people mean different things with the >>> term merely assures me that I have no idea what /you/ mean unless >>> you tell me. Having each reader make guesses about the meaning is >>> a way to > ensure non-interoperability of the construct. >> >> Per my note above, the expectation is that the document as a whole > will provide a rich explanation of what is meant by privacy. > ... >>> Guidance can't be very helpful if the reader has no idea when to > apply it. >> >> If the reader is unsure about whether to go through the thought >> process outlined in section 7, there is no harm (other than the use >> of > the reader's time) in doing it and then finding out that a particular > specification is already solidly designed when it comes to privacy. > > > >>> I strongly suggest that any explicit privacy discussion be >>> required > to be an entirely separate from the 'security considerations' section. >>> >>> My reasoning is simple: This community sees 'security' in terms of >>> encryption and signing, traffic analysis, and other such >>> mechanical, relatively low-level components. Privacy is an >>> entirely different and > broader and more human beast, even when its details devolve to these > familiar mechanics. >>> >>> At the least, making it a separate section will help writers and > readers to distinguish privacy from the security stuff we are used to > seeing discussed. >> >> I think sections 4 and 7 demonstrate that privacy and security are > interrelated at least in some respects. > > > > >>> Not sure whether this is a question or a suggestion; if it's the >>> latter, I'm not sure what to suggest: privacy issues often >>> develop as a combinatorial problem -- 'correlation' as you note >>> farther down -- that > is, developing out of unpredicted integration of information from > discrete services. While any specific IETF specification might have its > own, direct privacy issues needing consideration, where should > discussion of these combinatorial dangers be discussed? >> >> That is a good question and I'm not sure I know the answer. Of >> course there is nothing to prevent people from writing drafts about >> the > privacy considerations associated with the combination of discrete > services/protocols. > > > > > > >>>> 4.1. Combined Security-Privacy Threats >>> >>> The fact that you have a string like "Combined Security-Privacy" > supports the view that Privacy Considerations is distinct from Security > and should not be in the Security Considerations section… >> >> Actually I think it's the opposite. Section 4 makes concrete > distinctions between privacy threats that are already commonly covered > by security considerations and those that are not. > >>>> 5.2. User Participation >>>> >>>> >>>> As explained in Section 4.2.5, data collection and use that >>>> happens "in secret," without the individual's knowledge, is apt >>>> to violate the individual's expectation of privacy and may >>>> create incentives for misuse of data. As a result, privacy >>>> regimes tend to include provisions to require informing >>>> individuals about data collection and use and involving them in >>>> decisions about the treatment of their data. In an engineering >>>> context, supporting the goal of user participation usually means >>>> providing ways for users to control the data that is shared about >>>> them. It may also mean providing ways for users to signal how >>>> they expect their data to be used and shared. >>> >>> There is a serious downside to this. It presumes that this burden >>> on users is reasonable. For many scenarios, it isn't. Rather, the >>> focus on user participation is often used as an alternative to the >>> difficult > work (or research) on mechanisms that require less user participation. >> >> I agree that sole reliance on user participation is undesirable. It's >> listed here as one of several protections, so sole reliance is not >> implied. For protocol design I would actually argue that we tend not >> to > think about user participation enough (whereas I agree that privacy > policy tends to focus on it too much). > > > > > > >>>> 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. >>> >>> While a generically reasonable view, the challenge with its >>> application in the IETF is our general tendency to think that we > understand UI and UX issues, although few in the IETF actually have the > background for it. For example we tend to think that simply giving > users more information is a universal palliative. Most discussions here > about "expected user interactions" are simply wrong. Worse, I've no > idea what to suggest to counter this for the draft. >> >> Yeah, I'm not sure the draft can fix this problem. But agree that >> it's a problem. > > > > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net >