การยืนยันตัวตนด้วย Privacy Pass สำหรับ Kagi Search

 (blog.kagi.com)
2 คะแนน โดย GN⁺ 2025-02-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Kagi Search ได้นำ การยืนยันตัวตนด้วย Privacy Pass มาใช้ เพื่อตรวจสอบสิทธิ์การค้นหาแบบเสียเงิน โดยไม่เชื่อมโยงคำขอค้นหากับบัญชีโดยตรง
  • วิธีนี้แยก การสร้างโทเค็น ออกจาก การใช้โทเค็น ทำให้ Kagi ตรวจสอบความถูกต้องได้ แต่ไม่สามารถย้อนรอยผู้ใช้หรือเวลาที่สร้างได้จากโทเค็นเพียงอย่างเดียว
  • กลุ่มแรกที่รองรับคือแผน Professional, Ultimate, Family, Team ซึ่งมีการค้นหาไม่จำกัด ส่วน Trial และ Starter ที่มีการจำกัดจำนวนการค้นหายังไม่รองรับ เนื่องจากยังมีปัญหาเรื่องโทเค็นสูญหายและการใช้งานเกินโควตา
  • ใช้งานได้โดยตรงใน Orion, แอป Kagi Android และส่วนขยาย Chrome·Firefox ส่วน Safari ยังไม่รองรับเนื่องจากข้อจำกัดของ API ส่วนขยาย
  • แม้โทเค็นเพียงอย่างเดียวจะทำให้เชื่อมโยงการค้นหากับบัญชีได้ยาก แต่ยังมีช่องทางข้างเคียง เช่น ที่อยู่ IP·ฟิงเกอร์พรินต์ของเบราว์เซอร์·รูปแบบการค้นหาซ้ำๆ จึงแนะนำให้ใช้ Tor หรือ VPN

การยืนยันตัวตนด้วย Privacy Pass ที่เพิ่มเข้ามาใน Kagi Search

  • Kagi ได้นำการยืนยันตัวตนด้วย Privacy Pass มาใช้กับ Kagi Search พร้อมเปิดตัว Tor onion service ด้วย
  • Privacy Pass เป็นโปรโตคอลยืนยันตัวตนที่ให้ไคลเอนต์พิสูจน์สิทธิ์การเข้าถึงได้ โดยไม่ทำให้เซิร์ฟเวอร์ระบุได้ว่าผู้ใช้คนใดกำลังเชื่อมต่อ
  • Kagi ในฐานะเครื่องมือค้นหาแบบเสียเงินจำเป็นต้องตรวจสอบสิทธิ์การค้นหา แต่ฟีเจอร์นี้เพิ่มหลักประกันเชิงเทคนิคว่าจะไม่เชื่อมโยงคำขอค้นหากับบัญชีใดบัญชีหนึ่ง
  • การพัฒนาอ้างอิงจาก การพัฒนา Privacy Pass ด้วย Rust ของ Raphael Robert เป็นจุดตั้งต้น และเปิดเผยโค้ดไว้ที่ kagisearch/privacypass-extension

แผนและไคลเอนต์ที่รองรับ

  • Privacy Pass ให้บริการก่อนกับผู้ใช้แผนค้นหาไม่จำกัด ได้แก่ Professional, Ultimate, Family, Team
  • แผน Trial และ Starter ยังไม่รองรับในตอนนี้
    • ทั้งสองแผนมีการจำกัดจำนวนการค้นหารายเดือน
    • หากโทเค็นที่สร้างไว้สูญหาย เช่น จากการลบส่วนขยาย ประสบการณ์ผู้ใช้อาจแย่ลง
    • Kagi ไม่สามารถรู้บัญชีหรือแผนในขณะใช้โทเค็นได้ จึงอาจทำให้ตามทฤษฎีสามารถใช้โทเค็นได้มากกว่าจำนวนการค้นหาที่อนุญาต
  • ไคลเอนต์ที่รองรับมีดังนี้
  • ผู้ใช้ที่ใช้ส่วนขยาย Kagi Search เดิมอยู่ ควรอัปเดตเป็นเวอร์ชันล่าสุดหรือปิดใช้งานเพื่อหลีกเลี่ยงปัญหาความเข้ากันได้
    • Firefox คือ 0.7.6
    • Chrome คือ 1.2.2.5

โฟลว์การยืนยันตัวตนของ Privacy Pass

  • Privacy Pass แบ่งการยืนยันตัวตนออกเป็นสองขั้นตอนคือ การสร้างโทเค็น และ การใช้โทเค็น
  • ในขั้นตอนการสร้างโทเค็น ผู้ใช้พิสูจน์สิทธิ์ในการสร้างโทเค็นด้วยคุกกี้เซสชันของ Kagi
    • จากมุมมองของเซิร์ฟเวอร์ โทเค็นที่สร้างขึ้นจะแยกไม่ออกจากโทเค็นแบบสุ่ม
    • โทเค็นไม่สามารถถูกติดตามย้อนกลับไปยังผู้ใช้ที่สร้าง หรือไปยังโทเค็นอื่นที่ผู้ใช้คนเดียวกันสร้างได้
  • เมื่อส่งคำขอค้นหา จะส่งโทเค็นที่สร้างไว้ล่วงหน้า 1 รายการเพื่อพิสูจน์สิทธิ์การเข้าถึง
    • เซิร์ฟเวอร์ตรวจสอบได้เพียงว่าโทเค็นนั้นเคยถูกสร้างขึ้นอย่างถูกต้อง
    • ไม่สามารถเชื่อมโยงโทเค็นกับขั้นตอนการสร้างใดขั้นตอนหนึ่งได้
  • โทเค็นเป็นแบบ ใช้ครั้งเดียว
    • เซิร์ฟเวอร์ติดตามโทเค็นที่ใช้แล้วเพื่อป้องกันการใช้ซ้ำ
    • ไคลเอนต์เองก็ไม่ควรส่งโทเค็นเดียวกันสองครั้ง เพื่อไม่ให้ขั้นตอนการใช้ที่ต่างกันถูกเชื่อมโยงกัน
  • โทเค็นมีอายุใช้งานคงที่ หากเก่าเกินไปต้องสร้างใหม่

โมเดลการใช้งานของ Kagi และคุณสมบัติด้านความปลอดภัย

  • โมเดลการ deploy ของ Kagi เป็นไปตามโครงสร้าง Shared Origin, Attester, Issuer ของมาตรฐาน Privacy Pass
    • Kagi ทำหน้าที่เป็น Attester, Issuer และ Origin ทั้งหมด
    • ผู้ใช้ทำหน้าที่เป็นไคลเอนต์ผ่านส่วนขยายเบราว์เซอร์ Privacy Pass หรือการรองรับในตัวของ Orion
  • หลังติดตั้งและเป็นระยะหลังจากนั้น ส่วนขยายจะสร้างและจัดเก็บโทเค็นจำนวนมาก
  • ผู้ใช้สามารถเลือกด้วย toggle ว่าจะยืนยันตัวตนด้วยคุกกี้เซสชันเดิม หรือด้วยโทเค็น Privacy Pass เมื่อค้นหา
  • คุณสมบัติที่ปกป้องผู้ใช้มีสามข้อ
    • การไม่เชื่อมโยงระหว่างการสร้างกับการใช้: Kagi ไม่สามารถเชื่อมโยงโทเค็นที่ส่งตอนค้นหากับขั้นตอนการสร้างโทเค็นใดโดยเฉพาะ
    • การไม่เชื่อมโยงระหว่างการใช้กับการใช้: Kagi ไม่สามารถรู้จากโทเค็นเพียงอย่างเดียวว่าการค้นหาสองครั้งต่างกันมาจากผู้ใช้คนเดียวกันหรือไม่
    • การป้องกันการขโมยการใช้งาน: ผู้ดักฟังที่สังเกตกระบวนการสร้างโทเค็น ไม่สามารถใช้ข้อมูลนั้นเพียงอย่างเดียวเพื่อขโมยโทเค็นไปใช้ได้
  • ยังมีคุณสมบัติที่ปกป้อง Kagi ด้วย
    • โทเค็นที่สร้างอย่างถูกต้องจะผ่านการตรวจสอบของ Kagi
    • ไคลเอนต์ที่ประสงค์ร้ายไม่สามารถปลอมโทเค็นที่ถูกต้องใหม่ได้ แม้จะรู้โทเค็นที่สร้างอย่างถูกต้องอยู่แล้ว

ฟีเจอร์ที่ลดลงในโหมด Privacy Pass

  • ในโหมด Privacy Pass Kagi ไม่สามารถระบุตัวผู้ใช้ได้ จึงไม่สามารถใช้ การตั้งค่าบัญชี ได้
  • Kagi นำเสนอสิ่งนี้เป็นโครงสร้างให้ผู้ใช้เลือกระหว่าง “ความเป็นส่วนตัวทั่วไปและฟีเจอร์ครบถ้วน” หรือ “ความเป็นส่วนตัวสูงสุดและฟีเจอร์หลัก”
  • ณ เวลาที่เปิดตัว Kagi Assistant ยังใช้กับ Privacy Pass ไม่ได้
    • Kagi Assistant ให้บริการเฉพาะสมาชิก Ultimate
    • ใน Privacy Pass ไม่มีข้อมูลบัญชี จึงไม่สามารถตรวจสอบได้ว่าเป็นแผนใด
  • ณ เวลาที่เปิดตัว Privacy Pass ใช้เฉพาะกับการยืนยันตัวตนของ Kagi Search เท่านั้น
  • Kagi มีแผนจะขยายการรองรับไปยังบริการต่อไปนี้ภายในไม่กี่สัปดาห์ข้างหน้า
    • Kagi Assistant
    • Kagi Translate และ Kagi Maps
    • Kagi Universal Summarizer และ Ask questions about page
  • หากต้องการใช้บริการเหล่านี้ในตอนนี้ ต้องปิด Privacy Pass

ช่องทางข้างเคียงและการใช้ Tor

  • Privacy Pass ทำให้ไม่สามารถเชื่อมโยงการสร้างและการใช้โทเค็นได้ด้วยโทเค็นเพียงอย่างเดียว แต่ไม่สามารถอธิบายปฏิสัมพันธ์ออนไลน์ทั้งหมดด้วยโมเดลทางคณิตศาสตร์ได้อย่างสมบูรณ์
  • เซิร์ฟเวอร์ที่ประสงค์ร้ายอาจพยายามติดตามไคลเอนต์ด้วยข้อมูล ช่องทางข้างเคียง
    • หากค้นหาสิ่งที่เฉพาะเจาะจงเหมือนเดิมในเวลาเดียวกันทุกวัน อาจอนุมานได้ว่าการค้นหาเหล่านั้นมาจากคนเดียวกัน
    • สัญญาณอย่าง browser user-agent และที่อยู่ IP เป็นข้อมูลที่อยู่นอก Privacy Pass
    • หากคำขอสร้างโทเค็นและคำขอใช้โทเค็นเกิดขึ้นต่อเนื่องกันจาก IP เดียวกัน อาจถูกมองว่าเป็นคำขอของบุคคลเดียวกัน
  • RFC 9576 แนะนำให้แยกการสร้างและการใช้โทเค็นออกจากกันทางเวลา หรือแยกกันทางพื้นที่ด้วยบริการนิรนามอย่าง Tor
  • ส่วนขยาย Privacy Pass ของ Kagi และการพัฒนาในตัวของ Orion จัดการลบ HTTP header และคุกกี้ เพื่อทำให้ฟิงเกอร์พรินต์ของเบราว์เซอร์สม่ำเสมอที่สุดเท่าที่เป็นไปได้
  • Kagi มีที่อยู่ onion ที่เข้าถึงได้โดยตรงจากเครือข่าย Tor
  • หากใช้ Tor อย่างเดียว ที่อยู่ IP จะถูกซ่อน แต่หากยังล็อกอินโดยไม่ใช้ Privacy Pass การค้นหาในทางทฤษฎีอาจเชื่อมโยงกับบัญชีเดียวได้
  • เมื่อใช้ Tor ร่วมกับ Privacy Pass Kagi จะรู้เพียงว่าการค้นหานั้นมาจากผู้ใช้ที่เคยถูกตรวจสอบว่ามีสิทธิ์รับโทเค็น แต่จะไม่รู้บัญชีหรือตำแหน่งที่ตั้ง

จำนวนโทเค็น ประสิทธิภาพ และพื้นที่จัดเก็บ

  • ผู้ใช้แผนค้นหาไม่จำกัดสามารถสร้างโทเค็นได้ 2,000 รายการต่อหนึ่ง epoch หรือหนึ่งเดือน
  • หากต้องการโทเค็นเพิ่มเติม สามารถขอได้ที่ support@kagi.com
  • การสร้างโทเค็นค้นหา 500 รายการใช้การประมวลผลประมาณ 1 วินาทีบนแล็ปท็อปผู้บริโภคทั่วไป
    • อาจใช้เวลาเพิ่มอีกไม่กี่วินาทีจากการเชื่อมต่อเซิร์ฟเวอร์และเวลาตอบกลับ
    • เมื่อทำการติดตั้งส่วนขยาย จะดำเนินการในแบ็กกราวด์ให้มากที่สุดเท่าที่เป็นไปได้
  • โทเค็นหนึ่งรายการมีขนาด 216 ไบต์ และพื้นที่จัดเก็บต่อคำขอสร้างโทเค็นอยู่ที่ประมาณ 100KiB
  • ปัจจุบันเซิร์ฟเวอร์ตรวจสอบโทเค็น deploy อยู่เฉพาะในรีเจียน us-central1 และ Kagi มีแผนจะขยายหลังเปิดตัวไม่นาน

เหตุผลที่การปรับแต่งส่วนบุคคลและการตั้งค่าถูกจำกัด

  • ในการค้นหาด้วย Privacy Pass Kagi ไม่รู้ว่าผู้ใช้เป็นใคร จึงไม่สามารถให้ผลลัพธ์ที่ปรับตามการตั้งค่าแบบกำหนดเองของผู้ใช้ได้
  • Kagi เคยพิจารณาวิธีส่งการตั้งค่าขนาดเล็ก เช่น (language, region, safe-search) ไปกับแต่ละคำขอ แต่ปัจจุบันประเมินว่าอาจลดความเป็นนิรนามลงอย่างมาก
  • จากการวิเคราะห์ตัวอย่าง ผู้ใช้ที่ส่งการตั้งค่าภาษาเฉพาะอย่าง Lang 10 อาจสูญเสียหลักประกัน การไม่เชื่อมโยงระหว่างการใช้กับการใช้ โดยอัตโนมัติ เมื่อมีผู้ใช้ Privacy Pass ประมาณ 1,000 คน
  • Kagi มองว่าการประเมินนี้อาจระมัดระวังเกินไป แต่ปัจจุบันยังไม่เปิดใช้ระดับการปรับแต่งส่วนบุคคลพื้นฐานให้กับผู้ใช้ที่ยืนยันตัวตนด้วย Privacy Pass
  • การตั้งค่าการค้นหาแบบแมนนวลสามารถใช้ได้บางส่วนโดยเติม bangs ในคำค้น
    • เช่น ใส่ !de ไว้หน้าคำค้นเพื่อค้นหาในภูมิภาคเยอรมนี
  • หากต้องการประสบการณ์ค้นหาแบบปรับแต่งส่วนบุคคลเต็มรูปแบบ ควรใช้วิธีล็อกอินเดิมและปิด Privacy Pass

ข้อจำกัด เช่น Safari และหน้าต่างส่วนตัว

  • Privacy Pass ไม่ใช้ บล็อกเชน
    • ใช้โครงสร้าง elliptic curve, hash function และ verifiable oblivious pseudorandom function
    • โทเค็นไม่ได้ถูกสร้าง จัดเก็บ หรือซื้อขายบนบล็อกเชน
  • ในหน้าต่างส่วนตัวของ Chrome·Firefox การสร้างโทเค็นจะไม่ทำงาน
    • การสร้างโทเค็นต้องเข้าถึงคุกกี้เซสชัน
    • ในหน้าต่างส่วนตัว ส่วนขยายไม่สามารถเข้าถึงคุกกี้เซสชันได้
    • ใน Orion การสร้างโทเค็นทำงานได้แม้ในหน้าต่างส่วนตัว
  • แม้เปิด Privacy Pass แล้ว Kagi ยังสามารถเห็นที่อยู่ IP ของคำขอค้นหาได้ เนื่องจากวิธีทำงานของ TCP/IP
    • หากกังวลเรื่องการเปิดเผยที่อยู่ IP แนะนำให้ใช้ Tor หรือ VPN ที่เชื่อถือได้
  • โทเค็นทั้งหมดจะหมดอายุ ณ เที่ยงคืนของวันแรกของเดือน X+2 โดยอิงจากเดือน X ที่สร้างขึ้น
    • เป็นวิธีหลีกเลี่ยงปัญหาที่วันหมดอายุคล้ายกันของโทเค็นที่สร้างในเวลาเดียวกันอาจถูกใช้ระบุการค้นหาหลายครั้ง
  • Safari ยังไม่รองรับในปัจจุบัน
    • Kagi เข้าใจว่า Safari extension API ไม่รองรับความสามารถในการลบคุกกี้ออกจากคำขอ
    • หากลบคุกกี้ไม่ได้ ก็จะยังคงยืนยันตัวตนด้วยบัญชีที่ล็อกอินอยู่
    • หากต้องการประสบการณ์แบบเนทีฟที่คล้ายกันบนฐาน WebKit สามารถใช้ Orion Browser ที่ผสาน Privacy Pass เป็นทางเลือกได้

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

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

 
GN⁺ 2025-02-14
ความคิดเห็นจาก Hacker News

  • ดีที่ Kagi ตอนนี้ใช้ Privacy Pass แล้ว และโดยรวมบริษัทเองก็ดูโอเค
    แต่ Kagi แทบจะเอาร่าง IETF [1] กับ implementation ภาษา Rust [2] ที่ผมเคยทำอยู่พักหนึ่งไปใช้ แล้วทำ wrapper บาง ๆ [3] ครอบไว้ ก่อนจะเรียกมันว่า “implementation ของ Privacy Pass ของ Kagi”
    ผมคิดว่าควรให้ เครดิต กับผมบ้าง งาน IETF และงานซอฟต์แวร์โอเพนซอร์สส่วนใหญ่ทำด้วยความสมัครใจและไม่ได้รับค่าจ้าง และมักทำกันนอกเวลางาน ถ้าถูกปฏิบัติแบบนี้ก็ไม่มีกำลังใจ Kagi น่าจะทำได้ดีกว่านี้
    [1] https://datatracker.ietf.org/doc/draft-ietf-privacypass-batc...
    [2] https://github.com/raphaelrobert/privacypass
    [3] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...

    • พูดตามตรง “implementation ของ Privacy Pass ของ Kagi” ที่บทความพูดถึง ดูเหมือนจะไม่ได้หมายถึงตัว RFC หรือ implementation ของโปรโตคอลเอง แต่หมายถึงส่วนที่ ผสานรวม ฟังก์ชันนั้นเข้ากับ เซิร์ฟเวอร์และไคลเอนต์ ของ Kagi มากกว่า ส่วน RFC เองบทความก็ยอมรับอยู่แล้ว
    • สงสัยว่าถ้า Kagi เพิ่ม “เครดิตให้ raphaelrobert” หรือใส่สำเนาไลเซนส์ไว้สักที่ในโค้ด แบบนั้นจะถือว่าปฏิบัติตามแล้วไหม
      โอเพนซอร์สของผมไม่เคยถูกนำไปใช้จริง และปกติแจกจ่ายภายใต้ไลเซนส์ MIT เลยอยากรู้ว่ากลุ่มหรือองค์กรอื่น ๆ ปฏิบัติตามไลเซนส์กันจริง ๆ อย่างไร
    • ตอนแคปเจอร์ส่วนหัว README ราว ๆ วันที่ 14 กุมภาพันธ์ 2025 เวลา 12:15 น. ตามเวลาตะวันออก มีข้อความเขียนไว้แบบนี้

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      แบบนี้ให้ความรู้สึกไม่ดีอย่างชัดเจน อย่างไรก็ตาม คิดว่าคนฝั่ง Kagi น่าจะเปิดรับการแก้ให้แม่นยำขึ้น เช่น “ไลบรารีหลักที่ implement wrapper ภาษา Crystal Lang สำหรับ raphaelrobert/privacypass” น่าจะมีโอกาสสูงที่ไม่ได้ตั้งใจ แต่มัวโฟกัสกับการทำให้มันใช้งานได้จนไม่มีใครกลับมาอ่านถ้อยคำใหม่

  • เจ๋งดี เป็นเรื่องหายากที่จะได้เห็นบริการที่ผมใช้อยู่ทำสิ่งที่เป็นประโยชน์ต่อ ผู้ใช้ มากกว่าตัวบริการเองจริง ๆ แม้จะคาดไม่ถึง แต่ก็เป็นเซอร์ไพรส์ที่ดีมาก
    อยากให้ส่วนขยายนี้เข้าใจบริบทของเบราว์เซอร์โดยอัตโนมัติและผสานรวมได้ดีกว่านี้ กล่าวคือ ในโหมดปกติก็ใช้ session ของผม และในโหมดท่องเว็บแบบส่วนตัว (browser.extension.inIncognitoContext) ก็ให้ยืนยันตัวตนด้วย Privacy Pass โดยที่ผมไม่ต้องทำอะไรเพิ่ม
    ผมไม่ได้ใช้ Orion เพราะไม่มีเวอร์ชัน GNU/Linux

    • เหตุผลที่เรื่องแบบนี้หายากขึ้น ก็เพราะบริษัทส่วนใหญ่ในวงการนี้ อันที่จริงรวมถึงบริษัทเทคโนโลยีจำนวนมาก ใช้ โมเดลตลาดสองด้าน ที่มอบอะไรบางอย่างให้ผู้ใช้กลุ่มหนึ่ง แล้วเอาผลลัพธ์ไปขายให้ผู้ใช้อีกกลุ่มเพื่อทำรายได้
      เนื่องจากฝั่งหลังคือฝั่งที่สร้างรายได้จริง โดยพื้นฐานแล้วผลประโยชน์ของกลุ่มแรกกับกลุ่มหลังจึงขัดกัน และโครงสร้างก็มักกลายเป็นศัตรูกับกลุ่มแรกได้ง่าย
      สิ่งที่ทำให้ Kagi และบริษัทเทคโนโลยีใหม่ ๆ อื่น ๆ ดูสดใหม่ คือพวกเขาทิ้งโมเดลนี้ แล้วกลับไปสู่โมเดล “แบบเก่า” ที่กลุ่มที่ตนให้บริการและกลุ่มที่ทำรายได้ให้เป็นกลุ่มเดียวกัน
    • เพิ่งเริ่มทำ Orion สำหรับ Linux เมื่อวานนี้
    • ข้อเสียของวิธีนี้คือ ถ้าไม่ได้อยู่บนเครือข่ายขนาดใหญ่ แค่ที่อยู่ IP ก็อาจทำให้ความไม่ระบุตัวตนพังได้
      Kagi รู้ว่าผู้ใช้ล็อกอินอยู่ และถ้าผู้ใช้ค้นหาเรื่องละเอียดอ่อนในหน้าต่างส่วนตัว ก็สามารถเชื่อมโยงการค้นหาเหล่านั้นได้ การสลับไปมาระหว่างโหมดอย่างรวดเร็วไม่ใช่เรื่องที่ดี
    • เผื่อยังไม่รู้ ประมาณปลายปี 2024 มีการประกาศในพอดแคสต์ว่ากำลังวางแผน Orion เวอร์ชัน Linux อยู่
    • พอใช้ Kagi ไปเรื่อย ๆ ก็เริ่มชินกับการที่เขาเลือกทำสิ่งที่ถูกต้อง น่าทึ่งจริง ๆ ที่แทบไม่มีพลาดอะไรเลย
      หวังว่าเสื้อยืด Kagi ของผมจะเป็นแบบนั้นด้วย ซักครั้งที่สองชายเสื้อก็หลุดลุ่ยแล้ว ตอนนี้เลยกลายเป็นเสื้อนอนกับเสื้อใส่ทำสวนไปแล้ว ได้คูปองเสื้อฟรีสำหรับเปลี่ยนตัวใหม่มาแล้ว แต่ยังไม่ได้จัดส่ง

  • ตามที่บทความบอกเป็นนัย การมี ร้านค้าที่ซื้อ Privacy Pass ได้โดยไม่ต้องมีบัญชี นั้นสมเหตุสมผล
    ควรรองรับคริปโตสักตัว อาจจะเป็น Monero และถ้าเทคโนโลยีอย่าง GNU Taler ใช้งานได้ดีขึ้นในสักวัน ก็ควรรองรับด้วย

    • Kagi รับ Bitcoin แต่ Vlad ผู้ก่อตั้งเคยบอกในฟอรัมว่ามีคนใช้ตัวเลือกนี้น้อยมากจนไม่คุ้มที่จะลงทุนกับ การรองรับ Monero
    • เห็นด้วยว่าร้านค้าบุคคลที่สามที่ขายโทเคนโดยไม่ต้องมีบัญชีคือทางออกในอุดมคติ แต่ถ้าไม่มีบัญชี ก็จะพลาดฟีเจอร์ที่ทำให้ Kagi น่าใช้ เช่น การลบโดเมนบางโดเมนออกจากผลลัพธ์ หรือการเพิ่มลำดับความสำคัญให้ผลลัพธ์บางประเภท

  • ผมสงสัยว่าสุดท้ายแล้วนี่คือ ความเป็นส่วนตัวแบบที่ต้องสมมติว่าไม่มีการเก็บล็อก หรือเปล่า ไม่ได้จะหาเรื่องนะ แต่ผมไม่เข้าใจส่วนนี้จริง ๆ
    สมมติว่าผู้ใช้ A ขอ token จาก Kagi แล้ว Kagi บอกว่า “ได้เลย จะให้ token 500 อัน” ถ้า Kagi บันทึก token 500 อันที่เพิ่งให้ผู้ใช้ A ไปไว้ ทีหลังเมื่อมีการใช้อันใดอันหนึ่งในนั้น ก็รู้ได้ไม่ใช่หรือว่า token นั้นถูกจัดสรรให้ผู้ใช้ A?
    แน่นอนว่าถ้า Kagi ไม่เก็บข้อมูลนี้ไว้ ตัว token เองก็จะแสดงแค่ว่า valid/invalid และไม่เหลือบันทึกว่าเป็น “token ที่ยังใช้ได้ซึ่งให้ผู้ใช้ A เมื่อวันที่ Y” แบบนั้นก็น่าจะโอเค แต่นั่นคือทั้งหมดจริง ๆ ใช่ไหม? ผมเข้าใจอะไรผิดไปหรือเปล่า?

    • ไม่ใช่ server เป็นคนสร้าง token แต่เป็น client ที่สร้าง token server ต้องสามารถตรวจสอบได้ว่า token นั้นถูกสร้างโดย client ที่ได้รับสิทธิ์ให้สร้าง แต่ไม่ควรรู้ว่า client คนไหนเป็นคนสร้าง อย่างน้อยก็ต้องเป็นแบบนั้นถ้าไม่มีข้อมูล side-channel

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      ผมไม่แน่ใจว่า primitive นี้ผ่านการพิสูจน์/ตรวจสอบมามากแค่ไหน แต่ดูเหมือนมีโครงสร้างมากกว่าการที่ server แจก token ให้ client แล้วแกล้งทำเป็นไม่รู้ว่าให้ใครไปมาก ๆ
      paper อ้างอิง: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • เอกสาร Privacy Pass [0] กล่าวถึงส่วนนี้ แต่โดยหลักจะอธิบายลึกกว่าใน paper ประเด็นสำคัญคือ token ที่ server ส่งกลับมา เชื่อมโยงไม่ได้ กับ token ที่ถูกปรับแก้แล้วซึ่ง client ส่งกลับมาอีกครั้ง
      server รู้ได้ว่าเคยส่ง token A, B, C กลับไปให้ผู้ใช้บางคน และภายหลังได้รับ token X, Y, Z มา และรู้ด้วยว่า X, Y, Z ใช้งานได้ แต่ไม่รู้ความสัมพันธ์ว่าอันไหนตรงกับ token ที่ตัวเองออกให้ ในนี้ใช้ elliptic curve cryptography
      [0] https://privacypass.github.io/
    • แนวคิดคือ token ไม่ได้เชื่อมกับบัญชีใด ๆ เป็น token แบบไม่ระบุตัวตน
    • ดูเหมือนคุณยังไม่เข้าใจสมมติฐานของ Privacy Pass token
      ใจความคือ server ไม่รู้ว่า token ใดเป็นของ client คนไหน server ไม่ได้สร้าง token

  • ข้อบกพร่องใหญ่ที่สุดของ Kagi ที่ผมเห็นมาตลอดได้รับการแก้ไขแล้ว ขอบคุณที่รับฟังและลงมือทำเพื่อทำให้ผลิตภัณฑ์น่าสนใจสำหรับแทบทุกคน

  • หนึ่งในข้อร้องเรียนใหญ่ที่สุดจากคนที่ยังไม่ใช้ Kagi คือ ความกังวลด้านความเป็นส่วนตัว จากการต้องให้ข้อมูลล็อกอินและการชำระเงิน
    ผมไม่ใช่คนที่กังวลเรื่องนั้น แต่ก็อยากรู้ว่าการเปลี่ยนแปลงนี้ช่วยลดความกังวลให้คนที่กังวลจริง ๆ ได้มากแค่ไหน

    • ผมเป็นคนหนึ่งที่กังวลเรื่องนั้น และยังรู้สึกเหลือเชื่ออยู่เลยที่ต้องล็อกอินเข้า search engine แน่นอนว่าตอนนี้ผมรู้แล้วว่ามีคนทำแบบนั้นกันมากแค่ไหน
      หลังจากตรวจสอบระบบอย่างคร่าว ๆ แล้ว ตอนนี้มีโอกาสค่อนข้างสูงที่ผมจะสมัครใช้
    • ถ้า cryptography ทำงานตามที่ Kagi บอก วิธีนี้จะแยกคำขอค้นหาออกจากข้อมูลบัญชีโดยสิ้นเชิง โครงสร้างคือบัญชีสร้าง search token หลายอัน และแต่ละคำขอค้นหาจะใช้ token ไปหนึ่งอัน
      token ถูกสร้างบนอุปกรณ์ และไม่ออกจากอุปกรณ์จนกว่าจะถูกใช้ ดังนั้นในเชิงทฤษฎี Kagi จึงไม่มีทางรู้จาก token เพียงอย่างเดียวว่าบัญชีใดสร้าง token นั้นขึ้นมา มันไม่ได้แก้เรื่อง fingerprinting หรือการเชื่อมโยงด้วย IP แต่บอกกันว่า plugin สำหรับ Firefox และ Chrome มีมาตรการเพื่อลด fingerprinting เรื่องนี้ไม่ได้แย่กว่าหรือดีกว่าการใช้ Google หรือ DuckDuckGo ตรง ๆ และถ้าต้องการความเป็นส่วนตัวจริง ๆ ก็ใช้กับ Tor ได้ด้วย
      ผมไม่แน่ใจว่าพิสูจน์ความถูกต้องได้อย่างไรโดยไม่แชร์ token เลย แต่น่าจะมีอะไรทำนอง ~~zero-knowledge proof~~ อยู่ในนั้น
      แก้ไข: ดูเหมือนไม่ใช่ zero-knowledge proof แต่เป็น blind signature

  • ผมไม่เข้าใจว่าอะไรจะไปกันไม่ให้คนฝั่ง Kagi เพิ่มคอลัมน์ใหม่ในตารางโทเค็น เพื่อเก็บผู้ใช้ที่สร้างโทเค็นกับ SessionCookie ของคนนั้นไว้
    มองไม่เห็นเหตุผลว่าทำไมมันถึงจะเชื่อมโยงกลับไปยังผู้สร้างโทเค็นเดิมได้ยากมาก

    • ผมเป็นคนทำ implementation เอง ในโปรโตคอล “การออก” ของ Privacy Pass ไคลเอนต์จะสร้าง “ข้อความ” ให้เซิร์ฟเวอร์ประมวลผล เอาต์พุตของเซิร์ฟเวอร์จะถูกส่งกลับไปยังไคลเอนต์ แล้วไคลเอนต์จะแก้ไขเอาต์พุตนี้ต่อเพื่อสร้างโทเค็นสุดท้าย
      ในขั้นแก้ไขขั้นสุดท้ายฝั่งไคลเอนต์ โทเค็นเหล่านี้จะถูกสุ่มใหม่ ทำให้เซิร์ฟเวอร์ไม่สามารถระบุได้ว่าโทเค็นนั้นเป็นของกระบวนการออกโทเค็นครั้งใด
      จุดที่เจ๋งจริง ๆ คือ แม้เซิร์ฟเวอร์จะพยายามทำตัวไม่ดีในขั้นของตัวเอง ผลลัพธ์ก็ยังเป็นแบบนั้นอยู่ ดังนั้นผู้ใช้จึงต้องเชื่อถือแค่ซอฟต์แวร์ฝั่งไคลเอนต์เท่านั้น และเราเปิดซอร์สโค้ดไว้แล้ว: https://github.com/kagisearch/privacypass-extension
      มีหลายคนพูดถึง blind signature ซึ่งจริง ๆ แล้ว Privacy Pass สามารถใช้สิ่งนี้เป็นองค์ประกอบได้ แต่ถ้าพูดให้แม่น ใน Kagi เราใช้ “Privately Verifiable Tokens”(https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) ที่อิงกับ “Oblivious Pseudorandom Function” (OPRF) และโดยส่วนตัวผมมองว่า OPRF เจ๋งกว่า blind signature
    • ดูเหมือนเป็นสิ่งที่อธิบายไว้ในเปเปอร์โปรโตคอลโทเค็นนิรนามเชิงเข้ารหัสลับที่อ้างถึง [1] ไม่ใช่แค่ โทเค็นข้อความธรรมดา
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Cloudflare ก็น่าจะเคย implement สิ่งเดียวกัน อย่างน้อยคอมเมนต์ใน HN ก็ลิงก์ไปยังเปเปอร์เดียวกัน
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • โทเค็นถูก “สร้าง” ที่ฝั่งไคลเอนต์ และเซิร์ฟเวอร์ให้ข้อมูลกับไคลเอนต์เท่าที่เพียงพอให้โทเค็นที่สร้างในเครื่องนั้น “ใช้ได้” แต่ขณะเดียวกันก็ไม่สามารถเชื่อมโทเค็นนั้นกับความพยายามตรวจสอบครั้งใดครั้งหนึ่งได้
    • ผมก็คิดคำถามนั้นเหมือนกันเป๊ะ ๆ เพราะพึ่งพาความเชื่อใจฝั่งเซิร์ฟเวอร์ไม่ได้ เลยสงสัยว่าผมเข้าใจอะไรผิดไปหรือเปล่า
    • ถ้าผมเข้าใจถูก “Privacy Pass” ใช้ blind signature ดังนั้นจึงไม่สามารถเชื่อมโยงโทเค็นที่อยู่ใน TokenResponse กับโทเค็นที่ถูกส่งไปพร้อมคำค้นหาเข้าด้วยกันได้

  • มันใช้งานได้จริงหรือ? โทเค็นใช้ได้ครั้งเดียว ดังนั้นในทางปฏิบัติไคลเอนต์ก็น่าจะวนลูปสร้างและใช้โทเค็นภายใน search session หนึ่ง ๆ ซึ่งจะทำให้เชื่อมคู่กันได้ง่ายมาก บทความเองก็พูดแบบนี้

    For this reason, it is highly recommended to separate token generation and redemption in time, or “in space” (by using an anonymizing service such as Tor when redeeming tokens, see below).
    Tor อาจช่วยสุ่มมิติของพื้นที่ได้ แต่เรื่องเวลาล่ะ? ผมเลยไปดูส่วนที่บอกว่า “ดูด้านล่าง” แต่หาเนื้อหาที่เกี่ยวข้องไม่เจอ แนวคิดคือถ้ามีปริมาณคำขอมากพอ ไคลเอนต์ทั้งหลายจะช่วยบังกันและกันในเชิงเวลาหรือเปล่า?
    อีกอย่าง Tor เองก็มีข้อจำกัดในการสุ่มมิติของพื้นที่ เว้นแต่จะสร้าง session ใหม่ตลอด เท่าที่ผมรู้วงจรจะคงที่ตลอด session และการสร้าง session ใหม่ใช้เวลาประมาณ 10 วินาที แล้วจะถือว่าสุ่มพื้นที่ได้จริง ๆ ไหม?

    • คำขอโทเค็นหนึ่งครั้งสามารถสร้างโทเค็นได้ N รายการ เราตั้งค่าไว้ที่ N = 500 ดังนั้นผู้ใช้ส่วนใหญ่จะต้องขอโทเค็นใหม่ค่อนข้างไม่บ่อย

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

    • ใช่แล้ว หลายอุปกรณ์ เป็นเรื่องไม่ง่ายแน่นอน เราลองไอเดียมาหลายแบบแล้ว แต่ไม่ใช่ปัญหาที่มีคำตอบชัดเจน
      ตอนนี้เราเปิดให้ใช้ Privacy Pass บนอุปกรณ์หลายเครื่องได้โดยให้อุปกรณ์แต่ละเครื่องสร้างโทเค็นอย่างอิสระผ่านการจำกัดอัตราใช้งาน เราจะดูว่ามันเป็นอย่างไร รับฟังฟีดแบ็กผู้ใช้ แล้วค่อยกลับไปออกแบบใหม่อีกครั้ง

  • นี่คือ Privacy Pass แบบเดียวกับที่ Cloudflare เคยใช้เพื่อให้ไคลเอนต์ข้าม CAPTCHA ได้หรือเปล่า? ถ้าใช่ นี่เป็นการประยุกต์ใช้ระบบนี้ที่เนี้ยบมาก ผมไม่เคยคิดมาก่อนว่าจะใช้มันเพื่อยืนยันตัวตนกับบริการแบบเสียเงินอย่างนิรนามได้

    • วิทยาการเข้ารหัสลับ [1] ที่ Privacy Pass อิงอยู่นั้นจริง ๆ มาจาก Ecash[2] ก็เลยเหมือนวนกลับมาครบวง
      [1] https://www.petsymposium.org/2018/files/papers/issue3/popets...
      [2] https://en.m.wikipedia.org/wiki/Ecash
    • ใช่ แต่เท่าที่ผมรู้ Cloudflare ยุติ การทดลองใช้งาน Privacy Pass ไปแล้ว
      ผมจำได้ว่า Safari เป็นเบราว์เซอร์เดียวที่ implement แบบเนทีฟ แต่ตอนนี้ดูเหมือน Orion ก็รองรับแล้ว