Consider dropping the secure context requirement for randomUUID() #408

Activity

1. twiss commented on Jul 10, 2025

   

   twiss

   on Jul 10, 2025

   Member

   More actions

   Hi 👋 This was discussed in WICG/uuid#23, though there didn't seem to be a strong consensus.

   I think if you can convince the implementers to agree to expose it in insecure contexts, we could change this in the spec.
2. Psychpsyo commented on Jul 10, 2025

   

   Psychpsyo

   on Jul 10, 2025

   Author

   More actions

   Hi 👋 This was discussed in WICG/uuid#23, though there didn't seem to be a strong consensus.

   I think if you can convince the implementers to agree to expose it in insecure contexts, we could change this in the spec.

   Thank you! :D
   I've now filed implmentation bugs for this:
   Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1976651
   WebKit: https://bugs.webkit.org/show_bug.cgi?id=295700
   Chromium: https://issues.chromium.org/issues/430616182
3. twiss commented on Jul 10, 2025

   

   twiss

   on Jul 10, 2025

   Member

   More actions

   Thanks, but I meant more like, ping the implementers to discuss here :)
   Cc @Frosne, @davidben, @annevk.
   From looking at issues linking to WICG/uuid#23, it seems like there's some real-world evidence that developers are choosing not to use this API because of this (e.g. ppy/osu-web#11692) or provide a suboptimal fallback (e.g. partykit/partykit#54), so I think it may be worth reconsidering this.
4. Frosne commented on Jul 28, 2025

   

   Frosne

   on Jul 28, 2025

   Member

   More actions

   Personally, I don’t believe a change is necessary.

   Polyfilling for UUID v4 is fairly straightforward, and developers have managed the secure context requirement for years. Given that, I don’t see a compelling reason to alter it now. Additionally, the vast majority of websites—over 90%—already use HTTPS.

   That said, I’m open to hearing the arguments. :)

   👍React with 👍2Reacted by Anne van Kesteren and Tobias Nießen
5. pnappa commented on Aug 11, 2025

   

   pnappa

   on Aug 11, 2025

   Last edited by pnappa

   More actions

   I'd like to also tip my hat into the ring - I think it should be allowed in non-secure contexts.

   Whilst I do believe secure contexts should encouraged where possible, however I don't believe paternally restricting non-mandatorily secure-context functions to them is the right solution.

   There are so many poorly written, insecure ID generation libraries out there (having read their source code, I would say a majority have insufficient random sources), that having any reason to not use randomUUID() is dangerous. Based on the examples that @twiss provided, it's a non-zero amount of people actually choosing to do so, and in some cases - dangerously.

   If I were writing a library, I likely wouldn't be internally using randomUUID() out of fear of breaking my users' code, and instead probably find a library on npm for it.

   👍React with 👍6Reacted by Nikita Skovoroda, Martin Heidegger, Dan Schellekens, Radon Rosborough, Georgii Dolzhykov and Glenn Willen
6. gwillen commented on Oct 4, 2026

   

   gwillen

   on Oct 4, 2026

   Last edited by gwillen

   More actions

   It is quite bizarre that crypto.getRandomValues is available in any context, but crypto.randomUUID is restricted. I don't see how this restriction could possibly have any function, except to ensure that nobody uses crypto.randomUUID. This just means I now polyfill it as follows, forever, to ensure that it's present:

     window.crypto.randomUUID = function () {
       return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
         (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
       );
     };
   

   What is accomplished by making me do that? I'm just running some shitty too-clever code I got from Stack Overflow, that's probably wrong, instead of using the standard API; because I can't guarantee the standard API will be available. (Because in dev / integration test contexts, it's often easiest to test the raw app server, without the https-applying reverse proxy.)