[wp-trac] [WordPress Trac] #14682: Privacy leakage: gravatars leak identity information

[WordPress Trac]

#14682: Privacy leakage: gravatars leak identity information
-----------------------------+------------------------------
 Reporter:  jmdh             |       Owner:  (none)
     Type:  defect (bug)     |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Privacy          |     Version:  3.0
 Severity:  normal           |  Resolution:
 Keywords:  privacy-roadmap  |     Focuses:
-----------------------------+------------------------------

Comment (by Denis-de-Bernardy):

 Replying to [comment:45 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/14682#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform