Git Product home page Git Product logo

Comments (34)

aredridel avatar aredridel commented on July 18, 2024 67

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.

StanDog avatar StanDog commented on July 18, 2024 42

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.

Aymkdn avatar Aymkdn commented on July 18, 2024 27

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.

jspizziri avatar jspizziri commented on July 18, 2024 17

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.

c0b avatar c0b commented on July 18, 2024 12

+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.

denizdogan avatar denizdogan commented on July 18, 2024 11

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.

dgw avatar dgw commented on July 18, 2024 11

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.

jefflembeck avatar jefflembeck commented on July 18, 2024 9

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.

ryh avatar ryh commented on July 18, 2024 8

(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.

shirakaba avatar shirakaba commented on July 18, 2024 7

@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.

isaacs avatar isaacs commented on July 18, 2024 7

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.

StanDog avatar StanDog commented on July 18, 2024 6

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.

lethevimlet avatar lethevimlet commented on July 18, 2024 6

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.

ricardonunesdev avatar ricardonunesdev commented on July 18, 2024 5

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.

denizdogan avatar denizdogan commented on July 18, 2024 5

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.

shirakaba avatar shirakaba commented on July 18, 2024 4

@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.

jefflembeck avatar jefflembeck commented on July 18, 2024 3

@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.

hpohlmeyer avatar hpohlmeyer commented on July 18, 2024 3

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.

jefflembeck avatar jefflembeck commented on July 18, 2024 2

As mentioned previously, we removed the email addresses from the profile page. They should no longer be publicly available on the website.

from www.

tomscholz avatar tomscholz commented on July 18, 2024 1

GEEEZZZ!

from www.

MartinJohns avatar MartinJohns commented on July 18, 2024 1

@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.

davepile avatar davepile commented on July 18, 2024 1

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.

gugadev avatar gugadev commented on July 18, 2024

This a very basic settings option; there is no logic reason to not allow it for us.

from www.

 avatar commented on July 18, 2024

This is a bit daft. Please fix it...

from www.

et304383 avatar et304383 commented on July 18, 2024

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.

pi-dash avatar pi-dash commented on July 18, 2024

+1. Pls fix it.

from www.

LeonardoGentile avatar LeonardoGentile commented on July 18, 2024

Any update on this?

from www.

 avatar commented on July 18, 2024

Using temporary email address is a workaround, but it feels like using an early php forum.

from www.

aearly avatar aearly commented on July 18, 2024

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.

derekphilipau avatar derekphilipau commented on July 18, 2024

In this case I believe that obfuscation is not better than nothing, as it gives people a false sense of security.

from www.

ricardonunesdev avatar ricardonunesdev commented on July 18, 2024

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.

monbro avatar monbro commented on July 18, 2024

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.

LeonardoGentile avatar LeonardoGentile commented on July 18, 2024

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.

tsmith123 avatar tsmith123 commented on July 18, 2024

@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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.