-
Notifications
You must be signed in to change notification settings - Fork 204
Leaking email to Gravatar. #1114
Comments
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 (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/. |
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 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 📦🚀 |
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).
The text was updated successfully, but these errors were encountered: