-
Notifications
You must be signed in to change notification settings - Fork 48
Why not cloaking email addresses on account pages? #16
Comments
We hear you, and we want to solve it right. 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. |
Actually, it is not that complicated to solve. Implement an internal messaging system, like it is used by every forum software. No email addresses will be visible. A very simple contact form, will send messages through your internal system without leaking the addresses. This would be better than the current weak solution. |
+1 on this, need the email not public on npm, like what github already provided, keep email address private https://help.github.com/articles/keeping-your-email-address-private/ |
Hi, If we provide a Github account or Twitter account, then it should be enough to contact us, and the email could be hidden to public. You could also only show the email address when someone is loggued into the website. There are many options here instead of just showing the email to everyone... Thanks for trying to improve that part ! |
GEEEZZZ! |
It makes me sad to see that this issue has been closed. I think that virtually everyone agrees that our email addresses should not be made public, as it attracts loads of spam. The least you could do for the community would be to just obfuscate the public email address so that it cannot be scraped by bots so easily. This is an easy problem to solve. Please, re-open this issue. |
Emails should be private. It's an incredibly simple solution as not only are we providing twitter handles, but also 99% of all packages are hosted on GitHub (which is the appropriate Channel of communication for anyone needing assistance, and what you should be encouraging people to do IMHO). People sending emails directly about issues is confusing and results in redirecting to GitHub anyway. The result of the current situation is going to be ineffective communication anyway, as people are going to simply start using spam emails for NPM that they don't monitor anyways. Please fix. |
(if) when someone |
This a very basic settings option; there is no logic reason to not allow it for us. |
This is a bit daft. Please fix it... |
NodeJS -> not working for enterprise since 2009.
This. This is exactly what I just did. |
+1. Pls fix it. |
Can't believe this hasn't been fixed yet... I want to sign up and publish my modules, but I won't until this is fixed. I don't want to publicly show my email and be bombarded by spam. At least give us the privacy option. Any requests or disputes should just go into the repo's issues, which are clearly shown in each module's page. Maybe a Github signup would be a logical step here. Please fix this. |
Any update on this? |
Using temporary email address is a workaround, but it feels like using an early php forum. |
While npm still lacks a proper email/messaging solution, I would like to point out that emails are sent over the wire obfuscated, requiring javascript to display: <a href="#" data-email=%61%6c%65%78%61%6e%64%65%72%2e%65%61%72%6c%79%40%67%6d%61%69%6c%2e%63%6f%6d>obfuscated</a> We can also easily detect crawlers on our website and and block or rate-limit them. This, coupled with requiring javascript to display emails (either executing all the page's JS, or writing a custom crawler) (and the general tech-savvy of npm's users) makes it unlikely our website is a good ROI for an email spammer. |
That may be, but I still think that publishing emails might not be in the interrest of the developers. While this obfuscation is better than nothing (although JS is not required - it is a simple url encoding), it makes not much sense if the emails are leaked through other channels. For example, a single HTTP request to https://api.npms.io/v2/s... (I won't publish the entire URI here) returns at least 250 unencrypted emails at once. No custom crawler required. |
In this case I believe that obfuscation is not better than nothing, as it gives people a false sense of security. |
It's nice to know that some measures have been implemented, like obfuscation with javascript and crawler detection. |
Having public email on a website on 2017 is incredibly dumb and unacceptable for enterprise. |
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. As many others have pointed out, this isn't a 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? This isn't the only thread about email addresses on npm being public. See e.g. npm/policies#58, which I'm referencing to create a link between threads. |
@aredridel Still great interest in this more than one year later, and it's a factor blocking me from contributing. What's the status on this feature proposal? |
this is really f**** up. I just notices that my email is public on your website all the time. what are you guys thinking? It is like on no page like this... |
It's been more than a year since this issue was closed and no real answer from NPM has been given. @aredridel Could you give us an update? Your closing comment has 54 "thumbs down", something rarely seen in GitHub issues apart from personal attacks, so it's clear that people are outraged about this.
The way I see it there are multiple ways to do this:
Every software developer worth their salt would disagree with this statement. It would be beneficial to everyone if you could elaborate on what the real problem is. |
@aredridel @rockbot @jefflembeck @bcoe @ashleygwilliams @arobson @iarna @isaacs @soldair @zkat Sorry to resort to this, but I (and well over fifty other users adding reactions and comments to this issue over the past year) feel that this issue is a real deal-breaker, yet has been completely swept under the rug by the npm team. Contributors to the npm service have a right to privacy. How can npm, Inc defend this part of their privacy policy (13th Dec 2017 archive):
... given that involuntary disclosure is assured through the information being publicly accessible to any number of people and email-scraping bots circulating the internet? It's getting harder and harder to protect one's identity from spam and fraud these days, and npm doesn't afford even the most trivial protections against it at present. As mentioned in this thread, many users (myself included) are refusing to contribute as a result of the lack of privacy, or are resigned to using a temporary/fake email address, which prevents resolution of disputes over ownership and squatting. Please could we have a serious response about this issue and re-evaluate it as a real priority for the npm service? |
Hey all, thanks for taking the time to comment about this (and open up other issues regarding it). We know this is a serious subject and apologize for the time it has taken to get to a solution. Truth be told, as @aredridel mentioned a while back, we've kept emails available on public profiles as a mechanism for people to reach out to one another to handle package help and disputes. When email is not on the page, our support requests increase by a lot, and npm is not a large company with a huge support team (5 people for 11 million users). In making this decision and waiting for the time when our tiny web team (2.5 dedicated people - seriously) could get to creating a perfect solution, we've allowed this to go on for too long and instead put the problem on your (our users) shoulders, and this was the wrong thing to do. As you may have seen or heard, we're rewriting the website right now from the ground up. You can access it at https://preview.npmjs.com. It updates basically as we merge commits to master and is a beta, so I hope you can understand if it's missing some functionality or has a few bugs (feel free to open up issues here if you see them though, it's really quite helpful for our internal tracking)! You'll notice there that we've removed the email address from the profile page. This should be a permanent change. The new site will replace the old site in entirety quite soon, and when it does so, 🎉 . It will help us be able to address outstanding features like this a lot faster and will give you a lot better experience all together. We really hope you like it. Thanks again |
@jefflembeck If your intention is to permanently remove the email address from the profile page on the new website, why not make everyone happy in the meantime by just removing it from the current profile page too? Just deleting the code that renders the email should not take much time. |
If this was so important for everybody then how will you manage these sort of communications after the email removal? |
@LeonardoGentile the design decision of leaving the email on the profile page was made at a different time for npm. There were far fewer users and the average person with a profile was a person who was publishing packages (and those that were publishing packages were publishing a lot of them). 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. @MartinJohns You're not wrong that this should be a short and quick task, but we really are pushing and are focused on getting the new version of the site out, so we've put a freeze on the old code base. |
I was about to sign up, but the public email field really put me off. |
I dont like criticising people doing their best in a volunteer capacity but this really is almost unbelievable. I am not a big publisher but wanted to publish something today and was required to confirm my email. I wouldnt mind providing it to prevent spam or abuse of the service but I certainly wont be providing it to be published. I am just glad I didnt provide it in the first place. As mentioned above, this course of action will be counter productive as those that did provide an email will replace it with an less frequently monitored one and then you will have no way to contact them. Baffling |
@hpohlmeyer I was just wondering this too. Have email addresses "officially" been removed from the npm package page? I might change my fake email address for my real one if this is the case! |
As mentioned previously, we removed the email addresses from the profile page. They should no longer be publicly available on the website. |
Note that email addresses are still discoverable through registry metadata (as of writing this on 2018-04-13). For example, check the So, it's still appropriate to show the warning that email addresses are public (since they are for package publishers at least). But it is correct that they're no longer displayed on the website. |
Replica of https://webcache.googleusercontent.com/search?q=cache:aA5eZUjNlt0J:https://github.com/npm/npm-www/issues/569+&cd=1&hl=en&ct=clnk&gl=ca (posted by @davidbourguignon)
It doesn't look like it's been resolved yet.
The text was updated successfully, but these errors were encountered: