greenlight icon indicating copy to clipboard operation
greenlight copied to clipboard

Consent on join can be circumvented by changing the setting while the room is running

Open ichdasich opened this issue 5 years ago • 5 comments

For 2.7, #1296 got merged. However, the merged version no longer checks if a room is running when changing the setting. This allows the following issue:

  • Enable recordings for a room and start it (with recordings enabled)
  • Change the setting to 'disabled'
  • Users joining the room are not informed about the session being recorded

The initial implementation by @yanosz did actually check for this. Is there any chance this can also be backported? I already had users ask about whether they could use this mechanic to circumvent the recording disclaimer when I ran @yanosz version in production (where it was not possible to circumvent this).

ichdasich avatar Aug 13 '20 13:08 ichdasich

@farhatahmad I just submitted my master thesis - what was the reasoning?

yanosz avatar Aug 13 '20 17:08 yanosz

@yanosz Congrats :).

The reason I removed it was because it made room settings inconsistent. At the moment, I believe there are a couple of Room Settings that suffer from the same issue, so I was planning on doing something more universal. Probably going to end up with something that prevents room owners from changing a rooms settings if a session is running for all settings, not just the recording one.

This is definitely a bug though

farhatahmad avatar Aug 13 '20 18:08 farhatahmad

As this is more-or-less security/privacy sensitive, is there a chance we can get this fixed in 2.7.2/soonish?

I am currently trying to let my own code-base not deviate too much from upstream (and this feature helped a lot in that ;-)), but it is somewhat critical for my use-case. Hence, it would be good to know your plans, so i can see whether hot-patching it myself makes sense.

Edit: Ah, and congrats @yanosz :-)

ichdasich avatar Aug 13 '20 19:08 ichdasich

Thanks - and thanks for your feeback. :-)

UI consistency is a very good point - actually, I was also wondering about other settings that cannot be applied while a session is running. (https://github.com/bigbluebutton/greenlight/issues/1163#issuecomment-615329822)

Regarding disabling all settings: That's a tricky part. I see some conflicting use-cases:

  • Given that a session has started. The moderator notices that join options (e.g. PIN-number) need to be changed and changes the settings. We had this situation at work, when the moderator actually forgot to delete the PIN-number of a room.
  • Some people tend to have long-running sessions. Think of a workshop or training going on for a week. BBB session timeout is set to a few days, to keep the chat, etc. Maybe settings need to be changed during this period.

Technically, there are settings that solely concern Greenlight (e.g. room pin). These can be changed, while the session is running. However, whether a setting is changeable or not results from BBB's API. This is purely technical and by no-means clear to the user. If there's a chance to provide an UX, which allows users to distinguish; that's a good idea, IMHO.

Furthermore, it could be helpful to terminate sessions from the settings screen. Use-case: Moderator - in a hurry - notices that he has forgotten to enable recordings and decides to change settings. When Greenlight informs the user on the running session, it could also provide details (e.g. number of users, running time) and show a button for terminating for session. Ideally, restarting a session could result in users re-joining automatically – but this is not possible with BBB atm, afaik.

yanosz avatar Aug 14 '20 07:08 yanosz

I like the suggestions. However, for the problem at hand, it might be good to get a quick fix out for the privacy sensitive part.

ichdasich avatar Aug 14 '20 08:08 ichdasich

Please note: Greenlight v3 has been released. With this new version, many of the issues and bugs that were present in v2 have been resolved.

As a result, we will no longer be providing updates or support for v2 (except for major security issues), and we will be closing any outstanding bug reports / feature requests related to v2. While we understand that some of you may still be using v2, we highly encourage you to upgrade to v3 to take advantage of the improved features and stability. If your request/bug still applies to v3, please open a new issue for it

farhatahmad avatar Feb 17 '23 15:02 farhatahmad