[Feature Request] Make recording of a session optional

wolbernd commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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,

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 commented 4 years ago

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 commented 4 years ago

@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 (https://github.com/bigbluebutton/greenlight/pull/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 commented 4 years ago

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 commented 4 years ago

On Tue, Apr 14, 2020 at 12:07 PM basisbit notifications@github.com 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 https://github.com/bigbluebutton/greenlight/issues/1163#issuecomment-613533260, 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 commented 4 years ago

@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 commented 4 years ago

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

christianlupus commented 4 years ago

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 commented 4 years ago

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.

https://github.com/bigbluebutton/greenlight/blob/52ed7150f68c6c66c0488374ccc3457d30fd09d4/app/views/rooms/components/_room_event.html.erb#L21

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

This is hardly related to #1163. This issue discusses creating sessions without recordings. Implementing ACLs to existing ones is a different subject.

datenpunk commented 4 years ago

As a quickfix to allow users to enable recordings on a per room basis I only allow recordings for rooms with names ending in _recording for all other rooms recording is disabled. https://github.com/datenpunk/greenlight/tree/restrict_recording_quickfix

yanosz commented 4 years ago

I just pushed to #1296. From the UX side, the toggle is disabled when a session is active. I find it rather intuitiv, but I'm open for suggestion. The patch should be functional. #1222 is closed and the patch is rebased. I guess, that you could give it a try

@farhatahmad I'd cool to get feedback on a few things:

The current test coverage seems to ignore joiner.rb - no tests are failing, when changing the record flag. That makes me feel uneasy, since there's no check, wheter the value specified in the UI is actually applied to the API call to BBB. Have you thought about these kind of tests?
The room_settings - method in the rooms_controller applied JSON encoding twice. The field was stored as JSON and encoded as JSON. Assuming it was an error, I changed it. Is there a reason for applying JSON-encoding twice?
Are you happy with the code as of now? What is needed before merging this PR?

Thanks in advance, Greetz, yanosz

ichdasich commented 4 years ago

Heho, Thank you! This really helps!

I just took a look and integrated it into my dev-systems. Will roll out to production in the coming days (want to add some more i18n). Furthermore, I added a couple of things to make it work better(commits below, feel free to copy/paste; not the repo-hygien/code quality for a pull request), and noticed some things I did not (fully) address.

Addressed

room_params has to allow :recording in rooms_controller.rb: https://github.com/ichdasich/greenlight/commit/9391f044e72bf32477eddb97fcb5f26a5785da23
There is no admin-override for the recordings setting: https://github.com/ichdasich/greenlight/commit/5714b791322e34f2da4f32f5aac9925edd7f6461 and https://github.com/ichdasich/greenlight/commit/388eb12d70327115b4346df46e1e034b1e5e99fb

Noticed

There is no handling for rooms that to not yet have a recording key in the roomsettings JSON. I patched around that by putting a default into the code, but for transition it might be nice to have control via a migration script for the DB or by making this another admin setting (so you can either opt for mirroring existing behavior for existing rooms)
The moodle for changing room settings is also used for creating rooms, where the check if a room is not active errors out, i.e., whatever you set on creation is not saved, as the room is seen as running for some reason.
Newly created home-rooms also do not yet get a recording: key in their settings JSON

But in general, it works really nice, thanks!

.oO( In production now, btw... will let you know if it crashes and burns.)

yanosz commented 4 years ago

@ichdasich Thanks for your feedback. You're keen having this in production, since vital integration tests are missing. nvm - thanks for the hint on https://github.com/ichdasich/greenlight/commit/9391f044e72bf32477eddb97fcb5f26a5785da23 - appereantly, it got lost while rebasing.

For the admin-setting: I decided to go for .env instead of settings for the reasons outlined in this ticket.

Edit: To be more specific.

I find it rather confusing to have 2 places (.env, admin settings), where administrators can disable a certain feature, since it creates a rather confusing UX: The setting has to be enabled in both places and users have to remeber changing the other. This can be frustrating - what's the UX perspective for having both?

ichdasich commented 4 years ago

I agree that this is somewhat confusing, and would personally suggest going for the admin interface instead of .env. However, I put it into my version for consistency reasons. It is there for everything else after all. ;-)

More specifically, personally I'd also like to see the default options (default on room create/if not present) there in the admin interface. But this is a discussion beyond the scope of your pull request, i'd say.

yanosz commented 4 years ago

tl;dr: Maintainer feedback would be helpful

More specifically, personally I'd also like to see the default options (default on room create/if not present) there in the admin interface. But this is a discussion beyond the scope of your pull request, i'd say.

Depends. I'm not certain. The UX perspective is relevant for this issue. Having a setting either in the .env, or in the admin panel or both is of practical concern. Nevertheless, there a pros and cons for all options:

Having a per instance configuration (.env) is inline with idea of cutomizing greenlight w.r.t mandatory privacy policies depending on the user legal status, but is less flexible
Having both is inline with the room-features as of today, but is confusing from a UX perspective.
Having solely admin-Setting helps to provide reasonable default options has a good UX w.r.t recordings, but breaks with the idea of the .env file.

I'd cool to get some feedback on how room features will be implemented in the next release and in what way the redundancy is addressed. E.g. for the moment non-availble room settings are hidden without any notice. I'd prefer a notice like "disabled in the instance configuration (.env file)". But this - for sure - is a different topice.

yanosz commented 4 years ago

I just cherry picked ichdasich's commits and pushed this to the PR branch and made a single commit out of this: https://github.com/yanosz/greenlight/commit/cfafee0f4e888f575a91e7dd0f5468cf33887208

It looks a little bit like its difficult to get maintainer feedback on this, due a fair share OpenSource rushes into committing to this project nowadays ;-). @ichdasich is it running stable in production for a few days no? If so, I'd like to take this Branch as it is an file a new "Fix 1163" PR. I hope to have it merged soon, then.

ichdasich commented 4 years ago

Heho, well, don't tell my students that I am running dev code in production. :-P

I will probably rebase my changes branch to the newest version of your branch and the head of master tonight; Let's see how things go with that.

What i think should also be adressed for this is:

fixing the room create modal (dunno if you merged that)
fixing the consent page if room recordings are enabled: The join button should be disabled, until a checkbox for 'I consent to the recording... ' etc. is checked.

yanosz commented 4 years ago

Create moodle? What are you talking about?

ichdasich commented 4 years ago

Modal m-( I am not good with words. :-P

You added checks around 'room running' to the room edit/create modal. However, when I deployed this, I noticed that on room creation the case for 'room running' was shown, and hence any option set for 'Recording' on room creation was discarded. I assume that this is due to the check in rooms.js behaving differently if the room is not yet created.

https://github.com/yanosz/greenlight/commit/8bd81971f8fe01e4ab58cfb8663aea9059975565#diff-ca7855f9fab21b58b96b20275d568e10

https://github.com/yanosz/greenlight/commit/8bd81971f8fe01e4ab58cfb8663aea9059975565#diff-2405afd37b7411d49972f349619729f7

yanosz commented 4 years ago

@ichdasich Thx - I'll have a look in the next days. I've to admit, that some weired thinks happend on rebasing. In general, null / not created yet / etc. should default to not changes in controls

For the checkbox: That's almost out-of scope. IMHO the need for a checkbox is highly subjective and based on your legal sitaution. Some may argue, that its enough to mention, the red warning in the privacy policy. Others argue, that it is enough to label the button "Consent & Join" instead of join. Others are more happy with a checkbox, whereas others are annoyed by the extra click from a UX perspective

In general, that really depends on your privacy policy and a specific privacy policy requires customization in almost any situation - for displaying a certain link at least.

That being said: I'm ok with implementing a checkbox if there's no veto in the next days (w.r.t. this issue). If there's one, I'd like to leave the code as of it is today.

ichdasich commented 4 years ago

Heho, your choice. I am already very grateful for what you did so far! And thanks!

rasos commented 4 years ago

GDPR requires consent of each user to start any recording. So Europeans definitely need a checkbox 'I consent to the recording option.' before joining the room.

yanosz commented 4 years ago

@ichdasich what's the current status - have you noticed any other problems? I'll check the room creation issue and try to finish the thing as proposed.

@rasos GDPR-related issues are almost out-of-scope. This issues addresses room-configuration w.r.t. recordings. The current onboarding process for unregistered users does not provide any kind of documentation - especially no legally sound audit trail w.r.t. consent. Therefore, I seriously doubt that this issue can address GDPR related aspects. IMHO people need to customize greenlight to address individual aspects w.r.t their legal position.

ichdasich commented 4 years ago

@yanosz works like a charm. Have scheduled maintenace to remove the record=true default i had transitionally in tomorrow.

Concerning the checkbox: Making users klick a checkbox and only then enable would imho still be in scope (To ensure they actually notice the session is being recorded, and making a concious choice.). Sadly, I am not enough of a coder to implement that myself.

yanosz commented 4 years ago

Hmm... I fixed the dialog on room creation and added a test-case for the settings. That should be fine now

I checkbox for consent is really ugly. There's no way of directing the focus of the user in a meaningful way. If it's above the name input, its irritating. If it's below, it's not in focus.

I experimented with a 2-click form (as pushed recently). At first, the user has to consent to the recording - afterwards the join button is presented. That's sane from a UX perspective - imho - but is somewhat out-of-scope for #1163. Hence, I created to commits.

I'd cool, if you could test the branch in #1296 and provide some feedback.

ichdasich commented 4 years ago

Gave the branch a test, but would argue that it does not sufficiently divert a users attention to be considered consent. I would actually be looking for something similar to the consent button on the terms on registration/login_after_terms, i.e., if the box is not checked, notify that consent is required, and do not allow room-joining before the checkbox is not set.

I gave this a shot in https://github.com/ichdasich/greenlight/tree/consent_button The tree is sadly an absolute mess... not enough experience with git, ruby, and being a dev. ;-) In case you like it, please feel free to pick from the code.

Main essence is in https://github.com/ichdasich/greenlight/blob/consent_button/app/views/rooms/join.html.erb and the removal of the error text in https://github.com/ichdasich/greenlight/blob/consent_button/app/views/rooms/components/_room_event.html.erb together with two new entries to the i18n files.

Edit: The room edit/create modal is still buggy on room creation btw. When there is any running room, an active session is being detected, and the recording setting can not be adjusted for a to-be-created room.

yanosz commented 4 years ago

Thanks for your feedback. Regarding:

Edit: The room edit/create modal is still buggy on room creation btw. When there is any running room, an active session is being detected, and the recording setting can not be adjusted for a to-be-created room.

Have you done a clean pull? It seems to be working for me. I rebased / forced push, btw.

Gave the branch a test, but would argue that it does not sufficiently divert a users attention to be considered consent.

Hmm... I'm not sure, if everything works as it should be. In general, there's a big red button that has to be clicked: First Screen

Has this shown up? After clicking the button, the name-inpurt appears: Second Screen

IMHO, users taking this onboarding-process are aware of a recording taking place.

Please check, that you're actually running the codes as it online. E.g. are these changes part of the code, that you're running? https://github.com/bigbluebutton/greenlight/pull/1296/commits/28657abff4976d70e3dccc6503d7cda5590f6e79

basisbit commented 4 years ago

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.

yanosz commented 4 years ago

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 commented 4 years ago

Sure will create a new issue regarding that.

bigbluebutton / greenlight

[Feature Request] Make recording of a session optional #1163

--