Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Thu, 02 November 2017 17:12 UTC

Return-Path: <rfc@daveor.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C013F7A2 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 10:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com
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 IH3BRsUgvyuY for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 10:12:48 -0700 (PDT)
Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (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 259961386DE for <v6ops@ietf.org>; Thu, 2 Nov 2017 10:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=xROmqji2IP18fN6L2E7UVRmcy08dOM+pB4rg5Bbmck4=; b=ZtlGTMzeH6OwCy3qRVGnfVSyhB nbFE3LJ/bA1TXWrqp1ezQlPqHbzruSTIIttTpFXTXxuL/IxOIGCuA9DuZJ9Kk/FkY/UzeYR2sqwwS tmQ94SDOpKZdTCY0Aua+B96o2hXAlP69R6HJpZE5ofaerip3/qnQPQ+GWvu4d+H7ftP0=;
Received: from [83.103.212.135] (port=62318 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <rfc@daveor.com>) id 1eAJ2a-0002sr-Vf; Thu, 02 Nov 2017 17:12:29 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave O'Reilly <rfc@daveor.com>
In-Reply-To: <CALx6S36kUrhP=+8KiX3ttr5cszezQfpYdmaFBsOFS-s+_Dqd8g@mail.gmail.com>
Date: Thu, 02 Nov 2017 17:12:29 +0000
Cc: Mark Smith <markzzzsmith@gmail.com>, Ole Troan <otroan@employees.org>, v6ops list <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C09CC26-AA68-4E1F-98F4-963B5A53F875@daveor.com>
References: <f403045ef57ac52962055bd88b84@google.com> <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <alpine.DEB.2.20.1710190655260.31961@uplift.swm.pp.se> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <alpine.DEB.2.20.1710190856530.31961@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHw9_iLWAMexrfXwsdB8duGa5ueJMofqVRqNck6DeOzA=KChqA@mail.gmail.com> <C4E37677-A2FB-49F8-B362-C29B28DFD570@daveor.com> <CE4906A4-E0CC-4C3F-A1F8-D2B5BED294D7@employees.org> <EDC5E9C7-F193-40CE-B21C-8E1D91E9E7E3@daveor.com> <C71D6C23-2720-403F-B655-D8156898A137@employees.org> <CALx6S37E9TN9SyMQfk3CSx9vWzjBM3bmuhvsyN0tFXGYFz9Mjw@mail.gmail.com> <CAO42Z2yXH0sPJYXJ6Nrq0B=UaDK4mC1R2Tds1tFQeBhuVh5meg@mail.gmail.com> <CALx6S36kUrhP=+8KiX3ttr5cszezQfpYdmaFBsOFS-s+_Dqd8g@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - daveor.com
X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com
X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bUvlm2dUnVBT2Uw6lxGS6Q54-p8>
Subject: Re: [v6ops] Google Alert - IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2017 17:12:49 -0000

Tom, I have a question.

You say:
 
>> 
> Mark,
> 
> I think the point is that for privacy we _don't_ want IP addresses to
> identify individuals, but it is work to ensure that they don't. The
> fact that a device can be shared makes the coupling weaker, but
> probably not weak enough to be considered good privacy unless the
> population sharing the device is large enough to avoid statistical
> inference.
> 

I never understood this to be a design consideration of IPv4 (I don’t know about IPv6 but perhaps others could enlighten me?). In either case, is it the case that “we don’t want IP addresses to identify individuals”? Is it not more the case that the evolution of technologies on the Internet has, as a side effect, meant that IP addresses don’t identify individuals?



>> There really needs to be something else that supports or proves use of a
>> device other than an assumption that an IP address is tightly coupled to a
>> device's owner, and therefore all actions associated with an IP address are
>> thoe se of the device's owner.
> 
> I believe there is. It is common for apps, like email, social
> networking, etc. to login to a service with username and password.
> When login is done, the service now has a mapping of an individual to
> an IP address. That mapping could then be exploited to identify the
> same individual in completely unrelated communications, hence breaking
> privacy. This could be done external to the device and the network
> provider and across different jurisdictions. The problem is
> exacerbated if the app is always connected so that whenever the
> devices gets a new IP address to user mapping maintained by some third
> party is kept up to date. Also, in this case, randomizing addresses at
> some frequency may no provide much benefit to privacy unless every
> connection gets a different source address (which is effectively is
> what CGNAT gives).
> 

You don’t even need to log in to anything - isn’t this exactly how doubleclick et-al work? They drop a cookie on your browser and then follow you around the Internet on all sites with double-click banners? 

Same problem for any application layer identifying information - but also a bit beyond the scope of the CGNAT discussion...

daveor