npm / policies

Privacy policy, code of conduct, license, and other npm legal stuff
69 stars 78 forks source link

Private profile or hidden email address #58

Closed hexpunk closed 6 years ago

hexpunk commented 7 years ago

I really wish there were a way to make your profile private or at least an option to hide or obscure your email address.

The use case for my account is private packages related to my employer only.

On the sign-up page, it reads "Your email address will show on your profile page, but npm will never share or sell it." How is showing it on my profile page not sharing it?

ghost commented 7 years ago

Agreed, I just went to sign up and saw that a public email is required, surely you would get a ton of spam if you used a main email address here as it would be pretty easy for a scraper to grab all those emails and spam them.

bstrilziw commented 7 years ago

Well, this is on their 'radar'. https://github.com/npm/www/issues/16

This isn't simple and there is some importance of allowing users to contact each other in the case of disputes. We do have as yet unscheduled product plans to improve this but no ETA.

I'm going to close this issue but know that this is on the product team's radar.

Still nothing happened yet.

palortoff commented 7 years ago

I have an email address that I use exclusively for npm. It is being flooded with spam...

TheJaredWilcurt commented 7 years ago

GitHub offers a dummy email address:

https://help.github.com/articles/about-commit-email-addresses/

It has a good system for securing your email address and keeping it private.

danielduan commented 6 years ago

GitHub offers a dummy email address:

That's not a good solution because if you ever forget your password and need to recover it, you will not receive the password reset email.

TheJaredWilcurt commented 6 years ago

Well the way GitHub handles it is you have a real email address you use to log in, and you have a masked one (<github username>@users.noreply.github.com) that is publicly available. Your real email is never shared publicly, unless you tell it to use it instead of the masked version.

As it is right now, I have no way to "confirm" my email address, because I'm using the masked GitHub one as my NPM address. So it's the worst of both worlds. To maintain a safe email address that is not public and not shared, I am forced to use the "fake" masked one from github. However that masked account does not forward emails, so I have no means of verifying my account. I'm forced to chose privacy or security. And between the two, if you give up privacy just once, it's gone forever, where as security can always be improved, fixed, and hacked anyways. So the logical option is to value privacy over security, which is a choice the user should not have to make, as both should be treated with equal value by the system. However the current system forces you to choose. Which to me is a fault of the system that must be remedied for the prolonged security and privacy of it's users.

dgw commented 6 years ago

I'm thinking about publishing a package on npm for the first time, but this issue has me stuck on it. Supporting a platform with such disregard for one of its users' most basic wishes seems unwise.

Technically, this isn't a particularly hard problem to solve. Users can already specify several other ways to get in touch (right now: freenode nickname, GitHub username, and Twitter handle) that are not subject to the sort of privacy hangups some of us have about email addresses. None of that requires npm to implement anything new; it's existing functionality. All we'd need is a checkbox in the settings to hide our email address from the public profile.

Another sort of halfway solution would be showing email addresses on npm profile pages only if the user viewing the profile is authenticated. I know I'd be happier with my email address being "public" by force if it was only viewable by other npm developers, and not just anyone. Perhaps that could be a good stepping stone on the way to better email address privacy options?

ElliotNB commented 6 years ago

+1 for this

TabithaES commented 6 years ago

I basically didn't register an npm account just now, this is completely beyond absurd.

TheJaredWilcurt commented 6 years ago

@dgw @StellarTabi

You can register with your <username>@users.noreply.github.com masked email. Then send an email to the npm support team, and they'll have you create a private Gist on github with a special code to confirm that it is your github account. After that they will manually approve your email address.

This seems like a bad solution that could be improved via automation, but would still be bad. A better solution would be to have a private and public email address field in the settings. The private is used for account verification and contact from the site admins. The public can be optional and if opted in to it will be shown only to logged in users.

ph55 commented 6 years ago

opened this issue on Nov 15, 2016

Just lol

kemitchell commented 6 years ago

The team at npm has considered e-mail masking several times over the years. And we're very aware of what GitHub does. As commenters here have noticed, we haven't implemented any such functionality to date. But we keep the concept on our roadmap, to revisit on a recurring basis, each time making sure our reasoning and cost-benefit still make sense. Next time around, we'll have the benefit of our new security team's input and point of view.

I can't represent everyone who's given input on the idea over time on my own. But a recurring theme in conversation is the fact that, unlike GitHub or Twitter, the npm public registry fundamentally isn't a person-to-person communication service. There are no @-mentions or private messages on the npm public registry, just packages and metadata.

When things go well, that's fine. There's often no need to contact the people behind your dependencies, or your dependencies' dependencies, directly. But in edge cases, like disputes about IP, privacy, or abuse of the service, some kind of out-of-band communication is absolutely essential. Sometimes those issues involve npm, and npm has to use an account e-mail address to send a message. But more often, the issue concerns publishers and downloaders, or two publishers, and they need to contact each other. They may not want npm, Inc. to mediate in any way. And npm definitely couldn't afford to mediate every issue that comes up, given the number of packages, publishers, and downloaders.

That's the view from 10,000 feet down. What about individuals' concerns? There are a few ways to mitigate.

The quick-and-easy fix, for those whose e-mail providers support it, is often to use a tagged address like example+npm@gmail.com. That makes filtering messages a great deal easier, but still reveals the actual, unfiltered address to those who take the time to review manually.

If total e-mail address secrecy is a concern, please note that npm does not require using your given or legal name, either in your account handle, or in your e-mail address. You're free to register a special-purpose e-mail address just for npm, or npm and other services online. You're free to use a forwarding address from a provider of your choice, or to host your own mail server and use an address there.

If you have practical questions about the public registry, metadata, the website, or how to approach using an e-mail address for an npm account, please reach out to support@npmjs.com. They're here to help.

If you have a privacy-related emergency, especially one that requires immediate action to keep you safe, please copy privacy@npmjs.com, as well.

ElliotNB commented 6 years ago

@kemitchell If I understand correctly, your rational for requiring public email addresses boils down to this:

But in edge cases, like disputes about IP, privacy, or abuse of the service, some kind of out-of-band communication is absolutely essential.

But then you go on to say that users are welcome to sign up with throwaway email accounts:

You're free to register a special-purpose e-mail address just for npm, or npm and other services online.

If npm isn't requiring package maintainers to be available for important communication, then why have the public email requirement at all? If you allow throwaway email accounts, then publishing your email address should be optional to begin with.

Requiring users to create a separate email account just for the purpose of publishing on npm with privacy is just a poor user experience.

LeonardoGentile commented 6 years ago

I think @kemitchell comment contrast with what expressed on a linked issue

Times have changed. npm's community looks different! At this point, the message system is still in the product queue, but we have a few more things up our sleeve first. If a user wants to reach out to another to talk about their package before that point, there are multiple avenues: Twitter, Github, and the email listed in the package.json are just a few.

kemitchell commented 6 years ago

@ElliotNB, you were close, but I think you misunderstood especially the second sentence you quoted.

We do require that account holders provide a working e-mail address, and keep their address up to date. We don't welcome accounts that exist just for registration, or aren't checked at all. The purpose is, in fact, to make sure there's some way to contact you. So you can use an npm-specific address, but not a "throwaway" address, to use your word.

We do not require special npm e-mail addresses. Most publishers use their day-to-day personal or work addresses. But users with particular concerns about publishing a personal e-mail address tend to land on a special npm e-mail address as their solution.

kemitchell commented 6 years ago

I closed this issue with my prior comment, and I'm going to ask that the issue be locked, as well. We hear that users would like npm to offer free e-mail aliasing in addition to free package distribution.

To recap: npm, Inc. doesn't provide e-mail hosting or aliasing at present. We reconsider doing so periodically. Opinions within the company differ.

However, other companies already provide those kinds of services, frequently free of charge. You're welcome to use addresses from those services with npm, as long as your account address remains an effective way to contact you.