ถูก Cloudflare บล็อก

 (jrhawley.ca)
1 คะแนน โดย GN⁺ 2023-08-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างใช้งานหน้า GitLab ที่จำเป็นต่อการทำงาน ผู้เขียนติดอยู่ใน “secure connection loop” ที่การตรวจสอบ Browser Integrity Check ของ Cloudflare ไม่สิ้นสุด และหลังจากนั้น Firefox ก็ถูกบล็อกไม่ให้เข้าถึงเว็บไซต์ภายในอีกแห่งของบริษัท
  • การเปลี่ยนค่า privacy.resistFingerprinting ใน Firefox ช่วยให้เข้า GitLab ได้ แต่วันถัดมากลับมีหน้าบล็อกปรากฏขึ้นบน เว็บไซต์ภายในที่ไม่เกี่ยวข้องกัน และแม้จะเปลี่ยนค่ากลับก็ยังไม่หาย
  • ภายใต้เงื่อนไขเดียวกันคือใช้อุปกรณ์ทำงานเครื่องเดิม, VPN ของบริษัท, และใบรับรองความปลอดภัยเดียวกัน Chrome เข้าได้ แต่ Firefox ถูกบล็อก จึงมองว่าสาเหตุการบล็อกน่าจะเกี่ยวข้องกับ browser fingerprint หรือการไม่มี fingerprint
  • ในช่วงนี้จึงต้องใช้ Chrome กับเว็บงานภายใน และผู้ใช้ก็ยากจะรู้ว่าเว็บภายในหรือภายนอกที่ถูก “ปกป้อง” ด้วย Cloudflare จะได้รับผลกระทบอีกมากแค่ไหน
  • หากแนวโน้มอย่าง remote attestation, Web Integrity API และ passkeys ให้อำนาจกับองค์กรมากขึ้น บุคคลทั่วไปอาจสูญเสียเสรีภาพในการเลือกฮาร์ดแวร์ ระบบปฏิบัติการ และซอฟต์แวร์ และต้องปรับตัวให้เข้ากับกฎที่มองไม่เห็น

secure connection loop ของ Cloudflare

  • Cloudflare ให้บริการเครือข่ายส่งข้อมูล, การป้องกันการโจมตีแบบปฏิเสธการให้บริการแบบกระจาย, และบริการโครงสร้างพื้นฐานเครือข่ายอื่น ๆ แก่ส่วนใหญ่ของอินเทอร์เน็ต
  • เว็บไซต์จำนวนมากที่ใช้ Cloudflare จะวาง Browser Integrity Check ไว้ก่อนการเข้าถึง
    • เป้าหมายคือกันผู้ไม่หวังดี บอต และทราฟฟิกที่ไม่ต้องการ พร้อมทำให้แน่ใจว่ามนุษย์จริงใช้งานเว็บไซต์ตามที่ตั้งใจไว้
    • แม้แต่ผู้ใช้ปกติที่เข้ามาด้วยเจตนาดีก็อาจถูกขวางอยู่ที่หน้าความปลอดภัยได้
  • secure connection loop คือภาวะที่เมื่อผู้ใช้กรอก URL แล้ว Cloudflare ดักคำขอไว้และแสดงหน้า “Checking if the site connection is secure” โดยที่การตรวจสอบไม่เคยจบ
    • ตัวแสดงการโหลดหมุนไม่หยุด หรือมีการขอให้ยืนยันความเป็นมนุษย์ซ้ำแล้วซ้ำอีกพร้อมการรีเฟรชวนลูป
    • แม้ผู้ใช้จะทำตามขั้นตอนที่ร้องขอแล้ว ก็ยังถูกขอขั้นตอนเดิมหรือขั้นตอนถัดไปอีกจนไม่สามารถผ่านได้
  • หากค้นหา “Cloudflare checking if the site connection is secure” จะพบว่านอกจากเอกสารทางการของ Cloudflare แล้ว ยังมีคำถามจากผู้ใช้จำนวนมากที่พยายามหาทางข้ามหน้านี้ จึงดูเป็นปัญหาที่พบได้บ่อย

ปัญหาการเข้า GitLab และการเปลี่ยนค่าตั้งค่า Firefox

  • ตอนพยายามเข้า GitLab จากคอมพิวเตอร์ที่ใช้ทำงานเพื่อตรวจสอบซอฟต์แวร์วิทยาศาสตร์ หน้าตรวจสอบ Browser Integrity Check ของ Cloudflare ก็ปรากฏขึ้น
  • ผู้เขียนลองดูข้อผิดพลาดใน developer console, ปิดส่วนขยายชั่วคราว, เปิดหน้าต่างส่วนตัว, และรีสตาร์ตคอมพิวเตอร์ แต่ก็ยังออกจากลูปไม่ได้
  • จากผลการค้นหา พบคำแนะนำให้ปิดใช้งานตัวเลือก privacy.resistFingerprinting ใน about:config ของ Firefox
    • ตอนนั้นค่าดังกล่าวเป็น false อยู่แล้ว
    • แต่เมื่อเปลี่ยนเป็น true กลับผ่านการตรวจสอบ Browser Integrity Check ได้ และเข้าถึงซอฟต์แวร์ที่ต้องการตรวจสอบได้

การบล็อกบนเว็บไซต์ภายในที่ไม่เกี่ยวข้องกัน

  • วันถัดมา เมื่อพยายามเข้า หน้าเว็บภายในของบริษัท ที่จำเป็นต่อการทำงาน ก็มีหน้าบล็อกปรากฏขึ้น
  • ตามลำดับเหตุการณ์ ผู้เขียนไม่สามารถผ่าน Cloudflare check loop ได้ จากนั้นจึงเปลี่ยนค่าตั้งค่าความเป็นส่วนตัวของ Firefox หนึ่งรายการเพื่อหลีกเลี่ยงปัญหา และต่อมากลับถูกบล็อกบนอีกเว็บไซต์งานหนึ่งที่แยกจากกัน
  • กระบวนการทั้งหมดเกิดขึ้นบนอุปกรณ์ทำงานและหลัง VPN ของบริษัท
    • VPN ดังกล่าวต้องให้มีการติดตั้งใบรับรองความปลอดภัยเฉพาะบนอุปกรณ์ก่อนจึงจะเข้าได้
    • เนื่องจาก Cloudflare ร้องขอใบรับรองดังกล่าว จึงมองได้ว่า Cloudflare รับรู้การมีอยู่ของใบรับรองนี้
  • ผู้เขียนยกตัวอย่างข้อมูลยืนยันตัวตนที่แข็งแรงซึ่ง Cloudflare อาจใช้ได้ เช่น ใบรับรองความปลอดภัยรายบุคคลและ IP ของบริษัทหลัง VPN
    • ในบทความต้นฉบับตอนแรกกล่าวถึง MAC address แต่มีเชิงอรรถแก้ไขภายหลังว่า Cloudflare น่าจะเห็นเพียง IP หลัง VPN ของบริษัท ไม่ใช่ MAC address
  • ไม่มีการติดตั้งส่วนขยายเพิ่มเติม, ใช้ headless browser, เปลี่ยน user agent, ใช้ Tor หรือโปรโตคอลที่ไม่ปกติ สิ่งที่เปลี่ยนมีเพียงค่าตั้งค่าความเป็นส่วนตัวของเบราว์เซอร์หนึ่งรายการ
  • แม้จะเปลี่ยนค่ากลับเป็นค่าเดิม การบล็อกก็ยังไม่หายไป และการเข้าถึงทรัพยากรที่จำเป็นต่อการทำงานก็กลายเป็นเรื่องไม่แน่นอน

การคาดเดาสาเหตุของการบล็อกและการเปรียบเทียบกับ Chrome

  • เนื่องจาก secure connection loop ทำให้เบราว์เซอร์ร้องขอหน้าเดิมหลายครั้งภายในเวลาสั้น ๆ เป็นไปได้ว่า Cloudflare ตรวจจับความถี่สูงของการร้องขอและการถูกปฏิเสธนี้ว่าเป็นรูปแบบที่น่าสงสัย
    • ส่วนนี้ไม่ใช่ข้อสรุปแน่ชัด แต่เป็นคำอธิบายที่เป็นไปได้
    • ต่อมาแม้จะผ่านการเข้าครั้งแรกได้ด้วยการปรับการป้องกัน fingerprinting แต่ผู้เขียนมองว่า Cloudflare อาจตีความชุดเหตุการณ์ทั้งหมดว่าเป็นพฤติกรรมไม่พึงประสงค์และทำเครื่องหมายเบราว์เซอร์นี้ว่าไม่น่าไว้ใจ
  • เมื่อทดลองเข้าเว็บไซต์ภายในผ่าน Google Chrome กลับไม่ถูกบล็อก
  • ข้อเท็จจริงที่ว่า Firefox ถูกบล็อกแต่ Chrome ไม่ถูกบล็อก ทำให้ผู้เขียนสรุปว่าการบล็อกของ Cloudflare น่าจะอิงกับ browser fingerprint หรือการไม่มี fingerprint
    • ทั้งสองคำขอใช้ใบรับรองความปลอดภัยเดียวกัน, VPN ของบริษัทเดียวกัน, อุปกรณ์เดียวกัน และช่วงเวลาเดียวกัน
    • ความแตกต่างมีเพียงเบราว์เซอร์ที่ใช้
  • ผู้เขียนมองว่า Chrome ไม่มีการออกแบบด้านความเป็นส่วนตัวและการเสริมความปลอดภัยในระดับเดียวกับ Firefox และไม่ได้ต่อต้าน fingerprinting หรือบังคับให้ปรับค่ามากเท่ากัน

ผลกระทบต่อการทำงาน

  • ในระยะใกล้จำเป็นต้องใช้ Chrome เพื่อเข้าถึงเว็บไซต์งานภายใน
  • ไม่อาจรู้ได้ว่าเว็บไซต์ภายในและภายนอกที่ถูก “ปกป้อง” ด้วย Cloudflare จะถูกบล็อกเพิ่มอีกมากแค่ไหน
  • อาจลองติดตั้ง Firefox ใหม่ได้ แต่เพราะก่อนหน้านี้การแก้ปัญหาแบบคาดเดาทำให้สถานการณ์แย่ลง จึงไม่แน่ใจว่าควรทำอะไรต่อ
  • เนื่องจากไม่มีขั้นตอนที่ชัดเจนที่ผู้ใช้จะแก้เองได้ จึงอาจต้องค้นหาระบบผู้ดูแลที่รับผิดชอบหน้าเว็บนั้นจากไดเรกทอรีภายในบริษัทแล้วขอให้อนุญาตการเข้าถึง

ความกังวลต่อเว็บโดยรวม

  • แม้จะมีหลักฐานยืนยันตัวตนที่แข็งแรง หากพฤติกรรมหลุดจากสิ่งที่ระบบคาดไว้เพียงเล็กน้อยก็อาจถูกกันไม่ให้เข้าถึงทรัพยากรที่จำเป็นได้ และเรื่องนี้นำไปสู่ความกังวลต่ออนาคตของเว็บ
  • หาก remote attestation และมาตรการ “ความปลอดภัย” ถูกนำไปใช้กับด้านต่าง ๆ เช่น ธนาคารออนไลน์ ก็อาจส่งผลต่อเกือบทุกส่วนของชีวิตส่วนตัว
  • ผู้ใช้ Android แบบ de-Googled ต้องพยายามอย่างมากเพื่อให้ hardware attestation ทำงานถูกต้องสำหรับการใช้แอปธนาคาร
    • คู่มือ attestation compatibility ของ GrapheneOS เป็นตัวอย่างของกรณีเช่นนั้น
    • ผู้เขียนมองว่ามีพื้นที่ตรงกลางน้อยมากระหว่างการเข้าถึงเงินจากอุปกรณ์ส่วนตัวของตน กับการยอมให้ Google เฝ้าติดตามการโต้ตอบกับอุปกรณ์
  • ข้อเสนอเกี่ยวกับเว็บที่ให้อำนาจองค์กรซึ่งตรวจสอบความรับผิดได้ยากกว่าบุคคล อาจทำให้เกิดสถานการณ์ที่ผู้ใช้ต้องหลงทางอยู่กับกฎที่มองไม่เห็นมากขึ้น
  • เพิ่งไม่กี่ปีมานี้เองที่เริ่มมีการลงโทษบริษัทที่ละเมิดกฎหมายความเป็นส่วนตัวอย่างมีนัยสำคัญ และ ค่าปรับ Facebook 1.2 พันล้านยูโร จากการละเมิด GDPR ก็เป็นตัวอย่างหนึ่ง

คำถามที่ Web Integrity API และ passkeys ทิ้งไว้

  • ข้อเสนอ Web Integrity API เป็นข้อเสนอที่ก่อให้เกิดแรงต้านต่ออนาคตของเว็บ
    • หากบริษัทการเงินนำใช้นโยบาย remote attestation กับเว็บไซต์ บุคคลทั่วไปอาจถูกจำกัดมากขึ้นในชนิดของฮาร์ดแวร์ ระบบปฏิบัติการ และซอฟต์แวร์ที่สามารถใช้ได้
    • แม้อาจมีเหตุผลที่ชอบธรรมในการกันอุปกรณ์เก่าและมีช่องโหว่ที่แก้แพตช์ไม่ได้ แต่การตัดสินใจขององค์กรอาจไหลไปในทิศทางที่เพิ่มการควบคุมขององค์กรโดยแลกกับเสรีภาพหรือสิทธิของปัจเจก
  • ตัวอย่างแรกในข้อเสนอ Web Integrity API ยกกรณีเว็บไซต์ที่พึ่งรายได้โฆษณา ว่าผู้ลงโฆษณาควรจ่ายเงินได้อย่างมั่นใจว่าโฆษณาถูกดูโดยมนุษย์ ไม่ใช่หุ่นยนต์
    • ผลก็คือผู้ใช้ที่เป็นมนุษย์จริงกลับต้องเป็นฝ่ายแบกรับภาระในการพิสูจน์ว่าตนเป็นมนุษย์
    • ผู้เขียนยังตั้งคำถามด้วยว่าผู้เขียนข้อเสนอนี้สังกัด Google ซึ่งมีรายได้โฆษณามหาศาล
  • การนำ passkeys มาใช้ อาจเป็นข้อเสนอที่มีประโยชน์ เพราะช่วยให้การเข้าถึงเว็บไซต์ปลอดภัยขึ้นและง่ายขึ้น
    • อย่างไรก็ดี หากแม้แต่หลักฐานยืนยันตัวตนที่แข็งแรงก็ยังถูกมองข้ามได้อย่างในกรณี Cloudflare ก็ยากจะรู้ว่า passkeys จะถูกผู้ให้บริการอย่าง Cloudflare ปฏิบัติอย่างไร
  • ยังมีคำถามเชิงปฏิบัติอีกหลายข้อเกี่ยวกับ passkeys
    • ผู้ใช้จะสามารถสร้างและซิงก์ passkeys ได้ด้วยตนเองหรือไม่
    • หากมีเพียงซอฟต์แวร์บางชนิดที่ใช้ passkeys ได้ ใครเป็นผู้กำหนดเกณฑ์นั้น
    • จำเป็นต้องมีข้อกำหนดด้านฮาร์ดแวร์หรือซอฟต์แวร์เฉพาะอย่าง TPM, DeviceCheck, หรือ Integrity API หรือไม่
    • ผู้ใช้จะสามารถส่งออก passkeys จากผู้ให้บริการหนึ่งไปยังอีกรายได้ทุกเมื่อหรือไม่
    • หาก passkey เข้าไปเกี่ยวข้องกับเหตุการณ์น่าสงสัย สถานะน่าสงสัยนั้นจะแพร่ไปยังอุปกรณ์อื่นที่ใช้ passkey เดียวกันหรือไม่
    • และอุปกรณ์ที่มี passkeys น่าสงสัยจะถูกทำเครื่องหมายว่าเป็นเป้าสงสัยไปด้วยหรือไม่ จนกระทบต่อการเข้าถึงเว็บไซต์อิสระอื่น ๆ บนอุปกรณ์เดียวกัน
  • แม้รหัสผ่านจะมีข้อเสียมากมาย แต่ก็มีจุดแข็งตรงที่บุคคลสามารถสร้างขึ้นเอง สร้างบนอุปกรณ์ที่ตนมี และจัดการได้ตามวิธีที่ต้องการ
  • แม้เทคโนโลยีอย่าง VPN, ใบรับรอง, และ fingerprinting จะช่วยอุดจุดอ่อนของรหัสผ่านและความปลอดภัยของคอมพิวเตอร์ได้ แต่ถ้าการทำเรื่องพื้นฐานยังต้องแลกด้วยการสละความเป็นส่วนตัว และสุดท้ายก็ยังถูกบล็อกได้อยู่ ประโยชน์ของมันก็มีจำกัด

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

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

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

  • แม้แต่คนที่บอกว่าใส่ใจความเป็นส่วนตัว ก็มักใช้ Chrome โดยไม่รู้เรื่องนี้
    หน้าเว็บที่ถูกบล็อกใน Firefox กลับเปิดได้ใน Chrome แต่ Chrome ไม่ได้ถูกออกแบบให้เสริมความเป็นส่วนตัวและความปลอดภัยเหมือน Firefox อีกทั้งยังเก็บและแชร์ประวัติการท่องเว็บกับข้อมูลส่วนบุคคลมากกว่า และต้านทานการติดตามด้วยลายนิ้วมือได้น้อยกว่า
    ถ้าใช้ใบรับรองเดียวกัน, VPN บริษัทเดียวกัน, อุปกรณ์เดียวกัน, ช่วงเวลาเดียวกัน แต่แค่เปลี่ยนเบราว์เซอร์แล้วผ่านได้ ก็ดูเหมือนว่า Cloudflare กำลังบล็อกตาม ลายนิ้วมือของเบราว์เซอร์ หรือการไม่มีลายนิ้วมือ
    ถ้าทุกวันนี้ยังใส่ใจอะไรแม้แต่นิดเดียว ก็ไม่ควรใช้ Chrome

    • ผมไม่ใช่แฟน Google แต่ตรรกะที่ว่า “ผ่านได้เพราะ Chrome ให้ข้อมูลมากกว่า” ยังไม่น่าเชื่อถือเท่าไร
      ในสถานการณ์นี้ยังไม่ชัดเจนว่า Chrome ให้ข้อมูลอะไรที่ Firefox ไม่ให้ และอาจเป็นเพียงเพราะ Firefox เป็น user agent ที่พบได้น้อยกว่า จึงถูกกรองเข้มงวดกว่าก็ได้
      เคยเห็นกรณีที่เมื่อเปลี่ยนเบราว์เซอร์บนเว็บไซต์ ข้อความจำกัดความเร็วหายไป อาจเป็นไปได้ว่าด้วยข้อมูลที่มีจำกัด ระบบสันนิษฐานว่า IP เดียวกัน + user agent ต่างกัน = คอมพิวเตอร์คนละเครื่อง
      อย่างน้อยก็ควรทดสอบกับเบราว์เซอร์ตัวที่สามด้วย
    • ฮิวริสติก ที่พยายามแยกสิ่งที่เรียกว่า “บอต” กับ “มนุษย์” นั้นไม่เหมาะสม ตราบใดที่มนุษย์ยังถูกเข้าใจผิดว่าเป็นบอตและถูกบล็อก
      “ใช้ Chrome สิ” ไม่ใช่วิธีแก้ และคนที่ใช้ Firefox หรือซอฟต์แวร์อื่นที่ไม่ใช่ของ Google ก็ยังเป็นมนุษย์อยู่ดี
      วิธีตรวจสอบว่า “ไม่ใช่บอต” ด้วย JavaScript ดูเหมือนเป็นเครื่องมือบังคับให้ผู้ใช้เปิด JavaScript และเปิดตัวเองรับการแสดงโฆษณามากขึ้น
    • พูดว่าอย่าใช้ Chrome นั้นง่าย แต่พูดว่า อย่าใช้ Cloudflare นั้นยากกว่ามาก
      หากใช้เกณฑ์ว่าเป็นการผูกขาดตลาดและคุกคามอนาคตของอินเทอร์เน็ตแบบเปิด Cloudflare เป็นภัยคุกคามที่ใหญ่กว่า และทันทีที่ระบอบเผด็จการของ Cloudflare เปลี่ยนไปในทางที่เจตนาดีน้อยลง ทุกคนจะรู้สึกได้
    • ถ้าทุกวันนี้ยังใส่ใจอะไรแม้แต่นิดเดียว นอกจาก Chrome แล้วก็ไม่ควรใช้ Cloudflare ด้วย
    • เพิ่งเคยได้ยินเป็นครั้งแรกว่า “คนที่ใส่ใจความเป็นส่วนตัวใช้ Chrome กันเยอะ”

  • ผมเป็น PM ของแพลตฟอร์ม challenge ของ Cloudflare และอยากตรวจสอบสาเหตุของปัญหา
    เราไม่ได้ลงโทษผู้ใช้เพียงเพราะทำพฤติกรรมซ้ำ ๆ ดังนั้นเบราว์เซอร์จึงไม่น่าถูกแสดงว่าน่าสงสัยเพราะเรื่องนั้น
    ส่วนตัวใช้ Firefox อยู่มาก แต่ไม่เคยเห็นพฤติกรรมแบบนี้ และถ้าเป็นปัญหาทั่วทั้ง Firefox ระบบแจ้งเตือนอัตโนมัติก็คงดังขึ้นและถูกจัดการเป็นเหตุการณ์ร้ายแรงแล้ว
    ถ้าสนใจช่วยแก้ปัญหา ส่งอีเมลมาที่ amartinetti at cloudflare ได้

    • สาเหตุของปัญหาคือซอฟต์แวร์มี ข้อบกพร่องโดยการออกแบบ
      ที่อยู่ IP มีไว้ใช้สำหรับการกำหนดเส้นทางแพ็กเก็ต ไม่ใช่เอาไปให้ “คะแนนพฤติกรรม” ผู้ใช้เบื้องหลัง IP ของผมเมื่อวานอาจเป็น IP ของคนละคนโดยสิ้นเชิงก็ได้
      การใช้ลายเซ็น TLS มาตัดสินว่าใครเข้าถึงเว็บครึ่งหนึ่งได้ ไม่ได้แก้อะไรในระยะยาว มีแต่จะเสริมการผูกขาดเบราว์เซอร์ และขัดกับจิตวิญญาณของเว็บแบบเปิดอย่างจัง
      ผมรันบอตอย่าง crawler เป็นโปรเจกต์งานอดิเรก ก็มีส่วนทำให้เกิดเรื่องกับตัวเองอยู่บ้าง แต่ถ้าแค่เลียนแบบลายเซ็น TLS ของ Chrome ก็ยังใช้งานได้ เพื่อน ๆ ที่ไม่มีความรู้ทางเทคนิคและไม่ได้ทำอะไรเลยก็โดนการบล็อกครั้งนี้ไปด้วย
      มีความเป็นไปได้สูงที่บริการของ Cloudflare ทำให้คนหลายล้านคนได้รับผลกระทบจากการถูก บล็อกจากครึ่งหนึ่งของ WWW แบบกะทันหันในวันหนึ่ง และความเสียหายแบบนี้คือผลสืบเนื่องทางตรรกะของฮิวริสติกที่ใช้ตัดสินว่าจะให้เข้าถึงเว็บไซต์หรือไม่
      การที่บริษัทเดียวที่อยู่นอกประเทศของผมเป็นผู้ตัดสินว่าผมจะใช้งานเว็บได้หรือไม่ก็เป็นเรื่องน่าขัน และตอนนี้ผมต้องกลับไปหาซื้อพร็อกซีจากที่น่าสงสัยเพื่อให้ยังใช้ Firefox ต่อได้
    • ผมใช้ Firefox และช่วงหลังเห็นหน้าแทรก “ตรวจสอบว่าเป็นมนุษย์หรือไม่” ของ Cloudflare บ่อยขึ้น
      โดยปกติมันจบเองอัตโนมัติ จึงไม่ใช่เรื่องใหญ่ แต่รู้สึกได้ว่าความถี่เพิ่มขึ้นเมื่อสัปดาห์ที่แล้ว
    • ผมใช้ Firefox แต่ไม่รู้สึกว่าต้องแก้ CAPTCHA บ่อยขึ้น และแทบไม่เห็นหน้า “connection secure” เลย
      อาจเป็นเพราะส่วนขยาย Privacy Pass ที่ใช้อยู่ก็ได้ แต่จริง ๆ แล้วไม่ค่อยรู้ว่ามันทำอะไร
    • พร็อกซี IP ที่ใช้ประจำเกิดปัญหาเมื่อกรรมสิทธิ์ดาต้าเซ็นเตอร์เปลี่ยนจาก ARIN ไปเป็น RIPE
      ตำแหน่งจริงยังอยู่ที่ NYC แต่เมื่อเข้าเว็บไซต์ในสหรัฐฯ ที่ป้องกันด้วย Cloudflare กลับดูเหมือนมาจากสหราชอาณาจักร และถูกบล็อกจากที่ต่าง ๆ มากขึ้นเรื่อย ๆ เช่น หนังสือพิมพ์ท้องถิ่น ร้านขายของชำ บริษัทบัตรเครดิต
      ข้อมูลตำแหน่งทางภูมิศาสตร์ของ IPv6 ของ Cloudflare เสีย และดูเหมือนจะเข้ามาแทรกแซงแม้เชื่อมต่อผ่าน IPv4 ด้วย ตั้งแต่แรกแล้ว การตัดสินตามตำแหน่งทางภูมิศาสตร์ก็ไม่ใช่แนวคิดที่ดี
    • ถ้า route ทราฟฟิกผ่าน ProtonVPN จะเห็นอาการนี้ใน Firefox
      อาจเป็นเพราะผู้ใช้ VPN คนอื่นทำพฤติกรรมไม่ดี แต่ดูเหมือนมีความเป็นไปได้สูงกว่านั้น

  • ผมเคยเจอปัญหาเดียวกันเป๊ะอยู่พักหนึ่ง และสามารถค้นหา “just a moment” ในประวัติเบราว์เซอร์เพื่อหาว่าเว็บไหนที่เข้าไม่ได้
    https://gitlab.com/users/sign_in, https://steamdb.info/login/, https://www.zabbix.com/forum/, https://casetext.com/, https://namemc.com/login, https://spinroot.com/, https://camelcamelcamel.com/
    เป็นปัญหาที่ลากยาวมาหลายเดือน หรืออาจจะหลายปีแล้ว แต่ Cloudflare ดูเหมือนไม่แก้ และให้ความรู้สึกว่าไม่ชอบเว็บแบบเปิด พร้อมพยายามบังคับให้ Chrome/Chromium/Blink ครองตลาด

    • ถ้าคุณแชร์ rayID ที่เห็นใน challenge วนซ้ำแบบนี้ได้ ผมอยากลองตรวจสอบดู
      rayID ไม่มีข้อมูลระบุตัวตนส่วนบุคคล จึงเผยแพร่ต่อสาธารณะได้ หรือจะส่งอีเมลไปที่ amartinetti at cloudflare ก็ได้
      เรากำลังจะปล่อยกลไกการรายงานในเร็ว ๆ นี้ด้วย เพื่อให้ต่อไปสามารถแจ้งและรับมือกับปัญหาแบบนี้ได้รวดเร็ว
    • ผมก็เจอตลอดเหมือนกัน และเป็นมาหลายปีแล้ว แถมยิ่งเวลาผ่านไปก็ยิ่งแย่ลงอย่างเห็นได้ชัด
      ถ้าจะใช้เว็บ ก็ต้องจ่ายต้นทุนไม่ทางใดก็ทางหนึ่ง: ไม่ว่าจะเสียสิทธิ์เข้าถึงเพราะตั้งค่าความเป็นส่วนตัวเข้มงวด หรือยอมสละความเป็นส่วนตัว ไม่มีทางชนะเลย
    • ใน Waterfox ไม่เจอปัญหา แต่การที่ตอนนี้แค่จะเข้าเว็บไซต์ก็ยังต้องใช้ JavaScript นี่มันไร้สาระมาก
    • GitLab ก็เคยกันไม่ให้ล็อกอินเพราะ Cloudflare แม้ตอนที่ผมเป็นลูกค้าแบบเสียเงินก็ยังเป็นแบบนั้น
      ผมเลิกจ่ายเงินให้ด้วยเหตุผลอื่นแล้ว แต่ยังไงก็รู้สึกว่าเลิกได้ถูกทาง
    • ดูเหมือนผู้ใช้ต้องการให้ Chrome ครองตลาด และไม่สนใจเว็บแบบเปิดหรือ Firefox
      ทั้งที่เป็นเบราว์เซอร์อันดับหนึ่งบนเดสก์ท็อป โดยไม่ได้แถมมากับระบบปฏิบัติการด้วยซ้ำ—Windows มี Edge และ Mac มี Safari อยู่แล้ว แต่ผู้ใช้ก็ยังดาวน์โหลด Chrome เอง

  • เมื่อทราฟฟิกอินเทอร์เน็ตส่วนใหญ่ถูกควบคุมโดยแหล่งเดียว ปัญหาแบบนี้ก็จะตามมา
    แค่ Cloudflare ตัดสินตามอำเภอใจว่าใครใช้เน็ตได้หรือไม่ได้ คำตัดสินนั้นก็แทบจะกลายเป็นกฎหมายไปแล้ว
    ตอนแรกอาจเริ่มจากสมมติฐานใสซื่ออย่าง “วิธีง่าย ๆ ในการกันผู้ไม่หวังดี” แต่สุดท้ายก็ขยายไปเป็นเกณฑ์ตามอำเภอใจ
    ถ้าจะสนับสนุนความเป็นส่วนตัว ก็ต้อง ยอมให้คนไม่ดีเข้ามาได้ด้วย แต่ผู้ใช้อินเทอร์เน็ตทั่วไปไม่เข้าใจความละเอียดอ่อนนี้
    แม้ในกรณีที่ใสซื่อที่สุด commit ผิดเพียงอันเดียวก็ทำให้อินเทอร์เน็ตล่มได้ และเคยเกิดเรื่องแบบนั้นกับ Cloudflare แล้ว
    กฎหมายต่อต้านการผูกขาดมีอยู่ก็เพราะบริษัทอย่าง Cloudflare, Google, Meta แต่ดูเหมือนไม่มีผู้มีอำนาจคนไหนที่อยากใช้กฎหมายนั้นจริงจัง อีก 20 ปี อินเทอร์เน็ตจะต่างจากที่เราเคยเห็นมาทั้งหมดอย่างสิ้นเชิง และคงไม่ใช่การเปลี่ยนแปลงที่ดี

    • คุณไม่ใช่ลูกค้าที่จ่ายเงินให้ Cloudflare ลูกค้าคือเว็บไซต์ที่จ่ายเงินเพื่อปกป้องโครงสร้างพื้นฐานของตัวเอง
      ลูกค้าสามารถเลือกผู้ให้บริการ CDN/WAF ได้จากหลายเจ้า และ Cloudflare ก็ไม่ใช่รายที่ใหญ่ที่สุดด้วย Akamai ใหญ่กว่า
      CDN ที่เติบโตเร็วที่สุดคือ CloudFront และการแข่งขันก็ดูดีอยู่ ผมเลยไม่เข้าใจว่าทำไมกฎหมายต่อต้านการผูกขาดถึงควรเข้ามาเกี่ยว
    • ทุกคนลืมไปว่าเว็บไซต์แทบใช้งานไม่ได้เพราะ crawler และ bot
      เจ้าของเว็บเลือกใช้ Cloudflare เพื่อกันสิ่งเหล่านี้ ไม่ใช่ Cloudflare บังคับ
    • อินเทอร์เน็ตตอนนี้ก็แตกต่างจากอินเทอร์เน็ตเมื่อ 20 ปีก่อนโดยสิ้นเชิงอยู่แล้ว
    • ผมไม่คิดว่า Cloudflare มีส่วนแบ่งตลาดมากพอถึงขั้นก่อให้เกิดข้อกังวลด้านการผูกขาดเลย
    • การพูดถึงกฎหมายต่อต้านการผูกขาดจะสมเหตุสมผลก็ต่อเมื่อ Cloudflare ขัดขวางไม่ให้ย้ายไปใช้คู่แข่งเท่านั้น

  • ถ้าลองแกะดู session cookie หลายตัวของ Cloudflare, หน้าที่เรียกว่า “integrity gum” หรือสคริปต์แบบแทรกกลางทางที่ส่งมาในโหมด “super bot-fight” ฯลฯ จะเห็นว่าโดยพื้นฐานแล้วมันใช้ web worker ทำ การตรวจสอบความสมบูรณ์ของเบราว์เซอร์ แบบ heuristic
    กล่าวคือ มันรันชุดการทดสอบที่เบราว์เซอร์จริงซึ่งผู้ใช้ควบคุมจะผ่าน แต่ headless browser ที่ bot ควบคุมจะล้มเหลว
    เช่น วาดภาพลง canvas แล้ว export เป็น PNG เพื่อเทียบ hash ว่าเป็นเบราว์เซอร์จริงหรือเป็นแค่ HTML parser ดิบ ๆ หรือเช็กฟอนต์แปลกเฉพาะของ OS ผู้บริโภคที่มักขาดหายเมื่อรัน Puppeteer ในคอนเทนเนอร์เริ่มต้นของ Lambda/Cloud Function
    ไปไกลกว่านั้นก็อาจดูว่าการขยับเมาส์และการกดแป้นที่ไม่จำเป็นก่อนเปิด prompt ดูเหมือนความผิดพลาดของมนุษย์หรือไม่ และไม่คล้ายกับรูปแบบการเล่นซ้ำจากการบันทึกล่าสุดที่เคยเห็น
    ถ้าติดอยู่ในลูปตรวจสอบ ก็เป็นเพราะเบราว์เซอร์ อุปกรณ์ หรือส่วนขยายของคุณปิดบังหรือปิดใช้งานสัญญาณ heuristic เหล่านี้มากพอ จน Cloudflare ไม่ได้หลักฐานชัดเจนว่าคุณเป็นมนุษย์ และขึ้นอยู่กับการตั้งค่าของเจ้าของเว็บไซต์ ระบบอาจพยายามเก็บหลักฐานต่อไปแทนที่จะแจ้งว่าล้มเหลว
    เพราะถ้าบอก bot ว่าล้มเหลว ก็เท่ากับส่งสัญญาณว่า “หยุดใช้วิธีที่ใช้ไม่ได้ แล้วเปลี่ยนความถี่ของโล่เสีย”

    • จากมุมผู้ใช้ มันดูเหมือนแค่ เว็บไซต์พัง
      ไม่มี exception ในคอนโซล มีแต่หน้าเดิมโหลดซ้ำไปเรื่อย ๆ
    • ถ้า bot ติดอยู่ในลูป Cloudflare นาน 10 นาที ผมว่ามันเป็นสัญญาณค่อนข้างแรงว่ามีอะไรบางอย่างไม่ทำงาน
    • ถ้าอย่างนั้น ผมก็ไม่รู้จะอธิบายการบล็อกที่เกิดกับเบราว์เซอร์หรือแพลตฟอร์มที่ไม่ค่อยแพร่หลายได้อย่างไร

  • สิ่งที่บางครั้งถูกมองข้ามคือ เจ้าของไซต์ที่ใช้ Cloudflare เป็นคนกำหนดได้ว่าจะหวาดระแวงในระดับทั่วโลกแค่ไหน และยังสามารถสร้าง กฎ WAF ที่ละเอียดและดุดันมาก ๆ แยกต่างหากได้ด้วย
    ดังนั้นบางกรณี เจ้าของไซต์ตั้งกฎที่ดุดันเกินไป แต่ Cloudflare กลับเป็นฝ่ายโดนด่า ผลลัพธ์ที่ผู้ใช้ปลายทางเห็นมักเหมือนกัน
    ครั้งหนึ่งผมเคยสร้างกฎ WAF เพื่อบล็อกทราฟฟิก bot ที่ยังไม่ได้ยืนยันทั้งหมดจากดาต้าเซ็นเตอร์ใหญ่ ๆ อย่าง Google Cloud, OVH, DigitalOcean แต่กลายเป็นความผิดพลาด เพราะมีหลายบริษัทที่ด้วยเหตุผลบางอย่าง route ทราฟฟิกผ่าน ASN เหล่านั้น
    ผู้ใช้เหล่านั้นคงโกรธ Cloudflare แต่สาเหตุจริง ๆ คือผมตั้งค่าผิดเอง

  • ในคลาสเขียนโปรแกรมใช้ เบราว์เซอร์แบบง่าย เป็นตัวอย่าง ซึ่งไม่ประมวลผล CSS หรือ JavaScript ทำให้การแสดงผลค่อนข้างดิบ แต่ก็ใช้งานได้
    มันทำงานได้กับบางเว็บไซต์ แต่โดยเฉพาะเว็บใหญ่ ๆ มักมองว่าเป็นเบราว์เซอร์ที่ไม่รู้จักและปฏิเสธการส่งคอนเทนต์ให้ ดูเหมือนจะคิดว่าเป็นบอต
    ต่อให้เป็นบอต ถ้ามันทำงานอย่างสุภาพก็ไม่เห็นว่าปัญหาคืออะไร และอดสงสัยไม่ได้ว่าเรายอมให้บริษัทเทคยักษ์ใหญ่สร้างเว็บแบบปิดเช่นไรขึ้นมา

    • เว็บไซต์มีสิทธิ์ตัดสินใจเองว่าจะตอบสนองต่อคำขอหรือไม่
      ไม่มีหน้าที่ต้องให้บริการทุกคน
    • ในมุมของการเล่นบททนายปีศาจ ก็สงสัยว่าเหตุใดเซิร์ฟเวอร์จึงไม่ควรมีสิทธิ์ตัดสินใจว่าจะคุยกับไคลเอนต์ตัวใด

  • น่าหงุดหงิดเหมือนกันที่หน้าตรวจสอบของ Cloudflare ทำให้การรีเฟรชหน้าใน Firefox พัง
    เมื่อ Cloudflare ส่งกลับไปยังหน้าเดิม มันจะนำทางด้วย POST โดย POST ครั้งแรกถูก Cloudflare ดักไว้ แต่พอรีเฟรชหน้า POST นั้นจะไปถึงหน้าจริง และหน้านั้นก็มักไม่รู้ว่าต้องทำอะไร จึงมีแนวโน้มจะแสดงข้อผิดพลาด
    วิธีแก้มีแค่กด Enter ในแถบที่อยู่เพื่อไปที่หน้านั้นใหม่แทนการรีเฟรช หรือหาลิงก์สำหรับกลับไปยังหน้านั้น
    ถ้าโดนบางเว็บบล็อกเพราะ POST แบบนั้นก็ไม่น่าแปลกใจ เว็บอาจตัดสินว่า “ทั้งที่รู้ว่าไม่ควร POST ไปหน้านั้นแต่ก็ยังส่งมา งั้นคงเป็นบอตอันตรายที่พยายามแฮ็ก”

  • จำนวนครั้งที่ Cloudflare ทำให้ต้องเจอหน้า “checking your connection” นาน 15–30 วินาที นั้นมากจนไม่สมเหตุสมผล
    สำหรับคนที่ใช้ชีวิตกับ ADHD อย่างผม/ฉัน ความล่าช้าและการรบกวนแบบนี้ที่สะสมทั้งวันอาจส่งผลกระทบรุนแรงได้
    แม้จะกินยาอย่างเหมาะสมแล้ว มาตรการนี้ก็ยังทำให้รู้สึกหมดแรงจริง ๆ และทำให้ประสบการณ์ออนไลน์เลวร้ายและสิ้นเปลืองพลัง

    • โดยปกติสิ่งนั้นจะถูกเปิดใช้กับเว็บที่กำลังโดน การโจมตี DDoS อย่างหนัก
      ไม่มีใครอยากให้ผู้ใช้เห็นมัน แต่บางครั้งก็จำเป็นต้องใช้
    • ไม่ใช่ Cloudflare เป็นคนสั่งให้ทำ แต่เป็นลูกค้าที่ใช้ Cloudflare ตั้งค่าไว้แบบนั้น
    • Privacy Pass ของ Cloudflare อาจช่วยได้: https://privacypass.github.io/
      มันจะช่วยลดจำนวน CAPTCHA ที่ต้องเจอได้มาก โดยใช้วิธีที่ไม่เลวร้ายต่อความเป็นส่วนตัวนัก
      ใน Safari สามารถเปิด Private Access Tokens ได้: https://blog.cloudflare.com/how-to-enable-private-access-tok...
      ทั้งสองวิธีคล้ายกับข้อเสนอเว็บ DRM ของ Google ตรงที่มีผู้ออกภายนอกเป็นผู้สร้างโทเคน แต่ต่างจากความพยายามของ Google ตรงที่ไม่ได้รับประกันให้หน้าที่ต้องการใช้โทเคนรู้ว่าตัวบล็อกโฆษณาถูกปิดอยู่

  • เพิ่งรู้เมื่อวานนี้เองว่า การเข้าสู่ระบบ PayPal ใช้กับ Safari หรือ Firefox ไม่ได้ และใช้ได้เฉพาะเบราว์เซอร์ที่อิง Chromium เท่านั้น
    เรากำลังถลำลึกขึ้นเรื่อย ๆ สู่ยุค “เว็บไซต์นี้ปรับแต่งมาสำหรับ Google Chrome”

    • Twitch ก็มีปัญหานี้เช่นกัน
      ถ้าเปิดการป้องกันการติดตามด้วยลายนิ้วมือใน Firefox ก็จะล็อกอินไม่ได้ และดูเหมือนว่าการยืนยันตัวตนสองขั้นตอนอย่างเดียวจะยังไม่เพียงพอสำหรับการปกป้องบัญชี
      ถ้าไม่อนุญาตให้ Twitch ระบุคอมพิวเตอร์ของฉันแบบไม่ซ้ำใคร ก็ไม่ยอมให้ล็อกอิน ผม/ฉันเลยเลิกดูสตรีม Twitch ไปเลย
    • เจอปัญหา PayPal มาพักหนึ่งแล้ว
      เป็นแบบนี้ทั้ง Firefox บน Windows, Linux และ Android โชคดีที่ในแอปยังล็อกอินค้างอยู่ แต่เพราะเข้า PayPal ผ่าน Firefox ไม่ได้ เลยเคยต้องจ่ายด้วยบัตรเครดิตทั้งที่มีเงินคงเหลือใน PayPal