5 ms·

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 organi

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.

RulerOf 4y ago
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.
- filmgirlcw 4y ago
  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.
  - vlovich123 4y ago
    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)
  - RulerOf 4y ago
    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 https://githubnext.com was enough validation for me. Can't wait for Voice Copilot :) 1: https://github.com/githubnext https://github.com/githubnext
  - rjzzleep 4y ago
    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.
  - Kye 4y ago
    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.
- eitland 4y ago
  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.
- dheera 4y ago
  Time to register a rogue Github Pages site at next.github.com?
  - filmgirlcw 4y ago
    Next.GitHub.com redirects to GitHubnext.com fwiw.
  - tcbyrd 4y ago
    Pages sites no longer work on github.com https://github.blog/changelog/2021-01-29-github-pages-will-stop-redirecting-pages-sites-from-github-com-after-april-15-2021/ https://github.blog/changelog/2021-01-29-github-pages-will-s...
madeofpalk 4y ago
I raised this concern before about how unclear this is and the concern was pretty much dismissed https://news.ycombinator.com/item?id=33539150 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.
- BubbleRings 4y ago
  This becoming the top thread here might get their attention. You have a very good point.
- basch 4y ago
  >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.
  - cyrusatjam 4y ago
    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
- filmgirlcw 4y ago
  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.
- xp84 4y ago
  > 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.
idan 4y ago
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.
someguyformdn 4y ago
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.```
Borgz 4y ago
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 https://news.ycombinator.com/item?id=33917962 [2]: https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps https://docs.github.com/en/developers/apps/building-oauth-ap... [3]: https://news.ycombinator.com/item?id=33919481 https://news.ycombinator.com/item?id=33919481 [4]: https://github.com/community/community/discussions/37117 https://github.com/community/community/discussions/37117 [5]: https://github.com/cirruslabs/cirrus-ci-docs/issues/751 https://github.com/cirruslabs/cirrus-ci-docs/issues/751

RulerOf 4y ago

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.

filmgirlcw 4y ago
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.
- vlovich123 4y ago
  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)
- RulerOf 4y ago
  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 https://githubnext.com was enough validation for me. Can't wait for Voice Copilot :) 1: https://github.com/githubnext https://github.com/githubnext
- rjzzleep 4y ago
  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.
- Kye 4y ago
  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.
eitland 4y ago
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.
dheera 4y ago
Time to register a rogue Github Pages site at next.github.com?
- filmgirlcw 4y ago
  Next.GitHub.com redirects to GitHubnext.com fwiw.
- tcbyrd 4y ago
  Pages sites no longer work on github.com https://github.blog/changelog/2021-01-29-github-pages-will-stop-redirecting-pages-sites-from-github-com-after-april-15-2021/ https://github.blog/changelog/2021-01-29-github-pages-will-s...

madeofpalk 4y ago

I raised this concern before about how unclear this is and the concern was pretty much dismissed https://news.ycombinator.com/item?id=33539150 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.

BubbleRings 4y ago
This becoming the top thread here might get their attention. You have a very good point.
basch 4y ago
>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.
- cyrusatjam 4y ago
  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
filmgirlcw 4y ago
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.
xp84 4y ago
> 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.

idan 4y ago

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.

someguyformdn 4y ago

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.```

Borgz 4y ago

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 https://news.ycombinator.com/item?id=33917962 [2]: https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps https://docs.github.com/en/developers/apps/building-oauth-ap... [3]: https://news.ycombinator.com/item?id=33919481 https://news.ycombinator.com/item?id=33919481 [4]: https://github.com/community/community/discussions/37117 https://github.com/community/community/discussions/37117 [5]: https://github.com/cirruslabs/cirrus-ci-docs/issues/751 https://github.com/cirruslabs/cirrus-ci-docs/issues/751