At 15:53 19-07-2013, Andrew Allen wrote:
Do you not think that the text in the security considerations section::
"because IMEIs can be loosely correlated to a user, they need to be
treated as any other personally identifiable information. In
particular, the IMEI URN MUST NOT be included in messages intended
to convey any level of anonymity"
covers the privacy issue?
If not what is the additional privacy concern?
There is a difference between privacy concerns and privacy
considerations. It has been mentioned that "the view in 3GPP was
that the IMEI should not be of any greater concern when used as an
instance ID than using a UUID". draft-montemurro-gsma-imei-urn-16 states that:
"Specifically the IMEI is to be incorporated in a module which is
contained within the terminal. The IMEI SHALL NOT be changed
after the terminal's production process. It SHALL resist tampering,
i.e. manipulation and change, by any means (e.g. physical,
electrical and software)."
The pervasive use of UUID in computing does not make it a good
idea. I doubt that there has been any privacy analysis of how UUID
will be used or misused prior to the publication of the RFC. The
IMEI is built into the device. The scope for misuse would be clear
enough for a person designing identifiers.
From draft-montemurro-gsma-imei-urn-16:
"Therefore the IMEISV (that is, the IMEI URN with svn parameter)
MUST NOT be delivered to devices that are not trusted. Further,
because IMEIs can be loosely correlated to a user, they need to
be treated as any other personally identifiable information. In
particular, the IMEI URN MUST NOT be included in messages intended
to convey any level of anonymity."
The IMEI is considered as personal data in some jurisdictions. There
is a strong correlation between the IMEI and a user.
I read draft-montemurro-gsma-imei-urn-16 and I see that the four
authors have listed their phone numbers as "unlisted". Is there a
reason for that? The question may sound unrelated to the draft and
it can be argued that it is unrelated to the draft. I asked it as it
may help the casual reader understand what privacy is
about. draft-moonesamy-privacy-identifiers-00 (expired) argues that
there is an implicit assumption that the underlying protocols are
transmitting the right amount of information needed for the protocols
to work. Is for example, urn:gsma:imei:90420156-025763-0, required
for SIP to work? I do not think so.
The world was somewhat naive about privacy in 2006. Privacy is a hot
topic nowadays. The metadata debacle is one of the contributing
factors. There seems to be an assumption that the IMEISV is usually
sent over trusted channels to trusted parties.
The second sentence containing "must not" written in capital letters
takes a position where anonymity of messages is opt-in. The GSM
Association has published a set of principles which mentions "privacy
by design". It is up to the reader to read the two sentences quoted
above and determine whether "privacy by design" is just another
buzzword or a principle which the GSM Association considers as important.
At 04:23 20-07-2013, Scott Brim wrote:
Thanks, SM, for finding what I said back in 2010. I still think this
is architected wrong, conflating devices with communication endpoints
higher up the stack, and steers us toward a path toward eventually
"needing" to reduce privacy even more. However, 3GPP has apparently
already already started marching down that path. Could our liaison
explain the situation there? Is anyone actually going to use it? Is
this a done deal - do we have to support it because otherwise 3 years
of 3GPP work get undone?
As a responding to Scott's comment about the three years of work I
would say that this has the signs of an inevitable decision. I'll
describe the IETF angle as follows:
Is it okay to assign a Uniform Resource Name namespace for GSMA?
The namespace assignment is not a problem. Have an assignment
request sitting in the IETF queue for seven years is a problem. It
would be good if someone explained why this happened unless the IETF
considers it as acceptable to be asked to take inevitable decisions.
I agree with Scott's comment. Tim Bray already pointed out that this
is a bad idea.
At 04:53 20-07-2013, GARBA KORA TAMSIRD BELLO wrote:
Yes it true , but more argumentations are welcome
The duck won't fly. :-)
Regards,
S. Moonesamy