|
|
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.
|
|
|
|
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.)
|
|
|
|
|
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.
|
|
|
|
> 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
Well, it is PITA to implement so I'm not surprised really...
|
|
|
|
Giving a website access to star repos through the API for my convenience is not anything I should be banned over though.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
> 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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
|
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?
|
|
|
|
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 [email protected], feel free to log them into your site as [email protected]”). 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.
|
|
|
|
> 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
>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
|
|
|
|
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.
|
|
|
|
> ..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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.)
|
|
|
|
Laws are different in the world. I'm pretty sure in Germany the account would have to be restored.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
They know people don't always update their profiles and use throwaway accounts. They nudge you to provide actual data.
|
|
|
|
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.
|
|
|
|
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. :-)
|
|
|
|
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 ?
|
|
|
|
|
|
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)
|
|
|
|
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.
|
|
|
|
Yep. Single reason we don’t use them anymore. Great service, but we don’t have corporate MS, GitHub or Google accounts.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Head scale FTW? I mea n you need to self host it and deal with all that... But it is your network...
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
> 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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
> 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
|
|
|
|
I believe it goes against the ToS for Microsoft GitHub to have more than one account per human.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
You don't have to be an Elite Hacker to read a permissions list and be informed about what you're consenting to.
|
|
|
|
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"
|
|
|
|
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?
|
|
|
|
Some do, some don't. That said, I haven't said a option to reject scopes on any of the big oauth providers
|
|
|
|
"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.
|
|
|
|
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
|
|
|
|
And the day the "master" account gets suspended or compromised you lose access to 10 other accounts. No thanks.
|
|
|
|
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.
|
|
|
|
> 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!
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
It seems like GitHub gave them the boot as well: https://github.com/NopeCHA/NopeCHAIs 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.
|
|
|
|
|
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. :)
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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)
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
|
I'm guessing to allow people to make github browser apps, like the official desktop app.
|
|
|
|
Tf illegitimate use do you have for solving captchas automatically? Play with abusive software you deal with the consequences.
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
Captchas are extremely annoying, and a pox on the web.
|
|
|
|
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.
|
|
|
|
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?
|
|
|
|
Shady software does shady stuff. Very surprising.
|
|
|
|
> 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.
|
|
|
|
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.
|
|
|
|
"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.
|
|
|
|
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.
|
|
