Overview

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

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

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

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

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

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

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

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

ราคา

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

โควต้า

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

URL ที่เหมาะสม

Google Safe Browsing ออกแบบมาเพื่อดำเนินการกับ URL ที่จะแสดงในแถบที่อยู่ของเบราว์เซอร์ แต่ไม่ได้ออกแบบมาเพื่อใช้ตรวจสอบกับทรัพยากรย่อย (เช่น JavaScript หรือรูปภาพที่อ้างอิงโดยไฟล์ HTML หรือ URL ของ WebSocket ที่เริ่มต้นโดย 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 ในโหมดแบบเรียลไทม์ ไคลเอ็นต์จะรักษาสิ่งต่อไปนี้ในฐานข้อมูลในเครื่องของตน (1) แคชส่วนกลางของเว็บไซต์ที่ไม่เป็นอันตราย ซึ่งจัดรูปแบบเป็นแฮช SHA256 ของนิพจน์ URL คำนำหน้าโฮสต์/คำต่อท้ายเส้นทาง (2) ชุดรายการภัยคุกคามที่จัดรูปแบบเป็นคำนำหน้าแฮช SHA256 ของนิพจน์ URL คำนำหน้าโฮสต์/คำต่อท้ายเส้นทาง แนวคิดระดับสูงก็คือเมื่อใดก็ตามที่ไคลเอ็นต์ต้องการตรวจสอบ URL หนึ่งๆ จะมีการตรวจสอบในเครื่องโดยใช้แคชส่วนกลาง หากการตรวจสอบผ่าน ระบบจะตรวจสอบรายการภัยคุกคามในพื้นที่ ไม่เช่นนั้น ไคลเอ็นต์จะดำเนินการต่อด้วยการตรวจสอบแฮชแบบเรียลไทม์ตามรายละเอียดด้านล่าง

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

โปรดดูรายละเอียดของกระบวนการนี้ด้านล่าง

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

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

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

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

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

เมื่อใดก็ตามที่ไคลเอ็นต์ต้องการตรวจสอบ URL หนึ่งๆ ไคลเอ็นต์จะเชื่อมต่อกับเซิร์ฟเวอร์เสมอเพื่อทำการตรวจสอบ โหมดนี้จะคล้ายกับไคลเอ็นต์ของ Lookup API v4 อาจใช้

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

การกำหนดหน้า Canonical ของ URL

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

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

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

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

ข้อที่ 3 ให้ Percent-unEscape กับ URL ซ้ำๆ จนกว่าจะไม่มี Escape เป็นเปอร์เซ็นต์แล้ว (วิธีนี้อาจทำให้ URL แสดงผลไม่ถูกต้อง)

วิธีกำหนดหน้า Canonical ของชื่อโฮสต์

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

1. นำจุดนำหน้าและจุดต่อท้ายออกทั้งหมด
2. แทนที่จุดติดกันด้วยจุดเดียว
3. หากแยกวิเคราะห์ชื่อโฮสต์เป็นที่อยู่ IPv4 ได้ ให้ปรับค่าดังกล่าวเป็นค่าทศนิยมที่คั่นด้วยจุด 4 จุด ไคลเอ็นต์ควรจัดการการเข้ารหัสที่อยู่ IP ตามกฎหมาย ซึ่งรวมถึงเลขฐานแปด เลขฐานสิบหก และองค์ประกอบน้อยกว่า 4 ส่วน
4. หากชื่อโฮสต์สามารถแยกวิเคราะห์เป็นที่อยู่ IPv6 ในวงเล็บได้ ให้ทำการปรับให้เป็นมาตรฐานโดยการนำเลขศูนย์นำหน้าที่ไม่จำเป็นในคอมโพเนนต์ออก และยุบคอมโพเนนต์ 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 หลีกควรใช้อักขระเลขฐาน 16 ตัวพิมพ์ใหญ่

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

เมื่อ 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 หากแสดงผล 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

แม้ว่าโปรโตคอลนี้จะระบุเวลาที่ไคลเอ็นต์ส่ง expressionHashPrefixes ไปยังเซิร์ฟเวอร์ แต่โปรโตคอลนี้จะไม่ได้ระบุวิธีส่งอย่างชัดเจน ตัวอย่างเช่น ไคลเอ็นต์จะส่ง expressionHashPrefixes ทั้งหมดในคำขอเดียวได้ และไคลเอ็นต์จะส่งคำนำหน้าแต่ละรายการใน expressionHashPrefixes ไปยังเซิร์ฟเวอร์ในคำขอแยกกันได้ด้วย (อาจดำเนินการพร้อมกัน) ไคลเอ็นต์สามารถส่งคำนำหน้าแฮชที่ไม่เกี่ยวข้องหรือที่สร้างขึ้นแบบสุ่มร่วมกับคำนำหน้าแฮชใน expressionHashPrefixes ได้ ตราบใดที่จำนวนของคำนำหน้าแฮชที่ส่งในคำขอเดียวไม่เกิน 30

ขั้นตอนการตรวจสอบ 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

กระบวนการนี้ไม่ได้ระบุวิธีส่งคำนำหน้าแฮชไปยังเซิร์ฟเวอร์เช่นเดียวกับขั้นตอนการตรวจสอบ URL แบบเรียลไทม์ ตัวอย่างเช่น ไคลเอ็นต์จะส่ง expressionHashPrefixes ทั้งหมดในคำขอเดียวได้ และไคลเอ็นต์จะส่งคำนำหน้าแต่ละรายการใน expressionHashPrefixes ไปยังเซิร์ฟเวอร์ในคำขอแยกกันได้ด้วย (อาจดำเนินการพร้อมกัน) ไคลเอ็นต์สามารถส่งคำนำหน้าแฮชที่ไม่เกี่ยวข้องหรือที่สร้างขึ้นแบบสุ่มร่วมกับคำนำหน้าแฮชใน expressionHashPrefixes ได้ ตราบใดที่จำนวนของคำนำหน้าแฮชที่ส่งในคำขอเดียวไม่เกิน 30

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

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

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

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

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

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

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

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

291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc  a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c  b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03  y.example.com/

001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part

00111010001001001111011010001101110010111110100100000000001110100

0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100

01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000

additions_four_bytes {
  first_value: 489866504
  rice_parameter: 30
  entries_count: 2
  encoded_data: "t\000\322\227\033\355It\000"
}

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

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

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

โดยอนุญาตให้ไคลเอ็นต์ควบคุมพร็อกซีเซิร์ฟเวอร์การแคชเพื่อเรียกรายการข้างต้นบางส่วนหรือทั้งหมด จากนั้นให้ไคลเอ็นต์ติดต่อพร็อกซีเซิร์ฟเวอร์ หากเป็นเช่นนี้ เราขอแนะนำให้กำหนดระยะเวลาแคชสั้นๆ เช่น 5 นาที ในอนาคต อาจมีการสื่อสารระยะเวลาของแคชนี้โดยใช้ส่วนหัว HTTP Cache-Control มาตรฐาน

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

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

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

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

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

1. นําออบเจ็กต์ ClientInfo V4 ออกทั้งหมด แทนที่จะให้ข้อมูลประจำตัวของลูกค้าโดยใช้ช่องเฉพาะ ให้ใช้ส่วนหัว User-Agent ที่รู้จักกันดี แม้ว่าจะไม่มีรูปแบบที่กําหนดไว้สําหรับการระบุไคลเอ็นต์ในส่วนหัวนี้ เราขอแนะนําให้รวมรหัสไคลเอ็นต์เดิมและเวอร์ชันไคลเอ็นต์โดยคั่นด้วยการเว้นวรรคหรือเครื่องหมายทับ
2. สำหรับออบเจ็กต์ ListUpdateRequestv4 แต่ละรายการ
   • ค้นหาชื่อรายการ 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 บิต ความแตกต่างคือข้อมูลที่เข้ารหัสมีการเข้ารหัสด้วยปลายทางที่ต่างกัน ทั้งในเวอร์ชัน v4 และ v5 คำนำหน้าแฮช 32 บิตจะจัดเรียงแบบพจนานุกรม แต่ใน v4 คำนำหน้าเหล่านี้จะถูกจัดว่าเป็นค่า endian เล็กเมื่อจัดเรียง ขณะที่ใน v5 คำนำหน้าเหล่านั้นจะถูกจัดว่าเป็น Big Endian เมื่อจัดเรียง ซึ่งหมายความว่าไคลเอ็นต์ไม่จำเป็นต้องจัดเรียงใดๆ เนื่องจากการจัดเรียงคลังศัพท์จะเหมือนกับการจัดเรียงตัวเลขด้วย Big Endian ดูตัวอย่างการจัดเรียงนี้ในการใช้งาน Chromium v4 ได้ที่นี่ การจัดเรียงดังกล่าวสามารถนำออกได้
4. ต้องใช้อัลกอริทึมการถอดรหัส Rice สำหรับความยาวแฮชอื่นๆ

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

ใน v4 ผู้ใช้จะใช้เมธอดfullHashes.find เพื่อรับแฮชแบบเต็ม เมธอดที่เทียบเท่าใน v5 คือเมธอด Hases.search

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

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

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

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