Subject: [ietf-privacy] Privacy Considerations for Internet Protocols (was: Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt)

From: SM <[email-masked]>
Date: Sat, 09 Jul 2011 10:09:09 -0700

Hi Frank,

I added a Cc to the ietf-privacy mailing list.  I suggest using that 
mailing list for further discussion.

At 13:04 08-07-2011, Frank Ellermann wrote:
>I'd like to have "privacy considerations" in all future I-Ds -
>it could be merged with the "security considerations" or even
>omitted as beside the point depending on the final RFC, but an
>indication in I-Ds that the authors "considered privacy" like
>"security" or "i18n" or "IANA" would be good.  If authors then
>decide that this is bureaucratic nonsense to be ignored for
>their purposes it worked as designed:  At least they spent the
>milliseconds to think about it.

draft-morris-policy-cons-00 discusses about Policy Considerations for 
Internet Protocols.  There is another I-D, 
draft-morris-privacy-considerations-03, that discusses about  Privacy 
Considerations for Internet Protocols.

The term "Network Access Identifier" is used in RFC 4282; it is the 
user identity submitted by the client during network access 
authentication.  A common identifier which is picked for user 
authentication is an email address as it offers uniqueness and it is 
easy for the user to remember.  That has privacy 
implications.  Disallowing "anonymous" (FTP) as the user name and the 
email address as the password does not solve the problem as 
credentials are required to access a protected resource.

Reality check, some users will:

  (i)   provide their email address

  (ii)  use [email-masked]

  (iii) pick a random email address which does not belong to them

The is ongoing work in the OAUTH WG on access to a protected resource 
using an intermediary which provides the access token.  That's one 
way to deal with the question of providing credentials to an unknown party.

draft-mayer-do-not-track-00 discusses about a HTTP header-based 
mechanism for users to express their preferences about 
tracking.  draft-vandergaast-edns-client-ip defines an EDNS0 
extension to carry relevant (client) network range information.

If you do not provide information within the layer, the information 
will be gleaned from other layers.  There are times when user consent 
is an explicit decision about the information to provide (see reality 
check) and there are times when it is an implicit decision; e.g. the 
terms of service that the user did not read.

If you would like to have "privacy considerations" in all future 
I-Ds, the above could get you started.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 9 Jul 2011 19:46:40 +0200

On 9 July 2011 19:09, SM wrote:

> I suggest using that mailing list for further discussion.

Thanks, I stripped APPS.  Not intending further discussions,
just confirming that "privacy considerations" can be a very
good things for apparently unrelated I-Ds, such as rescuing
FTP URIs from RFC 1738.

I'm vaguely aware of HTML5 discussions (reading four blogs)
wrt "do not track", but never looked into RFC 4282 before.

Similar for OAUTH 2.0, but as there is no "MD5" in it for
my test suite I never looked further into it.  I'm a user
of a quite sophisticated OpenID provider (xlogon.net), they
allow to create different "personas" for different purposes,
e.g., where a working mail address is required it is not
necessarily the ugly (but valuable) address I'm using now,
it could be a "public disposable" address @mailinator.com.

> draft-morris-privacy-considerations-03, that discusses
> about Privacy Considerations for Internet Protocols.

Interesting, but apparently not mandating some kind of
"privacy considerations".  I recall some [GeoPriv] last
calls years ago, which sadly didn't prepare me for the
precise geolocation with mobile broadband today - while
the application (browser) asked for my permission as it
should, I never allowed whatever enabled this beyond my
permission (at my wireless ISP, or another kind of magic
beyond IP-based approaches).

Regards,
 Frank

---

From: SM <[email-masked]>
Date: Sat, 09 Jul 2011 12:50:51 -0700

Hi Frank,
>beyond IP-based approaches).

There is a divergence between what is written in a RFC and what is 
implemented.  If "privacy considerations" was mandatory, some people 
might not know what to put in that, others will resort to copy and paste.

draft-hansen-privacy-terminology-02 discusses about 
terminology.  I'll quote a sentence from it:

   "Viewed in terms of the relation of the individual to social
    participation, privacy is the voluntary and temporary withdrawal
    of a person from the general society through physical or
    psychological means, either in a state of solitude or small-group
    intimacy or, when among larger groups, in a condition of anonymity
    or reserve."

Once the individual seeks to communicate with someone else or to 
access content through Internet protocols, some information about the 
individual is communicated.  Some form of consent is 
required.  Applications, e.g. browsers, dumb down requests for user 
permission for usability reasons.  That doesn't always translate into 
informed consent.

Going back to the sentence quoted above, for the individual 
interacting in one or more small groups, if the concern is about 
keeping interactions within these small groups segregated, we would 
be talking about unlinkability.

I guess that the starting point would be to get the privacy 
terminology document published as a RFC.

Regards,
-sm