Cidram: GDPR

[Maikuolan]

This issue is in regards to the __The EU General Data Protection Regulation (GDPR)__, which will come into effect on 25 May 2018 (that's 11 days from now).

I'm not a lawyer, but I've been carefully reading over the publicly available information I could find about it, and trying to make sense of it all, to figure out exactly what measures should be implemented, both here for CIDRAM, and for other, related projects (e.g., phpMussel), in order to mitigate any legal risks as much as possible.

In reference to:

• GDPR FAQs

Of particular note:

What constitutes personal data?

Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.

I'm not entirely sure what effect this would have on basic logging functionality from a legal perspective (e.g., logging blocked IP addresses, and with an IP address being considered "personal data" in most contexts according to GDPR), but due to that logging is an essential part of the package (so, not practical to remove at all; forcibly disabling or removing it would make no sense, I think), and considering that it requires modifying various configuration directives (e.g., specifying which filenames to use for logging block events) in order to work properly anyway, my current thought, is to leave it be and not change anything about it at all, but to add some information to the documentation (I would propose, in the form of a new FAQ entry, advising users that they are responsible for deciding what to enable in the package and what to leave disabled, advising users that we aren't lawyers, and that they should seek their own legal advice about these matters if they need help in making these decisions, and that certain features of the packages might be incompatible with GDPR or similar such laws).

If anyone else had ideas about this though (possibly other suggestions, or opinions about what I've suggested above), I would be happy to hear those ideas.

Next, in reference to:

• GDPR compliance
• Currently not GDPR compliant - reason external fonts

Currently, both CIDRAM and phpMussel leverage some Google Webfonts for some of their themes (including the default theme). A configuration directive (disable_webfonts) is already supplied in both packages, allowing package users to disable webfonts if they so choose. However, this directive is set to false by default. As using Google Webfonts without explicit consent from the end-user may cause non-compliance with GDPR, I propose that the default value of this directive should be changed to true, in order to mitigate any legal risk for package users (thus disabling webfonts by default). Additionally, the directive documentation should cross-reference to the newly added FAQ entry. (It's on the to-do list currently to be able to host WOFF files locally within installations at some point, but as this feature hasn't yet been implemented, simply changing the default value of an existing directive might be the simpler, more expedient solution for now).

Next: Use of reCAPTCHA in CIDRAM.

Official statement from Google in regards to GDPR compliance:

• Compliance | How Google complies with data protection laws

Our commitment to GDPR

We are working hard to prepare for the EU’s General Data Protection Regulation (GDPR). Keeping users’ information safe and secure is among our highest priorities at Google. Over the years, we have spent a lot of time working closely with Data Protection Authorities in Europe, and we have already implemented strong privacy protections that reflect their guidance. We are committed to complying with the new legislation and will collaborate with partners throughout this process.

..Which is great and all, and great to hear that collected data is apparently secure, but doesn't really address the problem of user consent.

One possible solution, is to force that a predefined "privacy agreement" be presented to users, before reCAPTCHA is loaded, in order to gain their explicit consent. I don't think this is really practical though, due to possible language barriers, possible interference with normal logging routines, general inconvenience for users as they would be being forced to read a lot of information, just to be allowed to prove that they are human (e.g., to be given the opportunity to complete the reCAPTCHA instance). Alternatively, a similar approach could be taken as per suggested above with logging and webfonts: Have the configuration directives related to reCAPTCHA be crossed-referenced with the newly added FAQ entry, to make it clear that there may be possible legal compliance issues, and that websites serving EU users might want to leave it disabled. Going on this idea, we wouldn't need to implement any changes to the codebase itself, seeing as reCAPTCHA requires API keys in order to work (thus meaning that it is disabled by default, until the package user enters some API keys into the configuration).

Worth noting too: Current implementation of the "invisible" reCAPTCHA would definitely be non-compliant, due to that CIDRAM handles everything automatically, meaning there'd be a high chance that the end-user wouldn't notice anything anyway (thus eliminating the possibility of gaining meaningful consent). At the very least, websites targeting EU users should probably revert to the older, more primitive "V2" reCAPTCHA, due to that it isn't automatic (though disabling reCAPTCHA entirely would still be preferable, from the perspective of mitigating legal risks).

There are also some provisions in GDPR about websites based in member countries not being allowed to block IPs from other member countries (which.. could be problematic for website owners, to say the least), but shouldn't be any problem from the perspective of package maintainers, due to the basic warranty disclaimer as per the GNU/GPLv2 license and such ("This script is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE" ...), and that a maintainer is not the same thing as the entity which installs or operates the package (which would be responsible themselves for however they choose to install and operate the package). It's also __mentioned in our FAQ already__ that individual website owners are responsible for what they choose to block and not block:

__I've been blocked by CIDRAM from a website that I want to visit! Please help!__

CIDRAM provides a means for website owners to block undesirable traffic, but it's the responsibility of website owners to decide for themselves how they want to use CIDRAM. In case of the false positives relating to the signature files normally included with CIDRAM, corrections can be made, but in regards to being unblocked from specific websites, you'll need to take that up with the owners of the websites in question. In cases where corrections are made, at the very least, they'll need to update their signature files and/or installation, and in other cases (such as, for example, where they've modified their installation, created their own custom signatures, etc), the responsibility to solve your problem is entirely theirs, and is entirely outside our control.

In summary, what I've proposed above:

• Adding a new FAQ entry to the documentation to address possible legal risks, advising users to seek their own legal advice if necessary, and to reiterate that we aren't lawyers, nor legally responsible for their choices.
• Cross-referencing directives related to possibly affected features to this newly added FAQ entry.
• Changing the default value of disable_webfonts to true.

Thoughts, ideas, opinions, etc, are invited. Whatever we decide though, I'll want to get started ASAP, in order to try to get everything finished before May 25th (changes proposed thus far are pretty small anyway, so, I could probably get it all done in a day or so, assuming we don't decide on something much more complicated).

[dev-101]

GDPR (not GPDR) ;-)

I am also not a lawyer, and doubt one will come here to shed some light specifically, but there is a lot of FUD and misinformation out there (and many decided to make $$$ starting as low as $200/mo, reminiscent of SSL hype few years ago).

In terms of logging IP address, I think it falls under 'fair use' / legal interest category (e.g. service security, law enforcement requests, etc.), where no explicit consent should be given, unless you plan to process that data (e.g. identify person, contact, share data with other entities, make targeted offers etc.). I mean, every server out there logs it!

Re Google Fonts, I also think that it will be safe, as you already linked to it's git repo issue, I assume you've read it, nothing concrete there, except speculation and few common-sense reasonings.

I guess in a month or two dust will settle, and things will become much clearer.

_disclaimer: this is my personal opinion_

[Maikuolan]

GDPR (not GPDR) ;-)

Oops.. Good catch. Original post + issue title edited accordingly. 😳 😄

[Maikuolan]

And fingers crossed (re: dust settling). I guess we'll see.

[dev-101]

First and foremost, every web app/service/site out there must have a proper Privacy Policy (PP) page, where all those things (data logging, data usage, cookies, opt-in/opt-out (if applicable), usage of external services, social networks, widgets and what not) should be explained.

Also, link to those services / their privacy policy pages would not harm, especially in case where no explicit consent is required (e.g. I'm assuming that will be the case for Google Fonts, reCaptcha and similar). reCaptcha already comes with a badge, which is explicitly required by Google, where users can click and inform themselves about their respective PP terms.

[DanielRuf]

TL;DR

Shorten IP addresses at the end, host Google fonts yourself and add data information about external services.

Anything else would be against GDPR. IP addresses are PII.

[ghost]

Also not a lawyer.

But I would think that basic logging for security purposes is ok as long as it is done with transparency. I.e. a privacy policy statement explaining that the data is anonymous (no person traceable) and only used for keeping the site secure.

Key parts: Data not used for anything else, log rotation available. Clear explanation about this in documentation.

Although terribly implemented the goal with the directive is to stop the misuse of data, not to stop keeping the web secure.

[DanielRuf]

he data is anonymous (no person traceable)

It is not if you do not shorten IPs ;-)

[DanielRuf]

Also logs should be deleted automatically after a specific period.

[ghost]

It is, as long as it is IPv4 at least. You can never isolate that kind of address to a single person, especially not with all the DHCP rotation going on at ISP level and NAT-ed networks being common technology.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[DanielRuf]

It is, as long as it is IPv4 at least.

Even IPv6 here in Germany. IPs are PII by law.

You can never isolate that kind of address to a single person, especially not with all the DHCP rotation going on at ISP level and NAT-ed networks being common technology.

Sure you can here, it is called "Vorratsdatenspeicherung" by law and also many people also have the same IP for a specific time even with cable internet.

Still, IP addresses (it does not matter if v4 or v6) are PII as the court says.

[ghost]

Well then, why not just a flip switch to turn off logging if you are paranoid about IP addresses in this use case, and be done with it?

[DanielRuf]

Well then, why not just a flip switch to turn off logging if you are paranoid about IP addresses in this use case, and be done with it?

Just shorten them. This is what Google and Nintechnet already do.

[dev-101]

Daniel, can you post a link where Google claims that?

I don't think they are shortening IPs in their logs, they only hide it or encrypt it when sharing data with 3rd parties, to prevent own employees spying and using unauthorized access, etc.

That's what GDPR does per my understanding.

Also, see lawful basis in GDPR:
https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/

[DanielRuf]

they only hide it or encrypt it when sharing data with 3rd parties, to prevent own employees spying and using unauthorized access, etc.

This is not the case.

That's what GDPR does per my understanding.

No, there is much more.

See https://support.google.com/analytics/answer/2763052, they shorten / nullify the last part. This is the anonymization part and what Google logs on their side. And what also others do and should do.

All this is not new in general.

https://www.enterprisetimes.co.uk/2016/10/20/ecj-rules-ip-address-is-pii/
https://www.whitecase.com/publications/alert/court-confirms-ip-addresses-are-personal-data-some-cases

[dev-101]

Ah, I knew you were talking about analytics :)

That's what I was talking about when sharing data with 3rd parties in data processor role.

I was talking about G's own services, like Gmail, YouTube etc. where do they state that they aren't logging IPs?

That's a big difference.

[DanielRuf]

about analytics :)

Not just analytics, YouTube and others also have these settings, either in the dashboards and generated snippets or in the frontend.

[DanielRuf]

I was talking about G's own services, like Gmail, YouTube etc. where do they state that they aren't logging IPs?

They log, like everyone does. But new regulations will require the shortening of IP addresses in general if you log european data.

[DanielRuf]

That's a big difference.

No. Also Google !== everyone else. They can move their datacenters around and apply the required steps.

Website creators / webmasters have to apply these steps themself.
GDPR affects everyone.

The YouTube and analytics settings are very old.

[dev-101]

Yeah, but you have to separate analytics stuff and server/services usage logging.

Analytics can be used to share data with others, and server logs usually (under normal conditions) are not. They are only used by scripts and security modules (for e.g) to provide service.

I mean, it's a rabbit hole right there, but it is different.

[dev-101]

I simply haven't found anywhere in GDPR that we are required to obfuscate IPs in apache/nginx etc.

I believe you've misunderstood that part.

Also, if I'm not mistaken, Zebra from SFS once told me in Germany you are required to keep server logs for at least 2 months or so, in case Law enforcement entities make a request to provide them in certain cases. Other countries may have similar laws, I don't know for sure, but logs are important pieces in case of frauds etc.

GDPR is not created to protect fraudsters!

[DanielRuf]

Also CMS logs and logs of CIDRAM and other solutions are definitely affected. And server logs, at least AWStats and others.

[DanielRuf]

in Germany you are required to keep server logs for at least 2 months or so

That would be new for me.

[dev-101]

Hmm, so, how anti-fraud credit card services and many others can work in that case? You need a popup before first page loads asking for consent? I haven't seen anyone doing it (yet). So, they are effectively breaking GDPR?

I'll wait & see what happens in ~10 days before jumping into the conclusions. I simply hope that my reasoning is right about this.

[dev-101]

Also, as the nature of web is such, you can't connect to the server, which will first serve you the page asking for consent (without any logging) and then start logging subsequent requests. It's not how it works. Again, analytics and marketing stuff aside.

[horninc]

If you look both at the GDPR and the opinions and recommendations given by the WP29 working party - the correct way to solve this would be to pseudonymize the IP address to something like 127.0.0.xxx a.k.a 192.168.9.0 instead of 192.168.9.5.

In addition, current log files that do write IP address in full or in general all log files should be encrypted for application only access or use envelope encryption (recommended).

Simply storing IP will not fly, and the law is not concerned with the fact that most systems at the moment do so.

[DanielRuf]

If you look both at the GDPR and the opinions and recommendations given by the WP29 working party - the correct way to solve this would be to pseudonymize the IP address to something like 127.0.0.xxx a.k.a 192.168.9.0 instead of 192.168.9.5.

That's exactly what I mean and already wrote ;-)

In addition, current log files that do write IP address in full or in general all log files should be encrypted for application only access or use envelope encryption (recommended).

Simply storing IP will not fly, and the law is not concerned with the fact that most systems at the moment do so.

Exactly. Server providers have other solutions which you should not have to care about. But CIDRAM logs.

[Maikuolan]

<the TL;DR part of my reply>

Perhaps a very badly worded law (I know I would've worded many parts of it very differently, if I'd had any involvement at all), and a PITA for operators, and something that (ideally, if there was a choice) would be much easier and preferable to ignore, but as it does affect anyone that deals with the EU (and considering that CIDRAM+phpMussel have a geographically-diverse userbase which would certainly include people from within the EU and people serving customers in the EU), it's definitely something that we would need to address somehow, in order to mitigate potential legal risks as much as possible for the userbase.

Also, due to that we don't track who actually uses CIDRAM or phpMussel, and have no way to 100% know for certain who does and doesn't use these packages, I would need to assume that it's at least possible that in theory, some big companies, which could be subject to these types of fines, could be using them (not because I know of anything specific, but more so, because I couldn't prove otherwise), and therefore could be considered as part of the userbase.

The point about being geographically-diverse, is also a reason (other than not being lawyers) that we should avoid giving specific legal advice, because the exact implications of the law (especially in regards to enforceability, and in regards to possible similar laws implemented elsewhere), could be slightly different between different regions (therefore meaning that any specific legal advice could be true for some users, and false for other users). I know that the State of California, for example, has "CalOPPA", which is something that anyone operating an internet-based business out of California, or targeting Californians would need to be careful about (I've heard some people draw some parallels before between GDPR and CalOPPA). GDPR may also directly conflict with data retention laws which exist in other countries, demanding that operators retain data for X period of time, and these laws will likely differ greatly between different countries. But I think, doing whatever is reasonably possible for us to do (without negatively impacting the packages as a whole, of course), and at least, warning users that they should "seek advice" where laws may affect their use of the packages, would be a good idea nonetheless.

Probably, in the case of standard communication from endpoint to endpoint (some IP address sending a request to a server, the server processing the request, sending a response and such), I don't think laws could be practically enforced, because like you've already mentioned, it's just not how it works (basic internet request paradigms and such), and we'd have the whole chicken and egg paradox (how to reply to a request from an IP address, if the server isn't allowed to see the IP address and such). Expecting as much from operators could be considered unreasonable though, could be reasonably exempted as an essential component of providing a service (so I assume..? but again, not a lawyer), probably won't be enforced, and is also outside the scope and responsibility of the packages in question anyhow (in short: a possible problem for webhosts, and for the maintainers of Nginx, Apache, etc, but not so much our problem).

Also, an interesting article on that exact subject: __EU GDPR and personal data in web server logs – Ctrl blog__

Above-linked article mentions possible disabling access logs in some cases where necessary and reasonable (though there are also provisions in the GDPR for retaining data where necessary to prevent fraud and to maintain security, so retaining complete access logs may be permissible in some cases; I assume you'd still need to be able to legally prove that it's necessary though, if it ever came into question).

Related:

• __Standard server logs with IP addresses must be disclosed in a privacy policy but... | Hacker News__
• __Access logs - impossible to be compliant? - General Data Protection Regulation (GDPR) - Spiceworks__

And also:
__Recital 47 EU General Data Protection Regulation (EU-GDPR). Privacy/Privazy according to plan.__

(47) The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller.
(..)
The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned.

Probably, anti-fraud services (like those dealing with credit cards and such) would have some leeway here, due to the above-mentioned exemptions (but as CIDRAM is not an anti-fraud service, the same exemptions wouldn't apply to CIDRAM so much, I think).

</the TL;DR part of my reply>

---

Adding the ability/option to anonymize/pseudonymize definitely sounds like a good approach, and could be implemented relatively easily, I think. So, if for example, 1.2.3.4 (IPv4) or 1:2:3:4::1 (IPv6) was blocked by CIDRAM, and the block event logged, we could (when the option is enabled) log it as 1.2.3.x, or 1:2:3:4::x, or etc (munging the final octet for IPv4, or rounding everything to a x/32 or something like that in the case of IPv6; because in IPv6, each individual internet connection could potentially have their own /64 for individual devices within the local network, simply munging the final octet might not be adequate, I'm thinking).

Worth noting generally, that anonymizing/pseudonymizing IPs might be incompatible with CIDRAM's "IP tracking" feature (more a thing pertinent to "modules" anyway, and not required for basic IP blocking), and therefore incompatible with the somewhat more complex features relying on it, so, users using such an option in CIDRAM to anonymize/pseudonymize IPs, would probably need to disable IP tracking too (and might be worth adding some note about it to the documentation). That said though, anonymizing/pseudonymizing IPs shouldn't cause any problem for core functionality (reading signature files, blocking requests from IPs that match one or more signatures, etc), and sounds like a good idea, I think. Edit: Actually, it doesn't conflict with IP tracking at all, so I've struck out that part of my message. Easy enough to keep it all separate (from a technical perspective). Might still want to disable it from a legal perspective though.

Any thoughts (from the perspective of changes necessary to current logging implementation in CIDRAM) regarding what would be the best approach to encryption?

[ghost]

In regards to the global scope of data retention Vs privacy, the settings should of course be selectable so the end user can adjust according to local regulations.

We need some different options about logging, and what is even more important, we need a transparent and clear explanation of exactly what is logged, how long, and what the usage is - for each alternative provided.

As muddy as the GDPR is written, it is clear that end user transparency is essential and top on the list.

[horninc]

GDPR in essence and in spirit does not have a problem with storage and processing of IP address for legitimate security purposes. It is in no way intended to prevent the "free flow of information".

It does, however, no matter what the justification, necessitates Controller to inform the data subject that the IP address is collected and processed. That also in its essence is not a big problem for CIDRAM itself.

The only thing were tools like CIDRAM and GDPR really rub shoulders, in essence, is the length of retention of that IP address.

My proposal would be that there is a distinction between different phases, such a the prime phase where system would have the full address for the time it is necessary for it to effectively fulfill its purpose, with the soft threshold (say 72 hours) after which it can automatically pseudonymize the address as described above, and then furthermore a hard threshold after which the IP address would be removed from the system, or stored permanently in an anonymized form.

Then the admins themselves can choose what thresholds they want to use for what, and how to properly communicate it to the data subjects.

[soumsps]

reCaptcha logs still contains original IPs ..when pseudonymising IP addresses is activated... Is that intentional?

[Maikuolan]

Definitely not intentional (option to pseudonymise IP addresses should apply to all logs). I'll check on that now and reply shortly.

[Maikuolan]

@soumsps Cheers for reporting this. Problem found and fixed. :+1:

[Maikuolan]

(BTW, I've made a start on the relevant legal documentation for the project. I haven't quite written enough yet for it to be worth reviewing or committing, but I should be at that point reasonably soon, if anyone would be willing to take a look at it to review it and give some feedback when I get to that point).

[soumsps]

I am willing to look at it...

[Dibbyo456]

What if I don’t want to allow any users from EU?

A on/off option (like country blocking) would also be nice for some of cidram who intends to block whole EU.

[DanielRuf]

What if I don’t want to allow any users from EU?

That won't help. An EU resident can be anywhere in the world. How do you know if he is European or not and if he is just traveling?

[Dibbyo456]

That won't help. An EU resident can be anywhere in the world. How do you know if he is European or not and if he is just traveling?

Then why some companies totally blocking EU to avoid GDPR? - Source.

[horninc]

Then why some companies totally blocking EU to avoid GDPR?

Because they do not know better and are acting on the basis of misinformation and bad advice.

In terms of the scope of Regulation, you cannot discount its application if you already hold personal information of EU individuals incl. IP address.

If the company would delete completely all EU personal information from its systems, or completely anonymize this information prior to 25th of May, and then block all EU traffic, you maybe might have an argument here.

In most cases, and in the source you have provided, the only step taken is blocking EU countries. That does not solve the problem with existing data for which you need to comply with the data subjects rights and the obligations as controller and processor, nor does it solve the problem of the new trends such as VPN or IP privacy options used by networks such as 1.1.1.1

As such simply blocking existing customers is much more likely to gather DPA attention and claims from individuals than simply updating Privacy policy and being transparent.

I do not believe blocking traffic would in any way exclude you from applicability of GDPR unless you would take other measures into account too.

[horninc]

To further add to the argument.

Many companies can escape the scope because they simply do not cater to EU customers. That is actually relatively easy to do and achieve, and can be easily demonstrated with balancing.

A webshop in California selling skateboards, albeit in English and without any geo-restrictions will not need to comply with the Regulation because they "did not have any intention to sell to EU". It is extremely improbable that DPA will ever go after such a company even if they manage to sell to EU, as long as a few minor requests by individuals are (such as request to delete personal data) are honored within reason (you do not need to delete invoices and other data you need to legally keep to comply with the national laws).

On the other side of the spectrum. If the same shop offers Bulgarian and Latvian language options (catering to EU market), allows you to pay in EUR and offer delivery options to EU countries with specific options not related to USA market (intention to do business with EU), than even 1 sale to EU might trigger GDPR obligation, and it will then be very very difficult to prove to a DPA, that you should not comply with the GDPR.

I am simply trying to illustrate that geo-blocking in these contexts make much less sense since anyone with VPN or IP address obscured by any other technical means could still clearly see that you did intend to do business in EU.

[Maikuolan]

__New documentation written thus far (pending review):__

• 11.0 SECTION PREAMBLE
• 11.1 LIABILITY AND RESPONSIBILITY
• 11.2 THIRD PARTIES
• 11.2.0 HOSTNAME LOOKUP
• 11.2.1 WEBFONTS
• 11.2.2 SEARCH ENGINE VERIFICATION
• 11.2.3 GOOGLE reCAPTCHA
• 11.2.4 STOP FORUM SPAM
• 11.3 LOGGING
• 11.3.0 BLOCK EVENTS
• 11.3.1 reCAPTCHA LOGGING
• 11.3.2 FRONT-END LOGGING
• 11.3.3 LOG ROTATION
• 11.3.4 LOG TRUNCATION
• 11.3.5 IP ADDRESS PSEUDONYMISATION
• 11.3.6 OMITTING LOG INFORMATION
• 11.3.7 STATISTICS
• 11.3.8 ENCRYPTION
• 11.4 COOKIES
• 11.5 MARKETING AND ADVERTISING
• 11.6 PRIVACY POLICY

__Not yet written (plan to finish this either today or tomorrow):__

• Actual, specific information relating to GDPR/DSGVO (only one small reference to the new regulations has been made thus far in the newly written documentation), with links to relevant information (official documentation, downloadable PDFs, etc), possibly with some key points worth mentioning (who the regulations actually apply to, notable exemptions, etc).
• Where the package stands in the context of "data processors", "data controllers", etc.
• Maybe peripheral information (not sure yet; might leave this out; depends on what information I can actually find, and how reliable it is), such as similar laws elsewhere, what bearing GDPR/DSGVO might have on similar (or different, contradictory) laws elsewhere.

No point sending review requests until after everything is finished (because new commits would technically void any already completed reviews anyway), but feedback/suggestions would be welcome at any time.

Link: https://github.com/CIDRAM/CIDRAM/blob/legal-wip/_docs/readme.en.md#11-legal-information

Note: Above link points to a temporary branch that I've created, in order to be able to get the changes reviewed via a PR prior to syncing anything to the master branch. Temporary branch will be deleted after the PR gets merged, so, above link may return 404 in the future.

[Maikuolan]

"11.7 GDPR/DSGVO" added.

Might skip out on the other points not yet covered for now (such as comparisons between different regulations and such, explicitly stating where we stand with "data controllers" and "data processors", etc) due to time constraints (somewhat less important elements than those already covered, and users can probably figure it out for themselves if they need to anyway, by reading the EUR-Lex docs, googling, etc).

Will send review requests now. :-)

(Edit:) Actually can't send specific review requests to people unless they've joined as members of the organisation, so, I'll need to send organisation invitations first, I think. '^.^

Alternatively, could always just thumbs up :+1: or thumbs down :-1: on the PR though, or comment feedback directly, I guess (no restrictions there, and anyone can do that).

[soumsps]

Seems fine to me... :+1:

[Maikuolan]

Thanks for reviewing. 😊 :+1:

Hoping to tag a new release not later than the 25th if possible, so, unless anyone can spot any problems, or think of anything that needs to be changed in the documentation currently, I'll prepare a new tagged at some point between now and early tomorrow morning (and of course, as always, refinements can be made over time anyway, so if we find any problems, or things which should be changed at a later point, no problem; we'll get to those things too at some point for whatever releases come afterwards).

[soumsps]

In my privacy policy. I have mentioned that "This site is protected from spammers and malicious activity by CIDRAM firewall." and in Data Retention segment "CIDRAM generate log files with pseodnomised IPs which is stored on server for 7 days for monitoring purpose" Although I know logged IPs will be mostly non-human access point.

I feel like this much transparency is sufficient for stupid law . What do you say @Maikuolan ?

[Maikuolan]

Lawful basis and purpose (maintaining website security and preventing unwanted traffic) + transparency (documenting what happens, and why) = Should be sufficient, I think. :+1:

[Maikuolan]

PR merged. Closing.