GDPR

Cookies Policy and GDPR

On May 25th, 2018 the European Union's General Data Protection Regulation (GDPR) comes into effect. In this article we will explain what are the changes it brings with regards to our services and our software.

he GDPR is legislation designed to promote a privacy first approach to handling your personal data with more transparency and a way to reasonably exercise your data rights. While it only covers citizens of any member state to the European Union we consider it better to provide the same level of treatment to everyone. Not only it's more sane for us (since we can't know what is your nationality, to begin with) but also because we care deeply about your privacy and security.

First and foremost, you will see that there our Privacy Statement and our Cookies Policy are now separate documents from our Terms of Service. However, accepting the whole lot is still required to use our services. The Terms of Service does state that the privacy statment and our cookies policy are integral parts of our Terms of Service.

Per the GDPR you now have to give your explicit consent to us processing your personal information. That's a fancy way of saying that you let us give your invoicing information to the tax authorities and our accountants and auditors, as well as let our staff (who are technically subcontractors) to provide you support. Starting May 19th you will need to indicate your consent if you subscribed before April 2018 or do not have an active subscription with us. You can withdraw your consent at any time but we won't be able to provide any of our services to you until you give your consent again. Managing your consent (revoking your consent) is possible after that. Read the "Exercising your Data Rights" section below for more information.

Cookies can likewise be rejected, including the login / session cookie of our site. If you reject cookies you will not be able to log into our site and we will not be able to provide you our services due to no fault of ours. We might revise this policy in the future since login cookies are exempt by the GDPR. It's just that the third party extension we currently use does not have that option. Most importantly, when you reject cookies you just disable Google Analytics. We don't use any other cookies on our site as of the time of this writing; check the Cookies Policy for the most up to date information. Cookie consent can be given and revoked at any time. Look at the bottom of every page of our site for the controls.

If you have questions about our handling of your personal information please do read the privacy statement and cookie policy pages. All the information the European Union requires us to make available to you is in there. Emails or other forms of contact with similar questions will be answered with a link to this page which contains links to the pages with the information you are seeking. If you feel something is missing please do say so in your email and point out exactly what so we can help you. If you have spotted something substantial missing we will of course update this page to include the missing information.

Below list our third party components and software and how they regulate for the GDPR

Our Backup software (Akeeba Backup, Akeeba Solo)

Backups, by their nature, keep averbatim copy of the entire site including personally identifiable information. We recommend that you use the JPS (Encrypted Archives) format with a strong password and / or store the backups on an encrypted disk to comply with the GDPR's requirements for implementing common technical measures to prevent data leaks. Ideally, the JPS password should not be stored in the database. Instead, you should pass it as a command line parameter to the CLI CRON script that runs the backup. If you are not using the CLI CRON script then at the very least make sure that you are only ever accessing your site through HTTPS to protect the JPS password from eavesdropping.

Storing backups is not illegal and no, you don't have to go back to all your backups and delete personal inforamtion whenever someone asks you to delete their profile on your site. You must, however, keep an audit trail of profile deletions and replay it after restoring from a backup. In other words, after restoring an older backup make sure you delete the information of the people who had already asked you to delete their personal information between the date you took the backup and when you restored the backup. For this reason it makes sense to keep automated daily backups; this will minimize the work you will have to do.

Where your store your backups and where you are hosted is also important. If you are an EU site you SHOULD use servers in the European Union or otherwise use services which comply with the GDPR. Unfortunately, cheap / free storage such as Dropbox, OneDrive and Google Drive do NOT meet the GDPR requirements. Dropbox for Business, while too expensive for most of you, does offer storage exclusively in EU servers and does comply with GDPR. Big cloud storage providers such as Amazon, RackSpace and Microsoft do offer EU-only storage. We recommend that you do that. As an important aside, if you only ever store encrypted (JPS) archives then even consumer-grade storage such as Dropbox and OneDrive would be acceptable: even though these services do not guarantee the privacy of your data stored with them, the total encryption of the backup archive (a key feature of the JPS format) does.

Regarding our handling of our site's backups, they are encrypted, stored on our Australian Server with Ventra IP Australia and we have written our own GDPR compliance software which allows us to replay audit logs even in the unlikely event of a catastrophic failure of our site. We apply the audit log replay every time we restore backups, including on our local testing servers (this onlyapplies after May 25th). Furthermore, should our subcontractors require a copy of our site for development reasons they do NOT get access to ANY personally identifiable information (we apply deep scrubing and / or complete anonymization of the data).

Our security software Akeeba Admin Tools

While storing IP information may be considered personally identifiable information, the GDPR makes an exception for IP information stored in the context of security. As such the Admin Tools' security exceptions log and related IP whitelist, IP blacklist, automatic IP blocks and automatic IP blocks history is outside the scope of personal data protection. It's also worth noting that IP addresses per se are not personally identifiable information. If your organization has the legal means to compel ISPs to divulge the real world identity belonging to an IP address (that is to say, without having to go through court) OR if you store the IP address in cojuction with personally identifiable information (e.g. email address) or a personal marker (e.g. user ID) then that IP address becomes personally identifiable information. But, again, if it's just used for security logs it is exempt from the requirement of providing consent.

Text log files may, however, contain privileged information as they capture the entirety of the request sent by the user to your site. We therefore recommend that you DISABLE the "Keep a debug log file" option in the Configure WAF page.

Furthermore, the GDPR calls for data minimization. To comply with this requirement we urge you to set the "Maximum security exceptions log entries" option to a non-zero value in the System - Admin Tools plugin. Typically, a value of 1000 to 10000 provides a good balance between data minimization and security.

The Project Honeypot and "Warn about use of well-known passwords" features do transmit information to third parties. However, this information is anonymous and should, therefore, fall outside the scope of the GDPR.

Using the GeoIP feature is also GDPR compliant. The IP address does not leave your server. The copy of the MaxMind GeoLite Country IP Database used to determine the country and continent of an IP address is stored on your own server. And no, before you ask, if you are outside the EU you can NOT use GeoIP blocking to dodge GDPR completely. The GDPR applies to all EU citizens regardless of where they live. A French person sitting in a cafe in New York city is protected by the GDPR the same way as if they were sitting in a cafe in Paris. GDPR concerns the nationality of the user, not their physical location. Not to mention that there are VPN and proxy services to fake the GeoIP location of a user, as well as the imperfect (around 90%) accuracy of GeoIP in general. Don't try to use GeoBlocking to dodge the GDPR, you will only make matters worse for you.

Finally, it is possible that in the past you may have enabled the feature to log failed login passwords. This might be a security concern or a violation of the GDPR. We have now removed that feature but you may still have information stored in your database. We recommend that you go to the Security Exceptions Log page, filter by reason "Login failure" and delete all records presented to you.