Github failed to indicate clearly what the consumer was going to use this person's credentials for.
This is Github's fault, end of story. If the permissions included "can star repos", instead of just "can read/write repos", then sure.
Github are too _lazy_ to build granular enough scopes; they should be able to ask "why are you using this scope?" and it should _never_ be the case that someone using one small part of the api has to ask for a scope granting blanket access.
Granted, there are quite a few issues with granularity of scopes/oauth for various other services, too.
Edit: also the stinking elitism in here; the worst part of the tech community. Just bc someone has a Github account doesn't mean they're some sort of super hacker, there are junior devs out there who could've easily done this and your response to them is "get gud scrub".
Could you please not post in the flamewar style to HN? It destroys the curious conversation that this site is supposed for. You can make your substantive points without that.
> If the permissions included "can star repos", instead of just "can read/write repos", then sure
Not to blame the victim here, but your logic implodes on itself. Do you realize that granting someone access to "read/write your repos" can have more severe consequences than what happened here?
What GitHub did was wrong - regardless of the scope, they need to be able to differentiate the user from malicious developer. With that being said, it is prudent to pause and think before granting permissions to your resources without some level of trust.
Everyone is dancing around talking about everything other than the clear issue.
If a user grants someone rights via a platform, then the explicit trust is that the granted party will abide by the platforms TOS in the same way the grantee would.
If the TOS is broken by the granted party, that is them breaking the TOS via a victims extended trust. It is not a true reflection of the situation to say that the grantee broke the TOS.
If the grantee is using their OAuth integration for platform abuse, that’s not the fault of the victim, and it’s surely a TOS violation of itself. They should have their API access revoked and the victim’s account should be restored.
I think you agree with OP, they just mixed up grantee and grantor (they use "granted" for grantee and "grantee" for grantor):
> If a user grants someone rights via a platform, then the explicit trust is that the granted party will abide by the platforms TOS in the same way the grantee would.
It's exactly what happened with the Cambridge Analytica scandal fwiw.
Users logged in to a quiz with an oauth token that asked explicitly for a huge set of the users Facebook permissions which then led to scraping and spam.
Oauth isn't very safe. Users don't read the grant prompt and mistake it for a login dialog rather than for an authorization to act as you dialog.
Facebook basically took oauth away after Cambridge Analytica. Note that the 'login with' authentication flow is different to this authorization flow they removed.
Oauth may have practical uses for users on GitHub but a warning dialog of the permissions granted absolutely is not enough. I think Cambridge Analytica can be treated as precedent here but ianal.
> that asked explicitly for a huge set of the users Facebook permissions which then led to scraping and spam.
I seem to remember early 2010s... I had written a few small FB apps, and ... the minimal permissions it would ask for from people were... large. IIRC, the minimal permissions always included access to friend lists, even when I had 0 intention of using that. I didn't want it, but there was no way to opt out. I suspect it's somewhat more granular now, and less intrusive out of the box, but... yeah, when your defaults/minimums are expansive, you'll get stuff like that. I think the CA stuff still happened while those defaults were in place (although they may have also asked for more permissions too).
Facebook API is today very granular and a lot stricter, in fact their system is borderline onerous for developers. They've obviously learned from the Cambridge Analytica situation, and I understand the need for the requirements, but unfortunately it also stops all smaller projects.
I believe that use of “can read/write repos” was to demonstrate a lack of granularity rather than advice on what an appropriate level of access would have been. Therefore - in my mind, their logic stands.
It’s still GitHub’s fault for not communicating this clearly enough.
The problem really is, why does “Sign in with GitHub” grant permissions to act as the user on GitHub? Shouldn’t that be called something else like “Allow nopecha.com to Act as You”?
I would argue that the words “Sign in with X” should NEVER grant any other permissions than needed for being a pure auth proxy.
Unless I'm mistaken, the "Sign in with GitHub" referred to by the OP was a styled button on the attacker's site, entirely in their control. There's no way to force a site to be well-behaved about this. The question is entirely whether Github's warning was reasonable here. What others have noted is that at the very least, even if "starring" wasn't mentioned, the OP did give the attacker full read/write privileges to their public repositories.
You can think that Github should improve their processes on the permissions presentation front, and still think that agreeing to this was a massive fuck up by the user.
It's definitely prudent to check the permissions you're granting via oauth. It's also prudent for a women to dress modestly if she's going to be alone in more dangerous locations and times. But people don't always behave prudently for various reasons. They might not think an area is dangerous, when it is. They might not spot the read/write your repos part among the long list of other permissions. That doesn't make it the victim's fault if a bad actor took advantage of them.
Well said, I wasn't sure how to communicate it like you have. Any time it is anyone vs a megacorp HN comes out siding with the little guy, but here, vs Microsoft of all people, the original evil-tech, they are blaming the little guy.
I've been an embedded developer for decades and while I have heard of oauth, and I'm a bit wary of "sign in with X", I really have no idea what oauth or oidc are and expecting such broad and poorly named permission categories to be understood by average GitHub users is unreasonable.
Yes, but we in the web dev world also need to find a way to fix the UX of these auth flows, because right now most of the population isn't in school. Even if we added data safety to the curriculum tomorrow in every school in the world, it would be decades before a majority of digital citizens learned data safety practices in a classroom.
I completely agree with you, but if we want to support apps to use APIs we have to have some sort of access flow to do so! I'm not sure what a better UX for those flow would look like.
Furthermore, an app taking an action on your behalf through a public API should be the app's fault, not the user's. The app should get it's API access removed and all the users restored. This is just lazy investigation on GitHub's part.
This whole attitude that OAuth is some fundamental Law of Nature written on tablets our forefathers brought from the mountains high - oh, the horrors of someone with a GitHub account not knowing it!
These are probably the same people who will interview a candidate and fail them for not knowing something they themselves learned over a weekend three months ago.
> Github are too _lazy_ to build granular enough scopes
Agreed. They're punishing users because of the side effects of their own negligence. This wouldn't have happened had they built the software properly with granular permissions.
Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner.
For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.
> the more API coverage a platform can provide the better
This is a very common opinion of people who consume APIs, but people maintaining the APIs often feel differently. Every API endpoint is a promise, and it's also a constraint on future innovation. Firefox is a good example, in that their old API allowed extensions to "intimately intertwine" [1] themselves, which proved a huge barrier to improving the Firefox core.
>Every API endpoint is a promise, and it's also a constraint on future innovation.
I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.
I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.
Oh? If it's that easy, could you explain how you would have applied that in the Firefox case and avoided the massive problems they experienced?
Because in my view their problem wasn't about API versioning. They came out with a new version and deprecated the old, after all. It was that they provided way too much coverage early on.
I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API.
Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.
My point is very simple. You said "the more API coverage a platform can provide the better". I'm saying that's not true because it can create large long-term costs that outweigh the benefits. I even gave an example. I get why you as an API consumer want maximum surface area. But API producers often feel differently, and they have good reason to. I think the better general strategy for API producers is to open up gradually based on actual need discovered via dialog with community.
Users build their workflows around apps that use APIs.
Sometimes devs get bored/burn out/get a family/die/get a promotion, and stop building new features for apps. Sometimes, if users are lucky, they'll stay on top of security issues. But maybe, users install an app once and never update it even if it is getting updates. Which is risky, but if it works for them, whatever.
Service provider kills API endpoint.
App breaks.
User's workflow breaks. Worked yesterday, does not work today. :-(
Maybe, if the user is lucky, they connect with other users of the app, or users of other apps that are similarly affected, and they figure out workarounds, or someone creates a fork of the app(s) to use your new equivalent endpoint (if you even created one!) and, eventually, after much wailing and gnashing of teeth, they pick up the pieces of their workflow which you just broke and cobble together a new one.
Sounds cool, except that people will get banned. I'd recommend making a menu where people can click on individual dependencies to star, or have a button to star all (but with a very clear warning about the possibilty if getting banned).
There absolutely is a need for API endpoints for every single feature present on the web application. What if someone wants to make their own custom client for GitHub?
Curbing automation is not a valid reason for its omission. I can reverse engineer the web page, figure out how it does it and implement it in a script if I want. People have done this to YouTube and Twitter, they can do it to GitHub too and there's absolutely nothing they can do about it.
Sure, people can do that. And people diving into janky private APIs know that they're taking a gamble, and that things may break at any time. That doesn't in any way oblige GitHub to support them.
>If the permissions included "can star repos", instead of just "can read/write repos", then sure.
There could be perfectly legitimate reasons for a "can star repos" permission as well, with no way for a user to know beforehand if it's going to be abused or not. How about a site wanting to ask a user something like "Hey, you've been using this service for a week now. If you want to support us on Github by starring our repository, click here." for example?
Can anyone share a screenshot of the Oauth prompt during login? I'm pretty sure it states very clearly that repository write permissions are going to be granted.
I'd sympathize if the prompt displayed only "Nopecha will have permissions to your account" with no other clarification, but this is not the case.
The permissions granularity is a problem, but I think the bigger problem is that the designs for these permissions banners need to change to adapt to the post-GDPR world of the cookie banner.
Users on the web today have pop-up fatigue like we've never seen before. If you have uBlock or similar set to block the banners, you may not realize just how bad most users have it. When the average internet user sees a big popup window asking for their consent and there's a big green button at the bottom, at this point they're conditioned to immediately go to the bottom and click on the big green button to get back to what they were doing.
OAuth consent modals look like a cookie banner. There's a big title saying "X would like permission to", followed by a list of permissions they want, followed by a "Proceed" and "Cancel" button. GitHub's is better than most in that the text on the big green proceed button is explicit, but by the time the user's eyes rest on that button it's too late, they're already tuned out and ready to get to the content they're trying to access.
I'm not sure what the solution is, but we have to change the design of those banners. It's not OAuth's fault that the cookie banner created this problem, but we can't stubbornly insist on retaining the same design just because OAuth was there first.
Wow, yeah. I'd love to know what the source of that is all about, personally. I mean, my initial thought was "oh, it's a younger crowd here, they haven't shot themselves in the foot enough to be able to empathize with the situation", but age doesn't matter ... experience does. It's a simple fact that if you're writing software, it doesn't matter how good you are, over time "the house always wins." And this is a crowd that has plenty of experience.
Thousands of comments from other stories and stories themselves are rife with "how I deleted our entire production database with this one cool trick" stories -- things that are orders of magnitude worse on the "blunder scale". And it's not that these are "stories of humility", i.e. the author is writing because they want to tell you how dumb they are. They're, minimally, warning tales (because you will make a mistake this bad at some point). Sometimes they're stories meant to make the author feel better for having made the ridiculous blunder (I can relate to that). :)
Usually those stories are not filled with a bunch of comments along the lines of "You really should have known better given the work you do". No kidding?!
> Just bc someone has a Github account doesn't mean they're some sort of super hacker
Well stated. I'd add "just because they're some sort of super hacker doesn't mean they're any less likely to to make the same mistake/be tricked into doing something like this" ... including if the permissions were more clear. It's the old "Mechanic's Car" (which hasn't had its oil changed in 15,000 miles).
The party deserving of harsh penalties is the product implementing Github's API, alone, in my opinion. Here's my thinking: change the scenario, slightly. Imagine I use "login with Github" in a tool that's distributed by a trusted third-party, that spells out exactly how they use those permissions in a clear manner at login and then uses them exactly as they state. Several years down the road, the company is sucked up by someone "not as trustworthy". It's possible they dropped an e-mail about an update to their application Terms & Conditions and buried deep within there is something about consenting to allow them to "star their repositories". Even if they sent a one-sentence e-mail in bright red letters saying they were going to do it, in all likelihood, GMail didn't put it in my Priority Inbox, so I missed it. :)
The "typical exposure a user (including a super hacker) has to 'consent dialogs'" on a PC are the kind that ask for permission "to sign me in and see minimal profile information". On a phone, the things they're asking for are things that "if I give them permission to, I'm not usually allowing them to harm an internet community in a general sense" like "star farming" would. I think seeing these dialogs as frequently as we do might work against paying more attention to them ... regardless of the fact that we know the kind of damage and we'd probably assign more blame to ourselves than is warranted.
All of that said, there's probably more to the story. Unless something stated is fabricated, I can't think of a detail that could be added to the story that would make me feel a permanent ban is justified. I can think of reasons I would be sympathetic to Github initially banning the account (due to AI/automation) and then unbanning the account after "a human being saw that this was something close enough to phishing" that the account should be restored.
Friendly reminder: GitHub has lacked granular scopes since forever, people have complained about the issue since forever, and GitHub haven't implemented it still.
Microsoft also sucks, for more reasons than I can care to count, but this particular issue have been in GitHub since they started exposing their API. Now GitHub IS Microsoft, and it's both of their fault, I guess.
> there are junior devs out there who could've easily done this and your response to them is "get gud scrub".
Because junior devs should remain incompetent forever.
I’m pretty sure GitHub did display what permissions the app was requesting. The user should have been alerted and refused to proceed as soon as it requested more than ‘Access user email addresses (read-only)’, as nothing else should be required just for SSO. The user’s inattentiveness is their problem.
But sure, blame GitHub every time, even when they explicitly tell you the operation entails irreversible loss of data and have you manually retype the repository name.
> even when they explicitly tell you the operation entails irreversible loss of data and have you manually retype the repository name.
This is proof that inattentiveness is something developers should account for. Otherwise, GH could just have easily slapped a modal that said "Are you sure?"
> “On display? I eventually had to go down to the cellar to find them.”
> “That’s the display department.”
> “With a flashlight.”
> “Ah, well, the lights had probably gone.”
> “So had the stairs.”
> “But look, you found the notice, didn’t you?”
> “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
"The plans were on display" isn't an 100% ironclad argument, because there are two contracts taking place: The literal contract being presented to the user, and the social compact that the user expects if they are reasonable.
So, if you show a dire warning to a user, in a place where they are unlikely to expect a dire warning, it's your own damn fault if they ignore it. After all, they aren't expecting it. It's up to you to educate them and prepare them for receiving such a warning.
I'm sure the legal world has some name for this. Probably similar to "how small can you make fine print before it becomes legally unenforceable". "But your honor, the user ONLY needs buy a 10,000x magnifier, and the legalese is plain as day!" Yeah, not gonna cut it, buster.
> I’m pretty sure GitHub did display what permissions the app was requesting.
I don't understand why "sign in with GitHub" should grant any permissions whatever. "Sign in" doesn't mean "grant this website permission to use my github identity". It means "have github confirm my identity to this website".
To me this is both the website's and GitHub's fault for abusing what "sign in" means. The website shouldn't be asking for permissions in this scenario, and GitHub shouldn't be giving them.
Github failed to indicate clearly what the consumer was going to use this person's credentials for.
This is Github's fault, end of story. If the permissions included "can star repos", instead of just "can read/write repos", then sure.
Github are too _lazy_ to build granular enough scopes; they should be able to ask "why are you using this scope?" and it should _never_ be the case that someone using one small part of the api has to ask for a scope granting blanket access.
Granted, there are quite a few issues with granularity of scopes/oauth for various other services, too.
Edit: also the stinking elitism in here; the worst part of the tech community. Just bc someone has a Github account doesn't mean they're some sort of super hacker, there are junior devs out there who could've easily done this and your response to them is "get gud scrub".