WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 13 months ago

#14682 reopened defect (bug)

Privacy leakage: gravatars leak identity information — at Version 8

Reported by: jmdh Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0.1
Component: Comments Keywords: close
Focuses: Cc:

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 (8)

comment:1 @jmdh5 years ago

  • Cc jmdh added

comment:2 @Denis-de-Bernardy5 years ago

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

comment:3 follow-ups: @jane5 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.

comment:4 in reply to: ↑ 3 @jane5 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.

comment:5 in reply to: ↑ 3 ; follow-up: @jmdh5 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.

comment:6 follow-up: @jmdh5 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.

comment:7 in reply to: ↑ 6 @jmdh5 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.

comment:8 in reply to: ↑ 5 @Denis-de-Bernardy5 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.

Note: See TracTickets for help on using tickets.