[LINK] smartphone privacy problems

[Paul Brooks]

On 27/01/2011 8:18 PM, Jan Whitaker wrote:
> 14 January 2011, 15:41
> IPv6: Smartphones compromise users' privacy
>
> Since version 4 of the iOS operating system, Apple's iPhones, iPads and iPods have been 
> capable of handling IPv6, and most Android devices have been capable since version 2.1. 
> However, the operating systems transfer an ID that discloses information about their users: 
> devices usually determine half of their IPv6 address (the "interface identifier") themselves. 
> On a wireless network, the smartphones don't appear to be careful enough with this task; they 
> simply add the same two bytes to their globally unique MAC address and use it as their 
> identifier. As a result, they transfer a unique hardware ID whenever they communicate with an IPv6-enabled server.
Which is exactly how the IPv6 specifications require the device to do it.
Its not a fault or 'not being careful enough', its the requirement of the protocol -
specified in documents like RFC4862 and RFC5072, if you want to read further.
 
> devices tend to be used by one specific person. 
> As a result, the MAC address, which is accessible 
> to any server operator and network monitor, allows this user to be identified.
>
> The basic problem isn't an IPv6 issue, because 
> various other methods for generating the address 
> are available. For instance, a device can 
> generate a random interface identifier and 
> replace it on a regular basis. This method is 
> called Privacy Extensions[1] and is the 
> factory-set option in Windows; it can also be 
> enabled in other operating systems.

Yes, RFC4941 Privacy Extensions for Stateless Addess Autoconficuration in IPv6 does
document an alternative method of generating an interface ID, and an IPv6 address,
which changes over time.

Note it shouldn't be the 'factory-set' option in Windows, or any other OS, since use
of these extensions can break some activities. RFC4941 specifies that, if implemented,
the OS must provide a way to turn the extensions off and on - unfortunately it doesn't
specify what the default should be, usually such documents specify the default should
be OFF, so the extended behaviour can be enabled under the control of someone who
should know the implications of doing so.

Downsides, noted in the RFC, are that some applications may break, and debugging of
problems may become more complicated. It also notes that the extensions are useless
unless the device is operated inside a network which has many other devices - the
extensions won't be much use in your house, for example, since your house will be
allocated a network prefix, and all the autogenerated addresses will have the same
network prefix, so the network prefix portion will still be enough to identify your
transactions.

One that is not noted in the RFC is that it does prevent the peer-to-peer model of the
Internet on which the Internet was based. Arguably NATs and dynamic addressing have
already done that in IPv4 - but thats one reason why we're moving to IPv6 in the first
place, to eliminate NAT.

One of the promises of IPv6 is that every device can have an IPv6 address which is
static - with no requirement to change over time, so that it can be advertised and
used by other devices to establish inbound connections to - including while mobile.
Widespread use of these extensions will break that model, and relegate us to
client-server modes of operating forever.

Paul.