[Feature Request] Make recording of a session optional

[wolbernd]

When starting a BBB session via greenlight the API call to BBB to create the conference always contains record=true.

Since we mostly use our BBB for office meetings recording by default is not necessary and causes the disk to fill up pretty quickly.

It would be nice to have a room option like "Allow recording of sessions" which toggles if record=true will be passed to BBB on creation.

As far as I can see right now this option is hardcoded in the file app/controllers/concerns/joiner.rb (Line 89).

[sualko]

I think this is not the default behavior. For my fresh installation, recording has to be manually started.

Check if you have autoStartRecording=false in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties.

[wolbernd]

@sualko autoStartRecording is in fact something different.

If you submit the parameter record=true to BBB it then records the whole meeting (see here: https://docs.bigbluebutton.org/dev/recording.html#overview).

When the moderator pushes the Record or pause record button it will only note start and stop marks. After the meeting is done BBB parses all files and generates a bundle to be published. The option autoStartRecording=false is just used to virtually push the recording button when the first user joins. The parameter record=true just allows this behaviour.

If record=true is not set, the record button is not shown and BBB doesn't record in the background

[sualko]

When the moderator pushes the Record or pause record button it will only note start and stop marks.

That's crazy... But thanks for the clarification.

[farhatahmad]

Greenlight doesn't "record" every meeting in the way that you think it does. Greenlight pass record=true to allow every meeting to be recorded.

Recordings are only processed if the "Start Recording" files are created. The raw files can be deleted if the meeting isn't recording through something like a cron job

[sualko]

Greenlight doesn't "record" every meeting in the way that you think it does.

I think it does and @wolbernd explanation was very helpful. For me it's problematic that everything gets recorded without the knowledge of the user. If you publish the recording (raw or processed) is something different.

The raw files can be deleted if the meeting isn't recording through something like a cron job

That's true, but it's still recorded. If you visualize that someone would use his phone to record a privat meeting with the words, it's just for the case and I will delete it afterwards, I think you would react different.

[wolbernd]

Oh yeah that's right. I haven't looked at it from a data protection perspective yet. This might even be in violation of GDPR since data is being recorded without the user being made aware of.

Example case: Meeting is startet via Greenlight, no one pushes the record button, so no one is notified by BBB that recording takes place but still all audio and video etc. files are stored on the server until they are deleted via a cron job. Admittedly only admins of the server can access those files but from a legal standpoint this doesn't change a thing.

[basisbit]

This is correct. To be allowed to use BBB with Greenlight in Europe or for european customers, either disableRecordingDefault has to be set to true in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties so the recording doesn't get stored on disk, or the user has to be asked for permission and so on before joining the session. Just not processing/displaying the recording is not enough to be GDPR compliant. The start/stop recording button does only set start/stop markers so the recording can be processed & cut after the meeting finished, but it does not influence what actually gets recorded.

Edit: this post got quite a bit of attention, so I'd like to add that BBB + Greenlight can be operated in compliance to GDPR, but like lots of server software does, it requires proper installation and configuration. If you don't know what you are installing, then you should find someone who can help you get your system in compliance with GDPR. That includes setting logging levels of bbb + nginx + freeswitch + kurento + red5 + ufw, obviously disabling the session recording feature and also adjusting the bbb daily cronjobs. The bbb architecture + recording documentation is a very good start to learn about what bbb actually does and how it works.

[Sea444]

The best way would be to set default values to that values respecting GDPR and to let these setting easily been modified via administration backend for users outside Europe.

[ReimarBauer]

The API default of bigbluebutton is "false" for recording. In greenlight this is used as "true". So only the "disableRecordingDefault" of the bigbluebutton properties can be used now.

There are also options in GDPR which allows recordings based on the existence of legitimate interests,

• https://edpb.europa.eu/sites/edpb/files/consultation/edpb_guidelines_201903_videosurveillance.pdf
• https://vcc.live/blog/gdpr-affects-call-recording/

We should alter the join rules on greenlight and may be need to adjust the recording feature on the server. The first three can be done in the frontend.

a) on joining a room consent to recording, if recording is prepared.
b) room settings: enable/disable init of recording
c) user settings: recordings: never, ask me
d) server site recording has to take care for the users decission, filter what gets recorded - this needs an API change

We have also to consider that a room for one alone for something like a tutorial which could be shown to an audience needs only one consent.

[yanosz]

Hm ... from my impression it appears rather minor thing to configure recording yes / no on a per room basis. The flag could be stored in greenlights database (table rooms) and be applied when joining a room. To keep thing's simple, I'dn't put this into the rights mgmt (aka cancancan).

@farhatahmad would do you think? Could I go for a prototype? Is there a chance to have a PR accepted?

[farhatahmad]

@yanosz If it works in the correct way, then yes. The issue is that it needs to be configurable for admins which leads to more complexities with this potential PR as well (#1222).

We have meeting today to discuss some things, and if we go ahead with that PR, then maybe I'll just make the changes and include them in that PR

[basisbit]

what about changing the server and the api so that recording does actually only start storing the data only when the "start recording" button gets pressed? For many use cases, you don't know in advance if you want to record the meeting or not.
This would also reduce CPU load a bit on the server because then most meetings don't need to be recorded.

[ritzalam]

On Tue, Apr 14, 2020 at 12:07 PM basisbit ***@***.***> wrote: what about changing the server and the api so that recording does actually only start storing the data only when the "start recording" button gets pressed? For many use cases, you don't know in advance if you want to record the meeting or not. This would also reduce CPU load a bit on the server because then most meetings don't need to be recorded.

I am not familiar with GDPR so will not justify if BBB is compliant or not. I'll just explain how the recording works. If in the api and bigbluebutton.properties, recording is turned on, all media and events are automatically recorded. The start/stop recording button just add markers for processing of the recordings. Recording of media by default when record=true has become useful for meetings that the user forgot to press start/stop recording as we can then manually insert the markers. We've had a number of users that were happy that their recording were re-processed when they forgot to press start recording. The idea too of just using markers is to allow in the future to be able to edit recordings. Another property that might affect GDPR is the keepEvents=true property in bigbluebutton.properties. Even if record=true but keepEvents=true, the events are recorded (but not the media). This keepEvents=true generates the events.xml file which can then be used to process data for analytics (users, user activities, etc.) purposes. This is our first attempt of providing data of what happened in the meeting. Richard

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1163 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABNCYA6FE2HIQIOVH3PB2LRMSC5LANCNFSM4L2FKOVQ> .

-- ----- BigBlueButton Developer http://www.bigbluebutton.org https://github.com/bigbluebutton <http://code.google.com/p/bigbluebutton>

[yanosz]

@basisbit please discuss this for bigbluebutton. Greenlight has no chance but to specify the record flag when creating rooms.

The idea to keep raw files for batch processing later one is actually driven by your idea of not knowing whether to keep recordings in advance. Ditching batch processing in favor of real time recording is a difficult decision.

However, creating raw files can be considered to be a privacy violating issue. Having a per-room toggle option, whereby asking users for consent appears to be realistic.

[yanosz]

Btw. first try is #1296 - I'm going to revisit the PR when #1222 is merged.

[christianlupus]

a) on joining a room consent to recording, if recording is prepared.
b) room settings: enable/disable init of recording
c) user settings: recordings: never, ask me

Maybe an option always consent would be useful as well for the moderator that starts regularly.

d) server site recording has to take care for the users decission, filter what gets recorded - this needs an API change

The alternative would be to disallow entering if no consent was given in the sense "either you accept the chance of been recorded or you cannot use this service". Maybe with a bit more words (customizable?) but in fact, the question is: Is is a technical requirement to record the whole session if one wants to record at all?

[yanosz]

Heiho,

a) on joining a room consent to recording, if recording is prepared.
b) room settings: enable/disable init of recording
c) user settings: recordings: never, ask me

Maybe an option always consent would be useful as well for the moderator that starts regularly.

Hmm.. that's an interesting point. In general I'd like to avoid having users to consent to their own settings - that's superflous.

Still, there could be some edge case, in shared room situations, i.e. when user enter a room, without the usual onbording screen. I don't mind much about these situations, since users creating accounts in greenlight are legally required to consent to the privacy policy beforehand and the recording bar gives some indication, but INAL.

Having a note in the onboarding screen is part of #1296 - but one could argue, that this big fat red warning is clumsy. I guess, the layout will be subject to discussion.

greenlight/app/views/rooms/components/_room_event.html.erb

Line 21 in 52ed715

<h4 class="text-left text-danger"><%= t("room.recording_present") if @room.settings_hash["recording"]%></h4>

d) server site recording has to take care for the users decission, filter what gets recorded - this needs an API change

The alternative would be to disallow entering if no consent was given in the sense "either you accept the chance of been recorded or you cannot use this service". Maybe with a bit more words (customizable?) but in fact, the question is:

Typically, users can customize i18n-texts according to their needs. Having a "Consent & Join" button instead of a "Join" button is rather trivial.

Is is a technical requirement to record the whole session if one wants to record at all?

BBB does batch processing for recordings - recording yes/no happens on a per-session basis. I'm fine with this design. Using real-time processing instead of batch processing is probably more error-prone, less-stable and requires more ressources. From a privacy perspective, audio and video is recorded in both situations and published eventually - you need consent, for sure. From a GDPR perspective, short term data storage for technical reasons can be justiified IMHO, but INAL.

[basisbit]

From a GDPR perspective, short term data storage for technical reasons can be justiified IMHO, but INAL.

Looking at the legal requirements regarding short term data storage, that does not include recording the whole session and then only deleting the data weeks after post-processing. What would be ok is to store the data, then immediately trigger a service that processes and then deletes the data - but that would break being able to change the start/stop timestamps a few days later. (also see this and this)

Anyways, as soon as the note on the onboarding screen is shown and the user has to agree to it, the recording feature should be usable again in the EU or for EU customers, at least if the server is configured appropriately and all the other legal requirements regarding documentation and being able to export or delete private data on request are fulfilled.

Whatever, this repo/issue here is about Greenlight, so here only the Greenlight frontend related topics should be discussed and fixed.

[yanosz]

From a GDPR perspective, short term data storage for technical reasons can be justiified IMHO, but INAL.

Looking at the legal requirements regarding short term data storage, that does not include recording the whole session and then only deleting the data weeks after post-processing.

That's highly subjective. Given, that the users has consented to recordings, the duration of a post-production process is not limited by numbers defined in a law, nevertheless it has to be transparent. For instance, if one organisation needs a week for post production (e.g. including revisiting the recordings, editing, cutting, interview approvals), thats fine. It has to be appropiate and justified.

What would be ok is to store the data, then immediately trigger a service that processes and then > deletes the data - but that would break being able to change the start/stop timestamps a few days > later.

I don't agree. The EU requires data to be kept for the shortest time possible. It does not exclude the existence of a review process, that needs a couple of days, due to work that is needed to be done - as long as the authors can justify its duration.

Anyways, as soon as the note on the onboarding screen is shown and the user has to agree to it, the recording feature should be usable again in the EU or for EU customers, at least if the server is configured appropriately and all the other legal requirements regarding documentation and being able to export or delete private data on request are fulfilled.

Ehm - nope. Two things to have in mind:

• For the moment, greenlight instructs the server to record all sessions completly. Its up to the server to decide wheter to record a session or not.
• Recording a session is very privacy invasive. The operator has to make sure, that all participants agreed to it. This process cannot be implemented solely by greenlight. The legal basis is highly subjective to the operators (Article 28 or not; company internal (i.e. workers rights applicale) ./. public conferences). No predefined i18n text or templete can address all the diverse legal requirements.

For the moment, greenlight / bbb can be operated in the EU, if consent to recordings is given.

IMHO, greenlight can never alone fulfill all documentation-requirements needed by the privacy invasive properties of video recording . Operators should be smart enough to get a written confirmation beforehand. If consent is given this way, the greenlight screen's won't matter much.

Nevertheless, creating sessions without recording is not implemented in greenlight and poses a valid feature - imho.

[basisbit]

you write "Ehm - nope." and then agree with what I wrote...

So, I want to at least say that For the moment, greenlight / bbb can be operated in the EU, if consent to recordings is given. is not practical with the default settings of Greenlight, because so far there is no consent/agree-process integrated, by default everyone can join a session with a random name, thus the moderator can not even check if consent is given before the recording already recorded data from the user who joined and because the default config records everything and the person who installed is not made aware of any "post-production process" which might be needed.

So, lets stop this discussion here. There were already a bunch of good suggestions of what could/should be changed (for example the enable/disable recording option when creating the room and also the consent text + consent&join button) to make it much easier for the server operator to legally use the recording feature.

[farhatahmad]

I think @ritzalam provided some pretty important points from BigBlueButton's perspective.

Another property that might affect GDPR is the keepEvents=true property in
bigbluebutton.properties. Even if record=true but keepEvents=true, the
events are recorded (but not the media).

This means that even if the user sets recording to be off, there is still some information in the session that gets stored. As far as I know, keepEvents can't be configured by passing a parameter in the create call like record, which means that Greenlight has no control over it.

Going through the process of making recording configurable but still recording some information either way doesn't seem right to me.

[yanosz]

@ritzalam, @farhatahmad Thanks for your input!

This means that even if the user sets recording to be off, there is still some information in the session that gets stored. As far as I know, keepEvents can't be configured by passing a parameter in the create call like record, which means that Greenlight has no control over it.

Going through the process of making recording configurable but still recording some information either way doesn't seem right to me.

Indeed, that's a rather strange situation. Intuitively, I'd have expected to have a "all or nothing" situation w.r.t. recording. From I privacy perspective, I cannot think of use-cases, in which keepEvents is ok, but record is not (or vice versa).

From a greenlight point of view, it's reasonable to have a simple flag recording: yes / no; but the BBB-provider side is rather confusing.

Having an ticket / issue in bigbluebutton on keepEvents without record being present could help to clarify the intentions of the API behaviour. If so, I'd go for this "all or nothing" approach from an UX perspective and implement the API call accordingly.

[christianlupus]

Just one more thought on this: Consider you have a server with mixed rooms for recording/no recording. Now you want to record on some rooms. But on other rooms, you want to disallow it completely because critical data is to be discussed like a personnel interview. Then you must configure it room by room.

[yanosz]

I did a minor update to the PR - it should be functional atm. Yet, I'm confused by the UX regarding recordings.

In general, the recordings are started whenever a session starts, whereas Greenlight allows changing room options later one (i.e. while a session is running). From a UX perspective I'd expect changed settings to applied at once. Nevertheless, the recording cannot be stopped without terminating the session.

In consequence, I'd be helpful to disable the recording toggle while a session is running. Nevertheless - is "record" the one and only setting, that cannot be applied while a session is running? If not: How shall I maintain a consistent UX? (@farhatahmad - any insights? thx in adv)

[ReimarBauer]

I think we should have the change request on the burger menu

where we currently have

• Room Settings
• Manage Access
• Delete

Let's look first on new rooms

• On room creation we have to decide recording (yes/no)
• Hint: You can only change this decission with a termination/recreation of this room
• I would add enable recording, disable recording and this will do the recreation afterwards

On current existing rooms:

• Do you want to disable recording (yes/no)
• Hint: You can only change this decission with a termination/recreation of this room
• I would add disable recording, enable recording and this will do the recreation afterwards

[Arnei]

It might also be useful to allow the administrator to control whether recordings are possible at all or not. Similar to the "Allow users to share rooms" setting under "site settings" there could be a "Allow users to record" setting.

[yanosz]

It might also be useful to allow the administrator to control whether recordings are possible at all or not. Similar to the "Allow users to share rooms" setting under "site settings" there could be a "Allow users to record" setting.

That's done via .env:
https://github.com/bigbluebutton/greenlight/pull/1296/files#diff-2e442a3aa9a769d9607926f610e462f5

From a UX perspective, I'd like to be consistent with all other settings, i.e. specify room features in .env, apply defaults as proposed by #1222. I know that some .env settings potentially also qualify as site-settings (e.g. mute on join). Nevertheless, I decided to go for .env due to enabling recordings having more consequences (e.g. changes to the privacy policy) and cannot be accomplished solely by toggeling.

[iangilmour]

Oh yeah that's right. I haven't looked at it from a data protection perspective yet. This might even be in violation of GDPR since data is being recorded without the user being made aware of.

There is an additional security/GDPR problem here. After a default BBB + Greenlight install the recordings themselves are accessible without any user authentication, see: BBB issue 8505.

[yanosz]

Red-green color blindness is very common. Thus I'd suggest to change the consent button color to blue just like the other button when a user has to enter a password of the session.

Red is the default "danger" color in greenlight CSS (class="btn-danger"). I'm only using defaults, here. IMHO it looks like additional style sheets addressing accessibility is a different issue. @basisbit are you ok with filing a new issue, here?

Edit: I'm also not sure, that red-green blindness is impacting the UX that much: There are no green elements in greenlights default's CSS on this screen - users don't have to distinguish between green and red elements on this screen. People suffering from red-green-blindness just click a big gray button.

[basisbit]

Sure will create a new issue regarding that.

[ichdasich]

I had been running the code as it was online. Esp. when the two buttons have the same color (suggested by basibit/case on my dev system), this is just a doubleclick for users. I'd really suggest going for the checkbox, leading to the same UX as in other places where there is PP/Terms consent.

See an example here: https://dev.bbb.surfcloud.nl/b/tob-m6p-hfg

[yanosz]

@ichdasich Thanks for testing and providing feedback. I think, that we can agree to disagree. As I already mentioned, aligning the join process and (potential individual) requirements w.r.t. data protection policies is hardly related to a room setting for recordings. I'd rather prefer to go back to a warning text, then trying to find a consensus, here.

In general, already the warning text (no button, no check-box) provides an example for customization. It demonstrates how to reflect the recording status during on-boarding. Configuring colors (esp. on your dev-system) is out of scope. This PR does not define or use colors. It uses semantic classes (CSS: text-danger, btn-danger). Mapping these to colors (e.g. for customization) is not related to this issue.

But besides colors and on-boarding: Are you able to reproduce the problematic “session running” phenomena? It seems to be working for me, but there could be some rather problematic situations when providing defaults for some values. How can I trigger this?

Edit: Gotcha: When you close the room-settings dialog without cklicking "Update room" it persists.
It seems, that I've had clicked "Update Room" all the time ;-). I'll have a look at it.

[yanosz]

Ought to be fixed, now.

[ichdasich]

Sorry, still having breakfeast. So you could reproduce it now?

…

-- sent from my mobile; please excuse my brevity On May 17, 2020 12:42, yanosz <notifications@github.com> wrote: Ought to be fixed, now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1163 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABKT76G5OTCUZXGSBIU4G33RR65PRANCNFSM4L2FKOVQ>.

[yanosz]

Sorry, still having breakfeast. So you could reproduce it now?

Yep, ought to be fixed by yanosz@a4b7439

[ichdasich]

@yanosz just merged and deployed to dev. Indeed fixes the issue, thank you!

[christianlupus]

Red-green color blindness is very common. Thus I'd suggest to change the consent button color to blue just like the other button when a user has to enter a password of the session.

Red is the default "danger" color in greenlight CSS (class="btn-danger"). I'm only using defaults, here. IMHO it looks like additional style sheets addressing accessibility is a different issue. @basisbit are you ok with filing a new issue, here?

Edit: I'm also not sure, that red-green blindness is impacting the UX that much: There are no green elements in greenlights default's CSS on this screen - users don't have to distinguish between green and red elements on this screen. People suffering from red-green-blindness just click a big gray button.

That is not 100% true. The huge amount of people suffering from the red-green-issues are not completely blind but only partly. See English wiki and German wiki. So we (I am affected by this as well) can not only see gray but some other color I cannot tell you which. Ask me for any further questions.

You are right: As long as no distinguishment between red and green needs to be done there is no big deal here.

[yanosz]

@christianlupus thanks for your feedback.

According feedback I got, the 2-click variant (having a danger button for consent) doesn't seem address the requirements mentioned in this ticket. Probably, I'll go back to the simple notice in order to keep changes minimal. I'd guess, it could be helpful to address:

• GDPR-related on-boarding aspects in On-boarding: User consent w.r.t. privacy policies #1619
• Accessibility related design aspects in @basisbit ticket, that I'm unable to find atm.

IMHO it could be helpful do restrict the discussion / featureset of this issue to @wolbernd initial post.

I'll keep the commit for the consent-button for cherrypicking, in case sbdy is interested, then.
I hope to have things merged in the near future.

[yanosz]

Pushed to #1296 - consent button is removed. It was doing more harm, than good. I'm unable to spot any problems right now. Feel free to test. Travis-CI seems to take to time, yet.

[Arnei]

@farhatahmad Sorry to bother, but what's the current plan for this feature/pull request to make its way into a release? We're probably going to use it anyway, but having it in a release would of course be more convenient :)

[basisbit]

there are at least >30 companies / institutions using the PR 1296 already in production in Europe. Would indeed be nice if this makes it into one of the next releases.

[farhatahmad]

Fixed in 2.7

[basisbit]

• TODO: update privacy page of bigbluebutton.github.io regarding the recording feature being optional

(sorry, I am 200% busy currently, thus can't do this within the next weeks)

[rugk]

@basisbit Any news regarding that TODO? (just being a helpful pecker for your TODO comments here 🙂)

[jgribonvald]

Hi folks,

I'm not sure to understand all was done, but it would be great to make the recording configurable from option passed to the API.
I mean , it's great to have default values from BBB, but as example we would like to set from greenlight (and any other UI) if the room can be recorded or not, if it require a consent, if the record can start/stop at convenience of the moderator, etc...

I ask about that because we are looking at some fined user rights, we would like that only some peoples have the rights to make recording. And that without having to deploy a different BBB conf that set disableRecordingDefault and allowStartStopRecording depending on the context.

Thanks

[ichdasich]

IIRC the parameter you are looking for is called 'record'; This is also what is used by the greenlight feature to make recordings configurable.

[jgribonvald]

Thanks I will watch on that so.

But you mean that I need to add something to greenligth to pass this param ? I thougth that was already linked to the greenlight ROOM_FEATURES=recording rigth. Is it an other param ? thanks

[ichdasich]

For configuration support, please turn to the mailinglists.