Greenlight: On-boarding: User consent w.r.t. privacy policies

[yanosz]

Is:

• Greenlight generates links for inviting users. When taking the invituation, user on-boarding asks for names and access code (if required). Consent regarding data protection policies is not required

Should:

• Giving consent regarding the privacy policy should be part of the on-boarding process. Entering a room should require explicit consent to data processing.

Note: This idea is also discussed in #1163, but got stuck during discussion. In general, consent is required even when no recordings are taking place (private data is processed in any case). Ideas w.r.t. recordings range from simple notices to checkboxes and an additional screen during onboarding (1st: consent, 2nd: access code, 3rd: Name).

[ichdasich]

For documentary purposes, I am crossposting my proposal from #1163 in here:

Main code here: https://github.com/ichdasich/greenlight/blob/consent_button/app/views/rooms/join.html.erb

Screenshots:

If the user tries to join the room without checking the box:

This can easily be extended for cases where there is no uploaded privacy policy/requesting consent from users when there are no recordings (with less disclaimer text) in app/views/rooms/join.html.erb.

[lonesomewalker]

I would also go for this solution, because it makes Greenlight more GDPR friendly (but not fully compliant).
Otherwise no consent is given to use BBB.
Please keep in mind: even if you run your server in countries outside the EU, and somebody joins from EU -> you have to check and be aware of this.

To get this done, we would need 2 additional variables:
privacy policy and imprint

And the text:
"i accept the privacy policy" is kinda unlucky.
Better would be: "i've read/i noticed the privacy policy and agree/consent".

[yanosz]

well... there are some thinks to discuss:

• How to document consent, having a legally sound audit trail?
• How to have a consistent onboarding experience?
• How to explain customizing w.r.t to custom privacy policy?
• Is consent supposed to be provided inband (i.e. by greenlight) or out-of band, i.e. by having an external landing page.

Personally, I'd vote vote an out-of-band implementation: Greenlight has an URL-configuruation option (.env), provinding a hook to an external system. The external system takes care of all privacy policy releated issues (showing the policy, asking for consent, documenting consent) and redirects to greenlight after privacy related on-boarding aspects are complete.

[yanosz]

Btw. @lonesomewalker there is no such thing as a GDPR-compliant open source software. GDPR-compliance means, that processing of personal information happens according to a legally sound privacy policy.

BBB / Greenlight are good a documenting the data, that it processes. But it:

• Cannot judge whether you are allowed to process data that way (e.g. are you required to process webcam data et all)
• Include a privacy policy subjective to your situation. E.g. there're a significant differences between privacy policies of training videos producers, elementary schools and churces. The legal basis is completly different.

Thus: It is up to you: either processing data using greenlight / bb is a strict necessity for you and can be justified, hence. If no such strict necessity exists for you (i.e. you're not forced to use bbb / greenlight due to whatever reason), it's illegal to use greenlight / bbb, because it is illegal to process personal data with no strict necessity.

In essence, no program can be GDPR-compliant - you using a programm can be GDPR-compliant or not.

[lonesomewalker]

@yanosz maybe you should read my comment again.
I wrote GDPR-friendly. ;-)

And speaking of Greenlight and documentation (for the consent):
not that hard to achieve.
Just add a row with:
userid,did he consent, when
and you are safe to go, because you can also add this to the user profile in the backend.

For admins and also users, so the user can decide to "untick" his consent, therefore he isn't able to use Greenlight anymore and after a period which can be defined, his account will be deleted automatically by a cron job.

On the other hand, this might get out of hands when you should provide the collected user data to this profile... :-)
Technically it would be better to store the user information in ONE place instead of scattering it over several external systems. But to be honest: this might bloat Greenlight a bit too much :-/

[ichdasich]

I'd argue that delegating consent and PP items to an external software is not really the way to go. Quiet a UNIX philosophy in there, but these are basics that have to be handled. Furthermore, we have to keep the UX flow in mind; All the redirects will confuse users.

Furthermore, i'd disagree that software "can not be GDPR compliant", as there certainly is inherrently non-GDPR complian software, for example a software that is hard-coded to covertly retain submitted data for an indefinit time without telling users. :-) Nothing an Operator could do apart from patching the software to fix this.

[yanosz]

I'd argue that delegating consent and PP items to an external software is not really the way to go. Quiet a UNIX philosophy in there, but these are basics that have to be handled. Furthermore, we have to keep the UX flow in mind; All the redirects will confuse users.

I don't see, that an redirect has an intorable impact on the UX. Considere The landing page is the external system. It can explain, that providing consent will redirect the user to the "video conference system" or whatever it is called. In that case, the redirect is expected by the users.

In case of in-band consent, these question should be addressed:

• How is consent going to be document in a legally sound way? In general, that includes tamper proof logging.
• What kind of reporting capabilities are needed? (E.g. informing users when consent was given up on entering)
• How to hook custom privacy policies of arbitrary length, while still being consistent with the UI?

Furthermore, i'd disagree that software "can not be GDPR compliant", as there certainly is inherrently non-GDPR complian software, for example a software that is hard-coded to covertly retain submitted data for an indefinit time without telling users. :-) Nothing an Operator could do apart from patching the software to fix this.

The non-existence of GDPR-compliant software does not imply the non-existence of software for which hardly anybody can think of any GDPR-compliant operation. Still, by logic that does not exclude the existence of GDPR-compliant operation in any case - only in those, we can think of ;-):

The actual idea behind this reasoning is that the functionality must certainly needs some clever hooks for customization for a specific legal context and privacy policy. There is no one-size-fits-all implementation, here.

[lonesomewalker]

The actual idea behind this reasoning is that the functionality must certainly needs some clever hooks for customization for a specific legal context and privacy policy. There is no one-size-fits-all implementation, here.

Sorry, but you are wrong.
Privacy by design, privacy by default.
One size fits all :-)

[ichdasich]

Jep. In line with @lonesomewalker ... Kind of professional opinion because I do some research in that field: Nobody changes defaults, and just hopes for the best. If we want to make the world a better place, software we write has to keep privacy-by-default and design in place.

[yanosz]

The actual idea behind this reasoning is that the functionality must certainly needs some clever hooks for customization for a specific legal context and privacy policy. There is no one-size-fits-all implementation, here.

Sorry, but you are wrong.
Privacy by design, privacy by default.
One size fits all :-)

well... orgs and people tend to write their own privacy policy. Guess why. There is no uber-policy, that fits all. In effect, customization needs to be possible.

[lonesomewalker]

well... orgs and people tend to write their own privacy policy. Guess why. There is no uber-policy, that fits all. In effect, customization needs to be possible.

That is true, orgs and people do that. So i agree there needs to be possibility to customization.
BUT: by default we can do our best :-)

[yanosz]

hmm... I'm afread we're loosing focus and this disucssion is slightly OT. IMHO the point of this ticket is to derive a common ground, which can be implemented after receiving feedback from the maintainers.

I started posting some questions to sketch the idea. I guess, that we're still in brainstorming .. so, I'd could help to phrase additional questions seeking for answers or to derive user stories.

[ReimarBauer]

How to document consent, having a legally sound audit trail?

Let us look on the scope who is responsible for this. In my opinion it is the one who is listed as responsible in the GDPR document. It may be best to ask a data protection officer about best practices. Based on this we can discuss the process/workflow.

How to have a consistent onboarding experience?

I think we can learn from the various conferences in the past. People sign somthing and parties accept rules by this. The consistent onboarding has to be only to sign.
We have only to provide an option to sign and may be have a process which satisfied the needs of the data protection officer .

How to explain customizing w.r.t to custom privacy policy?

Is consent supposed to be provided inband (i.e. by greenlight) or out-of band, i.e. by having an external landing page.

There is from the software site scope not much difference. The out-of band landing page will also need a GDPR page and the reponsible there has may be an existing process to handle this or likes to use the one suggested.

[farhatahmad]

Fixed in 2.7