Ask HN: Developer abused “sign in with GitHub”?
suddenly i am unable to log in to my github and the page just says "account suspended."
contacted their support and the last response i got from them was "your ban should stay as you engaged in improper behavior of stars farming" or some other BS.
Here is my problem. I am not a part of nopecha. I just used their website once using "sign in with github" button. That is the extent of my involvement.
How can github allow the developer to use "sign in with" button to create a situation that they could LATER consider abusive but then go ahead and ban all the victims also?
i did not voluntarily want to join their abusive practice, i just wanted a log into the website. (There was no explicit mention of the stars farming practice on the website) Why is github allowing the developer to abuse their Oath in the first place?
If this is going to be a norm going forward, i do not see any hope of "sign in with" buttons for any service because then you could be banned from one service and suddenly everything connected to your account is also banned.
I honestly expect the "sign in with x" button to provide a frictionless access to a website, thats it. how could the developer abuse that process and the website, instead of acting on the developer alone, are causing trouble to unsuspecting victims?
edit: to add a bit more context, here is the first reply i got from github on my support request
"Your account has restrictions imposed because it appears to have been used for the purpose of artificially inflating the popularity of GitHub accounts or repositories.
This activity isn't in keeping with our Terms of Service.
We'll need to leave the restrictions in place."
I knowingly or unknowingly accepted to allow the app to access my stars action or whatever. i did not engage in this practice myself, their automated system did. i even had "forkhub" android app and i did see "stars" and i remember unstarring 4/5 of their repos myself so its not like i did not try to undo their actions.
the problem here is. 1. if github is allowing developers to include their permissions alongwith the SSO workflow 2. github is allowing apps write action to stars from the users accounts which can be legitimate or not. 3. user is not responsible for automated actions taken without their consent or even if consent was there, user is not aware of the "actual scope" meaning app could say "you allow us stars access" but not "you allow us stars access with the knowledge that such permission can be a banable offense, you are warned" 4. unless the user is a sockpuppet account created for the sole purpose (by checking age/activity of user), is it reasonable to throw the banhammer so quickly on everyone involved? 5. why did github not ban the original dev, stop the users from starring for a "cooling period" or "undid their stars" ? why was a ban necessary?
493 comments
[ 0.34 ms ] story [ 324 ms ] threadI can't remember the site that does/did this, but there was some site that wanted you to log in with OAuth2 through some identity provider and they initially ask for access to your contacts. If you click 'cancel', it sends you back through the OAuth2 flow but without the "read contacts" scope. Sketchy dark pattern BS.
Any platform that offer easy to use API, openID or integration service should be concious about what they consider to be a vulnerable and what can be easily exploited. The amount of meaningless authorization buttons we have to press is astounding and it should be considered by all platforms. This argument doesn't advocate for strict integration control and disabling their OpenID features.
Any system that chalks up massive amount hassle to people only due to "human error" is poorly designed.
So the only way to use them is to either deny most legitimate apps because of scary permissions, or learn to click past the prompts to get your work done. If people do the latter due to a bad system then GitHub is not blameless here. They need to fix their system.
That's what you do when you're user centric. But it's also actively hostile to developers. What you should do is preserve a balance:
- let developer know permissions have been refused (no need to go chasing fake data)
- tell users to report apps that simply stop working without a given permission. It should be a separate "report button" that is on the same page as the "give permission" UI.
But this means you'll need people to review those reports properly, otherwise there is no balance. And that is why it's never done like this.
Also, an app is merely a suggestion of what to run on a CPU. What actually runs, and what data is provided, is my decision, since it is my hardware.
I don't think developers ever have a right to know permissions have been refused. People should have a fundamental right to lie about their location to private businesses, to protect their privacy.
When you're asked to sign in, it will show you, this application can:
1. Read and manage your stars 2. Read and manage your repositories.
Be very careful when granting applications access because they can misuse it like this. GitHub integrations should be verified for editing repos and editing stars of the user, but that's just my opinion.
Applications such as Heroku in which you can host an application through GitHub require to read, access and edit the files in your repository. After all starring is just an action.
So if this action was allowed by github, how is that a banable offense if someone gets overzealous with it?
Most apps don't need that permission, which is why it's called out as an explicit special permission that apps need to ask for, which in this case it probably did. If you find a good way to make sure that nobody's going to just mindlessly click through a big list of permissions, I'd love to hear it because it's a real problem. But not letting apps do those things at all is a really heavy-handed solution.
However, say that developer took advantage of the fact that the permission seemed reasonable to automatically make you star their app for that Sublime extension upon install. That would be malicious and unethical.
So there's a difference, but the permission isn't inherently sinister.
that is what i am saying. whether i read the permissions or not, (i did not though) whether i gave them the permission or not, did i actually go and manually contributed to their stars farming operation or not? if i did, then i would be guilty, if not, well blame the developer, not the user who was tricked into allowing their app to do this maliciously
Is that not obvious? It's not a "farm stars" permission.
In that case, Heroku may add files such as Procfile, etc.
Clicking dropout shows that permission is r/w not just r/o, but does not mention stars either.
2. A user has no way of controlling which permissions are abused.
If you get scammed, you get scammed, but the response from GH here isn't warranted. They're adding damage on top of whatever the user already got themselves into with allowing the malicious developer access.
It is trivial to determine whether an action was taken via a direct user interaction (using an access token granted by GH.com, by clicking a thing on their website) vs a 3rd party (who presumably had to go through a sign up to even use "Sign in with GH" and has a dedicated application ID). Instead, GH is attributing the actions of a 3rd party to the user, which isn't appropriate. They're essentially accusing the malicious developers' victims of being "in on it".
Another possible legal angle is that by providing these powers to websites with little or no oversight and "people wil just gloss over it" UX, they are facilitating the very star farming they are banning over.
This is a dead giveaway:
> i logged in, clicked through a bunch of pages because its the same drill everytime
For SSO, “login with GitHub” type flows, there’s no “clicking through a bunch of pages” post sign-in - you aren’t granting them access to your GH account, you’re just letting GH tell the site “yup, this is person X”. What OP describes sounds like explicitly granting a 3rd party access to your GitHub account, and OP was just being sloppy - I’d strongly bet the pages said things like “do you want to grant nopecha access to star repos on your behalf”, and OP clicked “yes”. If there’s any lesson here, it’s to read things more carefully, and not just freely give out access to your accounts to sketchy websites.
What is strange is that you are banned for an action someone else took. That doesn’t make any sense.
Also, seems like you’re probably a developer? If so, SSO, OAuth2, OIDC, etc. are worth learning about. You seem to be confusing/conflating SSO and OAuth2 authorization code flows, when they’re reasonably different things.
That said GitHub should have banned that website for lying and abusing instead of OP.
It makes a possibly dodgy website look more secure and legit by using a well known provider like Github for the login process.
In addition, it potentially exposes data from that well known provider, which is often sensitive data, as in the case of Github.
Or maybe I shouldn't just take everything at face value and pay attention to what I'm doing.
However, what you won’t see in a standard SSO flow is anything along the lines of “GitHub will be able to star repositories on your behalf.” If you’re seeing those kind of messages, you aren’t doing a minimal SSO flow (just having GH vouch for your identity), you’re granting access to a 3rd party to do things with your GH account.
I'll honestly never get that point of view: it's an evolutionary disadvantage to not fall for these kinds of attacks. Our intelligence is largely predicated on how easily we can pattern match and filter out "excess" information.
So OP being bombarded with a list of harmless permissions along with one deceptively dangerous one (deceptive because they wouldn't expect to lead to being pwn'd anyways, since it's stars) and granting is not being sloppy, it's being an intelligent person.
Github is large enough to have UX experts who know this stuff, and at the very least if stars are grounds for being banned, they should be grouping it with dangerous permissions and using more confirmations.
And even better... they should just rate limit starring! How often is someone going to star 500 of someone's repos legitimately that rate limiting would ruin everyone's day?
And you're ready to hand over even the first 3 items there, you're not likely to assume or even notice that github stars about to get you knocked out of orbit.
I know this is a place of hubris but it almost comes across as a strange lack of self-awareness that this many people actually think they'd have caught that.
No, that is being an intelligent ape reacting to a twitching bush by running up a tree on the chance that a predator is behind the bush. The tables have turned since then. Back then the analytical ape would have gotten eaten and not passed his genes on, but there is no longer a biological imperative to mindlessly react to things.
Modern humanity hasn't existed for an eye blink compared to the everything that led up til now, so there's two kinds of people:
- People who understand we all have these blind spots and understand account for them
- People who don't even realize how often they run into these blind spot.
You're much better off learning to be the former, but I'm sure it feels good to proclaim from on high how you're just sloppy for not checking every dialog you come across...
- People who've heard about about the marshmallow impulse control study + the effects that medieval-plagues/cousin-marriage has had on the human gene pool
- People who say silly things like "Modern humanity hasn't existed for an eye blink compared to.."
You're much better off reading a long term study on the life trajectories of people who had their impulse control quantified as children - spoiler: they do not do well in the modern world relative to everyone else enjoying a reduced probability of incarceration.
Intelligent apes surrounded by wiggling bushes stop paying attention to wiggling bushes and get munched on by a predator eventually, no?
Agreed, but unlike a login prompt, those things are there for the benefit of others - not you. To continue the analogy: blowing through a login (or changing traffic signal, regardless of color) is like an ape exposing his belly to any silhouette vaguely shaped like a trusted member of the troop.
> ..stop paying attention to wiggling bushes..
Dunno, he could also have a breakdown - lab rats are known to practically lay down and die when you suddenly reverse the role of external stimuli in a system of punishment and reward. But I don't see how that fits here, the user isn't being plagued by nonsensical login prompts constantly springing into existence.
If you didn't want them starred you shouldn't have given the site permission to star
Legally they might be in the right, but punishing victims of social engineering further doesn't seem like a fair or smart business decision.
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).
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.
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.
An example requesting the 'public_repo' scope (the client_id is a random one from the internet): https://github.com/login/oauth/authorize?client_id=33a703d01...
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.
What I would not expect is Github banning me in some misplaced form of victim blaming.
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
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.
You can blame the person handing out the wallet for being naive, but ultimately the bad actor is the other.
I automatically decline the moment I see any app trying to authorize with that scope.
Nonetheless, perhaps this is pointing to Microsoft’s Window’s UAC moment for GitHub.
Bright yellow or red UX with warnings that if you click “agree” then you might as well have given away your computer to a malicious actor.
GitHub is taking the “ban them all and let God sort ‘em out” approach to figuring out if OP is telling the truth.
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.
I’m sorry which rule covers that?
"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."
>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."
https://news.ycombinator.com/newsguidelines.html
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...
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.
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.
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.
The whole story is suss, tho.
However, getting banned is pretty minor compared to the other bad things that can happen if you grant sketchy websites access to your accounts without reading what you’re granting.
Sorry I'm somone else but I'd just go and assume it was because they are human, not a terminator, and their eyes do not have an integrated HUD talking with GitHub's backend with status indicators showing each currently authenticated account??? You want this kind of correctness you have to write software in Rust or something. "You're holding it wrong" lol
Yes, you are supposed to read the dialogs. OP really got got, and that sucks. But it's literally why that permissions checklist step - that they ignored - exists.
If the same happens to me I'm positive I'm /punching the screen, locating whoever set that bullshit up and taking a dump into their physical mailbox./
None of those things are an excuse. The dialog is there as a gateway to protect your data and GitHub's platform from the third party. If you're not going to review a clear dialog describing the permissions, then there is nothing that GitHub can do, other than decide that you cannot be trusted with this responsibility.
Also, drunk and high? You chose to be in those states. If you can't make the decision correctly in whatever state you currently are, then shouldn't be making decisions in that state. Take some responsibility for yourself.
I don't really believe you "choose to be in states", what an absurd way to think about the behavior of hairless apes. Sorry but I will continue having the illusion of making decisions in whatever state I please. What now?
Maybe have some kids or smoke a joint because you're going to end up in a looney bin with this kind of expectations towards your fellow idiot humans
> smoke a joint Done that. Didn't use it as an excuse.
> What now? Consequences don't care about your defiance. Nor should GitHub or whatever party has to deal with you.
Normal people make mistakes. Decent people care about limiting the damage to others. Assholes blame everybody else and deny all responsibility.
But that's getting a bit off track. I responded to the attitude where someone should not be expected to read a simple and clear dialog because they were a hairless ape that could be drunk.
FINALLY you said something reasonable :-D I'm sorry for being an idiot, I wanted to give a different perspective, I guess I'm passionate about nice and human UI. What happened to OP is what I call a Huge Dick Move. I will defend them to the grave because I like to cut people a big big piece of slack. Because yeah they could be drunk, or just tired, which is cool, you know.
What's not cool at all though is so called "engineers" ebgineering shit like OP described which makes me ashamed of my profession everytime I watch my grandpa painstakingly wade through crap like this all the time.
I will cope, I'm a dev, many people will not and there goes their UX. Straight to trash \o/
I don't want to get absolved of my responsibilities or whatever, I want UI that doesn't suck dick and ideally doesn't star 500 repos by itself
when was i already logged in? there was only 1 action of "sign in with github". thats it
This is accurate, but oauth2 is the standard sign in with GitHub. oauth is literally designed as an authorisation mechanism to allow people to do things on your behalf, the ability to authorise access was later repurposed into an authentication mechanism.
It's not enough that the user gives an app permission to act on my behalf, the issuer (in this case github) also has to give the app permission to ask for these scopes in the first place.
Github definitively messed up in giving the nopecha app permission to ask users for permission to star on their behalf.
If stars are important enough for them to ban users over, they should be very careful about letting third party apps request this scope from their users.
[1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-ap...)
While sure it isn't immediately expected to access "stars" feature when you give public repo access...
...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.
I'm surprised this hasn't been used for malicious purposes until now.
What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf.
Seriously there should be a big red warning on all scopes apart from the "none" one.
So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc.
Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known.
BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...
GitHub isn’t doing the handing out, it is the user doing the handing out.
I don’t blame the user, as a rule, but in this type of scenario, the user (a consumer of development tools) shouldn’t be excused, in my opinion.
This would be like a doctor complaining for getting sued for malpractice by a patient of a nurse under the doctor, while the doctor neglected to review the patient chart and neglected to take the time to speak with the nurse.
caveat emptor
All that said, I would hope that bad actors that get caught, effectively phishing for GitHub credentials, using a technique like this end up being banned from GitHub.
I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them.
And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.
Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully.
Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.
It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners.
It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.
Let alone banning the user instead of the client app...
Caveat emptor is not a threat model, it is a risk mitigation.
It is arguably the only mitigation directly in the hands of the consumer.
And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation.
> it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials
thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated
edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”
If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".
Nothing but agreement there.
Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case?
> And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".
I had to look up that apparent reference to Harry Potter, but I disagree.
Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.
Similarly we shouldn't bill for service accounts, especially when they're documented as the way to limit API token access. It's self-defeatist like taxing longer passwords.
Therefore if you want them, pay up or do it yourself.
They exist for github apps, and they're being rolled out for PATs alongside forced expiration: https://github.blog/2022-10-18-introducing-fine-grained-pers...
Not sure there's any way for them to happen for oauth apps though. And even if they do, they're opt-in for the app and the old broad scope will remain. At best the broad scopes would only be accessible to old apps grandfathered in but that ain't much (there's probably a billion abandoned oauth applications you could purchase for that grandfathering).
$x/mo * Service accounts is dumb.
Github's responsibility is to ask consent to the user and display all the requested permissions. If the user accepts then Github has done its work.
This is how all oidc providers work.
If the screen to give a 3rd party permission to identify you, looks like the screen to give a 3rd party sweeping permission to act on your behalf, that's github's responsibility and problem.
It would also be a good reason for responsible 3rd parties to ditch github for identity, if they don't address it.
(Another matter is that the big public OIDC providers' eagerness to let you use them might be a lot about tracking.)
See the latest draft for OAuth Rich Authorization Requests (“work in progress”): https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html
edit: you might be mixing up / conflating Open Authorization (an authorization standard - authorization scopes are in scope) with Open Identity (an authentication standard - authorization scopes are out of scope)
edit 2: It probably doesn’t help disambiguate which auth is which when the same company is providing both the authentication service and the authorization service.
Yes, of course OAuth is about scopes! But OIDC is a protocol built on top of OAuth2 which is for identity only. You get no permission to act on the user's behalf from the OICD scopes, only read access to information you need to identify them.
This whole problem only happened because
1. Github is an OIDC provider, allowing you to identify yourself to websites around the world.
2. Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site.
3. The one looks too much like the other. OP probably thought he was just showing ID, but what he was doing was giving the site sweeping permission to act on his behalf, which the site promptly misused.
The problem here starts already at 2. That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes? There are not that many third party apps that have a legitimate need to act on the user's behalf. Maybe some continuous integration stuff? But even that should only have access to the user's own repositories. Nothing I can think of has a legitimate need to go around starring random repositories.
That was probably one of the advantages of shoe-horning authentication (OpenID) with the existing authorization standard (OAuth).
> Why is everyone linking this draft? It's got very little to do with what we're discussing.
> … Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site
> … But even that should only have access to the user’s own repositories.
Seems like Rich Authorization Requests are exactly what we are discussing.
Give it a skim (or a read).
This is not very fine-grained. It would be perfectly possible to gate access to social features of github (such as starring) behind a plain old scope. Distinguishing "access to all your own repositories" from "access to anything else on github, as you" also is not a fine-grained difference.
(Imagine if e-mail adresses were considered "invalid" in forms if not from Gmail or Outlook !)
It was especially bad with last years Advent of Code, where going through OpenID (or was it OAuth ?) was the ONLY way to join, and with only 3 options listed, none of which I wanted to use !
So an app could request only the non-data-access OIDC scope, or an IdP could enforce that it only allows apps the OIDC info.
On top of that is the user consent. What has been pointed out in threads here is that the IdPs are making the UX for basic OIDC consent too similar to the UX for consenting to privileged data access.
And of course if an oauth token is being abused, the IdP should ban the client app first, not the user...
It is good to take a step back from the tech and think about it from the user's perspective.
No. When an app is registered with them, a provider does check if the scopes requested have a reasonable business purpose. Many registration forms even ask you to explain why you need the scopes requested. This is similar to how Apple App store does review.
Many OAuth providers also check periodically if one of their registered apps is used for any pattern of abuse.
"public_repo Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories."
We at least/even have OIDC for that now.
Use Gitea instead. It's great and doesn't add eyeballs to this giant corporate SPOF. It even has a feature to push everything in your repo to a remote (eg GitHub) as a mirror automatically. (Or set up a repo as an automatically pulled mirror for the inverse.)
It's not perfect and it's not social/collaborative but it gets the job done in the absence of a mailing list.
https://en.wikipedia.org/wiki/Max_Schrems#Schrems_I
They don't have to provide you the service, that is totally their right - but it seems unlikely they would be allowed to keep your intellectual property at the point of service cancellation, especially given the reason for cancellation. They should provide a way to download the repos you want to keep for a reasonable time frame, if for example they send you an email
We no longer want your business, please get your stuff by this date or it will be deleted.
Then that would be one thing, but if they're saying
We no longer want your business, and you can never have your stuff back because that is our policy.
That's opening up a can of worms that their lawyers probably don't want opened either.
on edit: Were any of these repos paid for - then they really better solve it, even so they evidently derive benefit as a business for offering free repos so they should still provide a way to get your repo on service cancellation.
Finally they argue that reusing your code in training things like CoPilot is fair use - have your public repos been used in such a way and if so they are continuing to derive business benefit from your code while not allowing you access to it. Even bigger can of worms.
Considering the rather unfair cancellation (and basically any situation that relies on arguing you should have been more careful or you wouldn't have been taken advantage of is unfair) I think they should reach out, give you your code and say Good-day, sir (or madam, no offense meant).
But even if you were the person doing the starring of repos they would be in an iffy place to keep your intellectual property and not have a limited time, get your stuff back solution (which for all I know they have, I've never researched the matter)
I.e. the flow is
1. Auth by Github
2. App says "thanks, now please log into your github account and grant the following permissions, X, Y Z"
3. User logs into github.com, goes to account page and grants whatever they fell is necessary
4. App now has permissions.
If you give random websites access to your account that is 110% on you. This just goes to show that people have extremely poor login practices. You need to actually read what popups say before accepting/authorizing.
Also if I understood correctly this was some scammy captcha bypass thing anyway so OP was doing shady shit anyway.
Curiosity and analysis should never be considered "shady." Proximity to "shadiness" doesn't make one "shady."
You stopped off an a random Dairy Queen on a roadtrip, got our M&M Blizzard, and attmepted to go along your merry way. But the local cops have stopped you because "obviously" you were doing shady shit by stopping into the DQ that's "known" to deal in nefarious things.
It's not GitHub's fault if the user doesn't read the permissions and authorizes the application.
Unless you have a couple million dollars burning a hole in your pocket and 5-10 years you'd like to spend in court, good luck suing Microsoft. The US Justice Dept couldn't even get a meaningful result in their antitrust case. The courts exist to protect these multinationals, not for you.
I'm sure there isn't. No one has any inherent right to a GitHub account, and their ToS allows them to ban you for pretty much any reason.
I don't quite get why you're talking about "legal angles"; there's nothing here related to the legal system. Yes, it's stupid that GH makes it so easy to give full access of your account to other entities. Yes, it's stupid that they're going to then ban you for what those entities do with that access. But GitHub has no legal or contractual obligation to not ban user accounts for stupid reasons.
For others, let this serve as another lesson to never sign in somewhere with any account if you can help it.
This week there's also this other person that says there are soft locked into Google because they signed in with Google to many places.
Go to the trouble of creating a regular account. It's less trouble in the end. (here it was not possible, but of course, it looks like it was a scam, so maybe it's a red flag anyway)
https://app.travis-ci.com/signin
I understand why they are doing it, because they have to pull from GitHub, but it's not the only way. They could create a regular user on GitHub and ask people to let that user pull from their repositories. Obviously it's more trouble for the user, it would harm adoption and growth, that user could be banned and halt all of Travis.
Travis is the only site I have ever used in that way, because I have a customer that uses it. With hindsight I think that I should create a per customer account on GitHub, just in case something bad happens to Travis.
Is it too late to do that?
My immediate line of thinking to this thread of "sometimes you have to use an account to sign in" was that then you'll need to create a new account specifically to sign into that service. If you have to sign into that service. Maybe I'm weird, but I tend to even use a DuckDuckGo e-mail when I sign up, so that a specific service is in no way linked directly to me and so that I can stop forwarding e-mails from any specific service.
To be fair, I sort of wonder why Github has an API that allows 3rd parties to star projects with your account. I get that the author of this post on HN is responsible for not reading the "clicked through pages" part of the processes and that they should consider themselves sort of lucky it was only abused for star farming, but why do we have that sort of "facebooky" functionality on Github in the first place?
I would say though that if GitHub is allowing requests like that through the API then they should be banning the API token and the account it was issued to if it uses the API maliciously
> One person or legal entity may maintain no more than one free Account
This means that for nearly all of us it is one account per person.
The rules are more relaxed for corporations
https://docs.github.com/en/site-policy/github-terms/github-c...
> A User’s login may not be shared by multiple people.
and that's it.
So there could be joe@company1.com, joe@company2.com, etc. Probably only the joe in his current company can login because the others have revoked its access.
In case you missed it: https://news.ycombinator.com/item?id=33906591
I had an incident only a week ago where I had to sign up to Snyk and the only way to do so was to use a third party sign in -- no option to create a new account using email.
The end results was me signing in using a Google account tied to the client, resulting in an immediate account disabled message from Google. It took a week to get the account re-opened, but left a bad taste in my mouth. If a billion dollar company can't be bothered to create their own sign in, what can we do?
I was so pissed off at the time that I wanted to open a support ticket with Snyk and vent, but of course, couldn't find any way to do that on their website.
(I haven't encountered the situation myself, didn't try it)
> Snyk is a Boston-based cybersecurity company specializing in cloud computing...
how is it secure [or wise] to require you to share an external login?
that's infuriating
I've managed to. It does mean that some services are unavailable to me, but that's life.
FB, Twit, Goog, need to separate oauth login from the rest of their service.
Kinda deeply nested into settings submenus.
I think that is for third party apps that help you tweet. I never used any.
The best course of action would have been for you to de-couple your Identity Provider from your account completely, I have done that over a course of a few months. I have de-coupled myself from Google Sign in on my most frequented sites, using Email + a Password manager + 2FA wherever its supported. though I have also have even used Apple's sign in for some apps
These VPN services have little to do with the traditional meaning of a VPN. They don't provide a private network at all, they just use VPN tech to implement a proxy service.
Tailscale is not a "VPN service" in that sense, they actually provide software for setting up a VPN between computers you control.
Don't feed the trolls.
That does make things harder for small shops where things are more ad-hoc, or an individual hobbyist who wants to use it. But not sure how much of Tailscale's market consists of people like that, or if Tailscale even cares that much about that segment. No judgment if they don't; that's a perfectly reasonable decision to make.
+1 to this. I got locked out of my StackOverflow account because they stopped supporting my auth provider, I think a couple of years ago.
This question is about a Facebook account that was deleted but it should apply to OpenID providers that go away too. The mods' comments seem to indicate that the "Contact Us" link gets you through to a human that may be able to help as well.
> i logged in, clicked through a bunch of pages because its the same drill everytime
GitHub is clearly listing list of permissions, and yes - I check it before accepting log in and in some cases have not granted permission because scope was overly large.
Is it possible you got caught by some automated system that tries to prevent sockpuppet accounts from inflating stars?
nope. Google login is still present on the website...
The comment you are responding to states one thing (Github banned NopeCHA) and asks an other. (If the ban was done by an automated system)
Which one of these two are you saying “nope” to? And what does google login has anything to do with these?
It would be a PITA for developers, but if it was the norm, you wouldn't think about it twice.
The minimum scope should be a random identifier that's unique to the service provider you are logging in to.
Why on earth would anyone use SSO? Are we that lazy?
That being said, this approach requires monitoring and enforcement; otherwise nothing prevents the developer from not allowing the user to proceed without granting some specific permissions. Facebook again seems relatively strict here, at least post- Cambridge Analytica.
The callback page would tell you that you screwed up, give you a link to try again, and not let you authenticate until you offer the proper scope.
I can't imagine anyone else doing much different than that outside of special cases.
the scope mechanic would have to be reworked altogether if this feature has any chance of actually achieving the desired effect, so a scope can only be granted for n-minutes or something. But that would make a lot of good use-cases borderline impossible (i.e. the previously mentioned alternative frontends for popular pages).
Its really hard without revamping the oidc standard altogether, but thats unlikely to happen as well. Good authentication/authorization is just super hard and continues to be unsolved, especially if untrusted entities are involved.
Or is it better to farm the manual labor out to Amazon Mechanical Turk / Filipinas / etc?
But I agree on your last sentence, like when a porn site invites you to sign in with your Google account. That feels like a way to get compromised somehow.
I also forgot about it until this post. Thanks for saving me a potential headache OP. Just uninstalled it
Well, probably sidestepping this utter idiocy.
buster is a technically legal software designed to show how easy it is to bypass google recaptcha.... if this continues to work, why not a third party SAAS that allows the same thing via an api?
As in Github and Micro$hit along with them
Nah, the list of permissions you were granting were right there. This is on you.
"Your account has restrictions imposed because it appears to have been used for the purpose of artificially inflating the popularity of GitHub accounts or repositories.".
so i ask again, if "manage stars" is a legitimate action that is not a problematic one in itself, how would i know, beforehand that going in to "sign in with github", that i would be giving the app stars access and that they were going to use to artificially inflate popularity of their repo? and that was a banable offense?
Google learned this too, that's why it is very hard to get access to certain oauth scopes. Making the product nearly impossible to use except for anything then identity. But that's how it is.
Accounts are only necessary if I actually have to maintain content on the site, or specific permissions are tied to my account.
I do wonder if it would be useful to use my Auth0 personal account for this type of thing on sites that support it instead of using email login. I think a dedicated identity provider might be less risky in terms of random account freezing. Google, Microsoft and Github probably have a zillion ways (valid and invalid, accidental or not) you can violate TOS because they all own platforms for publishing content. A dedicated identity provider might be safer in that regard.
What makes me unhappy are the services that don't support non-oauth accounts at all, e.g. ProductHunt.
You have one account with stronger sec. Like 2fa instead of 10 random accounts without 2fa cuz you dont want to give ya phone number to untrusted ppl
Important reminder to maintain a backup of any data stored on your online accounts.
That has been the main criticism of pervasive SSO since the beginning. It's even worse with Google. At least with github it seems to have ben an actual human telling you to fuck off!
If the offending site is causing issues they should just delete that oauth key and prevent the site from using "sign-in with github". How hard is that?
It's also a matter of UX. Github (or anyone with social login) should be clear about what your granting. "Do you trust this website? They will be able star repos on your behalf"
... "and if they do this too often, it's your account that will be punished" (in big bold red text and with a 15 second delay before the authorize button is enabled).
For example, these two prompts look very similar:
https://community.atlassian.com/t5/image/serverpage/image-id...
https://user-images.githubusercontent.com/2584493/51578239-b...
But they have entirely different levels of access!
What you're doing is victim blaming. The phishing/scamming equivalent of shouldn't have been walking down an abandoned street at 1am in the morning.
If anything, Github already wasted time by targeted the user into a victim, rather than the original source of the API call.
Punish the site. But dont bother wasting anymore resources to protect the stupids. Its their own action, let them be accountable for their own choice.
Trouble is that if you need to migrate from Apple, then there's no way to recover the account.
For sure, there's a lot of support headache related to OAuth in general.
I like that the ACCC has teeth. Keeps Australian companies on their toes.
The right to be forgotten and make them delete all your data ( including backups ).
( No, they don't need to know whether you are a citizen within EU or not )
So, want to write a full front end for github? Do it. It's likely the github mobile app uses this API to provide every service it provides.
Open issues, create repos, add comments, create gists, create releases, star repos, etc...
https://docs.github.com/en/rest?apiVersion=2022-11-28
All that said, I have ranted about github's permissions
https://games.greggman.com/game/github-permission-problem/
Otherwise the user would get a giant prompt upon first use about which claims are needed to proceed. If that takes hold, people will just click away the message and third party logon would be as vulnerable to phishing than conventional logins.
Otherwise it is nice to have an API that almost can do anything. I think this is the strategy of GitHub, to provide a service beyond the user login and also serve as infrastructure.
This is an unfortunate event and I hope GitHub will lift the ban from the ones affected and enforce ban on the people misusing this. But always check what permissions you are giving.