> Giving a website access to star repos through the API for my convenience is not anything I should be banned over though.
Sorry, hard disagree. You have responsibility, here. We all do. Be extremely wary of what privileges you are giving away, and do not hesitate to forgo sign-in when the privileges are unreasonable.
Why would anyone click "yes" to a random site that wants control over their Github starring privileges without a clear explanation as to what they will be using it for?
We can excuse the naïve, but this is a tech-related site. If you don't know, now you know.
The issue here is that the OP did not abuse anything, tried to correct the mistake once discovered and was 'still' the one being punished for someone else's shady practice.
I think it’s because from GitHub’s standpoint, OP looks just like a bad actor who took $5 to allow someone to use their account to Star 500 repos, and says the same things.
GitHub is taking the “ban them all and let God sort ‘em out” approach to figuring out if OP is telling the truth.
You realize that the oauth token is tied to the client app, right? Not only can GitHub see that this action was taken by/through a third party service, they can also see all actions taken by that service across all users. So there are much better ways to detect and correct the abuse.
All oauth tokens are authorized by users. So GitHub sees the app and sees the users who authorized the app. Users are responsible for all the bots that act in their names.
Otherwise it would be quite simple to write a malbot and then claim innocence because it was the bot doing it, not me.
I think the approach to automation is best when the authority and responsibility always ties back to an individual or group.
We keep asking that users must be asked for explicit permissions and granular scopes are for the good and then users themselves skip reading on these permission grants.
Github has always (in my experience) been clear about what permissions are being granted to the site you're signing into, and if you don't agree, you can easily cancel the sign-on flow.
It's not clear at all. The scope UI says 'Repositories - Public repositories'. It does not sound dangerous and only reveals that the access is r/w (not r/o) after expanding the dropout. It does not mention stars at all.
Sounds like the basis for an argument for refining the scopes such that it is abundantly clear which scopes write data and which ones do not.
No one should be surprised that allowing an untrusted program to write files and permissions through an operating system could lead to a security exploit.
Many would likely be cognizant of the risk of becoming a member of a botnet.
Allowing untrusted programs to control your digital services is not fundamentally different, in my current perspective.
Truly though, wouldn’t you expect that your IP might be banned if your computer was compromised by a ddos botnet?
Your GitHub user account was compromised by a bad actor, so it shouldn’t be surprising nor considered victim blaming.
Of course, GitHub might cross the line to being unreasonable if they become aware of this as a potential security issue and fail to mitigate the phishing risks that they are exposing their customers to.
edit: restoring your user account to good standing, if absolutely necessary, is certainly something to strive for, but be aware that it can take years or never, from anecdotes that I’ve heard about Google, Apple, Twitter, etc. Microsoft/GitHub/LinkedIn won’t likely be any different, in that regard
> Your GitHub user account was compromised by a bad actor, so it shouldn’t be surprising nor considered victim blaming.
But GitHub sees where did the request to create the stars come from. The requests all came with authentication tokens associated with the given malicious site. They have all the data to see how the account got “compromised”, and they also can see that the account owner is unlikely to have knowingly participated in the “star farming”.[1]
The obvious and correct solution is to delete all stars created through tokens associated with the malicious site[2], disable access for the malicious site and write a letter to the compromised users.
1: further absurdity is that by deciding that the stars were farmed Github already made the decision that they are not comming organically from users. Because if they were comming organically from the users then it wouldn’t be star farming, just a popular repo. So why are they punishing the users then?
2: one more absurdity is that stars don’t cost github anything. It is just a number in a DB. It is not like they incurred a cost due to this attack. Github decided that they care about some stupid stars, and make the farming of them a bannable offense.
Yes, we should be careful, thanks a lot for this hindsight, but giving developers the ability to request for a permission and banning users who click it by accident or doubt is kind of a dick move. Why not remove the permisson and ban the developer instead? To teach people a lesson? Would you like a leash and a whip with that?
I believe that the individual responsible for these bans should be transferred as punishment: working on the weird photo editor in PowerPoint, or the msvc++ compiler.
>without a clear explanation as to what they will be using it for?
No one lies on the internet? Those Nigerian princes are very clear what they are going to do with the money you send them, but it doesn't make it true. Providing 3rd party access to an account should come with over sight abilities.
Asking "What if this other thing that didn't happen, but could happen, happened?" and then using that to excuse reckless behavior.
I'm going by what the guy wrote. He "clicked through a bunch of pages". If you "click through a bunch of pages" and get scammed, you suffer consequences. Play stupid games, win stupid prizes.
I'd like to login to a 3rd party site to determine that their DOM structure hasn't changed - because I develop an extension that interacts with it.
It's great when you can get a test account for this, but often companies will simply tell you "create a throw away account and test there" (ex: google does this).
That's not malicious - I'm well within my terms of service - I'm not doing anything with the service other than ensuring that behavior that is not contractually guaranteed still works (because unlike an API, most sites change their DOM often and with no warning).
It's not something I can fake with self-hosted content or mocks, because my version won't change when their DOM does.
---
I've investigated captcha solutions for this exact reason. Not to mention ways to automate 2fa. I understand the overlap with malicious intent here, but just because there is overlap does not imply that OP was malicious.
>Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes.
>Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
>When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
For what it's worth - this is the same colloquial language I would use with close coworkers when discussing topics.
None of the cursing is directed at the person, but the topic under discussion. At no point have I cursed at him, or even been snarky to him. I have used emphatic language outside of a formal setting.
Personally - the existence of a curse word alone is not enough to invalidate an argument.
And in this case - it reflects my true opinion on the topic: It's bullshit to blame the user here, when the tech exists precisely to allow more accurate determinations of cause. It literally exists to prevent EXACTLY the sort of grey area the commenter above me seems to take for granted. I absolutely should be able to allow an oauth app to interact with a service and not be held accountable for malicious actions of that app if the actions are the result of abuse by the app and not my intent.
Otherwise why fucking bother with the rigmarole of the oauth app registration in the first place? Just hand the user a personal access token and let them plug it in where ever they'd like if you're going to ban them anyways...
"Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. Edit out swipes."
from github's pov you starred the repos. You signed up for a service the stars repos. it could have been starallthereposforme.com and you signing up a granting them permission to star repos is exactly what you wanted. So girhub is correctly assuming you wanted those repos starred.
If you didn't want them starred you shouldn't have given the site permission to star
But an 'abusive service' might still involve misconduct by the user in question.
Suppose there is a service which allows you to watch free porn videos as long as you hand over permissions to star a bunch of repos using your account. Clearly, the service is abusive and should be banned. But isn't it also quite fair for Github to penalize the users? They knew they were handing over something of value when they authorized the access. Either they chose to exchange their genuine 'Github clout' for something they wanted, or their accounts are spammy in the first place (for example, if they created an account solely to access that service).
If you gave the owners of some website permission to star repos on your behalf, then you are trusting them; you are still the one responsible for your endorsements. Whether endorsing the wrong repo ought to ban worthy is definitely up for debate. But the question of whether you endorsed manually or delegated it seems unrelated.
You will have to find someone who’s suggested that they don’t want users starting repos via API to ask them that. I’ve instead suggested that repos started via clicking and API should be treated the same way.
How far does this extend though? Should people not be banned for granting access to any app, and doesn't the screen where you grant access present some kind of disclaimer or warning?
Getting your account hijacked and engaged in suspicious behaviour is cause for Github to suspend the account. You're not free from blame when you let your account be abused, at best you might be able to ask Github to help get control over your account back.
