Leon Bollerup

You've no doubt heard about GDPR by now. It's a very hot topic in many circles. Lots of experts are weighing in on the best approach to take before the May 25th deadline.
Which reminds me of my favorite joke:
"Do you know a great GDPR expert?”
Yes, I do!
“Could you send me his email address”
No, I'm afraid not.
I wrote about how Invision Community can help with your GDPR compliance back in December. I've seen a lot of posts and topics on GDPR in our community since then.
First, let's get the disclaimer out of the way. I'm a humble programmer and not a GDPR expert or a lawyer. The information here is presented to assist you in making decisions. As always, we recommend you do your own research and if you're in any doubt, book an appointment with a lawyer.
It is also worth mentioning that GDPR is very much a living document with phrases like "legitimate interest" and "reasonable measures". None of these phrases have any real legal definition and are open to interpretation. Some have interpreted them severely, and others more liberally.
GDRP is about being a good steward of the data you store on a user. It's not designed to stop you from operating an engaging web site. There's no need to create stress about users linking to other sites, embedding images, anonymizing IP addresses, and such on your site. These don't impact any data you are storing and are part of the normal operation of how the web works. Be responsible and respectful of your users' data but keep enjoying your community.
Let's have a quick recap on the points we raised in our original blog entry.
Individual Rights
The right to be informed
Invision Community has a built in privacy policy system that is presented to a new user, and existing users when it has been updated.

 
What should your privacy policy contain? I personally like the look of SEQ Legal's framework which is available for free.
This policy covers the important points such as which cookies are collected, how personal information is used and so on.
There may be other services out there offering similar templates.
Right to erasure
I personally feel that everyone should listen to "A Little Respect" as it's not only a cracking tune, but also carries a wonderful message.
The GDPR document however relates to the individuals right to be forgotten.
Invision Community allows you to delete members. When deleting members, you can elect to remove their content too. There is an option to keep it as Guest content, thus removing the author as identifiable.
It's worth using the 'keep' option after researching the user's posts to make sure they haven't posted personal information such as where they live, etc.
Emailing and Consent
Invision Community has the correct opt-in for bulk emails on registration that is not pre-checked. If the user checks this option, this is recorded with the member's history. Likewise, if they retract this permission, that action is also recorded.

 
When you edit the terms and conditions or privacy policy, all users are required to read it again and opt-in again.
Cookies
A lot of GDPR anxiety seems to revolve around these tiny little text files your browser stores. If you read the GDPR document (and who doesn't love a little light reading) then you'll see that very little has actually changed with cookies. It extends current data protection guidance a little to ensure that you are transparent about which cookies you store.
Invision Community has tools to create a floating cookie opt-in bar, and also a page showing which cookies are stored and why.
This is the page that you'd edit to add any cookies your installation sets (if you have enabled Facebook's Pixel, or Google Analytics for example).
Your GDPR Questions
Now let's look at some questions that have been asked on our community and I'll do my best to provide some guidance that should help you make decisions on how to configure your Invision Community to suit your needs.

Alan!!
Is the soft opt-in cookie policy enough? What about the IP address stored in the session cookie?
Great question. There's conflicting advise out there about this. The GDPR document states:
The ICO states that session cookies stored for that session only (so they are deleted when the tab / window is closed) are OK as long as they are not used to profile users.
This is re-enforced by EUROPA:

My feeling is that GDPR isn't really out to stop you creating a functioning website, they are more interested in how you store and use this information.
Thus, I feel that storing a session cookie with an IP address is OK. The user is told what is being stored and instructions are given if they want to delete them.
Given the internet is very much driven by IP addresses, I fail to see how you can not collect an IP address in some form or another. They are collected in access logs deep in the server OS.
Finally, there is a strong legitimate interest in creating a session cookie. It's part and parcel of the website's function and the cookie is not used in any 'bad' way. It just allows guests and members to retain preferences and update "last seen" times to help deliver content.
Do I need to delete all the posts by a member if they ask me to?
We have many large clients in the EU with really impressive and expensive legal teams and they are all unanimous in telling us that there is no requirement to delete content when deleting a user's personal information. The analogy often given is with email: once someone sends you an email you are not obligated to delete that. The same is true with content posted by a user: once they post that content it's no longer "owned" by them and is now out in public.

Ultimately, the decision is yours but do not feel that you have to delete their content. This is not a GDPR requirement.
What about members who haven't validated? They're technically not members but we're still holding their data!
No problem. The system does delete un-validated users and incomplete users automatically for you. You can even set the time delay for deletion in the ACP.

 
What about RECAPTCHA? I use this, and it technically collects some data!
Just add that you use this service to your privacy policy, like so:
I see many companies emailing out asking for members to opt back in for bulk mail, do I need to do this?
Short answer: No.
Since Invision Community 4.0, you can only ever bulk email users that have opted in for bulk emails. There's no way around it, so there's nothing to ask them to opt-in for. They've already done it.
There is a tiny wrinkle in that pre 4.2.7, the opt-in was pre-checked as was the norm for most websites. Moving forward, GDPR asks for explicit consent, so this checkbox cannot be pre-ticked (and isn't in Invision Community 4.2.7 and later). However, the ICO is clear that if the email list has a legitimate interest, and was obtained with soft opt-in, then you don't need to ask again for permission.
What about notifications? They send emails!
Yes they do, but that's OK.
A notification is only ever sent after a user chooses to follow an item. This falls under legitimate interest.
There is also a clear way to stop receiving emails. The user can opt-in and opt-out of email as a notification device at their leisure.

 
Do I need to stop blocking embeds and external images?
No. The internet is based on cross-linking of things and sharing information. At a very fundamental level, it's going to be incredibly hard to prevent it from happening. Removing these engaging and enriching tools are only going to make your community suffer.

There's no harm in adding a few lines in your privacy policy explaining that the site may feature videos from Vimeo and Youtube as part of user contributions but you do not need to be worried. As stated earlier, GDPR isn't about sucking the fun out of the internet, it's about being responsible and transparent.
Phew.
Hopefully you've got a better understanding about how Invision Community can assist your GDPR compliance efforts.
The best bit of advice is to not panic. If you have any questions, we'd love to hear them. Drop us a line below.

This entry is about our IPS Community Suite 4.2 release.
We are happy to introduce the next major feature that will be available in IPS Community Suite 4.2 - Clubs.
Clubs are a brand new way of supporting sub-communities within your site. Many people have requested social group functionality in the past and Clubs are our implementation of this concept. Let's take a look at a few screenshots, and then go over what they are capable of doing.

The Club directory

A Club homepage

Club member listing

Example of content within a club (topics, in this case)
There's a lot to digest there! Let's go over the basic functionality.
 
Club Types
Four types of club are available:
Public clubs
Clubs that anyone can see and participate in without joining. Open club
Clubs that anyone can see and join. Closed club
Clubs that anyone can see in the directory, but joining must be approved by a Club Leader or Club Moderator. Non-club-members who view the club will only see the member list - not the recent activity or content areas. Private club
Clubs that do not show in public, and users must be invited by a Club Leader or Club Moderator As the site admin, you can of course configure which club types can be created and by whom. You could, for example, allow members to create public and open clubs, but allow a "VIP" group to also create Closed and Private clubs.

Admin configuration option for Club creations
 
Club Users
Each club has three levels of user:
Leader
A leader has all of the permissions of a moderator, and can add other moderators. They can also add content areas (see below). The club owner is automatically a leader. Moderators
Moderators, as the name implies, have the ability to moderate content posted within the club. As the site administrator, you can define which moderator tools can be used. You could, for example, prevent any content being deleted from clubs, but allow it to be hidden. Moderators can also remove members from a club. Users
Anyone else that joins the club.
Defining the moderator permissions available to club moderators
Your site administrator and moderators, with the appropriate permissions, are able to moderator content in any Club regardless of whether they are a member of it. 
Clubs can be created by any user who has permission. As you would expect, this is controlled by our regular permission settings.
For closed clubs, there's an approval process. Users can request to join and the request must be approved by a leader. Leaders get a notification when a user requests to join; the user gets a notification when their request is approved or denied.

Approving and declining join requests
 
Club Content
Club Leaders can add a variety of content areas to their club - forums, calendars, blogs and so on. It's important to note that these content areas are fully functional just as if they existed as a top-level admin created area. They will appear in search results, activity streams, users can follow them, embed links to them, and so on. If a user has permission to see a forum (for example) within a club it will behave exactly like other forums they see - and the same for all other kinds of content.
Each content area a leader adds can have a custom title, and will appear in the club navigation. This means, for example, that you can have multiple forums within a club, and give each a different name.

Adding content areas to a club
 
Club Custom Fields
Clubs also support custom fields. Custom fields are defined by the site administrator and can be filled in by Club Owners. The values they enter are shown (along with the club description) on the club homepage.

Custom fields in a club
On the Club Directory page, users can filter by the custom club fields.

Filtering clubs
 
Club Locations
Clubs have built-in support for Google Maps, allowing users to specify a physical location for their club. Let's say you run a community for car enthusiasts; each club might be tied to a particular region's meetup. The Club Owner specifies the location when setting up the club, and clubs are then shown on map on the directory page:

Club locations
And within a club, the location is shown too:

 
Club Display
We offer two ways to display club headers within the club - the standard way, shown in the screenshots you've seen up to this point, but we also have a sidebar option. This is something the admin sets globally for the site, rather than per-club. This is useful where your site design doesn't facilitate another horizontal banner taking up valuable screen real-estate; moving the club banner to the sidebar alleviates this pressure on vertical space.

Sidebar club style
Using Clubs in Other Ways
There's a lot of scope for using clubs beyond allowing users to create their own groups. You do not even have to call them "clubs" if that does not suit your use case. For example, on a company intranet you could rename Clubs to "Departments", and create a private group for each of your main roles. This would allow each department to have its own community, with its own forums, gallery, file sharing and so on, private and separate from other departments.
Similarly, they'd also work well in situations where you as the site admin want to create entire micro-communities. Take for example a video game publisher. Using Clubs, they could create a micro-community for each of their games, complete with forums, galleries and so forth, and then set the Clubs directory as their overall community homepage. Immediately, they have a setup that hasn't until now been possible out-of-the-box with IPS Community Suite.
 
We expect our clients will come up with some really innovative uses for the new Club functionality, and we can't wait to see what you do. We'd love to hear your feedback - let us know what you think in the comments.