Overview

เกริ่นนำ

หมายเหตุ: เอกสารนี้ยังอยู่ระหว่างการพัฒนา ซึ่งเราจะปรับปรุงให้ดีขึ้นได้ในอนาคตอันใกล้นี้

Google Safe Browsing v5 คือวิวัฒนาการของ Google Safe Browsing v4 การเปลี่ยนแปลงสำคัญ 2 ประการใน v5 คือความใหม่ของข้อมูลและความเป็นส่วนตัวของ IP นอกจากนี้ แพลตฟอร์ม API ยังได้รับการปรับปรุงเพื่อเพิ่มความยืดหยุ่น ประสิทธิภาพ และลดการเพิ่มการเติบโต นอกจากนี้ Google Safe Browsing v5 ยังออกแบบมาเพื่อทำให้การย้ายข้อมูลจาก v4 เป็นเรื่องง่าย

ปัจจุบัน Google มีทั้ง v4 และ v5 ซึ่งถือว่าพร้อมสำหรับการใช้งานจริงแล้ว คุณสามารถใช้ v4 หรือ v5 ก็ได้ เรายังไม่ได้ประกาศวันที่จะเลิกใช้ v4 หากประกาศ เราจะแจ้งให้คุณทราบอย่างน้อย 1 ปี หน้านี้จะอธิบายเกี่ยวกับ v5 และคำแนะนำในการย้ายข้อมูลจาก v4 ไปยัง v5 เอกสารทั้งหมดของ v4 จะยังคงใช้งานได้

ความใหม่ของข้อมูล

การปรับปรุงที่สำคัญอย่างหนึ่งของ Google Safe Browsing v5 ผ่าน v4 (โดยเฉพาะ v4 Update API) คือความใหม่และความครอบคลุมของข้อมูล เนื่องจากการปกป้องจะขึ้นอยู่กับฐานข้อมูลภายในเครื่องที่ดูแลโดยลูกค้า ความล่าช้าและขนาดของการอัปเดตฐานข้อมูลในเครื่องจึงเป็นปัจจัยหลักของการป้องกันที่พลาดไป ใน v4 ไคลเอ็นต์ทั่วไปจะใช้เวลา 20 ถึง 50 นาทีเพื่อรับรายการภัยคุกคามเวอร์ชันล่าสุด ขออภัย การโจมตีแบบฟิชชิงแพร่กระจายอย่างรวดเร็ว โดยตั้งแต่ปี 2021 เป็นต้นมา 60% ของเว็บไซต์ที่ทำให้เกิดการโจมตีดังกล่าวใช้งานได้ไม่ถึง 10 นาที การวิเคราะห์ของเราแสดงให้เห็นว่าประมาณ 25-30% ของการป้องกันฟิชชิงที่หายไปนั้นเกิดจากการไม่มีการอัปเดตของข้อมูลดังกล่าว นอกจากนี้ อุปกรณ์บางเครื่องไม่มีความสามารถในการจัดการรายการภัยคุกคามทั้งหมดของ Google Safe Browsing ซึ่งจะขยายจำนวนมากขึ้นเรื่อยๆ

ใน v5 เราเปิดตัวโหมดการทำงานที่เรียกว่าการป้องกันแบบเรียลไทม์ วิธีนี้ช่วยหลบเลี่ยงปัญหาการไม่มีอัปเดตของข้อมูลข้างต้น ในเวอร์ชัน 4 ไคลเอ็นต์จะต้องดาวน์โหลดและดูแลรักษาฐานข้อมูลในเครื่อง ดำเนินการตรวจสอบกับรายการภัยคุกคามที่ดาวน์โหลดไว้ในเครื่อง จากนั้นเมื่อมีการจับคู่คำนำหน้าบางส่วน ให้ส่งคำขอดาวน์โหลดแฮชแบบเต็ม ในเวอร์ชัน 5 แม้ว่าไคลเอ็นต์ควรจะดาวน์โหลดและดูแลรักษาฐานข้อมูลของรายการภัยคุกคามในเครื่องต่อไป แต่ในตอนนี้ไคลเอ็นต์จะต้องดาวน์โหลดรายการเว็บไซต์ที่ไม่เป็นอันตราย (เรียกว่า Global Cache) ดำเนินการทั้งตรวจสอบในเครื่องสำหรับแคชทั่วโลกนี้ รวมถึงการตรวจสอบรายการภัยคุกคามในเครื่อง และสุดท้าย เมื่อมีการจับคู่คำนำหน้าบางส่วนสำหรับรายการภัยคุกคามหรือการจับคู่ที่ไม่ตรงกันในแคชส่วนกลาง ให้ส่งคำขอเพื่อดาวน์โหลดแฮชทั้งหมด (สำหรับรายละเอียดเกี่ยวกับการประมวลผลข้อมูลภายในที่ลูกค้าต้องการ โปรดดูขั้นตอนที่ระบุไว้ด้านล่าง) การเปลี่ยนแปลงนี้แสดงถึงการเปลี่ยนจาก "อนุญาตโดยค่าเริ่มต้น" ไปเป็น "ตรวจสอบโดยค่าเริ่มต้น" ซึ่งช่วยปรับปรุงการปกป้องเพื่อให้ครอบคลุมการเผยแพร่ภัยคุกคามบนเว็บได้เร็วขึ้น กล่าวอีกนัยหนึ่งคือ โปรโตคอลนี้ออกแบบมาเพื่อมอบการปกป้องแบบเกือบเรียลไทม์ เรามุ่งหวังให้ลูกค้าได้รับประโยชน์จากข้อมูล Google Safe Browsing ใหม่ๆ ของ Google

ความเป็นส่วนตัวของ IP

Google Safe Browsing (v4 หรือ v5) จะไม่ประมวลผลข้อมูลที่เชื่อมโยงกับข้อมูลประจำตัวของผู้ใช้ในคำขอที่แสดง คุกกี้ (หากส่ง) จะถูกละเว้น Google ทราบที่อยู่ IP ต้นทางของคำขอแล้ว แต่ Google จะใช้ที่อยู่ IP ดังกล่าวเพื่อความต้องการด้านเครือข่ายที่สำคัญเท่านั้น (เช่น เพื่อส่งการตอบกลับ) และเพื่อวัตถุประสงค์ในการต่อต้าน DoS

และควบคู่ไปกับ v5 เราได้เปิดตัว API ที่แสดงร่วมกันที่เรียกว่า Safe Browsing Oblivious HTTP Gateway API การดำเนินการนี้ใช้ Oblivious HTTP เพื่อซ่อนที่อยู่ IP ของผู้ใช้ปลายทางจาก Google เครื่องมือนี้จะทำงานโดยให้บุคคลที่สามที่ไม่ได้คอลแลบจัดการคำขอของผู้ใช้ในเวอร์ชันที่เข้ารหัส แล้วส่งต่อไปยัง Google ดังนั้นบุคคลที่สามจึงมีสิทธิ์เข้าถึงเฉพาะที่อยู่ IP และ Google จะเข้าถึงได้เฉพาะเนื้อหาของคำขอเท่านั้น บุคคลที่สามใช้งาน Oblivious HTTP Relay (เช่น บริการนี้โดย Fastly) และ Google ดำเนินการ Oblivious HTTP Gateway เป็น API ที่แสดงร่วมกันซึ่งไม่บังคับ เมื่อใช้งานร่วมกับ Google Safe Browsing จะไม่มีการส่งที่อยู่ IP ของผู้ใช้ปลายทางไปยัง Google อีกต่อไป

การใช้งานที่เหมาะสม

การใช้งานที่อนุญาต

Safe Browsing API มีไว้เพื่อการใช้งานที่ไม่ใช่เชิงพาณิชย์เท่านั้น (หมายความว่า "ไม่ได้มีไว้เพื่อขายหรือสร้างรายได้") หากคุณต้องการโซลูชันเพื่อวัตถุประสงค์เชิงพาณิชย์ โปรดดูที่ความเสี่ยงเกี่ยวกับเว็บ

ราคา

Google Safe Browsing API ทั้งหมดไม่มีค่าใช้จ่าย

โควต้า

นักพัฒนาซอฟต์แวร์จะได้รับการจัดสรรโควต้าการใช้งานเริ่มต้นเมื่อเปิดใช้ Safe Browsing API ดูการจัดสรรและการใช้งานปัจจุบันได้ในแผงควบคุมสำหรับนักพัฒนาซอฟต์แวร์ Google หากคุณคาดว่าจะใช้โควต้าที่จัดสรรไว้ในปัจจุบัน คุณสามารถขอโควต้าเพิ่มเติมได้จากอินเทอร์เฟซโควต้าของ Developer Console เราตรวจสอบคำขอเหล่านี้และกำหนดให้มีบุคคลที่ติดต่อเมื่อขอโควต้าเพิ่ม เพื่อให้มั่นใจว่าความพร้อมให้บริการของเราตรงตามความต้องการของผู้ใช้ทุกคน

URL ที่เหมาะสม

Google Safe Browsing ออกแบบมาเพื่อดำเนินการกับ URL ที่จะแสดงในแถบที่อยู่ของเบราว์เซอร์ ไม่ได้ออกแบบมาเพื่อใช้ในการตรวจสอบกับทรัพยากรย่อย (เช่น JavaScript หรือรูปภาพที่อ้างอิงโดยไฟล์ HTML หรือ WebSocket URL ที่เริ่มต้นโดย JavaScript) URL ของทรัพยากรย่อยดังกล่าวไม่ควรตรวจสอบกับ Google Safe Browsing

หากการเข้าชม URL ทำให้เกิดการเปลี่ยนเส้นทาง (เช่น HTTP 301) คุณควรจะตรวจสอบ URL ที่เปลี่ยนเส้นทางกับ Google Safe Browsing การจัดการ URL ฝั่งไคลเอ็นต์ เช่น History.pushState จะไม่ส่งผลให้มีการตรวจสอบ URL ใหม่กับ Google Safe Browsing

คำเตือนสำหรับผู้ใช้

หากคุณใช้ Google Safe Browsing เพื่อเตือนผู้ใช้เกี่ยวกับความเสี่ยงจากหน้าเว็บบางหน้า คุณจะต้องปฏิบัติตามหลักเกณฑ์ต่อไปนี้

หลักเกณฑ์เหล่านี้ช่วยป้องกันทั้งคุณและ Google จากการเข้าใจผิด โดยการระบุอย่างชัดเจนว่าหน้าเว็บดังกล่าวไม่ได้เป็นที่รู้จักในฐานะแหล่งข้อมูลเว็บที่ไม่ปลอดภัย 100% และคำเตือนเป็นเพียงการระบุถึงความเสี่ยงเท่านั้น

• ในคำเตือนที่แสดงต่อผู้ใช้ คุณต้องไม่ทำให้ผู้ใช้เชื่อว่าหน้าเว็บที่เป็นปัญหานั้นเป็นแหล่งข้อมูลเว็บที่ไม่ปลอดภัยโดยไม่ต้องสงสัย เมื่อคุณอ้างอิงหน้าเว็บที่ระบุหรือมีความเสี่ยงที่หน้าเว็บดังกล่าวอาจแสดงต่อผู้ใช้ คุณต้องตรวจสอบคุณสมบัติของคำเตือนโดยใช้คำต่างๆ เช่น สงสัยว่าน่าสงสัย อาจจะเป็นไปได้
• คำเตือนของคุณจะต้องช่วยให้ผู้ใช้ดูข้อมูลเพิ่มเติมได้โดยตรวจสอบคำจำกัดความของ Google เกี่ยวกับภัยคุกคามต่างๆ ขอแนะนำให้ใช้ลิงก์ต่อไปนี้
  • วิศวกรรมสังคม: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • มัลแวร์และซอฟต์แวร์ไม่พึงประสงค์: https://developers.google.com/search/docs/monitor-debug/security/malware
  • แอปพลิเคชันที่อาจเป็นอันตราย (Android เท่านั้น): https://developers.google.com/android/play-protect/potentially-harmful-applications
• เมื่อแสดงคำเตือนสำหรับหน้าเว็บที่บริการ Google Safe Browsing ระบุว่ามีความเสี่ยง คุณต้องแสดงที่มากับ Google โดยใส่บรรทัด "คำแนะนำจาก Google" พร้อมกับลิงก์ไปยังคำแนะนำเกี่ยวกับ Google Safe Browsing หากผลิตภัณฑ์แสดงคำเตือนจากแหล่งที่มาอื่นๆ ด้วย คุณต้องไม่รวมการระบุแหล่งที่มาของ Google ไว้ในคำเตือนที่มาจากข้อมูลที่ไม่ใช่ของ Google

• ในเอกสารประกอบของผลิตภัณฑ์ คุณจะต้องส่งหนังสือแจ้งเพื่อให้ผู้ใช้ทราบว่าการปกป้องที่ Google Safe Browsing มีให้นั้นยังไม่สมบูรณ์แบบ โดยต้องแจ้งให้ทราบว่ามีโอกาสทั้งที่เป็นผลบวกลวง (เว็บไซต์ที่ปลอดภัยแจ้งว่ามีความเสี่ยง) และรายการเชิงลบลวง (เว็บไซต์ที่มีความเสี่ยงไม่ได้ถูกแจ้งว่าไม่เหมาะสม) เราขอแนะนำให้ใช้ภาษาต่อไปนี้

  Google พยายามจัดหาข้อมูลที่ถูกต้องและเป็นปัจจุบันที่สุดเกี่ยวกับทรัพยากรบนเว็บที่ไม่ปลอดภัย อย่างไรก็ตาม Google ไม่สามารถรับประกันได้ว่าข้อมูลของเว็บไซต์นั้นครบถ้วนและปราศจากข้อผิดพลาด ไม่สามารถระบุเว็บไซต์ที่มีความเสี่ยงบางเว็บ และอาจมีการระบุเว็บไซต์ที่ปลอดภัยบางแห่งด้วยความผิดพลาด

รูปแบบการดำเนินการ

Google Safe Browsing v5 ช่วยให้ลูกค้าสามารถเลือกการทำงานได้ 3 โหมด

โหมดเรียลไทม์

เมื่อลูกค้าเลือกใช้ Google Safe Browsing v5 ในโหมดเรียลไทม์ ไคลเอ็นต์จะเก็บรักษาไว้ในฐานข้อมูลภายในเครื่องของตนเอง เช่น (1) แคชส่วนกลางของเว็บไซต์ที่มีแนวโน้มไม่เป็นอันตราย ซึ่งมีรูปแบบเป็นแฮช SHA256 ของนิพจน์ URL โฮสต์/คำต่อท้ายเส้นทาง (2) ชุดรายการภัยคุกคามซึ่งมีรูปแบบเป็นคำนำหน้าแฮช SHA256 ของนิพจน์ URL ส่วนต่อท้ายโฮสต์/คำนำหน้าเส้นทาง แนวคิดระดับสูงคือ เมื่อใดก็ตามที่ลูกค้าต้องการตรวจสอบ URL หนึ่งๆ จะมีการตรวจสอบในเครื่องโดยใช้ Global Cache หากการตรวจสอบดังกล่าวผ่าน ระบบจะตรวจสอบรายการภัยคุกคามในพื้นที่ ไม่เช่นนั้น ไคลเอ็นต์จะดำเนินการต่อด้วยการตรวจสอบแฮชแบบเรียลไทม์ตามรายละเอียดด้านล่าง

นอกจากฐานข้อมูลในเครื่องแล้ว ไคลเอ็นต์จะยังมีแคชในเครื่อง แคชในเครื่องดังกล่าวไม่จำเป็นต้องอยู่ในพื้นที่เก็บข้อมูลถาวรและอาจล้างออกในกรณีที่มีหน่วยความจำไม่พอ

ข้อกำหนดโดยละเอียดของกระบวนการมีดังต่อไปนี้

โหมดรายการในเครื่อง

เมื่อลูกค้าเลือกใช้ Google Safe Browsing v5 ในโหมดนี้ ลักษณะการทำงานของไคลเอ็นต์จะคล้ายกับ API การอัปเดต v4 ยกเว้นการใช้แพลตฟอร์ม API ที่ปรับปรุงใหม่ของ v5 ไคลเอ็นต์จะเก็บรักษาชุดรายการภัยคุกคามไว้ในฐานข้อมูลภายในเครื่องของตนเองที่จัดรูปแบบเป็นคำนำหน้าแฮช SHA256 ของนิพจน์ URL คำนำหน้าโฮสต์/เส้นทาง เมื่อใดก็ตามที่ลูกค้าต้องการตรวจสอบ URL หนึ่ง จะมีการตรวจสอบโดยใช้รายการภัยคุกคามในท้องถิ่น หากมีการจับคู่ที่ตรงกัน ไคลเอ็นต์จะเชื่อมต่อกับเซิร์ฟเวอร์เพื่อตรวจสอบต่อ

เช่นเดียวกับข้อมูลข้างต้น ไคลเอ็นต์จะเก็บรักษาแคชในเครื่องที่ไม่จำเป็นต้องอยู่ในพื้นที่เก็บข้อมูลถาวร

โหมดเรียลไทม์แบบไม่มีพื้นที่เก็บข้อมูล

เมื่อลูกค้าเลือกใช้ Google Safe Browsing v5 ในโหมดเรียลไทม์ที่ไม่ต้องใช้พื้นที่เก็บข้อมูล ลูกค้าไม่จำเป็นต้องรักษาฐานข้อมูลใดๆ ในเครื่อง เมื่อใดก็ตามที่ไคลเอ็นต์ต้องการตรวจสอบ URL ที่ต้องการ ไคลเอ็นต์จะเชื่อมต่อกับเซิร์ฟเวอร์เสมอเพื่อตรวจสอบ โหมดนี้คล้ายกับสิ่งที่ไคลเอ็นต์ของ Lookup API เวอร์ชัน 4 อาจนำไปใช้ได้

กำลังตรวจสอบ URL

ส่วนนี้ประกอบด้วยข้อกำหนดโดยละเอียดเกี่ยวกับวิธีที่ลูกค้าตรวจสอบ URL

การกำหนดหน้า Canonical URL

ก่อนที่จะตรวจสอบ URL ใดๆ ก็ตาม คาดว่าไคลเอ็นต์จะทำการกำหนดหน้า Canonical บางอย่างใน URL นั้น

ในการเริ่มต้น เราสมมติว่าไคลเอ็นต์ได้แยกวิเคราะห์ URL และทำให้ URL ถูกต้องตาม RFC 2396 หาก URL ใช้ชื่อโดเมนสากล (IDN) ไคลเอ็นต์ควรแปลง URL เป็นค่าแทนรหัส ASCII URL ต้องมีคอมโพเนนต์เส้นทาง กล่าวคือ ต้องมีเครื่องหมายทับอย่างน้อย 1 ตัวตามหลังโดเมน (http://google.com/ แทนที่จะเป็น http://google.com)

ขั้นแรก ให้นำอักขระ Tab (0x09), CR (0x0d) และ LF (0x0a) ออกจาก URL อย่านำลำดับหลีกของอักขระเหล่านี้ออก (เช่น %0a)

ขั้นที่สอง หาก URL ลงท้ายด้วย Fragment ให้นำ Fragment ออก เช่น ย่อ http://google.com/#frag เป็น http://google.com/

ขั้นที่สาม ให้คิดเป็นเปอร์เซ็นต์ซ้ำๆ ในการใช้ URL กับ URL จนกว่าจะไม่มีอักขระหลีกอีกต่อไป (การดำเนินการนี้อาจทำให้ URL ไม่ถูกต้อง)

วิธีตั้งค่าให้ชื่อโฮสต์เป็นหน้า Canonical

ดึงข้อมูลชื่อโฮสต์จาก URL แล้วทำดังนี้

1. นำจุดนำหน้าและจุดต่อท้ายออกทั้งหมด
2. แทนที่จุดที่ติดกันด้วยจุดเดียว
3. หากแยกวิเคราะห์ชื่อโฮสต์เป็นที่อยู่ IPv4 ได้ ให้ปรับให้เป็นค่าทศนิยมที่คั่นด้วยจุด 4 จุด ไคลเอ็นต์ควรจัดการกับการเข้ารหัสที่อยู่ IP ตามกฎหมาย ซึ่งรวมถึงเลขฐานแปด ฐานสิบหก และคอมโพเนนต์ไม่เกิน 4 ส่วน
4. หากสามารถแยกวิเคราะห์ชื่อโฮสต์เป็นที่อยู่ IPv6 ในวงเล็บได้ ให้ทำให้เป็นมาตรฐานโดยนำเลข 0 นำหน้าที่ไม่จำเป็นในคอมโพเนนต์ออก และยุบคอมโพเนนต์ 0 โดยใช้ไวยากรณ์เลขโคลอนคู่ เช่น [2001:0db8:0000::1] ควรแปลงเป็น [2001:db8::1] หากชื่อโฮสต์เป็นหนึ่งใน 2 ประเภทที่อยู่ IPv6 พิเศษต่อไปนี้ ให้เปลี่ยนรูปแบบเป็น IPv4
   • ที่อยู่ IPv6 ที่แมป IPv4 เช่น [::ffff:1.2.3.4] ซึ่งควรเปลี่ยนเป็น 1.2.3.4
   • ที่อยู่ NAT64 ที่ใช้คำนำหน้าที่รู้จักกันดี 64:ff9b::/96 เช่น [64:ff9b::1.2.3.4] ซึ่งควรเปลี่ยนเป็น 1.2.3.4
5. ตัวพิมพ์เล็กทั้งสตริง

วิธีตั้งค่าเส้นทางเป็น Canonical

1. จับคู่ลำดับ /../ และ /./ ในเส้นทางโดยแทนที่ /./ ด้วย / และนำ /../ รวมถึงคอมโพเนนต์เส้นทางก่อนหน้าออก
2. แทนที่การเรียกใช้เครื่องหมายทับที่ต่อเนื่องกันด้วยเครื่องหมายทับตัวเดียว

อย่าใช้การกำหนดหน้า Canonical ของเส้นทางเหล่านี้กับพารามิเตอร์การค้นหา

ใน URL ให้ใช้อักขระหลีกทั้งหมดที่เป็น <= ASCII 32, >= 127, # หรือ % ใน URL ส่วนอักขระหลีกควรใช้อักขระเลขฐานสิบหกตัวพิมพ์ใหญ่

นิพจน์คำนำหน้าเส้นทางของโฮสต์-คำต่อท้าย

เมื่อ URL เป็น Canonical แล้ว ขั้นตอนถัดไปคือการสร้างนิพจน์คำต่อท้าย/คำนำหน้า คำต่อท้าย/นิพจน์คำนำหน้าแต่ละรายการประกอบด้วยคำต่อท้ายของโฮสต์ (หรือโฮสต์แบบเต็ม) และคำนำหน้าเส้นทาง (หรือเส้นทางแบบเต็ม)

ไคลเอ็นต์จะสร้างชุดค่าผสมคำต่อท้ายโฮสต์และคำนำหน้าเส้นทางที่เป็นไปได้ที่แตกต่างกันสูงสุด 30 รายการ ชุดค่าผสมเหล่านี้ใช้เฉพาะโฮสต์และคอมโพเนนต์เส้นทางของ URL ระบบจะทิ้งรูปแบบ ชื่อผู้ใช้ รหัสผ่าน และพอร์ต หาก URL มีพารามิเตอร์การค้นหา ชุดค่าผสมอย่างน้อย 1 รายการจะรวมเส้นทางแบบเต็มและพารามิเตอร์การค้นหา

สำหรับโฮสต์ ไคลเอ็นต์จะลองสตริงที่แตกต่างกันไม่เกิน 5 สตริง ปัจจัยต่างๆ มีดังนี้

• หากชื่อโฮสต์ไม่ใช่ IPv4 หรือ IPv6 แบบลิเทอรัล จะมีการสร้างชื่อโฮสต์สูงสุด 4 รายการโดยการเริ่มต้นด้วยโดเมน eTLD+1 และเพิ่มคอมโพเนนต์นําหน้าติดต่อกัน การกำหนด eTLD+1 ควรอิงตามรายการคำต่อท้ายสาธารณะ ตัวอย่างเช่น a.b.example.com จะทำให้ได้โดเมน eTLD+1 ของ example.com รวมถึงโฮสต์ที่มีคอมโพเนนต์โฮสต์เพิ่มเติม 1 รายการ b.example.com
• ชื่อโฮสต์ใน URL ที่ถูกต้อง จากตัวอย่างก่อนหน้านี้ จะมีการเลือก a.b.example.com

สำหรับเส้นทาง ไคลเอ็นต์จะลองสตริงที่แตกต่างกันไม่เกิน 6 สตริง ปัจจัยต่างๆ มีดังนี้

• เส้นทางที่แน่นอนของ URL รวมถึงพารามิเตอร์การค้นหา
• เส้นทางที่แน่นอนของ URL โดยไม่มีพารามิเตอร์การค้นหา
• เส้นทางทั้ง 4 เส้นที่เกิดจากการเริ่มต้นที่ราก (/) และองค์ประกอบเส้นทางต่อๆ มา รวมถึงเครื่องหมายทับปิดท้าย

ตัวอย่างต่อไปนี้จะแสดงลักษณะการตรวจสอบ

สำหรับ URL http://a.b.com/1/2.html?param=1 ไคลเอ็นต์จะลองใช้สตริงที่เป็นไปได้ต่อไปนี้

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

สำหรับ URL http://a.b.c.d.e.f.com/1.html ไคลเอ็นต์จะลองใช้สตริงที่เป็นไปได้ต่อไปนี้

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(หมายเหตุ: ข้าม b.c.d.e.f.com เนื่องจากเราจะเลือกเฉพาะองค์ประกอบของชื่อโฮสต์ 5 รายการสุดท้าย และชื่อโฮสต์แบบเต็ม)

สำหรับ URL http://1.2.3.4/1/ ไคลเอ็นต์จะลองใช้สตริงที่เป็นไปได้ต่อไปนี้

1.2.3.4/1/
1.2.3.4/

สำหรับ URL http://example.co.uk/1 ไคลเอ็นต์จะลองใช้สตริงที่เป็นไปได้ต่อไปนี้

example.co.uk/1
example.co.uk/

การแฮช

Google Safe Browsing จะใช้ SHA256 เป็นฟังก์ชันแฮชโดยเฉพาะ ควรใช้ฟังก์ชันแฮชนี้กับนิพจน์ข้างต้น

แฮชแบบเต็ม 32 ไบต์จะถูกตัดให้เหลือ 4 ไบต์, 8 ไบต์ หรือ 16 ไบต์ ทั้งนี้ขึ้นอยู่กับสถานการณ์

• เมื่อใช้เมธอดhashes.search ปัจจุบันเรากำหนดให้แฮชในคำขอถูกตัดให้เหลือ 4 ไบต์พอดี การส่งไบต์เพิ่มเติมในคำขอนี้จะกระทบต่อความเป็นส่วนตัวของผู้ใช้

• เมื่อดาวน์โหลดรายการสำหรับฐานข้อมูลภายในโดยใช้เมธอดhashList.get หรือเมธอดhashLists.batchGet ความยาวของแฮชที่เซิร์ฟเวอร์ส่งจะขึ้นอยู่กับทั้งลักษณะของรายการและค่ากำหนดความยาวแฮชของไคลเอ็นต์ ซึ่งจะสื่อสารโดยพารามิเตอร์ desired_hash_length

ขั้นตอนการตรวจสอบ URL แบบเรียลไทม์

ใช้กระบวนการนี้เมื่อไคลเอ็นต์เลือกโหมดการทำงานแบบเรียลไทม์

ขั้นตอนนี้จะใช้ URL เดียว u และแสดงผล SAFE, UNSAFE หรือ UNSURE หาก URL แสดงผลเป็น SAFE แสดงว่า Google Safe Browsing ถือว่า URL ปลอดภัย หากแสดงผล UNSAFE กลับเห็นว่า Google Safe Browsing อาจไม่ปลอดภัย URL และควรดำเนินการตามความเหมาะสม เช่น แสดงคำเตือนต่อผู้ใช้ปลายทาง ย้ายข้อความที่ได้รับไปยังโฟลเดอร์จดหมายขยะ หรือกำหนดให้ผู้ใช้ยืนยันเพิ่มเติมก่อนดำเนินการต่อ หากแสดงผลเป็น UNSURE หลังจากนั้น คุณควรใช้ขั้นตอนการตรวจสอบภายในต่อไปนี้

1. กำหนดให้ expressions เป็นรายการของนิพจน์คำต่อท้าย/คำนำหน้าที่ URL u สร้างขึ้น
2. กำหนดให้ expressionHashes เป็นรายการ โดยที่องค์ประกอบคือแฮช SHA256 ของแต่ละนิพจน์ใน expressions
3. สําหรับแต่ละ hash ของ expressionHashes:
   1. หากพบ hash ในแคชส่วนกลาง ให้แสดงผล UNSURE
4. อนุญาตให้ expressionHashPrefixes เป็นรายการโดยที่องค์ประกอบคือ 4 ไบต์แรกของแฮชแต่ละรายการใน expressionHashes
5. สําหรับแต่ละ expressionHashPrefix ของ expressionHashPrefixes:
   1. ค้นหา expressionHashPrefix ในแคชในเครื่อง
   2. หากพบรายการที่แคชไว้ ให้ทำดังนี้
      1. พิจารณาว่าเวลาปัจจุบันมากกว่าเวลาหมดอายุหรือไม่
      2. หากจำนวนมากกว่า:
         1. ลบรายการที่แคชไว้ที่พบออกจากแคชในเครื่อง
         2. วนซ้ำเรื่อยๆ
      3. หากค่าไม่มากกว่า:
         1. นำ expressionHashPrefix นี้ออกจาก expressionHashPrefixes
         2. ตรวจสอบว่าพบแฮชแบบเต็มที่เกี่ยวข้องภายใน expressionHashes ในรายการที่แคชไว้หรือไม่
         3. หากพบ ให้แสดงผล UNSAFE
         4. หากไม่พบ ให้ดำเนินการต่อด้วยการวนซ้ำ
   3. หากไม่พบรายการที่แคชไว้ ให้ดำเนินการต่อด้วยการวนซ้ำ
6. ส่ง expressionHashPrefixes ไปยังเซิร์ฟเวอร์ Google Safe Browsing v5 โดยใช้ RPC SearchHashes หรือเมธอด REST hashes.search หากเกิดข้อผิดพลาด (รวมถึงข้อผิดพลาดเกี่ยวกับเครือข่าย ข้อผิดพลาดของ HTTP ฯลฯ) ให้แสดงผล UNSURE มิเช่นนั้น ให้ตอบกลับเป็น response ที่ได้รับจากเซิร์ฟเวอร์ SB ซึ่งเป็นรายการแฮชแบบเต็มพร้อมด้วยข้อมูลเสริมบางส่วนที่ระบุลักษณะของภัยคุกคาม (วิศวกรรมสังคม มัลแวร์ ฯลฯ) รวมถึงเวลาหมดอายุของแคช expiration
7. สําหรับแต่ละ fullHash ของ response:
   1. แทรก fullHash ลงในแคชในเครื่องพร้อมด้วย expiration
8. สําหรับแต่ละ fullHash ของ response:
   1. ให้ isFound เป็นผลลัพธ์ของการค้นหา fullHash ใน expressionHashes
   2. หาก isFound เป็น "เท็จ" ให้เล่นวนซ้ำต่อไป
   3. หาก isFound เป็น "จริง" ให้แสดงผล UNSAFE
9. กลับ SAFE

ขั้นตอนการตรวจสอบ URL ของรายการ LocalThreat

ใช้กระบวนการนี้เมื่อไคลเอ็นต์เลือกใช้โหมดรายการในเครื่อง และยังใช้กับไคลเอ็นต์ที่ขั้นตอน RealTimeCheck ข้างต้นแสดงผลค่า UNSURE ด้วย

ขั้นตอนนี้จะใช้ URL เดียว u และแสดงผล SAFE หรือ UNSAFE

1. กำหนดให้ expressions เป็นรายการของนิพจน์คำต่อท้าย/คำนำหน้าที่ URL u สร้างขึ้น
2. กำหนดให้ expressionHashes เป็นรายการ โดยที่องค์ประกอบคือแฮช SHA256 ของแต่ละนิพจน์ใน expressions
3. อนุญาตให้ expressionHashPrefixes เป็นรายการโดยที่องค์ประกอบคือ 4 ไบต์แรกของแฮชแต่ละรายการใน expressionHashes
4. สําหรับแต่ละ expressionHashPrefix ของ expressionHashPrefixes:
   1. ค้นหา expressionHashPrefix ในแคชในเครื่อง
   2. หากพบรายการที่แคชไว้ ให้ทำดังนี้
      1. พิจารณาว่าเวลาปัจจุบันมากกว่าเวลาหมดอายุหรือไม่
      2. หากจำนวนมากกว่า:
         1. ลบรายการที่แคชไว้ที่พบออกจากแคชในเครื่อง
         2. วนซ้ำเรื่อยๆ
      3. หากค่าไม่มากกว่า:
         1. นำ expressionHashPrefix นี้ออกจาก expressionHashPrefixes
         2. ตรวจสอบว่าพบแฮชแบบเต็มที่เกี่ยวข้องภายใน expressionHashes ในรายการที่แคชไว้หรือไม่
         3. หากพบ ให้แสดงผล UNSAFE
         4. หากไม่พบ ให้ดำเนินการต่อด้วยการวนซ้ำ
   3. หากไม่พบรายการที่แคชไว้ ให้ดำเนินการต่อด้วยการวนซ้ำ
5. สําหรับแต่ละ expressionHashPrefix ของ expressionHashPrefixes:
   1. ค้นหา expressionHashPrefix ในฐานข้อมูลรายการภัยคุกคามในเครื่อง
   2. หากไม่พบ expressionHashPrefix ในฐานข้อมูลรายการภัยคุกคามในท้องถิ่น ให้นำรายการดังกล่าวออกจาก expressionHashPrefixes
6. ส่ง expressionHashPrefixes ไปยังเซิร์ฟเวอร์ Google Safe Browsing v5 โดยใช้ RPC SearchHashes หรือเมธอด REST hashes.search หากเกิดข้อผิดพลาด (รวมถึงข้อผิดพลาดเกี่ยวกับเครือข่าย ข้อผิดพลาดของ HTTP ฯลฯ) ให้แสดงผล SAFE มิเช่นนั้น ให้ตอบกลับเป็น response ที่ได้รับจากเซิร์ฟเวอร์ SB ซึ่งเป็นรายการแฮชแบบเต็มพร้อมด้วยข้อมูลเสริมบางส่วนที่ระบุลักษณะของภัยคุกคาม (วิศวกรรมสังคม มัลแวร์ ฯลฯ) รวมถึงเวลาหมดอายุของแคช expiration
7. สําหรับแต่ละ fullHash ของ response:
   1. แทรก fullHash ลงในแคชในเครื่องพร้อมด้วย expiration
8. สําหรับแต่ละ fullHash ของ response:
   1. ให้ isFound เป็นผลลัพธ์ของการค้นหา fullHash ใน expressionHashes
   2. หาก isFound เป็น "เท็จ" ให้เล่นวนซ้ำต่อไป
   3. หาก isFound เป็น "จริง" ให้แสดงผล UNSAFE
9. กลับ SAFE

ขั้นตอนการตรวจสอบ URL แบบเรียลไทม์ที่ไม่มีฐานข้อมูลในเครื่อง

ใช้กระบวนการนี้เมื่อไคลเอ็นต์เลือกโหมดการทำงานแบบเรียลไทม์ที่ไม่ใช้พื้นที่เก็บข้อมูล

ขั้นตอนนี้จะใช้ URL เดียว u และแสดงผล SAFE หรือ UNSAFE

1. กำหนดให้ expressions เป็นรายการของนิพจน์คำต่อท้าย/คำนำหน้าที่ URL u สร้างขึ้น
2. กำหนดให้ expressionHashes เป็นรายการ โดยที่องค์ประกอบคือแฮช SHA256 ของแต่ละนิพจน์ใน expressions
3. อนุญาตให้ expressionHashPrefixes เป็นรายการโดยที่องค์ประกอบคือ 4 ไบต์แรกของแฮชแต่ละรายการใน expressionHashes
4. สําหรับแต่ละ expressionHashPrefix ของ expressionHashPrefixes:
   1. ค้นหา expressionHashPrefix ในแคชในเครื่อง
   2. หากพบรายการที่แคชไว้ ให้ทำดังนี้
      1. พิจารณาว่าเวลาปัจจุบันมากกว่าเวลาหมดอายุหรือไม่
      2. หากจำนวนมากกว่า:
         1. ลบรายการที่แคชไว้ที่พบออกจากแคชในเครื่อง
         2. วนซ้ำเรื่อยๆ
      3. หากค่าไม่มากกว่า:
         1. นำ expressionHashPrefix นี้ออกจาก expressionHashPrefixes
         2. ตรวจสอบว่าพบแฮชแบบเต็มที่เกี่ยวข้องภายใน expressionHashes ในรายการที่แคชไว้หรือไม่
         3. หากพบ ให้แสดงผล UNSAFE
         4. หากไม่พบ ให้ดำเนินการต่อด้วยการวนซ้ำ
   3. หากไม่พบรายการที่แคชไว้ ให้ดำเนินการต่อด้วยการวนซ้ำ
5. ส่ง expressionHashPrefixes ไปยังเซิร์ฟเวอร์ Google Safe Browsing v5 โดยใช้ RPC SearchHashes หรือเมธอด REST hashes.search หากเกิดข้อผิดพลาด (รวมถึงข้อผิดพลาดเกี่ยวกับเครือข่าย ข้อผิดพลาดของ HTTP ฯลฯ) ให้แสดงผล SAFE มิเช่นนั้น ให้ตอบกลับเป็น response ที่ได้รับจากเซิร์ฟเวอร์ SB ซึ่งเป็นรายการแฮชแบบเต็มพร้อมด้วยข้อมูลเสริมบางส่วนที่ระบุลักษณะของภัยคุกคาม (วิศวกรรมสังคม มัลแวร์ ฯลฯ) รวมถึงเวลาหมดอายุของแคช expiration
6. สําหรับแต่ละ fullHash ของ response:
   1. แทรก fullHash ลงในแคชในเครื่องพร้อมด้วย expiration
7. สําหรับแต่ละ fullHash ของ response:
   1. ให้ isFound เป็นผลลัพธ์ของการค้นหา fullHash ใน expressionHashes
   2. หาก isFound เป็น "เท็จ" ให้เล่นวนซ้ำต่อไป
   3. หาก isFound เป็น "จริง" ให้แสดงผล UNSAFE
8. กลับ SAFE

การบำรุงรักษาฐานข้อมูลในเครื่อง

Google Safe Browsing v5 คาดหวังว่าไคลเอ็นต์จะรักษาฐานข้อมูลไว้ในเครื่อง ยกเว้นในกรณีที่ลูกค้าเลือกโหมดเรียลไทม์แบบไม่มีพื้นที่เก็บข้อมูล ขึ้นอยู่กับไคลเอ็นต์รูปแบบและพื้นที่เก็บข้อมูลของฐานข้อมูลในเครื่องนี้ เนื้อหาในฐานข้อมูลภายในนี้จะมองตามแนวคิดว่าเป็นโฟลเดอร์ที่มีลิสต์ต่างๆ เป็นไฟล์ และเนื้อหาของไฟล์เหล่านี้คือแฮช SHA256 หรือคํานําหน้าแฮช

การอัปเดตฐานข้อมูล

ไคลเอ็นต์จะเรียกใช้เมธอดhashList.get หรือเมธอด hashLists.batchGet เป็นประจำเพื่ออัปเดตฐานข้อมูล เนื่องจากลูกค้าทั่วไปจะต้องการอัปเดตหลายรายการพร้อมกัน เราขอแนะนำให้ใช้เมธอดhashLists.batchGet

รายการจะระบุตามชื่อที่ต่างกัน ชื่อเป็นสตริง ASCII สั้นๆ ที่มีความยาว 2-3 อักขระ

ซึ่งแตกต่างจาก V4 ที่รายการจะระบุด้วยกลุ่มของประเภทภัยคุกคาม ประเภทแพลตฟอร์ม และประเภทรายการภัยคุกคาม ในรายการ v5 จะระบุเพียงด้วยชื่อ ซึ่งจะช่วยให้มีความยืดหยุ่นเมื่อรายการ v5 หลายรายการสามารถแชร์ภัยคุกคามประเภทเดียวกันได้ ประเภทแพลตฟอร์มและประเภทรายการภัยคุกคามจะถูกนำออกใน v5

เมื่อเลือกชื่อสำหรับรายการแล้ว จะไม่มีการเปลี่ยนชื่ออีก นอกจากนี้ เมื่อรายการปรากฏขึ้น ระบบจะไม่นำรายการออก (หากรายการไม่มีประโยชน์อีกแล้ว รายการดังกล่าวก็จะว่างเปล่าและยังคงมีอยู่ต่อไป) ดังนั้น จึงสมควรที่จะฮาร์ดโค้ดชื่อเหล่านี้ในรหัสไคลเอ็นต์ของ Google Safe Browsing

ทั้งเมธอด hashList.get และเมธอด hashLists.batchGet จะรองรับการอัปเดตเพิ่มเติม การใช้การอัปเดตที่เพิ่มขึ้นจะช่วยประหยัดแบนด์วิดท์และปรับปรุงประสิทธิภาพ การอัปเดตส่วนเพิ่มทำงานโดยการส่งเดลต้าระหว่างรายการเวอร์ชันของไคลเอ็นต์กับรายการเวอร์ชันล่าสุด (หากไคลเอ็นต์มีการติดตั้งใช้งานใหม่และไม่มีเวอร์ชันใดเลย ก็จะมีอัปเดตพร้อมใช้งาน) การอัปเดตที่เพิ่มขึ้นมีดัชนีการลบและการเพิ่ม ก่อนอื่น ไคลเอ็นต์จะต้องนำรายการที่ดัชนีที่ระบุออกจากฐานข้อมูลภายในเครื่อง จากนั้นจึงนำการเพิ่มออก

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

การถอดรหัสเนื้อหารายการ

รายการทั้งหมดถูกส่งโดยใช้การเข้ารหัสพิเศษเพื่อลดขนาด การเข้ารหัสนี้ทำงานโดยการยอมรับว่ารายการ Google Safe Browsing มีชุดแฮชหรือคำนำหน้าแฮช ซึ่งไม่สามารถแยกแยะความแตกต่างทางสถิติออกจากจำนวนเต็มแบบสุ่มได้ หากเราจัดเรียงจำนวนเต็มเหล่านี้และใช้ผลต่างที่มีติดกัน ค่าต่างที่อยู่ติดกันก็ควรจะมีค่าเป็น "เล็ก" เช่นกัน การเข้ารหัสแบบ Golomb-Rice แล้วใช้ประโยชน์จากความเล็กๆ นี้

Google Safe Browsing v5 มี 4 ประเภทที่แตกต่างกันในการจัดการข้อมูล 4 ไบต์, ข้อมูล 8 ไบต์, ข้อมูล 16 ไบต์ และข้อมูล 32 ไบต์ มาดูตัวอย่างกันที่เข้ารหัสจำนวนเต็ม 4 ไบต์ที่มีตัวเลขติดกัน 3 ตัว กำหนดให้พารามิเตอร์ Rice ซึ่งแสดงด้วย k เป็น 3 ส่วนผลหารของการเข้ารหัสคือค่าผลต่างที่อยู่ติดกันซึ่งเลื่อนไปทางขวาทีละ k บิต เนื่องจากจำนวนเต็มที่ระบุจะติดต่อกัน ผลต่างที่อยู่ติดกันจึงเท่ากับ 1 และหลังจากเลื่อนทีละ 3 บิต ส่วนผลหารจะเป็น 0 บิต k ที่มีนัยสำคัญน้อยที่สุดคือ 001 ผลหารศูนย์มีการเข้ารหัสเป็น 0 บิตเดียว ส่วนที่เหลือคือ 1 และเข้ารหัสเป็น 100 ซึ่งจะทำซ้ำอีกครั้งเพื่อสร้างบิตสตรีม 01000100 บิตสตรีมที่ได้จะได้รับการเข้ารหัสโดยใช้ Little Endian เป็น 00100010 ดังนั้น จึงสอดคล้องกับข้อมูลต่อไปนี้

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

หลังจากขั้นตอนการถอดรหัสข้างต้นสำหรับจำนวนเต็ม 32 บิต ผลลัพธ์จะใช้ได้โดยตรงเป็นดัชนีการนำออกหรือการเพิ่ม ซึ่งต่างจาก v4 ตรงที่ไม่จำเป็นต้องสลับไบต์ในภายหลัง

รายการที่ใช้ได้

เราขอแนะนำให้ใช้รายการต่อไปนี้ใน v5alpha1:

ชื่อรายการ	แจกแจง ThreatType ที่สอดคล้องกัน v4	คำอธิบาย
gc	ไม่มี	รายการนี้เป็นรายการแคชส่วนกลาง ซึ่งเป็นรายการพิเศษที่ใช้ในโหมดการทำงานแบบเรียลไทม์เท่านั้น
se	SOCIAL_ENGINEERING	รายการนี้มีภัยคุกคามของประเภทภัยคุกคาม SOCIAL_ENGINEERING
mw	MALWARE	รายการนี้มีภัยคุกคามประเภทภัยคุกคาม MALWARE สำหรับแพลตฟอร์มเดสก์ท็อป
uws	UNWANTED_SOFTWARE	รายการนี้มีภัยคุกคามประเภทภัยคุกคาม UNWANTED_SOFTWARE สำหรับแพลตฟอร์มเดสก์ท็อป
uwsa	UNWANTED_SOFTWARE	รายการนี้มีภัยคุกคามประเภทภัยคุกคาม UNWANTED_SOFTWARE สำหรับแพลตฟอร์ม Android
pha	POTENTIALLY_HARMFUL_APPLICATION	รายการนี้มีภัยคุกคามของประเภทภัยคุกคาม POTENTIALLY_HARMFUL_APPLICATION สำหรับแพลตฟอร์ม Android

เราจะดูรายการเพิ่มเติมได้ในภายหลัง โดยจะขยายตารางด้านบน

ความถี่ในการอัปเดต

ไคลเอ็นต์ควรตรวจสอบค่าที่ส่งคืนของเซิร์ฟเวอร์ในช่อง minimum_wait_duration และใช้เพื่อกำหนดเวลาการอัปเดตฐานข้อมูลครั้งถัดไป ค่านี้อาจเป็น 0 ซึ่งในกรณีนี้ไคลเอ็นต์ควรจะดำเนินการอัปเดตอีกครั้งทันที

ตัวอย่างคำขอ

ส่วนนี้แสดงตัวอย่างเกี่ยวกับการใช้ HTTP API โดยตรงเพื่อเข้าถึง Google Safe Browsing โดยทั่วไป ขอแนะนําให้ใช้การเชื่อมโยงภาษาที่สร้างขึ้น เนื่องจากจะจัดการการเข้ารหัสและถอดรหัสโดยอัตโนมัติให้สะดวก โปรดอ่านเอกสารประกอบสำหรับการเชื่อมโยงนั้น

ต่อไปนี้คือตัวอย่างคำขอ HTTP ที่ใช้เมธอดhashes.search

GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ

ส่วนเนื้อหาการตอบสนองเป็นเพย์โหลดที่มีการจัดรูปแบบบัฟเฟอร์โปรโตคอลที่คุณอาจถอดรหัสได้

ต่อไปนี้คือตัวอย่างคำขอ HTTP ที่ใช้เมธอด hashLists.batchGet

GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw

ส่วนเนื้อหาการตอบสนองจะเป็นเพย์โหลดที่มีการจัดรูปแบบบัฟเฟอร์โปรโตคอลซึ่งคุณถอดรหัสได้

คำแนะนำในการย้ายข้อมูล

หากคุณกำลังใช้ v4 Update API อยู่ เส้นทางการย้ายข้อมูลจาก v4 ไปยัง v5 จะเป็นไปอย่างราบรื่นโดยไม่ต้องรีเซ็ตหรือลบฐานข้อมูลของเครื่อง ส่วนนี้จะกล่าวถึงวิธีการในการดำเนินการดังกล่าว

กำลังแปลงการอัปเดตรายการ

ในเวอร์ชัน 4 จะใช้เมธอด threatListUpdates.fetch เพื่อดาวน์โหลดรายการ ใน v5 ผู้ใช้จะเปลี่ยนไปใช้เมธอด hashLists.batchGet

คุณควรทำการเปลี่ยนแปลงต่อไปนี้ในคำขอ

1. นำออบเจ็กต์ v4 ClientInfo ออกทั้งหมด ใช้ส่วนหัว User-Agent ที่รู้จักกันดี แทนที่จะต้องใส่ข้อมูลระบุตัวตนของลูกค้าโดยใช้ช่องเฉพาะ แม้ว่าจะไม่มีรูปแบบที่กำหนดสำหรับการระบุไคลเอ็นต์ในส่วนหัวนี้ แต่ขอแนะนำให้ใส่รหัสไคลเอ็นต์เดิมและเวอร์ชันไคลเอ็นต์โดยคั่นด้วยการเว้นวรรคหรือเครื่องหมายทับ
2. สำหรับออบเจ็กต์ ListUpdateRequest v4 แต่ละรายการ ให้ทำดังนี้
   • ค้นหาชื่อรายการ v5 ที่เกี่ยวข้องในตารางด้านบน และใส่ชื่อนั้นในคำขอ v5
   • นำช่องที่ไม่จำเป็นออก เช่น threat_entry_type หรือ platform_type
   • ฟิลด์ state ใน v4 สามารถใช้ร่วมกับช่อง versions ของ v5 ได้โดยตรง สตริงไบต์เดียวกันที่ส่งไปยังเซิร์ฟเวอร์โดยใช้ช่อง state ใน v4 จะส่งได้ง่ายๆ ใน v5 โดยใช้ช่อง versions
   • สำหรับข้อจำกัด v4 นั้น v5 จะใช้เวอร์ชันที่เรียบง่ายเรียกว่า SizeConstraints ควรเว้นช่องเพิ่มเติม เช่น region

ควรทำการเปลี่ยนแปลงต่อไปนี้กับคำตอบ

1. แทนที่ enum ResponseType v4 ด้วยช่องบูลีนที่มีชื่อว่า partial_update
2. ในตอนนี้ ช่อง minimum_wait_duration สามารถเป็น 0 หรือละเว้นได้ ซึ่งหากเป็นเช่นนั้น ระบบจะขอให้ลูกค้าส่งคำขออีกครั้งทันที กรณีนี้จะเกิดขึ้นเมื่อไคลเอ็นต์ระบุว่าขนาดการอัปเดตสูงสุดน้อยกว่าขนาดฐานข้อมูลสูงสุดใน SizeConstraints
3. จะต้องมีการปรับอัลกอริทึมการถอดรหัส Rice สำหรับจำนวนเต็ม 32 บิต สิ่งที่แตกต่างคือข้อมูลที่เข้ารหัสจะมีการเข้ารหัสด้วยปลายทางที่แตกต่างกัน คำนำหน้าแฮชแบบ 32 บิตจะจัดเรียงแบบพจนานุกรมทั้งใน v4 และ v5 แต่ใน v4 คำนำหน้าเหล่านั้นจะถือเป็น endian เล็กเมื่อจัดเรียง ขณะที่ใน v5 คำนำหน้าเหล่านั้นจะถือว่าเป็น Big Endian เมื่อจัดเรียง ซึ่งหมายความว่าลูกค้าไม่ต้องจัดเรียงใดๆ เนื่องจากการจัดเรียงแบบพจนานุกรมจะเหมือนกับการจัดเรียงตัวเลขด้วย Big Endian ดูตัวอย่างประเภทนี้ในการใช้งาน Chromium ของ v4 ได้ที่นี่ และนำการจัดเรียงลักษณะนี้ออกได้
4. ต้องใช้อัลกอริทึมการถอดรหัสข้าวสำหรับความยาวแฮชอื่นๆ

การแปลงการค้นหาแฮช

ในเวอร์ชัน 4 จะใช้เมธอดfullHashes.find เพื่อรับแฮชแบบเต็ม เมธอดที่เทียบเท่าใน v5 คือเมธอดแฮชes.search

คุณควรทำการเปลี่ยนแปลงต่อไปนี้ในคำขอ

1. จัดโครงสร้างโค้ดให้ส่งเฉพาะคำนำหน้าแฮชที่มีความยาว 4 ไบต์พอดี
2. นำออบเจ็กต์ v4 ClientInfo ออกทั้งหมด ใช้ส่วนหัว User-Agent ที่รู้จักกันดี แทนที่จะต้องใส่ข้อมูลระบุตัวตนของลูกค้าโดยใช้ช่องเฉพาะ แม้ว่าจะไม่มีรูปแบบที่กำหนดสำหรับการระบุไคลเอ็นต์ในส่วนหัวนี้ แต่ขอแนะนำให้ใส่รหัสไคลเอ็นต์เดิมและเวอร์ชันไคลเอ็นต์โดยคั่นด้วยการเว้นวรรคหรือเครื่องหมายทับ
3. โปรดนำช่อง client_states ออก จึงไม่จำเป็นอีกต่อไป
4. ไม่จำเป็นต้องรวม threat_types และช่องที่คล้ายกันอีก

ควรทำการเปลี่ยนแปลงต่อไปนี้กับคำตอบ

1. นำช่อง minimum_wait_duration ออกแล้ว ลูกค้าสามารถส่งคําขอใหม่ได้ทุกเมื่อตามต้องการ
2. มีการลดความซับซ้อนของออบเจ็กต์ v4 ThreatMatch เป็นออบเจ็กต์ FullHash
3. การแคชมีการปรับให้ง่ายขึ้นเป็นระยะเวลาแคชเดียว ดูขั้นตอนด้านบนสำหรับการโต้ตอบกับแคช