Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds

Adrian Farrel <adrian@olddog.co.uk> Mon, 01 February 2021 20:28 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5C3A145F; Mon, 1 Feb 2021 12:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZlpZcKW1f3lZ; Mon, 1 Feb 2021 12:28:15 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157A03A145E; Mon, 1 Feb 2021 12:28:12 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 111KSAh1014355; Mon, 1 Feb 2021 20:28:10 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ADC7D22044; Mon, 1 Feb 2021 20:28:10 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 9868F22042; Mon, 1 Feb 2021 20:28:10 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.201.183]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 111KS98v028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 20:28:10 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Randy Bush'" <randy@psg.com>
Cc: <opsawg@ietf.org>, <opsawg-chairs@ietf.org>, <draft-ietf-opsawg-finding-geofeeds@ietf.org>
References: <06bf01d6f884$18acfd10$4a06f730$@olddog.co.uk> <m2h7mvfv0p.wl-randy@psg.com>
In-Reply-To: <m2h7mvfv0p.wl-randy@psg.com>
Date: Mon, 1 Feb 2021 20:28:08 -0000
Organization: Old Dog Consulting
Message-ID: <075b01d6f8d8$c189db70$449d9250$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFV2pWrMD8L80NxalLEZfAag+BYoADWfMLtqz8+NlA=
Content-Language: en-gb
X-Originating-IP: 87.112.201.183
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003
X-TM-AS-Result: No--3.585-10.0-31-10
X-imss-scan-details: No--3.585-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--3.584600-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbI61Z+HJnvsOIj/yNb3TyWdzv5uglk3O3ylc g6zmOeBGFko6OvLNpDP+/cfzqw3RXtA18qcHeGs/AkW6JTMS9Iw7GNv1BBu35JqJlhRqJEmkVhY Zjy1spv7dXcM2dsgV1igolYHtwn7AkwH4NjNdKLWIf3m0sUfx53cEoz5ZZVPj31GU/N5W5BA0ln zX2yER2gBwzlMHnd4itzx/NGs3xVwy7yxTnyruH0GwNTQDBmK4sb2x5zTl2EG8R/gT2rHyD+K/k 578W+0NDiI0Nf5Rv9XGljl9xdOl4TcnxLnjDSYFXK5keCa+bmhRwfT2oEaYdDhdESD0qLXT1jqf 1r9/odbgOlORWSzsM07VKm6ozDdhafFVMpfEiu3M1jffIgQXhpRRlLuwwc4YBthzL1hCXp50Vlw t7NFUH10judJ2px9ZJ3tygEYIblGwk2ceO9w6ifRUId35VCIe/qWl+m17jWFDxRz4rfQjRnW7HS PhvJoSV+lCDzhvoi2uQ6I+8huFgm3LHGiNPUiE3nHtGkYl/Vp9iuvWn3J8KrEtLGRAe3PGCw+a5 bqJz+irlP1qvpAXKY+puIYEjzDF3NeWIGF0vmMM6z3iDvziB8nlJe2gk8vIh70hwvbiYSBO6Uab KTpD1a0VYyvgULK2mg54RmuR1ezbfsHllEVJTuUKNN5hHcAB6mfKLabvuvgINpIFnbd6mtpPMEm Gzz3Z4uMZycXDp6ZGkjdFiy2u3NFx3T4w4JQ6pqbreSinCdMOZNXmvnJaesQ/OmGf7mPlMBup69 F09Y+XUzspP39qoJ/Wcgx8s9Yd8Q9MdDeTdNKeAiCmPx4NwBaLWfA4qcOBi2QFaYS1v20qtq5d3 cxkNQwWxr7XDKH8z9ZFWOXT08gEEpVqwp2NjPTqf8aa9anUS6LC52v/UTw2luC2S0zFVUHaYOer MCR6Q9Tm6OzhiW9CPKhH70zbI4SwU2dLeWv1JeJ1WMCERkGtftyYo2KwDjKpoRvzNKOP9DB8M7t iaMAWbf9vijls8w==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Oz2AXjgPnM09wdGinqdADLVrLSg>
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2021 20:28:17 -0000

Hi Randy,

Thanks for engaging, and I know I presented an "interesting" challenge.

8805 was, of course, an Independent Stream production. So I carry as much
responsibility as anyone else for the lack of privacy discussion. But, more
significantly, I am entirely responsible for not having noted section 4 of
RFC 8805 when I wrote my email - oops.

So perhaps modifying your paragraph to...

    RFC8805 geofeed data may reveal the approximate location of an IP
    address, which might in turn reveal the approximate location of an
    individual user.  As noted in section 4 of RFC8805, publishers of
    geolocation feeds are advised to have fully considered any and all
    privacy implications of the disclosure.  Further, operators who publish
    geolocation information are strongly encouraged to inform affected
    users/customers of this fact and of the potential privacy-related
    consequences and trade-offs.  In publishing pointers to geofeed files
    as described in this document the operator should be aware of these
    privacy concerns and be cautious.


That would just leave me asking whether everyone was happy with the
normative reference to a non-IETF RFC. It seems a little odd that the IETF
didn't want to publish 8805, but is chipper about publishing this document.
But, I'm not bothered by this.

Cheers,
Adrian

-----Original Message-----
From: Randy Bush <randy@psg.com> 
Sent: 01 February 2021 19:28
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: opsawg@ietf.org; opsawg-chairs@ietf.org;
draft-ietf-opsawg-finding-geofeeds@ietf.org
Subject: Re: WG LC: draft-ietf-opsawg-finding-geofeeds

hey adrian,

> Is it too late to ask for some privacy considerations to be added to
> this document?

it is never too late to ask for privacy.  as usual, the problem is how
to provide it :)

> My initial thought was that the authors would point me to 8805, but a
> quick look there doesn?t show any mention of privacy.

which is unfortunate.  the authors have sworn under oath that they
considered it.

e.g. they told me that this is why postal codes are not in 8805 geofeed
files.  they described places such as those isles to the west of europe
(on which i think you live) postal codes can locate an individual or
extremely small group.

> My concern here is that the end-user?s geographic locale is being
> exposed to the service provider without the agreement of the end-user,
> and without the end-user even knowing that it is happening.

i think we all share the concern that an end-user's locale might be
revealed.  and i suspect at least you and i pretty much agree on the
core issues.  but ...

tl;dr: that is an 8805 problem, water under someone else's bridge

unnecessary and pedantic details:

  o in pretty much all cases i know, the user's locale is known by their
    service provider.  the issue would seem to be the provider's
    revealing the user's locale to the public, which includes other
    providers.

  o my understanding is that 8805 was developed specifically to provide
    a mechanism for the user's provider to publish the user's locale to
    other providers, with the major goal being content customization.

  o whether we believe that content should be customized by locale,
    while an interesting discussion, is probably best held in another
    locale.

  o luckily, the folk who want to customize content by locale seem happy
    with fairly low resolution.

  o though clearly agencies such as law enforcement and my mother, would
    love one's precise locale at all times; i do not think they were the
    intended customer for 8805, and they are definitely not the intended
    customer for this draft.

> I know that this information has great value for a number of aspects
> of service provision (not least geographic licensing), and I am not
> opposed to its availability. I do object, however, to the concept that
> a user?s locale is generally available. A user should have the option
> of not revealing their locale (in the knowledge that this may exclude
> them from accessing some services).

let's remember that even 8805 does not directly reveal the location of
users.  it reveals low resolution location of ip address spaces.  but of
course we know ip addresses can be attributed to users.

> Now, I doubt that this document is the right place to fix these
> privacy concerns. But it might be a good place to add a short
> paragraph on the privacy issues raised by using geo feeds.

to paraphrase the immortal words of vince perriello, send text :)
but, as a first idea, how about something such as this in the Geofeed
Files section?

    RFC8805 geofeed data may reveal the approximate location of an IP
    address, which might in turn reveal the approximate location of an
    individual user.  Unfortunately, RFC8805 provides no privacy
    guidance on avoiding or ameliorating possible damage due to this
    exposure of the user.  In publishing pointers to geofeed files as
    described in this document the operator should be aware of this
    exposure in geofeed data and be cautious.

sad to say, i can not think of more useful guidance than caution.

randy