Have you ever clicked "Sign in with GitHub" on a website and thought nothing of it? It seems like a quick, easy way to get into a new service. But what if that simple click could get your entire GitHub account suspended? That's exactly what happened to many users who tried out a new captcha service.

This story is a wild ride about how a developer's clever, or perhaps sneaky, use of a common login feature caused a lot of trouble for people who just wanted to use a website. It highlights a big problem with how these "sign in with" buttons work, and the potential dangers hiding in plain sight.

The Website Promising Speed

A website called nopecha.com popped up, claiming it could solve text captchas in just one second. This was a big deal because captchas are usually annoying and slow. Many people, including developers, were interested in trying it out to see if it really worked.

At first, the only way to log in was through Google. But then, a "Sign in with GitHub" option appeared. This made it accessible to a whole new group of users who preferred using their GitHub accounts.

A Hidden Action: Star Farming

When users clicked "Sign in with GitHub," they went through the usual steps to connect their accounts. They didn't realize that by doing this, they were also giving the website permission to do something else. This hidden action was to automatically "star" the website's repositories on GitHub.

For those unfamiliar, "starring" a repository on GitHub is like bookmarking or liking a project. It shows support and helps make a project more visible. The website was using the "sign in with" feature to artificially boost the popularity of its own projects. Many users reported seeing around 500 stars added this way.

The Unexpected Ban

Soon after logging in, users started facing a serious problem. They found themselves locked out of their GitHub accounts. The page would simply display a message: "account suspended."

This was a shocking and confusing experience. People who had only used the website once, through the "Sign in with GitHub" button, were suddenly banned from GitHub, a platform many rely on for their work and projects. The connection between a simple login and a full account ban was not clear at all.

Reaching Out for Answers

Users who were banned immediately contacted the website's support. The response they received was frustrating and unhelpful. They were told that their ban would remain because they had engaged in "improper behavior of stars farming."

This response didn't make sense to the users. They argued that they hadn't intentionally farmed stars. They had simply used the "Sign in with GitHub" option to log in. There was no clear warning on the website about this "stars farming" practice.

The Core Problem:

Abuse of Trust

This situation raised a huge question: How could GitHub allow a developer to use its "Sign in with" feature in a way that could later be considered abusive? And why were the users, not the developer, the ones getting punished?

The "Sign in with" buttons are meant to make logging into websites easier and more secure. They use a system called OAuth, which allows one application to access another application's data without needing the user's password. However, in this case, the system was exploited.

The developer used the "Sign in with" button to create a situation where they could later consider it abusive, but then go ahead and ban all the victims also?

This highlights a critical flaw. Users expect these login buttons to provide simple access, not to be a gateway for hidden actions that could lead to bans.

GitHub's

Response and User Confusion

When users appealed to GitHub, they received a response explaining the ban:

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

Users felt this was unfair. They argued that they didn't knowingly engage in star farming. If they gave permission, it was part of the login process, and they weren't aware that this permission could lead to a ban. Some even tried to undo the actions, like unstarring repositories, but it was too late.

Key Issues Raised by the Incident

This incident brought several important points to light about how these integrated login systems work:

• *Permission Scope:

• Developers can request broad permissions through the login process. Users might agree to these permissions without fully understanding the scope or potential consequences.

• *Automated Actions:

• Apps can perform actions, like starring or forking, automatically after a user logs in. Users may not be aware of these automated actions or their implications.

• *Lack of Warning:

• There was no explicit warning to users that agreeing to connect their GitHub account would also involve actions that could violate GitHub's terms of service.

• *Punishing Victims:

• Instead of solely holding the developer accountable, GitHub banned the users who were essentially tricked into the action.

• *Developer Accountability:

• The primary developer who designed this system faced fewer immediate consequences compared to the hundreds of users they affected.

What Does This Mean for "Sign In With" Buttons?

If this becomes a common practice, it could erode trust in all "Sign in with" buttons. People might become hesitant to use them, fearing that a single click could jeopardize their accounts on other platforms.

The expectation is that these buttons offer a smooth and secure way to access services. When they are used to trick users into actions that lead to bans, the entire system breaks down. It raises questions about who is responsible when a developer abuses the trust placed in these integration tools.

The

Danger of Hidden Permissions

Users often click through permission requests quickly during the login process. They trust that the service is legitimate and that the permissions requested are necessary for basic functionality. This incident shows that developers can hide potentially ban-worthy actions within the standard login flow.

It's not just about the user's intent. If an app uses a user's account to perform actions that violate a platform's terms, even if the user wasn't fully aware, the consequences can be severe. The automated nature of these actions makes it even harder for users to defend themselves.

Looking Ahead: Protecting Users

This situation calls for better safeguards on platforms like GitHub. Here are some potential improvements:

• *Clearer Permission Explanations:

• When a user connects their account, the platform should clearly explain what permissions are being granted and what actions the app can perform.

• *Stricter Developer Vetting:

• Platforms need more robust processes to check how developers are using integrated login features and permissions.

• *User Control Over Actions:

• Users should have more granular control over specific actions an app can take, not just a blanket "allow access."

• *Grace Periods and Warnings:

• Instead of immediate bans, platforms could implement warning systems or temporary restrictions for suspicious activity, giving users a chance to correct it.

This story serves as a stark reminder that convenience can sometimes come with hidden risks. Always be mindful of the permissions you grant when using "Sign in with" features, as the consequences can extend far beyond the website you're trying to access.