'''Contributors:'''
- basisbit
- prlanzarin
- zner0L
In many countries there exist regulation of data protection. For operators of BigBlueButton services, especially private data protection regulations are an important topic. In the European Union the relevant regulation is the General Data Protection Regulation (GDPR). Many other countries also adopted similar regulations (for example the California Consumer Privacy Act (CCPA) in California, USA) and some of these regulation even have to be complied with outside of these countries under certain conditions. The following documentation is supposed to help understand where private data gets processed and stored in a typical setup of BigBlueButton, and what configuration options there are.
This section documents privacy related settings, defaults, and configuration options in BigBlueButton itself. Keep in mind that your configration changes here may be silently overwritten upon upgrades via apt, see bigbluebutton/bigbluebutton#9111 To prevent this, make sure to follow http://docs.bigbluebutton.org/2.2/customize.html#automatically-apply-configuration-changes-on-restart to ensure changes are retained upon upgrades and restarts.
When a room is created in BBB that allows recordings (i.e., the recording button is present) BBB will always record the session. This is independent of the button actually being pressed. The technical reason behind this is that parts of the recordings (esp. the SVG files for the Whiteboard) depend on earlier state to be properly processed, see: https://docs.bigbluebutton.org/dev/recording.html By default these files are stored for two weeks (see 'Retention of Cache Files' below). Furthermore, depending on the use-case and jurisdiction it might be prudent to retain the option to create 'retroactive' recordings, e.g., when users forgot to click the recording button.
Operators have two options for handling this:
Users can change /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties
and adjust disableRecordingDefault=false to disableRecordingDefault=true to
globally disable recordings. Furthermore, Recording of breakout rooms should be
disabled by setting breakoutRoomsRecord=false. In general, this is an
advisable idea (independent of disableRecordingDefault=true, as break-out
rooms might imply a certain level of privacy.
Users can deploy a custom script that purges recordings and cache-files of recordings if no recording markers are present.
Simple version:
/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')
For a more complete version that also explicitly deletes cache files of recordings for freeswitch/kurento, please see: https://github.com/Kalagon/bbb-recording-archive-workaround
BBB stores the presentations of sessions in /var/bigbluebutton even if the room is started with record=false.
Unknown, unclear which post-recording actions are triggered if no recording is created.
BigBlueButton stores the raw recording data for meetings that have recording markers indefinately. This might include parts of the session where BBB was not supposed to record.
This can be resolved by deleting raw recording data after a meeting has been archived. For setups using scalelite, this can be achieved by the following changes:
/etc/sudoers:
bigbluebutton ALL = NOPASSWD: /usr/bin/bbb-record
/usr/local/bigbluebutton/core/scripts/post_publish/scalelite_post_publish.rb, after line 66:
system('sudo', 'bbb-record', '--delete', "#{meeting_id}") || raise('Failed to delete local recording')
For other systems, removal of /var/bigbluebutton/recording/raw/$meeting/
should be added to the post-archive script.
This data can also be removed periodically, see Retention of cache files
By default, BBB recordings are accessible, see e.g., bigbluebutton/bigbluebutton#8505 Additionally, the URLs for recordings are easily enumerable, see bigbluebutton/greenlight#1466 and bigbluebutton/bigbluebutton#9443
Users can change the nginx configuration to restrict access to the recording URLs. Depending on the use-case, the auth statement in nginx can interact with the used frontend to enforce further restrictions (e.g., requesting the same credentials as the frontend). For an example of configuration options and an authentication callback to a greenlight frontend, see: https://github.com/ichdasich/bbb-rec-perm
The stack of BBB creates various cache files when recordings are enabled. Specifically in:
/var/bigbluebutton/recording/raw/
/var/bigbluebutton/unpublished/
/var/bigbluebutton/published/presentation/
/usr/share/red5/webapps/video/streams/
/usr/share/red5/webapps/screenshare/streams/
/usr/share/red5/webapps/video-broadcast/streams/
/var/kurento/recordings/
/var/kurento/screenshare/
/var/freeswitch/meetings/
For automatically cleaning up these files after recordings, see BigBlueButton always records when recording of a room is enabled. In addition, to prevent
this data to be written to disk, these files can be mounted with tmpfs to keep
recording caches in-memory. For this, the following lines have to be added to
/etc/fstab:
tmpfs /var/bigbluebutton/recording/raw/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0
tmpfs /var/bigbluebutton/unpublished/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0
tmpfs /var/bigbluebutton/published/presentation/ tmpfs rw,nosuid,noatime,uid=998,gid=998,size=16G,mode=0755 0 0
tmpfs /usr/share/red5/webapps/video/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0
tmpfs /usr/share/red5/webapps/screenshare/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0
tmpfs /usr/share/red5/webapps/video-broadcast/streams/ tmpfs rw,nosuid,noatime,uid=999,gid=999,size=16G,mode=0755 0 0
tmpfs /var/kurento/recordings/ tmpfs rw,nosuid,noatime,uid=996,gid=996,size=16G,mode=0755 0 0
tmpfs /var/kurento/screenshare/ tmpfs rw,nosuid,noatime,uid=996,gid=996,size=16G,mode=0755 0 0
tmpfs /var/freeswitch/meetings/ tmpfs rw,nosuid,noatime,uid=997,gid=997,size=16G,mode=0755 0 0
After that, the operator has to execute bbb-conf --stop; mount -a; bbb-conf --start.
Furthermore, the uid/gid values have to be adjusted to the local installation. The above example assumes:
red5:x:999:999:red5 user-daemon:/usr/share/red5:/bin/false
bigbluebutton:x:998:998:bigbluebutton:/home/bigbluebutton:/bin/false
freeswitch:x:997:997:freeswitch:/opt/freeswitch:/bin/bash
kurento:x:996:996::/var/lib/kurento:
BBB retains various cache and log files. The general retention period for these files can be configured in /etc/cron.daily/bigbluebutton.
historyis the retention period for presentations, red5 caches, kurento caches, and freeswitch caches in daysunrecorded_daysthe retention periods of recordings for meetings which have no recording markers set (user expectation: Were not recorded)publised_daysthe retention period of recordings' raw data, if these got published. To enable this, the line#remove_raw_of_published_recordingsalso has to be uncommented
For directly deleting these caches, please see 'Deploy a post-recording script that removes recordings without recording markers'
A stand-alone BBB server (unlike with scalelite) does not delete recordings
when it receives a deleteRecording request via the API. Instead, it moves the
recording to /var/bigbluebutton/deleted and unpublishes it.
There is no easy resolution configurable. Users are advised to create a
high-frequency cron-job, that deletes the contents of
/var/bigbluebutton/deleted.
If users opt to keep recording files and logs, they should know and change:
- the duration for which to keep to keep the recording files in
/etc/cron.daily/bigluebutton, using thelog_historysetting - the logrotate setttings in
/etc/logrotate.d/(bbb-record-core.logrotate|bbb-webrtc-sfu.logrotate)which rotate logs in/var/log/bbb-webrtc-sfu/every 7 days, and/var/log/bigbluebutton/(bbb-rap-worker.log|sanity.log)every 8 days
This logs all interactions with rooms, i.e., when they were created, who joined when, and when they left in /var/log/bigbluebutton/bbb-web.log
The log verbosity of the core application can be reduced by setting
appLogLevel=Error in
/usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties.
By default bbb has full access logs enabled for nginx. This includes users IP
addresses, usernames, joined meetings, etc. This can be disable by switching
the loglevel to 'ERROR' only in /etc/nginx/sites-available/bigbluebutton and
/etc/nginx/nginx.conf:
error_log /var/log/nginx/bigbluebutton.error.log;
access_log /dev/null;
Freeswitch, as installed, by default logs with loglevel DEBUG. This can be
changed in /etc/bbb-fsesl-akka/application.conf and
/etc/bbb-fsesl-akka/logback.xml. The default configuration Stores usernames,
joined sessions and timestamps.
Red5 seems to only log meeting ids and timestamps of when video feeds are
started. Still is configured for log-level 'info', which spills the disk. Can
be configured in /etc/red5/logback.xml.
Logs session names and timestamps, as well as user IP addresses. This also
includes user IP addresses behind NATs, i.e., the actual client addresses,
potentially making users identifiable accross sessions. Can be configured in
/etc/default/kurento-media-server, see
https://doc-kurento.readthedocs.io/en/latest/features/logging.html
Note, that this can most likely be overridden by kurento's systemd unit file.
Hence, --gst-debug-level=1 should also be set in /usr/lib/systemd/system/kurento-media-server.service.
BBB uses a TURN server for nat traversal. By default, a STUN server from
freeswitch.org is configured for BBB. Set up your own TURN/STUN server, and
configure it in
/usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml, see
https://docs.bigbluebutton.org/2.2/setup-turn-server.html
There is a hardcoded google STUN server in
/usr/share/meteor/bundle/programs/web.browser/app/compatibility/sip.js.
However, this should never be used, as a failed GET of the TURN/STUN settings
in BBB-web should return an empty array, overwriting this setting. Nonetheless,
careful users may want to replace this default.
Kurento uses a google STUN server to identify its own external IP address on
each ICE connect. This can be changed in /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini,
by statically configuring the external interface and disabling the stun server
if the kurento system itself does not sit behind NAT.
For client side kurento activities (listen only, screenshare, video) there is a public fallback STUN server pool which is used if the bbb-web GET fails. There is work on removing this default.
When using an upstream greenlight, bbb rooms are always created with 'record=true'. This leads bbb to record full sessions, even if the recording button is not pressed, see above.
There exists a pull-request that adds per-room enabling of the recording feature, see: bigbluebutton/greenlight#1163
Greenlight does not request consent to a privacy policy and/or recording of a session when joining a room as a guest.
BigBlueButton has no feature that forces participants to consent to a privacy policy or being recorded prior to joining a room.
In bigbluebutton/greenlight#1163 it is discussed how this can be addressed. https://github.com/bigbluebutton/greenlight/blob/52ed7150f68c6c66c0488374ccc3457d30fd09d4/app/views/rooms/components/_room_event.html.erb#L21 adds a disclaimer. The code could be extended to provide a link to the privacy policy, and a checkbox users have to press to acknowledge that the meeting they are joining will be recorded, and that they consent to this; The join button should only be enabled when that checkmark is set.
A more substantial change to BBB and greenlight would be selective recording, i.e., excluding video, audio, chat and drawing input from users that did not consent to a recording.
In Greenlight, room URLs contain the username of the owner, which might also be private data. Solving this depends on bigbluebutton/greenlight#1057
Greenlight supports displaying of terms and conditions for registered users/upon registration. See: http://docs.bigbluebutton.org/greenlight/gl-config.html#adding-terms-and-conditions
By default, BBB recordings are accessible, see e.g., bigbluebutton/bigbluebutton#8505 Additionally, the URLs for recordings are easily enumerable, see bigbluebutton/greenlight#1466 and bigbluebutton/bigbluebutton#9443 Greenlight, by default provides two settings for recordings: public, i.e., the recording is listed on the room page, and unlisted, i.e., the recording is only accessible via the (enumerable) direct link.
Greenlight can be patched to allow more fine-grained control of recording visibility and publications. With https://github.com/ichdasich/greenlight/tree/rec_restrictions a third value is added to the recording visibility pull-down menu (public/unlisted/private), which leads to corresponding recording metadata being set (gl-listed=true/unlisted/false) in the recording either in scalelite or on the bbb host.
https://github.com/ichdasich/bbb-rec-perm can then be used to check requests for recordings against that metadata, returning a 403 if the recording is set to private, and returning the recording if it is set to unlisted or public.
By default, greenlight logs to $GREENLIGHTDIR/logs/production.log. Removing that line from .env does keep the logs, but does not expose them to the docker host. The easiest sollution is linking GREENLIGHTDIR/logs/production.log to /dev/null
By default greenlight has full access logs enabled for nginx. This includes
users IP addresses, usernames, joined meetings, etc. This can be disable by
switching the loglevel to 'ERROR' only in
/etc/nginx/sites-available/bigbluebutton and /etc/nginx/nginx.conf:
error_log /var/log/nginx/bigbluebutton.error.log;
access_log /dev/null;
By default, coturn logs to /var/log/coturn.log, with regular log-rotation. This logfile includes IP addresses of users using the TURN server, and the ports they use. Together with other BBB logs this enables identification of the sessions these users joined.
coturn has no option of restricting logging. The best option here is linking
/var/log/coturn.log to /dev/null
Scalelite uses a container running nginx as frontend, which accumulates standard access logs. By default scalelite has full access logs enabled for nginx. This includes users IP addresses, usernames, joined meetings, watched meetings etc. The easiest way to address this is migrating the nginx to the host.
Then, this can be disable by switching the loglevel to 'ERROR' only in
/etc/nginx/sites-available/bigbluebutton and /etc/nginx/nginx.conf:
error_log /var/log/nginx/bigbluebutton.error.log;
access_log /dev/null;
The GDPR lists several important considerations, especially:
- The right to request a (machine readable) aggregate of all private data stored
- The right to have all personal data be erased
Both pose challenges in the context of BBB, especially when considering that rooms can be joined anonymously/ This means that an operator may not be able to identify all private information connected to a user easily, even though it is clearly personal, e.g., webcam recordings of a room joined to as a guest with a pseudonym.