ietf
[Top] [All Lists]

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

2013-07-20 15:48:14
Tim

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(_at_)textuality(_dot_)com]
Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time
To: Andrew Allen
Cc: ietf(_at_)ietf(_dot_)org <ietf(_at_)ietf(_dot_)org>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen 
<aallen(_at_)blackberry(_dot_)com<mailto:aallen(_at_)blackberry(_dot_)com>> 
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(_at_)textuality(_dot_)com<mailto:tbray(_at_)textuality(_dot_)com>]
Sent: Friday, July 19, 2013 10:58 AM Central Standard Time
To: Andrew Allen
Cc: ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> 
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>
Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt

On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen 
<aallen(_at_)blackberry(_dot_)com<mailto:aallen(_at_)blackberry(_dot_)com>> 
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(_at_)textuality(_dot_)com<mailto:tbray(_at_)textuality(_dot_)com>]
Sent: Friday, July 19, 2013 10:02 AM Central Standard Time
To: IETF-Discussion Discussion 
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>
Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt

Just 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.html

I’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.

 -Tim
---------------------------------------------------------------------
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.