I strongly suggest that you distribute your game with a small static servers. I already found some open source static servers that weigh less than a megabyte that  do not even require an installation. file:// URLs have many limitations compared to HTTP/HTTPS URLs.

I already have such a server built into platform-specific builds. However, the whole point of packaging A-code games as HTML/JavaScript is to free myself from hardware/software dependencies. In this format games can be run on *any* platform with an HTML5 compliant browser: any hardware, any OS, any other software present or absent. And they require nothing fancy, nothing incompatible with the file:// protocol.

In any case, there are no third-party data or cookies involved, so it is illogical for that Chrome setting to block access to IDBFS. Things work just fine without that setting.

Note that IDBFS is a library that happens to use Indexed DB for storage. Adjusting summary appropriately.

"Cookie" is used in the UI for any persistent storage mechanism that would allow users to be tracked.

And FWIW the Indexed DB check is here:

https://cs.chromium.org/chromium/src/chrome/browser/renderer_host/chrome_render_message_filter.cc?type=cs&l=303

Which delegates into:

https://cs.chromium.org/chromium/src/components/content_settings/core/browser/cookie_settings.cc?type=cs&l=121

(related to issue 271996 which discusses blocking or isolating file:/// access)

Basically, behavior of storage APIs on file:/// is not defined (and also inconsistent across browsers) and should not be relied upon. Leaving this open, though.

Thanks. Please bear in mind that no third party is involved, which is presumably why IDB is available, as it should be, when the page is accessed on some random remote server. It is hard to see file:/// access as being less secure and hence needing blocking.

As more context, file:// behavior is unspecified, and hasn't been thoroughly vetted by years of security analysis.

For example, should file:///a/b/c.html and file:///a/b/d.html be treated as "same origin" and share data? Browsers disagree.

Early on, file:// content was given full trust by browsers like IE ("hey, it's local, must be fine!"). But granting full power to files downloaded by the user is bad (e.g. Downloads/evil.html) so file:// content is no longer considered as trusted as content from secure origins.

For this kind of application, browser inconsistency as to what counts as same origin makes is no big issue. I fully expect "same origin" to be absolutely tight: same URI only. If some browsers are more permissive than that, that's up to them. OTOH the gain for me is massive: not having to rely on platform dependent pseudo-server code (believe me, I've suffered! :-)), while allowing players to play on devices not connected to the Internet. Plus it eliminates all installation complexities -- the user just saves a file.