5 ms·
> 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 itse
by screamingninja 4y ago
> 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.
- deleted 4y ago[deleted]
- aframe 4y agoI 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.
- eloff 4y agoIt'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.
- screamingninja 4y ago> 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?
- deleted 4y ago[deleted]
- dragonwriter 4y ago> 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.
- weego 4y agoEveryone 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.
- jolux 4y agoIf 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.
- sowbug 4y agoTrust is intentional, not mechanical.
- lolinder 4y agoI 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.
- jolux 4y agoYeah, OP edited their post to clarify. I do agree.
- AnotherGoodName 4y agoIt'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.
- mgkimsal 4y ago> 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).
- realmod 4y agoFacebook 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.
- eproxus 4y agoIt’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.
- bscphil 4y agoUnless 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.