Leaking email to Gravatar.
MP70 opened this issue · comments
I have noticed that this leaks email hashes to gravatar. Given Gravatar is quite a old service, I wonder if it better to just allow users to upload thier own profile images (or not).
Similar comment on the adorable avatars, for this project perhaps we could have a 'GDPR/privacy sensitive' branch that brings this all in house.
For example, in 'v0.1' of this branch we could use something like https://github.com/thatisuday/npm-no-avatar instead of adorable and remove gravatar functionality OR we could just remove adorable/gravatar functionality from the API and then in the front end demo generate the dummy avatars.
Later we can build an endpoint that accepts user uploaded avatars (perhaps uploading to s3 compatible endpoint and storing the relationship in the database) and/or pull them down from e.g Microsoft/Github when they link a social account.
Thanks for opening this issue, @MP70! I think this is something to think about, because I've always thought of Gravatar as the "go to" for email avatars, it's perhaps been the "de facto standard" to find the best image for an email. However, there are better options like Unavatar, but those also require "leaking" the email. I do like the idea of fetching the avatar of the social media service in case a user connects their account.
I don't think it's required to add a new endpoint to generate the avatar, we can just use something like https://ui-avatars.com, right? In this case, we leak the user's initials:
Example: https://ui-avatars.com/api/?name=JD
I think it's easier to maintain a configuration parameter rather than a privacy-sensitive branch, because I should aim to keep the entire project GDPR-proof. Perhaps a configuration option AVATAR_SERVICE that defaults to "gravatar_adorable" with alternate options being "adorable" (for skipping Gravatar and only using Adorable), "ui_avatars" or "unavatar" for the services above, or "none" for a generic default? We can also just set the image as null and let the frontend dynamically generate the initials profile picture.
(Quick update: I definitely am going to add the option to upload a custom profile picture in v2 soon)
What do you think?
Thanks for your thoughts on this!
I agree that setting this as a config param is a good idea (better than a branch, I didn't want to remove/degrade the avatar functionality for those who do feel it is acceptable).
For maximum privacy (i.e leaking nothing > leaking initials) my personal view is 'do not call external APIs with any user data (PII or not)' is the safest. On that basis perhaps we could add an addition to your options (eventually) and implement a 'none-except-linkedacct-useruploaded' option OR make your config parameter a 'fallback_avatar' config param so that we set the user profile image based on "if user_uploaded_photo else if linked_acct_photo else if fallback_avatar_fn."
For the time being for those using the 'none' option, they can generate avatars in the frontend and later add in images from the API (when it supports it) if they want to include avatars from linked accounts or user uploaded avatars.
Perhaps if you like I could include a basic implementation for that in the front end demo either from scratch or by using something like https://eliep.github.io/vue-avatar/.
For maximum privacy (i.e leaking nothing > leaking initials) my personal view is 'do not call external APIs with any user data (PII or not)' is the safest.
I think this makes a lot of sense. The defaults should be "don't use any external APIs," and people who want to can configure it to use UI Avatars, Adorable, or anything else they want. If this is the case, Staart UI can use vue-avatar or similar to show. Once this is the standard, we can replicate this in other places we're using/will use third-party services. The default should always be not using them.
I'll make these changes shortly.
🎉 This issue has been resolved in version 4.0.0 🎉
The release is available on:
Your semantic-release bot 📦🚀