[Privacy Issue] RAW recordings are created and stored, even if the meeting isn't recorded

[ichdasich]

Describe the bug
Raw recordings are stored even if no recording button is pressed.

To Reproduce
Steps to reproduce the behavior:

1. Start a meeting
2. DO NOT Click on 'Record meeting'
3. End the meeting
4. Find RAW files of the session on the BBB server

Expected behavior
Sessions during which the recording button is not pressed are not stored.

Actual behavior
Sessions during which the recording button is not pressed are stored

Additional context
I am not sure if I am holding it wrong, but i migrated to a new BBB setup, and moved recordings. There, I found that reencoding all recordings would make recordings of non-recorded meetings show up in my users' accounts. This obviously caused unrest and is an (unintended) privacy violation on my side.

This should:

• Not be default behavior
• Be clearly documented
• Possible to configure off

[ichdasich]

To clarify: I understand that there might be a reason to do this temporarily; However, if there is no recording-press during a session, the RAW data should be deleted when the session ends.

[basisbit]

This is not a bug, but instead this is a documented feature and design decision. See https://docs.bigbluebutton.org/dev/recording.html

[basisbit]

Related to bigbluebutton/greenlight#1163 (comment)

[ritzalam]

You can drop a script in the post_archive dir to check if there are recording marks. If none, delete the recording.

/usr/local/bigbluebutton/core/scripts/post_archive

Here is how to check.

https://github.com/bigbluebutton/bigbluebutton/blob/develop/record-and-playback/core/scripts/archive/archive.rb#L203

[ichdasich]

@basisbit the problem is not the design decission. The problem is the absence of the script @ritzalam suggested.

[basisbit]

This is still on purpose (although not a good default in my opinion).
There already exists a script in /etc/cron.daily/bigbluebutton which deletes the raw recording data 14 days after the recording ended by default. This allows one to create a recording of the session even when the record button was not clicked. Anyways, when starting a new session, the bigbluebutton API call specifies if recording is desired or not. This allows the frontend to handle notifying the user of data being recorded / ask for permission or not enable the recording feature at all. To be GDPR compliant on a public server which allows guests, you have to set disableRecordingDefault to true anyways (Edit, this was true back in 2020, but not anymore nowadays, when the system is properly set up/adjusted).

[ichdasich]

Btw, closing this as duplicate of bigbluebutton/greenlight#1163

[yanosz]

@ichdasich : Please consider reopening this issue.

IMHO this issue relates to the UX of bbb's HTML5 client. Typically, recoding user content (e.g. webcams) requires consent in many situations, whereby users has to be informed about recordings going on.

However, the current UX of the HTML5 client suggests, that no recording is done if the record button is grey / white.

Based on the old red recording light in a TV studio, users expect a recording to be present, when the button is red, whereas a grey / white button suggests, that no recording is taking place. But: In the background, recording takes place nevertheless, as long as record=true is specified when creating the room.

I'd suggest to change the UI of the HTML5 client.

• The record button has to be red and looking activylish when recording is enabled on a session basis.
• In addition, the the insert begin/end marker action should be addressed by a button labeled as "Insert Begin Marker" (or "insert end marker" resp.)

[ichdasich]

Hey @yanosz,
I agree with you there. I though the other ticket was indeed also in BBB, not in GL; For greenlight, there should be a specific interaction. I will open a new ticket in the GL repo for the interaction changes for joining and starting rooms.

[ichdasich]

Reopened. UX for GL considered in bigbluebutton/greenlight#1395

For BBB, it might be nice to change the meaning of the recording button:
make it always red (different shades for set-start-marker/set-end-marker) and reword the recording notion around "Setting start-marker/setting end-marker"

User stories:
As a moderator, i want to use a button labled 'start recording marker' to set a start recording marker if none has been set yet.
As a moderator, i want to use a button labled 'stop recording marker' to set a stop recording marker, if a start recording marker has been set and no stop recording marker is present thereafter.

[marcarneg]

I want to second this strongly, since the GDPR (DSGVO in german) requires everyone to specifically consent for userdependent data to be saved.

Saving the videostream even temporarily, when the UI suggests that nothing(!) is being actively recorded, could (and IMHO should) be interpreted as an active lie.

[basisbit]

@marcarneg regarding consent for video recording, please see bigbluebutton/greenlight#1163 - if you use some other frontend, the consent-text/check has to be done in that specific frontend before the user joins the session.

[ichdasich]

Actually bigbluebutton/greenlight#1163 bigbluebutton/greenlight#1395 has been closed as a duplicate of that.

[marcarneg]

@basisbit This is still impossible to sell to people, when security of personal data is important to them. Yes, recordings of session should be possible (and therefore greenlight should correctly point that out before the session starts), but if the moderator promises (and the html5 frontend signals), that the session is not being recorded, it's very important to make sure, thats totally true.

In our case, we even don't want participants to create a greenlight-account on our server (they're joining via url+pin)- a saved video on the harddisk without a direct consent or at least notification to the users could send a complicated (and destructive) message.

[ichdasich]

@marcarneg As a hot fix in your situation: If you do not need recordings, globally disabling should be relatively straight forward (which then also prevents the recording of the temp-files.) This then only might (didn't check) leave temp files in, e.g., freeswitch.

In general, I fully agree with your comment. My todo currently has implementing a consent switch on the room-join form (for my own fork of GL; Not really prod-level code.), also detailing this.

[basisbit]

If you don't need recording, set disableRecordingDefault to true in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties
If you need recording capability, you could have your teachers / presenters ask every participant of the session, and if they agree, then the presenter can use OBS to record the screen.
(Personally, I'd say that every public instance of BBB that uses Greenlight and has not disabled recording either in Greenlight code or in BBB config, is not in compliance with GDPR. There was plenty of discussion about this already in the previously mentioned issue, so let's not continue it here, please.)

[basisbit]

In our case, we even don't want participants to create a greenlight-account [...]

@marcarneg They don't have to create a greenlight account. The session-join-link shows a "join this session" page. Exactly this page of your frontend should be extended to ask the participant to accept the recording legal information if record=true is set for this session.

[fefrei]

A naïve question: I get that BBB records everything temporarily because it makes recording easier. But why does it hang on to these temporary files for 14 days? I think a way saner, and more defendable default, would be to allow recordings, using the same infrastructure as now, but immediately cleanse the temporary files after the postprocessing after the end of a meeting is finished.

[ichdasich]

I actually configured my installation like that, and put all temporary directories/the recording directories on TMPFS. (very nasty solution adding sudo access to bbb-record for the bbb-user and calling a record-delete if there were no recording markers.):

/etc/sudoers:
bigbluebutton ALL = NOPASSWD: /usr/bin/bbb-record

and
/usr/local/bigbluebutton/core/scripts/archive/archive.rb (after line 242):
BigBlueButton.logger.info("There's no recording marks for #{meeting_id}, deleting the recording.")
system('sudo', 'bbb-record', '--delete', "#{meeting_id}") || raise('Failed to delete local recording')

I suppose (but don't know) that this feature comes from an environment where people occassionally forget to hit record, and then panic-y write to the IT that they forgot things... and demand it to be restored. ;-)

[OskarCarl]

I've created a more extensive another version of the change in archive.rb. I didn't want to keep the temporary files anywhere so the changes to tmpfs are not required in my version. [Disregard that. I should've read the bbb-record code beforehand]
It's not pretty but it works on our server. It also allows automatic cleaning of previously generated archives.

https://github.com/Kalagon/bbb-recording-archive-workaround

[felcaetano]

A naïve question: I get that BBB records everything temporarily because it makes recording easier. But why does it hang on to these temporary files for 14 days? I think a way saner, and more defendable default, would be to allow recordings, using the same infrastructure as now, but immediately cleanse the temporary files after the postprocessing after the end of a meeting is finished.

I've been using BigBlueButton since 0.81 and one of the most common requests I get is "I forgot to click (or misclicked) on the recording icon, can you still retrieve it?". Usually followed by a "It is a really important meeting".
So yeah, I love that it keep temporary raw files for a potential rebuilding. I don't wish this to go away.
But, sure, a better indication that the session is being recording regardless is welcome. (Maybe when you activate your webcam?)

[fefrei]

I agree that having the ability to record post-meeting is a nice option – but it should be that, an option, in my humble opinion.

[basisbit]

And it has to be implemented so that it actually is easily legal usable in most of the world: that requires asking for permission before the user joins the meeting. Thus, asking just before webcam is activated is not a suitable solution.

[felcaetano]

And it has to be implemented so that it actually is easily legal usable in most of the world: that requires asking for permission before the user joins the meeting. Thus, asking just before webcam is activated is not a suitable solution.

Indeed, asking before joining makes way more sense.

[Cistoge]

I do not understand ichdasich's suggestion to add the mentioned lines to archive.rb after line 242. My line 242 is

else

and that else relates to line 226

if not archive_has_recording_marks?(meeting_id, raw_archive_dir, break_timestamp)

So, should the suggested lines not be inserted BEFORE line 242?

[DudeCalledBro]

Please update the documetation, so that the european customers can make changes in their /usr/local/bigbluebutton/core/scripts/archive/archive.rb. My ruby experience is pretty bad.

Thank you :)

[ghost]

Are you still facing this issue? Nearly been a year, Please let me know. We might ship the fixed version (Releasing version 3.4 by 1st October 2021) of the BigBlueButton which has been re-branded and is still under process... On our Fork, we have seemed to fixed this issue. In case, you need help , I am happily willing to contribute my code.

[basisbit]

@vagbox ??? I suggest reading the last couple of messages instead of randomly mentioning a seemingly non-existing fork from a github account with close to zero participation in anything BigBlueButton related.
The typical frontend (Greenlight) has been adjusted so that a session creator can choose if a session should be recorded or not. There exist adjustments for showing a notification text before joining a recorded session in order to comply with certain legal requirements that exist in some countries. This issue here is not closed because a rewrite of the recording feature would still be a nice and desirable improvement, so that it is easier to use the recording feature in countries with very strict data protection requirements.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rugk]

This should really be handled as a critical security issue (partly to you, bot!).

[basisbit]

@rugk see discussion above. This issue was already handled quite a while ago and is not critical any more at all. The current implementation is just not yet as good as desired, thus it is kept open until a bigger rewrite of it is done.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.