Overview

เกริ่นนำ

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

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

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

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

การปรับปรุงที่สำคัญอย่างหนึ่งของ 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 จะไม่มีการส่งที่อยู่ IP ของผู้ใช้ปลายทางไปยัง Google อีกต่อไป

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

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

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

ราคา

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 ให้ลูกค้าเลือกการทำงานได้จาก 3 โหมดการทำงาน

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

เมื่อลูกค้าเลือกใช้ 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 อาจใช้

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

การตรวจสอบ URL

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

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

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

ในการเริ่มต้น เราสมมติว่าไคลเอ็นต์ได้แยกวิเคราะห์ URL และทำให้ URL ถูกต้องตาม RFC 2396 หาก URL ใช้ชื่อโดเมนสากล (IDN) ไคลเอ็นต์ควรแปลง URL เป็นตัวแทน ASCII Puycode URL ต้องมีคอมโพเนนต์เส้นทาง กล่าวคือ 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

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

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

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

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

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

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

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

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

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

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

การถอดรหัสแฮชและคำนำหน้าแฮช

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

สมมติว่า ระบบจะส่งนิพจน์คำนำหน้าเส้นทางของโฮสต์ 3 รายการ ได้แก่ a.example.com/, b.example.com/ และ y.example.com/ โดยใช้คำนำหน้าแฮช 4 ไบต์ นอกจากนี้ สมมติว่าพารามิเตอร์ Rice ที่แสดงด้วย k นั้นได้รับเลือกให้เป็น 30 เซิร์ฟเวอร์จะเริ่มต้นด้วยการคํานวณแฮชแบบเต็มสําหรับสตริงเหล่านี้ ตามลําดับ

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

จากนั้นเซิร์ฟเวอร์จะสร้างคำนำหน้าแฮช 4 ไบต์สำหรับข้อมูลข้างต้นแต่ละรายการ ซึ่งก็คือ 4 ไบต์แรกของแฮชแบบเต็มขนาด 32 ไบต์ที่ระบบจะตีความว่าเป็นจำนวนเต็ม 32 บิตสำหรับบิ๊กเอนด์ Big Endianness หมายถึงข้อเท็จจริงที่ว่าไบต์แรกของแฮชแบบเต็มจะกลายเป็นไบต์ที่สำคัญที่สุดของจำนวนเต็ม 32 บิต ขั้นตอนนี้จะเป็นจํานวนเต็ม 0x291bc542, 0x1d32c508 และ 0xf7a502e5

เซิร์ฟเวอร์จำเป็นต้องจัดเรียงคำนำหน้าแฮช 3 อันนี้แบบพจนานุกรม (เทียบได้กับการจัดเรียงตัวเลขใน Big Endian) และผลของการจัดเรียงคือ 0x1d32c508, 0x291bc542, 0xf7a502e5 ระบบเก็บคำนำหน้าแฮชแรกไว้ในช่อง first_value โดยไม่มีการเปลี่ยนแปลง

จากนั้นเซิร์ฟเวอร์จะคำนวณความแตกต่างที่อยู่ติดกัน 2 ค่า ได้แก่ 0xbe9003a และ 0xce893da3 ตามลำดับ เมื่อเลือก k ให้เป็น 30 เซิร์ฟเวอร์จะแยกตัวเลข 2 จำนวนนี้ไปยังส่วนผลหารและส่วนเศษเหลือที่มีความยาว 2 และ 30 บิตตามลำดับ สำหรับจำนวนแรก ส่วนที่เป็นผลหารคือ 0 และเศษเหลือคือ 0xbe9003a สำหรับจำนวนที่สอง ส่วนที่เป็นผลหารคือ 3 เนื่องจากเศษสองบิตที่สำคัญที่สุดคือ 11 ในไบนารี และเศษที่เหลือคือ 0xe893da3 สำหรับผลหาร q ที่กำหนด จะเข้ารหัสเป็น (1 << q) - 1 โดยใช้ 1 + q บิตเท่านั้น เศษที่เหลือจะได้รับการเข้ารหัสโดยตรงโดยใช้ k บิต ส่วนผลหารของจำนวนแรกจะเข้ารหัสเป็น 0 และส่วนที่เหลืออยู่ในเลขฐานสอง 00101111101001000000000111010 ส่วนผลหารของตัวเลขที่สองจะเข้ารหัสเป็น 0111 และส่วนที่เหลือคือ 00111010101001

เมื่อตัวเลขเหล่านี้ถูกสร้างเป็นสตริงไบต์ ระบบจะใช้ Litian Endian ตามหลักแล้ว อาจง่ายกว่าถ้าจะจินตนาการบิตสตริงยาวๆ ขึ้นมาโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด คือ เรานำส่วนผลหารของจำนวนแรกมาใส่ไว้ข้างหน้าส่วนที่เหลือของตัวเลขแรก จากนั้นเพิ่มส่วนหารของตัวเลขที่สองไว้ข้างหน้าส่วนที่เหลือ ซึ่งจะส่งผลให้มีจำนวนมากดังต่อไปนี้ (การขึ้นบรรทัดใหม่และความคิดเห็นเพื่อเพิ่มความชัดเจน)

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

เขียนในบรรทัดเดียว

00111010001001001111011010001101110010111110100100000000001110100

เห็นได้ชัดว่าจำนวนนี้เกิน 8 บิตที่ใช้ได้ในไบต์เดี่ยว จากนั้นการเข้ารหัสแบบ Endian จะใช้ 8 บิตที่มีนัยสำคัญน้อยที่สุดในตัวเลขนั้น และแสดงผลเป็นไบต์แรกซึ่งก็คือ 01110100 เพื่อความชัดเจน เราจะจัดกลุ่มบิตสตริงด้านบนออกเป็นกลุ่มๆ ละ 8 บิตโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด ดังนี้

0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100

จากนั้นการเข้ารหัสแบบ Endian จะใช้แต่ละไบต์จากด้านขวาใส่เป็นไบต์สตริง ดังนี้

01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000

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

สุดท้ายนี้

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

ไคลเอ็นต์เพียงทำตามขั้นตอนข้างต้นแบบย้อนกลับเพื่อถอดรหัสคำนำหน้าแฮช วิธีนี้ต่างจาก v4 ตรงที่ไม่จำเป็นต้องสลับไบต์ในตอนท้ายเนื่องจากระบบจะตีความจำนวนเต็มของตัวเลขนำหน้าแฮชว่าเป็น Big Endian

การถอดรหัสดัชนีการนำออก

ดัชนีการนำออกจะเข้ารหัสด้วยเทคนิคเดียวกับด้านบนโดยใช้จำนวนเต็ม 32 บิต การเข้ารหัสและการถอดรหัสของดัชนีการนำออกไม่มีการเปลี่ยนแปลงระหว่าง v4 และ v5

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

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

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

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

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

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

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

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

ส่วนนี้จะแสดงตัวอย่างการใช้ 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

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

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

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

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

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

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

1. นําออบเจ็กต์ ClientInfo V4 ออกทั้งหมด แทนที่จะให้ข้อมูลประจำตัวของลูกค้าโดยใช้ช่องเฉพาะ ให้ใช้ส่วนหัว 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 บิต ความแตกต่างคือข้อมูลที่เข้ารหัสมีการเข้ารหัสด้วยปลายทางที่ต่างกัน ทั้งในเวอร์ชัน 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. การแคชได้รับการปรับให้ซับซ้อนน้อยลงในระยะเวลาเพียงแคชเดียว ดูกระบวนการข้างต้นในการโต้ตอบกับแคช