Vụ việc bị chặn khỏi tài khoản hỗ trợ khả năng tiếp cận của hCaptcha vì “không phải người khiếm thị” (2023)
(michaels.world)- Một người dùng khiếm thị đã hỏi về việc cookie của tài khoản hỗ trợ khả năng tiếp cận hCaptcha không được thiết lập trên Brave, nhưng đội ngũ hỗ trợ nói rằng cách dùng hỗ trợ khả năng tiếp cận này không được hỗ trợ, đồng thời thông báo sẽ xóa tài khoản và chặn đăng ký lại
- Khi đó, thay vì CAPTCHA âm thanh, hCaptcha cung cấp các tài khoản đặc biệt dùng cookie để bỏ qua thử thách CAPTCHA; về sau có phần đính chính rằng một bản cập nhật đã bổ sung tùy chọn CAPTCHA dạng văn bản
- Trên Firefox và Chromium, tài khoản hoạt động, nhưng trên Brave trong khoảng 1 năm cookie không được thiết lập; trong console JavaScript, endpoint set cookie trả về 401 Unauthorized
- Đội ngũ hỗ trợ cho rằng người dùng không phải người khiếm thị nên chặn họ dùng tài khoản hỗ trợ khả năng tiếp cận, và vẫn giữ lệnh chặn ngay cả sau khi người dùng yêu cầu gỡ chặn, nói rằng mình thực sự là người khiếm thị
- Một hệ thống giao khả năng tiếp cận cho một cơ chế đi đường vòng riêng biệt có thể loại người dùng thực khỏi việc sử dụng dịch vụ ngay khoảnh khắc cơ chế đó bị chặn tùy ý
Cách hCaptcha cho đi đường vòng để hỗ trợ khả năng tiếp cận
- hCaptcha là một dịch vụ CAPTCHA yêu cầu người dùng bấm vào checkbox rồi chọn các hình ảnh cụ thể, chẳng hạn như ngôi nhà
- Khi đó hCaptcha không cung cấp CAPTCHA âm thanh cho người khiếm thị, với lý do làm vậy sẽ khiến bot dễ vượt qua hơn
- Thay vào đó, họ có cách cung cấp tài khoản đặc biệt cho người khiếm thị để thiết lập cookie và không phải đi qua thử thách CAPTCHA
- Sau này có thêm cập nhật rằng hCaptcha đã có tùy chọn CAPTCHA dạng văn bản, nhưng bài viết nói vấn đề được nêu trong phần chính vẫn còn hiệu lực
Cookie không được thiết lập chỉ trên Brave
- Người dùng dùng Brave làm trình duyệt chính, và trong khoảng 1 năm tài khoản hỗ trợ khả năng tiếp cận hCaptcha không thể thiết lập cookie trên Brave
- Cùng tài khoản đó hoạt động bình thường trên các trình duyệt khác như Firefox, Chromium
- Theo hướng dẫn, người dùng đã kiểm tra các biện pháp cơ bản như cho phép cookie bên thứ ba, nhưng sự cố vẫn tiếp diễn trên Brave; thông báo lỗi hướng dẫn gửi email cho đội ngũ hỗ trợ nếu vấn đề tiếp tục xảy ra
Yêu cầu hỗ trợ dẫn đến nghi ngờ
- Cuối cùng người dùng đã gửi email cho đội ngũ hỗ trợ hCaptcha, và đội ngũ hỗ trợ hướng dẫn các bước khắc phục sự cố cơ bản
- Để thu hẹp vấn đề, sau khi kiểm tra console JavaScript, người dùng cho biết có vẻ lệnh gọi endpoint set cookie của hCaptcha trên Brave trả về
401 unauthorized - Người dùng cung cấp thông tin này để giúp hỗ trợ kỹ thuật, nhưng cho rằng chính nội dung đó có thể đã khiến đội ngũ hỗ trợ nghi ngờ
Xóa tài khoản hỗ trợ khả năng tiếp cận và chặn đăng ký lại
- Trong khi đang trao đổi với một nhân viên hỗ trợ, một nhân viên hỗ trợ khác gửi câu trả lời với ý như sau
- Cách sử dụng đó không được hỗ trợ
- Không nhận được credit cho accessibility pass
- Tất cả tài khoản được dùng theo cách này sẽ bị xóa khỏi hCaptcha
- Nếu người dùng cố đăng ký lại tài khoản hỗ trợ khả năng tiếp cận, họ sẽ bị chặn
- Người dùng bối rối, nói rằng mình không làm điều gì không được phép mà chỉ cố làm cho nó hoạt động trên Brave
- Sau đó đội ngũ hỗ trợ giải thích rằng vì người dùng không phải người khiếm thị, họ không được dùng tài khoản hỗ trợ khả năng tiếp cận
Sau khi phản bác rằng mình thực sự là người khiếm thị
- Người dùng nói rõ rằng mình thực sự là người khiếm thị và yêu cầu gỡ chặn, nhưng đội ngũ hỗ trợ gửi một câu trả lời theo mẫu rằng họ vẫn giữ lệnh chặn tài khoản
- Tài khoản thực tế đang bị chặn, và người dùng nói rằng để vượt qua hCaptcha, họ rơi vào tình thế phải vi phạm điều khoản dịch vụ và dùng chương trình tự động giải
- Điều này dẫn tới lời cảnh báo rằng không nên tin một công ty cố ý cung cấp sản phẩm không thể tiếp cận sẽ duy trì ổn định một cơ chế đi đường vòng cho khả năng tiếp cận riêng biệt
- Bài viết kêu gọi các nhà vận hành website cân nhắc trải nghiệm này nếu họ dùng hCaptcha, đồng thời nói thêm rằng Cloudflare có vẻ đã dùng hệ thống riêng của mình
1 bình luận
Các ý kiến trên Hacker News
Tôi cũng là người khiếm thị, và hCaptcha thật sự tệ nhất
Cái cookie ngu ngốc đó hết hạn, nên gần như mỗi lần gặp hCaptcha tôi đều phải nhận email rồi thực hiện quy trình đặt cookie
Nếu dùng nhiều thiết bị và trình duyệt thì trải nghiệm người dùng đặc biệt khủng khiếp, và tôi nghĩ người khác chắc sẽ bỏ cuộc luôn
Bot có thể giải dễ hơn người khiếm thị, hoặc thuê ngoài cho lao động ở thế giới thứ ba với giá gần như miễn phí. Ví dụ: Anticaptcha [0]:
Nó đưa ra những hình ảnh cực nhỏ, gần như không phân biệt được với nhau; việc họ xoay xở làm cho nó còn tệ hơn reCaptcha nhiều đúng là đáng nể
CAPTCHA của Google đa phần dù giải đúng hơn 3 phút vẫn đưa tôi vào vòng lặp vô tận và luôn thất bại, trong khi hCaptcha chỉ cần giải đúng 1–3 cái là cho qua
Tôi dùng cookie phiên, nhưng không có lý do gì tôi phải cho phép một công ty cấy cookie vào hệ thống của mình chỉ để né cái CAPTCHA ngu ngốc của họ
Nói cách khác, tôi không cần phải tiết lộ bất cứ điều gì cho họ. Trong mắt họ tôi có là AI cũng không nên quan trọng
Chỉ nhìn tiêu đề thì vấn đề có vẻ ít nghiêm trọng hơn thực tế rất nhiều
Theo bài viết, dù tác giả thực sự là người khiếm thị, hCaptcha vẫn nhiều lần thô lỗ cáo buộc tác giả nói dối mà không có căn cứ
Đây không phải là biện hộ mà là giải thích; đồng thời nó cũng cho thấy ý tưởng “không cung cấp cách vượt CAPTCHA cho người khiếm thị, nhưng chỉ ngoại lệ cho người khiếm thị ‘thật’ để qua được ADA” là hoàn toàn bất khả thi và không thể mở rộng đến mức nào
Ngay cả ở quy mô như Google, Facebook hay Amazon cũng khó gánh nổi tải của một hệ thống xác định ai là người khiếm thị “thật”. Điều đó vẫn đúng ngay cả khi bỏ qua những câu hỏi như rốt cuộc định nghĩa chính xác “khiếm thị” là gì
Đây không phải là thứ đem triển khai rồi mới thành vấn đề; nó là một ý tưởng đáng lẽ chỉ cần xem xét 5 phút trong cuộc họp đề xuất là phải chặn lại trước khi kịp bước vào giai đoạn thiết kế
Nếu có một hệ thống có thể phân định hoàn hảo một đặc tính như “ai là người khiếm thị” trong môi trường đầy tấn công đối kháng, thì bản thân nó còn có giá trị hơn nhiều so với hệ thống CAPTCHA
Ý tưởng này chỉ có thể đứng vững nếu bạn đã có sẵn một lời giải mạnh hơn vấn đề mà CAPTCHA cố giải quyết, nên về mặt logic nó không đứng vững ngay từ gốc
Một số CAPTCHA đang ngày càng trở nên phân biệt đối xử. Không phải ai cũng sống ở phương Tây và nhận ra được các vật thể mà CAPTCHA yêu cầu
Gần đây tôi còn thấy loại yêu cầu chọn hình có số lượng bằng số mặt nón (conoids) trên màn hình; nếu hỏi người ngoài phố conoid là gì thì khá nhiều người sẽ nhìn trân trối
Dù vậy, giờ tôi cũng biết có người gọi vạch sang đường là crosswalk
Có lẽ ý bạn muốn nói là “không phải ai cũng sống ở Mỹ”
Vòi cứu hỏa, taxi vàng, xe buýt vàng tôi cũng chẳng có cảm giác gì
Tất nhiên nhờ chủ nghĩa đế quốc văn hóa Mỹ thông qua những thứ như CAPTCHA, cả thế giới phải biết các chuẩn mực văn hóa Mỹ, nên thực tế là tôi có biết
Đến giờ tôi vẫn không biết phải chọn đến phần nào của vật thể, và đèn giao thông là gì cũng mơ hồ. Không rõ có tính cả cột hay không
Xe máy cũng khá khó, và có lần tôi gặp bức ảnh toàn cầu thang nên hình như đã đánh dấu khoảng 15 ô
Từ điển Google nói đó là thuật ngữ động vật học nghĩa là “có dạng gần giống hình nón”, còn khung Wikipedia nói trong hình học đó là một mặt kẻ thỏa mãn một số điều kiện nhất định, nhưng hình minh họa cũng hoàn toàn không trực quan
Kết quả Merriam-Webster thì nói là “cấu trúc dạng nón, đặc biệt là một bào quan rỗng hình nón cụt ở đầu trước của sinh vật”
Thấy chẳng liên quan gì nên tôi bấm sang tab hình ảnh, thì chỉ toàn các đồ thị phức tạp kiểu Mathematica trông chẳng giống hình nón mấy
Có vẻ những người khác trong bình luận HN cũng không biết y như vậy
Bạn có thể mô tả bạn đã thấy gì trên màn hình không? CAPTCHA nghĩ cái gì là conoid vậy? Kiểu nón giao thông à?
Bài học đầu tiên khi cạnh tranh với Google phải là “đừng coi thường người dùng hơn cả Google”. Nếu không, mọi người sẽ cứ dùng Google
Dù cách kinh doanh của họ như vậy, trông chờ vào thiện chí của một nhóm nhỏ “những người tuyệt đối không dùng Google” không phải là con đường dẫn tới thành công
Trong lúc hCaptcha tự hủy hoại danh tiếng của mình, phần còn lại của thế giới sẽ tiếp tục dùng reCaptcha và chẳng quan tâm đến sự tồn tại của hCaptcha
Nhân tiện, cách viết đúng là intentional, không phải “intensional”. Hãy nghĩ là “intent” + “-tion” + “-al”, chứ không phải “in-” + “tension” + “-al”
Về bản chất, tác giả đã quá thông minh để là người khiếm thị
Có lẽ họ nghĩ người khiếm thị thì làm sao “nhìn” được JavaScript console?
Tất nhiên nói “để trình đọc màn hình đọc nội dung JavaScript console” thì hơi dài
Tôi cũng gặp chuyện như thế này quá thường xuyên. Vì tôi ở những nơi tôi “không nên” ở, hoặc làm những việc tôi “không nên” làm, nên họ cho rằng tôi không phải người khiếm thị
Thử nghiệm CAPTCHA nên sớm được kết thúc. Nó đã không hiệu quả
Xác minh số điện thoại cũng không hay, nhưng ít nhất nó cũng làm tăng chi phí spam ở một mức nào đó. CAPTCHA thì không. Hầu hết mọi dịch vụ CAPTCHA trọn gói đều có thể bị giải chỉ với vài xu
Việc giải quyết vấn đề spam và lưu lượng độc hại là khó, và tôi lo rằng cuối cùng nó sẽ thu hẹp lại còn ba khả năng
Thứ nhất là từ bỏ tính ẩn danh của người dùng. Nếu xác minh đủ kỹ danh tính ngoài đời, ta có thể cấm vĩnh viễn các cá nhân độc hại và lọc bot khá hiệu quả, nhưng tính ẩn danh trực tuyến sẽ biến mất. Theo tôi, điều đó đúng nghĩa là không thể chấp nhận được
Thứ hai là đóng nền tảng. Những cách tiếp cận như Web Environment Integrity và Private Access Tokens đang mở đường cho việc đóng nền tảng web. Phần lớn người dùng web dùng Google Chrome hoặc Safari trên thiết bị có Secure Boot, nên có thể chứng thực toàn bộ chuỗi khởi động. Theo thời gian, số người dùng có thể thực hiện việc này sẽ tăng lên
Trong tương lai đó, web sẽ không còn mở theo nghĩa thực chất. Các lựa chọn thay thế sẽ ngày càng kém hữu dụng hơn; chẳng hạn, ngay cả khi học máy không đạt tới trí tuệ nhân tạo tổng quát, nó vẫn sẽ áp đảo mọi CAPTCHA trước mắt, nên nếu không có cách này thì khả năng cao là việc vào các trang web sẽ trở nên khó khăn
Thứ ba là tăng trách nhiệm của nhà vận hành mạng. Dù thích hay không, Internet hưởng lợi rất nhiều từ các nhà vận hành ở vùng xám, ít bị giám sát hoặc thiếu minh bạch. Nhưng một cách khác để loại bỏ lưu lượng độc hại là đặt nhiều trách nhiệm hơn lên nhà vận hành mạng, và cắt các nhà cung cấp không hợp tác khỏi Internet. Cách này có lẽ cũng chẳng hay, và sẽ khuyến khích lạm dụng quyền lực
Dù vậy, đây là vấn đề khó. Còn có thể làm gì khác? Dù cố giảm động cơ tạo lưu lượng độc hại, điều đó khó thực hiện nếu không làm giảm giá trị mà dịch vụ cung cấp; còn obfuscation có thể khiến lưu lượng độc hại khó tạo hơn, nhưng khó chặn được đối thủ có quyết tâm cao
Dù theo hướng nào, kỷ nguyên web mở trên thực tế có vẻ đã kết thúc. Web mở có thể tiếp tục tồn tại, nhưng nhiều khả năng sẽ bị một web mới, khép kín hơn rất nhiều che khuất
Trên website của chúng tôi, nếu không có CAPTCHA thì bot điền hàng chục biểu mẫu mỗi ngày. Thêm CAPTCHA vào thì con số về 0
Dù chi phí phá CAPTCHA rẻ, có vẻ trên site của chúng tôi không ai muốn vượt qua rào cản nhỏ đó
CAPTCHA chỉ hữu ích khi việc giải nó có chi phí. Nó trở thành tín hiệu chi phí cho thấy yêu cầu này đến từ một người thật, hoặc ít nhất là một thực thể lớn hơn 1 phần tỷ của một người thật. Nghĩa là không phải một hệ thống spam hoàn toàn tự động
Dịch vụ bưu chính cũng có chi phí. Muốn gửi thứ gì đó qua bưu điện, ai cũng phải mua tem. Phí vận chuyển là một cách “tự nhiên” để điều tiết lưu lượng và ngăn spam
Nếu dùng kết hợp cấu trúc mạng và tiền mã hóa, có thể áp phí vận chuyển cho mỗi lần thử gửi hoặc thử đăng nhập. Chỉ cần tốn 1 cent cho mỗi email spam hoặc mỗi lần đoán đăng nhập cũng đã trở thành chi phí cấm đối với phần lớn spam hoàn toàn tự động
Thành phần tiền mã hóa nhằm cho phép các giao dịch giống tem thư, có tính tiền mặt, đồng thời vẫn giữ được tính ẩn danh khi truy cập ví cá nhân
Mạng xã hội đã giết USENET, còn email đã quản lý được vấn đề spam nhờ lọc
Cũng có quá nhiều người dùng sẽ bấm vào bất cứ thứ gì để có cơ hội trúng quà, và trong quá trình đó chấp thuận cho danh tính của mình bị dùng cho spam
Những thứ như Web Environment Integrity hay Private Access Tokens sẽ không bao giờ hoạt động đúng. Vì spammer chỉ cần phá được một mẫu thiết bị phổ biến là đủ
Bên đề xuất những thứ này hoặc là kẻ lừa đảo, hoặc là các công ty nền tảng muốn dùng chúng để tạo hiệu ứng khóa chân. Spammer sẽ bỏ tài nguyên để phá hệ thống, còn người dùng bình thường thì không chịu đựng bất tiện, nên cuối cùng nó sẽ chặn đối thủ cạnh tranh và khả năng tương tác
Trách nhiệm của nhà vận hành mạng hiện đã diễn ra ở mức đáng kể. Các dải IP có uy tín xấu bị chặn. Nhưng khi xuất hiện botnet gồm người dùng rải rác ở nhiều ISP, một số ISP có mức độ sẵn sàng phản ứng khác nhau, và dù có phản ứng cũng không thể xử lý ngay; một số bên không quan tâm lại nằm trong các khu vực tài phán không thể kiểm soát, nhưng quá lớn để chặn
Giải pháp tốt nhất có lẽ là yêu cầu trả một khoản nhỏ nào đó khi tạo tài khoản, bằng tiền, tiền mã hóa hoặc proof-of-work. Người dùng bình thường chỉ cần vài tài khoản sẽ dùng lâu dài, còn spammer cần số lượng lớn tài khoản gần như sẽ bị chặn ngay, nhờ đó tạo ra cấu trúc chi phí bất đối xứng cần thiết cho một hệ thống hoạt động được
Khi đó cũng đã phải liên tục làm bài toán khó hơn để theo kịp phần mềm nhận dạng
Giờ nó đã chuyển sang lĩnh vực mà máy giải dễ hơn người, nên đã trở nên vô dụng với mục đích ban đầu
Đáng tiếc là hầu hết tùy chọn hỗ trợ tiếp cận dường như không được tạo ra để thực sự được sử dụng
Nếu là chính phủ hoặc tập đoàn lớn, hỗ trợ tiếp cận là yêu cầu cơ bản. Họ phải có thể nói “vâng, chúng tôi có thể tiếp cận được”, nếu không dư luận sẽ ồn ào
Vì vậy họ loại khỏi danh sách nhà cung cấp những bên không nói rằng mình có cung cấp hỗ trợ tiếp cận. Các nhà cung cấp cũng biết điều này và chắc chắn sẽ nói là có cung cấp
Nhưng đây là tính năng khó làm cho đúng, và chỉ liên quan đến một phần nhỏ của tập người dùng. Mỗi dạng khuyết tật lại cần hỗ trợ khác nhau. Không ai trong đội phát triển thực sự hiểu đúng các yêu cầu
Những người cần hỗ trợ tiếp cận sẽ chuyển sang nơi khác, hoặc càu nhàu rồi cố xoay xở chịu đựng. Cả hai trường hợp đều không xuất hiện trên dashboard chỉ số
Sự kết hợp này khuyến khích shelfware: thứ được mua về rồi đặt đâu đó trên kệ, nhưng thực tế không được dùng
Nếu tôi hiểu đúng, vấn đề về hỗ trợ tiếp cận mà hCaptcha tạo ra đang chặn người khiếm thị này truy cập nhiều website phải không?
Chẳng phải nhiều khách hàng của hCaptcha có thể gặp vấn đề từ góc độ ADA sao?
Nếu tác giả muốn kiện, đây có vẻ gần như là một vụ thắng kiện rõ ràng
Điều khoản sử dụng không thể bảo vệ họ khỏi trách nhiệm theo ADA
Tôi không hiểu vì sao đến giờ captcha vẫn còn tồn tại
Nếu ai đó muốn scrape thứ gì đó hoặc tạo tự động hóa thì cứ để họ làm không được sao? Dù sao thì họ cũng phải tôn trọng hệ thống đăng nhập
Cũng có lợi ích về quyền riêng tư: không phơi bày khách truy cập trước một dịch vụ captcha có hàng chục bên xử lý dữ liệu phụ
Bot tạo hàng nghìn tài khoản giả bằng địa chỉ email của người khác, và các email xác nhận mà chúng tôi gửi bị người nhận báo cáo là spam vì họ chưa từng đăng ký
Cuối cùng nhà cung cấp email đã đình chỉ tài khoản của chúng tôi vì có quá nhiều báo cáo spam
Tôi thì rồi, và chỉ sau vài ngày bot đã bắt đầu dùng biểu mẫu đó để gửi spam
Tôi đã thêm một captcha nhỏ kiểu hard-code như “2+3=”, nhưng nếu quy mô lớn hơn thì chắc đã không thể kham nổi
Cũng cần nghĩ đến việc tạo tài khoản tự động để spam tin nhắn riêng hoặc lạm dụng gói miễn phí
Tự động hóa hoặc scraping sẽ đi vòng qua điều đó
Nếu bỏ captcha khỏi biểu mẫu đăng nhập, bạn sẽ thấy mỗi ngày mình bắt được hàng trăm người dùng phải nhận email “vui lòng xác nhận địa chỉ email” mà chẳng vì lý do gì
Niềm tin rằng “họ cũng nên tôn trọng hệ thống đăng nhập” là rất tốt, nhưng khi vận hành thứ gì đó trên Internet, bạn sẽ biết rằng dù cố ý hay không, người ta sẽ đập hệ thống cho đến khi nó sập
Những bot này không hỗ trợ CSS, nên khi kết hợp với các trường biểu mẫu bị ẩn thì còn hoạt động tốt hơn
Tuy nhiên, nếu là tấn công có chủ đích thì cùng lắm chỉ nâng tỷ lệ chặn bot từ 95% lên 99% trong khi chỉ làm người dùng hợp pháp thêm khổ