ietf
[Top] [All Lists]

Re: [IAB] Call for Comment: 'Privacy Considerations for Internet Protocols'

2013-02-25 13:58:10
Hi,

Related to your question, if it wasn't done already, I think there is one item to consider or define - $Owner(s) and/or $Ownership. (I don't see any terms like owner, ownership in this document). The US ECPA has evolved with additional new laws, some as the "Good Samaritan" provisions, relaxations and also there has been new challenges and in my assessment it was primarily based on long adhered ownership principles. Just like employers enjoyed many US ECPA privacy exemptions, the Googles, Facebooks and other 3rd party service bureaus have also used "ownership" justify their leveraging of user data - "its our network and equipment...."

I think the $intermediary term touches base, but i don't see it describe nor the $initiator being related to the owner of things.

Ownership is very fundamental when we look at the natural ethical design considerations, this should be one of the tenets of the document, in my view. Recognized ownership has a very vital effect on what a protocol may|can|should offer or not offer as to not open Pandora's box.

--
HLS

On 2/24/2013 2:23 PM, Hannes Tschofenig wrote:
Hi Hector,


On Feb 23, 2013, at 9:51 PM, Hector Santos wrote:

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?
Yes, that's the goal.

As you know, the IETF develops specifications that are used on the Internet and 
not just in a specific region. Trying to interpret national laws and to provide 
region-by-region specific guidance did not seem desirable to us.

  Do you feel you have reached providing such "Global Common" guidelines in the 
area of privacy?
Yes, I think so and this document follows the spirit of RFC 3552 "Guidelines for 
Writing RFC Text on Security Considerations". This document is essentially the 
privacy version of what RFC 3552 is for security. If you look at RFC 3552 you will also 
fail to find references to regulation on security matters (even though they exist).

We did look at many documents that seemed relevant input, such as the mentioned 
OECD document, and we spoke with data protection authorities and solicited 
their input. Our job would have been easier if we could have just re-used one 
of these documents listing the privacy principles. Unfortunately, it turns out 
that these documents were written for a different audience and that audience is 
supposed to have different capabilities regarding the design and the deployment 
of their services. In the IETF we do not have the same degree of freedom and 
impact and so we developed these guidelines to the best of our capabilities.

  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.
What is interesting for us to find out whether you believe that the Electronic 
Communications Privacy Act has for additional privacy aspects we need to 
address in the document.
It is not our goal to interpret specific regulatory documents (even though it 
is interesting). This is the (well-paid) job of many lawyers.

Ciao
Hannes

--
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