GDPR Thread
Per the convo in the Vanilla room, here is a thread for this discussion 
Hey @all CSM and Support folks, you may be getting some questions about EU General Data Protection Regulation Compliance (GDPR) from our European clients. We've added this page to our website: https://vanillaforums.com/en/legal/gdpr/and this page to the internal docs: https://internal.vanillaforums.com/support/gdpr/ Everyone should read both of these documents. Please let me know if you get any questions or requests regarding GDPR
I'm going to add some questions we've answered already below.
Comments
-
Q&A with Oculus:
1) will their server security model change, ie are they changing OS/volume encryption policies/changing/updating intrusion detections as part of this move?
No, except we will be adding comprehensive WAF and Anti-DDoS to the environment.
2) will the way Oculus customers connect to vannilla change, ie HTTP<->HTTPS downgrade or upgrades?
No.
3) will this change the way Oculus community support/ admins will connect into vanilla? Ie introduction of MFA, new auth model, new identity model etc?
No.
4) Will there be any cost difference from using the Canadian server versus staying in the US?
No.
5) Will there be any difference in the quality/speed/etc. of the service between the Canada and US servers?
The new Canadian one will be better! As technology improves we are occasionally given the opportunity to rearchitect our solutions to leverage that technology. Our upcoming Canadian datacenter is an order of magnitude more powerful, resulting in better app performance.
0 -
Redundancy Question from Tripwire:
You mentioned redundancy in your email. Would we have data sitting in multiple data centers in different countries, or would everything be located in the single data center in Canada?
The redundancy would be for Vanilla, your cluster would be hosted all in one place (preferably the new and better Canadian hosting).
We will be keeping the American site for customers that prefer to be hosted in the U.S for legal reasons, and only those customers would have their clusters located there.
0 -
Talking points from @Derrick :
Per Tim's announcement yesterday, we have plans to move to a Canadian datacentre. Everybody on a public, shared cluster will be moving over, but we want to give our VIP customers some choice in the matter, but we would much prefer it if they move over.
Tim prepared some talking points, I'll paste them below:
I've jotted down some talking points for the CSMs regarding the upcoming move to a CA datacenter.
1) As a growing company, we're constantly evaluating our processes and looking for ways to add value and improve our offering. One of those ways is to diversify our hosting footprint to provide redundancy. We've decided the open a Canadian datacenter to give our customers more choice about where they host their data.
2) Our analysis of the current data protection and privacy landscape we believe it is in our best interests, and those of our clients and their end users, to migrate as many of our customers to EU-compatible hosting as possible, while retaining close proximity to the US userbase. Canadian privacy laws are directly compatible with EU privacy regulations, making it difficult for US authorities to force us to compromise the privacy of our end users.
3) As technology improves we are occasionally given the opportunity to rearchitect our solutions to leverage that technology. Our upcoming Canadian datacenter is an order of magnitude more powerful, resulting in better app performance. We're also better protected here against denial of service attacks due to our decision to leverage best-of-breed third party mitigation services for our new environment.
Please start sending out emails to your VIP clients telling them about this new datacentre and seeing if they would like to be interested in moving over. While we'd like to give them the choice, we want to make the Canadian datacentre sound like the more attractive option (because it is).
I'm still gathering information on timeline and downtime, but I think we can still start to send out feelers about this. If you're customers have follow up questions about this, send them over to Tim and I.
plus,
I figure your customers may ask some of these questions:
What's the timeline of this move?
Within the next 2-4 months.
Will there be downtime associated with this move? If so, how long?
Yes. Could be up to 6 hours but we're aiming for closer to 30 minutes if everything goes according to plan.
Have we picked a provider? (will it still be rackspace)?
We are in the final stages of picking a provider. It will not be Rackspace. They don't have Canadian datacenters and are a US entity anyway, negating the privacy gains from moving to Canada. We are leaning towards Vexxhost.0 -
Will Vanilla offer any way of opting out of cookies or offer a means of users opting out of being tracked?
What is our relationship with cookies as they relate to GDPR and our platform.
The response I received: We use cookies for authentication. We don't use tracking cookies except for Who's Online, and even then its not personal data unless the user is logged in. Its not tracked cross site.
There is no way to opt out. It is a core part of our system.
I've read on some sites that cookies for authentication are exempt from GDPR. Not sure about that module/plugin.
1 -
What types of cookies does Vanilla employ and how does GDPR affect the use of those
Cookies?0 -
According to ArenaNet
In chatting with our GDPR counsel, it looks like any site with cookies will need to have a pop up indicating that cookies are collected. People just need to read it, maybe click a link out for more info, and click OK to acknowledge that they’ve seen it. What does Vanilla have that could accommodate that?
I've seen some of our clients do this themselves through customise theme. We do ArenaNet's theme but I imagine this could be possible through a pocket?
Is our recommendation to our clients if they want something like this to do it themselves via pockets? It might be a good idea to have a consistent/official stance on the subject of cookies.
0 -
That blog post is very good.
The part I want to highlight is that the answer to "can a user demand I delete all their content?" is not a simple 'yes' (and I'd argue it's more like "No, with a couple exceptions").
I think Moderation v2 is going to be very important to our future ability to deal with the workflows that are likely to come out of this, like a way to put requests for removal of personally identifiable information into a manageable queue (whether that be expunging IPs, selectively removing posts, or approving username changes).
The strong "It's Your Data" policy we implemented early on has proven extremely good for us in the long run, especially in this context, because it squarely makes the customer the data controller and simplifies the complexities we face now.
0 -
I am going to assume (and I think it safe to) that the blog post represents Vanilla's stance on a number of questions. Namely, my earlier question regarding cookies.
Per the blog post:
Q: Does the GDPR require users to consent to the use of Cookies? How do forums use cookies?
A: On some websites, you sometimes see a notification pop-up asking people to consent to the use of cookies. Those are there because of a different EU law about cookies. The law says that you must get consent if you are using cookies to collect and store ‘non-essential’ information such as info that is used for targeting advertising. By default, the cookies used by forum software are the ‘essential’ kind that are used to keep people logged in, track analytics and so on and you need not get consent for using those cookies. With respect to GDPR, you need to know that that information in cookies could be used to identify the person and should be treated as personal information.
Therefore, I am going to be telling Arenanet they can add a cookie warning banner via pockets if they like but we won't be doing it for them.
2 -
Yup, I'd cosign that interpretation of our cookies.
1 -
Question from Glu. They use Vanilla basic registration. Do we need to have a privacy policy as part of our registration? We have a terms of service there, which they could edit if they gave the text, but their legal counsel appears to be considered about a privacy policy that users agree to when they register.
0 -
I think it would be prudent to revise our default "terms of service" page and also include a separate privacy policy on that page. That said, I feel like Glu is asking for a free feature that isn't necessary, and they already have recourse to add to the page. If they demand a separate Privacy Policy page, they can do that with Profile Extender's checkbox on registration (with a link to their own policy page) - that's what it was made for.
1 -
Would marketing tracking software that clients often put in their forums via pockets require a GDPR cookie opt-in banner?
I have lulupress asking me the following:
Because we use Tealium and Google Analytics, it appears that we're gathering data about 'guest' users who would not have already passed through lulu.com and chosen their cookie preferences before accessing the forums. We're using our Tealium tools to manage this data and we would need some way to pass ip info that Vanilla sees about guest users to Tealium so we can properly default an EU users to turn off cookies.
Do you have any suggestions about how we might achieve this? Or is there a means already in place to prevent un-registered users from using cookies?
I am unclear on what they might be gathering from guests but I also haven't heard of any clients saying to not use any cookies on guest users but rather just leave the choice to opt-in our not if that makes them more comfortable.
0 -
If they have their tracking codes already on their community, Tealium probably provides a way to display a banner. This is how we do it, via Hubspot. It displays because of the tracking js we have placed on the website. @BrendanParm
Here's the info I could find.
https://tealium.com/solutions/privacy-data-protection/0 -
Hola,
The boyzz @ D3Go ( https://console.vanilladev.com/sites/view/overview/6029755/d3go.vanillacommunities.com ) are still pulling hairs trying to make sure they're GDPR compliant and doing what ESRB tells them to do.
Since we don't have an age gate, we've set them up with the Approval method of registration + swapped "Why do you want to join" with "please confirm your date of birth" so they can see that upon approval/denial of membership. However, because members don't receive a notification of declined registration, there's no real way to tell them about it - which also means there's no space for them to be transparent about whether or not those details are stored anywhere, which GDPR wants to be a bugger about.
Workaround I've been able to do on my demo site was to adjust the message they get when they first try to register to: "Your application will be reviewed by an administrator. You will be notified by email if your application is approved. Should your application be denied, please know that your information will be immediately deleted from the system."
But before I can offer that to them, I need to make sure I'm not lying and that the data actually is deleted immediately, or the details around that.
Por favor
0 -
@BrigitteP said:
Hola,The boyzz @ D3Go ( https://console.vanilladev.com/sites/view/overview/6029755/d3go.vanillacommunities.com ) are still pulling hairs trying to make sure they're GDPR compliant and doing what ESRB tells them to do.
Since we don't have an age gate, we've set them up with the Approval method of registration + swapped "Why do you want to join" with "please confirm your date of birth" so they can see that upon approval/denial of membership. However, because members don't receive a notification of declined registration, there's no real way to tell them about it - which also means there's no space for them to be transparent about whether or not those details are stored anywhere, which GDPR wants to be a bugger about.
Workaround I've been able to do on my demo site was to adjust the message they get when they first try to register to: "Your application will be reviewed by an administrator. You will be notified by email if your application is approved. Should your application be denied, please know that your information will be immediately deleted from the system."
But before I can offer that to them, I need to make sure I'm not lying and that the data actually is deleted immediately, or the details around that.
Por favor
Great question @BrigitteP
We don't store any applicants' personal data after an application is rejected.
Here's what shows up in the db once declined:
Stay awesome,
0 -
Since we don't have an age gate, we've set them up with the Approval method of registration + swapped "Why do you want to join" with "please confirm your date of birth" so they can see that upon approval/denial of membership.
We do not have an Age Gate on purpose. We deleted it because it adds liability where none exists unless your site is marketed at children under 13.
//edit: I could not find where I posted this information a year ago when this last came up so I created a discussion about it: https://staff.vanillaforums.com/discussion/373/
0 -
How long is the information captured by Keen.io stored for? I think it might be for as long as it has been active on a site but I need confirmation.
0 -
How long is the information captured by Keen.io stored for? I think it might be for as long as it has been active on a site but I need confirmation.
That is accurate. Keen does not have an expiry system in place for data. It stays until manual action is taken (e.g. the project is deleted, the API is used to delete data, etc.). I believe the justification is in keep the data for as long as there is a legitimate use for it (e.g. historical analytics).
From Keen's Keen and the EU General Data Protection Regulation (GDPR):
Data retention: Keen stores data for as long as it is necessary to provide services to our customers and for an indefinite period after a customer stops using Keen. In most cases, data associated with a customer account will be kept until a customer requests deletion. (There is also a self-service delete API which is suitable for removing small amounts of data.)
1
