Lmao the victim blaming on this one.
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".
deleted 4y ago
[deleted]
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.
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.
deleted 4y ago
[deleted]
This was extremely helpful to me:
OAuth 2.0 and OpenID Connect (in plain English)
https://www.youtube.com/watch?v=996OiexHze0 https://www.youtube.com/watch?v=996OiexHze0
This should really be taught in schools - not how oauth works but that you should be careful who you grant what access to what data.
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.
> 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.
deleted 4y ago
[deleted]
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 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.
I can't see the need for an API to star repos at all. There shoulnt even BE a permission, let alone one that is opaquely labeled.
In the modern web application architecture, a somewhat "static" frontend uses the API to talk to the backend, so an API is a requirement.
How publicised and easy to use an API is is a different matter, which is why captchas are a thing. Though tbh, I hate captchas.
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.
Having seen some pretty deep npm trees, I worry what you're building could end up (accidentally) doing hundreds or thousands of stars.
I'd be careful to not make it recursive, at least - only look at direct dependencies.
Please dont. Your extension will probably get more people banned when they star 1200 repos.
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 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?"
> 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.
> “But the plans were on display…”
> “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.
> 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.
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.
>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?
+1 on the elitism.
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.
Grow some empathy, folks!
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.
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.
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.
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.