Jump to content

Community

ptprog

+Clients
  • Content Count

    509
  • Joined

About ptprog

  • Rank
    Community Regular

Recent Profile Visitors

4,215 profile views
  1. Regarding performance, my experiments show a small degradation of performance (15% ~ 20%, measured with a RUM script) during the period I used the preload setting.
    Very useful plugin. Despite some minor issues, it does its job very well. The plugin's author is also very helpful and open to suggestions for improvement.
  2. Has anybody tried to use '<link rel="preload" ...>' to load fonts? Any idea if this improves performance?
  3. That option is enabled. The problem is the primary group 🙂 Thanks!
  4. Aren't admins supposed to receive notifications when there is an account deletion request?
  5. Does this means that we can choose between keeping the username or anonymizing member's content, as when we delete a member from AdminCP?
  6. Hashes are not difficult to reverse when you have a small set of possible unhashed values (the number of IPv4 addresses is small enough that you can hash all of them quickly, to create a lookup table; for IPv6 may take a little longer, though). Also, actual IPs may be useful in proofs of consent (to prove somebody subscribed a newsletter, for example). In case you don't need actual IPs in any case, you can easily anonymize IPs adding a few lines of code your constants.php file, I believe. (I had this kind of solution in place, until I realized I needed actual IPs in some cases.)
  7. This plugin seems to be adding some additional tag&prefix settings for blogs, which I'm trying to use. I want to override the "Minimum Tags Allowed" of a group blog in its "Blog Settings" (AdminCP). I removed the check from the "Default" option, and put the value "1", for example, in the input field. However, after saving and going again to the settings page, the value I set disappeared, and the "Default" option is checked again. So, it seems there is a bug preventing the changes made from being persisted.
  8. For contact forms probably only Privacy Policy is relevant. For guest posts I believe both are important. (In general I agree with you that this is stupid, and it is unlikely anybody will have problems with this. But I wouldn't be surprised if this is indeed required.)
  9. 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,
  10. 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).
  11. 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".
  12. 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.
  13. 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.)
  14. 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).
×
×
  • Create New...