search

octobercms / october

Self-hosted CMS platform based on the Laravel PHP Framework.
https://octobercms.com/
Other
11k stars 2.22k forks source link

OctoberCMS GDPR + ePrivacy Compliance Discussion #3493

Closed ghost closed 6 years ago

ghost commented 6 years ago

Hi,

GDPR compliance! All websites in the world need to be GDPR compliance in the E.U. or around the world if an "E.U. Person uses your website"

About GDPR:

consent: the user should be given the ability to opt-in or out, a solo accept button is equivalent to a pre-ticked box (which is non-compliant),

storage: You are required to keep an up-to-date record of users preference status and be able to demonstrate that record upon request (local storage in this instance), and

opt-out: The user should be able to change their mind with as much ease as they opted in, preferably using the same mechanism (DP by design).

There are a bunch more reasons. It's worth noting that cookies are one of the most ambiguous topics of the GDPR, mentioned one (I recall) but included in the scope without any directions on how to comply. It is the EU's view that much of the data collected using cookies can be used alone or in combination to pinpoint specific users (IP, GA snippet, Zip or postcode) so it is well within scope.

For more information, I add the link: https://www.eugdpr.org/

The Enforcement date: 25 May 2018 - at which time those organizations in non-compliance may face heavy fines.

So let's say an E.U. person uses the octobercms.com website and you don't have GDPR working after 25th May 2018 then you could get fined for example.

Because this is a major thing and there is no way to stop a person from the E.U. viewing your website I request that a feature is built into October CMS to keep us safe haha.

Some kind of option in the settings to store the record(s) and a few options like the opt-in and opt-out and the ability to add some more (custom ones). As OctoberCMS uses Cookies, for example, this would be a requirement.

Sorry to write a boring issue, but I feel it's an important one.

There is a plugin found here (in beta): https://github.com/Rebel59/oc-gdpr-user-plugin

However, this plugin only covers the data when installing the Rainlab.User plugin. This would NOT protect Octobercms users that don't use the Rainlab.User plugin and also doesn't cover the issue of Cookies etc. It would be best to have a feature built into the cms settings directly.

LukeTowers commented 6 years ago

@ayumihamsaki This really should have been two separate issues.

In regards to GDPR, there is no magical solution to it. The responsibility is on each organization to implement policies and procedures to ensure that they are in compliance. Storing an additional flag on a user opt-in vs opt-out doesn't actually do anything.

While I agree that OctoberCMS.com itself may need to make some changes to come into full compliance, there isn't really anything concrete I can think of at the moment that can be done to OctoberCMS in general. (Related: WP Privacy Policy, WP GDPR system)

Do you have any actionable proposals for what can be done to bring users of OctoberCMS more in line with the GDPR?

In regards to auto updates, this is something that doesn't currently exist but could be handled by a plugin. Is this something that you would pay for?

ghost commented 6 years ago

@LukeTowers Hi Luke, I have removed the Auto-Update part and just want to keep this issue about GDPR only. I am still reading up about GDPR and not fully confident to give suggestions. I just know that there are several types to GDPR and the bit about Cookies was the bit I thought could be added directly to OctoberCMS.

Recital 30 of the GDPR states:

Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

In short: when cookies can identify an individual via their device, it is considered personal data.

Achieving compliance:

Soft opt-in consent is probably the best consent model, according to Cookie Law: “This means giving an opportunity to act before cookies are set on a first visit to a site. If there is then a fair notice, continuing to browse can in most circumstances be valid consent via affirmative action.”

GDPR Covers these areas with regards to Cookies:

  1. Authentication cookies - To track user login to a web application
  2. Statistic cookies - help website owners to understand how visitors interact with websites by collecting and reporting information anonymously. Cookies for analytics e.g. Google Analytics, Facebook etc.
  3. Form cookies - set when you fill forms e.g. contact us etc.
  4. Preference cookies - enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
  5. Marketing cookies - are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
  6. Mandatory cookies - cannot be deselected. Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

Example Plugins for Cookies:

consent-manager2

consent-manager1

consent-manager3

Other Parts to GPDR:

There are many other parts to GDPR, for example, things like Email Data, Contact Form Data, Guest Posts, Blog Comments, Forum Data etc.

From what I have read the user needs to be able to edit and adjust their Privacy Settings throughout their whole journey throughout your website.

Things to avoid:

  1. Annoying POP-Up Design which will give a bad UX to users on Mobile Devices.

  2. Having a bunch of plugins all asking for their GDPR - when we could have everything in one place, which would be better for the user and the webmaster.

Future:

Maybe best to create a single plugin that the webmaster/developer could add custom features to with regards to GDPR. The plugin could have the most common GDPR things for the webmaster to choose e.g. Cookies listed above, How we store Email Data and/or Contact Form Data, Blog comments (I am not sure about as they can be third party e.g. Disqus and not stored on the website server), Forum Data you would have to get a data protection officer (DPO) etc.

Look forward to people's imput and ideas.

Maybe best for other people to add comments, would it be a good idea to change the label from Question to Discussion?

ghost commented 6 years ago

@ayumihamsaki I would consider moving this question to the forum so that more people get a chance to contribute their ideas. It's not really suitable for a GitHub issue.

LukeTowers commented 6 years ago

@danharrin Forums are mostly dead and tricky to use, I think a GitHub issue is fine for discussing this.

ghost commented 6 years ago

@DanHarrin Have created a forum page and linked it here, can find it here: https://octobercms.com/forum/post/octobercms-gdpr-compliance

ghost commented 6 years ago

Personnaly, to handle this, I added this plugin to my starter theme.

It's easy to install and support major services. One days, we noticed the author than a service we needed was not listed, it was added few days later.

I use Magic form plugin to manage my forms and I just created a PR to be able to delete records after a certain time (which to me make it GPRD compatible).

With that 2 things + a solid legal notes page, I think October CMS is GPRD comptible (at least for basic needs).

ghost commented 6 years ago

I raised an issue with the most common form plugin for OctocerCMS here: https://octobercms.com/plugin/support/renatio-formbuilder/make-this-plugin-general-data-protection-regulation-gdpr-compliant

LukeTowers commented 6 years ago

@ayumihamsaki thanks for your contributions to this! As a note; there is an easy way to make data encrypted in October, just use the Encryptable trait in your model: http://octobercms.com/docs/database/traits#encryptable

roulendz commented 6 years ago

I think, on of approaches could be to build a plugin. @ayumihamsaki give good reference images + here is good demo We could start from here.

Also good would be to add some trait to models, for automatic old data deletion after a certain period.

ghost commented 6 years ago

Hi to all,

in order to be compliant to gdpr we acted as follow: Extended the eu cookie law madness plugin for octboer cms with using a standard js pop out button to allow users to revoke always cookies. Ipdated and extend oour privacy policy declaring who we are, what do we do with this data and if we collected them. I prefer always to not collect data for a simple form.

Anyway here is an example: A robust privacy policy with extended explanation, the cookies section and a button to always revoke cookies.

We disabled all "like" buttons style, i don't think they are necessarily needed, but have always the doubt: these buttons help to create profile for social nwetwork? So we have declared it if we used it. And block.

So to be compliance to gdpr we think: You have to create a strong policy, a button, always available to revoke cookies. This tasks could be reached by a plugin.

Then you have to project by design the database part. We use magic forms for our forms. We don't store nothing, but it would be necesseraly i think the author updated the plugin to be compliant with new rules.

Hava another doubt. For a future project we will have a private area. If we will use rainlab.user, what steps will do to have all as much as ok? @ayumihamsaki which were your technicla solutions?

Bye

CptMeatball commented 6 years ago

Quick status update about our plugin. (GDPR User) That was a try out and did not do anything that really matters in the scope of the GDPR. The idea of that was to encrypt all user related data, so in case of a data breach user data would not have been out on the streets directly.

We've done some more research about the GDPR, and we're convinced that fully encyrpting all user related data fields is not the way to go. You are also compliant if you set up the rest of your infrastructure in a common sense way. Encrrypting everything feels (and to our knowledge) is a last stand in case you have a crappy host or don't care about updating your hosting environment.

Apart from the consent part, you need to keep everything up to date and install some safe practices (using env setup and mirror the public folder for example). In that way if it goes wrong, you can prove you've done everything with safety in mind.

The GDPR is not a ENCRYPT ALL THE THINGS legislation. However, it does force companies to think about how data is stored and which data is absolutely necessary.

ghost commented 6 years ago

@CitrinoDeveloping, In the end, our solution was to do a full GDPR and ePrivacy!

@CptMeatball Sorry about that I should of stated it was in beta but looked a good idea and worth a mention.

Our conclusion of using Encryption was that is was not needed for GDPR, but needed for ePrivacy. But a more serious issue is that hackers can attack a website, steal the data and then do a Ransom Demand saying: "Pay us money or we will release the hacked data and you will get a fine of €20 million or 4% of annual turnover (whichever is higher)". So that issue needs to be taken into consideration I feel.

Good luck to everyone doing GDPR + ePrivacy!

CptMeatball commented 6 years ago

Encrypting everything in the database doesn't have any use, if they already have your cipher. Most likely they already have access to your webserver if they get access to the database. But none the less, it was worth a try. ;)

Have you guys made something of a GDPR cookie compliance popup?

tobias-kuendig commented 6 years ago

If anyone is looking for a simple solution or starting point to get GDPR compliant with October and custom plugins we have created a GDPR plugin over at https://github.com/OFFLINE-GmbH/oc-gdpr-plugin

At the moment you can delete old plugin data automatically and include a cookie consent widget via the component system.

If anyone has further ideas on how to extend the plugin we're open for suggestions!

CptMeatball commented 6 years ago

Awesome! We'll definitely take a look at it!

ghost commented 6 years ago

Want to add this extra information and update the title.

ePrivacy and GDPR:

The GDPR came into effect in 25th May 2018 which replaces the Data Protection Directive 95/46/EC. It deals with Privacy!

ePrivacy (also known as ePR) came out in 2003 and got updated in 2011, it is currently being updated right now and The EU hopes to finish the updated new ePrivacy Law at the end of 2018 or in 2019. There is a draft out which can be found here: https://iapp.org/media/pdf/resource_center/ePR_2018-04-13.pdf

A progress report dated June 2018 is found here: https://iapp.org/media/pdf/resource_center/ePR-ST_9079_2018_INIT_EN.pdf

ePrivacy deals with Unsolicited Marketing (SMS, Emails, Web Notifications, Cold Calling etc.), Cookies and Confidentiality. Also, social media sharing, like buttons and widgets are under ePrivacy.

Technically there is no such thing as GDPR Cookies, it would be ePrivacy Cookies!

EU Cookie Requirements (incl. GDPR):

Also some things I want to point out that make me think many Cookie Plugins wont pass the new ePR laws.

Section (23) states:

End-users should be offered a set of privacy setting options, ranging from higher (for example, ‘never accept cookies’) to lower (for example, ‘always accept cookies’) and intermediate (for example, ‘reject third party cookies’ or ‘only accept first party cookies’). Such privacy settings should be presented offered in a an easily visible and intelligible manner.

Therefore cookie settings need to be in a range, not a toggle switch saying on and off. You would need to have the option in a slider range.

Section (24) states:

Information provided should not dissuade end-users from selecting higher privacy settings and should include relevant information about the default setting and about the risks associated with the different privacy settings, including those related to allowing third party cookies to be stored in the computer, including the compilation of long-term records of individuals' browsing histories and the use of such records to send targeted advertising.

Therefore you would also need to explain the difference in the cookie setting range of each cookie setting.

Another factor is that Cookie settings need to be on a "second page", so I am really not sure if that would allow a popup modal from a banner for example?

On a personal level, I really don't like the idea of using Javascript cookies for a cookie plugin, this opens up a big array of security issues ranging from XSS, CSRF, Session hijacking, Meltdown and Spectre (Spectre part) and many other problems. Using PHP cookies we can give some proper security things such as HTTPonly, Secure and SameSite.

Methods of Consent:

There are three main ways: (Please note this is before the Settings)

untitled

One last thing with ePrivacy, I'm really up for building a proper ePR plugin, that will let the webmaster and developer have control over cookies, social media data sharing, push notifications, sending sms/txt and emails and lastly widgets (for example Twitter timeline embeds etc.) My coding is not so strong so any help would be great at a later stage.

Finally gonna change the title to: OctoberCMS GDPR + ePrivacy compliance Discussion.

tobias-kuendig commented 6 years ago

Another factor is that Cookie settings need to be on a "second page", so I am really not sure if that would allow a popup modal from a banner for example?

This means you'll have to be able to edit your cookie settings after the initial prompt (maybe via a "second page"), right? With a solution like Klaro! you can create a simple link to reopen the overlay again at any time. I really don't see the reasoning to expect a separate page instead of a simple modal. I cannot imagine that such implementation details are being defined.

On a personal level, I really don't like the idea of using Javascript cookies for a cookie plugin, this opens up a big array of security issues ranging from XSS, CSRF, Session hijacking, Meltdown and Spectre (Spectre part) and many other problems. Using PHP cookies we can give some proper security things such as HTTPonly, Secure and SameSite.

Do you have a concrete example? I don't see how PHP cookies are more secure than JS cookies.

ghost commented 6 years ago

@tobias-kuendig

Hi,

I'm really not totally sure about the overlay if it's ok or not with regards to a legal point of view. Can't really say for sure as the ePrivacy is still in draft. However from a UX point of view, many don't work on a lot of Mobile devices so that would be a bigger problem in my eyes.

Do you have a concrete example? I don't see how PHP cookies are more secure than JS cookies.

A HttpOnly cookie means that it's not available to scripting languages like JavaScript.

Note sure about the secure flag on Javascript?

The SameSite flag is for server-side only as well, so again Javascript cannot use it. For details on Samesite see here: https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/

Security Spec's on Cookies: https://scotthelme.co.uk/tough-cookies/

ghost commented 6 years ago

Going to outline the idea of a good GDPR + ePrivacy Plugin, if someone wants to code it for everyone you are more than welcome. I just don't have enough time to code all my things right now. So sharing my idea hopefully can benefit everyone.

Part 1

Use a banner consent when a user opens the website for the first time. The banner needs to be at the bottom of the webpage and not at the top due to Google crawling rules. The banner also needs to be small because under Better Ads Standards the total banner height for all things on a webpage is under 30% or you will get a Google Penalty, see image:

interstitials-28

My idea for a Banner would be to have a short text description of what Cookie's you have and what they are used for. Also, a Cooke Settings button and an Allow All button, plus a close Banner button that would also act as a denied consent option, see example:

untitled

The results go to the plugin and save as analytics data in the back end for the webmaster to know what people are selecting. The results also make a PHP cookie which has the flags 'HTTPonly', 'Secure' and 'SameSite'.

Part 2

We don't use an overlay or modal or another banner or pop-up. Users hate these things and reduce your website conversion rates. So we send the user to a proper Settings Page. Here the user can read what the cookies and other things do and be able to use a normal form to select options in a range.

Things that could go into the contact form are:

You could also explain to the user when they use the slider what happens when they increase the slider to each thing. For example, Google Analytics uses 7 cookies and I use the PWA version which is called Auto Track, it gives me a dozen plugins for GA, so the user could slider the GA option and turn on each of the plugins etc. Here is an example:

untitled

Part 3

We use Twig PHP Wrappers, OctoberCMS is an amazing tool and we should use its powers here. To be able to turn things on and off we create Twig Wrappers an example can be this:

  {% if GdprOption1 is not '0' %}
    <div>Widget</div>
  {% endif %}

If GdprOption1 = 0 don't display
If GdprOption1 = 1 do display

You can also add CSS and Javascript to OctoberCMS Partials using the header plugin. So I don't have to create a Wrapper to each script tag - like many cookie plugins do. Instead, we could have several Javascript code snippets in one file and be able to turn on and off each bit, for example:

<script>
  {% if GdprOption1 is not '0' %}
    JS Code 1
  {% endif %}

JS Code 2

  {% if GdprOption2 is not '0' %}
    JS Code 3
  {% endif %}
</script>

Part 4

We are only going to send ONE cookie via PHP using the flags 'HTTPonly', 'Secure' and 'SameSite'. An example of the backend of the plugin could look something like this:

untitled

For extra security, we could make an array using integers only and use regrex validation to remove any other characters, to prevent hacking! e.g.

If GdprOption1 = 0 don't display If GdprOption1 = 1 do display If GdprOption2 = 0 don't display If GdprOption2 = 1 do display

Would be like:

"1": "0", "2": "1",... etc. Which would make a cookie like: "GDPR Cookie", "1021", "", "", ""...

Anyway, a very simple idea which is very powerful because it uses OctoberCMS Laravel features. If someone wants to make it please go ahead, as I am so busy! I don't think I could spend time on it for 2-3 months at least.

tobias-kuendig commented 6 years ago

:clap: Very nice write up! I'll try to implement a prototype in our GDPR plugin.

tobias-kuendig commented 6 years ago

A first implementation has been released! :tada:

You can check out what it looks like on our demo website: https://mall.offline.swiss The code is available over at https://github.com/OFFLINE-GmbH/oc-gdpr-plugin

Currently there are the following components available:

cookieBanner

image

This component displays the cookie banner. It displays checkboxes for each cookie group that has been defined via the backend settings. This allows the user to quickly enable or disable certain types of cookies.

If the user accepts the cookies, all relevant scripts will be reloaded via AJAX (optionally a hard reload of the page can be triggered). If the user declines the banner disappears and no cookies are enabled.

If the user clicks on the advanced settings link no cookies are set until a decision is made via the cookieManager.

All user specific decisions are stored in a single cookie.

cookieManager

cookie-manager

This component displays detailed information about all cookies. Note that the table in the GIF is only displayed for debugging purposes.

Cookies can be enabled or disabled. If a cookie has levels defined a slider is shown additionally.

Twig helpers

The Twig helpers gdprCookieAllowed and gdprAllowedCookieLevel make it easy to conditionally include your dependencies.

{% if gdprCookieAllowed('google-analytics') %}
    <!-- Include Analytics Code here -->
{% endif %}

{% if gdprCookieAllowed('google-analytics', 3) %}
    <!-- Include advanced Level 3 Analytics Code here -->
{% endif %}

Feedback and PRs are highly welcome. Thanks again to @ayumihamsaki for the great write up that served as blueprint for this addition.

ghost commented 6 years ago

@tobias-kuendig Looks great! Congrats, gonna beta test it and will pass any useful feedback.

ghost commented 6 years ago

Gonna close this issue, we are busy working on the October CMS GDPR and ePrivacy Plugin, so use this link: https://github.com/OFFLINE-GmbH/oc-gdpr-plugin