#55062 closed defect (bug) (duplicate)
GDPR compliance: Loading gravatars from gravatar.com might pose a problem.
Reported by: | BjornW | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | critical | Version: | |
Component: | Privacy | Keywords: | close has-privacy-review |
Focuses: | privacy | Cc: |
Description
A German court ruled the use of external Google webfonts to be in violation of the GDPR. See this article on WPTavern.
As far as my understanding goes, the German court came to this ruling because the website in question was loading external assets without consent nor legitimate interest.
I think WordPress might have a similar problem with the use of gravatar.com in wp-admin.
As far as I know the user has not been asked for permission to load gravatar assets nor is there a legitimate interest for the use of Gravatars in an out-of-the-box WordPress installation.
Therefor I belief WordPress might be not compliant with the GDPR at this moment.
I'd also suggest to investigate if any other external loading of external assets (fonts, images etc) is happening and if the exchange of information needed for update checks does comply with the GDPR.
Attachments (1)
Change History (10)
#3
@
3 years ago
Just to be sure, I checked with a brand new install of 5.9, using an email address that does not have a Gravatar attached. As soon as I log in I see a request to (a subdomain of) gravatar.com
, so this is definitely still an issue in the most current release.
This ticket was mentioned in Slack in #forums by vladytimy. View the logs.
3 years ago
#5
follow-up:
↓ 6
@
3 years ago
- Keywords close has-privacy-review added
This is indeed very similar to the problem we have discussed in #16020 so I propose we close this new ticket and keep the discussion going on the previous one.
With regards to the Google fonts: No, the problem is not that the website is loading external assets. The problem was that the IP address of a visitor was sent to Google every time the visitor visited a website with Google Fonts enabled. The solution there is to self-host the Google Fonts.
#6
in reply to:
↑ 5
;
follow-up:
↓ 7
@
3 years ago
With regards to the Google fonts: No, the problem is not that the website is loading external assets. The problem was that the IP address of a visitor was sent to Google every time the visitor visited a website with Google Fonts enabled. The solution there is to self-host the Google Fonts.
Hi @paapst,
I think we mean the same, but just to make sure: with external assets I'm referring to assets hosted by a third party and loaded without consent from a visitor, while sharing the ip-address of this visitor with the third party. Or is this issue specific for Google? If so, why? Thanks in advance!
Btw I'm ok with closing this ticket and adding it to #16020, although that ticket seems a bit stale..created 11yrs ago, last comment 10 months ago?
#7
in reply to:
↑ 6
@
3 years ago
- Resolution set to duplicate
- Status changed from new to closed
Replying to BjornW:
Hi @paapst,
I think we mean the same, but just to make sure: with external assets I'm referring to assets hosted by a third party and loaded without consent from a visitor, while sharing the ip-address of this visitor with the third party. Or is this issue specific for Google? If so, why? Thanks in advance!
Btw I'm ok with closing this ticket and adding it to #16020, although that ticket seems a bit stale..created 11yrs ago, last comment 10 months ago?
Yes, we mean the same. For more background on why GF is not compliant with the GDPR, please read this article that I wrote almost 3 years ago on this very topic: https://complianz.io/google-fonts-and-gdpr-does-it-work/
I will close this ticket because the other one is already being watched by many collaborators (they will get notifications if you post there) and it specifically focuses on the Gravatar problems and solutions.
#9
@
2 years ago
Hi,
Sorry to comment on a closed ticket but ...
I think this may be a massive issue, way more of a problem than just exposing visitor IPs to third party servers without consent.
The gravatar ID is just an MD5 of their email address. Apparently the National Institute of Standards and Technology (NIST) considers an email address to be PII, or personally identifiable information.
So publicly showing a hash of a user's email address is surely very, very bad indeed?
What's worse is that even if the user doesn't use gravatar, a hash of their email address is still shown.
Surely the only solution is for a user's gravatar to be downloaded by the web server and cached in /wp-content/ and given a completely random filename that is in no way related to their email address.
This would ...
1) Prevent user's email address hashes from being exposed
2) Prevent visitor requests to gravatar when a gravatar doesn't exist
3) Prevent visitors from making requests to a third party server exposing their IP address without their consent
A CRON shedule could then be setup to update the user's gravatars.
Apologies if this is already in hand but none of the old, related tickets seemed to cover this!
Thanks,
Oliver
A screenshot of a request made to secure.gravatar.com after the owner logs in and arrives on the dashboard in wp-admin