About the GDPR
Dear users,
Many of you had questions about the GDPR and how to comply with this EU law about processing personal data of EU-citizens.
To make things easier for you, our next releases will include multiple features to help you with that.
The current list of features we are expecting to add to SMF is as follows:
- Data export, so users may (if you allow them to) export their profile data. (Profile including IP address(-history), posts (optional), personal messages (optional)). In the future, SMF might get an option to restore the basic profile of another site.
- Include unsubscribe links in newsletter emails if you set them to be marketing related (functional emails will remain being sent if someone opts out of marketing emails, depending on notification settings.)
- Opt-in checkbox for marketing emails during registration
- Force users to agree to new registration agreement, keep track of who consented and when they did, and the ability to see who have not agreed (yet).
- We are considering making it possible to show the privacy policy separate from the registration agreement during registration
- Show Privacy Policy link in the footer
- Ability to, when deleting a user/user has requested deletion of their data, check a box to remove IP-history from posts and anonymise their posts; which is to say their user/nickname is automatically changed to something other than what they registered with. Of course you still retain the ability to remove their posts as well. Even though this is not strictly required by GDPR if your policy checks out! (Note that you can already (pseudo-)anonymise their posts by first changing their nick before removing their profile, but we figured it would be nice to automate this in the future.)
- Extra prune functions, like expunging IP history for users as far as (technically) reasonably possible, to limit the amount of personal data you have on record. (Use with care.)
These functions will likely not all be introduced at once and some features will be expanded/improved with later updates.
We are aiming to get the basics introduced first (such as ability to add privacy policy, basic profile export, opt-out function for newsletters and forcing users to agree again to a (changed) registration agreement/privacy policy and log that). More features may be added later. If you think we forgot something, you may also post suggestions here - but please keep in mind that we are limited in time and resources. We have decided to implement these features in to SMF itself rather than releasing it as a modification (mod), so when you update SMF: these features will be available to you instantly.
The features will be optional for you to enable/disable, so if you do not want to use or activate them: that is possible.
We have been working hard on this and will release it as soon as possible. Our estimate is a release around the end of this month/begin of July, but please do not consider that a promise. Keep in mind that these tools are to help you with being/becoming GDPR-compliant, only activating them doesn't necessarily make you compliant. We advise you to read up on the laws and obtain legal advice if you are unsure whether or not you are compliant or have to be and what you should put in your privacy policy.
As for our own site, we will post a Privacy Policy soon to make it easier for you to see what we do with the very limited amount of data that you provide us with and information about what your rights are. And of course we will introduce the above features here as well as they will be included in SMF itself.
Last but not least, we apologize for the delay in introducing these features. Once we became aware of this new law, we wanted to get to the bottom of it and get some legal advice first. And as we are all volunteers: there are some time constraints as well. We are working very hard on it though and will release the features soon.
Thank you!
Kind regards, on behalf of;
- SMF Team
- Simple Machines
Many of you had questions about the GDPR and how to comply with this EU law about processing personal data of EU-citizens.
To make things easier for you, our next releases will include multiple features to help you with that.
The current list of features we are expecting to add to SMF is as follows:
- Data export, so users may (if you allow them to) export their profile data. (Profile including IP address(-history), posts (optional), personal messages (optional)). In the future, SMF might get an option to restore the basic profile of another site.
- Include unsubscribe links in newsletter emails if you set them to be marketing related (functional emails will remain being sent if someone opts out of marketing emails, depending on notification settings.)
- Opt-in checkbox for marketing emails during registration
- Force users to agree to new registration agreement, keep track of who consented and when they did, and the ability to see who have not agreed (yet).
- We are considering making it possible to show the privacy policy separate from the registration agreement during registration
- Show Privacy Policy link in the footer
- Ability to, when deleting a user/user has requested deletion of their data, check a box to remove IP-history from posts and anonymise their posts; which is to say their user/nickname is automatically changed to something other than what they registered with. Of course you still retain the ability to remove their posts as well. Even though this is not strictly required by GDPR if your policy checks out! (Note that you can already (pseudo-)anonymise their posts by first changing their nick before removing their profile, but we figured it would be nice to automate this in the future.)
- Extra prune functions, like expunging IP history for users as far as (technically) reasonably possible, to limit the amount of personal data you have on record. (Use with care.)
These functions will likely not all be introduced at once and some features will be expanded/improved with later updates.
We are aiming to get the basics introduced first (such as ability to add privacy policy, basic profile export, opt-out function for newsletters and forcing users to agree again to a (changed) registration agreement/privacy policy and log that). More features may be added later. If you think we forgot something, you may also post suggestions here - but please keep in mind that we are limited in time and resources.
We have decided to implement these features in to SMF itself rather than releasing it as a modification (mod), so when you update SMF: these features will be available to you instantly.The features will be optional for you to enable/disable, so if you do not want to use or activate them: that is possible.
We have been working hard on this and will release it as soon as possible. Our estimate is a release around the end of this month/begin of July, but please do not consider that a promise. Keep in mind that these tools are to help you with being/becoming GDPR-compliant, only activating them doesn't necessarily make you compliant. We advise you to read up on the laws and obtain legal advice if you are unsure whether or not you are compliant or have to be and what you should put in your privacy policy.
As for our own site, we will post a Privacy Policy soon to make it easier for you to see what we do with the very limited amount of data that you provide us with and information about what your rights are. And of course we will introduce the above features here as well as they will be included in SMF itself.
Last but not least, we apologize for the delay in introducing these features. Once we became aware of this new law, we wanted to get to the bottom of it and get some legal advice first. And as we are all volunteers: there are some time constraints as well. We are working very hard on it though and will release the features soon.
Thank you!
Kind regards, on behalf of;
- SMF Team
- Simple Machines
And with the term "our next release", do you mean the next major update (the 2.1 branch) or the current stable branch (2.0.x)?
Good question on the Core features section, I'll ask the devs.
It will be turned off by default as we don't want to impose this on everybody, plus if you enable it you have to take extra actions such as populating your Privacy Policy.
Both!
But SMF 2.0 gets it first as that's the current stable version and thus what most people are using.
i appreciate that very much.
Regards!
(This is why it was removed in 2.1)
but we dont need to continue to be logical
In context of 2.0, burying stuff in Core Features only guarantees people having to ask where to find it.
Sorry is of german.
https://www.kreativ-web-marketing.com/de/news/meldungen/dsgvo-datenschutz-weisse-webseite.php
Congratulations, that's the second dumbest thing I've heard yet coming out of the German interpretation of the GDPR, the first being that if patients request their healthcare data to be deleted under RTBF, electronic records must be deleted, while the paper copies (that are fundamentally incomplete, if say, you have cancer where you'll have CTs and treatment plans and all that stuff as 95% of that won't ever make it to paper and even if it did, it wouldn't be especially useful anyway) must be kept for 30 years.
Fortunately the ICO is not quite so asinine about any of this. It's getting increasingly less worth the effort to run a website the way this is going.
EDIT:
As far as I know, this is THE point in GDPR that has been interpreted as the need of a privacy policy available:
In my understanding, appropriate measures does not mean it has to be available at all cost at all times, it simply means to make it public and clear where you can obtain the information if needed.
Article 13 in itself will not come in to play, if the server is down - because no information is then collected, and the user does not have to be informed of that.
This DSGVO is actually made to bring even more members to the social networks. The private websites will be broken. But that's not the topic here. The laws are made, then you should also see to implement them as far as possible. alberlast has already solved it.
So I think, this can simple ignored ...
It's very simple to handle that
In the index.php just before this
return 'InMaintenance';
check if the request the impressum or the gdpr policyEasy to handle that ..
Is there any progress to report?
Is there any progress to report?
Disclaimer: IANAL, everything that follow is just AFAIK.
An important part of the German DSGVO (I don't know it it's also part of the GDPR, but I would assume so) seems to be that in your privacy policy, you need a list of all third-party sites with access to personal data (f.e. IP address, which means basically any third-party site) and information about what exact data these sites receive, and how to access their privacy policy page if you want to object/reject them from handling your data (and under the German DSGVO, as the forum host, you apparently even need to have "commissioned data processing" (German: "Auftragsdatenverarbeitung") contracts with all of these sites).
Will SMF by default contain this data for the mandatory and optional built-in services, like JQuery, reCAPTCHA, Gravatar, ...?
Especially with the ad management mod, that has no way to know which providers are in use - so that really should be on the site owner to deal with.
That's not 100% correct, the 2.1 default (for Configuration -> Features and Options -> General -> "Source for the jQuery Library") seems to be "Auto", which, according to the docs, "[...] will use the CDN first and if not available fall back to the local source". This is what was seeing, and this took me by surprise, because I had expected the feature to work the other way around: Try local first, and if that fails, go for CDN. (And that's why I assumed jquery was a "mandatory" feature, although I didn't specifically say that.)
That was kinda what my query was about, the SMF PP should by default include all the info for all these third-party sites (not only the enabled-by-default ones), independent of the site actually using it. This is waaaay more practical than putting documentation somewhere (that 99.9% of users won't ever bother to read) that instructs the remaining 0.1% that if they enable feature X, they would also have to adjust the PP. Also, the forum owners can't really judge (with reasonable effort) how all those features work and what kind of personal information will be available to those third parties.
I agree that SMF can't reasonably solve this problem for mods (and I didn't ask for that).
The PP should not by default include things that are not enabled by default. And good luck to you to write the translated version of the privacy policy that patches all the bits together. Hint: other forum platforms that have had GDPR features for more than a year don’t try to solve this - at the end of the day, you are the site owner, you are responsible for it being correctly listed, not the software, and if the software has defaults there is a fair bet someone will be on the wrong side of it for assuming it is magically correct when it is not.
I thought to have read that there should also be a solution in the 2.0.x by SMF directly?
That also in the 2.0.X the privacy policy, as well as the terms of use, etc.
separately activate each and can view and confirm,
as well as the user can export his data and
the admin can then also delete a user DSGVO compliant, etc.?
Without the need of an extra mod?
Or did i choose the wrong topic here?
EDIT:
No, found this here:
The correctness was about your phrasing, it sounded like the default jQuery setting was local-only, and the admin needs to explicitly change the setting to use the CDN. (And yes, it is of course mandatory, I was just pre-coffee rambling...
I disagree, I think it should include all those third parties, and maybe prefix each one with something like "If this site is configured to use the Gravatar option, your personal data (including IP address, email address, …) will be processed by them, blah blah blergh…".
Otherwise, as a site owner, you would have to test all user-configurable options to see if any of them have an effect on any specific forum page, resulting in traffic to additional third-party sites.
Being on the other "wrong side", that is, including a "this external site might be processing your data under these circumstances"-prefixed reference to a site that isn't actually used, shouldn't be a problem.
I don't understand. I'm asking for one static policy that includes all of this. Not multiple versions, and not code-including sections based on features used.
This is the correct topic. AFAICT, the feature is not yet implemented in 2.0 or 2.1 RC2 (for the 2.1 branch, part of it is scheduled for RC3).
Full ACK. That's why I'm proposing to have these sections statically prefaced by "If this site is configured to use this (/the 'foo') option[…]".
And since mods cannot be done with this, why not just avoid the whole problem by making it the site owner’s responsibility in the first place, maybe by offering this information in the config screen.
Does the user have to know? Sure, if "optional service x" is the straw to break the camel's back, and the user reads it might be active, then that might keep a user from registering in the forum. But I'd err to the benefit of the site owner and document everything (in the case of a static document).
That would be a possibility, too, indeed. I haven't thought of that (but I still prefer the static catch-all document, I think). I, possibly mistakenly (is this even valid english?
Yes, again, IANAL, but I'd naively assume it's very much less of a legal problem to say, f.e.:
(and then be wrong about 99% of threads), than to not mention this fact to the users, which seems like an obvious disregard of the GDPR. (And, just to remind you, the GDPR doesn't apply to EU organizations and private site owners only, but to everybody worldwide that is handling PII of EU/EEA citizens.)
(I'll take the safe route for now and disable the [img] BBC in the forum I'm setting up, because it can include basically any URL (and the focus is on text anyway)...)