Hi everyone,
I want to make you aware of a potential privacy problem in Mailman's Hyperkitty. Under the upcoming EU General Data Protection Regulation (GDPR)1, which will be in force as of 2018-05-25, it is illegal to transmit data to third parties without a right to do so. Without going into the details, the inclusion of third party services into one's website is usually deemed such a transmission, and unless one has explicit consent of the user (e.g., by an optional (!), unticked ticking box) this is normally illegal (if one targets EU users).
The GDPR does not affect private and family use (Art. 2(2)(c) GDPR), but the exact reach of that clause is yet to be determined; it certainly does not exclude company use of Mailman.
I've found it's possible to disable the social login providers quite easily (we had this discussion here on the mailinglist recently), but I don't see an option to disable Gravatar. If there is one, please enlighten me, but anyway I want to propose this as a feature request against Hyperkitty. A GDPR-compliant implementation of Gravatar in Mailman would look like this:
- In order to not transmit website visitor's data (IP address, browser info, etc) to Gravatar, Hyperkitty has to request the avatar image itself and not leave that to the user's browsers to do. In other words, the HTTP GET request needs to come from the server running Hyperkitty and the user's browser then just requests the avatar from the Hyperkitty server. Most likely easiest way to do this is to pre-download the avatar when an email is archived.
- In order to not transmit the subscribers' data (email address, allows Gravatar to track the subscriber) to Gravatar illegally, the retrieval of the avatar image from Gravatar has to be disabled by default. Instead, an option needs to be added to the subscriber's control panel which he has to actively enable in order to have his Gravatar downloaded and thus used (privacy-by-default rule).
I'm not saying Gravatar tracks people and sells the information gathered, though I have doubts on how Automattic makes money with the service. I'm just outlining the legal duties under the upcoming GDPR for service owners, which are independant of how Automattic processes the data in this specific case.
Please don't dismiss this as some side feature not needed. The fines that can be imposed on service owners due to violation of the GDPR are very high (up to 20,000,000 € [that's 20 million euros, really]).
Marvin
-- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F
I've found it's possible to disable the social login providers quite easily (we had this discussion here on the mailinglist recently), but I don't see an option to disable Gravatar. I've created an issue about this a while ago. https://gitlab.com/mailman/django-mailman3/issues/1
I don't need the gravatars at all. If someone feels they really need them, they could just be added as uploads directly to the profiles. That way each user can choose whether or not to display one and the "gravatars" would be consistent between their emails.
I've found it's possible to disable the social login providers quite easily (we had this discussion here on the mailinglist recently), but I don't see an option to disable Gravatar. If there is one, please enlighten me
You can trick a bit and set GRAVATAR_URL and GRAVATAR_SECURE_URL to a address with the special IP-address "http://192.0.2.0/". This IP-Address is intended for documentation and example purposes and normally ends in nowhere. This might not be compliant to RFCs, but at least you comply with GDPR.
Daniel
Am 24. April 2018 um 18:31 Uhr -0000 schrieb dsd.trash@gmail.com:
You can trick a bit and set GRAVATAR_URL and GRAVATAR_SECURE_URL to a address with the special IP-address "http://192.0.2.0/". This IP-Address is intended for documentation and example purposes and normally ends in nowhere.
Thanks for the tip, that's a good idea and I'm probably going to deal with the problem that way. Actually, as long as the configured endpoint is compatible with Gravatar's API, one could set it to one's own server and use one's own avatar system.
This might not be compliant to RFCs, but at least you comply with GDPR.
I don't think there's an RFC for Gravatar, because it's a commercial service. I would actually appreciate it if there was an RFC that standardised how to retrieve global avatars decentrally, i.e. in a way that allows to self-host the avatar image. I've always viewed centralised services as a problem for the Internet...
Marvin
-- Blog: https://mg.guelker.eu PGP/GPG ID: F1D8799FBCC8BC4F
Am 25.04.2018 um 08:38 schrieb Marvin Gülker:
This might not be compliant to RFCs, but at least you comply with GDPR. I don't think there's an RFC for Gravatar
I meant that it is against RFCs to use this IP address range in the real internet. It is intended for example use only and should not be used in public. But hey, it solves the problem ;-)
Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks SHOULD NOT appear on the public Internet
Daniel
Daniel writes:
I meant that it is against RFCs to use this IP address range in the real internet.
It's also against RFC 5737 to use it locally: it should *never* resolve to a real host. So if the purpose is to substitute a non-working address, this would do (especially if you implement the RFC's suggested restriction that it be filtered locally, but packets to that addressed should be rejected, not discarded by such a filter).
On the other hand, if Marvin wants to implement a GDPR and Gravatar- compatible server, he should use a private address outside of the reserved ranges listed in RFC 5737.
Steve
participants (5)
-
Daniel -
dsd.trash＠gmail.com
-
Marvin Gülker -
Simon Hanna -
Stephen J. Turnbull