Re: [ietf-privacy] Is there an official working definition for Privacy Online?

Robin Wilton <> Thu, 05 May 2016 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03B9C12D7A6 for <>; Thu, 5 May 2016 06:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A9mQWrKKKJuS for <>; Thu, 5 May 2016 06:49:58 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA4A212D6E1 for <>; Thu, 5 May 2016 06:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uZXv3VTmqoI/ak4N0ZC0UPCX3s8Druc9xhhtv1vRH9w=; b=ms7pXcrFNZE4DGZpFu2rom9aCejH+gvYVCYfwLakuvbAgNtSqXOmZZ6Dv4q0jdqcl+r/vfTAX+5e8qu40H0ktj89B6gXOhmH58PgMd13UFsd5SU7+mMJ0rhXs8DY0tE7N6mv17PdXZZZWKiAiQ/VqK5iyLo8n21emdlqaVOcvIY=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.485.9; Thu, 5 May 2016 13:48:27 +0000
Received: from ([]) by ([]) with mapi id 15.01.0485.011; Thu, 5 May 2016 13:48:27 +0000
From: Robin Wilton <>
To: Stephen Farrell <>
Thread-Topic: [ietf-privacy] Is there an official working definition for Privacy Online?
Date: Thu, 05 May 2016 13:48:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <015a01d0798d$509954c0$f1cbfe40$> <> <> <029801d1a4b9$c3b57850$4b2068f0$> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: c073d22e-b784-4926-37c2-08d374ebef63
x-microsoft-exchange-diagnostics: 1; SN1PR06MB1838; 5:71eJ+29FOuKV8s10XnKAKOIPrWIKfdkU4+mazqtdFHr1f9lKB+X6zxHhl5JDvDjfApfk/ImKoWPf5pQvH7VQK5vHAfBOCjUCBq8MPwa138pqrGvQjmKMzc6jzZRgzZDTot+sWcEWMWlb4CvZuUPh1w==; 24:2G//VFA8ALGfMks1izb78NaA6rb4CMfD7x61/cq0P+GuqN8ZwGCIiTHWgIRDyRA5WPPXLFJ0OhZHAiwDNb7H5pWT952gl9dkzIgG1wCtA7s=; 7:kUfyW6pklxLYyU0rTLLiP+pgIxPgGMYxQ9dFXEZxwujswmculFCzHhKfdRE3IR4ESTi559JpI+2yvLw/kXT+vu236lViPj+0ebU7aqQAYVKpxFeRU44FrpxaLsillDmUty9QrF/aAxGEyZQqxGCFN308NW7wAbohQFL7n3Ai1x4i1McN6Ai3pCIdmQ3GyKhX
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1838;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(209352067349851);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(9101521098)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1838;
x-forefront-prvs: 0933E9FD8D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51444003)(24454002)(87936001)(83716003)(10400500002)(5004730100002)(99936001)(11100500001)(5002640100001)(3280700002)(54356999)(4326007)(3660700001)(2906002)(50986999)(92566002)(5008740100001)(93886004)(81166005)(586003)(8936002)(2900100001)(76176999)(1220700001)(2950100001)(106116001)(3846002)(6116002)(102836003)(15975445007)(110136002)(99286002)(19580405001)(82746002)(189998001)(77096005)(122556002)(66066001)(33656002)(86362001)(19580395003)(1720100001)(36756003)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1838;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_9C951076-44CC-4E77-A067-4606BE5B85E7"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2016 13:48:26.9265 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1838
Archived-At: <>
Cc: "" <>, Josh Howlett <>, "" <>
Subject: Re: [ietf-privacy] Is there an official working definition for Privacy Online?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 May 2016 13:50:06 -0000

2 comments inline… 
> On 5 May 2016, at 14:30, Stephen Farrell <> wrote:
> On 05/05/16 14:20, Dave Crocker wrote:
>> On 5/5/2016 1:30 AM, Robin Wilton wrote:
>>> Privacy can also be a subjective thing (for instance, some people
>>> think it's important to draw their curtains in the evening - others
>>> don't). That subjectivity makes privacy a highly contextual thing,
>> This is an Alice, Through the Looking Glass perspective on the term.
>> At the least, it means it is not a technical term, in which case using
>> it in technical contexts is mostly going to cause confusion, since one
>> speaker's intended meaning will differ from another listener's...
>> Standards work is primarily an exercise in gaining group consensus on
>> technical specifics.  If 'privacy' is to be a technical term, then we
>> need to agree on its specifics.  That doesn't mean the term needs lots
>> of fine-grained detail.  In fact, for something this important and this
>> basic, it needs as little detail as possible, while still serving to
>> guide technical choices.
>>> Privacy is about retaining the ability to disclose data consensually,
>>> and with expectations regarding the context and scope of sharing.
>> ...
>> This looks like an entirely reasonable and helpful definition, as I
>> noted a year ago.
> It's definitely not bad:-)
> I think it misses a bit though, in our context. Sometimes we just
> have to expose an identifier (e.g. a source IP address) and that
> can be privacy-sensitive, but there's no real way in which it's
> consensual, unless one considers even connecting to the network
> as consenting in some form to such exposure, which'd be odd I
> think.
> So while Robin's text is pretty good when I think about payloads,
> it doesn't seem to cover issues with meta-data and other protocol
> artefacts so well. I'm also not sure how much that'd help when it
> comes to considering re-identification issues which can be very
> subtle (cf. netflix competition).
> But it's a good start.

Thanks, Stephen - 

Very good point… metadata was definitely on the radar back then, but not high enough to feature explicitly in the definition.

I think subsequent discussion about “each layer of the network only exposing such data as is needed for it to function” goes a certain way in that direction, but you’re right, it would benefit from higher visibility.

>> There are other, similarly short and focused, definitions. Each is
>> reasonable.  And while the differences in the definitions probably
>> matter, I think that the need to focus technical work requires choosing
>> one.  If we want the term to have useful substance.
>> The fact that choosing one has some challenges is being used as a reason
>> for not trying.  That's an ironic excuse, for an organization whose
>> primary reason for being is the development of community consensus on
>> non-trivial choices...
> I'd be happy if someone wanted to try craft some definitional text
> say in an I-D, with the goal of meeting Dave's challenge to define
> privacy in a way that's useful for IETF work. I don't know
> if that'd end up as an RFC, but it might, and if well-done, and if
> it garnered consensus, it could be quite useful.

I’d be happy to work with Dave and others on draft wording...

> Cheers,
> S.
>> d/