Integrating external websites via IFRAME is a great feature! However as far as I can tell, there is no way for the embedded website to know which Gather user has opened it. It would make the integration much more useful if the embedded website could call document.postMessage() to ask the containing frame about who has opened it. In particular, I want to know the name of the avatar of the current player. It would also be nice if it could send a literal “data:” image of the current Avatar.
If I overlooked this, please let me know where its documented. If the feature doesn’t exist, please add it! It should be fairly low-hanging fruit since it doesn’t touch the server at all, only the javascript served to the users, and it would only require about 3 new functions. It is also not much to commit to for future compatibility since the game will always have the avatar image and name available.
While I agree this would be a really useful tool for some applications, when the subject was raised in the past, the potential for security concerns was very high. Namely, user data tracking by outside websites would become highly under-regulated. IFAIK, Gather has opted against this ‘openness’ as the currently targeted market is remote work style offices, which may have fairly exacting security requirements for any software they use.
That said, I would propose an alternative solution: have the iframe object generate a token whenever a user interacts with it, and pass that token into the iframe. At the same time, log the token in the playerInteracts event, such that a Websocket API connection could link an interaction token to player ID/information, and pass that (via an external database or program) to the accessed website. Then, the website could use the interaction token to make sure it knows who is interacting with the website, without Gather being directly responsible for passing any non-tokenized data through. An example setup:
By doing this, only spaces which have an active websocket listener set up would have any access to player data, which already implies they have some amount of acceptable use. Iframe websites would be able to collect the interaction token, but all that would enable them to track is “was this hit from a Gather.town site” which they can already do. This also puts any DPA, SLA, or overt data security responsibilities on the author of the Websocket API script, not Gather. (Not legal advice or assertion, just opinion)
On a separate note, Gather does offer Identity Linking as an option, where you can bake in a URL redirect through a Gather generated confirmation screen, which then passes player ID in the URL parameters. But just the fact that option was generated should give you some insight into their thoughts on user data security.
That’s a very sensible arrangement, but also more work for both parties, and less likely to get implemented soon.
Can we assume that the person editing the gather space has permission to decide this for all the users of the space? If so, on the same screen where they configure the URL, gather could provide checkmark options like:
Share player details with external website
When a player walks up to interact with this object, you can supply some player information to the external site:
As Gather currently only supports a boilerplate privacy policy agreement, I do not think it is safe to assume the owner of the space has the right to determine the user data usage agreements wholesale. At least, not in any regard to GDPR or CCPA (California).
If Gather were to implement custom or preference based privacy policies per space, maybe we could relax that assumption. Each solution will have consequence either in terms of compliance with data privacy and processing laws, or in terms of added engineering.
Yeah Bill is right here, sorry – I agree this would be super useful and not very hard, but we’re trying to error on the side of caution with user data here, so until we can sit down and come up with a deliberate policy on sharing data with 3rd parties, we’re trying to avoid dealing with specific cases
(the ws api has so much available only because that’s what’s already exposed via the UI, so there’s no little to no change in security model from baseline)
Fair enough I guess. Though the person who created the space has permission to connect with websocket API which has permissions to see which player just moved up to the object (i think), so there’s almost no difference here…
Speaking of which, the documentation link is really really bare, with no mention of the websocket. Are people just using the Chrome debugger to trace through the API, or is there another document somewhere?
Dropping this here as an illustration (though I am not a digital privacy lawyer, so this is more an interpretation, not an legal point of reference.). Gather controls how user data enters and exits their legal domain (in terms of data processing). As I understand it, the API/Auth/Roles output is covered at least in part by the EULA, as you have to have a Gather account to get an API key.
Now, there is grey area here, such as the “Whatever they want” block. If the information originates from within the Gather platform, whose role is it to police that information? Gather? The owner of the space? The user? The API script author? But by at least trying to isolate direct access to user data, Gather has fairly robust insulation from accusations of data breaches, information brokering, or user tracking from directly within the platform.
