กรณีถูกแบนจากบัญชีการช่วยการเข้าถึงของ hCaptcha เพราะถูกมองว่าไม่ได้เป็นผู้พิการทางสายตา (2023)
(michaels.world)- ผู้ใช้ที่มีความบกพร่องทางการมองเห็นรายหนึ่งสอบถามปัญหาที่คุกกี้ของ บัญชีการช่วยการเข้าถึง ของ hCaptcha ไม่ถูกตั้งค่าใน Brave แต่ทีมซัพพอร์ตกลับแจ้งว่าการใช้งานการช่วยการเข้าถึงแบบนี้ไม่ได้รับการรองรับ พร้อมทั้งลบบัญชีและบล็อกการสมัครใหม่
- ในเวลานั้น hCaptcha มีการให้บัญชีพิเศษที่ข้ามการท้าทาย CAPTCHA ด้วยคุกกี้แทน audio CAPTCHA และต่อมามีการแก้ไขเพิ่มเติมว่าภายหลังมีการอัปเดตเพิ่มตัวเลือก text CAPTCHA แล้ว
- บัญชีดังกล่าวใช้งานได้ใน Firefox และ Chromium แต่ใน Brave คุกกี้ไม่ถูกตั้งค่าต่อเนื่องราว 1 ปี และใน JavaScript console พบว่า set cookie endpoint ส่งกลับ 401 Unauthorized
- ทีมซัพพอร์ตตัดสินว่าผู้ใช้ไม่ได้เป็นผู้พิการทางสายตา จึงห้ามใช้บัญชีการช่วยการเข้าถึง และยังคงบล็อกไว้แม้ผู้ใช้จะขอปลดหลังยืนยันว่าตนเป็นผู้พิการทางสายตาจริง
- ระบบที่ฝากเรื่องการเข้าถึงไว้กับวิธีเลี่ยงแยกต่างหาก อาจกีดกันผู้ใช้จริงออกจากบริการได้ทันทีเมื่อวิธีเลี่ยงนั้นถูกปิดกั้นตามอำเภอใจ
วิธีเลี่ยงเพื่อการเข้าถึงของ hCaptcha
- hCaptcha เป็น บริการ CAPTCHA ที่ให้ผู้ใช้กดช่องทำเครื่องหมายแล้วเลือกภาพบางประเภท เช่น บ้าน
- ในเวลานั้น hCaptcha ไม่มี audio CAPTCHA สำหรับผู้พิการทางสายตา โดยให้เหตุผลว่าจะทำให้บอตผ่านได้ง่ายขึ้น
- แทนที่จะทำเช่นนั้น มีวิธีมอบบัญชีพิเศษให้ผู้พิการทางสายตาเพื่อใช้ตั้งค่าคุกกี้และไม่ต้องผ่านการท้าทาย CAPTCHA
- ภายหลังมีการเพิ่มอัปเดตว่ามี ตัวเลือก text CAPTCHA ใน hCaptcha แล้ว แต่ระบุว่าข้อวิพากษ์ในบทความยังคงใช้ได้อยู่
มีเพียง Brave ที่ตั้งค่าคุกกี้ไม่ได้
- ผู้ใช้รายนี้ใช้ Brave เป็นเบราว์เซอร์หลัก และเป็นเวลาราว 1 ปีที่บัญชีการช่วยการเข้าถึงของ hCaptcha ไม่สามารถตั้งค่าคุกกี้ใน Brave ได้
- บัญชีเดียวกันนี้ทำงานได้ตามปกติในเบราว์เซอร์อื่น เช่น Firefox, Chromium
- ผู้ใช้ตรวจสอบขั้นตอนพื้นฐานแล้วตามคำแนะนำ เช่น อนุญาตคุกกี้ของบุคคลที่สาม แต่ปัญหาใน Brave ก็ยังคงอยู่ และข้อความผิดพลาดแนะนำให้ส่งอีเมลถึงทีมซัพพอร์ตหากปัญหายังคงเกิดขึ้น
การติดต่อซัพพอร์ตนำไปสู่ความสงสัย
- ในที่สุดผู้ใช้ก็ส่งอีเมลถึงทีมซัพพอร์ตของ hCaptcha และทีมซัพพอร์ตได้แนะนำขั้นตอนแก้ปัญหาเบื้องต้น
- เพื่อจำกัดขอบเขตของปัญหา ผู้ใช้ตรวจสอบ JavaScript console แล้วแจ้งว่าในการเรียก set cookie endpoint ของ hCaptcha บน Brave นั้นน่าจะได้รับ
401 unauthorized - ผู้ใช้ให้ข้อมูลนี้เพื่อช่วยงานซัพพอร์ตทางเทคนิค แต่เห็นว่าเนื้อหาดังกล่าวอาจทำให้ทีมซัพพอร์ตเกิดความสงสัย
การลบบัญชีการช่วยการเข้าถึงและการบล็อกการสมัครใหม่
- ระหว่างที่กำลังคุยกับเจ้าหน้าที่ซัพพอร์ต เจ้าหน้าที่อีกคนหนึ่งส่งอีเมลตอบกลับโดยมีใจความดังนี้
- ไม่รองรับรูปแบบการใช้งานดังกล่าว
- ไม่ได้รับเครดิตสำหรับ accessibility pass
- ทุกบัญชีที่ถูกใช้งานในลักษณะนี้จะถูกลบจาก hCaptcha
- หากผู้ใช้พยายามสมัครบัญชีการช่วยการเข้าถึงอีกครั้ง จะถูกบล็อก
- ผู้ใช้สับสนเพราะตนไม่ได้ทำสิ่งที่ไม่ได้รับอนุญาต แต่เพียงต้องการให้มันทำงานได้บน Brave เท่านั้น
- หลังจากนั้นทีมซัพพอร์ตอธิบายว่าผู้ใช้ ไม่ได้เป็นผู้พิการทางสายตา จึงไม่ควรใช้บัญชีการช่วยการเข้าถึง
หลังจากยืนยันว่าตนเป็นผู้พิการทางสายตาจริง
- ผู้ใช้แจ้งว่าตนเองเป็น ผู้พิการทางสายตา จริงและขอให้ปลดบล็อก แต่ทีมซัพพอร์ตตอบกลับด้วยข้อความตามแบบว่าการบล็อกบัญชียังคงมีผลต่อไป
- บัญชีถูกบล็อกจริง และผู้ใช้บอกว่าหากต้องการผ่าน hCaptcha ก็เหลือทางเลือกเพียงต้องละเมิดข้อกำหนดการให้บริการและใช้โปรแกรมแก้อัตโนมัติ
- เรื่องนี้นำไปสู่คำเตือนว่าไม่ควรไว้วางใจว่าบริษัทที่ตั้งใจทำผลิตภัณฑ์ให้เข้าถึงไม่ได้ จะดูแล วิธีเลี่ยงเพื่อการเข้าถึง แยกต่างหากให้มีเสถียรภาพได้
- พร้อมเรียกร้องว่าหากผู้ดูแลเว็บไซต์ใช้งาน hCaptcha ก็ควรพิจารณาประสบการณ์นี้ด้วย และเสริมว่า Cloudflare ดูเหมือนจะใช้ระบบของตัวเองอยู่แล้ว
1 ความคิดเห็น
ความเห็นจาก Hacker News
ผมเองก็เป็นผู้พิการทางสายตา และ hCaptcha นี่แย่ที่สุด
คุกกี้โง่ ๆ มันหมดอายุ ทำให้แทบทุกครั้งที่เจอ hCaptcha ต้องรับอีเมลแล้วไปตั้งค่าคุกกี้ใหม่
ถ้าใช้หลายอุปกรณ์และหลายเบราว์เซอร์ ประสบการณ์ผู้ใช้จะเลวร้ายเป็นพิเศษ และผมคิดว่าคนอื่น ๆ คงยอมแพ้ไปเลย
บอตอาจแก้ได้ง่ายกว่าผู้พิการทางสายตาด้วยซ้ำ หรือไม่ก็เอาไปจ้างแรงงานในโลกที่สามทำให้แทบฟรีได้ ตัวอย่าง: Anticaptcha [0]:
มันแสดงภาพเล็กจิ๋วที่แทบแยกกันไม่ออก น่าทึ่งเสียด้วยซ้ำที่พวกเขาทำให้มันแย่กว่า reCaptcha ได้สำเร็จ
CAPTCHA ของ Google ส่วนใหญ่ ต่อให้ตอบถูกนานกว่า 3 นาที ก็ส่งเข้าลูปไม่รู้จบและล้มเหลวเสมอ ส่วน hCaptcha แค่ตอบถูกสัก 1–3 อันก็ปล่อยผ่านแล้ว
ผมใช้ session cookie แต่ไม่มีเหตุผลอะไรที่ต้องอนุญาตให้บริษัทไหนมาฝังคุกกี้ในระบบของผมเพื่อเลี่ยง CAPTCHA โง่ ๆ ของพวกเขา
พูดอีกอย่างคือ ผมไม่ควรต้องเปิดเผยอะไรให้พวกเขาเลย ต่อให้ในสายตาพวกเขาผมเป็น AI ก็ไม่ควรสำคัญ
แค่ดูหัวข้อแล้วเหมือนเป็นปัญหาที่ร้ายแรงน้อยกว่าความจริงมาก
ตามบทความ hCaptcha กล่าวหาผู้เขียนอย่างหยาบคายซ้ำหลายครั้งว่าโกหกโดยไม่มีหลักฐาน ทั้งที่ผู้เขียนเป็นผู้พิการทางสายตาจริง ๆ
นี่ไม่ใช่การแก้ต่าง แต่เป็นคำอธิบาย และในขณะเดียวกันก็แสดงให้เห็นว่าความคิดแบบ “อย่าให้ช่องทางเลี่ยง CAPTCHA แก่ผู้พิการทางสายตา แต่ยกเว้นให้เฉพาะผู้พิการทางสายตา ‘ตัวจริง’ เพื่อให้ผ่าน ADA” นั้นเป็นไปไม่ได้โดยสิ้นเชิงและขยายระบบไม่ได้
ต่อให้เป็นระดับ Google, Facebook หรือ Amazon ก็คงรับภาระของระบบที่ต้องตัดสินว่าใครเป็นผู้พิการทางสายตา “ตัวจริง” ได้ยาก ยังไม่นับคำถามอย่างว่าแล้วจะนิยาม “ความพิการทางสายตา” อย่างแม่นยำว่าอะไรตั้งแต่แรก
เรื่องแบบนี้ไม่ควรเป็นปัญหาหลังปล่อยใช้ แต่เป็นไอเดียที่ควรถูกพิจารณาแค่ 5 นาทีในที่ประชุมเสนอแนวคิดแล้ว ถูกกันไม่ให้ไปถึงขั้นออกแบบด้วยซ้ำ
ถ้ามีระบบที่สามารถระบุคุณลักษณะอย่าง “ใครเป็นผู้พิการทางสายตา” ได้อย่างสมบูรณ์แบบในสภาพแวดล้อมที่ถูกโจมตีโดยคู่กรณีอย่างหนัก สิ่งนั้นย่อมมีมูลค่ามากกว่าระบบ CAPTCHA เองเสียอีก
แนวคิดนี้จะ成立ได้ก็ต่อเมื่อมีวิธีแก้ที่แข็งแกร่งกว่าปัญหาที่ CAPTCHA พยายามแก้อยู่แล้ว ดังนั้นในเชิงตรรกะมันจึง成立ไม่ได้ตั้งแต่รากฐาน
CAPTCHA บางตัวกำลังกลายเป็นสิ่งที่ เลือกปฏิบัติ มากขึ้นเรื่อย ๆ ไม่ใช่ทุกคนจะอยู่ในโลกตะวันตกและรู้จักวัตถุที่ CAPTCHA ให้หา
เมื่อไม่นานมานี้ผมยังเห็นแบบที่ให้เลือกจำนวนรูปทรงเท่ากับจำนวนพื้นผิวกรวย (conoids) บนหน้าจอ ถ้าไปถามคนบนถนนว่า conoid คืออะไร คงมีคนจำนวนไม่น้อยทำหน้างง
แต่อย่างน้อยตอนนี้ก็ได้รู้ว่ามีคนเรียกเครื่องหมายแบบนั้นว่า crosswalk ด้วย
ที่อยากพูดคงเป็น “ไม่ใช่ทุกคนอยู่ในสหรัฐฯ” มากกว่า
หัวดับเพลิง แท็กซี่สีเหลือง รถบัสสีเหลือง ผมก็ไม่เข้าใจเลย
แน่นอนว่า ด้วยจักรวรรดินิยมทางวัฒนธรรมของสหรัฐฯ ผ่านสิ่งอย่าง CAPTCHA โลกทั้งใบต้องรู้จักมาตรฐานทางวัฒนธรรมอเมริกัน ดังนั้นเอาเข้าจริงผมก็รู้แหละ
จนตอนนี้ก็ยังไม่รู้ว่าต้องเลือกวัตถุถึงตรงไหน และ สัญญาณไฟจราจร คืออะไรแน่ ๆ ก็ยังคลุมเครือ ไม่รู้ว่าต้องรวมเสาด้วยหรือไม่
มอเตอร์ไซค์ก็ยากพอสมควร และครั้งหนึ่งมีรูปที่เต็มไปด้วยบันได จนผมน่าจะกดเลือกไปประมาณ 15 ช่อง
พจนานุกรมของ Google บอกว่าเป็นศัพท์สัตววิทยาที่แปลว่า “มีรูปร่างประมาณกรวย” ส่วนพาเนล Wikipedia บอกว่าในเรขาคณิตคือผิวเส้นตรงที่มีเงื่อนไขบางอย่าง แต่ภาพก็ไม่ชวนให้เข้าใจเลย
ผลค้นหาของ Merriam-Webster บอกว่า “โครงสร้างรูปกรวย โดยเฉพาะออร์แกเนลล์เซลล์กลวงรูปกรวยตัดที่อยู่บริเวณปลายด้านหน้าของสิ่งมีชีวิต”
ดูไม่เกี่ยวกันเลย ผมเลยกดแท็บรูปภาพ ก็เจอแต่กราฟซับซ้อนสไตล์ Mathematica ที่แทบไม่เหมือนกรวย
คนอื่น ๆ ในคอมเมนต์ HN ก็ดูเหมือนจะไม่รู้เหมือนกัน
อธิบายได้ไหมว่าบนหน้าจอคุณเห็นอะไร? CAPTCHA คิดว่าอะไรคือ conoid? อะไรอย่างกรวยจราจรหรือเปล่า?
บทเรียนแรกเมื่อต้องแข่งกับ Google ควรเป็น “อย่าปฏิบัติต่อผู้ใช้แย่กว่า Google” ไม่อย่างนั้นผู้คนก็จะใช้ Google เฉย ๆ
ต่อให้โมเดลธุรกิจจะเป็นแบบนั้น การหวังพึ่งน้ำใจจากคนกลุ่มเล็ก ๆ ที่ “จะไม่ใช้ Google เด็ดขาด” ไม่ใช่เส้นทางสู่ความสำเร็จ
ระหว่างที่ hCaptcha ทำลายชื่อเสียงของตัวเอง โลกที่เหลือก็จะใช้ reCaptcha ต่อไป และไม่สนใจด้วยซ้ำว่า hCaptcha มีอยู่
เพิ่มเติมคือสะกดว่า intentional ไม่ใช่ “intensional” ให้คิดว่าเป็น “intent” + “-tion” + “-al” ไม่ใช่ “in-” + “tension” + “-al”
โดยแก่นแล้ว ผู้เขียนคือ ฉลาดเกินกว่าจะเป็นผู้พิการทางสายตา นั่นเอง
คงคิดประมาณว่า ผู้พิการทางสายตาจะ “ดู” JavaScript console ได้ยังไง?
แน่นอนว่าถ้าพูดว่า “ให้ screen reader อ่านเนื้อหาใน JavaScript console ให้ฟัง” ก็ยาวไปหน่อย
ผมเองก็เจอเรื่องแบบนี้บ่อยเกินไป เหมือนว่าถ้าผมไปอยู่ในที่ที่ผู้พิการทางสายตา “ไม่ควร” อยู่ หรือทำสิ่งที่ผู้พิการทางสายตา “ไม่ควร” ทำ ก็แปลว่าผมไม่ใช่ผู้พิการทางสายตา
การทดลอง CAPTCHA น่าจะจบได้แล้ว มันไม่ได้ผล
การยืนยันด้วยหมายเลขโทรศัพท์ก็ไม่ดีนัก แต่อย่างน้อยก็ทำให้ต้นทุนของสแปมสูงขึ้นได้บ้าง CAPTCHA ไม่ได้เป็นแบบนั้น บริการ CAPTCHA แบบ turnkey แทบทั้งหมดถูกแก้ได้ด้วยเงินไม่กี่สตางค์
การแก้ปัญหาสแปมและทราฟฟิกไม่พึงประสงค์เป็นเรื่องยาก และผมกังวลว่าสุดท้ายอาจเหลือทางเป็นไปได้อยู่สามทาง
อย่างแรกคือการละทิ้งความไม่เปิดเผยตัวตนของผู้ใช้ ถ้าตรวจสอบตัวตนจริงได้มากพอ ก็สามารถแบนบุคคลที่เป็นภัยได้อย่างถาวร และคัดกรองบอตได้ค่อนข้างมีประสิทธิภาพ แต่ความไม่เปิดเผยตัวตนบนออนไลน์ก็จะหายไป ในความเห็นผม นี่รับไม่ได้จริง ๆ
อย่างที่สองคือการปิดแพลตฟอร์ม แนวทางอย่าง Web Environment Integrity และ Private Access Tokens เป็นการปูทางไปสู่การปิดเว็บแพลตฟอร์ม ผู้ใช้เว็บส่วนใหญ่ใช้ Google Chrome หรือ Safari บนอุปกรณ์ที่มี Secure Boot จึงสามารถพิสูจน์ได้ทั้งเชนการบูต เมื่อเวลาผ่านไป จำนวนผู้ใช้ที่ทำแบบนี้ได้จะยิ่งเพิ่มขึ้น
ในอนาคตแบบนั้น เว็บจะไม่เหลือความเปิดกว้างอย่างมีความหมาย ทางเลือกอื่น ๆ จะมีประโยชน์น้อยลงเรื่อย ๆ เช่น ต่อให้ machine learning ไปไม่ถึงปัญญาประดิษฐ์ทั่วไป มันก็จะเอาชนะ CAPTCHA ทุกอย่างตรงหน้าได้อยู่ดี จึงมีโอกาสสูงที่หากไม่มีวิธีนี้แล้วจะเข้าเว็บไซต์ได้ยากขึ้น
อย่างที่สามคือการเพิ่มความรับผิดชอบของผู้ให้บริการเครือข่าย จะชอบหรือไม่ อินเทอร์เน็ตก็ได้ประโยชน์มากจากผู้ให้บริการในพื้นที่สีเทาที่มีการกำกับดูแลหรือความโปร่งใสน้อย แต่อีกวิธีหนึ่งในการกำจัดทราฟฟิกไม่พึงประสงค์คือการให้ผู้ให้บริการเครือข่ายรับผิดชอบมากขึ้น และตัดผู้ประกอบการที่ไม่ให้ความร่วมมือออกจากอินเทอร์เน็ต วิธีนี้ก็น่าจะไม่ดีนัก และจะกระตุ้นให้เกิดการใช้อำนาจในทางที่ผิด
ถึงอย่างนั้นก็ยังเป็นเรื่องยาก แล้วจะทำอะไรได้อีก? จะลดแรงจูงใจของทราฟฟิกไม่พึงประสงค์ก็ทำได้ยากหากไม่ลดคุณค่าที่บริการมอบให้ และการทำให้อ่านยากหรือทำให้ซับซ้อนอาจทำให้ทราฟฟิกไม่พึงประสงค์ทำงานยากขึ้นได้ แต่ก็ยากจะหยุดฝ่ายตรงข้ามที่มุ่งมั่นจริง ๆ
ไม่ว่าจะทางไหน ยุคของ เว็บเปิด ก็ให้ความรู้สึกว่าจบลงแล้วในทางปฏิบัติ เว็บเปิดอาจยังคงมีอยู่ได้ แต่มีแนวโน้มสูงว่าจะถูกบดบังด้วยเว็บแบบใหม่ที่ปิดกว่ามาก
บนเว็บไซต์ของเรา ถ้าไม่มี CAPTCHA บอตจะกรอกฟอร์มวันละหลายสิบรายการ พอใส่ CAPTCHA แล้วเหลือ 0 รายการ
แม้ต้นทุนในการเจาะ CAPTCHA จะถูก แต่ดูเหมือนว่าในไซต์ของเราไม่มีใครอยากข้ามอุปสรรคเล็ก ๆ นี้
CAPTCHA มีประโยชน์ก็ต่อเมื่อการแก้มันมีต้นทุน มันเป็น สัญญาณด้านต้นทุน ว่าคำขอนี้มาจากมนุษย์จริง หรืออย่างน้อยก็เป็นสิ่งที่มีมูลค่ามากกว่าหนึ่งในพันล้านของมนุษย์จริง หมายความว่าไม่ใช่ระบบสแปมอัตโนมัติเต็มรูปแบบ
บริการไปรษณีย์ก็มีต้นทุนเช่นกัน ใครก็ตามที่อยากส่งอะไรทางไปรษณีย์ต้องซื้อแสตมป์ ค่าขนส่งเป็นวิธี “ตามธรรมชาติ” ในการควบคุมทราฟฟิกและกันสแปม
หากใช้การผสมผสานระหว่างโครงสร้างเครือข่ายกับคริปโตเคอร์เรนซี ก็สามารถเรียกเก็บค่าขนส่งต่อความพยายามส่งหรือความพยายามล็อกอินแต่ละครั้งได้ แค่อีเมลสแปมหรือการเดารหัสล็อกอินหนึ่งครั้งมีค่าใช้จ่าย 1 เซนต์ ก็กลายเป็นต้นทุนต้องห้ามสำหรับสแปมอัตโนมัติเต็มรูปแบบส่วนใหญ่แล้ว
องค์ประกอบของคริปโตเคอร์เรนซีมีไว้เพื่อให้ทำธุรกรรมแบบเงินสดคล้ายแสตมป์ได้ ขณะเดียวกันก็รักษาความไม่เปิดเผยตัวตนของการเข้าถึงกระเป๋าส่วนตัวไว้
โซเชียลมีเดียฆ่า USENET ไปแล้ว และอีเมลก็จัดการปัญหาสแปมได้ด้วยการกรอง
ยังมีผู้ใช้จำนวนมากเกินไปที่จะคลิกอะไรก็ได้เพื่อโอกาสลุ้นรับรางวัล และในกระบวนการนั้นก็ยินยอมให้ตัวตนของตัวเองถูกนำไปใช้กับสแปม
สิ่งอย่าง Web Environment Integrity หรือ Private Access Tokens ไม่มีทางทำงานได้อย่างถูกต้อง เพราะสแปมเมอร์แค่ต้องเจาะอุปกรณ์รุ่นยอดนิยมรุ่นเดียวก็พอ
ฝ่ายที่เสนอเรื่องแบบนี้ไม่ใช่นักต้มตุ๋น ก็เป็นบริษัทแพลตฟอร์มที่อยากใช้มันเพื่อสร้างผลล็อกอิน สแปมเมอร์จะทุ่มทรัพยากรเพื่อเจาะระบบ แต่ผู้ใช้ทั่วไปจะไม่ทนกับความไม่สะดวก สุดท้ายมันจึงกลายเป็นการปิดกั้นคู่แข่งและความสามารถในการทำงานร่วมกัน
ความรับผิดชอบของผู้ให้บริการเครือข่ายกำลังเกิดขึ้นอยู่แล้วในระดับหนึ่ง ช่วง IP ที่ชื่อเสียงแย่จะถูกบล็อก แต่เมื่อเกิดบอตเน็ตของผู้ใช้ที่กระจายอยู่ตาม ISP หลายแห่ง ISP บางรายก็มีความเต็มใจในการรับมือไม่เท่ากัน ต่อให้รับมือก็ไม่สามารถจัดการได้ทันที และบางรายที่ไม่สนใจก็อยู่ในเขตอำนาจที่ควบคุมไม่ได้ แต่ใหญ่เกินกว่าจะบล็อก
ทางออกที่ดีที่สุดอาจเป็นการให้จ่ายอะไรเล็กน้อยตอนสร้างบัญชี ไม่ว่าจะเป็นเงิน คริปโตเคอร์เรนซี หรือ proof of work ผู้ใช้ทั่วไปต้องการบัญชีแค่ไม่กี่บัญชีที่จะใช้นาน ๆ แต่สแปมเมอร์ต้องการบัญชีจำนวนมากที่จะถูกบล็อกแทบจะทันที จึงเกิด โครงสร้างต้นทุนแบบไม่สมมาตร ที่จำเป็นต่อระบบที่ใช้งานได้
ตอนนั้นก็ยังต้องทำโจทย์ให้ยากขึ้นเรื่อย ๆ เพื่อให้ทันซอฟต์แวร์รู้จำ
ตอนนี้มันข้ามไปสู่พื้นที่ที่เครื่องแก้ได้ง่ายกว่าคนแล้ว จึงไร้ประโยชน์ต่อวัตถุประสงค์เดิม
น่าเสียดายที่ ตัวเลือกด้านการเข้าถึง ส่วนใหญ่ดูเหมือนไม่ได้ทำมาให้ใช้งานจริง
ถ้าเป็นรัฐบาลหรือบริษัทใหญ่ การเข้าถึงจะอยู่ในข้อกำหนดพื้นฐาน ต้องสามารถพูดได้ว่า “ใช่ เราเข้าถึงได้” ไม่อย่างนั้นกระแสสังคมจะโวยวาย
ดังนั้นจึงตัดผู้ขายที่ไม่บอกว่ามีการรองรับการเข้าถึงออกจากรายชื่อ ผู้ขายเองก็รู้เรื่องนี้และจะบอกเสมอว่ามีให้
แต่มันเป็นฟีเจอร์ที่ทำให้ดีได้ยาก และเกี่ยวข้องกับผู้ใช้เพียงส่วนน้อย ความช่วยเหลือที่ต้องการก็แตกต่างกันไปตามประเภทความพิการ ไม่มีใครในทีมพัฒนาเข้าใจข้อกำหนดจริงอย่างถูกต้อง
คนที่ต้องการการเข้าถึงก็ไปใช้ที่อื่น หรือบ่นไปพลางและพยายามทนใช้ให้ได้ ไม่ว่าทางไหนก็ไม่ปรากฏบนแดชบอร์ดตัวชี้วัด
ส่วนผสมแบบนี้ส่งเสริมให้เกิด shelfware คือของที่ซื้อมาแล้ววางไว้บนชั้นที่ไหนสักแห่ง แต่ในความเป็นจริงไม่ได้ใช้งาน
ถ้าผมเข้าใจถูก ปัญหาการเข้าถึงที่ hCaptcha สร้างขึ้นกำลัง ขัดขวางการเข้าถึงเว็บไซต์หลายแห่ง ของคนตาบอดคนนี้ใช่ไหม?
ลูกค้าจำนวนมากของ hCaptcha อาจเจอปัญหาในมุมของ ADA ไม่ใช่หรือ?
ถ้าผู้เขียนอยากดำเนินคดี นี่น่าจะเป็นคดีที่ ชนะค่อนข้างชัดเจน
เงื่อนไขการใช้งานไม่ได้ช่วยกันความรับผิดตาม ADA ได้
ไม่เข้าใจว่าทำไม CAPTCHA ยังมีอยู่จนถึงตอนนี้
ถ้ามีใครอยาก scrape อะไรบางอย่างหรือทำ automation ก็ปล่อยให้ทำไปไม่ได้หรือ? ยังไงก็ต้องเคารพระบบที่ต้องล็อกอินอยู่แล้ว
ยังมีข้อดีด้านความเป็นส่วนตัวด้วย คือไม่ต้องเอาผู้เยี่ยมชมไป exposed กับบริการ CAPTCHA ที่มีผู้ประมวลผลย่อยด้านข้อมูลเป็นสิบ ๆ รายขึ้นไป
บ็อตสร้างบัญชีปลอมทีละหลายพันบัญชีด้วยอีเมลของคนอื่น และอีเมลยืนยันที่เราส่งไปก็ถูกผู้รับแจ้งเป็นสแปม เพราะพวกเขาไม่เคยสมัคร
สุดท้ายผู้ให้บริการอีเมลก็ระงับบัญชีของเรา เพราะมีรายงานสแปมจำนวนมาก
ผมเคยทำ และภายในไม่กี่วันบ็อตก็เริ่มใช้ฟอร์มนั้นส่งสแปม
ผมใส่ CAPTCHA ง่าย ๆ แบบฮาร์ดโค้ดอย่าง “2+3=” ลงไป แต่ถ้าขนาดใหญ่กว่านี้คงรับมือไม่ไหว
ต้องคิดถึงการสร้างบัญชีอัตโนมัติเพื่อส่งสแปมข้อความส่วนตัว หรือเพื่อใช้สิทธิ์ฟรีเทียร์ในทางที่ผิดด้วย
automation หรือ scraping จะเลี่ยงสิ่งนั้นไปได้
ลองเอา CAPTCHA ออกจากฟอร์มล็อกอินดู แล้วจะพบว่าทุกวันคุณต้องจับผู้ใช้หลายร้อยคนที่จำเป็นต้องส่งอีเมล “โปรดยืนยันที่อยู่อีเมลของคุณ” ไปหาโดยไม่มีเหตุผล
ความเชื่อที่ว่า “พวกเขาก็ควรเคารพระบบที่ต้องล็อกอินด้วย” นั้นยอดเยี่ยม แต่ถ้าลองดูแลระบบอะไรสักอย่างบนอินเทอร์เน็ต จะรู้ว่าผู้คนไม่ว่าจะตั้งใจหรือไม่ ก็มักจะทุบระบบไปเรื่อย ๆ จนมันล้ม
บ็อตเหล่านี้ไม่รองรับ CSS ดังนั้นถ้าใช้ร่วมกับฟิลด์ฟอร์มที่ซ่อนไว้ก็จะทำงานได้ดีขึ้น
แต่ถ้าเป็นการโจมตีแบบเจาะจง ก็เป็นเพียงการเพิ่มอัตราการบล็อกบ็อตจาก 95% เป็น 99% โดยทำให้ผู้ใช้ที่ถูกต้องตามกฎหมายต้องลำบากเท่านั้น