Jump to content

Community

ptprog

Members
  • Posts

    533
  • Joined

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by ptprog

  1. As I mentioned in other post, at least in the European Court, the decision was favorable to the use of legitimate interest as a reason to store IP addresses, even though they were classified as personal information. But I agree when you say that storing IP addresses is risky,
  2. Note that you can use the contact form without agreeing to the ToS, I believe. Probably there are other guest forms in a similar situation. I'm checking European Commission websites to see how they are complying with GDPR, and their contact forms (or at least some) have the consent checkboxes. So, even though I'm not particularly concerned with this issue, I think it would be wise to add this to contact forms and some other guest forms (maybe put it in the same places where you may place a CAPTCHA for avoiding guest spam messages).
  3. My understanding of the European Court decision is that not only it decided that IP address are personal data, but also said the the German law limitations on storing personal data based on legitimate interest were not in accordance with the EU directive. https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-10/cp160112en.pdf This latter part has been interpreted by some as meaning you can store the IP addresses for some time based on legitimate interest. It is also my interpretation, but I'm not a lawyer. I agree. I was just stressing that the rules to keep personal information may be tricky to define, as there is some information that needs to be retained for longer periods, and that information may not be properly "isolated".
  4. The account history is actually a particular cases where we need to keep some IP addresses indefinitely (the ones that are associated with "consents"). I disagree that you need to completely disable IP address collection (or even anonymize all IP addresses before storing then). Recital 49 says: Storing IP addresses for a limited amount time (a few months) is a perfectly proportionate measure to be able to investigate a security incident or block brute force attempts, for example. This is something you cannot simply enable after the fact, so you need to collect them under normal operation. There are also IP addresses such as the ones that are part of the proofs of consent, which you likely want to store indefinitely, and here I guess you can use "compliance with a legal obligation" as legal basis. You would only delete those IP addresses if you deleted the member account. This may be a delicate subject, though. I'm aware that German law has been traditionally more protective of IP addresses than some other European countries. I'm not sure if this is what you are asking for, but I would say that having a feature that allowed admins to define custom consents checkbox, which would be logged in user history in the same way as newsletter consents, would be very useful.
  5. The best I got was a suggestion from IPS staff to contact support in order to obtain the SQL queries to delete IP addresses from the database. But I agree that this kind of feature should be included in IPS core. (BTW, I'm not sure what you mean by "purge the users", but at least deleting a user is not enough to remove its IP addresses from the database.)
  6. Note, however, that if you do not delete old IP addresses from the database, nor anonymize them, that is personal data. Even for those like me that want to delete IP addresses after some time, the recent ones (and the ones from consents, for example) will be in the database. I don't think anybody will request this for data portability, but people may request it as part of their "right of access" (Article 15).
  7. Yes, in general you may have valid reasons to retain data. For example, when you retain IP addresses, or even emails, of banned users and spammers, I see a reasonable reason to retain that data: prevent future abuses, from users that already have a historic of abuses (although I have some doubts about the real usefulness of this data...). But I'm talking about a specific case. In particular, my problem is with the indefinite storage of IP addresses as result of the "normal" use of IPS software. I have used the IP data to detect abuses, but I never needed data from more than a few weeks ago. So, even if the user does not want to be forgotten, I believe retaining this data indefinitely does not comply with the balance requirements of legitimate interest. (This opinion is mainly based on my experience. Others may have legitimate use cases to justify keeping such data, and if that's the case, I'm curious to know more about concrete examples.) IP address are considered PII even when they are not directly connected with a user account. If you cannot associate the IP address with an account, you can still "track" the user. In this case, the IP addresses are similar to many other online identifiers such as tracking cookies, which are considered PII even if not associated with user accounts. Thanks. That may be enough for me.
  8. Two points: I would say that storing the IP address from which a post was made 5 years ago is storing more information than is needed. I just checked some private messages exchanged with a member that was deleted, and its IP address is still there (I did not check if posts also preserve this info), so it seems the possibility to delete a member is not enough to delete its personal data.
  9. One thing is to collect IP addresses for a limited time, and in a way which does not allow you to directly associate IPs with specific users. This can be easily justified by security reasons (I believe there are countries that require that info to be store for some time, so you would have legal reasons to do that). Another completely different thing is to keep IP addresses indefinitely and associated with users, as it happens with many of the IPs stored by IPS in the database, I believe. I'm wondering which legal basis your are going to use for this.
  10. Depending on the cookies, you may be able to use legitimate interest as legal basis for storing and processing cookies. In that case, GDPR does not require you to get users consent (as you are not using the consent legal basis). Now, in my opinion, you still need to ask for consent due to the previous cookies laws, but those laws accept weaker forms of consent than GDPR (such as implicit consent, which is more or less what IPS cookie consent implements). Currently, even the ICO uses implicit consent on their site, although they provide an option to turn off cookies (which does not seem to prevent tracking third-party cookies from Twitter to be set). (Disclaimer: I'm not a lawyer, and I'm still waiting for official replies on whether the interpretation presented above is indeed correct.)
  11. In that case, I repeat what I said before: With moved topics there is no URL invalidated, thus no broken links, even after you remove the redirect entry. With merged topics one URL is not valid anymore, thus after you remove the redirection you get a broken link. Again, I disagree they should follow the same rules.
  12. Do you have any idea about when that was implemented? Was that feature also supposed to redirect topics merged before it was implemented? If so, I guess I'm experiencing some bug in my community (I have a topic that was merged the last time around an year ago that is not redirecting automatically).
  13. I disagree they should follow the same rules. The problems of moving and merging topics are not necessarily the same. When moving a topic, the old URL remains valid, so we just need the link to also be listed on the old forum in case the users are looking for the topic URL in the old forum. But if you have links to that topic (external or not), the links will remain valid, even if there is no redirect. With merged topics one of the URLs will stop working, which means SEO issues and potential broken links if you disable the redirect link. I have actually experienced this issue multiple times in my community with a topic that is quite popular, and that was merged multiple times in the past, forcing me to manually setup redirects to avoid broken links. So, I believe the warning is indeed needed, and the permanent redirect is also a nice to have feature.
  14. As I mentioned previously, there seems to be a CSRF token in the login form. This would also need to be sent as login parameter, but this kind of tokens have a variable value. So, this is likely to make automated login impossible (but it would be nice if somebody from IPS could clarify this).
  15. Could you be more specific about the points 1 and 3? That is: Where did IPS "answer" about the opt-in/opt-out of cookies? For the record, showing a message stating that cookies were set is not a valid opt-in. I'm also not sure where we can opt-out after accepting the cookies. (I don't think GDPR forces us to rely on consent to store cookies, but it would be nice if IPS allowed us to do so.) Where did IPS "answer" about allowing to export users' personal data? I'm not sure which data users may require to be exported for portability, but even if we assume it is just the profile info (which may be easy to collect), note that the users may also request to know all personal data stored about them. I'm pretty sure this includes IP addresses stored in IPS logs. In any case, I did not find any feature to export users data in IPS 4.3 (but I may be missing it).
  16. These improvements are welcome, but there are a few issues that still need to be addressed. One is regarding the ability to either disable the collection or anonymize personal data that is not critical to the software functionalities. I'm thinking about IP address in logs, for example. I don't know if there are other items. Regarding cookies, I think GDPR requires affirmative user action for things like accepting cookies. Thus, IPS should not set any cookie until it has user consent, and it should also provide an opt-out mechanism. I believe this is not done in current version (I didn't test 4.2.7 yet). Using embedded content also means the users may get cookies from external domains/services. So, we need more control on the embeds that are enabled, to make sure we don't add unexpected cookies. It would also be nice to be able to rebuild posts and remove external embedded content.
  17. It seems that if you use the IPS image proxy you have no problems displaying the images.
  18. Among other things, IPS should provide some options to protect/encrypt personal data such as email and IP address (although I think it is not technically possible to provide any real protection for emails when both web server and MySQL are collocated), or even disable their collection (at least IP address I believe are just collected for logging purposes, so it should be ok to stop collecting them). For IP addresses, anonymization should be another option. Also, I'm not sure about what data IPS stores when using external login methods, but there may exist some personal data here too. Regarding cookies, I think GPDR requires websites to respect Do Not Track headers, and requires affirmative user action for things like accepting cookies. So, IPS should not set any cookie util it has user consent, and it should provide an opt-out mechanism. As far as I know, using embedded content also means the user may get cookies from external sites. So, we may need more control on the embeds we allow, to make sure we don't add more cookies, and to be able to rebuild posts removing external embedded content.
  19. Try rebuilding the cache again. I think this solved the issue for me.
  20. In previous versions I was able to do that changing the value of some constants in the source code. But currently that is not working anymore. Sending thousands of emails per hour with services such as Sparkpost usually means lots of rejected emails from Microsoft and Yahoo, for example, thus it is really important to be able to control the sending rate.
  21. Weird... depending on the browser I use I get different info on the page I linked (either 40000 emails free for 30 days trial, or 12000 emails free per month). Anyways, this is what I can see with Safari (probably it is some language setting that makes the page change, not the browser itself): Here and here you also have additional info about their free plan. I'm not using that free plan, so I cannot really confirm that you get the 12000 emails/month free, but I can confirm the 25000 emails/month for free offered when you signup through SoftLayer.
  22. If you signup for a SendGrid account through Azure or SoftLayer you get 25000 email/month for free. You can also get 12000 emails/month for free if you signup directly in SendGrid. I've used both Sendgrid and Sparkpost, and Sendgrid seems to be much more reliable than Sparkpost.
  23. I think I found the cause of the first two issues: some special characters are being encoded twice. For example, the tag @media has a delete URL containing the parameter "tag=%2540media", which won't work, but if change it to "tag=%40media" it already works.
  24. I just installed this application and I'm trying to clean up the tags using the Manage Tags page. I'm experiencing several issues, however: Most of the tags I try to delete are not deleted. Most of the tags I try to edit name are not edited. I have 1441 pages of tags, but only 207 have tags (the remaining are empty, and every time I run the Advanced Tool to add tags to topics, the number of empty pages increases). Are there any logs where I can check for errors?
  25. That's precisely my point. If you can already filter HTML to make it safe, why cannot we have a safe "Source" button in the editor that we can enable to all users? I agree that we also need a source button for admins that lets them use any HTML (which we already have). However, it would be useful if that button had a "safe" variant, which would enable the HTML filter, the profanity filter (as @The Dark Wizard requested), the URL filter, etc. You say "profanity is the least if your worries if you are allowing people to post raw HTML", but the other "worries" can also be solved. (And you are already solving them except when the "Source" button is available.)
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy