6 ms·

If you need privacy then you shouldn’t be uploading to GitHub in the first place. The moment you do that you’re publishing email addresses, other projects that

If you need privacy then you shouldn’t be uploading to GitHub in the first place. The moment you do that you’re publishing email addresses, other projects that you contribute too and potentially leaking your timezone by virtue of commit times. Your SSH public key is really the least of your identifiable information you’d be worried about because that’s the easiest to create a unique key for GitHub.

Gargyle 5y ago
Its actually the same thing. A shared identifier. Of course email is another thing to separate for separate identities. But it is way more widely known that email adresses are used ad an unique identifier.
- laumars 5y ago
  That’s my point though. If you’re concerned about privacy enough that even a throwaway SSH public key is sensitive then GitHub (and even any public git repository) is going to be a bad idea because they’re going to be leaking far more identifiable data than just your SSH public key. If you agree that said platforms leak lots of other identifiable data (which you seam to) then thus it is a fair statement to say GitHub hiding public keys do little to enhance your privacy. And thus one can reasonably conclude that privacy argument doesn’t really hold with regards to SSH keys. I’m happy to agree that it’s bad UX and probably should be advertised better so people are aware they should follow the (in my opinion best practice) of using a unique SSH key for GitHub.
  - Gargyle 5y ago
    You might have gotten me having this too narrow to be broadly useful. Because we were already arguing about a detail and I concentrate just on this detail, not a general github privacy overview. The whole intention was to raise attention to a less often mentioned part of the information github exposes about accounts.
  - deleted 5y ago
    [deleted]
eli 5y ago
Information being made public or shared with others against the user’s expectation is always bad. I agree that’s it’s more a documentation and UX issue than a security concern, but it’s not nothing.
- windexh8er 5y ago
  This is how I see it as well. May I have all of your usernames? No, but those are "public" in the spirit of this thread as well. However most are protective of them. Maybe you use a very specific email address for a password manager that you don't use with anything else. I wouldn't want a SaaS service automatically saying - "Oh you know <username>? This is an email they use." Just because the functional security of a system isn't dependent on the exposure of a public component doesn't mean it should implicitly be shared.
  - laumars 5y ago
    I’m not aware of any service that is protective over usernames. Some don’t allow scraping of user profiles for “privacy” reasons but that always struck me as a shallow excuse given they’re publishing them anyway - I often suspected the real reason was more that profile data is valuable for analytics so they’d rather offer deals selling that data. Deals that are undercut by scrapers. Some platforms don’t publish users lists but it’s often the same platforms that like to post headline figures about their user base so I suspect not publishing user lists is more about a company being able to exaggerate its worth rather than privacy. Especially when those same platforms readily publish user names in every format aside one consolidated list. In short, if a piece of information isn’t available on a social platform, or is frowned upon scraping, then odds are it’s more likely financially motivated than it is down to privacy. Given these same companies typically make their money from you handing over your data in the first place it would be naive to think they really care about your privacy.
- mmcnl 5y ago
  Exactly. Even if it's a "public" key. Public can be interpreted in different ways.
- 5y ago
andylynch 5y ago
You can go long way with an anonymous gmail address (this is what whoever from GCHQ do on their open source GitHub stuff)
- numair 5y ago
  You know, if I was 17 and bored, I’d look up all of the keys for all of the people from national security agencies that have contributed to open source projects on GitHub and see if anything noteworthy turns up anywhere.
  - semiquaver 5y ago
    What you describe isn’t possible since commits are not associated publicly with SSH keys in any way.
    - gpm 5y ago
      They are if you sign them...
      - larusso 5y ago
        you mean gpg sign? By the way the gpg public keys are also available via a URL. https://github.com/Larusso.gpg https://github.com/Larusso.gpg Edit If course you mean the new signing feature which will come to git and GitHub in the future. Sorry
        gpm 5y ago
        You're entirely right, just a brain fart on my part that those are different keys. Not sure why you're downvoted.
  - lou1306 5y ago
    Somewhat related: a friend of mine crawled across a ton of publicly available PDFs from several security agencies and found a lot of interesting metadata about their setup (stuff like OS version, word processor of choice, even the author's names in some cases). https://therecord.media/security-agencies-leak-sensitive-data-by-failing-to-sanitize-pdf-files/ https://therecord.media/security-agencies-leak-sensitive-dat...
throwaway09223 5y ago
"If you need privacy then you shouldn’t be uploading to GitHub in the first place." Nonsense. Would you say the same thing about a password? Would you make the same comment about a conversation over a messaging service? This is a configuration detail of an account setting -- not a blog post. Privacy is not binary; there are many shades of grey. It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out.
- laumars 5y ago
  > Would you say the same thing about a password? Passwords are secrets. Public keys are not. So the comparison doesn’t work. > Would you make the same comment about a conversation over a messaging service? If it was a public messaging service like HN, or public comments on Twitter or Facebook, then yes. > This is a configuration detail of an account setting -- not a blog post. We could be here all day and night saying what this is or isn’t but it doesn’t address the point I was making. The moment you create a GitHub account you start leaking far more sensitive data than your public keys. Data that is far harder to create anonymously (unlike your SSH keys). Thus if privacy is a concern then you shouldn’t be using GitHub in the first place. Even git version control itself leaks information about you. > Privacy is not binary; there are many shades of grey. Ironic you state that when you’re the one applying privacy in a binary way. I’m saying the SSH public keys are a lower risk than other details you share in GitHub. Not that it’s a zero or 100% bad thing, which is the only pidgin holes you’re allowing for this discussion. > It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out. That’s literally the point I’ve been making.
  - crazydoggers 5y ago
    Thanks for making this point clear. I think a lot of people have been clinging to the idea that there is such a thing as privacy with online public services. The parents quote I think is illustrative > But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.” And I’m not trying to pile on here, because I sympathize with that sentiment of “should”. But I think the two issues that make that never a real possibility are 1) privacy is actually a harder problem to solve than security and 2) companies aren’t incentivized to provide privacy. Anything you provide online should by default be assumed to end up public, and as much as we might not want that, we all really need to assume that.
cillian64 5y ago
My public key would still be published even if I only ever dealt with private repos, so this argument doesn’t hold.
- laumars 5y ago
  You profile isn’t private - regardless of whether you contribute to any repositories (even just private) or not.
  - remram 5y ago
    What would that "profile" show though, apart from your username? Email can be hidden, as well as contribution dates/volume to private repos.
    - laumars 5y ago
      Exactly the same as what the public SSH shows you: ie nothing of any direct risk but an identifiable piece of meta data to someone determined enough assuming the person creating that profile didn’t bother to enter anonymised information for GitHub. So your argument against SSH keys are just as valid for all the other items of meta data you’re dismissing as not a privacy problem. And that’s the point I’m making. If you care enough about privacy that your public SSH key is an issue, then creating a GitHub account is not the brightest idea regardless of their policy on public SSH keys. I don’t disagree that GitHub could do a better job documenting this risk nor that an ideal scenario would be giving users the option. But they’re all just side stepping the real issue that this is not a privacy because of the fact that public SSH keys are not more of a risk than any of the other data you’re already volunteering to be published by virtue of signing up to a social platform. If you want privacy then host your own git server (it’s really easy!) because GitHub is designed around sharing, not privacy. It’s weird the number of people here who don’t realise that convenience and privacy are often opposing forces and I bet the majority complaining don’t even pay for their GitHub account. Yet they are still complaining about specific aspects of privacy while willingly handing over a crap load more identifiable information for free. The whole debate here screams of security theatre: privacy for show rather than actual safeguarding of personally identifiable data.
jchw 5y ago
Actually, GitHub now defaults to obfuscating email address and has an easily accessible option which will reject any push that inadvertently reveals it. Also, plenty of people collaborate in private on GitHub. It has free private collaboration these days, not to mention.. paid. While it never strongly irked me that SSH public keys are visible, it’s not really that obvious. And I don’t buy the “but it has public in the name!” bit either. Sure, it’s not made to be confidential, but that doesn’t mean it should be published indiscriminately. I mean, I’m using it to authenticate to GitHub, and nobody browsing GitHub needs it. Having them visible by default can be convenient. I’ve used it to populate authorized_hosts for example. However it is unnecessary and unexpected. If you use different private keys on each machine, it reveals a lot of opsec info you may not have expected to be public. It’s a “public” key in the cryptographic sense, not in the address book sense.
- int_19h 5y ago
  It's visible so that your commits that are signed by that key can be verified by other GitHub users. There's an option somewhere in settings that makes it so that any commit from you that is not signed is automatically flagged.
  - jchw 5y ago
    Signing Git commits by SSH public key is brand new. GitHub has been doing this since before SSH or Git supported this.
csdvrx 5y ago
> Your SSH public key is really the least of your identifiable information you’d be worried about I disagree. The article points to simplifications that SSH did compared to GPG, like no web of trust. But there's now something very close to one, a bit hidden though: SSHFP + DNSSEC I think a lot of people here may not be familiar with SSHFP records, so check https://fanf.livejournal.com/130577.html https://fanf.livejournal.com/130577.html for a more detailed explanation. It's more or less a work around the problem of initially trusting a key, by using SSHFP records to verify that the server keys are validated by the domain, with DNSSEC validating the whole thing. When you can match server keys to domains and user keys to github users, you are just one link away from having a global picture of the web of trust. EDIT: and I wonder how feasible it would be to do just that with a sniff of the initial handshake > because that’s the easiest to create a unique key for GitHub And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use? I hate to say this, but Bitcoin did it right: by having a discardable private+public pair of keys derived from a seed key, it prevents leaks of information by correlation based on the public key.
- laumars 5y ago
  > And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use? Equally they might use the same user name as on other services, thus making them traceable. Ultimately if you care about privacy then it’s up to you, the individual, not to share that information or to provide anonymous information yourself. Sharing identifiable information and then blaming the company you shared it with is like blaming the horse for bolting after you’ve intentionally left the barn door open. Sure it should be that way but ultimately it’s your own responsibility to keep your stuff safe. I’d agree with your point more if you were advocating that documentation should be more explicit. Ie helping educate users into making smarter choices.
- numair 5y ago
  Thanks for posting this — it’s super-interesting. It seems as though it’s more about authenticating the server rather than the user, unless I read it wrong? The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014? I would love to test it out, but life is too short for the process they’ve outlined...

Gargyle 5y ago

Its actually the same thing. A shared identifier. Of course email is another thing to separate for separate identities. But it is way more widely known that email adresses are used ad an unique identifier.

laumars 5y ago
That’s my point though. If you’re concerned about privacy enough that even a throwaway SSH public key is sensitive then GitHub (and even any public git repository) is going to be a bad idea because they’re going to be leaking far more identifiable data than just your SSH public key. If you agree that said platforms leak lots of other identifiable data (which you seam to) then thus it is a fair statement to say GitHub hiding public keys do little to enhance your privacy. And thus one can reasonably conclude that privacy argument doesn’t really hold with regards to SSH keys. I’m happy to agree that it’s bad UX and probably should be advertised better so people are aware they should follow the (in my opinion best practice) of using a unique SSH key for GitHub.
- Gargyle 5y ago
  You might have gotten me having this too narrow to be broadly useful. Because we were already arguing about a detail and I concentrate just on this detail, not a general github privacy overview. The whole intention was to raise attention to a less often mentioned part of the information github exposes about accounts.
- deleted 5y ago
  [deleted]

eli 5y ago

Information being made public or shared with others against the user’s expectation is always bad. I agree that’s it’s more a documentation and UX issue than a security concern, but it’s not nothing.

windexh8er 5y ago
This is how I see it as well. May I have all of your usernames? No, but those are "public" in the spirit of this thread as well. However most are protective of them. Maybe you use a very specific email address for a password manager that you don't use with anything else. I wouldn't want a SaaS service automatically saying - "Oh you know <username>? This is an email they use." Just because the functional security of a system isn't dependent on the exposure of a public component doesn't mean it should implicitly be shared.
- laumars 5y ago
  I’m not aware of any service that is protective over usernames. Some don’t allow scraping of user profiles for “privacy” reasons but that always struck me as a shallow excuse given they’re publishing them anyway - I often suspected the real reason was more that profile data is valuable for analytics so they’d rather offer deals selling that data. Deals that are undercut by scrapers. Some platforms don’t publish users lists but it’s often the same platforms that like to post headline figures about their user base so I suspect not publishing user lists is more about a company being able to exaggerate its worth rather than privacy. Especially when those same platforms readily publish user names in every format aside one consolidated list. In short, if a piece of information isn’t available on a social platform, or is frowned upon scraping, then odds are it’s more likely financially motivated than it is down to privacy. Given these same companies typically make their money from you handing over your data in the first place it would be naive to think they really care about your privacy.
mmcnl 5y ago
Exactly. Even if it's a "public" key. Public can be interpreted in different ways.
5y ago

andylynch 5y ago

You can go long way with an anonymous gmail address (this is what whoever from GCHQ do on their open source GitHub stuff)

numair 5y ago
You know, if I was 17 and bored, I’d look up all of the keys for all of the people from national security agencies that have contributed to open source projects on GitHub and see if anything noteworthy turns up anywhere.
- semiquaver 5y ago
  What you describe isn’t possible since commits are not associated publicly with SSH keys in any way.
  - gpm 5y ago
    They are if you sign them...
    - larusso 5y ago
      you mean gpg sign? By the way the gpg public keys are also available via a URL. https://github.com/Larusso.gpg https://github.com/Larusso.gpg Edit If course you mean the new signing feature which will come to git and GitHub in the future. Sorry
      - gpm 5y ago
        You're entirely right, just a brain fart on my part that those are different keys. Not sure why you're downvoted.
- lou1306 5y ago
  Somewhat related: a friend of mine crawled across a ton of publicly available PDFs from several security agencies and found a lot of interesting metadata about their setup (stuff like OS version, word processor of choice, even the author's names in some cases). https://therecord.media/security-agencies-leak-sensitive-data-by-failing-to-sanitize-pdf-files/ https://therecord.media/security-agencies-leak-sensitive-dat...

throwaway09223 5y ago

"If you need privacy then you shouldn’t be uploading to GitHub in the first place." Nonsense. Would you say the same thing about a password? Would you make the same comment about a conversation over a messaging service? This is a configuration detail of an account setting -- not a blog post. Privacy is not binary; there are many shades of grey. It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out.

laumars 5y ago
> Would you say the same thing about a password? Passwords are secrets. Public keys are not. So the comparison doesn’t work. > Would you make the same comment about a conversation over a messaging service? If it was a public messaging service like HN, or public comments on Twitter or Facebook, then yes. > This is a configuration detail of an account setting -- not a blog post. We could be here all day and night saying what this is or isn’t but it doesn’t address the point I was making. The moment you create a GitHub account you start leaking far more sensitive data than your public keys. Data that is far harder to create anonymously (unlike your SSH keys). Thus if privacy is a concern then you shouldn’t be using GitHub in the first place. Even git version control itself leaks information about you. > Privacy is not binary; there are many shades of grey. Ironic you state that when you’re the one applying privacy in a binary way. I’m saying the SSH public keys are a lower risk than other details you share in GitHub. Not that it’s a zero or 100% bad thing, which is the only pidgin holes you’re allowing for this discussion. > It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out. That’s literally the point I’ve been making.
- crazydoggers 5y ago
  Thanks for making this point clear. I think a lot of people have been clinging to the idea that there is such a thing as privacy with online public services. The parents quote I think is illustrative > But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.” And I’m not trying to pile on here, because I sympathize with that sentiment of “should”. But I think the two issues that make that never a real possibility are 1) privacy is actually a harder problem to solve than security and 2) companies aren’t incentivized to provide privacy. Anything you provide online should by default be assumed to end up public, and as much as we might not want that, we all really need to assume that.

cillian64 5y ago

My public key would still be published even if I only ever dealt with private repos, so this argument doesn’t hold.

laumars 5y ago
You profile isn’t private - regardless of whether you contribute to any repositories (even just private) or not.
- remram 5y ago
  What would that "profile" show though, apart from your username? Email can be hidden, as well as contribution dates/volume to private repos.
  - laumars 5y ago
    Exactly the same as what the public SSH shows you: ie nothing of any direct risk but an identifiable piece of meta data to someone determined enough assuming the person creating that profile didn’t bother to enter anonymised information for GitHub. So your argument against SSH keys are just as valid for all the other items of meta data you’re dismissing as not a privacy problem. And that’s the point I’m making. If you care enough about privacy that your public SSH key is an issue, then creating a GitHub account is not the brightest idea regardless of their policy on public SSH keys. I don’t disagree that GitHub could do a better job documenting this risk nor that an ideal scenario would be giving users the option. But they’re all just side stepping the real issue that this is not a privacy because of the fact that public SSH keys are not more of a risk than any of the other data you’re already volunteering to be published by virtue of signing up to a social platform. If you want privacy then host your own git server (it’s really easy!) because GitHub is designed around sharing, not privacy. It’s weird the number of people here who don’t realise that convenience and privacy are often opposing forces and I bet the majority complaining don’t even pay for their GitHub account. Yet they are still complaining about specific aspects of privacy while willingly handing over a crap load more identifiable information for free. The whole debate here screams of security theatre: privacy for show rather than actual safeguarding of personally identifiable data.

jchw 5y ago

Actually, GitHub now defaults to obfuscating email address and has an easily accessible option which will reject any push that inadvertently reveals it. Also, plenty of people collaborate in private on GitHub. It has free private collaboration these days, not to mention.. paid. While it never strongly irked me that SSH public keys are visible, it’s not really that obvious. And I don’t buy the “but it has public in the name!” bit either. Sure, it’s not made to be confidential, but that doesn’t mean it should be published indiscriminately. I mean, I’m using it to authenticate to GitHub, and nobody browsing GitHub needs it. Having them visible by default can be convenient. I’ve used it to populate authorized_hosts for example. However it is unnecessary and unexpected. If you use different private keys on each machine, it reveals a lot of opsec info you may not have expected to be public. It’s a “public” key in the cryptographic sense, not in the address book sense.

int_19h 5y ago
It's visible so that your commits that are signed by that key can be verified by other GitHub users. There's an option somewhere in settings that makes it so that any commit from you that is not signed is automatically flagged.
- jchw 5y ago
  Signing Git commits by SSH public key is brand new. GitHub has been doing this since before SSH or Git supported this.

csdvrx 5y ago

> Your SSH public key is really the least of your identifiable information you’d be worried about I disagree. The article points to simplifications that SSH did compared to GPG, like no web of trust. But there's now something very close to one, a bit hidden though: SSHFP + DNSSEC I think a lot of people here may not be familiar with SSHFP records, so check https://fanf.livejournal.com/130577.html https://fanf.livejournal.com/130577.html for a more detailed explanation. It's more or less a work around the problem of initially trusting a key, by using SSHFP records to verify that the server keys are validated by the domain, with DNSSEC validating the whole thing. When you can match server keys to domains and user keys to github users, you are just one link away from having a global picture of the web of trust. EDIT: and I wonder how feasible it would be to do just that with a sniff of the initial handshake > because that’s the easiest to create a unique key for GitHub And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use? I hate to say this, but Bitcoin did it right: by having a discardable private+public pair of keys derived from a seed key, it prevents leaks of information by correlation based on the public key.

laumars 5y ago
> And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use? Equally they might use the same user name as on other services, thus making them traceable. Ultimately if you care about privacy then it’s up to you, the individual, not to share that information or to provide anonymous information yourself. Sharing identifiable information and then blaming the company you shared it with is like blaming the horse for bolting after you’ve intentionally left the barn door open. Sure it should be that way but ultimately it’s your own responsibility to keep your stuff safe. I’d agree with your point more if you were advocating that documentation should be more explicit. Ie helping educate users into making smarter choices.
numair 5y ago
Thanks for posting this — it’s super-interesting. It seems as though it’s more about authenticating the server rather than the user, unless I read it wrong? The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014? I would love to test it out, but life is too short for the process they’ve outlined...