[PRIVACY ISSUE] Weblate publishing email addresses

[ghost]

Hello!

Weblate publishes translators' email addresses in the public domain! This can lead to very serious problems for people who have taken on translations of your application. For example, it can lead to mass spam or phishing attacks.

Please take action. If it's impossible to change this behavior, please publish a warning that the email will be publicly visible and a recommendation to use a one-time email or an alias (such as Anonaddy or SimpleLogin)

Here is the proof:

[n8fr8]

How is this different than Github commit history?

commit d29bc980429c1641a4ec332fbdd62ac0edef4cbd (HEAD -> master, origin/master, origin/HEAD) Author: n8fr8 <[email protected]> Date: Fri Apr 7 13:04:55 2023 -0400

I agree there may be more new, less technical users on weblate doing localizations, but given that weblate is meant to work like a shared version control system, including syncing with git, there needs to be some kind of identity associated with a translation.

[n8fr8]

Some discussion and options with Weblate:

https://github.com/WeblateOrg/weblate/issues/3105 https://github.com/WeblateOrg/weblate/issues/6508 and https://github.com/WeblateOrg/weblate/issues/8451

will look into what we can do

[n8fr8]

Each user in account settings can change the email that is display publicy on their weblate account.

[maboroshin]

Now Weblate allows you to keep your personal information private at End of 2022.

But Weblate will embed your personal information into GitHub when you publish. It needs to be erased on GitHub. Assuming the right of deletion under GDPR, this was not a good approach. Your personal email address will be published on GitHub. GitHub is not controlled by Weblate. Changing Weblate's settings doesn't erase your personal information from GitHub. Need to put a little heavy-handed erasure on GitHub.

We need to delete for every 1 pull request that Weblate sends to GitHub. It would be difficult to erase all the mail dresses all sent over the years.

[Skyedra]

I discovered this the hard way today :sweat_smile:

But, there is a useful config var: PRIVATE_COMMIT_EMAIL_OPT_IN = False to default to the noreply commit e-mail

It would be nice to have an even stronger version of that setting that forces the noreply commit e-mail. That would prevent users from shooting themselves in the foot if they change that dropdown not understanding the consequences.