Hacker News Reader

I read through that thread and it really is baffling. It seems more like a legal CYA wording than a technical/security wording. Really poorly handled on githubs side, either remove the wording or do a better job explaining the technical distinction.

Like it’s super weird that they felt the need to be like “if you give someone your email address they might put together that you likely know the password to access your email.”

They've been developing the system, have used it extensively, and have internalized all the details and quirks. They are just as confused at why that question is a question as OP was.

Well thats part of my confusion. The initial response by them starts with

> We understand that this is poorly and confusingly worded for this kind of scenario. We’ve given this feedback to the team that is responsible for how this dialog is designed. We’ll be working with them to improve it to hopefully make it more clear and understandable as to what exactly is being requested so that you can be more confident in the decision you’re being asked to make.

Then they proceed to insist its fine as is.

The fix seems simple. Just rework the layout so its in line with what was suggested in the thread (https://github.community/t/why-does-this-forum-need-permissi...). No one even acknowledges this persons suggestion, even though it seems to be precisely what Github is trying to communicate.

I find auth stuff to be a huge ball of frustration for everybody. It strikes me as if the people designing auth mechanisms and APIs and people designing usable UX are different species with different goals and value systems, and this leaks out all the way up to the user.

In many ways this is just growing pains. For years people willingly handed their name/password to third party apps and sites, and this granted those sites full auth. This was too permissive, but extremely easy for people to understand, even for non-techies.

With things like OAuth, OS level capabilities in iOS and Android, etc., we've now got to break down these "scopes" into slices that are flexible enough to write useful software against without being too broad, too revealing of the underling software architecture (brittle), and too confusing for the user. I think this is actually a really hard problem.

Having worked as an Auth engineer for 5 years I can reaffirm not just does auth suck everyone doing auth in any capacity sucks.

The analogy that I like to use that illustrates the problem is that Auth is like working with the DMV.

No one wants to do it, everyone wants to get it over with as quickly as possible, it has a vast complicated structure that people don't want to know about or need to know about, it is usually painful, it doesn't actually give you any benefit but you have to do it anyway no matter who you are.

Thus everyone is trying to hammer out the minimum they can to pass the minimum requirements and then try to forget it exists at all.

Also, if you just ditch the whole enterprise, you end up with even worse problems.

I've been doing some auth development. Auth is hard because it's a deeply human problem, and therefore messy. Human beings share, cooperate cross-boundaries, self-organise and divide in all sorts of groups and hierarchies. There are policies and rules, and then there are unwritten rules and exceptions. On top of that, the planning phase of projects has lots of graphs and arrows of what needs to go where, but rarely includes the auth boundaries and permissions. It's an ungrateful job because basically you're throwing hurdles and setting limitations where everything would work by default in the utopia of an open internet (or intranet).

Today I tried logging on Circle CI for the first time via github. The login stuff asked, among other things, for read/write access on all repositories, public or private. I didn't go through.

I was later told that's not actually what happens in practice, but that permission prompt sure is scary.

Somewhat related auth scoping frustration: the v4 GraphQL API documentation doesn’t say what field/query/mutation need what scope, so you’re left guessing, or cross-referencing a related endpoint in API v3 documentation, or trial and error.

Reply on news.ycombinator.com