Skip to content
This repository has been archived by the owner on Apr 19, 2023. It is now read-only.

Leaking email to Gravatar. #1114

Closed
MP70 opened this issue Apr 27, 2020 · 7 comments
Closed

Leaking email to Gravatar. #1114

MP70 opened this issue Apr 27, 2020 · 7 comments
Assignees
Labels
api-v3 Issues for the legacy API v3 enhancement New feature or request released

Comments

@MP70
Copy link

MP70 commented Apr 27, 2020

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).

@MP70
Copy link
Author

MP70 commented Apr 27, 2020

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.

@AnandChowdhary
Copy link
Member

AnandChowdhary commented Apr 28, 2020

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?

@AnandChowdhary AnandChowdhary self-assigned this Apr 28, 2020
@AnandChowdhary AnandChowdhary added the enhancement New feature or request label Apr 28, 2020
@MP70
Copy link
Author

MP70 commented Apr 29, 2020

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/.

@AnandChowdhary
Copy link
Member

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.

@FindingAnand
Copy link
Member

⚠️ This issue has not seen any activity in the past 2 months so I'm marking it as stale. I'll close it if it doesn't see any activity in the coming week.

@FindingAnand FindingAnand added the wontfix This will not be worked on label Nov 9, 2020
@AnandChowdhary AnandChowdhary removed the wontfix This will not be worked on label Nov 9, 2020
@FindingAnand
Copy link
Member

⚠️ This issue has not seen any activity in the past 2 months so I'm marking it as stale. I'll close it if it doesn't see any activity in the coming week.

@FindingAnand FindingAnand added the wontfix This will not be worked on label Jan 9, 2021
@AnandChowdhary AnandChowdhary added api-v3 Issues for the legacy API v3 and removed wontfix This will not be worked on labels Jan 9, 2021
@FindingAnand
Copy link
Member

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-v3 Issues for the legacy API v3 enhancement New feature or request released
Projects
None yet
Development

No branches or pull requests

3 participants