Any plans for DSGVO support?

#1

Hi, I’m using GRAV now for a couple of weeks and it’s really an amazing CMS, I finally got rid of WP with it - thanks! But since May 2018 there is a problem here in Germany and the whole EU - the so-called DSGVO, which is like the GDPR. I know there are some plugins already considering this but I’m not happy with them at all.

If you’re a new GRAV user you’re looking for a DSGVO plugin, not GDPR. It should have a discreet Cookie notice (like on many pages out there), Youtube anonymization (with a preview image), a notice that you’re using embedded Fonts and all that data protection stuff. I’ve built two sites with GRAV for myself now but I’m not feeling good about releasing them to the public without a proper DSGVO setup.

So my question is: does anybody know a proper DSGVO plugin or is even working on it?

#2

To be frank, there’s a lot of hearsay and hysteria going around with regard to DSVGO. Yes, everybody is doing some of these things but also everybody was afraid of demons in the middle ages. Here’s a more sensible overview of the relevant legal facts (in German) from a trustworthy source:

The cookie confirmation modal, by the way, has always been pointless, even under the old law. If you don’t do user tracking, you don’t need the confirmation modal, since the law was never about cookies per se, but about data (it’s not okay, for instance to use localStorage instead of cookies for the purpose of collecting data). If you do collect user data, the modal does not give you free license. Neither do you have to inform about embedded fonts, unless you use them as a hack to track your visitors.

I’m unsure about social media buttons, embedded youtube videos etc, as these inject third party code into your site and might be a vehicle for user tracking from these parties. I wouldn’t know. Also plugins: To be really safe, you might want to inspect the html to make sure that no plugin you are using is doing anything suspicious. In Grav’s case not likely, but theoretically possible. If so: don’t use it. Better still: report it.

With regard to server logs etc. which could be used to identify users: Yeah, it might be a good idea to add information about that fact. It’s a bit pointless, I believe, but just to be on the safe side it doesn’t hurt to add explicit information. That doesn’t require a plugin, though, just information. The point “Datenschutz” from the link above provides more information about this.

All that is written, of course, assuming that your sites do not intentionally mine user data or allow third parties to do so via included advertisements.

I’m writing all that without warranty, of course. I really recommend reading the IHK page I linked to above.

#3

There’s plenty of scripts you could include, or HTML notices to be made, without a plugin. A plugin, irregardless, suffers in that it cannot guess the legal boundaries you are operating within. If the nature of your sites is such that tracking is not necessary, you can simply disable Grav’s session handler:

session:
  enabled: false

Further, pre-existing law from GDPR and DSGVO comply you to state the implied and binding contract between the user and the operator (you, your business, organization, etc). For most sites, that do not require consensual registration or explicit consent for use, a privacy policy will be sufficient as long as you make reasonable efforts to let consumers know about it.

It was the case before the recent set of laws and is the case now that any cookie-cutter privacy policy – there are many usable generators online – will suffice, and you need only include a link to the page with the policy where it is acceptably accessible for the end user; footer links still work. Even if you track behavior with JS-scripts that end-users could disable, or forcibly server-side, letting people know through this page gives you as much legal cover as you’ll ever need.

#4

Does the session handler involve storing data that would allow for a later identification of the user?

#5

Yes, because in modernity cookies are not isolated pieces of data, but can in aggregate be used to both track and identify users down to a frightening level (see cookie profiling, “people-tracking”, history, malwares, research). For example, a basic session-cookie in Grav will look like this:

Name: grav-site-8d348f4
Value: 3pm7pro2j9rlenvrcqg7thgsdi
Domain: .oer.local
Path: /
httpOnly: true
Last accessed on: 21/Oct/2018 12:56:54

The value is mostly used as a token when the user interacts with the site, and is common in many websites. Disabling this would for example prohibit users from logging in to services, or use contact forms, if provisions were not taken.

#6

Thanks for your input, guys - I know that the new laws can be interpreted widely and yes, I do not want to track users on my site, I’m just providing information about the progress on two of my free Indie game projects (and perhaps a third page about myself). I know that data protection laws make a lot of sense today but sometimes I’m just shaking my head about what they’re doing here, the data collectors and the politicians.

I do hate the cookie popups, too but until the new Cookie Law next year lawyers could use the fact against us that we don’t have it. I already have a detailed Privacy Policy, a Disclaimer and an Imprint (but without my phone number). As a private person it is not a must to have all of them but when you’re blogging to the public it is better to have them as they treat you like a journalist - huh? :roll_eyes:

So a quick solution for me would be to disable cookies - the pages should still work like a static HTML site as there is no login or forum yet? And I’m unsure if I should have a forum on a .de Domain today as it became a minefield if you’re the administrator of a discussion board here in germany. I’m hosting my own sites since the year 2000 but it make less fun since lawyers discovered the internet and turned it into a nightmare for webmasters :frowning_face:

My question was not about that I can create it myself (I know PHP for a long time but I don’t think I’m ready to dig deeper here), it was rather if anybody is already working on this common problem as I couldn’t find a well solution for it from the point of view of a new GRAV user like me and this could be interesting for other new users, too. That’s all.

#7

@OleVik Hm, this isn’t really my area of expertise: but the way I understand it, a cookie with a domain set (as Grav does) can only be set and read from the originating domain. My question was rather whether Grav keeps some sort of log file about connections that would allow for the monitoring of a users usage history at a later point in time. As far as I know, this is the point that would be of interest with regard to cookies and data protection law.

@Krischan: If you already have a data protection policy and that policy can easily be found (link in footer or link in impressum does suffice) and that policy does reflect your actual praxis, then you’re fine. Also registration to a forum implies consent that some information allowing for identification is stored. For the most part the DSVGO is quite reasonable. Since there’s a lot of FUD (“Fear, Uncertainty and Doubt”) being spread, this is maybe also of interest to German readers: https://www.heise.de/newsticker/meldung/Kommentar-zur-DSGVO-Posse-Klingelschilder-sind-die-neuen-Gurken-4197173.html

#8

@Krischan Actually, lawyers are hard pressed to argue that. The laws demand user-informed consent, and if you are not tracking users then you don’t need consent for anything. Further, there is no specification that this has to take the form of annoying popups, or even interaction. Informed consent is covered by informing the user, not asking their permission. The same provisions that cover a journalist also cover a private person, they are not a protected profession in any jurisdiction.

As you say, the pages will work as a static site - even though Grav is entirely dynamic - there would be no part of the website that records user information. The underlying server will, however, in all likelihood still do that - which is something to inform about in a /privacypolicy-page. Take heed, though, that most of these laws are largely theoretical. The only thing to go by when considering the implications is case-precedence, wherein there hasn’t been a slew of court decisions to punish any webmaster. Most of the EU laws are coercive, not punitive, so you wont wake up one day with a cease-and-desist letter in your mailbox.

@Utis That is marginally true, in that there are MiTM-methods that can connect this information, depending on what other scripts are running on the same page - either via what the site delivers or what the browser implements. You are right in saying that the default session-cookie cannot be regarded as tracking users or gathering their information. OWASP has a decent overview of the caveats, and why cookies values should be encrypted (as Grav’s session-cookie is). Though browsers and applications now have more robust methods for securing against session hijacking, it is still a method in use. Grav itself does not track activity, but the Admin-plugin does with its activity-statistics.

#9

Thank you. I’ll have a look at what information precisely the admin interface stores. If it’s just completely anonymized, we’re still in the green. If not, I would need to document what exactly is stored in my own data protection policies.

Krischan is right, though, in that under German law you need an imprint for any commercial site (nothing to do with journalism). What constitutes “commercial” is interpreted in the broadest sense possible, though. A blog about game development would probably count, if the games in question are commercially sold. As a rule of thumb: If in doubt, add an imprint.

#10

Utis, afaik even private sites need this. So if I only blog about my own open-source game, I’m already treated like a journalist, too. The legal distinction is: do I share the information only with my family/friends or with the whole public? And most blogs are made for the public. And if you post only a single Ad or a donate button you’re “commercial”.

So all blogs need an Imprint. But according to § 1 Abs. 4 TMG and § 55 Abs. 1 RStV, if the blog is not commercial a limited imprint obligation with a real name, a real address but no phone number is sufficient.

@all: and thanks for your information, I think I know what’s going on now :+1:

#11

The legal distinction (in Germany) is, roughly speaking: Is the site in any way affiliated with commercial activity. However, according to sources like the IHK (“Industrie- und Handelskammer”), already linking to a site that sells services or products or promotes them in any way might count. It’s probably a good idea to err on the side of caution.

I had a look at the data and the code of the admin panel. The log file visitors.json stores an array of IP-Adresses (as hashes) and dates (the other log files are just counting):

Class Popularity in popularity.php:

    protected function updateVisitors($ip)
    {
        if (!$this->visitors_data) {
            $this->visitors_data = $this->getData($this->visitors_file);
        }

        // update with current timestamp
        $this->visitors_data[hash('sha1', $ip)] = time();
        $visitors                 = $this->visitors_data;
        arsort($visitors);

        $count               = (int)$this->config->get('plugins.admin.popularity.history.visitors', 20);
        $this->visitors_data = array_slice($visitors, 0, $count, true);

        file_put_contents($this->visitors_file, json_encode($this->visitors_data));
    }

I feel stupid already just for asking this, because I should know this, but just to be a 100% sure: It’s impossible to reconstruct the IP from the hash, right? That’s the point of using a hash in the first place, right?

If so, we’re in the green with the admin panel. If the IP were not anonymized, it could in theory contribute to identifying a user. But since it is anonymized, there’s no need to mention it in one’s data protection policy.

(Btw. I have to say again, how much I like Grav. I hardly ever write PHP and I’m mostly clueless about backend stuff, and yet I find it comparatively easy and pleasant to read the source code. I’m not really competent to voice an informed opinion, but just from my guts, the gestalt of the whole thing gives an impression of what I would like to call ‘sophisticated simplicity’. A really lovely piece of software!)

#12

I totally agree with the imprint; I can hardly imagine any site without one. That is just a basic contract between you and the user, regardless of how much legalese is in it, and is worth writing for any site. The privacy policy generators available online will give you a good start and something to work from.

In regards to the updateVisitors-method, it’s not impossible - it’s only SHA1-encrypted - but virtually so. This is because of two things: The algorithm is chosen for its speed, but it also has a lot of collisions. Reconstructing any data from it is resource-intensive, but also very prone to errors because of the collisions. That makes data-analysis from backwards-engineering impractical and inaccurate.

I would mention this in a privacy policy regardless, because this shows transparency. You are open about the fact that this most basic of data is collected, but can also make users sure about how little data this is, and what you can and cannot do with it. You are unable to do any tracking that invades privacy, because the data does not allow you to. Of course, you could easily have disabled the encryption, but telling users what you are doing and why is always a good thing.

The word “gestalt” is excellent, and I wish we had a decent English equivalent for it. The code you highlighted is a good example of this. We find the data from a visitors-file, record the current time and obscured IP-address, add to the count, and put this back into the file. This is very straightforward, and typical of how Grav is written.

#13

Back then in my first answer, I wrote:

And that’s correct. I didn’t go into that stuff, because I never used any of this on my sites. However, I’ve been asked about adding social media buttons and embedded youtube videos and so I did a little research …

Oh boy …!

Basically: If you add any sort of Google services to your Website, you’re participating in user tracking. I didn’t bother to investigate what any of the other services do, I don’t believe anybody is better.

One could just declare their use in one’s data protection policy and I wouldn’t be afraid of lawsuits, then. However, even if this should conform to the letter of the law, it certainly goes against its spirit. More importantly, it would exhibit a “what do I care” attitude that I, personally, dislike very much.

There are solutions for that. For social media buttons, the influential German IT publisher Heise has developed “Shariff” (in English):

https://github.com/heiseonline/shariff

It should be straight forward to turn that into a plugin. For embedded youtube videos, I like the solution used by some public law broadcasters (like Deutschlandfunk): What you see on loading a Website is a placeholder box with the information that for data protection reasons you have to click before you can even see the video, thereby giving your consent to tracking. That would also work for Google maps. (Solutions displaying an image of the video possibly run into terms of service issues – they certainly do in the case of Google maps – and are not with absolute iudicial certainty secure with regard to copyright.)

I’m going to implement that, though it’s not on top of my TODO-list right now.

EDIT: In case it’s is of interest for anybody reading this: As for Google fonts – there’s no reason to use Google fonts at all. Fonts can and should be self hosted, Fontsquirrel, just for instance, provides free fonts for download and has an online Webfont generator for those who don’t want to do it from the command line.