Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove the requirement to share private email addresses. #635

Open
epoberezkin opened this issue Aug 1, 2024 · 6 comments
Open
Labels
enhancement New feature or request

Comments

@epoberezkin
Copy link

image

You don't need them.

@matchboxbananasynergy
Copy link
Collaborator

I'll wait for @lberrymage to fully weigh in on this, but this seems like the bare minimum required.

If you, as a developer, upload an update that for whatever reason (such as a new sensitive permission) requires a review and it is not clear to the reviewer why it was added, how else are they meant to reach out for clarification?

If an app that has been uploaded is about to be delisted due to falling behind in its targetSdk, how is the developer meant to be warned?

You could argue that in your case, assuming this is about uploading SimpleX Chat, someone could open an issue on the public tracker about this, but that doesn't sound like the best practice for 2 reasons:

  1. Not every app uploaded is going to have a public tracker
  2. The conversation about this might not be best made public

@matchboxbananasynergy
Copy link
Collaborator

To expand on this, I don't really see a viable path that doesn't require a contact e-mail of some sort.

An alternative path that could be viable would be to remove the e-mail from this GitHub prompt and instead add a mandatory e-mail field in Parcelo when uploading (or updating, for existing devs that wouldn't have provided it through Parcelo yet) instead. This would allow the flexibility of providing a more generic e-mail instead, rather than the one for the GitHub account, but it's also important for the provided e-mail to be one that the developer/project actually checks, as the communication for Accrescent might concern the app's removal from the store, so it's a balance...

@lberrymage
Copy link
Member

@epoberezkin A contact email is required for developer console accounts, and this is unlikely to change. However, you are correct that this doesn't necessarily require access to GitHub emails. Once an email verification system is implemented, this requirement can be removed, and developers will be able to use an email address of their choosing.

@lberrymage lberrymage added the enhancement New feature or request label Aug 1, 2024
@lberrymage lberrymage transferred this issue from accrescent/accrescent Aug 1, 2024
@epoberezkin
Copy link
Author

epoberezkin commented Aug 1, 2024

We publish the app on F-Droid, we communicate with F-Droid maintainers via their Gitlab and our GitHub issues - the email was never requested.

if you don’t recognise GitHub as an identity provider and don’t plan to communicate via GitHub, then there is no real reason to offer GitHub authentication - just ask to register with email and password.

You can’t really declare that you adhere to privacy principles, and then ask two forms of identification just to review the app registration process.

@epoberezkin
Copy link
Author

The same happened with many other repositories btw - flathub, AppImage - they accept pull requests as a registration and at no point asked to create accounts, leave alone asking for email address.

@lberrymage
Copy link
Member

lberrymage commented Aug 1, 2024

This is because we run very differently than these repositories. We manage a server which will include a stable API for DevOps automation; changing app security, privacy, and quality policies which developers will need to keep up with; notifications for when developer action is required, review pass/fails, and when publishing succeeds. All of these require an automated notification system, and email is ubiquitous for this.

We intentionally don't collect any more information than is needed of developers to verify they're authorized to publish their apps and to properly operate the service (send them notifications). There are also plans to add other forms of authentication including generic email/password in the future to allow more privacy and security for those that want it: see #478.

GitHub authentication was easy to implement and covers most people's needs, which is why it was implemented first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants