Hacker News Reader

Comment by nigamanth | Hacker News Reader

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.

View on HN

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.

1. If those permissions aren't reasonable to ever grant, then they shouldn't be available.

2. A user has no way of controlling which permissions are abused.

If you get scammed, you get scammed, but the response from GH here isn't warranted. They're adding damage on top of whatever the user already got themselves into with allowing the malicious developer access.

It is trivial to determine whether an action was taken via a direct user interaction (using an access token granted by GH.com, by clicking a thing on their website) vs a 3rd party (who presumably had to go through a sign up to even use "Sign in with GH" and has a dedicated application ID). Instead, GH is attributing the actions of a 3rd party to the user, which isn't appropriate. They're essentially accusing the malicious developers' victims of being "in on it".

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?

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.

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.

read is okay, write allows these abuses, no?

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

I guess the logic is "you are responsible for vetting who you give permissions to" but yeah this seems a bit extreme, I would not punish the users in this case either.

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 ?

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.

Reply on news.ycombinator.com