Comments (34)
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.
from www.
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.
from www.
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 !
from www.
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.
from www.
+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/
from www.
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.
from www.
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.
from www.
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
from www.
(if) when someone disputes
she/he should open a issue on the repo, not the email
looks like product team's radar
is broken 💔
from www.
@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):
We do not disclose your personal information to unaffiliated third parties who may want to offer you their own products and services unless you have requested or authorized us to do so.
... 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?
from www.
Note that email addresses are still discoverable through registry metadata (as of writing this on 2018-04-13). For example, check the maintainers
field here: https://registry.npmjs.org/abbrev
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.
from www.
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.
from www.
Having public email on a website on 2017 is incredibly dumb and unacceptable for enterprise.
Allow hiding email until you provide an internal messaging system, there's no excuse.
Another honorable mention npm login
CLI should not require email either!
from www.
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.
from www.
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.
We hear you, and we want to solve it right.
The way I see it there are multiple ways to do this:
- Don't show the email at all. This is the simplest way and in my opinion the right solution, for reasons already explained by other users.
- Don't show the email to non-authenticated users. This is also very simple and some middle-ground if you for some reason don't want to hide the email address completely.
- Obfuscate the email using one of many well-known techniques, many of which are likely published as packages on NPM itself. This would make the email address visible to only human beings. In my opinion, this is the least desirable option.
This isn't simple and there is some importance of allowing users to contact each other in the case of disputes.
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.
from www.
@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?
from www.
@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 hope that this is understandable.
from www.
I was about to sign up, but the public email field really put me off.
But after looking at several profiles, I could not find any email. Did you remove them from the profiles, or am I looking in the wrong places?
from www.
As mentioned previously, we removed the email addresses from the profile page. They should no longer be publicly available on the website.
from www.
GEEEZZZ!
from www.
@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.
from www.
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
from www.
This a very basic settings option; there is no logic reason to not allow it for us.
from www.
This is a bit daft. Please fix it...
from www.
NodeJS -> not working for enterprise since 2009.
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.
This. This is exactly what I just did.
from www.
+1. Pls fix it.
from www.
Any update on this?
from www.
Using temporary email address is a workaround, but it feels like using an early php forum.
from www.
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.
from www.
In this case I believe that obfuscation is not better than nothing, as it gives people a false sense of security.
from www.
It's nice to know that some measures have been implemented, like obfuscation with javascript and crawler detection.
I ended up just creating a new email for npm and be done with it.
from www.
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...
from www.
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.
If this was so important for everybody then how will you manage these sort of communications after the email removal?
Are you planning to implement the already mentioned internal message system for communication between users or not?
from www.
@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!
from www.
Related Issues (20)
- the image in the README is displayed beyond the screen HOT 1
- how can we close Solr Connection once it open
- Readability issues with new code block font HOT 2
- Readmes missing after publishing a new package HOT 6
- "@" in the install instruction is cut off
- unexpected status code from user-acl: 500 when trying to create a new account
- NPM Package UI (CSS) Breaking For My Package
- problem with rtl
- Links in h1 titles in packages' README files are hidden
- npmjs.org always assumes that all dependencies are on npmjs.org and ends up linking to unrelated packages. HOT 1
- Not able to install via npm
- Package search shows wrong date and version
- Index out of bounds exception when navigating to a member page past maximum
- Wrong documentation last modified date in docs.npmjs.com (October 26, 1985)
- Search result shows old version HOT 1
- 2fa recovery codes truncated HOT 1
- Provide links for specific tags at the top of the package details page (Readme, admin, dependencies, etc)
- Home page link url is incorrect HOT 2
- Repository link url is broken HOT 1
- Searchbar for @scoped packages
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from www.