Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 03 September 2015 13:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AF21B4993; Thu, 3 Sep 2015 06:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Zl5CaLaOa7; Thu, 3 Sep 2015 06:19:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209D31B46A0; Thu, 3 Sep 2015 06:19:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC94ABE77; Thu, 3 Sep 2015 14:19:37 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMRnX5Wreg1c; Thu, 3 Sep 2015 14:19:31 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F98DBE4D; Thu, 3 Sep 2015 14:19:31 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441286371; bh=QVP/TqNQRHm1/6lHW2sW/uXjXuAMumae8/tsE+C51HQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4ohivpHcwaq/oIvW1Qd9sMSViPAtToFJgn5WMigluVI/xc9o5SOEc7c2RzWqHnAtr mHFLG8iUazr0ZEyyEmSQ1R8nQDcIzgrkZ5bDI71S5amQruQA6wa8xCS9G731RVCJ6I okdaOitcXG/92qitL0OIqsv7Krd3PLuo5vnPS6r8=
To: Alissa Cooper <alissa@cooperw.in>
References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <CAFC1CD0-43EE-4F40-A755-C51D610FBD9A@cooperw.in> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <55E848E3.10403@cs.tcd.ie>
Date: Thu, 3 Sep 2015 14:19:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/U-ahXciRq_9L5VqXPvgJFFJdTTM>
Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde <dret@berkeley.edu>, IESG <iesg@ietf.org>
Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geopriv/>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2015 13:19:53 -0000

scroll on down...

On 03/09/15 14:14, Alissa Cooper wrote:
> 
>> On Sep 3, 2015, at 5:28 AM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie>; wrote:
>> 
>> 
>> Hiya,
>> 
>> On 03/09/15 13:23, Alissa Cooper wrote:
>>> Hi Stephen,
>>> 
>>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell 
>>>> <stephen.farrell@cs.tcd.ie>; wrote:
>>>> 
>>>> Stephen Farrell has entered the following ballot position for 
>>>> charter-ietf-geojson-00-01: Block
>>>> 
>>>> When responding, please keep the subject line intact and reply
>>>> to all email addresses included in the To and CC lines. (Feel
>>>> free to cut this introductory paragraph, however.)
>>>> 
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found 
>>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>
>>>> 
BLOCK:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>
>>>> 
This seems like a fine thing to do, but I have one
>>>> concern I'd like to chat about before we go ahead.
>>>> 
>>>> I could buy the "no privacy issues here" argument except for
>>>> the last sentence which says: "As the WG considers
>>>> extensibility it will be careful not to preclude extensions
>>>> that would allow GeoJSON objects to become location objects
>>>> unless the group determines such extensibility would be
>>>> harmful." Aside from being hard to parse, that seems to mean
>>>> that some extensions could mean this format does become a
>>>> RFC6280 Location object, which would then bring in the privacy
>>>> and security issues, previously argued to be out of scope.
>>> 
>>> Maybe this is a verb tense problem, but I think the points of
>>> the entire paragraph in question are:
>>> 
>>> 1) the format the group intends to create is for representation
>>> of things that are not location objects 2) even so, depending on
>>> how the format is specified, it may be possible for them to get
>>> used in ways in which they become location objects, in which case
>>> the privacy and security considerations kick in 3) in defining
>>> how to make the format extensible, the group does not want to
>>> preclude (2) in the future, but 4) the group will not be defining
>>> specific extensions to achieve (2).
>>> 
>>> Here is a re-phrase that tries to capture this better:
>>> 
>>> The WG will be careful to craft its extensibility mechanism such
>>> that extensions that would allow GeoJSON objects to become
>>> location objects are not precluded, but will not be defining such
>>> extensions itself. Should such an extension be needed,
>>> re-chartering will be required.
>>> 
>>> Is that better?
>> 
>> Yes. Definitely clearer.
>> 
>> However, the "not precluded" is a bit troubling still.
> 
> I think the thing is that you don’t want to specify this format such
> that it could never describe the location of a person or a device,
> because that would be an a priori limiting constraint on its utility.
> So the point is to leave the door open via the extensibility
> mechanism, but not design specific extensions to do this (unless
> there’s a re-charter).
> 
>> 
>> Let me try get to it this way - in the following timeline who/when 
>> would address the security/privacy issues and how'd we be
>> confident that'd really happen?
>> 
>> t1: This WG does it's planned stuff. t2: The foo-protocol uses
>> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't
>> consider security/privacy as geojson doesn't create location
>> objects
> 
> I think consideration for privacy/security could happen at t2
> depending on how the foo-protocol uses the geojson object. So in this
> case we would rely on the remit of the foo-wg (this is the "When a
> GeoJSON object is used in a context where it identifies the location
> of a Target …” sentence).

But at t2, the foo-wg doesn't know that a geojson object can e.g.
include my photo or FB name or whatever so they can't take that
into account.

> 
>> t3: This WG defines how to annotate a location with an identity 
>> thus creating location objects
> 
> Then certainly at t3 the geojson WG would address privacy/security.
> And this would be after re-charter.

Even if that re-charter says to consider the foo-protocol and
the bar-protocol, it'd likely be too late to handle things well.

On balance I think I'd argue that this charter would be better to
just say "no security/privacy stuff needed" (as it currentlyu does)
but to not get into extensibility and how that might affect privacy
at all.

Cheers,
S.


> 
> Alissa
> 
>> 
>> Ta, S.
>> 
>> 
>> 
>>> 
>>> Alissa
>>> 
>>>> I think that's a contradiction. As it happens, I also think
>>>> that, despite folks best efforts, RFC6280 isn't an architecture
>>>> that worked out that well, so I'd not suggest that this wG try
>>>> emulate that with square brackets. Instead, I'd suggest that
>>>> this WG be chartered to never take on work with does have
>>>> security or privacy consequences (without a re-charter).
>>>> 
>>>> That'd maybe mean a change in the last sentence such as:
>>>> 
>>>> OLD:
>>>> 
>>>> As the WG considers extensibility it will be careful not to 
>>>> preclude extensions that would allow GeoJSON objects to become 
>>>> location objects unless the group determines such
>>>> extensibility would be harmful.
>>>> 
>>>> NEW:
>>>> 
>>>> In order to continue to validly avoid having to deal with the 
>>>> security and privacy issues that would arise, this WG will not 
>>>> define any extensions that would have the effect of making a 
>>>> geojson object an RFC6280 location object or location
>>>> information as defined by RFC3693.  Should such an extension be
>>>> needed, re-chartering will be required.
>>>> 
>>>> My propsed NEW text is very clunky so probably needs
>>>> improving.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ Geopriv
>>>> mailing list Geopriv@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>> 
>