October: Add a user preference option to enable/disable Gravatar

[msimkunas]

There should be a user level preference to enable/disable Gravatar avatars that is set to false by default because of privacy concerns. The current behavior is to use Gravatar when no user avatar is present.

Currently, there is a way to overcome the problem by setting the user avatar manually: https://octobercms.com/forum/post/how-to-remove-gravatar-url-calls?page=1#post-30194

It's a hacky solution though - this really should be a user preference. Should I start working on a PR to fix this?

[LukeTowers]

It wouldn't be a user preference, it would be a config option.

But actually, what would be a better idea is if no avatar was assigned to a user when the user is created (and existing users with no avatar), the server itself makes the request to Gravatar to get the image for that user and then stores it locally as if the user had used the image. That way there is no privacy concern as the server is the one making the request, the request is only being made once, and it's cached locally which would also improve performance by no longer requiring an extra network request to Gravatar on every page load.

[msimkunas]

Caching the initial request sounds like a good improvement. However, I still think it would be better to give the user control over whether an initial request is ever made.

October sends an md5 hash of the email to Gravatar. The privacy concern here needs further investigation but the discussion here seems to suggest that it is, in fact, possible to recover an email address from the hash.

[LukeTowers]

@msimkunas that doesn't apply in this case as the MD5 hash would never be revealed to anyone but Gravatar, and Gravatar doesn't receive any information as to what site is making the request so there is 0 risk to it. "Recovering" original content from md5 hashes is really just making brute force / dictionary attacks against it that rely on it being so fast to do on modern hardware, which is why you should never use MD5 for anything related to authentication.

[LukeTowers]

@msimkunas the problem that StackOverflow had was that user's usernames & gravatar URLs were public information, but not their emails. This meant that using brute force and dictionary attacks combined with the public gravatar URLs they were able to attach the emails used for the accounts to the accounts.

[LukeTowers]

And finally, you can control the request ever being made in the first place, by overriding the User model (when this proposed change is implement) to prevent the initial request from occurring or overriding the partial that renders the gravatar URL in the browser to prevent it from using gravatar.

[msimkunas]

that doesn't apply in this case as the MD5 hash would never be revealed to anyone but Gravatar, and Gravatar doesn't receive any information as to what site is making the request so there is 0 risk to it

Thanks for clarifying this. I wasn't sure about how Gravatar actually works because I've never really used it that much.

"Recovering" original content from md5 hashes is really just making brute force / dictionary attacks against it that rely on it being so fast to do on modern hardware, which is why you should never use MD5 for anything related to authentication.

Yes, I'm well aware of that. That is part of the reason why I raised this issue after all. However, if there is no perceivable way to match user info with Gravatar URLs then I suppose there really is no privacy concern here.

That is, unless, October is used in a way where the backend users have their usernames and Gravatar URLs displayed on the frontend. I'm not aware of such use cases but I'm not sure whether this is an unexpected use case either. As per our previous discussion in Discord @LukeTowers, it sometimes makes sense not to mix backend and frontend users in a single system. If that system - for whatever reason - has a requirement to display public profiles of backend users on the frontend, that may present additional privacy concerns due to Gravatar URLs and/or usernames becoming public (although one could argue that in such a case a separate public profile should be used, thus preventing the backend user username from becoming public; Gravatar URLs though are a different matter).

I'm not saying that October should support such use cases but it's something that should be taken into consideration. If use cases such as the one I've outlined above are deemed acceptable, there should be a way to bypass Gravatar altogether without hacking around in the User model. A simple user preference would do the 'trick' nicely.

[LukeTowers]

@msimkunas I would say that the particular use case described is unlikely to be widely spread, so it would justify a bit of extra code in that case. Either way, implementing a local caching of gravatar images would solve any privacy concerns for pretty much all cases anyways.

[LukeTowers]

When we're maintaining and building a platform that's used by thousands upon thousands of projects around the globe, we have to very carefully consider every public API surface we introduce (whether that's events, public methods, configuration, or user preferences). Right now, I think the best solution to this problem is the one that I proposed above rather than adding a user configuration option. I will point out though that you could totally implement it yourself in a plugin.

[msimkunas]

@LukeTowers Fair enough. Although I don't see how caching those avatars does anything to improve _privacy_ here. It most certainly directly impacts _performance_ and not privacy. The user email is still sent to the Gravatar servers (albeit in a hashed form) irrespective of whether it is the user's browser or the web server itself.

[LukeTowers]

The privacy concern around gravatar isn't an email being sent to gravatar, it's public access to the hashed form of that email when developers aren't aware that the email can be determined from the hash. Locally cached files solves this problem by no longer providing the hash of the email to anyone but the server itself and gravatar in a single request.

[msimkunas]

Ah, yes. That slipped my mind for some reason...

I'll try to look into implementing your proposed change if I get the time.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.