Hi, with a quick review, and many comments and points, I think the one
single part that I would have some questions about is in the intro:
The guidance provided in
this document is generic and can be used to inform the design of any
protocol to be used anywhere in the world, without reference to
specific legal frameworks.
Is that a goal? Do you feel you have reached providing such "Global
Common" guidelines in the area of privacy? How does it compare to US
ECPA provisions for "User Expectations" which has served as a global
model for other jurisdictions?
The reason I ask is because I have been very sensitive to ethical design
and product liability issues in our product lines since 1986 following
the guidelines set forth by the US ECPA for:
- Thou shall not block/reject things without user knowledge,
- Thou shall not tamper/edit things especially when passing things (relays),
- Thou shall kept private things private.
This was considered "Global" once upon a time. Now its arguable.
--
HLS
On 2/23/2013 12:10 PM, Alissa Cooper wrote:
Hi SM,
Thanks for your comments. Some responses are inline.
On Jan 30, 2013, at 7:29 PM, SM wrote:
At 14:30 16-01-2013, IAB Chair wrote:
This is an announcement of an IETF-wide Call for Comment on 'Privacy
Considerations for Internet Protocols'.
The document is being considered for publication as an Informational RFC within
the IAB stream, and is available for inspection here:
http://tools.ietf.org/html/draft-iab-privacy-considerations
In Section 1:
'With regard to data, often it is a concept applied to
"personal data," information relating to an identified or
identifiable individual.'
I suggest rewriting the above sentence.
The authors have re-written that sentence several times and in different ways
already. Do you have a specific suggestion about how to improve it?
"Many sets of privacy principles and privacy design frameworks have been
developed in different forums over the years."
There is also some work in the APEC region (see
http://publications.apec.org/publication-detail.php?pub_id=390 (payware)).
As far as I know the APEC framework is one of many frameworks (none of which we
cite since there are so many) based on the OECD-style FIPs. Is that incorrect?
As a nit, the draft-ietf-geopriv-policy-27 reference should be RFC 6772.
Fixed.
I read some of the previous versions of this draft. The Abstract Section
describes the document as providing guidance for developing privacy
considerations for inclusion in protocol specifications. I found the draft
difficult to digest. I suggest simplifying the draft to make the guidance
accessible to the target audience.
I'm not quite sure what you are recommending here, but we have had
conversations in the IAB privacy program about moving the guidance part up, or
otherwise trying to make the focus on the guidance piece more prominent. The
difficulty is that there is a broad range in the extent to which potential
readers are familiar with privacy concepts, so jumping straight into the
guidance would not be appropriate for some portion of the audience. If you have
concrete suggestions for how to simplify, those would be helpful.
One of the issues nowadays is what to do about intermediaries. If I am not
mistaken RFC 3238 was one of the first documents to tackle that question from a
privacy perspective. There have been a few proposals to introduce
intermediaries as part of the architecture (I am using the word is used
loosely). It is easy to argue for intermediaries based on use cases. There
was a case recently where the users only became aware that they have signed up
for using an intermediary through the EULA.
The draft introduces the concept of secondary use (Section 4.2.3). Strictly
speaking, it is a disclosure (Section 4.2.4).
Not all secondary uses involve disclosure (such as the example given in 4.2.3).
I have added a sentence to clarify this, however:
"Secondary use encompasses any use of data, including disclosure."
The draft mentions consent in several places. The authors are likely aware
that consent was a hot topic for DNT. It's easier to start with something that
is easy for the average person to understand and build from there. Section 7.2
could more about consent instead of user participation or control.
We tried to think of a case where a consent mechanism was actually developed in
the IETF, but as a general matter consent mechanisms tend to be out of scope,
which is why we focus more on user controls (which still show up rarely but do
show up).
Thanks,
Alissa
Regards,
-sm