GDPR requirements, translation errors and others

[OttokarDomma]

My list of few bugs and minor improvements.

1.
Deleting user account does not comply with the requirements of the GDPR. In according to the conditions of the GDPR, the users ip must be deleted too.
Extend the code in Subs-Members.php beginning in line 131 after "// Make these peoples' posts guest posts." solved this.

Code Select Expand

// Make these peoples' posts guest posts.
$smcFunc['db_query']('', '
UPDATE {db_prefix}messages
SET id_member = {int:guest_id}' . (!empty($modSettings['deleteMembersRemovesEmail']) ? ',
poster_email = {string:blank_email}' : '') . ',
poster_ip = {string:blank_ip}
WHERE id_member IN ({array_int:users})',
array(
'guest_id' => 0,
'blank_email' => '',
'blank_ip' => '',
'users' => $users,
)
);


2.
To show the statistic from a specific user to any other is not allowed in according to the GDPR without agreement.
Change the permissions for the user statistic in the Profile.php for 'any' from 'profile_view' to 'view_stats' solved this and and merges the permissions for viewing statistics.
To cleaning up this, insert

Code Select Expand

$context['show_stats'] = allowedTo('view_stats');
in the Profile.php after "// Do some cleaning ready for the menu function."
and add the permissions in the Profile.template.php too:

Code Select Expand

if ($context['user']['is_owner'] || $context['show_stats'])
echo '
<a href="', $scripturl, '?action=profile;area=statistics;u=', $context['id_member'], '" class="infolinks">', $txt['statPanel'], '</a>';


3.
Some translation errors.

index.german.php

Code Select Expand

$txt['mc_reported_posts'] = 'Es sind momentan %1$d gemeldete Beiträge offen.'; must be changed to

Code Select Expand

$txt['mc_reported_posts'] = 'gemeldete Beiträge';

Code Select Expand

$txt['report_to_mod_func'] = 'Benutzen Sie diese Funktion, um Moderatoren/Administratoren über einen missbräuchlich oder falsch geschriebenen Beitrag zu informieren.<br /><em>Bitte beachten Sie, dass Ihre E-Mail-Adresse zum betreffenden Moderator gesendet wird, wenn Sie diese Funktion benutzen.</em>';must be changed to

Code Select Expand

$txt['report_to_mod_func'] = 'Benutzen Sie diese Funktion, um Moderatoren/Administratoren über einen missbräuchlich oder falsch geschriebenen Beitrag zu informieren.';because there is no users email address in the message.

Profile.german.php

Code Select Expand

$txt['showMessages'] = 'Benachrichtigungen';must be changed to

Code Select Expand

$txt['showMessages'] = 'Beiträge';

4.
Underlined links in the small news section above looks horrable and is confusing.
This litte code in the index.css solved this for a cleaner look.

Code Select Expand

.news .bbc_link {
border-bottom: none;
}
.news .bbc_link:hover {
text-decoration: none;
border-bottom: 1px solid #346;
}

5.
All bbc links are opened in new tabs, all internal bbc links too, but why? It's absolutely impractical.
Internal bbc links should be opened in the same tab, this is more handy and comfortable.
That will be done with this little script as workaround until it's fixed.

Code Select Expand

<script type="text/javascript"><!-- // --><![CDATA[
window.onload = function OpenLocaleBbcLinksInSelfWindow() {
var tags = document.getElementsByClassName("bbc_link");
for(var i = 0; i < tags.length; i++) {
if (~tags[i].href.indexOf(window.location.hostname) && tags[i].target === "_blank")
tags[i].target = "_self";
}
}
// ]]></script>
Place it in the index.template.php after:

Code Select Expand

// Load in any javascipt that could be deferred to the end of the page
template_javascript(true);

echo '

6.
The use of verification questions for spam protection causes an "Trying to access array offset on value of type null" error, if the answer fields are empty.

[Aleksi "Lex" Kilpinen]

1) This isn't really a clear case at all. Firstly, if IP alone is to be considered identifiable is a question on it's own, and secondly if you keep user submitted content, you do also have a legal reason to keep some identifying information connected to those posts to protect yourself. If you remove the posts, you remove the IP addresses as well.

2) Now this is just a ridiculously strict interpretation, one that I would really like to hear some explanation to - What do you base this claim on?

3) @Matthias @m4z - I think you two had something to say on this?

4) Haven't noticed. But this is a theme specific thing.

5) Because there are 2 types link BBC. Url and iurl are separate.

6) Where and when exactly?

Also, for future - Would be easier if we could handle one thing at a time.

[Arantor]

1) The GDPR does not say that. In fact there is a pretty good argument for keeping IP addresses for a period even after an account has been deleted to deal with people who cause trouble, demand deletion (presuming it includes IP address) only to come back to cause trouble.

As long as you have a policy to this effect, it's completely fine within the GDPR. I personally changed it around to delete after 90 days.

2) No, aggregation of overall stats is fine under the GDPR (e.g. stats per board) because that's not personally identifiable in itself. As for the stats showing positions of posts, this is also fine too because the reality is the numbers show information that is otherwise available: you can see from the stats that I am the most prevalent poster on this forum. This is information you could glean in other ways and merely collating what is otherwise available is not a violation.

3) No comment; I don't speak German.

4) Point of aesthetics; different people have different views.

5) There is an argument that a url (external bbcode) should default to becoming iurl (internal bbcode) if the link is internal. There is also the argument that no link should open in a new tab and that it should be the user's choice. All of these interpretations are valid, as is SMF's default behaviour. Mods do exist to alter this - but it isn't a bug, and 'fixing it' with JavaScript definitely is a poor solution.

6) That might be a legitimate bug.

[albertlast]

about 1) blank is not a valid ip address,
so this solution needs to be different when needed.

[OttokarDomma]

1)
EuGH had noticed that already 2016:
hxxp:curia.europa.eu/juris/document/document.jsf?text=&docid=186141&pageIndex=0&doclang=DE&mode=lst&dir=&occ=first&part=1&cid=607569 [nonactive]

2)

This is information you could glean in other ways and merely collating what is otherwise available is not a violation.

You are wrong. The merging of data stored at different locations may be a violation under circumstance.
Results the data merging into individual identification features and if you can create an individual profile, there is a violation. The user stats allow for just that.

5)

5) Because there are 2 types link BBC. Url and iurl are separate.

Never seen/known before, thanks.

6)

6) Where and when exactly?

I will check this.

[Aleksi "Lex" Kilpinen]

1) IP addresses are removed if and when all user provided content is removed, until then you do actually hold a legal reason (in some cases an obligation) to keep the IP (and in some cases even more) as well. This comes down to having a proper policy in place.

2) Merging of data stored at different locations may be a violation, but in this case the data is NOT stored in different locations to begin with. It's simply data that is presented in a different way, but from the same location. If someone else were to take that data and combine it with data from another source, that could be a violation, where we would still have done nothing wrong.

[Arantor]

2) Nonsense. What you're suggesting is that users can't look at forum threads, see the count of posts, and make a list of them themselves? Because that's all the stats page is doing. Ditto for topics started, most likes and so on. This is information a third party could quite possibly obtain for themselves and gather without any of the repercussions you are talking about.

I guess we need to remove post counts, likes and so on then, because the stats page is not doing anything a regular user couldn't do for themselves, for those stats anyway.

Better also remove the memberlist while you're at it because that reports on the number of posts a member has.

Or, you know, not. I can't speak to the specific wording that Germany may have implemented, but neither the base GDPR wording nor the UK wording (which I have read since I am in the UK) has anything on preventing the kinds of statistics that SMF returns. I even spoke to our regulatory body at length about it, as did some of the other forum platforms.

[OttokarDomma]

1) IP addresses are removed if and when all user provided content is removed

But that's not enough, the ip must already be deleted when the user account is deleted.
The deletion of the account results the revocation of all consent to data collection.

2) Merging of data stored at different locations may be a violation, but in this case the data is NOT stored in different locations

Different locations in data protection do not mean different server, countrys, databases or so. It means different places of finding, and they can also be stored on the same server, even in the same database, but in different datasets.
The problem is the output of the data in a merged view and what can to do with it.

2) Nonsense.

Nonsense, ha?
The opinion of a data protection person is not law and does not protect against lawsuits.
With the user stat you can create an individual profile of user behavior, this is always a violation.

[Aleksi "Lex" Kilpinen]

1) IP addresses are removed if and when all user provided content is removed

But that's not enough, the ip must already be deleted when the user account is deleted.
The deletion of the account results the revocation of all consent to data collection.

But you do understand that GDPR has other valid reasons too, you do not need consent when you have a different legal reason. In fact, consent very rarely comes in to play.
https://gdpr.eu/gdpr-consent-requirements/

2) Merging of data stored at different locations may be a violation, but in this case the data is NOT stored in different locations

Different locations in data protection do not mean different server, countrys, databases or so. It means different places of discovery, and they can also be stored on the same server, even in the same database, but in different datasets.

No. The data is not PI, it is not from different datasets, it is numbers from the _same_ dataset as all the other contents.

With the user stat you can create an individual profile of user behavior, this is always a violation.

Also no. That something can be used for something, is never a violation. That something IS used, can be a violation.

[Arantor]

But that's not enough, the ip must already be deleted when the user account is deleted.
The deletion of the account results the revocation of all consent to data collection.

No, they don't. Because it has long been established that scrubbing backups is not a viable requirement in practice. This is why retention periods should be defined in the policy and consented to when users sign up.

You can additionally make the argument (and I have to our data regulator here in the UK) that you need to keep IP addresses for a period to ensure the integrity of the system against abusers.

The key here is to write it into your policy that you will hold such data, why you hold such data and where appropriate how you intend to ensure data from deleted users does not re-enter the system during the retention period.

The opinion of a data protection person is not law and does not protect against lawsuits

Sorry but I will take the advice given to me by my country's data protection regulator over that of a random person on the internet.

With the user stat you can create an individual profile of user behavior, this is always a violation.

That's not how it works, no.

The stats will tell you that I have made 74,446 posts prior to this point. They will tell you that I have the most posts of anyone on the site. What, exactly, do these two facts tell you about my behaviour? Other than that I have clearly spent a lot of time here, there is nothing you can profile about this.

Even if you include the most liked posts into the mix, this also doesn't really tell you anything, because any individual with sufficiently many posts will likely attract a proportionately higher amount of likes.

Aggregate data is something expressly pointed out in the directive, and aggregating things that aren't even PII (post count certainly isn't, neither is number of topics started, nor really is the estimate of time online) and it's not being used for profiling by the platform or automated decision making.

Individual sites may do something with this (e.g. post count based rules) but this is still well within the bounds of what is covered. And the core is not in violation at this point, assuming configured appropriately which is not within the bounds of what is required; the features exist and can be used, correctness of configuration is at the site owner's liability.

[Aleksi "Lex" Kilpinen]

Honestly, I would never ever justify IP-address or hostname storing and handling with consent. On most webservers, they ARE gathered consent or not. And what does not require consent, can be kept without consent, as long as there is a legal basis for it.

[Arantor]

Neither would I, but there you go.

I'm not yet intrigued enough to go investigate what Woltlab Burning Board does, seeing how it's written by a team in Germany and sold primarily through a German-based company.

[albertlast]

ip address is the same like firstname and lastname,
in context of gdpr.

[Aleksi "Lex" Kilpinen]

ip address is the same like firstname and lastname,
in context of gdpr.

Eh, not quite - Similarly treated yes, but still this is irrelevant to the discussion.
What is relevant is not exactly what is kept, but why and how. To obtain and store a full name, in the context of SMF the user would need to provide it and give consent to storing it, consent which could then be revoked. To obtain and store an IP address, a user only needs to access the page and for technical reasons the address is already stored, no consent involved, no consent revokable.

[Shades.]

Since the definition includes "any information," one must assume that the term "personal data" should be as broadly interpreted as possible. This is also suggested in case law of the European Court of Justice, which also considers less explicit information, such as recordings of work times which include information about the time when an employee begins and ends his work day, as well as breaks or times which do not fall in work time, as personal data. Also, written answers from a candidate during a test and any remarks from the examiner regarding these answers are "personal data" if the candidate can be theoretically identified. The same also applies to IP addresses. If the controller has the legal option to oblige the provider to hand over additional information which enable him to identify the user behind the IP address, this is also personal data. In addition, one must note that personal data need not be objective. Subjective information such as opinions, judgements or estimates can be personal data. Thus, this includes an assessment of creditworthiness of a person or an estimate of work performance by an employer.

https://gdpr-info.eu/issues/personal-data/

[Aleksi "Lex" Kilpinen]

Like I said, irrelevant. To store and handle personally identifiable information, you DO NOT NEED consent.

[Arantor]

Be very careful with the assertions there - it is not lawful basis to keep IP addresses *just in case there is a requirement* to hand them over to police or other legal authorities. That particular wording covers against purposefully not keeping data in the hopes of evading justice, and/or whether the controller is suitably empowered to compel another to identify an individual: forum owners will almost never qualify for that distinction.

But Lex is right: consent (clause 6(1)(a)) is only one basis for retaining and processing data and there are several others. Let's look at them together.

Clause 6(1)(b) probably doesn't apply, unless you're purchasing something on a forum or engaging on a forum for support during an order. It would possibly come into play with some kinds of verification that you are the purchaser perhaps but it generally wouldn't.

Clause 6(1)(c) would give you coverage if you were engaging with a police operation around an investigation into an individual or individuals - sadly in my time with forums I have had to organise this with people who were later prosecuted for possession and distribution of very much illegal material. However this does not, as mentioned, give you the right to collect the data just in case of a police investigation becoming required.

Clause 6(1)(e) probably wouldn't come up for most forums, and I'd argue that in most cases (though certainly not all), 6(1)(d) wouldn't come up either. That said there are forums I have helped out on for things like abuse survivors where being able to keep certain people out can legitimately form the basis of protecting the vital interests of a data controller. But it normally wouldn't.

That leaves us with Clause 6(1)(f):

processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child

A site providing a service has a legitimate interest in keeping it secure both technically and socially, and banning people from the site absolutely qualifies; if a person coming to the site causes trouble repeatedly, this is impacting on the functioning of the service and it's really no great stretch to then argue that this is a legitimate interest on behalf of the controller - and that the protection of the individual in question is somewhat forfeit against an individual taking action to impinge upon the activities of others.

This does not mean you have carte blanche to hold IP addresses indefinitely but you absolutely can do so as long as you don't hold them longer than necessary and so on. My take on this was to define a retention policy and scrub them after 90 days because generally that's long enough.

As I said, a naive reading of the GDPR would imply that I could cause all manner of havoc, demand my data be removed, then come back and do it again. Moreover, it would not be looked upon favourably if the data were removed if later demanded by law enforcement; data removal just because the individual requests it is not an absolute, not in spirit or letter of the law.

[OttokarDomma]

Privacy data protection is hard to understand, so let me say it in other words (not nonsense).
(I asked a lawyer specializing in it and media law about this.)

The argument "collecting data that can also be found elsewhere in the forum is allowed" only applies to simple listing posts, topics and files, not to user statistic.
Because the user statistic is the merging and evaluation almost of all usage data (when, where, how, what, etc.), not a simple listing of found.
Merging and evaluating user data for statistics on individual user behavior is allowed for internal use only (Art. 6 (1)f GDPR).
To publish user statistic (show it to other users = transfer of data), the user's consent is required before (Art. 6 (1)a GDPR), or a contract to do just that (Art. 6 (1)b GDPR).
Without this, to show the user statistic is a violation.

Deleting the user account ends the contract, so is this legal basis for saving the IP address no longer applied (Art. 6 (1)b GDPR).
In addition, this also causes the revocation of the consent to data collection, so is also this legal basis for saving the IP address no longer applied (Art. 6 (1)a GDPR).
Without legal basis for saving the IP address, saving it's a violation.

You may or may not accept these facts here, but i advise every user in the EU to notice that, or it will cost you a lot of money.

[Aleksi "Lex" Kilpinen]

The argument "collecting data that can also be found elsewhere in the forum is allowed" only applies to simple listing posts, topics and files, not to user statistic.

What are the user statistics that you believe should not be shown? The statistics are in fact just simple listings of posts, topics and likes. Even the user activity is based on posting times. No new information is created or added to present the statistics.

To publish user statistic (show it to other users = transfer of data), the user's consent is required before (Art. 6 (1)a GDPR), or a contract to do just that (Art. 6 (1)b GDPR).
Without this, to show the user statistic is a violation.

I do not completely agree with your argument that to simply present data, is actually transferring data in the way that GDPR is concerned with. But for this, we have privacy policies and user agreements - You can only see statistics of a user account that exists, if you have permissions to access user profiles. Meaning you can either approach this through consent or through contract, or you can simply stop showing the statistics to anyone. The actual approach to this is up to you though, not to us.

Deleting the user account ends the contract, so is this legal basis for saving the IP address no longer applied (Art. 6 (1)b GDPR).

You do not need a contract, you do not need consent. You need a legal justification that can be your own legal interests.

In addition, this also causes the revocation of the consent to data collection, so is also this legal basis for saving the IP address no longer applied (Art. 6 (1)a GDPR).

You do not need consent. You need a legal justification that can be your own legal interests.
The secret is DO NOT ASK FOR CONSENT to keep data you do not need consent for.
Consent really should always be your last option, even if it actually is your easiest one to use.

I too live in the EU, I too run websites, and I also would like to remind everyone that the GDPR does not even directly concern you unless you are running a business.

[Sesquipedalian]

Simple Machines has legal professionals that we consult on relevant matters, and our implementation of GDPR complaint behaviour in SMF has been guided by that advice. Thank you for your attempts to help us, @OttokarDomma, but we will continue to rely on their advice.