Consider dropping the secure context requirement for `randomUUID()`

[Psychpsyo]

The Crypto Interface specifies randomUUID() as "[SecureContext] DOMString randomUUID();"

I don't see any reason for this to be locked to secure contexts, as it doesn't do any actual cryptography, apart from using secure random bytes. (which can be obtained outside of a secure context via getRandomValues() anyways)

Inspired by the errors I get when I try to open my locally hosted website on my phone for testing.

[twiss]

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.

[Psychpsyo]

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

[twiss]

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.

[Frosne]

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. :)

[pnappa]

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.