Mobile phones are not usually completely "factory reset" if resold and even if they were a UUID may still have been stored in non volatile as it may have been generated during final test.
In any case if the IMEI was to persist after a resale how would that be a privacy problem given the restrictions placed on the usage in
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/?
The intention is that the IMEI is not passed to the remote party except when required by regulations for an Emergency call.
Andrew
From: Tim Bray [mailto:tbray@xxxxxxxxxxxxxx]
Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time
To: Andrew Allen
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time
To: Andrew Allen
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen <aallen@xxxxxxxxxxxxxx> wrote:
---------------------------------------------------------------------
The quote is from RFC 5626 which also states:
"3.1. Summary of Mechanism
Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled."
Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID?
The difference is that the UUID (properly) vanishes when the device is factory-reset (“wiped”), as is common when a device is passed on to a new owner. The IMEI persists, however. -T
Andrew
From: Tim Bray [mailto:tbray@xxxxxxxxxxxxxx]Sent: Friday, July 19, 2013 10:58 AM Central Standard Time
To: Andrew Allen
Cc: ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen <aallen@xxxxxxxxxxxxxx> wrote:---------------------------------------------------------------------
I suggest you also read
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/
Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...”
Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T
That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards.
Andrew
From: Tim Bray [mailto:tbray@xxxxxxxxxxxxxx]
Sent: Friday, July 19, 2013 10:02 AM Central Standard Time
To: IETF-Discussion Discussion <ietf@xxxxxxxx>
Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt
----------------------------------------------------------------------TimJust wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.htmlI’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea.
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.