Intranet Twine Error with Firefox/Chrome Browser: window.crypto.randomUUID is not a function

[LeeThompson]

Describe the bug.

Starting with Twine 2.9.1, if you use Firefox browser on an intranet webserver without using https Twine will fail to load.
The console for Firefox will show: window.crypto.randomUUID is not a function

Uncaught TypeError: window.crypto.randomUUID is not a function
    IW http://(localurl)/twine/assets/index-CXvDOX45.js:37
    <anonymous> http://(localurl)/twine/assets/index-CXvDOX45.js:37

In my case, the web server is Apache 2.4 running in a Docker container on a Synology NAS.
The browser (Firefox) is running on Windows 10 Enterprise edition

Steps to reproduce:

1. Install Twine 2.9.1 on an intranet web server
2. Access Twine with Firefox or Chrome browser using http

Expected behavior:

It shouldn't require https, but apparently randomUUID on Firefox, Chrome (and possibly other browsers) requires https.

Additional context on this problem.

No response

Twine version number

2.9.1

Does this problem occur with the web version of Twine or the desktop app?

Web

What operating system does this problem occur on?

Other

If this problem is occurring with the web version of Twine, what browser does it occur on?

Firefox
Chrome
(Possibly Others)

Presubmission checklist

• I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
• I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
• If this problem is occurring with the app version of Twine, it still happens after I remove the user.css file from my Twine folder. (You would've added this file yourself. If you don't understand this question, you can safely check this box.)
• I have read and agree to abide by this project's Code of Conduct.

[klembot]

This is more-or-less by design. 2.9.1 replaced the tiny-uuid module with a built-in browser equivalent that has good support across browsers, but requires either running on localhost or in an HTTPS context. I think your best bet here will be to use a self-signed cert if you want to serve the app locally.

[LeeThompson]

I hope this doesn't affect playing games produced with TWINE as it will introduce hurdles for players to overcome just to play a local copy.

[greyelf]

I hope this doesn't affect playing games produced with TWINE

As far as I know none of the major Story Formats runtime engines need to generate UUIDs while a Story HTML file is being viewed. And if they are doing so I know that the crypto.randomUUID() function specifically isn't currently being used in the engine code of SugarCube, Harlowe, or Chapbook.

[klembot]

Discussion on intfiction.org reminded me that some users are still using the HTTP version of the online editor, so #1545 backs out the change we've been discussing.