v5.1.3 - Can't access Local Module Library, but remote DM/Referee has full access...

[VarianTemplar]

... to my content.


So question - I have lots of modules/content but have joined someone else's session (They are the DM). For some reason they are able to see my entire library on my end, as well as load my content and share it out to others on the session. I no longer have line-of-sight to my own library (as I had been able to previously over the last yonks).

Was this really intended in the update?

This presents like a licensed content data leakage issue, if I were to put on my CyberSecurity hat (which I'd much rather not do as it's game-night fer cryeye).

/edit - plugged in an Atlassian/JIRA tix on it

[Moon Wizard]

As I mentioned in Discord; as far as I know, there is no mechanism to share that data from player to GM machine (other than portrait data), so I'm not sure what you guys are seeing.

I'll try setting up a scenario here to check with superteddy57; but might need to having you connect to one of us to see if we can see what you do.

Regards,
JPG

[VarianTemplar]

We should find a time to sync up.

Just ran a test with a plain vanilla account (new account with FG's backend), a fresh install of v5.1.3 on a different endpoint, and has it run the 5e Sample Campaign with the default module library.

Then I connected with mine, and I saw selections of my module library in the activation window, appear on the 'serving side'/"DM" endpoint (the endpoint I joined to from my account's/primary endpoint).

I'll surmise that since the other fellow (DM from the original post here) had some assets like mine, that he saw 7 or so pages of module library content show up on his end that he was able to control whether or not my side (as client) could see.

Images of what I'm seeing with a test I ran between a different endpoint running FGU v5.1.3 in a different newly created account with the base install of free/included modules (no purchases or custom modules) against the endpoint I used last Thursday.

Here's what I saw on the "Loading"/DM endpoint side:

"Before" picture for the Module Library:
66606

"After" picture Page 1 for the Module Library "DM" endpoint:
66607

"After" picture Page 2 for the Module Library, "DM" endpoint:
66608


Here's the view I had from my "Join" endpoint/primary endpoint with the full module library local to my FGU installation:
66609

The Thursday night DM had control over what myself and others could see in the Module library list from my local module storage from the DM's version of source books, custom modules I created, modules from DriveThruRPG and some from Kickstarters, and a few modules from other systems (a Forge module from Traveller) - but I did warn the other fellows not to "peek" into them for fear of ruining years-long campaigns (we skip about over the last 10 years since FG Classic days) - thus unable to validate if they were able to see content beyond the titles.

In this test instance tonight, the "Load"/"DM" endpoint side was unable to read the index of the modules it had loaded from the list it fetched from my endpoint's storage.

[Moon Wizard]

That's correct behavior; and by design. The GM will see "phantom" module entries for all content owned by players which they do not own themselves. This allows the GM to control whether players can load content which the player individually owns, but the GM does not. The actual content of the modules is not shared with either the GM or other players.

If you are seeing actual content shared, then I would need steps to see that issue in action, or work with you to connect to one of our development campaigns to see.

Regards,
JPG

[VarianTemplar]

That's a new one on me.

Also, what provisions are in plans to restrict what the GM can see of the "phantom" modules entries? Even these name can be telling to groups that share the GM role.

[Moon Wizard]

The GM can not see any of the player module content that they do not own, as far as I’m aware from the code and from my experience.

Regards,
JPG

[VarianTemplar]

My next opportunity to duplicate last Thursday's situation is tomorrow. I'll see if I can't snag snapshots of his module library before I connect in with the 5.1.4 update, and what it looks like after I connect in. He saw reference to assets he did not own in common with my library.

[claedawg]

I want to say I have seen Player mods in my list, a long time ago. That was before I had 32 pages of mods (in Shadowdark, more for 5E).

[Trenloe]

I want to say I have seen Player mods in my list, a long time ago. That was before I had 32 pages of mods (in Shadowdark, more for 5E).
Yep, that's standard behavior - as mentioned my Moon Wizard in post #4.

[VarianTemplar]

So the phantom list appeared of all my (applicable) content (FG store purchased, from DriveThruRPG, custom modules, et al) that the GM did not own.

I take it a provision to selectively hide some of that content that turns into a Phantom list was not part of the consideration of "expected behavior" - correct?

[Moon Wizard]

The extra entries in the GM list are only for the GM to enable/disable for the players that own the content that the GM does not. They do not provide any access.

Regards,
JPG

[VarianTemplar]

Understood access is not granted - however the name of the assets are being shared, and in some cases for us it was rather telling. Again - no consideration for that I take it?

[Zacchaeus]

Understood access is not granted - however the name of the assets are being shared, and in some cases for us it was rather telling. Again - no consideration for that I take it?
Can you explain in more detail by what you mean that the name of assets are being shared?

[LordEntrails]

Understood access is not granted - however the name of the assets are being shared, and in some cases for us it was rather telling. Again - no consideration for that I take it?
This is as it has always been.
I assume your situation is that sometimes you are a player and sometimes GM? And that you create custom modules as a GM that when you are a player you do not want the current GM to see the names of?

Given that this is probably a rare case, not sure how FG would prevent this without causing issues for all the other use cases. You could just move the modules out of your modules folder when you are a player, or give them names that are not spoilers. Neither is ideal, but both are workable.

[VarianTemplar]

It's the disclosure of the list of assets in the module library from my side to the occasional GM's side. I'm the (nearly) forever-GM.

Let's say this, Thursday before last, it was a shock to him that he saw such a large list of modules that he hadn't expected to see, so not quite sure I'm tracking on the "This is as it has always been." statement.

Even so, the naming of the modules themselves it the concern at hand. There's enough info in that simple label, that is helpful for my purposes for the locally created/custom modules but opens to question of "oh, is that the direction our campaign(s) are going to go then?" from the opposite, occasional GM (as it did).

Is there provision to allow us to control who gets to see the names of the assets to a different GM for a given Ruleset?

[Moon Wizard]

No, there is no provision for anything like this. As @LordEntrails mentioned, it has been that way in FG for over 10 years and no one has ever mentioned it, so it's not anything that's ever been an issue before for anyone else as far as we know.

Regards,
JPG

[Speculi]

There's enough info in that simple label, that is helpful for my purposes for the locally created/custom modules

Keep in mind it is only showing modules marked as a player module when you export it. So usually those are character options, classes, sub classes, species, spells...
If you really don't want your other GM/Player to see them, you could temporarily move them out of your FG data folder, as a workaround.

(I personally would also prefer a system where the player can look at their library and press a button to ask the GM for permission to load, instead of the GM having to go to the library when the players connected and allow the modules, but that's another topic.)