Comment by vintermann | Hacker News Reader

Comment by vintermann | Hacker News Reader

Parent Full thread

As I said, before the app even can ask for a scope, github has to give that app permission to ask for a scope.

I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them.

And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.

> And "caveat emptor" is not the threat model you can get away with on the web.

Caveat emptor is not a threat model, it is a risk mitigation.

It is arguably the only mitigation directly in the hands of the consumer.

And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation.

> it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials

thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated

edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”

When you run a service on the web, it's not enough to protect yourself. You must protect your users to the best of your ability. Threats against your users must be part of your threat model.

If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

> When you run a service on the web, it's not enough to protect yourself

Nothing but agreement there.

Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case?

> And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

I had to look up that apparent reference to Harry Potter, but I disagree.

Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.

Github is not the Norwegian government though. Github is not a gateway to public bureaucracy or to public services. It provides repository hosting, project management, and integration with build tools and similar services. Fostering a wide ecosystem is a core part of their business strategy, and as such applications are only validated superficially. Also, it operates at a scale that makes such validation infeasible.

Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully.

Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.

> Also, it operates at a scale that makes such validation infeasible.

It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners.

It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.

GitHub is Microsoft. And as a provider of developer tools, weird to see such apologism for their inability to structure oauth scopes correctly and provide effective unambiguous UX for user consent.

Let alone banning the user instead of the client app...

Reply on news.ycombinator.com