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?
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?
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.
https://github.blog/2022-10-18-introducing-fine-grained-pers...
Accessibility.
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.
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.
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.
"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!
Imagine if you could only pick Gmail or Outlook in the form for email !
If I am creating a new service today I will probably won't bother and just offer social logins.
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
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.
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)
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.
> 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
I've managed to. It does mean that some services are unavailable to me, but that's life.
(I haven't encountered the situation myself, didn't try it)
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.
+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.
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.
FB, Twit, Goog, need to separate oauth login from the rest of their service.
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
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.
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?
In case you missed it: https://news.ycombinator.com/item?id=33906591
> 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.
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!
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"
If anything, Github already wasted time by targeted the user into a victim, rather than the original source of the API call.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Why on earth would anyone use SSO? Are we that lazy?
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
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
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.