Hacker News Reader

Comment by yashap | Hacker News Reader

It probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow, where OP granted them explicit access to do things like star repos. Like, the button on the nopecha site may have said “sign in with GitHub”, but it actually kicked off and authorization code flow with GitHub, where you’re granting nopecha access to do GH things on your behalf. And OP just didn’t read things carefully enough, clicked through without looking.

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.

View on HN

Now I haven't gone through this process with github, but for other pages where I have gone through it, the issuer doesn't just hand out scopes like candy.

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.

For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oauth/authorize?client_id=33a703d01... (I used a random client_id from google search). As you can notice, the UI does not mention stars at all.

[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...)

I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want.

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...

Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories".

I'm surprised this hasn't been used for malicious purposes until now.

> That includes read/write access to code [on public repos owned by the user]

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.

That [1] is how "ask only for e-mail", "proper" "just" SSO looks like.

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.

No this is standard procedure. You have to register the permissions you are going to request to github. But github is not going to inspect your app and checks that they are indeed required.

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.

It is not how Oauth2 needs to work, or should work. OIDC is (or should be) about the user's identity only. It's for third partiets to know who you are, not for third parties to act on your behalf.

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.)

OAuth is definitely about scope.

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.

Why is everyone linking this draft? It's got very little to do with what we're discussing.

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 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?

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).

You don't need RARs to limit access. It's just a proposal to standardize very fine-grained control access.

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.

Sure, but the extra “location” and “action” objects within the proposed “authorization_details” JSON object do seem compelling when compared to just a single “scope” string.

Speaking of shoehorning things, it doesn't look particularly "Open" to me that website owners are free to pick a limited number of authenticating authorities, instead of letting the user to pick their own.

(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 !

It is interesting though, most people use it just to avoid creating a new username/password on a random site. Usually there is no intention to grant access to any data maintained on the IDP's site. I know the concept of granting such access is the whole point of OAuth but honestly seems like a rarely needed use case.

The website (oauth client) has to tell the IdP (oauth provider) what level of access they want to have on the user's behalf. OIDC is an extension of oauth that focuses on the basic identity aspects. (It basically just standardizes the user info and how to ask for it).

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...

Yes, I know how it works. My assertion is it really should not work this way by default. Providing identity (i.e. email address) to a random website is much different from providing them with access to sensitive data (often subtly shown in the signup dialog).

It is good to take a step back from the tech and think about it from the user's perspective.

OIDC is build on top of OAuth and OAuth is all about scopes and authorizations. You can split the two but OIDC is designed to request id info and access authorization in the same transaction.

> This is how all oidc providers work.

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.

Furthermore, a client can omit scope and leave it up to the server to decide whether to fall back to a default scope or fail the oauth request.

This patently false. Google for example requires an oauth app registration and approval process. It's one of their annoying faceless processes that developers must go through, but exists for good reason.

> the issuer doesn't just hand out scopes like candy

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.

As I said, before the app even can ask for a scope, github has to give that app permission to ask for a scope.

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.

> And "caveat emptor" is not the threat model you can get away with on the web.

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”

When you run a service on the web, it's not enough to protect yourself. You must protect your users to the best of your ability. Threats against your users must be part of your threat model.

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".

> When you run a service on the web, it's not enough to protect yourself

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.

Github is not the Norwegian government though. Github is not a gateway to public bureaucracy or to public services. It provides repository hosting, project management, and integration with build tools and similar services. Fostering a wide ecosystem is a core part of their business strategy, and as such applications are only validated superficially. Also, it operates at a scale that makes such validation infeasible.

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.

GitHub is Microsoft. And as a provider of developer tools, weird to see such apologism for their inability to structure oauth scopes correctly and provide effective unambiguous UX for user consent.

Let alone banning the user instead of the client app...

> Also, it operates at a scale that makes such validation infeasible.

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.

Did you see how apparently inoffensive the permission granting sign in is? It looks very similar to a standard login. It would be very easy for anyone, regardless of knowledge, to blow right by that. The lack of distinctive labeling as not a standard sign in operation is really irresponsible on the part of GitHub here.

API scopes could totally use some mandatory standards. You can't make a digital ocean token to simply edit DNS without full delete-all-your-VM's & charge thousands access.

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.

Sounds like a good use case for Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html>

Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had).

Therefore if you want them, pay up or do it yourself.

> Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had).

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).

Fine, put that behind my $x/mo account + service accounts.

$x/mo * Service accounts is dumb.

That's not a practical suggestion, since GitHub isn't self-hosted or open-source.

Well, it is PITA to implement so I'm not surprised really...

If stars are so important that any program that can auto-check stars is inherently fraudulent, then why allow any official third party API the ability to click on stars? Shouldn't that always be something you explicitly have to click?

Giving a website access to star repos through the API for my convenience is not anything I should be banned over though.

> 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.

Presumably the OP would also have been aware that they were giving this third-party app the ability to rewrite the code on any of their public repos.

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.

Exactly.

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.

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...

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.

Of course. When you grant someone read/white you expect that they may delete all your repositories for shits and giggles.

What I would not expect is Github banning me in some misplaced form of victim blaming.

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.

If you lend someone your wallet so they can buy milk, and they go on a buying spree with your credit card, that’s still a crime.

You can blame the person handing out the wallet for being naive, but ultimately the bad actor is the other.

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.

The whole story is suss, tho.

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

GitHub should be able to tell that this was an abusive service doing it though.

Legally they might be in the right, but punishing victims of social engineering further doesn't seem like a fair or smart business decision.

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).

yep, it is easy for them to know if the star was the user itselft OR a third party app through the API...

What you give the site access to is something like ‘Full-repository access’, the permissions aren’t granular enough to specify starring.

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.

Why have repo-starring API if you don't want users starring repos via API?

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?

That I do agree with.

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.

Except GitHub allowed the abusive service to integrate in the first place, and knows every request it created...

I've always had at least one confirmation page where it stated what data would be shared with the 3rd party and what kind of access they get to my account.

True, there’s often a “GitHub will have access to your email address” type confirmation in SSO flows, as that’s basically what SSO is (it’s GH telling a 3rd party “yup this is bob@example.com, feel free to log them into your site as bob@example.com”).

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.

Github does not separate starring. It falls under the public_repo scope, which is one of the fundamental scopes. Source: https://docs.github.com/en/developers/apps/building-oauth-ap...

"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."

FWIW under the new fine-grained permission model (used by github apps, and the fine-grained personal access tokens currently in beta) "starring" is its own account-level permission: https://docs.github.com/en/rest/overview/permissions-require...

> probably wasn’t actually a standard “sign in with GitHub”, minimal SSO flow, it was likely an OAuth2 authorization code flow

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.

if i go with your argument, "what wrong did i commit" if i allowed an application a legitimate action of managing stars? how did i know beforehand the app was going to abuse this very action because there are other commenters saying that stars manage action is a legitimate, non-sinister action in itself so where was i sloppy?

I agree you should not have been banned - I think GH was wrong there. You got taken advantage of, you weren’t being malicious.

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.

I'm sorry you lost access to your github account, but let's be fair. This is not a legitimate application for managing your stars, this is a page that was committing fraud and probably requested access to your account in exchange for committing further fraud on your behalf. You were already logged in. Why did you log in again with github? Because it asked you to, and promised you more rewards if you did?

> Why did you log in again with github?

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

It's a bog-standard oauth2 authentication flow. I'm positive GitHub showed OP the list of permissions that this sketchy third-party app was requesting, and OP granted those permissions.

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.

And they're a bog-standard human. Very buggy, get all kinds of tired and sleepy and drunk and high. I don't have the patience to be terrorized with some dumb ass permission lists when I want to access something. My brain is there to process the experience of eating tasty food and making children with an another human or whatever, I'm not an API. Just ask yourself if the UI would confuse your demented grandmother, if it would then it's shit and I hate it. oauth, shmoauth, who cares?

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./

> And they're a bog-standard human. Very buggy, get all kinds of tired and sleepy and drunk and high. I don't have the patience to be terrorized with some dumb ass permission lists when I want to access something.

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.

All of those things are an excuse. The dialog is dumb and annoying. And excuse me but who are you exactly to tell what I can be trusted with? What responsibility? I'm not responsible for shit, it's a dumb website with bad UI and if I close my eyes then it disappears, that's how irrelevant it is to my life.

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

> Maybe have some kids Got those. I teach them responsibility for their actions.

> 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.

That doesn’t mean the inverse is true though: “if someone else is to blame you’re an asshole.”

Many things are untrue. Including "if someone else can be blamed, I am blameless".

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.

>You were already logged in. Why did you log in again with github? Because it asked you to, and promised you more rewards if you did?

when was i already logged in? there was only 1 action of "sign in with github". thats it

Maybe, just maybe, if companies like GitHub would read the fucking RFC’s for “OAuth is not for authentication” they’d get somewhere.

We at least/even have OIDC for that now.

no i did not because when i click on “sign in with GitHub” flow, that is the only thing i expect to happen. whatever the dev added to the workflow is what i assumed to be needed for the login to happen

As I said, it’s a lesson to read more carefully. If you’re granting a sketchy website broad access to your accounts without even reading what you’re granting, bad things are guaranteed to happen.

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.

GitHub could not control what lies other websites tell. They can have a button saying “Sign in with GitHub”but totally not signing in with GitHub.

That said GitHub should have banned that website for lying and abusing instead of OP.

This proves the point that these third party "Sign in with" buttons are really dangerous.

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.

When I double click on free_cookies.exe which I got from totallyawesomenotavirus.com I expect my computer to start giving me chocolate chip cookies.

Or maybe I shouldn't just take everything at face value and pay attention to what I'm doing.

And how has that worked out for the last 40 years.

That’s kinda your own fault. You could have known they were going to be able to star repos on your behalf if you’d read carefully.

What is strange is that you are banned for an action someone else took. That doesn’t make any sense.

I was with you until the last two sentences.

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?

FWIW, I agree GH shouldn’t have banned OP. But … I’m pretty sure they weren’t giving out access to control OP’s account through a standard SSO flow, as OP assumed. Massively more likely, OP just didn’t pay attention, and granted said access explicitly during an OAuth2 authorization code flow.

My entire point is that they did explicitly grant the permissions and that if you see a dialog like this: https://i.stack.imgur.com/Iol8j.png

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.

> ..is not being sloppy, it's being an intelligent person.

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.

That's... not how evolution works at all? I almost want to think this is satire.

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...

That is exactly how evolution works. Now if you wanted to argue that evolutionary pressure no longer applied due to modern medicine and safety regulations... you'd still be wrong, but at least you'd look less silly. So there's two kinds of people:

- 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.

There's an incentive to ignore the trivial BS that other humans relentlessly waste your time with. Reading EULAs and watching ads are not the path to success. People are trained to ignore information constantly.

Intelligent apes surrounded by wiggling bushes stop paying attention to wiggling bushes and get munched on by a predator eventually, no?

> Reading EULAs and watching ads are not the path to success.

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.

My point was just that whatever mental heuristics we use to decide whether information is worth parsing or not are built up over our lives. As with all such approximating things, there is trade-off between false positives and false negatives. The large amount of junk information one encounters in modernity could lead to aggressively-tuned heuristics, resulting in more false positives relative to negatives, effectively sending useful information to a mental spam folder.

And now I want to listen to Running up that Tree, by Ape Bush

You got me, I thought for a moment that I accidentally channeled Weird Al instead of Pearl Jam's Do the Evolution.

Reply on news.ycombinator.com