In the forums, we've been talking about adding a plugin that checks new user registrations against the database at https://www.stopforumspam.com/ - in discussing this with Georg, he raised potential concerns about data privacy, and after some discussion, we all agreed that input from someone with both a legal background and authority to speak for the project (and/or SUSE) was necessary before we proceeded.
The plugin uses the SFS API, which according to SFS:
"If during the operation of API access, you wish that no data is logged, then you must change your request from a GET method to a POST method, as described at https://www.stopforumspam.com/usage"
(https://www.stopforumspam.com/gdpr)
The plugin uses POST to perform its checks, so no log entries are created. The plugin checks the user's email address, username, and IP address. SFS also provides a mechanism for people who have been incorrectly identified as spammers to have this corrected.
Forums staff have used the website for years when we suspect an account is a frequent spammer; automation will make this more reliable and create a better experience for our legitimate users.
Malcolm has suggested that this would be better done at the IdP; I agree with this (and I believe Gertjan did as well, but I won't speak for him since he's on the board), so if something like this could be implemented at the IdP instead, that would be preferable, but one way or the other, we'd like to have this functionality in place to simplify management of the forums.
Please let us know how to proceed; if this is a question that's best answered by SUSE directly, I'm happy to discuss with Gerald or anyone at SUSE directly.
Metadata Update from @Pharaoh_Atem: - Issue tagged with: policies
I think this is fine, provided the following is true:
Proposal: The Board indicates no issue with deployment of the plugin as long as the user is aware of it as part of the forum signup and knows they can avoid by not creating an account.
Given the above is my summary, I'm thumbs up :thumbsup: :-)
I'm good with it, as I wrote it in here, so... :thumbsup:
I don't know that the plugin provides us with the option to get consent ahead of it running - it runs as a background process, and the signup process is driven by the IdP - we use OIDC for the authentication process, and if the user doesn't exist, it's provisioned automatically as part of the process.
Pretty sure no data is logged (I can verify that), but changing the authentication flow is likely going to prevent us from being able to use this.
From a privacy standpoint, I understand the need for consent; from the purpose of preventing spammers from registering with the platform, though, announcing to the world that this is what we use gives them the ability to circumvent the measure, making it less effective.
I'll talk it over with the other admins, but these conditions may mean that we just stick with doing it manually on accounts that we find suspicious.
Consent does not require us not running it before getting an action from a user. It requires informing them that they will need to disengage if they disagree with having a spam check service in place validating their account.
I see. So basically, what we would need to do is provide a notice (possibly in our T&Cs?) that says that we use an external service for identifying spammers - and that neither we nor the service logs any PII regarding the check. If they do not wish to be subjected to that check, they should simply not use the forums.
If that's the case, that's much more doable.
Jim, fellow board members, to me it looks like we have clarified and addressed this issue/request?
Are you going to take it from there? (Or is there anything open?)
Thanks, Gerald - I think the only remaining question in my mind is how vague we can get away with being in that notification. If we can just put it in the forums FAQ and say "we use an external service to help identify spam accounts", that's perfect. If we have to describe what the service is and what data is sent, then that tells the spammers how to circumvent the measure, which reduces the utility of the service itself.
I also understand that there's some discussion about changing the IdP (at least, that's what I heard; if that's not the case, clarity there would be good) - if that is the case, though, perhaps something we should do is take Malcolm's suggestion to evaluate using the IdP to block registrations from known spammers at the IdP so it's done consistently across the entire infrastructure.
Metadata Update from @ddemaio: - Issue assigned to ddemaio
Login to comment on this ticket.