Hacker News Reader

Comment by screamingninja | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com