Thật sự xin lỗi người dùng GitHub có tên @reset

 (discuss.systems)
1 điểm bởi GN⁺ 2023-07-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong một thảo luận trên GitHub Issues về việc đặt thanh ghi về 0, nội dung lại bị xử lý thành mention người dùng @reset, khiến một người không liên quan liên tục nhận email thông báo
  • Nguyên nhân là GitHub diễn giải các chuỗi như @reset thành mention tự động, nên những từ trong ngữ cảnh kỹ thuật có thể dẫn đến việc gọi nhầm người dùng thật
  • Những handle ngắn trùng với thuật ngữ kỹ thuật hoặc placeholder như @boxed, @stack, @else, @font, @acme cũng gặp tình trạng bị làm phiền bởi các thông báo tương tự
  • Đã có đề xuất dùng dấu backtick hoặc tránh kiểu @[any_text], nhưng vì thông báo vẫn có thể phát sinh trong commit message và bình luận PR·issue nên rất khó tránh hoàn toàn
  • Người dùng @reset được cho là đã vui vẻ đón nhận chuyện này trong phần bình luận trên Hacker News, nhưng các handle ngắn và phổ biến rất dễ xung đột với tính năng mention tự động của các công cụ dành cho lập trình viên

Sự cố mention @reset

  • Adrian Sampson đã xin lỗi vì trong lúc nói về việc đặt thanh ghi về 0 trên GitHub, anh vô tình gửi email thông báo đến người dùng @reset
  • Bình luận issue GitHub được liên kết là bình luận issue trong kho cucapra/calyx, và trọng tâm vấn đề là @reset đã bị hiểu là tên người dùng GitHub
  • Trong ngữ cảnh kỹ thuật của câu “setting registers to zero”, từ reset xuất hiện rất tự nhiên, và khi gắn thêm @ thì nó trở thành mention người dùng thật

Những thông báo nhầm mà các handle ngắn nhận được

  • Những handle trùng với thuật ngữ kỹ thuật hoặc định danh phổ biến rất dễ nhận các thông báo ngoài ý muốn trên nhiều dịch vụ
    • Người dùng @boxed dùng cùng một nickname trên GitHub và Mastodon, và cho biết mọi người thường viết @boxed trong commit message, khiến họ nhận rất nhiều thông báo GitHub
    • Người dùng @stack nói rằng khi một ngôn ngữ nào đó có biến liên quan đến stack kèm @, họ sẽ tự động nhận được thông báo
    • Một người từng dùng @else cuối cùng đã phải bỏ handle đó vì quá nhiều thông báo từ PR và bình luận
    • Người dùng @acme nhận nhiều thông báo vì trùng với placeholder của nhiều framework
    • Trong các cuộc thảo luận về CSS, khi bàn về @font-face, người dùng @font liên tục gặp phiền toái

Khó tránh cơ chế mention tự động của GitHub

  • Như phản hồi kiểu “không thể escape ký tự @”, cơ chế mention tự động của GitHub được chỉ ra là nguyên nhân cốt lõi
  • Có lời khuyên rằng không nên trực tiếp viết @[any_text] trong GitHub Issues hoặc PR
  • Cũng có đề xuất rằng bọc trong dấu backtick có thể giúp ích
  • Trong những không gian văn bản mà lập trình viên thường dùng như code, chú thích, commit message và bình luận issue, dạng @từ_ngữ có thể xung đột với tên người dùng

Những ví dụ liên quan mang màu sắc đùa vui

  • Tình huống này được xem là một tác dụng phụ của việc chọn các định danh ngắn và phổ biến
  • Có người nói nó giống câu chuyện một nhà nghiên cứu bảo mật mua biển số NULL rồi nhận các vé vi phạm giao thông vốn chưa được gán cho ai
  • Cũng có người nhớ đến chuyện Steve Wozniak sau khi có được số điện thoại 888-8888, trẻ con cứ bấm lặp lại các nút khiến cuộc gọi được thực hiện
  • Trên IRC, một người dùng tên pokes kể rằng mọi người thường gõ nhầm /me pokes [name] thành /msg, khiến họ thường xuyên nhận tin nhắn riêng
  • Trên Mastodon cũng có trường hợp ký tự mặt @_@ có thể gửi thông báo đến người dùng @_ trên một instance cụ thể

Phản ứng của người dùng @reset

  • Người dùng @reset được cho là đã để lại bình luận trên Hacker News với ý rằng họ trả lời mỗi khi nhận được thông báo, cười về chuyện đó và thực sự thấy thú vị
  • Phản ứng tiếp theo mang không khí nhẹ nhõm vì biết được điều này
  • Dù vậy, toàn bộ câu chuyện vẫn cho thấy khi các handle ngắn và phổ biến gặp tính năng mention tự động trên các nền tảng phát triển, những người không liên quan có thể liên tục nhận thông báo ngoài ý muốn

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-07-28
Ý kiến trên Hacker News

  • @reset đây. Hễ được mention bằng @ là tôi luôn trả lời. Vừa buồn cười, vừa thật sự rất vui khi sau đó được xem mọi người đang xây dựng gì
    Mong mọi người cứ tiếp tục làm vậy; đó là một phần khá thú vị trong ngày của tôi

    • Câu trả lời để lại trong PR được liên kết thật sự rất hay. Chuyện kiểu này có thể cực kỳ khó chịu hoặc cực kỳ vui, và thật tốt khi thấy bạn đón nhận nó bằng khiếu hài hước
    • Tài khoản của tôi từng là @username, rồi một ngày GitHub đột ngột đổi nó thành usernamex
    • Cũng vì lý do đó mà tôi lấy được tài khoản sshole

  • Trước đây tôi làm ở Realm, một công ty cơ sở dữ liệu di động. Chúng tôi có một tích hợp đăng lại lên Slack mỗi khi @realm được nhắc đến trên Twitter, để xem chuyện gì đang diễn ra
    Một buổi sáng, kênh #twitter gần như bị lấp đầy bởi nội dung gần như khiêu dâm. Những chàng trai trẻ mặc đồ hở hang khoe cơ bụng và cười với camera
    Hóa ra ai đó đã gắn một bot đăng lại bài Instagram lên Twitter, trong khi Instagram cho phép dấu chấm trong tên người dùng còn Twitter thì không. Tài khoản IG có lẽ là @realm.of.beauty, và Twitter diễn giải thẳng thành @realm

    • Tôi cũng dùng @cmg trên Twitter nên nhận khá nhiều mention Instagram kiểu này, và mọi người nhầm tôi với đủ thứ như CheckMate Gaming, Canadian Media Guild, Cocaine Muzik Group, Chipotle Mexican Grill, v.v.
    • Tôi cũng gặp chuyện tương tự. Tên một bảng tin công khai là một từ viết tắt nào đó, và từ viết tắt ấy cũng được dùng trong fetish chèo thuyền đồng tính
      Khi lướt qua hashtag hoặc mention của chúng tôi, thỉnh thoảng lại thấy cảnh một diễn viên trẻ bị đánh khêu gợi vào mông trần bằng thứ gì đó giống gậy cricket
    • Tôi dùng @CommonFirstNameCommonLastName trên Twitter, và thỉnh thoảng có người tưởng nhầm tôi là một người hoàn toàn khác rồi mention hoặc gửi DM. Không xảy ra quá thường xuyên nên cũng không quá khó chịu

  • Ở công ty cũ, chúng tôi quyết định tạo một kênh Slack đặt theo tên chỉ thị tiền xử lý C. Có lẽ là #define hoặc #endif. Một vài người phát hiện ra và hiểu trò đùa
    Nhưng vài tháng sau, quản trị viên liên hệ hỏi có thể xóa kênh đó không. Trong các tổ chức lớn, Slack biết những kênh không nên hiện ra với các bộ phận khác của tổ chức; vì thế các mention về chỉ thị tiền xử lý C bị kiểm duyệt với những người ngoài nhóm của tôi ^^;

    • Vậy là họ sẽ học cách đặt nó trong code block
    • Buồn cười là Slack cố chặn mention nhưng lại làm lộ sự tồn tại của kênh riêng tư

  • Tôi từng lỡ dán một backtrace vào issue GitHub mà không dùng code block. Stack khá sâu và mỗi dòng bắt đầu kiểu “#0”, “#1”, “#2”, GitHub biến tất cả thành liên kết tới issue có số tương ứng
    Thậm chí mỗi issue còn nhận thông báo tham chiếu ngược, và dường như không có cách nào hoàn tác hành vi đó

    • Trường hợp tôi gặp vấn đề lớn hơn với tham chiếu issue là trong commit message. Một repo dùng làm template có commit message “Fixes #123” để đóng ticket của chính repo template đó
      Vấn đề là khi merge template đã cập nhật vào các repo con, issue trong từng repo con cũng bị đóng luôn
    • Trong trình theo dõi issue GitLab của QEMU, họ cố ý bắt đầu số issue từ một số cao hơn. Hình như khoảng 100
      Họ gặp vấn đề này từ rất sớm khi di chuyển từ Launchpad, nên chỉ cần đánh số lại hai ba issue đã được tạo với số thấp; không phải chuyện lớn
    • Trong những trường hợp như vậy, nhất định phải có nút hoàn tác hiển thị ngay lập tức

  • Những người gặp bug đôi khi @ tôi chỉ vì gần đây tôi có đóng góp vào repo. Những lúc đó, nếu tôi chỉ trả lời “LGTM Approved” thì họ nổi giận
    Tôi chẳng quan tâm họ check in gì vào dự án này. Đâu phải dự án của tôi

  • Có lần tôi đổi số điện thoại sao cho 8 chữ số cuối là 69696969. Lúc đó tôi nghĩ nó cực kỳ buồn cười
    Rồi tôi phát hiện người ta đã viết bừa số đó lên mọi buồng vệ sinh kiểu “Muốn vui vẻ thì gọi XYZ69696969”, và đêm nào cũng có cuộc gọi suốt đêm

    • Steve Wozniak từng dùng 888-8888 trong một thời gian. Một số rất ngầu, nhưng ông nhận hàng trăm cuộc gọi chỉ có tiếng động ngẫu nhiên ở nền
      Sau đó mới biết là các em bé đang bấm nút trên điện thoại của bố mẹ, và số toàn 8 có vẻ rất dễ để trẻ con bấm
      https://www.wired.com/1998/09/woz/
    • Tôi có vài số 867-5309 ở nhiều khu vực. Giờ thì tôi đã cấu hình để chúng không làm gì cả, nhưng trong một thời gian khi nối vào PBX, mỗi đường dây nhận tới 2.500 cuộc gọi mỗi ngày. Rất nhiều gã say muốn gọi cho Jenny
    • Thật ngạc nhiên là người ta thật sự gọi đến những số như vậy
    • Ngôi sao bóng đá nổi tiếng người Đức Franz Beckenbauer từng yêu cầu số 66666666 khi làm quảng bá cho một nhà mạng di động, và cũng bị gọi vào ban đêm tương tự
      https://www.spiegel.de/panorama/falsche-nummer-beckenbauers-...

  • GitHub có vài tính năng khá nguy hiểm ở phần tag và mention. Ví dụ khi thêm ai đó vào tổ chức, tên người dùng sẽ được tự động hoàn thành
    Có một người có tên rất phổ biến, và chúng tôi từng lỡ thêm nhầm một người có tên tương tự nhưng không phải người đó vào tổ chức. May là đã gỡ họ ra trước khi họ chấp nhận lời mời và thêm đúng người

    • Đúng thật. Chuyện này cực kỳ khó chịu. Họ bắt bạn đi qua đủ thứ quy trình để chứng minh mã nguồn, rồi dùng nhiều lớp mã hóa, nhưng lại làm cho việc cấp quyền ghi toàn bộ code công ty cho một người hoàn toàn không liên quan trở nên quá dễ
    • Tôi cũng từng bị như vậy. Tôi chấp nhận lời mời, xem nội dung bên đó, rồi mở issue/PR yêu cầu họ gỡ tôi ra. Họ hoảng loạn, còn tôi thì thấy hơi buồn cười

  • Trên GitHub, thỉnh thoảng tôi bị tag như một múi giờ

    • Tôi tò mò không biết làm sao bạn lấy được tên người dùng đó. Tên ngắn biến mất cực nhanh, chắc bạn nằm trong 1.000 người đầu tiên

  • Nghĩ ra một đường spam khá thú vị. Chỉ cần tạo một PR quảng cáo thứ gì đó, rồi @ hàng loạt những người đã cào dữ liệu về là được
    Hướng tấn công cũng thú vị. Lấy một tên @ dễ gây nhầm lẫn rồi theo dõi xem mình có trở thành reviewer của PR nào không. Sau đó thêm mã độc vào PR đó và merge là xong
    Nói thêm, khi thiết lập quyền truy cập bảo mật cho tổ chức ở nơi làm việc, việc có thể thêm bất kỳ ai trên toàn thế giới từ phần tìm kiếm tổ hợp cũng thật ngu ngốc. Thậm chí không có tùy chọn lọc chỉ người trong nội bộ tổ chức
    Và đa số mọi người dùng các handle kỳ lạ trên GitHub công việc hoặc cá nhân. Vì vậy nếu dùng UI thì hoặc con người phải trở thành bộ so sánh chuỗi xuất sắc, hoặc phải tìm handle của từng người rồi sao chép-dán từng cái một
    Cách tấn công thứ ba là tạo hàng loạt tài khoản có tên giống nhân viên của công ty mục tiêu, rồi hy vọng ai đó lỡ tay thêm vào kho lưu trữ của tổ chức

  • Tôi từng khá bối rối khi biết rằng nếu liên kết đến một issue GitHub ở repository khác, issue được liên kết sẽ xuất hiện backlink. Xóa liên kết cũng không hoàn tác được; phải xóa hẳn issue
    Ước gì có thể tắt tính năng này

    • Hôm nay tôi mới phát hiện ra điều này. Tôi khá sốc khi thấy bên dưới một issue của repository công khai lại hiện liên kết tới PR trong repository riêng tư của chúng tôi
      May là ở chế độ ẩn danh thì nó biến mất, và đăng nhập bằng tài khoản khác cũng không thấy. Không phải ai cũng nhìn thấy, nhưng trong chốc lát đó là một bất ngờ khá khó chịu
    • “https://github.com./a/b” hoặc “https://www.github.com/a/b” cũng hoạt động như một cách lách
      Nhưng việc nó không biến mất ngay cả khi chỉnh sửa để xóa, thậm chí xóa cả bình luận chứa liên kết đó, thì cực kỳ ngu ngốc và khó chịu
    • Không sao đâu. Nó không gửi thông báo cho ai cả. Nếu bạn không làm chuyện đáng xấu hổ hay spam thì chắc chẳng ai bận tâm
      Việc xem một issue ảnh hưởng thế nào đến dự án khác là điều tốt, và có thể là thông tin khá hữu ích
    • Nếu thật sự muốn tránh, có lẽ có thể che bằng cách dùng trình rút gọn liên kết như bit.ly phía sau Markdown. Tôi chưa thử
      Tuy nhiên mong là chỉ làm vậy trong repository cá nhân mà chỉ bạn đóng góp. Nếu không, với người bấm vào thì trông cực kỳ đáng ngờ