[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unique identifiers and privacy

Hi Christian,

El 09/07/2004, a las 20:31, Christian Huitema escribió:

I am concerned with the general statement that we should merely "do no
worse than the current state of the art".

I think that we already have considered the multihoming solution to be a possibility to improve other parts of the architecture, namely, we have considered improving the security, the mobility, the renumbering and now the privacy of the Internet.
I am attracted to all this approaches, since i can see that all these approaches could provide some great benefits.
However, the multihoming problem presents a great difficulty on its own, so i feel that we should focus on choosing the solutions that best solves the multihoming problem without breaking any other part of the Internet. In other words, providing multihoming support without doing worst on the other aspects concerned.
For sure, if the best solution for the multihoming problem also provides more security or privacy or mobility or renumbering support, then great. But for now, imho these are nice-to-have features.
Just my 2 cents on this.

 I am specifically concerned
with the use of long lived unique identifiers. We have already got
significant feedback on such identifiers in a number of products, e.g.
identifiers of CPU chips, identifiers of users of audio-video players,
host identifiers in IPv6, use of social security numbers in data bases,
and the list goes on. Any unique identifier is a privacy time bomb.


Okey, i see your concern but i think that this is not the case here.
I guess that your point is about unique identifiers in the sense that they cannot be changed over time, like a hardware serial number or a MAC address. In this case, the hardware number is fixed and it is a clear privacy time bomb as you mention.

However, using identifiers, like crypto identifiers that can be changed periodically, does not pose the same level of privacy issues.

I mean, the problem with fixed identifiers is that they can be traced during long periods of time.

Periodically generated identifiers can have the same behaviour than RFC3041 addresses, so they can be changed pretty frequently, so i really don't feel that they pose the same privacy threats that you are mentioning.

regards, marcelo


Obviously, there are places where unique identifiers are unavoidable.
For example, one cannot receive mail without publishing a mail address
of some kind. But there are many places where identifiers are in fact
not needed. For example, a vast majority of Internet connections involve
resolving the name of a server, obtaining the server address or
"locator", and exchanging a few packets between a single pair of
locators. A cautious design would not mandate use of any identifier in
such circumstances.

If we do use identifiers, we should obviously allow systems to create
short-lived identifiers, and to use different identifiers for different
activities. However, we should be very concerned with the default
behavior. In practice, many application developers don't bother with
advanced API and just use whatever is the default behavior of the stack.
A cautious design would be to err on the side of privacy, and to make
sure that by default, an application's traffic will use an identifier
that is both short-lived and specific to that application. The use of
long lived global identifiers should be reserved to those applications
that specifically request them.


-- Christian Huitema