Hacker News Reader

Comment by filmgirlcw | Hacker News Reader

It’s officially from GitHub. There is some weird language (that I’ll absolutely pass feedback on to the team), I think because GitHub Next is a different organization from GitHub proper, but I can assure you, this is an official GitHub app.

But I totally agree that this isn’t a great/clear message about where this is from.

View on HN

I raised this concern before about how unclear this is and the concern was pretty much dismissed https://news.ycombinator.com/item?id=33539150

"Techies" often lament about how silly users are about falling for phishing tricks, but then they also routinely make it so difficult to determine what's legit from what's fake.

Totally agree. I did the same double-take with some stuff at Universe and I work here. As Idan said back then, there are lots of reasons that we want Next to be separate from GitHub proper. But you’re absolutely correct that we should make it more clear that anything from Next is not a rogue org and also part of GitHub.

Thanks for the feedback.

>routinely make it so difficult to determine what's legit from what's fake.

Like the amount of times on my phone where I get prompted for a username and password different from the app im in (to make some kind of connection) but then suppress the url from visibility. An astoundingly poor design choice that has proliferated into every single variant of that interface design flow.

Not to mention, the app you're in can inject JS into the page it renders. Best practice is to open in your default browser and then allow the deeplink in the callback_uri to return you back to the original app

> make it so difficult to determine what's legit from what's fake.

So true. I still think the DNS was one of the only chances to grant, and teach, the ability to confidently make trust decisions in the general population. IDN attacks notwithstanding, it's hard to beat an inspectable string that contains its own trust chain, compared to "app names" that can often be set to the hacker's own choice. Sadly, antipatterns seem more common than useful patterns.

(Antipatterns like using a domain like "talktotacobell . com" (don't visit that) as the site to complete a receipt survey. Or every public school district or even school having a random .com or .org.)

People decided that end users would find an address like xhs.xsd.ed.ca.gov too complicated, yet people found 10-digit completely meaningless telephone numbers perfectly fine for decades.

This becoming the top thread here might get their attention. You have a very good point.

The domain name on that authorization prompt was more than enough to get me to decline.

I wouldn't have hesitated at all if it were at next.github.com.

Totally get it.

I’ve passed feedback on to the team so (hopefully) the CLI app will be be clearly from GitHub soon (we need to transfer it to the regular GitHub org and then there hopefully won’t be any confusion). GitHub Next exists in a different org from GitHub proper for lots of reasons, but we should definitely make it more clear that those experiments are still from GitHub.

To me the auth flow looks wrong. The CLI oauth would get act on your behalf, but the website to apply for access should not under any circumstance do that.

Maybe it's just copy and pasted from somewhere, but it looks wrong to me regardless.

FYI, after digging down a few links from there and winding up at the GitHub Next org page[1], seeing the verified email next@github.com and the official site link to https://githubnext.com was enough validation for me.

Can't wait for Voice Copilot :)

1: https://github.com/githubnext

Doing it under a liberated domain under GitHub.com sounds like it would work (still a separate org but it’s a signal that this is from main GitHub)

It seems like one organization being able to specify a relationship with another, possibly with the ability to set a list of approved permissions, would solve this.

The amount of companies, including serious banks, that doesn't understand this is mind blowing.

Just the other day I had to verify with a Norwegian bank that the KYC form (which IMNSHO was utter nonsense as usual) that they linked to was actually them and not someone who had gained access to sneak in a link. Because the domain was something completely different.

Time to register a rogue Github Pages site at next.github.com?

Pages sites no longer work on github.com

https://github.blog/changelog/2021-01-29-github-pages-will-s...

Next.GitHub.com redirects to GitHubnext.com fwiw.

Correct! We know this is a terribly confusing thing. Hopefully by the next big launch we can work out a way to have GitHub Next things not bear the "not owned or operated" thing.

Did you actually pay for or license MDN for the database that you are building off of and selling your "product"? YOU ARE A BUNCH OF THIEVES. People haave been working on contributing to the MDN brandand the docs since at least 1995.

```We’re starting with documentation for React, Azure Docs, and MDN, so we can learn and iterate quickly with the developers and users of these projects.```

Unfortunately, I think this is another indication of a lack of understanding by GitHub of how their OAuth/GitHub App systems are expected to function by end users.

I'm reminded of this incident [1] from a few months ago. Allegedly, a malicious actor abused GitHub's poorly designed OAuth permissions to obtain up to 500 stars from developers without their consent, all thanks to a "sign in with GitHub" button and a flawed consent screen that did not communicate what the victims were consenting to. Even worse, GitHub allegedly decided to suspend at least one victim's account.

We're left with a number of questions:

1. Why does GitHub give third-party apps permission to star repos when it is apparently against the terms of service to automate such an action?

2. Why does GitHub lump this permission in with public_repo, a scope that grants read and write access to all public repositories? [2]

3. Why does the consent UI for this scope display simply as

    Repositories
    Public repositories

and not even mention that this grants write access unless the user clicks on it? [3] (it also doesn't mention that it gives permission to star repos)

4. Why does GitHub punish victims with account suspension for being tricked into giving consent to malicious apps?

It is good that GitHub is taking some steps to improve account security, such as fine-grained personal access tokens and mandatory 2FA. But these improvements do not seem to be extending to the OAuth system. The GitHub App system, while better in that it has granular permissions, is also flawed with its mysterious "act on your behalf" consent UI. [4] [5]

[1]: https://news.ycombinator.com/item?id=33917962

[2]: https://docs.github.com/en/developers/apps/building-oauth-ap...

[3]: https://news.ycombinator.com/item?id=33919481

[4]: https://github.com/community/community/discussions/37117

[5]: https://github.com/cirruslabs/cirrus-ci-docs/issues/751

Reply on news.ycombinator.com