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

From: Alissa Cooper <[email-masked]>
Date: Sat, 23 Feb 2013 12:10:40 -0500

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 23 Feb 2013 14:51:37 -0500

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

---

From: SM <[email-masked]>
Date: Sat, 23 Feb 2013 14:04:30 -0800

Hi Alissa,
At 09:10 23-02-2013, Alissa Cooper wrote:
>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?

Short answer, if nobody else said anything about the sentence I 
suggest leaving it as it is.  I'll send suggested text if I can think 
of something.

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

No, it isn't.

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

I agree with what you said above about difficulty.

How about taking a RFC 3552 approach?  If I understood that document 
correctly, it takes a tutorial approach to define common terms 
instead of using a terminology section.  Thinking aloud, maybe the 
problem is trying to keep privacy concepts and guidance together.  I 
would say, remove Section 2, see how that "breaks" the document and 
then take it from there.

Or maybe the problem is trying to reconcile data and communication 
model.  I'll comment (I am not sure when) on the privacy mailing list.

>Not all secondary uses involve disclosure (such as the example given 
>in 4.2.3). I have added a sentence to clarify this, however:

That would be the NEA stuff.

>"Secondary use encompasses any use of data, including disclosure."

Ok.

I gather that you know that there will be debates about whether it is 
disclosure or secondary use. :-)

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

I would avoid trying to develop a consent mechanism.  I was think of 
this more in terms of consent (of the user).

RFC 3552 starts by discussing the goals.  The question I would ask is 
what are the goals of privacy.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Feb 2013 21:23:32 +0200

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Feb 2013 14:55:40 -0500

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 25 Feb 2013 15:01:26 -0500

Hi Hector,

Just to clarify, do you mean ownership of personal data? Or something else?

Thanks,
Alissa

On Feb 25, 2013, at 2:55 PM, Hector Santos wrote:

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Feb 2013 15:26:06 -0500

Hi,  I would think both - ownership of the "things" and ownership of the 
medium moving, transporting, storing the "things."    Case in point:  I 
can write a protocol to move private data from point A to point B.  My 
first requirement is to make sure the design stipulates it stayed 
private, especially at the receiving end.  However, there is precedence 
where claims were made for ownership of the storage regardless of how 
temporary it may have been at the intermediary, a routed email for 
example.  Someone leverage a private email communications for their 
benefit by viewing the monitoring intermediate passthru transport data.  
I'm not sure how such a document as this prevent this. It would be more 
about ethics I suppose, but if a protocol was to consider this, a 
designer may come up with ideas to prevent or minimize it or leverage it 
even more.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 25 Feb 2013 15:35:34 -0500

It is true that claims of ownership rights, whether over data or transmission mediums, can have an affect on privacy. But as you say, I'm not sure what concrete guidance we can give protocol developers and implementers about considering ownership, since decisions about who owns what or who will be claiming ownership over what are made essentially independently from any decision about protocol design. Furthermore, I imagine that there is some contention about presuming that recipients of personal data are the owners. I would certainly be wary of including that presumption here, as it leads down the slippery "rights vs. harms" slope pretty quickly, and we've managed to avoid that altogether in this document so far.

Alissa

On Feb 25, 2013, at 3:26 PM, Hector Santos wrote:

> Hi,  I would think both - ownership of the "things" and ownership of the medium moving, transporting, storing the "things."    Case in point:  I can write a protocol to move private data from point A to point B.  My first requirement is to make sure the design stipulates it stayed private, especially at the receiving end.  However, there is precedence where claims were made for ownership of the storage regardless of how temporary it may have been at the intermediary, a routed email for example.  Someone leverage a private email communications for their benefit by viewing the monitoring intermediate passthru transport data.  I'm not sure how such a document as this prevent this. It would be more about ethics I suppose, but if a protocol was to consider this, a designer may come up with ideas to prevent or minimize it or leverage it even more.
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Feb 2013 18:51:13 -0500

Hi. I agree it is complex. Maybe your comments should be incorporated 
into the doc rather than ignore the topic.  I suggest the ideas of 
ownership can be conveyed into the other terms already defined, i.e. the 
$Attacker or $Eavesdropper can only be considered with these litigious 
profile only because they aren't "owners." These two terms were properly 
provided with negative connotations where the $observer was provided 
with positive connotations.  It describes some form of authorization is 
possible abeit from someone - an "owner?" The $initiator is the only 
entity that can be provided with ownership connotations.  Since this is 
not necessarily the case, all these terms can be different entities from 
a possible proposed $Owner entity.  I think it can be described while 
still keeping away from any "slippery slope."

Thanks

--
HLS