WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 2 months ago

#14682 reopened defect (bug)

Privacy leakage: gravatars leak identity information

Reported by: jmdh Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Privacy Keywords: privacy-roadmap
Focuses: Cc:
PR Number:

Description (last modified by Denis-de-Bernardy)

If a commenter on a blog leaves a comment without having a log in to the site, and the "Comment author must fill out name and e-mail" preference is enabled for the blog, the author must provide an email address. The form for this says "Mail (will not be published) (required)"

It's true that the email address itself is not published, but if the site has gravatars enabled, the persistent identity of the commenter is nonetheless revealed. Together with inspection of other posts where the commenter has chosen to reveal their identity, on the same blog or other blogs, or a brute-force approach taking a known email address to find postings attributed to them (using a global search engine) this results in a complete loss of anonymity.

At the bare minimum, the user should be aware of this, so that they can choose not to comment; preferably, the software should be changed so that gravatars are not used for these sorts of posts (or made configurable, in combination with the user being made aware).

Change History (59)

#1 @jmdh
9 years ago

  • Cc jmdh added

#2 @Denis-de-Bernardy
9 years ago

Provocatively said Eric Smith: "Online anonymity is going to die, because governments will demand it. Get over it."

#3 follow-ups: @jane
9 years ago

  • Description modified (diff)
  • Type changed from defect (bug) to feature request
  1. If someone really wants to remain anonymous, they shouldn't enter their real email into any web form, regardless of whether it will be published or not, because the site owner will always have access to it and there have been plenty of cases where an unscrupulous author has published a commenter's email address.
  1. The site owner chooses whether to enable gravatar or not.
  1. The theme decides whether gravatars will be shown or not.

I think the scenario you outline is a case where the burden of anonymity should fall on the commenter; if they don't want their identity to be findable, they shouldn't be using their real identity to leave comments. Will some site owners kill those comments b/c they don't seem to have a real person behind them? Sure. But it's up to the site owner: WordPress puts the power in the site owner's hands. Someone unwilling to let their identity be known may have valid reasons for wanting to hide, but that edge case shouldn't be determining functionality.

"the software should be changed so that gravatars are not used for these sorts of posts" << what sorts of posts? the software should not be changed. And the text that is displayed about it can be left to the theme.

#4 in reply to: ↑ 3 @jane
9 years ago

Replying to jane:

plenty of cases where an unscrupulous author has published a commenter's email address.

Sorry, I meant unscrupulous site owners.

#5 in reply to: ↑ 3 ; follow-up: @jmdh
9 years ago

Firstly - is it customary on this trac instance to edit the description with commentary? Since there is no built-in attribution it might confuse other people reviewing the bug.

Replying to jane:

  1. If someone really wants to remain anonymous, they shouldn't enter their real email into any web form, regardless of whether it will be published or not, because the site owner will always have access to it and there have been plenty of cases where an unscrupulous author has published a commenter's email address.

I disagree with this assertion. Clearly there are degrees of anonymity, and providing an email address with the promise that it won't be published is different to publishing it. I agree that you cannot necessarily trust a third party site owner to renege on this promise, but the software itself should not!

  1. The site owner chooses whether to enable gravatar or not.

Yes, it's true that the site owner does have the ability to turn off gravatars, and I will be recommending this to my users as a matter of course in the absence of other fixes to this problem. However that's a shame, because it means that gravatars aren't available where the user doesn't mind being identified in that way.

This doesn't have any bearing on the basic validity of the defect, however.

  1. The theme decides whether gravatars will be shown or not.

In that case, please consider my bug report as including the default themes shipped with Wordpress.

I think the scenario you outline is a case where the burden of anonymity should fall on the commenter; if they don't want their identity to be findable, they shouldn't be using their real identity to leave comments. Will some site owners kill those comments b/c they don't seem to have a real person behind them? Sure. But it's up to the site owner: WordPress puts the power in the site owner's hands. Someone unwilling to let their identity be known may have valid reasons for wanting to hide, but that edge case shouldn't be determining functionality.

Again, there are degrees of anonymity. If wordpress as a system isn't willing to even support its promise not to publish the email identity of the commenter, it should not make that promise.

"the software should be changed so that gravatars are not used for these sorts of posts" << what sorts of posts?

The sort of comments which are made by non-authenticated parties (I mistakenly used the term posts rather comments previously).

the software should not be changed.

I hope I've managed to clarify why I disagree with this statement.

And the text that is displayed about it can be left to the theme.

In that case, please consider my bug report as including the default themes shipped with Wordpress.

#6 follow-up: @jmdh
9 years ago

  • Type changed from feature request to defect (bug)

For the record, please note that I filed this ticket as "defect", not "feature request". trac does not make it obvious that the status was changed by a third party.

#7 in reply to: ↑ 6 @jmdh
9 years ago

Replying to jmdh:

For the record, please note that I filed this ticket as "defect", not "feature request". trac does not make it obvious that the status was changed by a third party.

Argh. And that I did not actually intend to revert the change, only record it.

#8 in reply to: ↑ 5 ; follow-ups: @Denis-de-Bernardy
9 years ago

  • Component changed from Security to Comments
  • Description modified (diff)
  • Type changed from defect (bug) to feature request

Replying to jmdh:

Firstly - is it customary on this trac instance to edit the description with commentary? Since there is no built-in attribution it might confuse other people reviewing the bug.

The close keyword should have been added instead.

Leaving this as a feature request, since nothing is technically dysfunctional.

I'm itching to close the ticket. It seems to me that highlighting the problem to the end user (a notice in the comment form, explaining that entering an email will reveal the avatar attached to it), and implementing the workaround (aka a "Show my Avatar" checkbox in the comment form), can (should) both be done in a plugin or in the theme. There's a get_avatar hook in get_avatar(), and comments can have a meta field.

#9 in reply to: ↑ 8 ; follow-up: @nacin
9 years ago

Replying to Denis-de-Bernardy:

Replying to jmdh:

Firstly - is it customary on this trac instance to edit the description with commentary? Since there is no built-in attribution it might confuse other people reviewing the bug.

The close keyword should have been added instead.

(If I had to guess, the line was accidentally added to the end of the description field instead of the comment field. I've done it before.)

#10 in reply to: ↑ 9 ; follow-up: @wpmuguru
9 years ago

Replying to nacin:

(If I had to guess, the line was accidentally added to the end of the description field instead of the comment field. I've done it before.)

I have as well.

I'm in favor of wontfix this one. If someone is concerned about their email address being discovered, they can get a free anonymous email from any number email services. From my perspective, the whole point of a globally recognized avatar (gravatar) is global recognition and that the gravatar.com landing and registration pages make clear that is what the service is for.

#11 in reply to: ↑ 10 @jmdh
9 years ago

Replying to wpmuguru:

I'm in favor of wontfix this one. If someone is concerned about their email address being discovered, they can get a free anonymous email from any number email services.

The user is not in a position to know that their identity will be leaked by the system. This is the fundamental point I am trying to make.

From my perspective, the whole point of a globally recognized avatar (gravatar) is global recognition and that the gravatar.com landing and registration pages make clear that is what the service is for.

Firstly, registering on gravatar.com should not mean that you should expect your identity to be disclosed even when the site you are talking to says that it won't.

Secondly, the user doesn't even have to have heard about gravatar.com for this problem to arise; the information disclosure occurs whether or not they have registered, via the image URL which appears next to the comment, containing the hash of their email address.

#12 in reply to: ↑ 8 ; follow-up: @jmdh
9 years ago

Replying to Denis-de-Bernardy:

Leaving this as a feature request, since nothing is technically dysfunctional.

I'm itching to close the ticket. It seems to me that highlighting the problem to the end user (a notice in the comment form, explaining that entering an email will reveal the avatar attached to it), and implementing the workaround (aka a "Show my Avatar" checkbox in the comment form), can (should) both be done in a plugin or in the theme. There's a get_avatar hook in get_avatar(), and comments can have a meta field.

Well, I'm really very surprised that this seems to be the prevailing attitude, but this is my first serious look at Wordpress so maybe I'm misjudging the sort of things that are important to the Wordpress team. I don't really feel that my points are being seriously considered at all in any of the responses on this ticket. The fact that you have said nothing is technically dysfunctional, and in the next sentence refer to the problems, and (technical) workarounds (suggesting that you agree that there is a problem) is itself puzzling.

If there are any aspects of the problem that you think I haven't made clear then do point them out and I'll try and explain better.

#13 @ryan
9 years ago

The avenues of address are to never show gravatars, weigh down the form with privacy policy tedium and explanations of baroque things such as md5 hashes, provide some sort of gravatar opt-in in the form which would have to be stored per comment, or simply remove the "will not be published" parenthetical. All of these seem unfriendly overkill for what is a willful and deliberate leak at the source. "Mail (will not be published)" does what it says. Plain text email addresses are not published so that they cannot be scraped by spammers. Deriving other privacy assertions beyond that is highly speculative on the part of a commenter who is giving away his email address (not to mention his IP) to a third party.

#14 in reply to: ↑ 12 @Denis-de-Bernardy
9 years ago

Replying to jmdh:

If there are any aspects of the problem that you think I haven't made clear then do point them out and I'll try and explain better.

Imo, your points are quite clear.

It's just that, generally, functionality which is of interest to nearly all users go in core; while the rest remains plugin material. This is to avoid feature creep in core. (There are exceptions, mind you. Matt's pet features, e.g. the capital_P_dangit() garbage or over-zealous data collection when calling home, go in regardless of what the majority of contributors think.)

Personally, I can easily picture a user changing his screen name before making a nasty comment on his favorite site, only to realize upon having posted it that his gravatar shows up because he forgot to change his email. So I do see the point in trying to prevent this. But I also think there is truth in Eric Smith's provocative comment -- anonymity is going to die.

#15 @nacin
9 years ago

  • Keywords close added

#16 @nacin
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#17 @hakre
9 years ago

whatever@… works always

#18 @hakre
9 years ago

was: at example.com

#19 @SergeyBiryukov
6 years ago

#26590 was marked as a duplicate.

#20 follow-up: @andreasnrb
6 years ago

Given latest Disqus fallout not removing Gravatar is really a strange choice.
http://www.thelocal.se/20131212/millions-of-disqus-comments-leaked-to-swedish-group

#21 @andreasnrb
6 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from feature request to defect (bug)

#22 in reply to: ↑ 20 @damst
6 years ago

  • Cc mst@… added

Replying to andreasnrb:

Given latest Disqus fallout not removing Gravatar is really a strange choice.
http://www.thelocal.se/20131212/millions-of-disqus-comments-leaked-to-swedish-group

+1

#23 @SergeyBiryukov
6 years ago

  • Milestone set to Awaiting Review

#24 @andreasnrb
6 years ago

What can be accomplished using the Gravatar system is demonstrated in this video: http://www.youtube.com/watch?v=fdphoc3XUF8

#25 follow-ups: @keha76
6 years ago

Why not simply add an option to disable the Gravatar system?

#26 in reply to: ↑ 25 @knutsp
6 years ago

Replying to keha76:

Why not simply add an option to disable the Gravatar system?

There is.

#27 in reply to: ↑ 25 @andreasnrb
6 years ago

Replying to keha76:

Why not simply add an option to disable the Gravatar system?

Problem is it being enabled by default and the privacy downside is not disclosed by WordPress. Discussing with non devs they have no clue about this issue, heck not even wp devs know about this issue to any large extent. The commentators on sites also dont know about this issue. Some WP folks has replied that users can just use fake email if it bothers them but such answers are completely useless since they do not solve the issue also only available for those that know about the Gravatar issue in the first place.

Last edited 6 years ago by andreasnrb (previous) (diff)

#28 follow-up: @ronalfy
6 years ago

I personally think this is plugin territory. Just create a checkbox in the comment form where a user can "opt-out" of using Gravatar. Save as comment meta, then if the meta is set, just show the default avatar.

If you don't want your Gravatar shown on sites, then don't use it, or use a fake e-mail address. I don't see the point of this discussion.

#29 in reply to: ↑ 28 @andreasnrb
6 years ago

Replying to ronalfy:

I personally think this is plugin territory. Just create a checkbox in the comment form where a user can "opt-out" of using Gravatar. Save as comment meta, then if the meta is set, just show the default avatar.

If you don't want your Gravatar shown on sites, then don't use it, or use a fake e-mail address. I don't see the point of this discussion.

And how will people know about the issue and be informed about the plugin? Saying plugin territory just shows a total lack of understanding of the main issue. That the issue is not disclosed. Not to mention possible legal ramifications in various countries by including this feature and having it enabled by default.
If you dont know about the issue how the heck can you opt out of it or inform your users? Answer that question and the discussion indeed looses its point. Assuming people do just shows a total disconnect from most users. This unfortunately seems to be the case for most WP devs giving their view on this matter.

#30 @Ammaletu
6 years ago

Just wanted to add that such a plugin exists: http://wordpress.org/plugins/avatar-privacy/ It's not as polished as I would like it to be, but it addresses the privacy issues raised in this ticket. I agree that it is not ideal that site owners have to actively look for such a solution to benefit from it.

#31 @andreasnrb
6 years ago

torque magazine published and excellent article concerning this matter today:
http://torquemag.io/if-you-wouldnt-say-it-in-person-would-you-say-it-online/

#32 @chriscct7
4 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed
  • Version changed from 3.0.1 to 3.0

This ticket was mentioned in Slack in #core-comments by rachelbaker. View the logs.


4 years ago

#34 @pento
19 months ago

#43799 was marked as a duplicate.

#35 @chrisherbert
19 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I think this issue deserves much more serious attention, especially now that Gravatars are easily accessible in the /users and /comments REST endpoints. I've created a tool that illustrates just how easy it is to de-anonymize (some) email addresses using Gravatars: http://wordpressexpose.chrisgherbert.com.

#36 @SergeyBiryukov
19 months ago

  • Milestone set to Awaiting Review

#37 @pputzer
18 months ago

A sample implementation of a possible solution to the privacy issues is available in the form of Avatar Privacy. The plugin uses a salted hash (SHA256) as the on-site identifier and caches the gravatars locally (it also does some other things that do not directly apply to this issue, such as adding a Gravatar.com consent checkbox to the comment form).

This ticket was mentioned in Slack in #core-privacy by lakenh. View the logs.


14 months ago

#39 @lakenh
14 months ago

  • Component changed from Comments to Privacy

Gravatar-related privacy issues are on the Core Privacy team's roadmap, therefore we're moving this into the Privacy component to keep track of it.

#40 @desrosj
14 months ago

  • Keywords privacy-roadmap added

This ticket was mentioned in Slack in #core-privacy by postphotos. View the logs.


14 months ago

This ticket was mentioned in Slack in #core-privacy by dejliglama. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.


5 months ago

#45 follow-up: @pputzer
5 months ago

Ways to fix this without replacing Gravatar with another user avatar system:

  • Cache the Gravatar response and serve the images from the local server.
  • This also improves performance (at least on HTTP/2), because no other connection needs to be opened.
  • The public URLs of the cached images should use a more secure algorithm than MD5 (like SHA256) and a site-specific salt.

Doing this will leave only the lesser issue of always disclosing the hashed email address to Gravatar.com, possibly without their consent (especially if they don't even have a Gravatar account). Fixing this as well requires the addition of a checkbox, and an alternate way to create non-static default avatars. (Not technically hard, because all the dynamic default images available in Gravatar were once standalone WordPress plugins.)

This ticket was mentioned in Slack in #core-privacy by pepe. View the logs.


4 months ago

#47 @flimm
3 months ago

At the very least, the text displayed to users "Your email address will not be published." should be changed to "Your email address may be published." (The text should not be merely deleted!) Some of the years old comments argue that users do not care or need their email address to stay private. If that is the case, then it should be a no-brainer to change the text as I suggested, and users will be well-informed and will choose not to care.

We shouldn't merely think about website users, we also need to think about website builders who are choosing to use WordPress to build their websites. Are we putting them in legal jeopardy? Some of them are making legal promises to their users about their privacy, and these website builders may be misled by WordPress' promise that commenters' emails will not be published. I assume that there are implications under the EU's GDPR law as well, as well as laws in other places. I'm confident that an email address is considered personal data under such laws, although IANAL.

#48 @fawp
3 months ago

I have just come across this. I am appalled that some WP devs consider this an a non-issue. Unfortunately this may be the case in some regions / jurisdictions but it is certainly not the case in others. For example in the European Union a recent privacy directive states :

"Organizations in breach of GDPR can be fined up to 4% of annual global turnover or €20 Million (whichever is greater). This is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts."

This is a feature provided by core and it is clearly flawed, fullstop.

So far I have been considering WP for some projects but this is not a point in its favor.

Site owners/admins can't be burdened with liabilities such as this. That some WP devs show a cavalier attitude towards privacy is simply not good enough in 2019.

This needs to be fixed, and fast.

#49 follow-up: @chrisherbert
3 months ago

I wanted to bring attention to another project that I've created to illustrate the potential privacy risks of Gravatars, especially in concert with the REST API: https://dontreadthecomments.org.

The site lets you search for for comments that are associated with an email across several thousand WordPress and WordPress.com sites.

#50 in reply to: ↑ 49 @fawp
3 months ago

Replying to chrisherbert:

I wanted to bring attention to another project that I've created to illustrate the potential privacy risks of Gravatars, especially in concert with the REST API: https://dontreadthecomments.org.

The site lets you search for for comments that are associated with an email across several thousand WordPress and WordPress.com sites.

Thanks Chris, I am interested in talking to you offline about this. I will be in touch.

#51 follow-up: @fawp
3 months ago

In the meantime, I checked gravatar.com privacy policy. By clicking on it I am redirected to https://automattic.com/privacy/ and I want to crystallize here what the policy summary says:

Your privacy is critically important to us. At Automattic, we have a few fundamental principles:

  • We are thoughtful about the personal information we ask you to provide and the personal information that we collect about you through the operation of our services.
  • We store personal information for only as long as we have a reason to keep it.
  • We aim to make it as simple as possible for you to control what information on your website is shared publicly (or kept private), indexed by search engines, and permanently deleted.
  • We help protect you from overreaching government demands for your personal information.
  • We aim for full transparency on how we gather, use, and share your personal information.

#52 in reply to: ↑ 51 ; follow-up: @Denis-de-Bernardy
3 months ago

Replying to fawp:

In the meantime, I checked gravatar.com privacy policy. By clicking on it I am redirected to https://automattic.com/privacy/ and I want to crystallize here what the policy summary says:

Your privacy is critically important to us. At Automattic, we have a few fundamental principles:

  • We are thoughtful about the personal information we ask you to provide and the personal information that we collect about you through the operation of our services.
  • We store personal information for only as long as we have a reason to keep it.
  • We aim to make it as simple as possible for you to control what information on your website is shared publicly (or kept private), indexed by search engines, and permanently deleted.
  • We help protect you from overreaching government demands for your personal information.
  • We aim for full transparency on how we gather, use, and share your personal information.

This would be a lot less funny if the API hadn't been used for political purposes already. :D

https://politics.stackexchange.com/q/41160/15531

On a more practical note, IMHO this ship has probably sailed for better or worse. If memory serves me well (this ticket is a decade old) there was chatter at one point that basically broke down to the notion that an email was no private so get over it, or something to that effect (which I disagreed and still disagree with, but that was the party line). Also, changing the API isn't trivial given the ecosystem that now depends on Gravatars in their current format. Which is to say, at this point this ticket is probably beating a dead horse.

#53 in reply to: ↑ 52 @pputzer
3 months ago

Replying to Denis-de-Bernardy:

Also, changing the API isn't trivial given the ecosystem that now depends on Gravatars in their current format. Which is to say, at this point this ticket is probably beating a dead horse.

Gravatar's API, yes. But that does not mean that WordPress' use of that API needs to continue in the current form. I've outlined what needs to be done in comment 52 and there's a plugin-based implementation available in the form of Avatar Privacy.

#54 in reply to: ↑ 45 ; follow-ups: @Denis-de-Bernardy
3 months ago

Replying to pputzer:

Ways to fix this without replacing Gravatar with another user avatar system:

  • Cache the Gravatar response and serve the images from the local server.

This won't solve or prevent anything. You can still scrape WordPress sites and get the Gravatar ID.

  • This also improves performance (at least on HTTP/2), because no other connection needs to be opened.

But this won't solve the privacy problem.

  • The public URLs of the cached images should use a more secure algorithm than MD5 (like SHA256) and a site-specific salt.

In spirit you are correct but the suggestion is not. SHA is designed to be fast. You want a slow algorithm. One that is adaptive to boot (which is to say, tunable so that you can make it arbitrarily slow by changing a parameter). So what you really want is something more like bcrypt or whatever else is used for password hashing nowadays. As to a site-wide salt, you're much better off with a per user per site salt.

For the note, I checked the plugin that got linked, and the only conclusion I picked up from scanning through the core file was that it was doing (bad) security through obscurity. sha256 with a salt-wide salt is *not* adequate.

Also, you don't even need to brute force the thing. If users consistently fill in their image then an image search will let you track them down on every site they're using irrespective of the hashing method used by site A or B.

Doing this will leave only the lesser issue of always disclosing the hashed email address to Gravatar.com, possibly without their consent (especially if they don't even have a Gravatar account). Fixing this as well requires the addition of a checkbox, and an alternate way to create non-static default avatars. (Not technically hard, because all the dynamic default images available in Gravatar were once standalone WordPress plugins.)

There remains the issue of Gravatar being used wholesale in forum software, gmail plugins, and what have you. The truth of the matter is that it's used everywhere, and not necessarily in a WP context. So fixing this in WP only is merely applying a bandaid.

The actual issue, and the only sensible fix, is that the Gravatar ID generation code should be changed on the Gravatar website. Anything short of that and you'll still end up with opportunities to track users online. You can obfuscate things with some salting or some algorithm change but you cannot prevent it. And as already noted, even with perfectly adequate hashing on Gravatar's end, Google image search can potentially spoil the party.

Which gets me back to the point I made in my prior comment: changing this 10 years ago might have been an option. Trying to change it today is probably beating a dead horse. If Gravatar changes its ID generation code then you'll have swaths of non-WP websites and applications that will break overnight.

#55 in reply to: ↑ 54 @Denis-de-Bernardy
3 months ago

Replying to Denis-de-Bernardy:

The actual issue, and the only sensible fix, is that the Gravatar ID generation code should be changed on the Gravatar website. Anything short of that and you'll still end up with opportunities to track users online. You can obfuscate things with some salting or some algorithm change but you cannot prevent it. And as already noted, even with perfectly adequate hashing on Gravatar's end, Google image search can potentially spoil the party.

Or then, change nothing (?) on Gravatar's end (it's a dumb cache at the end of the day) and advertise a new ID generation method for others to use on client websites. But keep in mind that WP is only dominant in the blog/CMS space. Change will be very slow.

Last edited 3 months ago by Denis-de-Bernardy (previous) (diff)

#56 in reply to: ↑ 54 @pputzer
3 months ago

Replying to Denis-de-Bernardy:

Replying to pputzer:

Ways to fix this without replacing Gravatar with another user avatar system:

  • Cache the Gravatar response and serve the images from the local server.

This won't solve or prevent anything. You can still scrape WordPress sites and get the Gravatar ID.

It does solve the issue of site visitors being (potentially) tracked by Automattic. It's a different issue than the identity leakage, but a privacy issue nonetheless.

  • This also improves performance (at least on HTTP/2), because no other connection needs to be opened.

But this won't solve the privacy problem.

By itself, of course not. That's why I said multiple steps were needed.

  • The public URLs of the cached images should use a more secure algorithm than MD5 (like SHA256) and a site-specific salt.

In spirit you are correct but the suggestion is not. SHA is designed to be fast. You want a slow algorithm. One that is adaptive to boot (which is to say, tunable so that you can make it arbitrarily slow by changing a parameter). So what you really want is something more like bcrypt or whatever else is used for password hashing nowadays. As to a site-wide salt, you're much better off with a per user per site salt.

You are right these measures would make brute-forcing the email address from the public hash more difficult. Using bcrypt() might be feasible for this specific application (and please note that sha256() was only an example). I see some real-world impediments to implementing per-user salts (mainly related to the number of DB requests necessary for commenting on high-traffic sites), but that suggestion can certainly be explored.

For the note, I checked the plugin that got linked, and the only conclusion I picked up from scanning through the core file was that it was doing (bad) security through obscurity. sha256 with a salt-wide salt is *not* adequate.

I'm not sure how you arrive at "security through obscurity". It prevents privacy leakage that is ridiculously easy to exploit on a large-scale basis across the whole internet. Is it providing perfect security (or treating the email address like a password)? No, but that was never the point. (And, since it is open source, you are welcome to provide a pull request.)

Also, you don't even need to brute force the thing. If users consistently fill in their image then an image search will let you track them down on every site they're using irrespective of the hashing method used by site A or B.

Sure. But that is their choice (as opposed to the current WordPress Core implementation which leaks everyones MD5 hash, even for people who do not use Gravatar at all.

Doing this will leave only the lesser issue of always disclosing the hashed email address to Gravatar.com, possibly without their consent (especially if they don't even have a Gravatar account). Fixing this as well requires the addition of a checkbox, and an alternate way to create non-static default avatars. (Not technically hard, because all the dynamic default images available in Gravatar were once standalone WordPress plugins.)

There remains the issue of Gravatar being used wholesale in forum software, gmail plugins, and what have you. The truth of the matter is that it's used everywhere, and not necessarily in a WP context. So fixing this in WP only is merely applying a bandaid.

True, but WordPress is a big chunk of the web and applying "a bandaid" here removes those sites from the equation, which is still much better than doing nothing at al.

The actual issue, and the only sensible fix, is that the Gravatar ID generation code should be changed on the Gravatar website. Anything short of that and you'll still end up with opportunities to track users online. You can obfuscate things with some salting or some algorithm change but you cannot prevent it. And as already noted, even with perfectly adequate hashing on Gravatar's end, Google image search can potentially spoil the party.

For those people who choose to use Gravatars, yes. But the issue described in this ticket affects a lot more people than those. That's why I disagree that we should all wait for Automattic/Gravatar to change their API (which obviously will not happen).

#57 follow-up: @chrisherbert
3 months ago

If you're proxying Gravatars through the site itself, do you need to do any hashing at all? Couldn't you just do something like example.com/wp-admin/gravatar-proxy.php?comment_id=1234, which would fetch the Gravatar server side and pass it on the user?

That way you wouldn't be exposing anything more than the comment ID, which doesn't seem sensitive at all. I guess you'd be serving some redundant images, since each comment would have a unique image URL even if they're from the same user. That doesn't seem like a big deal though.

#58 in reply to: ↑ 57 @pputzer
3 months ago

Replying to chrisherbert:

If you're proxying Gravatars through the site itself, do you need to do any hashing at all? Couldn't you just do something like example.com/wp-admin/gravatar-proxy.php?comment_id=1234, which would fetch the Gravatar server side and pass it on the user?

That way you wouldn't be exposing anything more than the comment ID, which doesn't seem sensitive at all. I guess you'd be serving some redundant images, since each comment would have a unique image URL even if they're from the same user. That doesn't seem like a big deal though.

Two main issues:

  • Not all avatar uses are for comments (e.g. embedded author boxes, the WordPress admin bar).
  • Scalability - you don't want PHP proxying every single one of those images on every page load.

So we need to construct a valid URL that can be handled directly by the web server if the cached file already exists, but that allows PHP to have all the necessary information to request the image upstream if it is not there.

#59 @fawp
2 months ago

Update: after some research I can see that this ticket is referenced in the roadmap that the Privacy-Core WP team is working on. Cross-referencing their page here: https://make.wordpress.org/core/roadmap/privacy/

Note: See TracTickets for help on using tickets.