W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2015

Re: local IP address (was Re: Request for feedback: Media Capture and Streams Last Call)

From: David Singer <singer@apple.com>
Date: Tue, 18 Aug 2015 09:27:06 -0700
Cc: Mike O'Neill <michael.oneill@baycloud.com>, Nicholas Doty <npdoty@w3.org>, Eric Rescorla <ekr@rtfm.com>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>, Jan-Ivar Bruaroey <jib@mozilla.com>
Message-id: <A29235B4-011B-415B-AD30-68904BCF63DA@apple.com>
To: 🔓Dan Wing <dwing@cisco.com>

> On Aug 18, 2015, at 4:02 , 🔓Dan Wing <dwing@cisco.com> wrote:
> On 18-Aug-2015 05:16 am, Mike O'Neill <michael.oneill@baycloud.com> wrote:  
>> That’s why IPv6 had autoconfig privacy extensions, so the local IP addtress is based on a random number (i.e. not the MAC address) + the network prefix. 
> Major OSs only change the privacy address every 24 hours (iOS, OS X, Windows).  Is that sufficient to avoid tracking, compared with the relatively-permanent local NATted address (which due to how DHCP clients and servers work, will often re-assign the exact same IP address, so long as it is available in the pool).

I have wondered whether we need a new DHCP method “give me a DIFFERENT address, please!” as, as you say, DHCP servers usually try to give you the same address as it previously gave to this MAC address. But, I think the IETF is not enthused about rev’ing IPv4, and indeed most users get to hide their true IPv4 address as they are behind a NAT anyway.

The IPv6 privacy address cycling could, of course, be different.  One concern is over networks where the network prefix effectively identifies a single host (I think this is the case in cellular, for example); fiddling with the device part may be immaterial if the attacker can work out “that prefix is one assigned by a cellular network, and therefore the prefix identifies a single host”.

David Singer
Manager, Software Standards, Apple Inc.
Received on Tuesday, 18 August 2015 16:27:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:30 UTC