GitHub ユーザー名が @reset の方、本当に申し訳ありません

• GitHub の Issue でレジスタを 0 に設定する議論が @reset ユーザーへのメンションとして処理され、関係のない人にメール通知が繰り返し送られた
• 原因は、@reset のような文字列を GitHub が 自動メンションとして解釈し、技術的文脈の単語が実際のユーザー呼び出しにつながってしまう点にある
• @boxed、@stack、@else、@font、@acme のように、技術用語やプレースホルダーと重なる短いハンドルも、同様の通知被害に遭っている
• バッククォートを使う方法や @[any_text] を避ける方法が提案されたが、コミットメッセージや PR・Issue コメントでも通知が発生し得るため、完全な回避は難しい
• @reset ユーザーは Hacker News のコメントで、これを笑って楽しんでいると知られているが、短く一般的なハンドルは開発ツールの自動メンション機能と衝突しやすい

---

@reset メンション事故

• Adrian Sampson は GitHub で レジスタを 0 に設定する話をしていた際、@reset ユーザーにメール通知を送ってしまう状況になったことを謝罪した
• 関連する GitHub Issue コメントは cucapra/calyx リポジトリの Issue コメントであり、@reset が GitHub ユーザー名として解釈されたことが問題の中心である
• “setting registers to zero” という技術的文脈で reset という単語が自然に登場し、そこに @ が付いたことで 実在ユーザーへのメンションになった

短いハンドルが受ける見当違いの通知

• 技術用語や一般的な識別子と重なるハンドルは、複数のサービスで意図しない通知を受けやすい
  • @boxed ユーザーは GitHub と Mastodon で同じニックネームを使っており、人々が コミットメッセージに @boxed と書くため、GitHub 通知を多く受け取るという
  • @stack ユーザーは、ある言語でスタック関連の変数に @ が付くと、自動的にメッセージを受け取るという
  • @else を使っていたユーザーは、多くの PR やコメント通知のため、最終的にそのハンドルを手放した
  • @acme ユーザーは、複数のフレームワークのプレースホルダーと重なり、多くの通知を受け取る
  • CSS の会話では、@font-face を議論する際に @font ユーザーが継続的に迷惑を被る事例が出てくる

GitHub の自動メンションを避ける難しさ

• 「@ 文字はエスケープできない」という反応のように、GitHub の 自動メンション処理が主な原因として指摘されている
• GitHub の Issue や PR では @[any_text] を直接書くべきではないという助言が出ている
• バッククォートで囲むと役立つかもしれないという提案もある
• コード、コメント、コミットメッセージ、Issue コメントのように開発者が頻繁に使うテキスト空間では、@単語 の形がユーザー名と衝突する可能性がある

ジョークにつながった関連事例

• この状況は、短くありふれた識別子を選んだときに生じる副作用として受け止められている
• NULL ナンバープレートを購入したセキュリティ研究者が、割り当て先不明の交通違反切符を受け取ったという話に似ているという反応がある
• Steve Wozniak が 888-8888 の電話番号を取得した後、子どもたちがボタンを繰り返し押して電話がかかってくる状況を思い出した人もいる
• IRC で pokes という名前を使っていたユーザーは、人々が /me pokes [name] を /msg と誤入力し、個人メッセージを頻繁に受け取ったという
• Mastodon でも、@_@ のような顔文字が特定インスタンスの @_ ユーザーに通知を送る可能性があるという事例が出ている

@reset ユーザーの反応

• @reset ユーザーは Hacker News で、通知を受け取るたびに返信し、笑って実際に楽しんでいるという趣旨のコメントを残したとされる
• それに続く反応は、それを知れてよかったという雰囲気だった
• それでも全体の事例は、短く一般的なハンドルが開発プラットフォームの自動メンション機能と出会うと、意図しない相手に繰り返し通知が届き得ることを示している

[GN⁺]

Hacker News のコメント

• @reset はここにいるよ。@でメンションされたらいつも返信している。面白いし、あとで人々が何を作っているのかを見る楽しみも本当に大きい。
  これからも続けてほしいし、自分の一日の中でかなり楽しい部分になっている。

  • リンク先の PR に残した返信が本当に良かった。こういうことはものすごく腹立たしいことにも、ものすごく面白いことにもなり得るけど、ユーモアのセンスで受け止めていて、見ていて気持ちがいい。
  • 自分のアカウントは @username だったのに、GitHub がある日突然 usernamex に変えてしまった。
  • 同じ理由で sshole アカウントを手に入れた。

• 以前、モバイルデータベース会社の Realm で働いていた。何が起きているかを見るために、Twitter で @realm が言及されると Slack に再投稿する連携があった。
  ある朝、#twitter チャンネルがほとんどポルノに近い内容で埋まっていた。若い男性たちが露出の多い服を着て腹筋を見せつけ、カメラに向かって笑っていた。
  判明したのは、誰かが Instagram の投稿を Twitter に再投稿するボットをつないでいたことだった。Instagram はユーザー名にドットを許可しているが、Twitter は許可していない。IG アカウントはたぶん @realm.of.beauty で、Twitter はそれをそのまま @realm と解釈していた。

  • 自分も Twitter で @cmg なので、こういう Instagram のメンションをかなり受けたし、人々は自分を CheckMate Gaming、Canadian Media Guild、Cocaine Muzik Group、Chipotle Mexican Grill など、いろいろなものと勘違いしていた。
  • 似たようなことがあった。公開掲示板の名前がある略語だったのだが、その略語はゲイのパドリング・フェティッシュでも使われていた。
    こちらのハッシュタグやメンションを見ていると、たまに若い俳優がクリケットのバットのようなものでむき出しのお尻を色っぽく叩かれている場面を見ることになった。
  • Twitter で @CommonFirstNameCommonLastName を使っているが、たまにまったく別人だと勘違いした人たちがメンションや DM を送ってくる。そこまで頻繁ではないので、特に大きなストレスにはなっていない。

• 前の職場で、C プリプロセッサディレクティブにちなんだ Slack チャンネルを作ることにした。たぶん #define か #endif だったと思う。何人かが見つけて、その冗談に気づいた。
  ところが数か月後、管理者からそのチャンネルを削除してもいいかと連絡が来た。大きな組織では、Slack が組織の別の部分に見えてはいけないチャンネルを把握していて、そのせいで自分のグループ外の人たちには C プリプロセッサディレクティブのメンションが検閲されていたらしい ^^;

  • それならコードブロックの中に入れる方法を覚えることになるね。
  • Slack がメンションを防ごうとして、逆に非公開チャンネルの存在を露呈しているのが面白い。

• GitHub の Issue に、コードブロックなしでバックトレースをうっかり貼り付けたことがある。スタックは深く、各行が「#0」「#1」「#2」のように始まっていたのだが、GitHub がそれを全部その番号の Issue リンクに変えてしまった。
  各 Issue に逆参照通知まで飛び、その挙動を取り消す方法はなさそうだった。

  • Issue 参照でもっと大きな問題を経験したのはコミットメッセージだった。テンプレートとして使っていたリポジトリが、そのテンプレートリポジトリのチケットを閉じるためにコミットメッセージで「Fixes #123」と書いていた。
    問題は、更新されたテンプレートを下位リポジトリにマージすると、各下位リポジトリの Issue も閉じられてしまうことだった。
  • QEMU の GitLab Issue トラッカーでは、意図的に Issue 番号をもっと大きい数字から始めた。たぶん 100 番あたりだったと思う。
    Launchpad から移行するごく初期にこの問題に遭遇したので、すでに低い番号で作られていた Issue を2、3個だけ付け直せばよく、大きな問題にはならなかった。
  • そういう場合には、すぐに表示される元に戻すボタンが必ずあるべきだ。

• バグに遭遇した人たちが、自分が最近そのリポジトリに貢献したという理由で、たまに自分を @ してくる。そういうときにただ「LGTM Approved」と返信すると、人々は怒る。
  このプロジェクトに何をチェックインしようが自分は気にしない。自分のプロジェクトではないから。

• 一度、携帯電話番号を変えて、最後の8桁を 69696969 にしたことがある。ものすごく面白いと思った。
  すると、あらゆるトイレの個室に「楽しい時間を過ごしたいなら XYZ69696969 に電話」みたいな感じでその番号が勝手に書かれていることに気づき、毎晩一晩中電話がかかってくるようになった。

  • Steve Wozniak はしばらく 888-8888 を使っていた。とても格好いい番号だが、背景にランダムな音だけが聞こえる電話を何百件も受けていた。
    後になって分かったのは、赤ちゃんたちが親の携帯電話のボタンを押していたということで、全部 8 の番号は赤ちゃんが押しやすかったらしい。
    https://www.wired.com/1998/09/woz/
  • いくつかの地域の 867-5309 番号を持っている。今は何も動作しないようにしてあるが、しばらく PBX につないでいたら、各回線に一日最大 2,500 件まで電話が来た。Jenny に電話しようとする酔った男たちが多かった。
  • 人々がそういう番号に実際に電話するというのが驚きだ。
  • ドイツの有名サッカースター Franz Beckenbauer は携帯電話会社のプロモーションで 66666666 を希望し、同じように夜に電話がかかってきた。
    https://www.spiegel.de/panorama/falsche-nummer-beckenbauers-...

• GitHub にはタグやメンション周りにかなり危ない機能がある。たとえば組織に誰かを追加するとき、ユーザー名が自動補完される。
  ありふれた名前の人がいたのだが、名前が似ているだけの別人を誤って組織に追加したことがある。幸い、その人が招待を受け入れる前に削除して、正しい人を追加できた。

  • 本当にそう。これはものすごく厄介だ。ソースコードを証明しろとあらゆる手続きを踏ませ、暗号化も何重にも使わせる一方で、まったく関係ない人に会社コード全体への書き込み権限を与えるのはあまりにも簡単にしている。
  • 自分にもそれがあった。招待を受け入れて中身を見たあと、自分を削除するよう Issue/PR を立てた。彼らはパニックになり、自分はちょっと笑った。

• GitHub では、たまに自分がタイムゾーンとしてタグ付けされる。

  • そんなユーザー名をどうやって取ったのか気になる。短い名前はものすごく早くなくなるのに、たぶん最初の1,000人以内だったのだろう。

• 興味深いスパム経路を思いついた。何かを宣伝するPRを作ってから、スクレイピングしてきた人たちを大量に @ すればいい
  攻撃経路としても興味深い。紛らわしい @ 名を取得して、どこかのPRのレビュアーになるのを見張る。そのPRに悪意のあるコードを追加してマージすればいい
  付け加えると、職場で組織のセキュリティアクセス権を設定するとき、組み合わせ検索で世界中の誰でも追加できるのも間抜け。組織内部だけにフィルタするオプションすらない
  そして多くの人は、仕事用または個人用のGitHubで変なハンドルを使っている。なのでUIを使うには、人間が優秀な文字列比較器になるか、各人のハンドルを調べて一つずつコピー＆ペーストする必要がある
  3つ目の攻撃は、対象企業の従業員に似た名前のアカウントを大量に作り、誤って組織のリポジトリに追加されるのを期待すること

  • 実際に、誰かが誤ってそういうことをしてしまった
    GitHubユーザーが40万人に通知を送信 [2022]
    https://news.ycombinator.com/item?id=31627061

• 別のリポジトリのGitHub Issueにリンクすると、リンク先のIssueにバックリンクが作られると知って、かなり面食らったことがある。リンクを消しても元に戻らず、Issueを完全に削除しなければならない
  この機能をオフにできるといいのに

  • まさに今日これを発見した。公開リポジトリのIssueの下に、うちの非公開リポジトリのPRへのリンクが表示されていて、かなり驚いた
    幸いシークレットモードでは消え、別アカウントでログインしても見えなかった。全員に見えるわけではないが、しばらくの間はかなり不快な驚きだった
  • “https://github.com./a/b” または “https://www.github.com/a/b” も回避策として機能する
    ただ、編集して消したり、さらにはそのリンクを含むコメントを削除したりしても消えないのは、とんでもなく間抜けで腹立たしい
  • 大丈夫。誰にも通知は送られない。恥ずかしいことやスパムっぽい作業をしているのでなければ、誰も気にしないと思う
    あるIssueが他のプロジェクトにどんな影響を与えるか見られるのは良いことだし、かなり有用な情報になり得る
  • 本当に避けたいなら、Markdownの裏で bit.ly のようなリンク短縮サービスを使えば隠せると思う。試してはいない
    ただし、自分だけが貢献している個人リポジトリでだけそうしてほしい。そうでないと、クリックする側からするとものすごく怪しく見える