ขออภัยอย่างยิ่งต่อผู้ใช้ GitHub ชื่อ @reset

 (discuss.systems)
1 คะแนน โดย GN⁺ 2023-07-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน GitHub issue การพูดคุยเรื่องการตั้งค่ารีจิสเตอร์เป็น 0 ถูกตีความเป็นการ เมนชันผู้ใช้ @reset ทำให้อีเมลแจ้งเตือนไปหาคนที่ไม่เกี่ยวข้องซ้ำ ๆ
  • สาเหตุคือ GitHub ตีความสตริงอย่าง @reset เป็น การเมนชันอัตโนมัติ ทำให้คำในบริบททางเทคนิคกลายเป็นการเรียกหาผู้ใช้จริง
  • แฮนด์เดิลสั้น ๆ ที่ซ้ำกับคำทางเทคนิคหรือ placeholder เช่น @boxed, @stack, @else, @font, @acme ก็เจอปัญหาแจ้งเตือนผิดคนในลักษณะคล้ายกัน
  • มีข้อเสนอให้ใช้ backtick หรือหลีกเลี่ยงการเขียน @[any_text] แต่เพราะการแจ้งเตือนอาจเกิดจาก commit message และคอมเมนต์ใน PR หรือ issue ได้ด้วย จึงหลีกเลี่ยงได้ไม่สมบูรณ์
  • มีรายงานว่าผู้ใช้ @reset เองคอมเมนต์ใน Hacker News ว่าเขาขำและสนุกกับเรื่องนี้ แต่แฮนด์เดิลที่สั้นและทั่วไปมักชนกับฟังก์ชันเมนชันอัตโนมัติของเครื่องมือสำหรับนักพัฒนาได้ง่าย

เหตุการณ์เมนชัน @reset

  • Adrian Sampson ขอโทษที่ระหว่างคุยเรื่อง การตั้งค่ารีจิสเตอร์เป็น 0 บน GitHub กลับทำให้อีเมลแจ้งเตือนไปถึงผู้ใช้ @reset
  • คอมเมนต์ใน GitHub issue ที่เกี่ยวข้องคือ คอมเมนต์ใน issue ของรีโพซิทอรี cucapra/calyx โดยปัญหาหลักคือ @reset ถูกตีความเป็นชื่อผู้ใช้ GitHub
  • ในบริบททางเทคนิคของ “setting registers to zero” คำว่า reset ปรากฏขึ้นอย่างเป็นธรรมชาติ และเมื่อมี @ นำหน้าก็กลายเป็น การเมนชันผู้ใช้จริง

การแจ้งเตือนผิดคนที่แฮนด์เดิลสั้น ๆ มักได้รับ

  • แฮนด์เดิลที่ซ้ำกับคำทางเทคนิคหรือตัวระบุที่พบบ่อย มักได้รับการแจ้งเตือนโดยไม่ตั้งใจจากหลายบริการ
    • ผู้ใช้ @boxed ใช้ชื่อเล่นเดียวกันทั้งบน GitHub และ Mastodon และบอกว่าคนมักเขียน @boxed ใน commit message จนได้รับการแจ้งเตือนจาก GitHub จำนวนมาก
    • ผู้ใช้ @stack บอกว่าเมื่อมี @ นำหน้าตัวแปรเกี่ยวกับ stack ในบางภาษา ก็จะได้รับข้อความอัตโนมัติ
    • ผู้ใช้ที่เคยใช้ @else สุดท้ายเลิกใช้แฮนด์เดิลนี้ เพราะได้รับการแจ้งเตือนจาก PR และคอมเมนต์จำนวนมาก
    • ผู้ใช้ @acme ได้รับการแจ้งเตือนเยอะ เพราะชื่อไปซ้ำกับ placeholder ของหลายเฟรมเวิร์ก
    • ในบทสนทนาเรื่อง CSS ก็มีกรณีที่ผู้ใช้ @font เจอความรำคาญอยู่เรื่อย ๆ เวลาคนคุยเรื่อง @font-face

ความยากในการหลีกเลี่ยงการเมนชันอัตโนมัติของ GitHub

  • มีความเห็นว่า “อักขระ @ ไม่สามารถ escape ได้” ซึ่งชี้ว่าต้นเหตุสำคัญคือ การประมวลผลเมนชันอัตโนมัติ ของ GitHub
  • มีคำแนะนำว่าไม่ควรเขียน @[any_text] ตรง ๆ ใน GitHub issue หรือ PR
  • บางคนเสนอว่าการครอบด้วย backtick อาจช่วยได้
  • ในพื้นที่ข้อความที่นักพัฒนาใช้งานบ่อย เช่น โค้ด คอมเมนต์ commit message และคอมเมนต์ใน issue คำในรูปแบบ @คำ อาจชนกับชื่อผู้ใช้ได้

กรณีใกล้เคียงที่กลายเป็นเรื่องขำ

  • สถานการณ์นี้ถูกมองว่าเป็นผลข้างเคียงของการเลือกตัวระบุที่สั้นและพบได้บ่อย
  • มีคนบอกว่าคล้ายกับเรื่องของนักวิจัยด้านความปลอดภัยที่ซื้อป้ายทะเบียน NULL แล้วได้รับใบสั่งจราจรที่ไม่ได้ถูกระบุเจ้าของ
  • บางคนนึกถึงกรณีที่ Steve Wozniak ได้หมายเลขโทรศัพท์ 888-8888 แล้วเด็ก ๆ กดปุ่มซ้ำ ๆ จนโทรติด
  • ผู้ใช้ที่เคยใช้ชื่อ pokes บน IRC บอกว่าคนมักพิมพ์ /me pokes [name] ผิดเป็น /msg ทำให้ได้รับข้อความส่วนตัวบ่อยครั้ง
  • บน Mastodon ก็มีกรณีที่อีโมติคอนหน้าอย่าง @_@ อาจส่งการแจ้งเตือนไปยังผู้ใช้ @_ บนบางอินสแตนซ์ได้

ปฏิกิริยาของผู้ใช้ @reset

  • มีรายงานว่าผู้ใช้ @reset คอมเมนต์ใน Hacker News ว่าทุกครั้งที่ได้รับการแจ้งเตือน เขาจะตอบกลับพร้อมหัวเราะ และจริง ๆ แล้วสนุกกับมัน
  • ปฏิกิริยาที่ตามมาคือหลายคนรู้สึกโล่งใจที่ได้รู้แบบนั้น
  • ถึงอย่างนั้น กรณีทั้งหมดนี้ก็แสดงให้เห็นว่าเมื่อ แฮนด์เดิลที่สั้นและทั่วไป ไปเจอกับฟังก์ชันเมนชันอัตโนมัติของแพลตฟอร์มสำหรับนักพัฒนา การแจ้งเตือนซ้ำ ๆ อาจไปถึงคนที่ไม่ได้ตั้งใจให้ได้รับ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-28
ความคิดเห็นบน Hacker News

  • @reset อยู่ตรงนี้ครับ/ค่ะ ถ้าถูก mention ด้วย @ ก็จะตอบเสมอ มันทั้งตลกดี และภายหลังก็สนุกมากจริง ๆ ที่ได้เห็นว่าผู้คนกำลังสร้างอะไรกันอยู่
    อยากให้ทำกันต่อไปนะ มันเป็นส่วนที่ค่อนข้างสนุกในแต่ละวันของฉันเลย

    • ชอบคำตอบที่เขาเขียนไว้ใน PR ที่ลิงก์มาจริง ๆ เรื่องแบบนี้อาจน่ารำคาญมากก็ได้ หรืออาจสนุกมากก็ได้ แต่ดีที่เห็นเขารับมือด้วย อารมณ์ขัน
    • บัญชีของฉันเคยเป็น @username แต่วันหนึ่ง GitHub ก็เปลี่ยนเป็น usernamex แบบกะทันหัน
    • ได้บัญชี sshole มาด้วยเหตุผลเดียวกัน

  • เคยทำงานที่ Realm บริษัทฐานข้อมูลบนมือถือมาก่อน ตอนนั้นมี integration ที่คอยโพสต์กลับเข้า Slack เมื่อมีการ mention @realm บน Twitter เพื่อดูว่าเกิดอะไรขึ้นบ้าง
    เช้าวันหนึ่ง ช่อง #twitter เต็มไปด้วยเนื้อหาที่แทบจะเป็นหนังโป๊ ชายหนุ่มสวมเสื้อผ้าเปิดเผย โชว์กล้ามท้อง แล้วยิ้มให้กล้อง
    ปรากฏว่ามีคนผูกบอตที่ repost โพสต์ Instagram ไปยัง Twitter แต่ Instagram อนุญาตให้มีจุดในชื่อผู้ใช้ ส่วน Twitter ไม่อนุญาต บัญชี IG น่าจะเป็น @realm.of.beauty แล้ว Twitter ก็ตีความตรง ๆ เป็น @realm

    • ฉันก็ใช้ @cmg บน Twitter เลยได้รับ mention จาก Instagram แบบนี้อยู่พอสมควร และผู้คนก็เข้าใจผิดว่าฉันเป็นสารพัดอย่าง เช่น CheckMate Gaming, Canadian Media Guild, Cocaine Muzik Group, Chipotle Mexican Grill เป็นต้น
    • เคยมีเรื่องคล้ายกัน ชื่อบอร์ดสาธารณะเป็นตัวย่อบางอย่าง ซึ่งตัวย่อนั้นก็ถูกใช้ใน เฟติชการตีด้วยไม้พายของเกย์ ด้วย
      เวลาส่องแฮชแท็กหรือ mention ของเรา บางครั้งก็ได้เห็นนักแสดงหนุ่มถูกตีบั้นท้ายเปลือยอย่างยั่วยวนด้วยอะไรสักอย่างคล้ายไม้คริกเก็ต
    • ฉันใช้ @CommonFirstNameCommonLastName บน Twitter แล้วบางครั้งก็มีคน mention หรือ DM มาเพราะเข้าใจผิดว่าเป็นคนละคนโดยสิ้นเชิง ไม่ได้เกิดบ่อยเกินไป เลยไม่ได้รำคาญมาก

  • ที่ทำงานก่อนหน้านี้ เราตัดสินใจสร้างช่อง Slack ตั้งชื่อตาม directive ของ C preprocessor น่าจะเป็น #define หรือ #endif นี่แหละ มีบางคนหาเจอและเข้าใจมุก
    แต่ไม่กี่เดือนต่อมา ผู้ดูแลระบบติดต่อมาถามว่าลบช่องนั้นได้ไหม ในองค์กรขนาดใหญ่ Slack รู้ว่ามีช่องที่ไม่ควรให้ส่วนอื่นขององค์กรเห็นอยู่ และเพราะเรื่องนั้น mention ที่เป็น directive ของ C preprocessor จึงถูกเซ็นเซอร์สำหรับคนนอกกลุ่มของฉัน ^^;

    • งั้นก็คงได้เรียนรู้วิธีใส่ไว้ใน code block
    • ตลกดีที่ Slack พยายามบล็อกการ mention แต่กลับเปิดเผย การมีอยู่ของช่องส่วนตัว เสียเอง

  • เคยเผลอวาง backtrace ลงใน issue ของ GitHub โดยไม่ได้ใส่ code block สแตกค่อนข้างลึก และแต่ละบรรทัดเริ่มด้วย “#0”, “#1”, “#2” ประมาณนี้ แล้ว GitHub ก็เปลี่ยนทั้งหมดให้เป็นลิงก์ไปยัง issue หมายเลขนั้น ๆ
    แถมยังส่งการแจ้งเตือนอ้างอิงย้อนกลับไปยังแต่ละ issue ด้วย และดูเหมือนไม่มีวิธีย้อนการทำงานนั้นกลับ

    • ปัญหาที่ใหญ่กว่าที่เคยเจอกับการอ้างอิง issue คือ ข้อความ commit repo ที่ใช้เป็น template เขียน “Fixes #123” ไว้ในข้อความ commit เพื่อปิด ticket ของ repo template นั้น
      ปัญหาคือพอ merge template ที่อัปเดตแล้วเข้า repo ลูก issue ของ repo ลูกแต่ละตัวก็ถูกปิดไปด้วย
    • ใน issue tracker ของ GitLab สำหรับ QEMU จงใจให้หมายเลข issue เริ่มจากเลขที่สูงขึ้น น่าจะประมาณ 100
      เพราะเจอปัญหานี้ตั้งแต่ช่วงแรกมาก ๆ ตอนย้ายมาจาก Launchpad เลยต้อง renumber แค่ issue สองสามอันที่ถูกสร้างไว้ด้วยเลขต่ำ ๆ แล้วก็ไม่ใช่ปัญหาใหญ่
    • กรณีแบบนั้นควรต้องมี ปุ่ม undo ที่แสดงขึ้นมาทันที

  • บางครั้งคนที่เจอบั๊กจะ @ ฉัน แค่เพราะฉันเพิ่งมี contribution ใน repo นั้นไม่นาน พอเจอแบบนั้น ฉันก็แค่ตอบว่า “LGTM Approved” แล้วคนก็โมโห
    จะ check in อะไรเข้าโปรเจกต์นี้ฉันไม่สนหรอก ไม่ใช่โปรเจกต์ของฉัน

  • ครั้งหนึ่งเคยเปลี่ยนเบอร์มือถือให้ 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 มีฟีเจอร์ที่ค่อนข้างอันตรายในส่วน tag และ mention เช่น ตอนเพิ่มใครสักคนเข้าองค์กร ชื่อผู้ใช้จะถูก autocomplete
    เคยมีคนที่มีชื่อสามัญมากอยู่คนหนึ่ง แล้วเราเผลอเพิ่มคนอื่นที่ชื่อคล้ายกันแต่เป็นคนละคนเข้าองค์กร โชคดีที่ลบออกและเพิ่มคนที่ถูกต้องได้ก่อนที่คนนั้นจะรับคำเชิญ

    • จริงมาก เรื่องนี้น่าหงุดหงิดสุด ๆ ให้เราต้องผ่านขั้นตอนสารพัดเพื่อพิสูจน์ source code และบังคับใช้การเข้ารหัสหลายชั้น แต่กลับทำให้การมอบ สิทธิ์เขียน โค้ดบริษัททั้งหมดให้คนที่ไม่เกี่ยวข้องเลยเป็นเรื่องง่ายเกินไป
    • เรื่องแบบนั้นเคยเกิดกับฉันเหมือนกัน ฉันกดรับคำเชิญ ดูของฝั่งนั้น แล้วก็เปิด issue/PR ให้เขาลบฉันออก พวกเขาตื่นตระหนกกันใหญ่ ส่วนฉันก็ขำ ๆ

  • บางครั้งบน GitHub ฉันถูก tag ว่าเป็น เขตเวลา

    • สงสัยว่าได้ชื่อผู้ใช้แบบนั้นมายังไง ชื่อสั้น ๆ หายไปเร็วมาก น่าจะอยู่ในผู้ใช้ 1,000 คนแรกมั้ง

  • นึกถึงเส้นทางสแปมที่น่าสนใจขึ้นมาได้ แค่สร้าง PR เพื่อโฆษณาอะไรสักอย่าง แล้วก็ @ คนที่ขูดรายชื่อมาให้เพียบก็พอ
    เส้นทางโจมตีก็น่าสนใจเหมือนกัน คือไปเอาชื่อ @ ที่ทำให้สับสนได้ง่าย แล้วคอยดูว่าจะได้เป็น reviewer ของ PR ไหน จากนั้นก็ใส่โค้ดอันตรายลงใน PR นั้นแล้ว merge
    อีกอย่าง ตอนตั้งค่าสิทธิ์เข้าถึงด้านความปลอดภัยขององค์กรในที่ทำงาน การที่ช่องค้นหาแบบ autocomplete สามารถเพิ่มใครก็ได้จากทั่วโลกนี่ก็โง่มาก ไม่มีแม้แต่ตัวเลือกให้กรองเฉพาะคนในองค์กร
    และคนส่วนใหญ่ก็ใช้ handle แปลก ๆ ทั้งใน GitHub สำหรับงานหรือส่วนตัว ดังนั้นถ้าจะใช้ UI คนก็ต้องกลายเป็นตัวเปรียบเทียบสตริงชั้นยอด หรือไม่ก็ต้องไปหาว่าแต่ละคนใช้ handle อะไร แล้วคัดลอกวางทีละคน
    การโจมตีแบบที่สามคือสร้างบัญชีจำนวนมากที่มีชื่อคล้ายกับพนักงานของบริษัทเป้าหมาย แล้วหวังว่าจะมีคนเพิ่มเข้า repository ขององค์กรโดยไม่ได้ตั้งใจ

    • ในความเป็นจริง มีคนเคยทำแบบนั้นโดยไม่ตั้งใจจริง ๆ
      ผู้ใช้ GitHub ส่งการแจ้งเตือนไปยังคน 400,000 คน [2022]
      https://news.ycombinator.com/item?id=31627061

  • เคยค่อนข้างตกใจเมื่อรู้ว่าถ้าลิงก์ไปยัง issue ของ GitHub ใน repository อื่น จะมี backlink เกิดขึ้นใน issue ที่ถูกลิงก์ไป ต่อให้ลบลิงก์ก็ย้อนกลับไม่ได้ ต้องลบ issue ทิ้งทั้งหมด
    ถ้าปิดฟีเจอร์นี้ได้ก็คงดี

    • เพิ่งเจอเรื่องนี้วันนี้เอง ค่อนข้างตกใจที่เห็นลิงก์ไปยัง PR ของ repository ส่วนตัว ของเราแสดงอยู่ใต้ issue ใน repository สาธารณะ
      โชคดีที่มันหายไปในโหมดไม่ระบุตัวตน และแม้ล็อกอินด้วยบัญชีอื่นก็ไม่เห็น ไม่ได้แสดงให้ทุกคนเห็น แต่ก็เป็นความประหลาดใจที่น่าขนลุกอยู่ชั่วครู่
    • “https://github.com./a/b” หรือ “https://www.github.com/a/b” ก็ใช้เป็นวิธีเลี่ยงได้เหมือนกัน
      แต่การที่มันไม่หายไปแม้จะแก้ไขเพื่อลบออก หรือแม้กระทั่งลบคอมเมนต์ที่มีลิงก์นั้นอยู่ ก็โง่และน่าหงุดหงิดมาก
    • ไม่เป็นไรหรอก มันไม่ได้ส่งการแจ้งเตือนไปหาใคร ถ้าไม่ได้ทำอะไรน่าอายหรือทำงานแนวสแปม ก็คงไม่มีใครสนใจ
      การเห็นว่า issue หนึ่งส่งผลต่อโปรเจกต์อื่นอย่างไรเป็นเรื่องดี และอาจเป็นข้อมูลที่มีประโยชน์มาก
    • ถ้าอยากหลีกเลี่ยงจริง ๆ ก็น่าจะซ่อนด้วย บริการย่อลิงก์ อย่าง bit.ly ไว้หลัง Markdown ได้ ยังไม่ได้ลองทดสอบ
      แต่ขอให้ทำแบบนั้นเฉพาะใน repository ส่วนตัวที่มีแค่ตัวเอง contribute เท่านั้น ไม่อย่างนั้นในสายตาคนที่คลิกจะดูน่าสงสัยมาก