Security when using multiple file://wiki(s)

It has long being emphasised all file:// wikis can access the same shared space, because unlike wikis found at a URL https://example.com/ they kind of live in a single domain.

I note FireFox containers allow multiple file://wiks in each container, but they can’t share localbrowser storage between containers. This is different to tab groups.

This suggests to me if we were to build sopisticated interwiki comunications between multiple field wikis we could keep them in a container like a trusted group. Why would we bother?

  • Tools could be build to share plugins and other content this way
  • A single file wiki may be able to test if it is already loaded in the container and not open a second time.
  • Other novel interwiki communications (within the file space)

If a different containers contain sites at file:// can they see each others browser storage?

No, different Firefox containers cannot see each other’s browser storage

Even when loading pages via the file:// protocol. The core purpose of Firefox containers is to provide isolation, and this applies to locally stored data like cookies, cache, and local storage

FWIW, locally, I use iframes in my TW’s to access and edit other local TW’s & D&D beTWixt.
Of course I have to have the rule “only IFRAME a local ONCE”.

A supra-level “monitor” would be useful. Could it be as simple as, on startup, a TW creates an external wiki-log.txt that is read by other wikis?

Dunno, stumbling
TT

Something similar is possible within the browser storage system for all wikis in the same domain, in this case file:// in the one firefox container. But its not that simple.

  • One reason its not simple is when the wiki is closed it needs to deregister itself from the storage, we dont typicaly have a “logout procedure”.
1 Like

Right.

TW as Handy Solo is normal.

But it could lay Eggs on start and an (explicit) finish? Or on every save?

What I’m getting at is “how do you message via save trails?”

Just a thought
TT