Martin from GitHub here - the offending repos have been taken down, but the article from Roman is still very much worth reading to understand the attack vector attempted.
595 karma · joined November 15, 2016
That post has a link to the FAQ which might also be helpful: https://github.com/orgs/community/discussions/188488
Previously we didn’t do any training on usage. However as other products have come into the market they do train on usage. We’ve been training on our internal usage for just over a year and have seen some major improvements. For details see of the types of improvements we’ve seen from training on our internal usage check out this article: https://github.blog/news-insights/product-news/copilot-new-e...
For users of Free, Pro and Pro+ Copilot, if you don’t opt out then we will start collecting usage data of Copilot for use in model training.
If you are a subscriber for Business or Pro we do not train on usage.
The blog post covers more details but we do not train on private repo data at rest, just interaction data with Copilot. If you don’t use Copilot this will not affect you. However you can still opt out now if you wish and that preference will be retained if you decide to start using Copilot in the future.
Hope that helps.
Sounds like you are already opted out because you'd previously opted out of the setting allowing GitHub to collect this data for product improvements. But I can check that.
Note, it's only _usage_ data when using Copilot that is being trained on. Therefore if you are not using Copilot there is no usage data. We do not train on private data at rest in your repos etc.
Usually starts with contacting them over email reminding them of the terms of service and warning them to stop. Then their account might get deactivated and they need to write and promise to not be naughty again. If they ignore that then the account gets removed.
There are a bunch of automated checks that are running all the time as well and will take automated action that then gets later reviewed by humans. At lot of times the process is fast-tracked.
The off-platform 'let's scrape a bunch of data and then spam nice people' is the hardest to police. Linking those mails to an offending GitHub account is hard and very manual, also anyone can send emails saying they are someone they are not and because of that anyone can deny they sent the mail and they'll usually blame a rogue agency they where working with etc.
I probably shouldn't say it, but the public shame that comes from being mentioned on social, in hacker news etc. That stops people who want to be treated as legitimate from doing that sort of thing and helps educate the wider community around what is and isn't acceptable behaviour - that is why it's good to see this thread and see the issue getting attention.
The fundamental nature of Git makes this pretty easy for folks to scrape data from open source repositories. It's against our terms of service and those folks might want to talk with some lawyers about doing it - but as every Git commit contains your name and email address in the commit data it's not technically difficult even if it is unethical.
From the early days we've added features to help users anonymise their email addresses for commits posted to GitHub. Basically, you configure your local Git client to use your 'no-reply' email address in commits and that still links back to your GitHub account when you push: https://docs.github.com/en/account-and-profile/reference/ema...
I think that's still probably the best route. We want to keep open source data as open as possible, so I don't think locking down API's etc is the right route. We do throttle API requests and scraping traffic, but then again there have been plenty of posts here over the years from people annoyed at hitting those limits so it's definitely a balancing act. Love to know what folks here think though.
We've had the ability to temporarily disable PR's for a while for maintainers but we felt like it was time to look at this again and see what folks think.
What I find most interesting is how consistent that top 10 list is with the Octoverse data. We have to look much further down the table to see the cool kids like Rust, Go or Lua. While growing very fast there is just so much code out there in Javascript, Typescript, Python, Java, C#, C++ etc that is takes a lot for a language to move up the charts.
That said, while I generally caution against an unhealthy interest in Stars - what the OSS Insight data does a decent job of showing is the activity and interest in the open source languages communities. Rust is clearly incredibly strong there along with things like TypeScript, Go, Python etc. But it's also heartening to see the strength in open source language ecosystems such as Swift, Java & .NET but also some surprises such as PowerShell or the more academic languages like OCAML.
https://github.blog/2020-12-17-no-cookie-for-you/
https://docs.github.com/en/account-and-profile/setting-up-an...
In this instance we don't think it will hurt the social coding experience of open source and in fact might encourage folks who would otherwise be put off. But we are testing this particular feature and will keep iterating on it depending how things go and what the feedback is.
But in the end went with simple. There will be a very limited subset that will render this way - executing raw code without the users permission in the browser just opens up too much attack surface area that we’d need a very compelling use case to do the security work necessary to make it protected (even if that was possible)