Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

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

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]