7 ms·

Yes, these kinds of marketing tactics are disgusting and despicable, but the broader issue is why does Github facilitate them by making user emails discoverable

Yes, these kinds of marketing tactics are disgusting and despicable, but the broader issue is why does Github facilitate them by making user emails discoverable? There are tools like github-email [1], which allow you to: > Retrieve a GitHub user's email even if it's not public. Pulls info from Github user, NPM, activity commits, owned repo commit activity. Why does Github have so many ways to exfiltrate a user's email address? [1]https://github.com/paulirish/github-email https://github.com/paulirish/github-email

deleted 5y ago
[deleted]
lmz 5y ago
Because the email is part of a Git commit (author and committer information) and your Github repo has public Git commits. "man git-commit" and search for "email" for details.
- Ansil849 5y ago
  Yes, I'm aware of how commits work, my point is that this kind of practice goes hand in hand with making it easy for spammers to harvest user emails.
  - fuzzy2 5y ago
    You're barking up the wrong tree. It's Git, and nothing else, that is to blame. Should GitHub stop being a Git host?
    - Ansil849 5y ago
      The problem is spammers harvesting emails. Git* makes harvesting emails ridiculously easy. Therefore some solutions are needed (e.g. using Github-assigned email address aliases instead of user-supplied email addresses).
      - fuzzy2 5y ago
        Git hosting services cannot change the address on the actual commits, so trying to hide it on the web frontend is pretty pointless. You could always just clone the repo to get the addresses. It will always be up to the user to set it up in a way they want. Well I guess GitHub could refuse non-GitHub e-mail addresses when pushing, but let's seriously not go there.
        MatthiasPortzel 5y ago
        > GitHub could refuse non-GitHub e-mail addresses when pushing This already exists as an option. GitHub does as much as they can to protect e-mail privacy without making it impossible to use an email.
      - lmz 5y ago
        The emails are part of the commit hash. https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-g... - good luck comparing them when the emails have been rewritten.
    - throwaway81523 5y ago
      That's just a convention in git. I always use fake emails in commits and nothing has happened to me.
      - fuzzy2 5y ago
        Yes and no. No, it is not a convention. A commit must contain an e-mail address. That’s how the data structure is specified. Of course, whether you use an existing e-mail address or whatever is entirely up to you. I’m not sure if it needs to be RFC-compliant. Still, even a fake address will be visible to everyone.
        throwaway81523 5y ago
        Using something with the syntax of an email address is a requirement. Having that be a real, deliverable email address is a convention. If it's a fake address, then sure, spammers can see it, but spamming it is useless to them.
Shared404 5y ago
Given that having an email address attached to commits is a fairly standard component of git, is there a way to prevent this? Short of using burner/fake email addresses of course
- mwt 5y ago
  The only (remotely) effective strategy I've seen is to use burners that only show up in commits and then report all companies using them to GitHub itself in the hopes that eventually those companies will somehow be reprimanded. Of course, the problems with this strategy are that the manual work scales poorly, there are two or more points of failure, and the best outcome is only marginally positive, doing nothing to deter future abuse.
  - myself248 5y ago
    > the best outcome is only marginally positive, doing nothing to deter future abuse. This is the problem with virtually all spam remedies so far. If the penalty is that their success rate merely goes down, well it's already dismal, what's another few percent even matter? The economics are massively in their favor. Until they start getting kicked off platforms for a certain number of spam complaints, the way creators get kicked off platforms for a certain number of DMCA strikes (which can be bogus, that's a problem I'd not like to copy), there's nothing incentivizing them to really, really hesitate and check with legal before pulling the trigger on an email. Spammers should live in fear. Until we make that happen, nothing will change.
    - mwt 5y ago
      > Until they start getting kicked off platforms for a certain number of spam complaints This is even far from a solution. The spam I get is always from a newsletter or "startup" I had never heard of before. This leads me to believe MyMachineLearningNewsletterForum will just rebrand under a new name if they were ever given some death penalty from the Internet (putting aside how infeasible that is).
    - throwaway81523 5y ago
woodruffw 5y ago
GitHub behaves similarly to git, which uses emails as a weak form of identity. They’re not meant to be private in git’s model, and having them be public is not a serious problem absent bad actors (who should be banned for violating GitHub’s TOS).

deleted 5y ago

[deleted]

lmz 5y ago

Because the email is part of a Git commit (author and committer information) and your Github repo has public Git commits. "man git-commit" and search for "email" for details.

Ansil849 5y ago
Yes, I'm aware of how commits work, my point is that this kind of practice goes hand in hand with making it easy for spammers to harvest user emails.
- fuzzy2 5y ago
  You're barking up the wrong tree. It's Git, and nothing else, that is to blame. Should GitHub stop being a Git host?
  - Ansil849 5y ago
    The problem is spammers harvesting emails. Git* makes harvesting emails ridiculously easy. Therefore some solutions are needed (e.g. using Github-assigned email address aliases instead of user-supplied email addresses).
    - fuzzy2 5y ago
      Git hosting services cannot change the address on the actual commits, so trying to hide it on the web frontend is pretty pointless. You could always just clone the repo to get the addresses. It will always be up to the user to set it up in a way they want. Well I guess GitHub could refuse non-GitHub e-mail addresses when pushing, but let's seriously not go there.
      - MatthiasPortzel 5y ago
        > GitHub could refuse non-GitHub e-mail addresses when pushing This already exists as an option. GitHub does as much as they can to protect e-mail privacy without making it impossible to use an email.
    - lmz 5y ago
      The emails are part of the commit hash. https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-g... - good luck comparing them when the emails have been rewritten.
  - throwaway81523 5y ago
    That's just a convention in git. I always use fake emails in commits and nothing has happened to me.
    - fuzzy2 5y ago
      Yes and no. No, it is not a convention. A commit must contain an e-mail address. That’s how the data structure is specified. Of course, whether you use an existing e-mail address or whatever is entirely up to you. I’m not sure if it needs to be RFC-compliant. Still, even a fake address will be visible to everyone.
      - throwaway81523 5y ago
        Using something with the syntax of an email address is a requirement. Having that be a real, deliverable email address is a convention. If it's a fake address, then sure, spammers can see it, but spamming it is useless to them.

Shared404 5y ago

Given that having an email address attached to commits is a fairly standard component of git, is there a way to prevent this? Short of using burner/fake email addresses of course

mwt 5y ago
The only (remotely) effective strategy I've seen is to use burners that only show up in commits and then report all companies using them to GitHub itself in the hopes that eventually those companies will somehow be reprimanded. Of course, the problems with this strategy are that the manual work scales poorly, there are two or more points of failure, and the best outcome is only marginally positive, doing nothing to deter future abuse.
- myself248 5y ago
  > the best outcome is only marginally positive, doing nothing to deter future abuse. This is the problem with virtually all spam remedies so far. If the penalty is that their success rate merely goes down, well it's already dismal, what's another few percent even matter? The economics are massively in their favor. Until they start getting kicked off platforms for a certain number of spam complaints, the way creators get kicked off platforms for a certain number of DMCA strikes (which can be bogus, that's a problem I'd not like to copy), there's nothing incentivizing them to really, really hesitate and check with legal before pulling the trigger on an email. Spammers should live in fear. Until we make that happen, nothing will change.
  - mwt 5y ago
    > Until they start getting kicked off platforms for a certain number of spam complaints This is even far from a solution. The spam I get is always from a newsletter or "startup" I had never heard of before. This leads me to believe MyMachineLearningNewsletterForum will just rebrand under a new name if they were ever given some death penalty from the Internet (putting aside how infeasible that is).
  - throwaway81523 5y ago

woodruffw 5y ago

GitHub behaves similarly to git, which uses emails as a weak form of identity. They’re not meant to be private in git’s model, and having them be public is not a serious problem absent bad actors (who should be banned for violating GitHub’s TOS).