Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.
SOLVED

How to ensure that no data is ever stored on the LCCS servers?

Avatar

Level 2

In particular, I want to use the SimpleChat and SharedWhiteboard in a secure application and don't want to have any of the data stored on the LCCS servers (just used to manage the streaming of data). At the very least I don't want to have data stored between sessions, but the "sessionDependent" property of both pods doesn't seem to work (ie. when set to "true" the chat history and whiteboard shapes are preserved between sessions).

I have put in some hooks to clear both at session end and session start, but what I really want is for that data to never be stored in the first place.

Is this possible with these pods, or do I need to custom develop something on my own to support this behavior?

Thanks

1 Accepted Solution

Avatar

Correct answer by
Employee

The data is stored only in memory only. When "persisted" we check the node configuration and if transient we don't save that node to disk.

If you are really concerned about a security breach you should probably encrypt your messages before sending them via LCCS (it should be easy to subclass the current models and encrypt/decrypt the items on the fly).

View solution in original post

5 Replies

Avatar

Employee

By default the SimpleChat component should be already configured to don't store messages between sessions.

One reason why you may still see messages is because you enter a room before the session really terminated. The way sessions are managed in LCCS is that a session starts when the first user enter and ends a few minutes after the last user exits. The delay is there to cover the case where all users are disconnected from the room because of a failure and try to reconnect. In this case they will start from where they have left (i.e. the session has not been terminated and all the content has been preserved).

So, please try to wait a few minutes after you close your client applications and then check if the data is still there.

If you really want to store as little as possible on our server (and don't need "all" the messages in case of failure) I suggest you create a different model or reconfigure the SimpleChat mode to use a different storage scheme (STORAGE_SCHEME_SINGLE_ITEM instead of STORAGE_SCHEME_QUEUE, but I am not sure of how the current chat model would work if you just change the storage scheme)

Anyway, if you use STORAGE_SCHEME_SINGLE_ITEM you will have at the most one item stored in the server. At the client level you can still, for example, display the last chat messages you received but in case of reconnection you'll start with just one message in the list.

This may not work very well with the shared whiteboard, since you do need the whiteboard to manage a list of message in order to draw complex pictures.

Avatar

Level 2

Hey Raff - Thanks for the quick response. I will check out the session inactivity time as suggested and make sure that the messages are being dropped. I thought that I had tested this, but I will double check. 

My concerns about the message storage are related to privacy issues that are specific to our application. Is there anyway that someone outside of a valid session connected to our room to access the chat messages that are temporarily stored on the server?

Thanks

Avatar

Employee

LCCS messages are only accesible from a client succesfully connected to the room or (soon) via a REST API for which you need to be authenticated as the room/account owner (and both the rtmp and REST connection are secured with SSL)

Avatar

Level 2

Thanks Raff - I guess I am more concerned about a platform security breach on your end if there is data temporarily stored that is of a sensitive nature in a chat or whiteboard session.

Avatar

Correct answer by
Employee

The data is stored only in memory only. When "persisted" we check the node configuration and if transient we don't save that node to disk.

If you are really concerned about a security breach you should probably encrypt your messages before sending them via LCCS (it should be easy to subclass the current models and encrypt/decrypt the items on the fly).