801950 - Change nsIUUIDGenerator.generateUUID() to guarantee version 4 UUIDs

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Gregory Szorc [:gps]]

nsIUUIDGenerator.generateUUID() does not currently specify what UUID version (e.g. 1 or 5) is returned. And, the implementation appears to vary between platforms.

Because there are privacy implications with exposing version 1 UUIDs (which contain the device's MAC address), I believe the Gecko platform should have the ability to generate a UUID of a specific version. e.g. generateUUID1() and generateUUID5().

I also believe that the existing generateUUID() should be switched to generate version 5 UUIDs by default because that is more privacy conscious. But, that may have undesired implications.

Comment 1

[Gregory Szorc [:gps]]

Where I said "version 5" in the initial comment, I really meant "version 4" (the random ones).

For reference, Python has what I consider to be a decent UUID library: http://docs.python.org/library/uuid.html. Note that is lacks a generic "generate a new UUID" function and leaves the selection of UUID version an explicit user choice. I would prefer if generateUUID() were thus deprecated in favor of version-specific APIs, but this is not my decision to make.

Comment 2

[Gregory Szorc [:gps]]

See bug 718067 comment #85 and later for some discussion. We think Windows and OS X produce UUIDs without MAC addresses, so this may not be as big of an issue as thought. Still, a strong guarantee from the API would be desired. If we are fine with changing the semantics of the API to guarantee no MAC address, we should at least add a test that confirms this.

Comment 3

[Masatoshi Kimura [:emk]]

Are you proposing stop using CoCreateGUID and CFUUIDCreate in our implementation? We have no control uuid version over the system API.

Comment 4

[Benjamin Smedberg]

I cannot think of a reason we would want anything other than fully random (version 4) UUIDs. Let's just use those, rather than making it a choice which we could get wrong. If somebody actually needs another version, we can revisit later.

Do you want to leave this bug open to document the current nsIUUIDGenerator guarantee?

Comment 5

[Gregory Szorc [:gps]]

I have multiple asks (not all of which are mutually exclusive):

a) Update the docs to reflect the guarantee (or lack thereof) of nsIUUIDGenerator.generateUUID()
b) Change the behavior of nsIUUIDGenerator.generateUUID() to guarantee specific behavior
c) Add new APIs to nsIUUIDGenerator to generate UUIDs of a specific version

Version 1 UUIDs can be useful for certain use cases. I've used high-volume logging systems that used the time field from within version 1 UUIDs to record the time the event was produced, for example. I'm not sure whether Gecko has a desire to support said scenarios.

Comment 6

[Benjamin Smedberg]

a) yes
b) as long as that behavior is version 4, yes
c) WONTFIX

Comment 7

[Gregory Szorc [:gps]]

Changing bug summary with bsmedberg's feedback.

This change may block landing of Firefox Health Report (which is targeted for Firefox 19) because of privacy concerns over version 1 UUIDs.

I'd take a stab at it, but I've never touched C++ in Gecko and it would likely take me longer to crank this out than a seasoned Gecko dev.

mconnor: could you try to wrangle resources for this? I'm pretty sure it will only be an hour or two of work for someone who knows what they are doing.

Comment 8

[Gregory Szorc [:gps]]

I audited the UUIDs of FHR documents on the server and something like 98% of the UUIDs are version 4. The other 2% appear to be evenly distributed between 0 and 15. My guess is some UUID generator out there is generating completely random bytes and using that as UUIDs. Nevermind that some bytes of UUIDs are supported to carry meaning. I suppose with a little investigating I could figure out which OS is doing this...

Anyway, we don't see version 1 UUIDs in the wild, so privacy disaster averted. Removing as FHR beta blocker.

Comment 9

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

Confirming that in the wild generated UUIDs are mostly '4', but some are arbitrary.

Claim:  OSX/Darwin?   Maybe old versions?

"""
>>> pprint(Counter([(x['geckoAppInfo']['os'], x['geckoAppInfo']['xpcomabi']) for x in d]).most_common())
[((u'Darwin', u'x86_64-gcc3'), 40)]
"""

I wish I had the smoking gun of the history of OSX `uuidgen` and `libuuid` sources, but I don't know where they live.  (If someone has deeper archaeology skills, I am all ears!)

Impact:  Mostly, this is 'undocumented' (and thus annoying), and it breaks existing uuid validators.

Proposed fix:  Doc update to suggest that UUIDs might not be V4 / V5 compliant at places like:
- https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/util_uuid
- https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIUUIDGenerator

Some wild observed samples (test pilot stuff, mostly)

"""
 164 0
 172 1
 160 2
 188 3
113058 4
 241 5
 184 6
 140 7
 156 8
 130 9
 158 a
 179 b
 150 c
 176 d
 168 e
 211 f
"""

Another sample yielded 4% of samples were (obviously) not v4 compliant.

Comment 10

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

Mystery continues:

>>> pprint(Counter([(x['geckoAppInfo']['os'], x['data']['last'].get('org.mozilla.sysinfo.sysinfo',{}).get('version',0)) for x in d]).most_common())
[((u'Darwin', u'10.8.0'), 9),
 ((u'Darwin', u'11.4.2'), 9),
 ((u'Darwin', u'13.1.0'), 7),
 ((u'Darwin', u'12.5.0'), 5),
 ((u'Darwin', u'13.0.0'), 3),
 ((u'Darwin', u'12.3.0'), 2),
 ((u'Darwin', u'12.4.0'), 2),
 ((u'Darwin', 0), 1),
 ((u'Darwin', u'11.3.0'), 1),
 ((u'Darwin', u'12.4.1'), 1)]

11.4.2 is 10.7.5 for example.

Comment 11

[u525076]

What is the status of this issue? What is guaranteed regarding the topic in the latest version of XULRunner? Is https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIUUIDGenerator going to be updated?

Thank you!

Comment 12

[Chris Peterson [:cpeterson]]

This bug will be fixed by bug 1723674, which will change nsUUIDGenerator to always return version 4 UUIDs.

Comment 13

[Chris Peterson [:cpeterson]]

Fixed in Fx95 by bug 1723674.