เปิดตัว Have I Been Pwned 2.0

• การรีแบรนด์ HIBP ที่เตรียมมานานได้ถูกเปลี่ยนมาเป็นบริการจริงแล้ว พร้อมเปิดตัวการสร้างเว็บไซต์ใหม่ทั้งหมดและการ ปรับปรุงฟังก์ชัน แทบทุกหน้า
• การค้นหาหลักปรับปรุงประสบการณ์การแสดงผลลัพธ์ แต่บนเว็บไซต์ได้เอาการค้นหาด้วย username และ phone number ออกไป ขณะที่ยังคงความเข้ากันได้กับ API เดิม
• หน้าเฉพาะของแต่ละเหตุข้อมูลรั่วไหลแบบใหม่ช่วยให้ผลการค้นหาซับซ้อนน้อยลง และแยก คำแนะนำการรับมือที่เป็นรูปธรรม ซึ่งผู้ใช้สามารถทำได้หลังเกิดเหตุ ไปไว้ในหน้าต่างหาก
• ฟังก์ชันที่ต้องตรวจสอบสิทธิ์การเข้าถึงอีเมลถูกรวมไว้ใน แดชบอร์ดแบบ Sign In และ domain search ทำงานได้เร็วขึ้นด้วย JSON API และการกรองฝั่งไคลเอนต์
• สแตกเทคโนโลยีถูกจัดระเบียบโดยมี Azure, Cloudflare, .NET 9.0, Bootstrap และ TypeScript เป็นแกนหลัก พร้อมเอา Google reCAPTCHA ออกและใช้เฉพาะ Cloudflare Turnstile

---

เว็บไซต์ใหม่และประสบการณ์การค้นหา

• เปิดตัว เว็บไซต์ Have I Been Pwned ใหม่
  • คอมมิตแรกของงานรีแบรนด์ใน repository สาธารณะเกิดขึ้นในเดือนกุมภาพันธ์ 2024
  • แบรนด์ใหม่ soft launch ในเดือนมีนาคม 2025
  • รีลีสครั้งนี้รวมถึงการสร้างเว็บไซต์ใหม่ทั้งหมด การเปลี่ยนแปลงฟังก์ชันของแทบทุกหน้า การเพิ่มฟีเจอร์ใหม่ และการเปิดตัวร้านสินค้า
• กล่องค้นหาหลักยังคงเป็นฟีเจอร์เด่นของ HIBP แต่เปลี่ยนวิธีแสดงผลลัพธ์
  • ผู้ใช้บางส่วนจะเห็นการตอบสนองแบบแสดงความยินดีและแอนิเมชัน confetti
  • หากตรวจพบว่ามีข้อมูลรั่วไหล จะแสดงคำตอบสีแดงที่สุขุมกว่า
  • ผลลัพธ์อยู่ในรูปแบบ timeline ที่เลื่อนได้ตามลำดับเวลาย้อนกลับ พร้อมให้ภาพรวมของแต่ละเหตุข้อมูลรั่วไหล
• การค้นหาบนเว็บไซต์เอาการรองรับ username และ phone number ออกไป
  • การค้นหาด้วย username ถูกนำเข้ามาเพื่อรองรับ Snapchat incident ในปี 2014
  • การค้นหาด้วย phone number ถูกนำเข้ามาเพื่อรองรับ Facebook incident ในปี 2021
  • ข้อมูลสองประเภทนี้ไม่เคยถูกโหลดในกรณีอื่นนอกจากสองกรณีนั้น
  • username ระบุเจ้าของได้ยาก และ phone number ก็ parse ได้ยากเพราะรูปแบบสากลและการเขียนที่แตกต่างกัน
  • การแจ้งเตือนทาง SMS มีต้นทุนสูงกว่าอีเมลมาก
  • การที่เว็บไซต์เดิมอนุญาตให้ป้อนข้อมูลเหล่านี้ทำให้เกิดความสับสนและภาระงานซัพพอร์ต เช่น “ทำไมเบอร์ของฉันถึงไม่อยู่ในเหตุข้อมูลรั่วไหลนั้น”
  • ใน API จะยังรองรับต่อไปเพื่อรักษาความเข้ากันได้ แต่ระบุว่าไม่ควรคาดหวังว่าจะมีข้อมูลเพิ่มเติมเข้ามา

หน้าเฉพาะของเหตุข้อมูลรั่วไหล

• breach page แบบใหม่แยกรายละเอียดของแต่ละเหตุข้อมูลรั่วไหลออกไปเป็นหน้าต่างหาก เพื่อลดปัญหาที่ผลการค้นหาหลักซับซ้อนเกินไป
  • ตัวอย่างคือ Ashley Madison breach page
  • แสดงข้อมูลเดิมในรูปแบบที่เป็นมิตรต่อผู้ใช้มากขึ้น
• การเปลี่ยนแปลงสำคัญของหน้านี้คือการให้คำแนะนำที่เป็นรูปธรรมมากขึ้นว่าผู้ใช้ควรทำอะไรหลังเกิดเหตุข้อมูลรั่วไหล
  • โฟกัสที่ผู้ใช้ซึ่งได้รับผลกระทบควรทำอย่างไร
  • รวมถึงแนวทางการเชื่อมกับบริการพาร์ตเนอร์ เช่น identity protection provider
• มีแผนเพิ่มข้อมูลของเหตุข้อมูลรั่วไหลและข้อมูลเฉพาะผู้ใช้ให้มากขึ้นในอนาคต
  • หากบริการนั้นรองรับ 2FA จะแสดงข้อมูลนี้อย่างเจาะจงแทนคำแนะนำทั่วไป
  • จะเพิ่ม passkey เป็นส่วนแยกต่างหากด้วย
  • การหารือกับ NCSC ของสหราชอาณาจักรครอบคลุมคู่มือข้อมูลรั่วไหลแบบ localized ที่จะแสดงโลโก้ NCSC และแหล่งข้อมูลคำแนะนำที่เกี่ยวข้องให้ผู้ใช้ในสหราชอาณาจักร

แดชบอร์ดรวมและการค้นหาโดเมน

• เมื่อฟังก์ชันที่ต้องยืนยันสิทธิ์เข้าถึงที่อยู่อีเมลเพิ่มขึ้นตลอดหลายปี จึงถูกรวมไว้ใน central dashboard เดียว
  • ในเหตุการณ์ Ashley Madison ปี 2015 มีการนำแนวคิด sensitive breach เข้ามา ทำให้ต้องยืนยันผ่านการรับอีเมล
  • ในปี 2019 มีการเพิ่มชั้นการยืนยันตัวตนให้ API เพื่อลดการใช้งาน API ในทางที่ผิด และกำหนดให้ยืนยันอีเมลก่อนซื้อ API key
  • หลังจากนั้นจึงเพิ่ม domain search dashboard, การจัดการ subscription แบบเสียเงิน และการดู stealer logs
• แดชบอร์ดใหม่จะตรวจสอบสิทธิ์เข้าถึงที่อยู่อีเมลหลัง Sign In เพียงครั้งเดียว แล้วจึงแสดงฟังก์ชันที่เกี่ยวข้อง
  • รวมทั้งฟังก์ชันสำหรับคนทั่วไปและฟังก์ชันเชิงธุรกิจ
  • มีแผนเพิ่มการรองรับ passkey เพื่อให้ล็อกอินได้โดยไม่ต้องส่งอีเมลในอนาคต
  • ฟังก์ชันลงทะเบียนอีเมลของคนในครอบครัวเพื่อรับการแจ้งเตือน แต่ให้การแจ้งเตือนส่งไปอีกที่อยู่หนึ่ง ก็ถูกยกเป็นตัวอย่างที่เหมาะกับแดชบอร์ดนี้
• domain search มีการปรับหน้าจอให้เรียบร้อยขึ้นและปรับปรุงการกรองจำนวนมาก
  • รายการโดเมนที่ยืนยันแล้วดูสะอาดตาขึ้น
  • ผลการค้นหาให้สรุปที่ชัดเจนขึ้น
  • เพิ่มการกรองตามที่อยู่อีเมลและตัวกรอง “ดูเฉพาะ latest breach”
• แดชบอร์ดค้นหาโดเมนรับ JSON จาก API และทั้งแดชบอร์ดทำงานเหมือน single-page app
  • การกรองทำที่ ฝั่งไคลเอนต์ โดยใช้ domain search JSON ทั้งหมด
  • ทดสอบแล้วว่าสามารถทำงานได้แม้กับโดเมนที่มีที่อยู่อีเมลรั่วไหลมากกว่า 250,000 รายการ
  • อย่างไรก็ดี ข้อมูลขนาดนั้นเหมาะที่จะรับผ่าน API มากกว่าการเลื่อนดูในเบราว์เซอร์
• การยืนยันความเป็นเจ้าของโดเมนก็ถูกเขียนใหม่ทั้งหมด
  • เปลี่ยนเป็นอินเทอร์เฟซที่สะอาดและเรียบง่ายขึ้น
  • วิธีตรวจสอบนอกเหนือจากอีเมลยังมีงานที่ต้องทำให้ลื่นไหลขึ้นอีก

เอกสาร API และร้านสินค้า

• ตัว API เองไม่มีการเปลี่ยนแปลง
  • อัปเดตครั้งนี้ไม่ทำให้เกิด การเปลี่ยนแปลงที่ทำลายความเข้ากันได้
  • ผู้ใช้ API เดิมจะไม่มีส่วนที่พัง
• เอกสาร API ยังไม่สามารถเปลี่ยนไปใช้แนวทางใหม่ได้ จึงคงเอกสารเดิมไว้
  • มีการพูดคุยเรื่องวิธีจัดทำเอกสาร API ใน UX rebuild GitHub repo และฉันทามติทั่วไปคือ OpenAPI
  • มีการทำงานโดยใช้ Scalar และดูได้ที่ haveibeenpwned.com/scalar
  • Scalar มีตัวอย่างหลายภาษาและ test runner ในเบราว์เซอร์
  • เนื่องจากทำไม่ทันในกำหนดการเปิดตัวใหญ่ จึงคง เอกสาร API เดิม ไว้โดยปรับให้เข้ากับสไตล์เว็บไซต์ใหม่
  • หากมีเวลาว่างในอนาคต มีแผนเปลี่ยนไปใช้ implementation ของ Scalar
• ร้านสินค้า HIBP เปิดตัวที่ merch.haveibeenpwned.com
  • ดำเนินการผ่าน Teespring
  • สินค้าทั้งหมดขายในราคาทุนและไม่ทำกำไร
  • จัดทำขึ้นเป็นการทดลองสนุก ๆ สำหรับชุมชน
• สำหรับสติกเกอร์ เนื่องจากตัวเลือกของ Teespring ยังคุณภาพไม่ถึง Sticker Mule เดิม จึงยังใช้ Sticker Mule store ต่อไป
  • ยังมี open source artwork ให้สามารถนำไปพิมพ์เองได้จากที่ที่ต้องการ

สแตกเทคโนโลยีและประสิทธิภาพ

• บริการต้นทางยังคงรันบน Microsoft Azure
  • เว็บไซต์ใช้ App Service
  • API ส่วนใหญ่ใช้ serverless Functions
  • ใช้ความสามารถของ storage account เช่น SQL Azure Hyperscale, queues, blobs และ tables
  • โค้ดส่วนใหญ่เป็น C# และใช้ .NET 9.0 กับ ASP.NET MVC on .NET Core
• Cloudflare ยังคงมีบทบาทสำคัญ
  • มีโค้ดจำนวนมากอยู่บน Workers
  • มีข้อมูลอยู่ใน R2 storage
  • ใช้ WAF และความสามารถด้าน caching
  • anti-automation ใช้เฉพาะ Cloudflare Turnstile และเอา Google reCAPTCHA ออกทั้งหมด
• ฟรอนต์เอนด์ใช้ Bootstrap รุ่นใหม่, SASS และ TypeScript
  • CSS เขียนด้วย SASS
  • JavaScript เขียนด้วย TypeScript
• ประสิทธิภาพเว็บไซต์ก็มีการปรับปรุงที่วัดได้
  • ตามการทดสอบของ Pingdom ลดขนาดหน้าเว็บลง 28%
  • ลดจำนวน request ลง 31%
  • เวลาโหลดมีความผันผวนสูง จึงไม่สรุปว่าต่างกันมาก
  • เน้นว่าแม้ผ่านไป 11 ปี ก็ยังลดขนาดหน้าเว็บและจำนวน request ได้เป็นสัดส่วนสองหลัก
• ไม่ใส่องค์ประกอบที่อาจมองว่าเป็นภาระจากการติดตามหรือโฆษณา
  • สถิติทราฟฟิกจริงอ้างอิงจากทราฟฟิกที่ผ่าน Cloudflare edge node
  • 1Password product placement มีเพียงข้อความและรูปภาพ
  • ไม่ติดตาม outbound click ด้วย
  • การเจรจา product placement กับบริษัท identity theft ที่คาดหวังตัวเลขการติดตามเชิงรุกจึงยากขึ้น

การใช้ AI ในกระบวนการพัฒนา

• มีการใช้ ChatGPT อย่างกว้างขวางในกระบวนการสร้างใหม่ โดยเฉพาะช่วงไม่กี่วันสุดท้าย
  • ใช้ช่วยหาไอคอนใน Bootstrap icons ที่เหมาะกับหัวข้อ “Index”
  • ใช้ในลักษณะค้นหาไอคอนที่เหมาะสมจากไอคอนมากกว่า 2,000 รายการได้ภายในประมาณ 30 วินาที
• ใช้ AI ในการตรวจสอบการย้ายเว็บไซต์ด้วย
  • ให้เขียน PowerShell script เพื่อ crawl haveibeenpwned.com แล้วแสดง URL ที่ไม่ซ้ำกัน
  • ให้เขียน script เพื่อตรวจสอบว่า path ที่พบมีอยู่บน stage.haveibeenpwned.com หรือไม่
  • ช่วยพบไฟล์ security.txt ที่ตกหล่น
  • ยังพบรายการที่ไม่เคยมีอยู่จริงด้วย จึงต้อง “trust, but verify”
• ยังใช้กับงานเล็ก ๆ เช่น คำแนะนำ CSS, การตั้งค่า Cloudflare rule และจุดเฉพาะของ .NET Core web app
  • ประเมินว่าสัดส่วนคำตอบที่ถูกต้องอยู่ที่ประมาณ 90%
  • กล่าวในเชิงบวกอย่างหนักแน่นถึงขั้นว่า หากไม่ได้ใช้ AI อย่างจริงจังในการพัฒนาซอฟต์แวร์ ก็ถือว่ากำลังทำผิดทาง

การเปิดตัวและปัญหา Turnstile

• เว็บไซต์ใหม่ถูก deploy ในช่วงเช้ามืดวันอาทิตย์ตามเวลาของผู้เขียน
  • แทบทุกอย่างเป็นไปด้วยดี และ glitch เล็ก ๆ หนึ่งหรือสองจุดได้รับการแก้ไขและ deploy อย่างรวดเร็ว
  • บทความถูกเผยแพร่หลัง live ไปแล้ว 2 วัน เพื่อเก็บปัญหาให้ได้มากที่สุดก่อน
  • ระหว่างนั้นมีการปล่อยรีลีสใหม่มากกว่า 12 ครั้งเพื่อ iterate และปรับปรุงอย่างรวดเร็ว
• การเปลี่ยนแปลงเล็ก ๆ อย่างข้อกำหนดการใช้งานและนโยบายความเป็นส่วนตัวก็ใช้เวลามาก
  • ต้องสะท้อนการอัปเดตเล็ก ๆ ในวิธีจัดการข้อมูลและบริการใหม่อย่าง stealer logs
  • การทำงานกับทนายใช้เวลาหลายชั่วโมงและเงินหลายพันดอลลาร์
• Cloudflare Turnstile เป็นวิธี anti-automation ที่ไม่ส่งทราฟฟิกไปยัง Google แบบ Google reCAPTCHA
  • สามารถ implement ให้มองไม่เห็นโดยสมบูรณ์ได้
  • ในเบราว์เซอร์ Cloudflare script จะสร้าง challenge และส่งไปพร้อม HTTP request จากนั้นตรวจสอบฝั่งเซิร์ฟเวอร์
  • HIBP ใช้งานในรูปแบบใดรูปแบบหนึ่งมาตั้งแต่ปี 2023
• ในจุดที่การกันบอทสำคัญ เช่น ฟอร์มส่งอีเมล หาก Turnstile ล้มเหลวจะแสดงคำแนะนำให้ผู้ใช้ลองอีกครั้งหรือรีเฟรชหน้า
  • หลายครั้งแก้ได้ด้วยการคลิกครั้งที่สองหรือ reload หน้า
  • หากยังไม่แก้ได้ อาจต้องพิจารณา implementation ของ Turnstile widget ที่มองเห็นชัดขึ้นและต้องให้ผู้ใช้โต้ตอบ
• Turnstile ยังถูกใช้สำคัญในหน้าค้นหาหลักด้วย
  • ส่ง request แบบ asynchronous ไปยัง API endpoint พร้อม challenge token
  • หาก challenge ล้มเหลวและ HIBP endpoint ส่ง HTTP 401 พร้อม Invalid Turnstile token กลับมา ต้อง fallback เป็น full page post
  • ตอนเปิดตัวเว็บไซต์ใหม่ครั้งแรก fallback นี้ยังไม่ทำงาน แต่แก้ไขแล้วในภายหลัง
  • ใน full page post จะแสดง Cloudflare managed challenge ซึ่งรุกล้ำมากกว่าแต่เชื่อถือได้มากกว่า
• ตามสถิติของ Cloudflare challenge ที่ออกไปประมาณ 82% ถูกแก้สำเร็จ
  • ใน 18% ที่แก้ไม่สำเร็จ จำนวนมากอาจเป็นบอทที่ Turnstile บล็อกตามที่ตั้งใจ
  • request จากคนจริงที่ถูกบล็อกอาจอยู่ในระดับตัวเลขหลักเดียวเป็นเปอร์เซ็นต์ และยังต้องหาวิธีลดตัวเลขนี้ต่อไป