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