How to make users to explicitly agree to ToS

You’re correct, thanks. I’m not sure what’s the perfect wording to not annoy users when they register. But still to make them aware that actually clicking the URLs and reading them is important.

Actually, it would need 2 fields - one for accepting the ToS, and the second to have read and understood the FAQ/guidelines. I’ve heavily modified the FAQ as the platform is more like QA and users tend to not know what to collect when asking a question. Similar thing with GitHub and issue templates, e.g. provide the OS, configs, logs and where to look for “troubleshoot on your own”.

I’ve asked our community what they do think, might need til next week for feedback. Weekend is where not many look into monitoring questions in their spare time and there’s expected low traffic.

If you scroll down on, you’ll recognise the footer. I’ve added this as German law requires your to have an URL to your legal notice (“impressum” in German) on every single page. This lists personal details such as name and address where the owner can be contacted. I haven’t had that in Austria, but Germany is more special on that.

It is far from perfect and not very “fancy”, but it works for me to be on the safe legal side. Germany is known for legal notice trolls because of that law requirement.

1 Like

I did that too - have links in the footer - using the Flex Footer Theme Component.

I am not required to show a url so just linked words instead.

I don’t include ‘about us’ because we aren’t required to in the US, but once we launch that could change depending on what people find useful.


This definitely will not hold up in court in Europe, and our legal guy says he thinks it’s not accepted in the USA either - after he stopped laughing.

You have to actively inform your users of such a change.


Usually when fees go up I have been required to click to accept fee increases like with Netflix for example. I got email notices before that. Click to accept changes in tos at sign in would be smart. Along with notices to members prior to that.

1 Like

I’m thinking another case with SSO. User A logged in Discourse, some day user A revokes consent from, say passport (if we have a passport site, i.e., how would we handle it?

I can think of a way to handle this, to add a javascript to check with passport site whether current user consented, if not, then ask user to consent, either redirect to passport site or show a modal in Discourse.


Discourse currently has ability to “Deactivate account” via Admin panel. I am wondering if we could use it to implement “Voluntary consent” required by GDPR for existing users.
Something like mass deactivation with custom activation email text explaining why existing users need to give consent by clicking link in activation email.
And to be legal this has to be done before May 25.

No, “activation” is only “prove you own this email” and unactivated accounts (with no posts, because of admins doing this kind of thing) are deleted after 7 days.

1 Like

Yes I know that, but I was just thinking about easy method to do what original poster asked about, i.e. make existing users to give explicit voluntary consent to process their data via clear affirmative action. Under GDPR you need to collect such consent from existing users and be able to demonstrate they gave it actively and when they gave it. I just thought that existing functionality could be used to collect that.

While it is easy to ask new users for consent at the sign up time by adding user field in the admin panel and making it required, Discourse has no functionality to collect required GDPR consent from existing users (except maybe asking everyone individually). As May 25 deadline approaches every working method (even if not perfect) would be good.

1 Like

This plugin may be helpful:

It’d be useful to know if anyone has used it for GDPR purposes, and if they could share their wording and config?


One important thing that is missing in requesting GDPR consent as “user field” is that changing user fields does not generate any entry in Users “Action logs”. Under GDPR it is important to be able to demonstrate when consent was given. For this Discourse should log such event in the user’s “Action log”.

It would be highly appreciated if Discourse team could tell us if Action logs can be improved to include user field change event.


You could use my Custom Wizard plugin to obtain consent under the GDPR, and I would be happy to work through any issues for that use case, however unless you’re using Discourse data for something other than just running a Discourse forum, it seems (at this preliminary stage) the more suitable basis for processing and control of data in Discourse is ‘Legitimate Interests’ rather than consent.

If you’re looking for some plain language explanations from a trusted source on this question, I would recommend the UK’s Information Commissioner’s Office.


In particular the ICO notes that consent needs to be granular, possible to withdraw and cannot be a precondition of service, each of which raises issues for the way you’re proposing to obtain consent in Discourse.

Moreover, they state:

But you often won’t need consent. If consent is difficult, look for a different lawful basis.

Legitimate Interests

They note: (highlights are mine)

  • Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate.

  • It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.

It seems to me that it would be reasonable to expect that when signing up for a discussion forum that the details you provide would be stored and processed for the purposes of running the forum.

See further:

Please note that none of this is legal advice and cannot be relied on as such. I am not your lawyer.


Is there a way to force existing users (not just new users) to check the box before logging in? I’m about to import many users into Discourse, and they won’t have checked that box, so I don’t think it will work, except maybe for new Discourse sites.

Drupal 7 has a module called Legal that saves the versions of the terms that users have agreed to. I think you can’t log-in without checking the boxes. It might be worth looking at for ideas.

@angus great work in the plugin, looks very useful. You had pointed out that the this can be helpful with GDPR compliance.

@neil and @sam pointed out that one can use the mandatory checkbox at sign-up to get users to agree with the terms.

Can you help us understand how your plugin can help with GDPR beyond the above? Can we it help cover other gaps we may be missing.

I know you’re looking for a clear, simple and short answer, but unfortunately this is a long and, in parts, complex answer. This reflects the reality that no-one yet knows how consent under the GDPR will be applied in practice.

What I can do is explain what’s going on and what you need to know in order to make an informed choice. I have given some specific suggestions on what I think you should do (see bottom).

I’m expanding on what I’ve already mentioned in various places before (including in this topic), as I think some people are still feeling a bit lost.

Consent is only one basis of handling user data in the GDPR

It’s important to understand that consent is one of six lawful bases for processing personal data in the GDPR. These are set out in Article 6.1 of the GDPR. Another relevant lawful basis is what’s called “legitimate interests” (6.1(f)). It’s also not clear how ‘legitimate interests’ will be interpreted. The UK Information Commissioner’s Office has this to say about it:

  • Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate.
  • It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.

To this, I would add that various uses of personal data in Discourse for security, spam prevention and stability seem quite similar to the specific legitimate interests mentioned in Recital 47 (which discusses the concept more discursively than in Article 6).

While this seems to me to be a reasonable ground to rest on for most of the processing in Discourse. There is a real possibility that some authority or court could decide that the ‘Legitimate Interests’ ground has a limited scope and is intended for emergencies and / or things like crime prevention.

Here’s an example of someone who takes a restrictive view of legitimate interests.

Some folks have also raised Article 6.1( c) “performance of a contract” as a ground for processing. Personally, I don’t think this is a great ground to rely on as:

  • What counts as a contract, and what counts as terms of the contract (i.e. whether incorporating T&C’s by reference at the time of signup counts) depends on the jurisdiction you’re working in.

  • The data controller (i.e. the forum provider) is not under a “legal obligation” to provide anything to the user, and probably would not want their relationship characterised in that way in any event. There is no quid pro quo here.

cc @RGJ

If you decide to rely on consent, it’s a high bar

It’s also important to understand that if you decide to rely on user consent as the basis for processing personal data, that:

  1. Consent must be clear, positive and unambiguous: “clear affirmative act establishing a freely given, specific, informed and unambiguous indication” (R.32).

  2. Consent must be given for each individual purpose of processing the data: “Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them.” (R.33)

  3. There must be a way for the user to say no (at any time): " Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment." (R.42).

See generally Article 7 of the GDPR.

Furthermore, the UK’s Information Commissioner’s Office has advised, amongst other things:

  • Keep your consent requests separate from other terms and conditions.
  • Make it easy for people to withdraw consent and tell them how.
  • Avoid making consent to processing a precondition of a service.

There are already claims under the GDPR focused on consent

The NOYB’s recent complaints under the GDPR against Google and Facebook are one example of how consent can be interpreted as a high bar in the GDPR.

For example, the complaint against Google mainly concerns ‘consent’ to terms and conditions and a privacy policy for the Android operating system when setting up a new phone.

The complaint discusses the effect of the power imbalance between the provider (i.e. Google) and the user on the user’s consent. They also make claims specific to each of the elements of consent mentioned above.

Relevant to your question, they claim:

On page 11 of its Guidelines on consent under Regulation 2016/679 (WP259) the Article 29 Working Part [sic] gives the example of “downgrading” a service when consent is not given, as a situation where there is a detriment to the data subject.

In the present case, the controller simply does not offer any service without data subject’s first agreeing to the terms and to the privacy policy. Being denied the use of any of these services could be seen as something worse than the simple downgrading of a service.

I will be watching the progress of these complaints to see how the Authorities they have been filed with respond.

So what should I do?

Personally, I think the best strategy for the legal basis of processing under the GDPR at the moment is to:

  1. Rely on legitimate interests for the processing personal data relevant to running the forum, security of the forum and ancillary matters such as spam.

    • This would cover the collection of ip-addresses for the legitimate purpose of security etc.
    • The various ways user identifiers are used in Discourse internals to make the site work are constantly changing and hard to specify in a sufficiently specific way to be ‘consented’ to.
  2. Rely on consent for the processing of email addresses for sending the digest email and / or other user notifications.

    • The user can not give consent and continue to use the service.
    • Consent can be clearly given and withdrawn at any time.
    • A user’s email is perhaps the most sensitive piece of personal data collected, and sending emails is perhaps the most ‘intrusive’ part of Discourse.

This is just a personal, non-legal, opinion that could well change based on:

  • The outcome of matters like NOYB’s filing
  • Updated advice from authorities.

So what specifically should I do?

You should update your privacy policy to reflect the strategy you’re taking in clear, readable terms and make sure users, new and old, know about it. To notify your users you could use:

  • an email.
  • a forum notice.
  • the Custom Wizard plugin.
  • the new Discourse Policy plugin.

But, if you follow what I’ve explained above, you’ll understand that personally I don’t think it’s strictly necessary to get your users to ‘consent’ to your privacy policy at this time. With respect to the GDPR such ‘consent’ may not mean much.

Regarding consent to the use of email addresses, specifically the digest, there’s a topic on that here which covers most of the relevant aspects. On whether anything needs to be done to ensure new and existing users have given explicit consent to digest emails, I am working on a feature for the Legal Tools plugin that may help in that respect. In the meantime, you have two options:

  • Rely on the existing controls to satisfy the demands of consent, as laid out here: GDPR and the Digest email. These are probably sufficient.

  • Turn off digests.


TL;DR I don’t agree with Angus where he argues that legitimate interest can be rested on for most of the processing in Discourse while I am convinced that most of the processing should rely on ‘performance of a contract’ and only some additional processing like collection of IP addresses and keeping statistics for spam prevention belongs to the legitimate interest category.

While I totally agree that people are focusing way to much on consent as a lawful basis for processing, I do not agree with you that legitimate interest is to be preferred (above performance of a contract) as a lawful basis for processing the personal data relevant to running the forum.

Legitimate interest is clearly meant as all processing done “in the background” or “on top” of the performance of a contract (or on top of other lawful bases like legal obligations, vital interests) to protect the interests of the controller. The examples in pages 10-12 of this document give a very clear idea of what kind of processing this lawful basis is meant for.

The pizza delivery example in the document referenced by you is, in my opinion, a bad example. It is contradicted here where the second example mentions the same situation where the address of the customer is being processed but this time as an example for ‘performance of a contract’.

Another objection against using legitimate interest as the lawful basis for processing the basic personal data, is that when providing a forum to a user is not to be seen as a contract, there cannot be a reasonable expectation of the user for processing either. The forum owner cannot just start collecting user data and sign up people for a forum, there has to be some kind of agreement where the user indicates the wish to participate in the forum. Signing up for a forum can IMO be seen as a contract and when that is the case then performance of a contract can be used as a lawful basis, eliminating the need to look further.

Last but not least, don’t forget that a user can object to processing under legitimate interest (GDPR art 21.1) which complicates things a lot.


Here is what I’ve done on my site. Almost the same as @neil (his post) but with explicit links:


To make it perfect, I’d probably hide the default clause at the bottom:


Also, the term “site rules” seems dispensable. I have so far not managed to target it with CSS though. Does anyone have some hints?

Isn’t this the name you give when adding the custom user field?

Yes, it is. But you can’t leave the field name blank so if you don’t want it to be displayed, you need to hide it.

In fact, I have had it hidden for over a year on my site and recently it started showing up. (This was possibly related to the redsign of the sign-up modal). I don’t remember though, whether I manually hid the Field Name back then (which would mean that I did actually manage to target it) or whether it simply didn’t show up.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.