GDPR discussion thread

Something that came across my path that raises a question for developers @Mike when someone visits a site (XF installation of course) are cookies deposited on that visitors device 'before' the cookie notice is displayed? And if they are, do they remain if a visitor decides not to say OK to cookies, or simply carries on browsing? Is there also a means for a visitor to remove said cookies if they decide they don't want them on their device?

This is all pertaining to the 'opt in' and the 'right to be forgotten' sections of the GDPR. It's something that needs to be addressed from a software development action - so, will XF be updated to reflect these opt in and right to be forgotten sections of the GDPR?

Sorry to be appearing to be picking at a carcass, but these are important aspects of the GDPR for which we have no control over at present. Yes, I know that visitors can make adjustments to their browser with regards to cookies, but that is a different choice that comes 'after' the fact.

;)
 
Blimey. They are *so* different. It's all about the wording. The Xenforo wording is factual/business like. Pintrest wording is way more personal in nature. Much more likely to engender support and cooperation in my opinion.

Snapchat updated their TOS in 2017 with a more readable format and promoted that fact. It's still pretty comprehensive, but it's readable

https://www.snap.com/en-GB/terms/

They also have a good little community guidelines section, most of which would carry over to a forum community without much modification.

https://support.snapchat.com/en-GB/a/guidelines
 
This is all pertaining to the 'opt in' and the 'right to be forgotten' sections of the GDPR. It's something that needs to be addressed from a software development action - so, will XF be updated to reflect these opt in and right to be forgotten sections of the GDPR?

My statement still stands that a default XenForo (1 or 2) install will meet the GDPR requirements for most sites. There may just be an expanding of some T+Cs or a default cookie description page added, but that would be about it.

It will be down to the owner to identify if they are expanding outside of the scope of a default install and implement the required GDPR policies.
 
The reason I raised this question about cookies being dropped before consent to accept cookies is given was through reading this:

Not all cookies are used in a way that could identify users, but the majority are and will be subject to the GDPR. This includes cookies for analytics, advertising and functional services, such as survey and chat tools.
To become compliant, organisations will need to either stop collecting the offending cookies or find a lawful ground to collect and process that data. Most organisations rely on consent (either implied or opt-out), but the GDPR’s strengthened requirements mean it will be much harder to obtain legal consent. The consequences of this were discussed during the 2016 Data Protection Compliance Conference and its findings described by Cookie Law:
  • Implied consent is no longer sufficient. Consent must be given through a clear affirmative action, such as clicking an opt-in box or choosing settings or preferences on a settings menu. Simply visiting a site doesn’t count as consent.
  • ‘By using this site, you accept cookies’ messages are also not sufficientfor the same reasons. If there is no genuine and free choice, then there is no valid consent. You must make it possible to both accept or reject cookies. This means:
  • It must be as easy to withdraw consent as it is to give it. If organisations want to tell people to block cookies if they don’t give their consent, they must make them accept cookies first.
  • Sites will need to provide an opt-out option. Even after getting valid consent, sites must give people the option to change their mind. If you ask for consent through opt-in boxes in a settings menu, users must always be able to return to that menu to adjust their preferences.
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.”

More can be read on this by visiting: https://www.itgovernance.eu/blog/en/how-the-gdpr-affects-cookie-policies/

So, based on this (if it is correct, and there's no reason to imply that it isn't) that is my question - are cookies dropped before consent to accept them is given by the XF (and every other) software?

;)
 
More can be read on this by visiting: https://www.itgovernance.eu/blog/en/how-the-gdpr-affects-cookie-policies/

So, based on this (if it is correct, and there's no reason to imply that it isn't)
;)

That link makes some dubious claims which directly contradict what the ICO told me this morning (I spend several hours discussing specific points with them, and cookies were included).

Given their website is geared towards selling you a course, take it with a pinch of salt.
 
Snapchat updated their TOS in 2017 with a more readable format and promoted that fact. It's still pretty comprehensive, but it's readable

https://www.snap.com/en-GB/terms/

They also have a good little community guidelines section, most of which would carry over to a forum community without much modification.

https://support.snapchat.com/en-GB/a/guidelines
How about if someone asks you to download his data for his account on your forum?

Like Snapchat has it here: https://support.snapchat.com/en-GB/article/download-my-data
 
@Slavik thanks for taking the time to talk with the ICO to attempt to clarify points being raised; however having just visited the ICO site and reading their Cookie Guidance Policy (which is based on The Privacy and Electronic Communications (EC Directive) Regulations 2003) they have this to say I've put the parts that relate to my earlier question in bold.

‘Prior’ consent. It has been suggested that the fact the Regulations do not specifically refer to ‘prior’ consent suggests that consent can be obtained after the activity consent is needed for has occurred (in this instance after the cookie has been set).

It is difficult to see that a good argument could be made that agreement to an action could be obtained after the activity the agreement is needed for has already occurred. This is not the generally accepted way in which consent works in other areas, and is not what users will expect. Setting cookies before users have had the opportunity to look at the information provided about cookies, and make a choice about those cookies, is likely to lead to compliance problems. The Information Commissioner does however recognise that currently many websites set cookies as soon as a user accesses the site. This makes obtaining consent before the cookie is set difficult. Wherever possible the setting of cookies should be delayed until users have had the opportunity to understand what cookies are being used and make their choice. Where this is not possible at present websites should be able to demonstrate that they are doing as much as possible to reduce the amount of time before the user receives information about cookies and is provided with options. A key point here is ensuring that the information you provide is not just clear and comprehensive but also readily available.

You should also consider whether users who might make a one-off visit to your site would have a persistent cookie set on their device. If this is the case, you could mitigate any risk that they would object to this by shortening the lifespan of these cookies or, where possible given the purpose for using them, making them session cookies.

Link to the document: https://ico.org.uk/media/for-organisations/documents/1545/cookies_guidance.pdf

So, the information you have gleaned from the ICO, is this based on 2003 directive mentioned above, or on the new regulations within the GDPR which is not yet law until May 28th? With thanks.

:)
 
or on the new regulations within the GDPR which is not yet law until May 28th

Everything we discussed was directly related to the GDPR.

There are exemptions to various types of cookies, and just visiting a default xenforo, should fall under those exemptions (though ive been working on a different thing this afternoon so will need to double check)
 
Not to sound glib about a serious law, but as mentioned by posters earlier in this thread, the wording is designed to catch companies who misuse your data, not a hobby site (or even a small-time addon developer / eCommerce site) using forum login cookies and Google Analytics / Google AdSense.

Not to say that it's perfectly fine ignoring this law, or that XF shouldn't add better cookie consent functionality in 2.1, but I would be pretty shocked if anyone currently registered on this forum would face any form of consequences for simply carrying on with their existing cookie notices and existing privacy policies.

Assuming no-one registered on this site is actually doing anything as dodgy as FB with their Cambridge Analytica nonsense, that is :P


Fillip
 
Assuming no-one registered on this site is actually doing anything as dodgy as FB with their Cambridge Analytica nonsense, that is :p

Yeah, and whatever you do, don't go storing the passwords from failed login attempts so that you can later check the logs and use those passwords to hack other online accounts of your users.

Now, who would go and do something like that? 🤔

Mark Zuckerberg was not content to wait until the morning to find out if the Crimson would include John's accusations in its story.

Instead, he decided to access the email accounts of Crimson editors and review their emails. How did he do this? Here's how Mark described his hack to a friend:

Mark used his site, TheFacebook.com, to look up members of the site who identified themselves as members of the Crimson. Then he examined a log of failed logins to see if any of the Crimson members had ever entered an incorrect password into TheFacebook.com. If the cases in which they had entered failed logins, Mark tried to use them to access the Crimson members' Harvard email accounts. He successfully accessed two of them.

In other words, Mark appears to have used private login data from TheFacebook to hack into the separate email accounts of some TheFacebook users.
 
Not to sound glib about a serious law, but as mentioned by posters earlier in this thread, the wording is designed to catch companies who misuse your data, not a hobby site (or even a small-time addon developer / eCommerce site) using forum login cookies and Google Analytics / Google AdSense.

It's not unreasonable to assume this, the GDPR came into existence due to the huge data breaches that have occurred previously (and more so recently) that have affected millions of people and is aimed at making big companies accountable for their actions and to toe-the-line, as it were. However, that does not preclude any group or excuse anyone for ignoring the law as it is written. We all 'bend' the rules at some time, as far as we are able, not wishing to break them, but that's a matter for each person to decide for themselves how far they will go.

The EU are extremely good at over-complicating issues, even going as far as to contradict themselves and failing to meet their own standards. As law abiding citizens we want to be seen to be doing the right thing, not just to comply with the law, but to protect those who visit and join our sites and give them the confidence to do so; we are not like FB or Twitter or any other named player. Armed with the right information and the right tools we can be 'seen' to be doing the right thing. And that will, hopefully, send a signal out to the big players out there, that if we, the little and often unseen guys can do it, they can do it; more so them with the resources and money at their disposal.

It's about doing the right thing.

;)
 
That link makes some dubious claims which directly contradict what the ICO told me this morning (I spend several hours discussing specific points with them, and cookies were included).

Given their website is geared towards selling you a course, take it with a pinch of salt.

The GDPR: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN

Specifically points 30 and 32 here:

30 said:
Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. 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.

32 said:
Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject's acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject's consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided.

30 implies that cookies that act as identifiers of some sort constitute as personal data. 32 shows that clear, unambiguous consent is required to process personal data.

I don't know to what extent that applies or if other clauses apply specifically to cookies, but these two would imply that more direct consent is required. IANAL, so...

The EU are extremely good at over-complicating issues, even going as far as to contradict themselves and failing to meet their own standards.
They get a bad rep in the media, tbh. Some parts of it are a mess but their directives (especially the more major ones, e.g. this, VAT-related directives, etc.) are honestly very clear. The data available to forum owners is honestly pretty limited, and forum owners were never the target of the GDPR.

And that will, hopefully, send a signal out to the big players out there, that if we, the little and often unseen guys can do it, they can do it; more so them with the resources and money at their disposal.
Not sure why you think they are physically unable to treat customer data with more respect. Data is money, a lot of large tech corps make the majority of their income from ad income still for one. I mean, your statement really doesn't make any sense to me.
 
The data available to forum owners is honestly pretty limited, and forum owners were never the target of the GDPR

The first part I agree with totally, the information for forum owners is extremely limited, also the information can often be contradictory. The second part I agree with too, but only to the point that forum owners were never the intended target, but the law does not distinguish between large and small where personally identifiable date is concerned. Depending on the size of the forum could possibly be guideline - 20 people's data may be too small to act upon (I say 'may', but you can never be too sure), but 5,000 people's data may not be out of their sites. It's these grey areas that need addressing as to at what point is a data breach considered serious enough to warrant action by the ICO?

Not sure why you think they are physically unable to treat customer data with more respect.

I believe that the past and current major data breaches speak volumes in this respect. They have the resources, the staff and the money to put into place the necessary protection, but they didn't. Yet, here we are, small people (by comparison) attempting to make some headway in trying to do the right thing with extremely limited budgets, probably only one or two people to action what is needed, who probably have full time jobs and practically no real viable resources to call upon to put into practice what's needed. I think that also speaks volumes in our favour. ;)
 
In the past I've rewarded donators be sending them military-style patches through the mail.

These members sent me their mailing addresses in private conversations. I'd like to remove the address information from my database because I don't want to hang on to personally identifiable information..

However, conversations are not searchable in default XF 1.5 and they cannot be deleted either (you can only leave them).

If we had better conversation tools this would immensely help me comply with the GDPR.

So this is me asking the XF team to make improvements on the conversations front in XF2. We need built-in search and deletion tools there, at a minimum. Having the full set of normal moderation abilities (locks, threadban, etc.) for conversations would be amazing.
 
The thing that concerns me about simply deleting user accounts (and forgive me if I've missed it elsewhere) is that this functionality, whilst it presumably does much of what the law requires, is something of a blunt instrument, and it may in fact do more than is necessary.

For one example, if we are not deleting posts - but we do delete the account - then the connection between those posts (so, other posts by this user account) is broken. This type of detail - insufficient to identify anything of the individual themselves - may well, I suspect, be outside the scope of the new rules, yet may be useful after the user has left. (We have a live case at the moment where an individual is threatening another member. It's a long story, but the important part is that in one post, followed by a conversation, he conspires to obtain the address - and then in another, he threatens to visit that address. I believe, if he were deleted, we'd lose the ability to connect these two events.)

I have to question whether, rather than deletion, complete anonymisation of a user account is actually sufficient - and would be a better approach. I'm not in a position of enough knowledge to propose a full scope of such a scheme, but presumably, replacement of the User Name with (say) the account number, and removal or replacement of the EMail address would be key elements. Is there actually any need for more?
 
The thing that concerns me about simply deleting user accounts (and forgive me if I've missed it elsewhere) is that this functionality, whilst it presumably does much of what the law requires, is something of a blunt instrument, and it may in fact do more than is necessary.

For one example, if we are not deleting posts - but we do delete the account - then the connection between those posts (so, other posts by this user account) is broken. This type of detail - insufficient to identify anything of the individual themselves - may well, I suspect, be outside the scope of the new rules, yet may be useful after the user has left. (We have a live case at the moment where an individual is threatening another member. It's a long story, but the important part is that in one post, followed by a conversation, he conspires to obtain the address - and then in another, he threatens to visit that address. I believe, if he were deleted, we'd lose the ability to connect these two events.)

I have to question whether, rather than deletion, complete anonymisation of a user account is actually sufficient - and would be a better approach. I'm not in a position of enough knowledge to propose a full scope of such a scheme, but presumably, replacement of the User Name with (say) the account number, and removal or replacement of the EMail address would be key elements. Is there actually any need for more?

I have verified the deletion of accounts can be avoided all together (you can deny requests) with a lovely little loophole the ICO provided me.
 
I have to question whether, rather than deletion, complete anonymisation of a user account is actually sufficient - and would be a better approach. I'm not in a position of enough knowledge to propose a full scope of such a scheme, but presumably, replacement of the User Name with (say) the account number, and removal or replacement of the EMail address would be key elements. Is there actually any need for more?

In the past few years I've started taking this approach myself - mostly in response to the spate of website hacking and subsequent publication of user databases.

My policy is that if someone has posted 5 or fewer times, I'll simply delete their account - there is no value in keeping it (other than the vanity of showing a higher user count for my site).

However, if they have posted more, I will instead "anonymise" their account by changing their username to their numeric userid and then changing their email address to my webmaster address with the userid in it (eg: webmaster+userid@example.com) - but could use any email address which comes to me.

So my own XenForo account https://xenforo.com/community/members/sim.4264/ would have a username of 4264 and an email address of webmaster+4264@example.com

I assign the user to a restricted usergroup and mark their account as having bounced email (overkill, but handy to ensure I don't get emails).

This approach doesn't clean any content - I deal with that on a case-by-case basis if they request further anonymisation and highlight specific posts which contain information they want removed. I never bulk-remove content and insist they do the legwork to locate problematic content.

Removal of their private conversations would be useful too - I haven't really addressed that yet.
 
Deleting a user account and the content they added can be done, but how do you export all user data and content and send that to them?

Good point. This is where the software needs to be changed to accommodate the new GDPR rules; the tools that we need are not sufficient at present, so some adjustments to the software are required that we cannot do ourselves; it's also not to be harvested out to a third party either, these are tools that need to be core.

An easier way to anonymise users without having to jump over hurdles
An easy way to provide all user content if they ask for it - portability rule would apply here
An easy way to ensure that PCs are deleted after anonymising - with the ability to allow the user to retrieve all PCs before anonymising takes place
An easy way to download log files associated with that member so they can be kept as evidence should the need arise to prove what actions took place whilst that person was a member, so freeing up database space
An easy way to request explicit permission to show linked data (e.g. YT videos) before they are shown and likewise withdraw permission if they change their mind
An easier way to get permission to accept cookies before they are dropped and a means for a person to request those cookies be removed

All of these would make life easier for site owners and help to keep them on the right side of the GDPR.

@Slavik whilst it's very much appreciated for the amount of time you spend in conversation with the ICO and collating all that they say, do you have what they say in writing? If not, then I would be wary because some of what you have been told in a telephone conversation is contrary to what they have in published form at present and will also be included in the GDPR but with more detail.

As always, when these rules and regulations are imposed there appears to be little thought given by the rule makers as to how people are supposed to implement them and at what cost; and, whether they can be implemented and executed without undue hindrance, as they say they have to, for those they are supposed to protect.

Let's keep digging, the hole is getting deeper lol.

:eek:
 
Back
Top Bottom