Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Developer abused “sign in with GitHub”?
860 points by 2Gkashmiri on Dec 9, 2022 | hide | past | favorite | 480 comments
The offending website "nopecha.com", which unfortunately i found about a week ago on HN itself appeared to be another captcha service but one that was offering "1 Sec" solve speed for text captchas. i was interested and by the looks of it, a lot of people. their webisite only had "sign in with google" so i didnt bother. The day before i check the website out of boredom and saw "sign in with github". i logged in, clicked through a bunch of pages because its the same drill everytime. i found out that i had "automatically starred their repos". by the looks of it, around 500 "stars", the last i saw.

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?




I partially blame github for having very un-granular permissions -- a sign in with github ought to be possible without granting the site any permissions to do anything at all on behalf of your account, other than verify your identity via OAuth.

But I have no idea if that really is possible, and we have gotten used to granting sites permissions to github, specifically, beyond what they really need, because github often doesn't make it possible to give them what they really need. So we've been trained to be like, sure, whatever, okay, grant permissions.

(I used to complain to third-party sites when they were asking for more github permissions via oauth than they needed, and even say I woudln't use their service becuase of it. The answer was invariably "Sorry, github won't let us get the permissions we need without this overreach", and the times I had the energy to investigate, it looked like they were right! And we're talking really basic things, like read-only to a single private repo without write to all private repos in all organizations!)

However, on top of all that... this site is offering to automate solving captchas for you? Is there any non-sketchy use for this? I guess I am not too shocked that a site offering to take your money to help you bulk trick your way past captchas is... doing something else unethical too?


I think one other thing is missing. There's generally no way to review what a service or app does with the permissions it gets. There should be an access log for any API used through OAuth so you can ensure that what you signed up with is actually doing what it says it's doing with the permissions you've given it.

edit: And once there's an access log, there should also be a way for users to flag/report suspicious activity for review. There's so much more we could be doing to protect users.


Also, why can't I set a phantom/virtual/dummy profile for a specific app/service asking for permissions? Why do I have to choose between not using something and giving it access to everything it wants? Why can't I choose which real data it's allowed to see and which is dummy data, regardless of permissions?


I also blame GitHub for not having a way for a user to grant only some of the permissions requested. Every once in a while somebody on my team will try to look into CodeCov integration, because it sounds useful. And then we realize it wants the ability to write to our repo, plus the ability to manage arbitrary hooks, when it should just need the ability to write check results and read the (public) repository. Every time we give up and don't use it.


Just make a duplicate repository under a different name for the sole purpose of codecov and other such integrations.


Pretty much everyone who uses GitHub for auth is going to want the user:email scope. But you can definitely do OAuth where that's all you ask for, and have no permissions to mess with the user's account.


Github has recently introduced fine grained tokens.

https://github.blog/2022-10-18-introducing-fine-grained-pers...


That's good progress to see! But in addition to that being a public beta launched less than 2 months ago, that doesn't seem to cover the case of "sign in with GitHub". It's for personal access tokens, not OAuth.


> ...this site is offering to automate solving captchas for you? Is there any non-sketchy use for this?

Accessibility.


Yeah, I would pay to reduce the number of clicks. Already using voice to text and a fancy professional mic.


Don’t the good captcha sites have audio and other means as an alternative?


hCaptcha is awful at this. You can request an 'accessibility cookie' by typing in an email address but for me it denied me with a generic error.

I contacted support, they asked me for IP and browser details. I responded and they gave me suggestions like using a VPN or rebooting the modem to pick up a new dynamic IP. :/


Sure but that doesn’t always work for everyone.


A screen reader is replaced by the audio, and otherwise for you to use the webpage you’re looking at it so you can see. What’s missing? I guess if you rely on braille because you’re deaf and blind?


> Is there any non-sketchy use for this?

Aside from accessibility, which a sibling poster noted, there's also just: CAPTCHAs are effing annoying. I am so tired of proving I'm not a robot over and over and over by giving Google free labor training their image recognition models.


Is it free labor? You’re essentially paying for access to “free” services


But you pay for their services whether you actually use them or not, since reCAPTCHA is so prevalent across the internet. So yes, free labor is a good way to characterize it.


GitHub can do that. Eg if you try to use GitHub to sign into gitlab.com:

GitLab.com by GitLab wants to access your unilynx account

- Personal user data

- Email addresses (read-only)

This application will be able to read your private email addresses.


Yeah, I am very new to the dev world, but I was blown away by the amount of information that GitHub let me have for free when using their oAuth implementation. I'm honestly glad to hear this isn't normal.


Or it didn't really use Oauth, and just outright stole his password.


While providing third-party login services as way to sign-up had some benefits, omitting the "Sign-Up with email" option downgrades the experience dramatically. And, you know what? Providing only third-party sign-up options with "unnecessary" privileges ruins the entire experience.

A few weeks ago, I wanted to sign-up for a Product Hunt account, and in just a few seconds, my experience.. you know.. "downgraded" because there was no other way to sign-up other than through third-party services. After hesitating for some time, I forced myself to try to sign-up with my Twitter account. I clicked the Twitter icon, and it took me to Twitter, where I got these "cute/honest" permissions requested by the app I'm willing to authorize:

1. See Tweets from your timeline (including protected Tweets) as well as your Lists and collections.

2. See your Twitter profile information and account settings.

3. See accounts you follow, mute, and block.

4. Follow and unfollow accounts for you.

5. Update your profile and account settings.

6. Post and delete Tweets for you, and engage with Tweets posted by others (Like, un-Like, or reply to a 8. Tweet, Retweet, etc.) for you.

7. Create, manage, and delete Lists and collections for you.

8. Mute, block, and report accounts for you.

9. See your email address.

Oh man! 4 and 5 and specially, 6 are my all-time favorites. Are all these permissions really needed to be able to create a PH account with my Twitter? I mean, cmon.. this is not supposed to be an alternative front-end app for Twitter like "Apollo", "RiF" and "Relay" are for Reddit, this is just a website where people post their e-products once they launched, simple, huh!

I cancelled this process, and I still haven't created a PH account yet, but hearing OP screaming with this scary submission today makes me think again 'n' again.. maybe forever.. to proceed down this path.


Funniest shit is when you finally sometimes fall victim to the feeling of "Ok fine, I'll use Twitter for the auth so I don't have to fill out the fucking 10 field form just to be able to sign up, why you need to know my current position anyways?" and when you're finished, they're just using the auth to autofill the username and email for the signup form and you have to fill it out regardless.


This is the absolute worst and why does it seem to happen 80% of the time?


Because most teams didn't write their user-auth code, it's either a framework or another team. But the PO want "Sign in with Twitter" so you hack this together.


It's so they can feed the data into the sales team in case their algo thinks you are a viable target to sell things to.


They know people don't always update their profiles and use throwaway accounts. They nudge you to provide actual data.


"Nudge"? You sound like a project manager

Forcing to create a new password and field out additional fields isn't a nudge


Before 3rd party sign up existed, I remember there were patterns, where the website you have registered had an option to add your "friends". Caveat was that it asked for your email and password to your email, so it could download your list of contacts. Crazy part is a ton of people didn't see a problem with this...


...Didn't fucking facebook did it at one point ?


Linkedin. FB probably too, but too lazy to check


Linkedin was worse. It used the login/pw to send emails to your friends from your email account, inviting them to join Linkedin.


Clubhouse too. Remember Clubhouse?

https://news.ycombinator.com/item?id=25685454


there's a big difference between a permitted contacts api and just giving up your regular gmail password.


Wait, after finding out the site is obviously just trying to grab as much info from you as can be profitably marketed and even after it sets itself up for further abuse, you are still considering signing up?! I really hope I'm missing sarcasm there, cause otherwise you need to readjust the amount red flags you are willing to ignore.

"Sign up with" is a tracker's paradise anyway, but not even offering something untrackable like email is just screaming out for everyone to hear that you are the product. With the abusive access demanded, it's down to victim, really.

Have some pride, people, and don't fall for these scams!


What I don't understand is that OAuth (and related) is supposed to be a protocol, so why can't I as a user get the option to enter one ?

Imagine if you could only pick Gmail or Outlook in the form for email !


that was a thing with openid but it pretty much died out.


Obviously bad permissions are bad. But "sign-up with email" means that you need to manage you users identities which is complex and risky. You can delegate that using something like Auth0 but then it costs you money.

If I am creating a new service today I will probably won't bother and just offer social logins.


> which is complex and risky

It really isn't, it's fairly basic. It's mostly "basic" because people have been implemented those things for so long that there basically are established patterns you can reuse with very few drawbacks.

As long as read up on how to implement it and use common sense, you can get authentication working (& being secure) under a day.

Edit: Today you can even do it the lazy way and implement "passwordless" email login as a step to see if it's worth implement the simple email+password way later. Basic steps: 1) Allow users to request login, which creates a login token in the DB and sends a URL to the users inbox 2) Allow users to exchange login token for a auth token that eventually expires somehow, delete login token from DB and store login token 3) be able to lookup if a login token is correct when hitting other API endpoints

Congrats, you now have a basic authentication scheme


That ruins the experience for all users who don't want to give you their Facebook or Twitter.


Even better: I don't have Facebook or twitter, therefore I'm out. :-)


Is "Sign-in with your Hacker News account" a thing?


I will never use social logins to sign up for anything. What a terrible idea. I assume anyone doing that is just doing it for tracking or scamming purposes.


If you have a password manager synced across browsers, like chrome or firefox's builtin ones, it should be fairly simple, right?


I really don't see how using KeePass or alt is hard, and it doesn't cost money.

If anything, it's 2FA that has me more concerned, because it has made my phone number a near single point of failure with the way everyone wants to use my phone number for it still.


You'd be excluding a whole lot of people who don't have any social media accounts, and a lot of others who aren't willing to use them for this purpose.


Good luck.

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)


You can't always avoid it.

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.


The best way to fix the problem is not to sign up to such companies and complain instead. If you can't find a feedback form, perhaps they are not interested in feedback? In that case there's always twitter.


just heard of snyk and googled

> 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


> You can't always avoid it.

I've managed to. It does mean that some services are unavailable to me, but that's life.


Maybe a way to handle this kind of situation would be to create a dedicated Google account?

(I haven't encountered the situation myself, didn't try it)


Google is known to link accounts by ip address, name similarity, phone numbers, emails, etc. There are for example stories of companies with their Google Cloud disabled because former employee using their personal account pushed app Google didn't like to Play Store.


And anyway you need a phone number for each account now. What a PITA, by design of course.


Tailscale only allows you to create a new account by signing in with Google, Microsoft or GitHub. It's a real shame because it's a great service otherwise, but this left a very sour taste.


I don't use services that force me to give up privacy like that. A VPN service no less? That's almost funny.


Tailscale is a real VPN, not a privacy proxy using VPN tech. VPNs have nothing to do with privacy, this is no worse than any other service doing it.


Virtual Private Networks are all about privacy. They aren't necessarily about anonymity though.


The term "VPN service" has become synonymous with "proxy service that allows circumventing region locks that is implemented using VPN". These services are often pretty scammy and have come in the news often for harvesting user data.

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.


Yes, that's what my comment is about: Tailscale is about privacy from the outside world for your network, not the privacy and anonymity VPN proxy services claim to provide.


Something being private and having privacy mean very different things in practice. I can stand in the middle of a field that is my private land, but have no privacy from people on the adjacent road looking at what I'm doing or listening to what I'm saying.


Private != privacy. Private corporate networks do not guarantee privacy either.


They do guarantee privacy from the outside world. They don't necessarily guarantee anonymity or privacy within the network.


No they don’t. VPNs allow _access_ to a set of subnets that might not be accessible otherwise - normally from external to private. Even though usually vpn traffic is encrypted it’s not a rule or an inherent property of VPNs - see GRE and PPTP for example.


> VPNs have nothing to do with privacy

Don't feed the trolls.


Yep. Single reason we don’t use them anymore. Great service, but we don’t have corporate MS, GitHub or Google accounts.


Any alternatives you can recommend?


I’m a big fan of Nebula (Slacks project maintained by Defined Networking)


Head scale FTW? I mea n you need to self host it and deal with all that... But it is your network...


It does look like they support SAML and OIDC. I think the idea here is that many (most?) Tailscale users will be corporations, and most corporations would rather integrate Tailscale access with their existing auth system, and not have an extra employee account to deal with that needs to be disabled when the employee leaves the company.

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.


You can add your own external provider. I'm using them with Okta at the moment.


Oh that's a shame.


If you want anonymity, why not just create new Google/Microsoft/GitHub accounts? How is that different from creating a new "Tailscale account" - presumably with what, your existing gmail address?


> For others, let this serve as another lesson to never sign in somewhere with any account if you can help it.

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


Not sure if you care any more after a couple of years, but https://meta.stackoverflow.com/q/309839

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 came across the same realization after disconnecting from twitter. I am signed into multiple places using twitter. Even though I have deactivated my account, I have to reactivate every time to login on a site like disqus.

FB, Twit, Goog, need to separate oauth login from the rest of their service.


You say the morally correct thing, but being a Managed Identity Provider is gonna cost loads of money and they really have no business incentive to do this, in fact it may be negative for some of their KPIs like the no. of sign ups they have on their site.

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


Can you trigger the reset password flow on disqus, etc? That’s what I’ve done on a few sites to disconnect from 3rd party oauth and use email instead.


I reactivated to disconnect disqus. But twitter does not share email address with sites so i could not do forgot password. That is why it was my preferred login technique.


Anyone know how to list which sites I used my twitter login on?


Don't know about twitter, but most providers have some sort of "Applications" tab in the user settings that lists every site you gave an oauth grant to.


https://twitter.com/settings/connected_apps

Kinda deeply nested into settings submenus.


It shows blank for me. And I know have had more than three sites that used it.

I think that is for third party apps that help you tweet. I never used any.


There is no way to create a regular account on Travis. It's only sign in with GitHub and a few others that they added recently.

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.


I believe it goes against the ToS for Microsoft GitHub to have more than one account per human.


https://docs.github.com/en/site-policy/github-terms/github-t...

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


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


A lot of the APIs that allow for things like starring projects have been around for a long time. Before GitHub introduced an official mobile app there were a number of unofficial mobile apps that used those types of APIs to give users a “fully functional” GitHub app.

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


> With hindsight I think that I should create a per customer account on GitHub, just in case something bad happens to Travis.

In case you missed it: https://news.ycombinator.com/item?id=33906591


Or do not do

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


Whoa, I'm very surprised at the amount of "told you so" and blaming the user in this thread. How many times are we going to retread the same tired arguments in this industry? Not everyone who uses github and other SSO sources is a elite hacker that knows exactly what the buttons they're pressing mean, plus sometimes we just make dumb mistakes. At the very least github should make it much higher friction to give a third party access to fuck with your account, and only make it dead simple to act as a identity provider.


This. Also the whole situation reminds me the early days of Facebook, when people abused your account with posts to the wall and so on.


You don't have to be an Elite Hacker to read a permissions list and be informed about what you're consenting to.


The UX for the authorization prompt is awful. The only difference between a regular sign in prompt and authorizing access to repositories is a single word: "Repositories".

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!


Everyone over reaches on permissions though. It's practically industry standard to ask for a whole bunch of permission you don't need. Such that the likes of Google have multi-year efforts to crack down on it and reduce the ability to do it (in say Android).

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"


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


because every time this happened, I will always think, great, now company gonna waste another resource for the benefit of the stupid, careless, lowests common denominator, and absolutely no benefit whatsoever (or worse) to people with common sense.


Is it really a waste of time for Github to target the site instead of the users?

If anything, Github already wasted time by targeted the user into a victim, rather than the original source of the API call.


I didnt say that. Dont put word in my mouth.

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.


Bad actors exist everywhere and manage to get even distinguished security people at times.

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.


I'm going with, no, GitHub shouldn't have banned your account. Disproportionate response.

They've bundled several different functionalities together in a GitHub account, but the core functionality is to publish public git repos, or access private ones. Account banning for abuse should relate to you not being trusted to do those actions, not the secondary actions. If you published deceptive malware repos masquerading as other projects, sure, ban the hell out of you. If you use your private repos as the nexus of a botnet, likewise.

"Use your stars to participate in GitHub popularity contests" is, like, a tertiary functionality of your GitHub account at best. If you can't be trusted with that, it should be separable from the rest of your account. Set a flag on your account that prevents your star from contributing to votes. Hell, give me a config option that lets me turn off my stars counting.

Banning your account wholesale is overkill and unreasonable.


For all their faults, that's something that Amazon actually does well - abuse their reviews system, you will lose ability to write new reviews/rate products, but you can still access all other functionality.


It's nice they handle that case well, but Amazon has similar arbitrary account lockout issues. I tried to buy an Amazon gift card for a friend, and I got locked out of my Amazon account entirely, including all of my Kindle ebook purchases and my AWS account (which had some backups in S3). Their system thought my account got hacked and was being used by a hacker to buy a gift card. It took a lot of back and forth interactions with support before I could convince them that there was no hacker involved and I wanted my account back. It was only once I mentioned the large amount of Kindle ebook purchases I lost access to that they finally budged. I even had 2fa set up and my phone number connected to the account that should have been able to verify my account. Thank god it didn't go worse and I wasn't using AWS for anything important at the time.


I know this doesn’t help your current problem, but there should have been a list of permissions your were granting during the setup flow. Anything more than asking for your identity is the indicator that a site could cause you trouble, unfortunately.


Permission overload exist specially when you are allowing users to sign up to third party sites with your platform credentials.

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.


The problem is GitHub's permission system is bad. I'm not sure if the problem is that legitimate apps are required to request way more permissions than they want to get the ones they need, or if the prompts themselves are basically crying wolf all the time ("act on my behalf"? That could mean literally anything, why are you showing me that at the bottom of a list of other permissions? Doesn't it imply all the rest?).

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.


Many of these permission grant UIs are bad. It should always be possible to grant some permissions and not others, and optionally, if a website does not receive a permission it should be able to send fake data in a well-formed API response response to fool it into thinking it actually got the permission.


> if a website does not receive a permission it should be able to send fake data in a well-formed API response

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.


> let developer know permissions have been refused

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.


The right thing is to generate fake data, but also provide an API to check whether the data is fake or not. That way apps don't have to test every permutation of granted/not granted permissions to ensure they don't break, but apps that really care can still explicitly check to see if they got the permissions they wanted.


This opens the door to unscrupulous apps that deny you access if you are using fake data, in the name of tracking you.

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.


agreed. 100%. in hindsight, but you know how you sign in to netlify or to some other website, the same thing happens, you are supposed to accept and there is no "continue without giving these permissions" so its an "either you continue or go back and dont use" thing..... i am saying, over 500 people fell for this and this is a good example of "permissions overload" and other such phenomenon. you just go through the flow because you expect everything is in order


> you are supposed to accept and there is no "continue without giving these permissions" so its an "either you continue or go back and dont use" thing

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


I wish SSO providers allowed users to individually decline requested scopes when logging in.

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.


I think we'll get there eventually, like how on iphone/android you can deny individual "scopes" these days. It took a long time and there were some growing pains, but now I have little worry about some sketchy app slurping all my photos from my phone.


Platforms can implement that and some already have, e.g. Facebook’s auth works like this.

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.


As a developer, I know exactly how I'd solve this.

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.


yeah, the granted scopes are part of the id tokens, so they're visible from the requesting application. They could theoretically be hidden by encrypting the bearer_token itself (thats part of the standard already, though few seem to actually do it atm) and omitting them in the id_token, but omitting it would to my knowledge be in violation of the standard

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.


You can't?

Why on earth would anyone use SSO? Are we that lazy?


The world works by automating things. When was the last time you washed all your clothes by hand?


Hardly an apt comparison.


Some do, some don't. That said, I haven't said a option to reject scopes on any of the big oauth providers


Well, there are two options here.

Either Github authorization, that by default asks only to use email [1] (I clicked some random GH sso using site, the one mentioned in post above doesn't have GH auth at the moment) have a bug and also gives starring rights.

Or OP is having prompt-induced illiteracy syndrome which caused them to not read and just click accept till "the thing worked"

* [1]https://imgur.com/a/VTFc2FD

...I give it 30/70. Kinda heard the second version from my users way too often


Fair point. But even if it had warned me that the site would be allowed to star repos, I would consider that such a low-risk innocent thing that I would likely just ignore it. Until reading this post I would have never considered how that could be abused.


Well, github does need some more fine-grained permissions.

Another stupid thing I found is about GH organization access.

If org didn't had Third-part application access policy set to restricted, THERE WAS NO OPTION TO NOT GIVE PERMISSIONS TO A TOKEN.

As in I HAD to give permission for repos for org I was in if I wanted to give app permissions for my personal repos.

Only after enabling that option in org I was given an option to not proliferate permissions to org I'm in. I happened to have admin access so I just enabled that option but if someone didn't it would be real easy for some user to give too much permissions on accident...

It really feels like those permissions should be at per-repo level. App should never need to have access to all of them, even if it asks for all there should be option to give limited access


See, my first question would be "WHY?!".

Every unnecessary permission is suspicious until proven not to be, and will at the very least be used in ways that I would not, if not even actively to my detriment.

Your android flashlight demanding to read your contacts is trying to scam you ( and worse, your contacts through your negligence), not just ask for some harmless permission you needn't care about.


Hence why the Google Play store reviews app permissions requests, just like Google OAuth app registration does, and just like GitHub could do...


There could be cause for legal action against Github over this, since one could not reasonably expect that using Github's own "Sign in with Github" could allow the site you are logging into to automatically cause actions on your behalf that would result in your account being banned. Contact a lawyer.

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.


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.


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.


[flagged]


What would the 'completely valid and compelling reason' be in this case? I can't think of one.


I'd like to login to a 3rd party site to determine that their DOM structure hasn't changed - because I develop an extension that interacts with it.

It's great when you can get a test account for this, but often companies will simply tell you "create a throw away account and test there" (ex: google does this).

That's not malicious - I'm well within my terms of service - I'm not doing anything with the service other than ensuring that behavior that is not contractually guaranteed still works (because unlike an API, most sites change their DOM often and with no warning).

It's not something I can fake with self-hosted content or mocks, because my version won't change when their DOM does.

---

I've investigated captcha solutions for this exact reason. Not to mention ways to automate 2fa. I understand the overlap with malicious intent here, but just because there is overlap does not imply that OP was malicious.


Not really necessary to curse at someone, even if you strongly disagree, my guy. You've been around HN long enough to know better.


> You've been around HN long enough to know better.

I’m sorry which rule covers that?


If falls pretty squarely under these guidelines:

>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


For what it's worth - this is the same colloquial language I would use with close coworkers when discussing topics.

None of the cursing is directed at the person, but the topic under discussion. At no point have I cursed at him, or even been snarky to him. I have used emphatic language outside of a formal setting.

Personally - the existence of a curse word alone is not enough to invalidate an argument.

And in this case - it reflects my true opinion on the topic: It's bullshit to blame the user here, when the tech exists precisely to allow more accurate determinations of cause. It literally exists to prevent EXACTLY the sort of grey area the commenter above me seems to take for granted. I absolutely should be able to allow an oauth app to interact with a service and not be held accountable for malicious actions of that app if the actions are the result of abuse by the app and not my intent.

Otherwise why fucking bother with the rigmarole of the oauth app registration in the first place? Just hand the user a personal access token and let them plug it in where ever they'd like if you're going to ban them anyways...


It's the very first guideline regarding comments:

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


My bad. I misread the initial interaction.


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.


> 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


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


I find this an interesting question - if you have a private repo with code in it and you get banned in this way can you export that repo? There could be situations arising where you don't have your code anymore because of the banning and that would probably be actionable.


Hopefully OP can recover any lost work(Or simply get unbanned), but I will venture a guess that buried in GH's TOS is something that amounts to "You agree to these rules, and if you violate them and get banned that is on you" and they can point at this/these clause/s and say, "Hey, OP broke the rules and that's that"


i do have public and private repos that i would love to get the data from but all the links are dead as of now


well then I would consider it might be worth talking to a lawyer, you have placed work into these repos, github no longer wants your business cool enough,

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)


cool. i will be mentioning that in my "strongly worded letter" as i wrote in another comment


Before you send that letter, talk to a lawyer. They have an army of lawyers. If you consider the account and its contents valuable, you should hire a professional who knows how to get the best results. DIY legal work is foolhardy.


GDPR "data access request" ought to get them to give you a copy.


if they're in EU, if in EU there are a bunch of other things that might be considered problematic legally with this behavior of github's so...


I've not seen any cited legal argument that says they can't ban you under their TOS?


No, but it doesn’t matter how “banned” your are according to the service, they still have to provide all your private data upon request.


They should require you to log into Github and use the full Github UI for any app permissions beyond saying knowing which github account it is.

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.


> Contact a lawyer

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.


> There could be cause for legal action against Github over this

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.


What laws are they breaking? Can't GitHub ban you without a reason? What about HN? Are they not allowed to ban whoever they see fit? Seems scary that I could face a lawsuit if I ban someone I think is obnoxious on my forum.


It wouldn't be a matter of laws being broken. It would be a matter of contract violation of some sort.


So of you don't have anything you sign on account creation you're safe? E.g. Hacker News is just name/password.


No, probably not. Here's the thing, GitHub integrations always ask the user whether they authorize the integration, they provide the list of permissions that the integration is asking for.

It's not GitHub's fault if the user doesn't read the permissions and authorizes the application.


Yeah but it is GitHub's fault for banning the user instead of the abusive application. You realize the oauth token is connected to the client_id, right?


damn. i am one. haha. waiting for their support to respond to my "response". i would be sending them a strongly worded legal letter if they don't let up but yeah, around 500 people are suffering and i want to talk about them en masse


Not really. Your GitHub account doesn't belong to you: it belongs to Microsoft. They let you use it as long as it pleases them, but it's their database and their servers and they don't have any obligation to continue to do so.

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


In Europe the account is not yours but the attached/coupled data (from email to code), since your are banned you also cant delete it, that is a legal problem...at least in europe.


A bigger legal problem here is that, being a US company asking for personal data, GitHub/Microsoft is effectively illegal in EUrope :

https://en.wikipedia.org/wiki/Max_Schrems#Schrems_I


Using gitea doesn't work if you are doing things for some existing repo in github, esp. if it's non-git related such as reviewing PR, issues, etc.


If you put .patch on the end of any GitHub commit URL you get a diff format patch and it usually has the committer's email the top. You can then email them your diff.

It's not perfect and it's not social/collaborative but it gets the job done in the absence of a mailing list.


Laws are different in the world. I'm pretty sure in Germany the account would have to be restored.


There is no legal action you can take.

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.


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


The amount of victim blaming here is over the top, even for HN. What I am really surprised about is the sheer number of people that are happy, or even gleeful, that this happened to this developer.

I've noticed a decline in the mood(?) on HN, but this is down to a whole new level.


I think you just need to wait. Dang has pointed out that early posts on a new-ish story tend to be of the lowest quality. At this point, most of the shitty posts have been downvoted and the top spots have been replaced with better quality.

Granted, looks like you posted 8 hours after the story was posted, so that should be enough time.


Yeah, I usually check HN early in the morning so I often get to see that "first posts are often terrible" effect. I don't think that's it though.


How to discuss the need to read the text before signing without blaming the victim? Or your suggestion is to refrain from discussing the victim’s actions whatsoever? Honest question.


Assuming honesty ...

There is a difference between:

"This is why you shouldn't use GitHub sign-ins, or any social logins, use email logins."

and

"It's your own fault. You deserve what you got! GitHub did the right thing here."


Sure, but the majority of reactions here are of the first type.


"Sign in with X" buttons all suck anyway. Why lose access to just one account when you can lose access to dozens? Use a password manager.


Agreed wholeheartedly. It has been a long time since I've run into a site that doesn't have an "or sign up with your email address" option, but whenever I do, I just decide not to bother. I don't really want any of my accounts tied to each other if I can help it.


If you use gmail, is "Sign in with Google" tying accounts together any more than "or sign up with your email address"? Don't they both mean you're relying on your google account/gmail address existing?


I use my own email domain.

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.


And more importantly: sites shouldn't require an account for things that don't require an account. I don't want to make an account just to read free content, download free software, or buy something.

Accounts are only necessary if I actually have to maintain content on the site, or specific permissions are tied to my account.


Mostly agreed, but I like to use them in cases when I'm fairly convinced that I'm using the service as a one-time thing to throw away anyway.

What makes me unhappy are the services that don't support non-oauth accounts at all, e.g. ProductHunt.


Uh?

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


2FA isn't the end all be all if it can lock me out by losing a device or an arbitrary number I dont actually own (e.g. sms 2fa)


With a password manager, keeping track of 10 passwords is barely any more effort than one user account. Same thing is true for 2fa secrets.


Use authenticator apps or things like yubikeys for 2fa, using your phone number is not a security benefit but an exploit waiting to happen at this point.


And the day the "master" account gets suspended or compromised you lose access to 10 other accounts. No thanks.


Literally impossible on the given website. It only supports "Sign in with Google" (now). I won't be testing it out for exactly that reason.


If you want people to use your authentication then you can not start banning accounts depending on which sites they authenticated against. What's next? "that political site was not in our view"?

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?


> you could be banned from one service and suddenly everything connected to your account is also banned.

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!


Just avoid using the "sign-in with" buttons ever. They are evil. Sooner or later you find out a reason or another why. Always sign-up with e-mail (and yes, for those who don't know, writing your GMail address and using the "sign-in with GMail" button are very different things).


> writing your GMail address and using the "sign-in with GMail" button are very different things

For those who don't know, what's the difference? Thanks.


"sign-in with" buttons mostly implement something like OAuth2 or OpenID protocol communicating with the authority (i.e. Google) server. Signing up/in the ordinary email way (when you enter your e-mail address directly into the 1-st party website without getting redirected to GMail/Facebook/whatever) does not, even if the email address is hosted on GMail. It either doesn't communicate to Google at all or just sends a simple email message to your address using bare SMTP. This is the nature of the difference and it is huge from the technical point of view.

There are downsides to both. Arguably those of the second are more annoying but less harmful.

The first downside I found (the moment I stopped use "Sign-in with GMail") - Google was passing additional non-essential privacy-compromising information about me besides my ID to the websites I signed-in to..


Thank you! I'd love to read a long blog post about that.


Can we make the GDPR thing permanent across the board that the company isn't allowed to send me unsolicited emails I didn't sign up for? This is the worst part about signing up with email.


Isn't your email exposed as well when signing up with a third party ? I do use third party auth but it does not protect me from unwanted emails so far...


I just realized that GitHub accounts can be suspended!

Important reminder to maintain a backup of any data stored on your online accounts.


It's another reason your programming community should lock into a platform as well. I know certain languages where this user would no longer be able to participate and publish packages anymore.


It is incredibly easy to click past some OAuth prompt only to find out later your account has been used to do some shady stuff. In the early to mid 2010s it was a rampant issue on Twitter. Always double check what you are allowing some app to do with your stuff.


It seems like GitHub gave them the boot as well: https://github.com/NopeCHA/NopeCHA

Is it possible you got caught by some automated system that tries to prevent sockpuppet accounts from inflating stars?


They were dumb to expect they would get away with it.


https://nopecha.com/

nope. Google login is still present on the website...


What are you “nope”ing exactly?

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?


sorry. i read that as google. i know...... sorry


No worries. That explains it. Thank you for the explanation. :)


What i take from this is that your personal actions on GitHub and the actions of a bot doing API calls are indistinguishable in their logs, otherwise it would be obvious that those stars have a caller that is not you.


That's the first thing I thought. They should be able to see which actions were taken by the app and undo them when cleaning up the abuse. No need to ban accounts.


Essentially how GitHub works is, when you sign in with the app, the app requires knowledge and data from the user. For example a simple GitHub integration telling you how many stars your repos have, they may need read access.

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.


The required scope for stars is 'public_repo' and the UI for that does not mention stars at all. Unless you click the dropout all you see is 'Repositories - Public repositories', which does not sound dangerous at all (although yeah, that shouldn't be needed for login).

Clicking dropout shows that permission is r/w not just r/o, but does not mention stars either.


"Read and manage" does not at all sound like read-only access. Is that not supported by GitHub?


Reading is supported, but writing permissions can also eb provided. Heroku is one great example of this, if you want to host your application on Heroku then you will need to grant read and write permissions.

In that case, Heroku may add files such as Procfile, etc.


1. If those permissions aren't reasonable to ever grant, then they shouldn't be available.

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


if stars farming is wrong, why should "1. Read and manage your stars 2. Read and manage your repositories." an application get these accesses in the first place?


An app that manages your stars and repos in some manner can be completely legitimately. Imagine perhaps an app that shows you some concise, curated list of what you frequently use but haven't starred and gives you the option to star them. Or imagine an alternative GitHub UI that just generally replaced all of the features of the default UI, including starring and unstarring.

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.


read is okay, write allows these abuses, no?


Well for example say it's a SublimeText plugin that you use for code editing, browsing repos, etc. And one of the options that you have from the control panel thing (ctrl+shift+P) is "star current repo." That would be a perfectly legitimate use of the API to apply stars, because you're deliberately taking this action yourself, it's not an app doing it maliciously.

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.


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

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


I guess the logic is "you are responsible for vetting who you give permissions to" but yeah this seems a bit extreme, I would not punish the users in this case either.


tomorrow github will ban sublime text because the dev allowed a malicious user to become a contributor and they changed the code to inflate their profile/repo. suddenly you are banned because you did not deny the permission to sublimetext ?


I think the star farming is inside the 2nd permission, read and manage your repositories.

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.


agreed. I am just saying, if someone can abuse stars action and be banned for it, what "legitimate" usecase is there in the first place otherwise?

So if this action was allowed by github, how is that a banable offense if someone gets overzealous with it?


I don't think it is bannable. I feel like explicit permissions should be verified by GitHub, so that they know that the use case is called for.


Because if it's not being malicious it might want to let the user star things in a non-farming way.

Is that not obvious? It's not a "farm stars" permission.


Slightly surprised by all of the victim blaming here.

The guy didn't intend to allow github star abuse from his account.


SOOO much victim blaming. I hope they remember all the victim blaming they did when they eventually fall for a bad actor.

Maybe I should write a bot that waits for the inevitable hacker news post and reposts the victim blaming comment from the past.


A slight aside:

It's interesting that things you create for one purpose can be turned into something else entirely by "culture". In this case, the primary reason for the addition of stars on Github was to make it easier to keep track of things you found interesting or useful. Their manual currently introduces stars like this: "Starring makes it easy to find a repository or topic again later."

But having many stars indicates popularity, and popularity indicates quality, and Github is used as a resumé…

When combined these factors turn the stars into a kind of currency, and brings in all the problems facing any system that handles any kind of currency. This may or may not have been Github's intention from the start, but it seems like they haven't really adapted their systems to treat access to starring powers like the access to currency it de facto is.

So be careful when you design things: the way they're used in the real world can transform something innocent into a big problem for all involved.


If stars were really for bookmarking, the solution would be simple: don't display total stars publicly. But we have browser bookmarks for this, and there is a way to subscribe to repo updates which is much more granular than a star. Taken together this suggests that the star function was always designed as a popularity contest.


I read a lot of comments here and everybody's "Github this, Github that". It's 4 years since Github was bought by Microsoft, so here is the breaking news:

Github IS Microsoft.

So every time you read "Github" invoke that part of your brain that uses "ReplaceString" function and read "Microsoft" instead.

"Sing in with Microsoft" - do I really want to use that on "this obscure site" knowing that if my account gets suspended/banned, Microsoft won't care at all? That's the real question.


Github identity and Microsoft identity are separate.


Doesn't matter. Both are controlled by Microsoft.


These are the common pitfalls for identity providers and their users. Usually you would have to check which claims the services requests from your account. I don't know the implementation of GitHub, but it should be their responsibility to display the needed permissions the service requests from your account. But these descriptions often aren't really transparent, you would need to know which GitHub API needs which permissions.

Yes, it is convenient, but third party login comes at a price and in my opinion that price is quite high. A bit funny (sorry) that it compromised their own product with false data. Since it is essentially their fault, you should get your account back and the service abusing your login should be removed from their identity provider. Probably already happend, but I fail to see how users should be indicted here.


I don't have any opinions on whether or not the OP should have done what they did, but it is a fairly concrete object lesson, as to why I don't use these SSO services.

I use 1Password and Spamex to maintain lists of DEAs and passwords. It's worked fine for years.


New fear unlocked; Being blocked from my github account.

Is there some easy way to mirror everything on GH to a NAS or something?


Search and you'll find various software doing it. If you just want a minimal shell thing for repos themselves, you can fetch a list from GH API for user X and clone them into destination `/home/X/repos` like so:

  $ curl -s https://api.github.com/users/X/repos?per_page=100
    | jq -r 'map([.name,.clone_url]|@tsv)|.[]'
    | xargs -n2 sh -c '[[ -d $0.git ]] || git clone --mirror $1 /home/X/repos/$0.git'
Then you can just put a cronjob to sync them like

  $ find /home/X/repos -maxdepth 1 -mindepth 1 -exec sh -c 'cd {} && git remote update' \;
Replace /users/X with /orgs/Y for an org. Pagination for >100 repos is left as an exercise to the reader.

Note that this will create mirror (bare) repos, so if you want to checkout you can e.g. git clone file:///home/users/X/repos/foo.git somewhere else.

Bonus: If you want to have these mirrors available remotely and self-hosted, the official git book lays out your options pretty nicely: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...

Easiest are probably git protocol (handled by git itself) or "Dumb HTTP" (just server these directories from a static HTTP server)


https://docs.github.com/en/repositories/archiving-a-github-r...

They say to use a marketplace app if you want an easy way. Or, you can get individual repo archives from their api: https://docs.github.com/en/rest/migrations/users?apiVersion=...


Local gitea can mirror repos


The source code itself is just Git, so you can 'git clone' it anywhere. Add that host to your origin(s) and just push it as you always do.

However, other data such as tickets, PR history, gists, etc. will be a lot harder to keep in sync with another service. GH allows exporting all the data, per GDPR, but importing it somewhere else will probably not be possible.


Exactly, it’s not the code part I see as hard. I don’t want to be locked out of my issues and wikis


Wikis on github are also git repositories which can be cloned.


I all but stopped signing in with SSO because I don't want to give out my GH e-mail address. Every service gets its own alias so when I get spam, I know who leaked it.


This is the weird bit where signing in with your GitHub account (or Google account, or some others) has a dual purpose: it can be used as a SSO/identity provider, and it can also be used to grant third-party sites access to your GitHub (or whatever) account.

You just really need to be vigilant[0], unfortunately. Personally I don't use "Sign in with X" ever[1], for two reasons: I don't want to accidentally grant too much access (as happened here), and I don't want my account on third-party sites being tied to my account on the identity provider (both for reasons of privacy, and because I don't want to be stuck in a situation where I lose access to the third-party site due to an issue with the identity provider). So when I see a site that doesn't allow me to create my own account with them, I move on.

If you do decide to use "Sign in with X", then you need to carefully read what permissions to your account the third-party site is requesting, and opt out of those you don't want to give. And if you can't opt out, you need to live with not having an account on the third-party site.

It is super messed up that GitHub has suspended your account for this; it makes no sense whatsoever. This will be a third reason to add to my list of reasons why I don't use "Sign in with X" anywhere.

[0] Which is not a general solution! Any fix for a problem that involves "everyone who uses this needs to pay better attention" is doomed to fail, since many people don't -- and won't -- pay attention, and even people who usually do pay attention can make mistakes.

[1] There are a few exceptions to this, unfortunately. It's incredibly annoying that crates.io only allows GitHub login, but it's something I can't realistically do without.


GitHub usually asks the user to provide permissions explicitly. When you go through the OAuth flow, GitHub will show what permissions the app require and you have to provide them explicitly.

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.


Tf illegitimate use do you have for solving captchas automatically? Play with abusive software you deal with the consequences.


What use would one have for using a robot to quickly and automatically solve a challenge that’s supposed to tell you are human and not a robot yet takes a human longer than a robot?

Well, probably sidestepping this utter idiocy.


You can be a legitimate user who wants to (legally, according to SCOTUS) scrape a site.

Or is it better to farm the manual labor out to Amazon Mechanical Turk / Filipinas / etc?


The same legitimate use you have for blocking ads: they're annoying.


I downloaded it just to see. Disabled it the same day because I didn't really understand if it was working. I never signed in with GitHub though...

I also forgot about it until this post. Thanks for saving me a potential headache OP. Just uninstalled it


https://github.com/dessant/buster/

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?


Maybe OP was just having a look, out of curiosity.

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.


Captchas are extremely annoying, and a pox on the web.


Who is nopecha.com?

I mean, like as a person, a company, an entity. Maybe that's a strange cultural thing, but is anyone fine with giving them money or access to data without ANY information at all about who is behind that site?

No contact information at all, just a link to a Discord server and nothing else.

That whole operation is just illegal under any law if you ask me.


Shady software does shady stuff. Very surprising.


> Shady software

As in Github and Micro$hit along with them


The real question for gh is why this is even available as a third party action via the oauth.

What possible legitimate reason could there be for this kind of action access?


GitHub asks users to type in the name of a project when deleting it. It seems they should ask users to type something in order to grant a third party access to a project. As someone who is working on a project that will require write access to repos, I support it.


It says something either about Github or HN that by now someone hasn't popped in the comments saying "Github employee here..."


People should contact the NopeCHA author over this. Refer to my previous comment about it: https://news.ycombinator.com/item?id=33769251


update: Looks like my account is back. I have not recieved any email confirmation but i just checked my github user and before it was 404 and now it is back. I was able to log in and all.

As i said, there has not been any email confirmation or notification from github regarding unbanning but this gives me a chance to get a copy of my repos.


I was wondering if you got it back :)

Good that its back!


for anyone wondering, the following is the exact text of the first response to my claim i got from github,

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


You didn't and Github should not have banned you. Wheras it is correct that you "could have avoided this by not granting unnecessary permissions" to the site which it then abused in your behalf, it is not your responsibility to ensure the site uses it's access credentials in a non ToS variolating way. This whole comment section is classic victim shaming. GitHub should be responsible to ensure all sites they grant oauth integration do follow the rules. If not, individual accounts should not have to live with the consequences of that.

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.


Follow up of this. The nopecha.com site does not have a Github sign in anymore (only Google at the moment). Looking through Github the organization nopecha seems to have been deleted and all its repositories return a 404 from Github, and seems to have been moved to a different organization recently created (and kept as public) Can't avoid feeling curious what has happened.


Probably a stupid question: Why can the user grant permission to third-party apps to star repos? What is the legitimate usage of this API?


Their API lets you do almost anything you can do on github. Its whole point is to allow people to write apps that do all the things you'd on github.

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/


It is a common problem for identity providers and their users that they do not have a strict definition of claims aside from a generic read/write.

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.


I'm guessing to allow people to make github browser apps, like the official desktop app.


> suddenly i am unable to log in to my github and the page just says "account suspended."

This happened to me the other day, out of nowhere. I have no idea why. At least OP managed to get a response out of their support, I've yet to get any sort of response after a couple weeks. All the other times I got an account banned from somewhere, I've always known why. In this case, I have literally no idea of what I did to get that kind of treatment

Maybe Github is purging accounts en masse or something? I have no clue

What I can say is this: Github/MS is highly unresponsive. The Copilot thing was highly disrespectful to users and shows how little regard MS has for the open source community

I self host gitea now and don't have any plans of using Github again for anything outside of school/work, where I don't have a choice (at least at the moment)

The service that Github offers has so many alternatives, there's literally no reason to stick around and play Micro$hit's head games (other than complacency)


Seems to me your first problem was trying to use a service like Nopecha in the first place. That immediately strikes me as a great way to get banned from whatever service you were planning on using it on. The fact that GitHub banned your account for Nopecha's actions is just a sideshow to that fact, in my opinion.


Part of the problem here is our cavalier use of "Sign in with <this other company>".

We software engineers can practice better, both in how we expose our development and production accounts and systems, and in what we encourage less-knowledgeable users to do.

(Maybe widespread hardware keys will make this problem go away before individual diligence does. Then we just have to tackle resisting the urge to copy&paste `workstation$ curl -sSL https://randomwebsite.weonlyjustlearnedof/something-shiny | sh`.)


> Then we just have to tackle resisting the urge to copy&paste `workstation$ curl -sSL https://randomwebsite.weonlyjustlearnedof/something-shiny | sh`.

The argument that goes around about "don't pipe curl into sh" is: "the website can detect that it's being piped into `sh`, and then run malicious commands which you won't know about".

I've never seen a compelling reply that explained why `curl ... > tmp.sh && sh tmp.sh` is practically any safer. -- "don't curl into sh" is significantly more specific than "don't run random scripts" or "always use a package manager".

Rather, even if I see that the script is running `wget https://example.com/program.bin`, it seems more practical that `program.bin` could itself run malicious commands at a later date.


The main problem is all the casual arbitrary code execution from unvetted sources -- both doing it, and encouraging it.


"I just realized that GitHub accounts can be suspended!"

I was banned by github. https://github.com/ransom1538. All work lost. All stars lost. I created a weekend project to view and see other github projects - and pushed users to start projects they liked. I shouldn't have had that many beers! lol. My userbase was exploding after 24 hours. Their security team just ended my profile then ghosted me. My profile links on open source projects just return a 404.

My advice. Be careful!! with a github account you spent years building on and respect your master: github.


Ouch.

If you're on Github, go to "https://github.com/settings/applications" and you can see, and revoke, any OAuth accesses.

I just discovered that "Improbable" (the game engine backend company) had too much access, obtained because I once signed up to look at their SDK. I revoked that. (They used to be legit, but then they got involved with Yuga Labs, the Bored Ape crypto people, so trusting them is now questionable.)


I once signed up for Runtastic with my Google account. It then wanted access to my personal data which I denied. After that I kept getting marketing emails from them. The only way to unsubscribe was to delete my account. I tried to delete my account but their workflow required me to authorise them to read my Google data. I still didn’t want them to have access. I tried contacting support, their office, via social media. Nothing. No response. The lesson learned for me, never ever use SSO again.


You can blacklist that sender.


This is an issue with anyone who has your email, not really SSO. Those emails would be illegal in Canada, the business has 10 days to stop sending them after you contact them requesting to unsubscribe.


Yeah Australia as well, a bunch of big companies got in trouble a few years back after emailing after unsubscribe from the ACCC. Multi-million fines.

I like that the ACCC has teeth. Keeps Australian companies on their toes.


Sign in with Apple gives the service a spoofed e-mail address it creates (you can choose to use your real one instead).

Trouble is that if you need to migrate from Apple, then there's no way to recover the account.


On the flip side things like Etsy digital download purchases then don't get delivered and the cause a support headache for sellers.


In this case Apple redirects the mail to you, but you can stop it anytime and then the other party can no longer reach you.

For sure, there's a lot of support headache related to OAuth in general.


Pull the GDPR card.

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 )


I actually did try that! No reply from the Austrian authorities. No reply from any email at Runtastic.


You fell for a phishing site it seems.


I don’t understand why GitHub would be upset with you; seems pretty clear they should be taking action against the app that you were using, and that you didn’t want this either.


Scary. Gotta be super careful about granting scopes. I use signin with google all the time - just to avoid creating new passwords. Imagine if I accidentally grant the scope for a random site to read all emails. I hope that isn't even possible but I imagine it is - it likely would be fairly nonchalantly displayed in the list of scopes. I'm a developer who has implemented OIDC flows so in theory I should know better. What about everyone else?


Google requires public oauth apps to go through a registration and review process. And requesting special privileged/sensitive scopes (like access to read email) causes increased scrutiny.

I believe users are also warned about apps with sensitive access on an ongoing basis.

Certainly not foolproof but hopefully helps assuage your greatest fears.


Good to know.


It’s really worth reading Privacy policies: https://nopecha.com/privacy

We may sell and may have sold in the last twelve (12) months the following categories of personal information:

Category A: Identifiers

Category B: Personal information categories listed in the California Customer Records statute (Cal. Civ. Code § 1798.80(e))

Category D: Commercial information

Category F: Internet or other similar network activity


Yeah this is exactly the problem with federated login.

One misstep your whole account gets canceled. Even other services you didn't violate but still need to login.


maybe, just maybe, having friction in logging into web services is a good thing.

i, for one, am not a fan of the tendency for every web service to require an account in the first place. making it easier for people to log in to these unnecessary accounts is helpful in discouraging this practice, as it will decrease utilization of services which require such superfluous accounts.


Ideally, schools should teach people how these access grant dialogs work and that you should be careful who you give access to what social media presence.

This is no different than somebody "logging in" via facebook and messaging everyone 3 minutes later that they lost their wallet and need $500 urgently.

Minus points to GitHub for going after the user and not the malicious app.


how about this. https://nopecha.com/ their website still has "sign in with google". how about someone uses a throwaway account and does the login workflow and see what happens? i dont have one so someone can see if they are doing some shady stuff there as well


Google is known to associate accounts used from the same place (ip, device) and bulk ban them so that's not safe.


That's terrible. I avoid SSO systems entirely for a whole bunch of reasons. I'll add this to my list.


Star farming is sad. Why would you ban for that? Sounds like their systems suck, and their patch is to ban users.


So now you can’t push or manage repos on your account? Since GitHub wants you to use one handle for everything, this is a new vector to screw over large open source projects or make it so someone is unable to work at their job.

Hope you can get access back soon!


If you are looking for captcha solving solutions you are likely up to no good.


So? Is the problem invald or resolved because the OP is "likely up to no good"?


It is for people that want to bypass account creation protections. So if I was github I would flag the account too.

Bypassing captcha is likely against terms of service or ar least it should be (most of them have a button saying "I am human")


I recently had a user (probably a robot) star all of my public repos. I never thought it could be a real user who didn't understand the repercussions of giving login to github.com.


Could it be that this wasn’t the official “Sign in with GitHub”, but a phishing version presented by NopCHA, so that they got your GitHub credentials?


Note to self: Another good reason to not use Popular SSO services, and instead continue creating a manual account for all.


gitter also asked something like this. like it wants to access my public repo. i took some time, but at the end i gave it. i thought it was a normal flow. after this, idk if that's normal. from now on i am not going to use sso esp github one.


Find and sue "nopecha". At least in Small Claims Court. Or talk to a lawyer. This might be good for substantial damages.

They're trying to hide, but they can't, not really, because they're a business that accepts payments. "nopecha" has a Chrome plug-in and domain registration with Google, along with a PayPal account. They can be found, but it may take a subpoena to Google or PayPal.[1]

"Nopecha" indicates on their site that they comply with California CCPA requests. Make one, and ask for your info and what they've done with it. That should yield more information. If they fail to reply within the 45 day time limit, file a complaint with the attorney general's office.[2]

[1] https://support.google.com/faqs/answer/6151275?hl=en

[2] https://www.oag.ca.gov/privacy/ccpa/enforcement


It seems they removed Github option. I only see signing up via Google.


M$ strike again!


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


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.


Yeah, OP edited their post to clarify. I do agree.


Trust is intentional, not mechanical.


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.


> Do you realize that granting someone access to "read/write your repos" can have more severe consequences than what happened here?

More severe, perhaps, but not obviously including what happened here: starring other people’s repos is neither reading nor writing to your repos.


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.


> That doesn't make it the victim's fault if a bad actor took advantage of them.

Correct. Did I state or imply in any way that it was the victim's fault?


No, I didn't mean to imply that you're doing that.


Useless question


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.


This was extremely helpful to me:

OAuth 2.0 and OpenID Connect (in plain English) 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.


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.


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


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


Nested is also good.

Permission A implies B & C allows you to scale to a more granular system than just listing fifty separate micro permissions with no grouping.


Good idea.


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.


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.

[1] https://arstechnica.com/information-technology/2015/08/mozil...


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


Service providers provide APIs.

Devs build apps that use APIs.

Users install apps that use APIs.

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.

But you caused them hours and hours of pain.

See also https://xkcd.com/1172/


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.


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


Great idea! will keep in mind.


Please dont. Your extension will probably get more people banned when they star 1200 repos.


>> the more API coverage a platform can provide the better

The more attack surface, the better?


Upvoted to counter others' apparent misunderstanding of your comment.

I absolutely agree -- starring repos should be a human act, not an automated one. No need for API exposure of this particular action.


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.


There are advantages to opening up all of the functionality of the web front-end as an API to allow alternative front-ends.


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.


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


[flagged]


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.


FWIW they are improving in other areas https://github.blog/2022-10-18-introducing-fine-grained-pers...


Also as annoying as they are very much one of the reasons why they're pushing for Github Apps.


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


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


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


[flagged]


> There's a genre here on HN of someone getting banned for doing actually bannable things, and then their "Ask HN" rises to the front page for some reason

I visit HN multiple times a day, and in my experience, this sort of thing is very rare. I see plenty of posts about seemingly-unjustified bans, though, like this one.

At any rate, not sure why you're being so argumentative here. It was pretty obvious to me what OP was trying to say, and it sounds like you're just deliberately refusing to understand so you have something to argue about.


> not sure why you're being so argumentative here

If someone were repetitively replying with negativity to posts they disagreed with, I might call them "argumentative", especially if their replies were dismissive and snarky. Was I doing something like that here? I don't personally see it, but I'm open to criticism.

There are people who will label any opinion they disagree with as "argumentative", however. That's not what's going on here, is it?


Spending an entire comment attempting to rebut what is clearly just misinterpretations of someone writing in a conversational tone is the most Hacker News thing I've seen all week.


Sign into nopecha.com with your Github login and let us know how it goes. I don't think the OP is BS'ing us but I'm happy to let you conduct your investigation.


The OP said they automatically starred "repos". Not a repo. Seems pretty clear to me.


> i logged in, clicked through a bunch of pages because its the same drill everytime.

Nah, the list of permissions you were granting were right there. This is on you.


I'm a big critic of MS and Github is just-another-acquisition to them to monetize users. To that end, the permission to allow a third party to engage in bannable behavior, using someone else's account, is promoting bad actors. MS has lots of experience with this and it will likely be addressed (prohibited outright) in the future. Too late for some.


Any site you grant this permission to could abuse it. The abuse is on the abuser, not the person granting permissions. Allowing the abusive behavior to happen at all - authorized or not - is on Github.


You can't put all the blame on the user, when GitHub makes the page where you just log in to a third party and where you grant them permissions look so similar.


Sorry, but you gave them permission to do it.

Why are people blaming GitHub?

Making it easy and frictionless for developers to build GitHub integrations is what a good developer platform should do.

You've learned a lesson to not just blindly click through an application requesting permissions to your account.


This


GitHub did the right thing. While GitHub might have had better ways to deal with this kind of thing technically, those controls are rather expensive to implement for novel scam use cases if they weren’t in place prior to the abuse.

The blast radius of their strategy is desirable since it will also remove the accounts of all participants, willing or not. It doesn’t really matter if each individual zombie is a willing participant in the horde, you’re still going to indiscriminately fire on all of them.

Participants will often claim to be victims, and while that’s probably not happening here, it’s way more cost effective to ban everything touching the scam. Tons of free users complaining essentially doesn’t matter since these users were already not generating value. Their potential loss is regrettable, but acceptable.

Genuine victims will eventually be able to get their accounts restored via support after they’ve contained the problem, and accounts in on the scam won’t bother. If they were a paying customer I’m sure they’d have ways to get this resolved.

The en masse bans weren’t utterly necessary, but they were a faster and more effective resolution to the problem from GitHub’s perspective.

If the suggestion is “do something really expensive and considerate of the scammers” the correct answer is always no. Scams create enormous costs, asking them to increase the cleanup costs is the wrong approach.


Genuine victims will eventually be able to get their accounts restored via support after they’ve contained the problem,

This part didn't actually happen though. They are still banned.


That is by far the least important part of this decision


As a deterrent for abuse, it makes sense to suspend lots of accounts up front, pending investigation, and then let them back selectively as they are reviewed slowly. But if you're not doing the review, it makes no sense to ban lots of users while not addressing the root cause. That's just a way to run out of users.


I don't think that github is at risk of "running out of users". If the cost of doing the review is greater than the cost of losing those wrongly banned users, it makes literally zero sense to do the review


> GitHub did the right thing.

If that was the right thing, then that's an excellent reason to avoid using that facility ever.


Couldn't have said it better myself. This is exactly the right move from GitHub. I don't think they should ever reinstate the accounts though




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: