Intent to Ship: crypto.randomUUID()

197 views
Skip to first unread message

Benjamin Coe

unread,
May 5, 2021, 5:11:06 PMMay 5
to blin...@chromium.org

Contact emails

ben...@google.comdom...@chromium.org

Explainer


https://github.com/WICG/uuid/blob/gh-pages/explainer.md

Specification

https://wicg.github.io/uuid/

API spec

Yes

Summary

Introduces the method crypto.randomUUID() for generating RFC 4122 version 4 identifiers. The method returns the namespace specific string representation (for example, "6e4decd0-6066-4a25-98e3-0227317cda52").



Blink component

Blink>WebCrypto

TAG review

https://github.com/w3ctag/design-reviews/issues/623

TAG review status

Issues addressed

Risks



Interoperability and Compatibility



Gecko: No signal
Some feedback in thread: https://github.com/mozilla/standards-positions/issues/511

WebKit: No signal 
Discussion thread startedhttps://lists.webkit.org/pipermail/webkit-dev/2021-April/031783.html

Web developers: Positive
- In twitter post (https://twitter.com/tomayac/status/1380445180403318785) from when randomUUID was landed behind flag, response from community was positive: “Would be super useful”, “Cool enough, I should start providing keys to react list elements using this uuid”, “We could roll one with crypto.getRandomValues(), but this is easier”. 
- Stack overflow thread with over 4000 upvotes (https://stackoverflow.com/questions/105034/how-to-create-a-guid-uuid), notable in that: several suggested implementations use Math.random(), which is not a CSPRNG; users were specifically looking for direction regarding how to create UUIDs safely. 
- uuid npm module (https://www.npmjs.com/package/uuid) is downloaded over 50,000,000 times a week, and it is one of the 20 most depended upon modules. It is unknown how much UUID is used server-side, vs., on the web, observationally I noted that the module is used by the web framework Gatsby.
- The Node.js crypto.randomUUID implementation is already seeing usage across hundreds of codebases (https://github.com/search?p=2&q=%22crypto.randomUUID%22&type=Code).


Is this feature fully tested by web-platform-tests?

Yes

Flag name

UUID

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1197594

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5689159362543616

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
May 6, 2021, 6:35:57 AMMay 6
to Benjamin Coe, blink-dev
The signal from Mozilla folks is extremely useful, and it seems like they are not opposed to the feature while some of them think that it won't provide value to the platform.
Signals from developers seem to counter that latter part, as there's evidence of clear developer demand for this functionality to be part of the platform.

One contentious point revolves around exposing this in non-secure contexts. It seems to me it'd be better to be cautious there, especially given opposition from Mozilla on that front and lack of clear reasoning to the contrary, and only initially expose the API in secure contexts.

Does that match your understanding of the current interop situation?



Is this feature fully tested by web-platform-tests?

Yes

Flag name

UUID

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1197594

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5689159362543616

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE4ckJGPwAogorjLL-06f7iefmPKOUYvpZNrM60nuigBc2prbA%40mail.gmail.com.

Benjamin Coe

unread,
May 6, 2021, 10:55:58 AMMay 6
to Yoav Weiss, blink-dev
> One contentious point revolves around exposing this in non-secure contexts.

I was leaning in the same direction. Perhaps we should start by exposing only in secure contexts, to help reach consensus with Mozilla?

-- Ben.

Yoav Weiss

unread,
May 6, 2021, 11:05:32 AMMay 6
to Benjamin Coe, blink-dev
LGTM1 to expose in secure contexts.

On Thu, May 6, 2021 at 4:55 PM Benjamin Coe <ben...@google.com> wrote:
> One contentious point revolves around exposing this in non-secure contexts.

I was leaning in the same direction. Perhaps we should start by exposing only in secure contexts, to help reach consensus with Mozilla?

SGTM!

Chris Harrelson

unread,
May 6, 2021, 11:20:36 AMMay 6
to Yoav Weiss, Benjamin Coe, blink-dev

Daniel Bratell

unread,
May 6, 2021, 2:48:14 PMMay 6
to Chris Harrelson, Yoav Weiss, Benjamin Coe, blink-dev

一丝

unread,
Jul 12, 2021, 10:31:59 PM (13 days ago) Jul 12
to Daniel Bratell, Chris Harrelson, Yoav Weiss, Benjamin Coe, blink-dev
Is Blink considering supporting nanoid? https://blog.bitsrc.io/why-is-nanoid-replacing-uuid-1b5100e62ed2

以上
一丝


Daniel Bratell <brat...@gmail.com> 于2021年5月7日周五 上午2:48写道:

Benjamin Coe

unread,
Jul 19, 2021, 1:26:42 PM (6 days ago) Jul 19
to blink-dev, 一丝, Chris Harrelson, yoav...@chromium.org, Benjamin Coe, blink-dev, Daniel Bratell
The work to add crypto.randomUUID hasn't centered around a specific library in the JavaScript ecosystem, e.g., (uuid, vs., uid, vs., nanoid).

Rather, it's based on the RFC 4122 spec which describes in a language agnostic way how to generate a random UUID (there are implementations in Java, Python, go, etc).

There's not a plan to support another algorithm at this time. Having said this, one of the reasons we opted for the name randomUUID, vs., something like uuid.v4 , is that it creates room for alternative "random UUID" algorithms (if a strong case is made for extending the algorithms supported in the future).
Reply all
Reply to author
Forward
0 new messages