Add GDPR Checkbox

[mhellmeier]

Checklist

• I am running the latest version. Installing Isso from GitHub from the master branch does not fix my issue
• I have checked the troubleshooting guide
• I have searched the open issues, but my issue has not already been reported

What is not working?

When using the plugin in the EU, it has to follow the laws. In order to be GDPR compliant, a user has to actively agree that personal data (the comment, name, mail address, ...) is stored by the website operator.

To realize the requirements it would be great to implement a required checkbox with content similar to this:

By sending this form I agree on the storage and processing of my personal data by this website

Would be great to see a config option like gdpr-checkbox that can be set to true/false and enables / disables the required checkbox.

How can one reproduce this issue?

[ix5]

Hello Malte, while I agree that preserving user privacy and getting their consent is really important, we shouldn't be contributing to the Web of Checkboxes™ and popups that currently exists out there. Instead, we should get consent only when really required and when it makes sense, in context.

Isso currently doesn't require users to enter any data about themselves, unless the site admin has enabled any of the require-email or require-author options. The only information that is stored is the IP address, which is already anonymized (see anonymize(remote_addr)).

If we decide to implement a type of GDPR checkbox, it shouldn't be an option but be valid for all users (everyone could get traffic from EU, unless someone has enabled geo-blocking on their site, which I doubt is a scenario we care about). It should be triggered by entering an author name or email and dynamically pop up. The "Submit" field should be HTML5-disabled until the checkbox is ticked.

Also, we could use an overhaul of the information presented to users, i.e. what will happen with the data they enter.

• The website and author name are saved in the DB and presented to users.
• The email is saved to DB, used for spam checking/moderation and only visible to admin, yet stays in the DB. Maybe we should only store a hashed version of the email in the DB and use that for comparison for features like approve-if-email-previously-approved and for identicons - we already compute a hash anyway, let's use that instead.

Another important aspect: We really need a sample privacy policy for users to copy to their site (and customize based on which options they have enabled). Would you be able to do that, @mhellmeier?

Some other thoughts and links, not necessarily 100% related:

• Since GDPR is only EU-wide, this may also benefit from geolocation detection? I.e. only show to EU users? But then again, e.g. California has similar legislation AFAIK
• Commento Legal page
• Commento on why anyone should care about privacy
• Remark42 privacy technical explanation
• Mobile forms UX part 1, Mobile forms UX part 2
• The Tips & Tricks docs page has a section on scrubbing IP addresses - maybe scrambling emails makes sense too, if we don't care about avatar stability?

This is what I use for informing users what happens to their email:

[mhellmeier]

Thanks a lot for your detailed answer!

Instead, we should get consent only when really required and when it makes sense, in context.

If I understand it correctly, every comment system needs such a checkbox to be GDPR compliant. Even if the data isn't used for other purposes and doesn't make public (like your mail example) you have to explicitly ask for consent. Just read the first 3 sentences of this blog post:
https://www.greengeeks.com/tutorials/add-a-checkbox-in-wordpress-comments-for-gdpr-compliance/

If we decide to implement a type of GDPR checkbox, it shouldn't be an option but be valid for all users (everyone could get traffic from EU, unless someone has enabled geo-blocking on their site, which I doubt is a scenario we care about). It should be triggered by entering an author name or email and dynamically pop up. The "Submit" field should be HTML5-disabled until the checkbox is ticked.

Yes, this sounds like a perfect solution for me!

Another important aspect: We really need a sample privacy policy for users to copy to their site (and customize based on which options they have enabled). Would you be able to do that, @mhellmeier?

I am sorry, but I haven't any background in law / legal. Perhaps we can find a person in the community who can assist here?!

[BBaoVanC]

Since GDPR is only EU-wide, this may also benefit from geolocation detection?

I feel that geolocation shouldn't be relied on. Plus some people could consider it worse for privacy. It also sounds like GDPR applies to EU users that are using a VPN to a non-EU country. It's probably better to be safe and show the checkbox all the time.

Maybe we should only store a hashed version of the email in the DB

But if we can't read the email address server-side, then we can't send email notifications. To me that's the primary use of storing email address.

We really need a sample privacy policy for users to copy to their site

Maybe we could also have a built-in privacy policy endpoint (/privacy-policy?) which could be linked above the main postbox. This would be better than making every website owner make their own privacy policy based on a template (many people won't bother to do that).

If I understand it correctly, this could just be a small checkbox just like the reply notifications one (except never hidden). It would probably need to always be shown because all 3 boxes (name, email address, website) are probably personally identifiable info. And even if it's a completely anonymous comment, there's still cookies (we need to mention these too probably) saved so the user can edit the comment for a short time.

[ix5]

I feel that geolocation shouldn't be relied on. Plus some people could consider it worse for privacy. It also sounds like GDPR applies to EU users that are using a VPN to a non-EU country. It's probably better to be safe and show the checkbox all the time.

You are correct there.

Maybe we should only store a hashed version of the email in the DB

But if we can't read the email address server-side, then we can't send email notifications. To me that's the primary use of storing email address.

The course of action should be: Save plain email address to DB if subscribed to at least one thread. If unsubscribed from all threads, hash email and only continue storing that. If not subscribed to anything, immediately hash email and only save that to DB.
Since even email hashes could be considered PII (you can query the DB if they are present or not), anytime we collect emails we need to collect consent.

We really need a sample privacy policy for users to copy to their site

Maybe we could also have a built-in privacy policy endpoint (/privacy-policy?) which could be linked above the main postbox. This would be better than making every website owner make their own privacy policy based on a template (many people won't bother to do that).

Providing a sample privacy policy at an endpoint is something I can get behind. As with providing an example syntax page, the issue is translations. We can only realistically provide an English page. Maybe have a config for three scenarios:
a) Config left untouched: Site admin uses Isso-provided privacy policy
b) Config set to custom URL: Site admin has own privacy policy
c) Config set to null: Site admin has surrounded comment box with their own notes and privacy links or has already collected consent for processing comments from a cookie banner elsewhere. This would hide the "privacy" link

If I understand it correctly, this could just be a small checkbox just like the reply notifications one (except never hidden). It would probably need to always be shown because all 3 boxes (name, email address, website) are probably personally identifiable info. And even if it's a completely anonymous comment, there's still cookies (we need to mention these too probably) saved so the user can edit the comment for a short time.

Those cookies are purely functional. We should probably only send credentials from cookies if really needed (for edit/delete), see api.js: xhr.withCredentials = true;. We are not serving different API responses for fetch calls to the user based on cookies. Thus, IMO they're not PII since cookie-dependent handling happens on the client side. We're neither tracking nor profiling based on these cookies.

[mhellmeier]

Providing a sample privacy policy at an endpoint is something I can get behind. As with providing an example syntax page, the issue is translations. We can only realistically provide an English page. Maybe have a config for three scenarios:
a) Config left untouched: Site admin uses Isso-provided privacy policy
b) Config set to custom URL: Site admin has own privacy policy
c) Config set to null: Site admin has surrounded comment box with their own notes and privacy links or has already collected consent for processing comments from a cookie banner elsewhere. This would hide the "privacy" link

If I understand it correctly, the user has to explicitly check a checkbox to agree actively and give their consent. Maybe just linking a privacy policy page isn't enough.
The legal requirements are extremely complex just by delivering the software to different countries. I don't think that isso have to provide a sample privacy policy page in different languages.

What about the following suggestion for config options:
a) Nothing happens (current implementation) --> Same as suggestion c) from @ix5

[gdpr]
type = null
content = null

b) A custom checkbox with a custom text that have to be checked to submit the comment.

[gdpr]
type = checkbox
content = By sending this form I agree on the storage and processing of my personal data by this website

c) A privacy policy is linked with a default text like "By sending this form you agree to our privacy policy." --> Same as suggestion b) from @ix5

[gdpr]
type = privacy-policy
content = https://isso-test-system.com/privacy-policy

[ix5]

(Related: #445)

[ix5]

@mhellmeier you have correctly identified the need for separating the consent checkbox and a link to the privacy policy.

The server config is not the right place for this (no i18n access), so the must go into the client config as data-isso-* attributes.
So you'd have a translatable string for the checkbox text ("By sending this form I agree...") and a link with a link text to the privacy policy. I'm not sure the i18n templating system accepts HTML/inline links (for the link to privacy policy), so you'll have to figure that out or extend/modify it.

The checkbox should be configurable to be disabled for people like you who immediately ask people for consent in another place - here when navigating to the website and obscuring the content (bad practice IMO, but if that's what you want, Isso shouldn't stand in your way).

Features in Isso can't happen without someone implementing them - @mhellmeier, would you like to work on this?

[mhellmeier]

Currently, I am pretty busy so every contribution is highly appreciated!

[jelmer]

I think the privacy policy is separate from this and should be site-wide? Most websites gather all sorts of different data, and isso is just one. Your web server probably also stores logs, as does your email server, and other parts of the website on might track or accept different bits of data.

How different bits of data are tracked and who has access to it will also be very specific to the site in question.

[jelmer]

a) Config left untouched: Site admin uses Isso-provided privacy policy

Providing a default policy seems wrong to me, and I feel uncomfortable with. The fact is that we don't know how the site administrator is going to use the data provided by the user. They might use the email addresses in the database to send spam. A default privacy policy is not something they promise to uphold when they install isso.

It's up to the site admin to provide a privacy policy. The most isso can do is provide some guidance on what data it stores in its database to help site admins write a privacy policy.

[kuba-orlik]

It would be nice to give the administrator a way to configure the text next to a checkbox and to not have a default value for that.

There are many situations (including GDPR and the Omnibus directive compliance), where making sure users need to check a checkbox in order to submit the comment is necessary.

We're currently using ugly hacks to add this functionality to the isso comment section, and it would be so much prettier if this was a built-in functionality

[jelmer]

Yeah, I like the idea of just making it possible for the admin to require users agree to some things before being able to submit a comment without being prescriptive.