Google Safe Browsing v5 คาดหวังว่าไคลเอ็นต์จะดูแลรักษาฐานข้อมูลในเครื่อง ยกเว้นกรณีที่ไคลเอ็นต์เลือกโหมดเรียลไทม์แบบไม่มีพื้นที่เก็บข้อมูล รูปแบบและพื้นที่เก็บข้อมูลของฐานข้อมูลในเครื่องนี้ขึ้นอยู่กับลูกค้า เนื้อหาของฐานข้อมูลในเครื่องนี้อาจเปรียบเสมือนโฟลเดอร์ที่มีรายการต่างๆ เป็นไฟล์ และเนื้อหาของไฟล์เหล่านี้คือแฮช SHA256 หรือคำนำหน้าที่เกี่ยวข้องซึ่งมีคำนำหน้าแฮช 4 ไบต์ซึ่งเป็นความยาวแฮชที่ใช้กันมากที่สุด
รายการที่ใช้ได้
รายการจะระบุด้วยชื่อที่ไม่ซ้ำกันซึ่งเป็นไปตามรูปแบบการตั้งชื่อที่มีนามสกุลที่บ่งบอกความยาวของแฮชที่คุณควรเห็นในรายการ รายการแฮชที่มีประเภทภัยคุกคามเดียวกันแต่มีความยาวแฮชต่างกันจะเป็นรายการที่มีชื่อแยกต่างหากซึ่งจะมีนามสกุลที่ระบุความยาวแฮช
รายการต่อไปนี้พร้อมให้ใช้งานกับวิธีการรายการแฮช
| ชื่อรายการ | ThreatType Enum ของ v4 ที่สอดคล้องกัน |
คำอธิบาย |
|---|---|---|
gc-32b |
ไม่มี | รายการนี้เป็นรายการแคชส่วนกลาง ซึ่งเป็นรายการพิเศษที่ใช้ในโหมดการดำเนินการแบบเรียลไทม์เท่านั้น |
se-4b |
SOCIAL_ENGINEERING |
รายการนี้มีภัยคุกคามประเภท SOCIAL_ENGINEERING |
mw-4b |
MALWARE |
รายการนี้มีภัยคุกคามประเภทมัลแวร์สำหรับแพลตฟอร์มเดสก์ท็อป |
uws-4b |
UNWANTED_SOFTWARE |
รายการนี้มีภัยคุกคามประเภท UNWANTED_SOFTWARE สำหรับแพลตฟอร์มเดสก์ท็อป |
uwsa-4b |
UNWANTED_SOFTWARE |
รายการนี้มีภัยคุกคามประเภท UNWANTED_SOFTWARE สำหรับแพลตฟอร์ม Android |
pha-4b |
POTENTIALLY_HARMFUL_APPLICATION |
รายการนี้มีภัยคุกคามประเภท POTENTIALLY_HARMFUL_APPLICATION สำหรับแพลตฟอร์ม Android |
รายการเพิ่มเติมอาจพร้อมใช้งานในภายหลัง เมื่อถึงเวลานั้น ตารางด้านบนจะขยายออก และผลลัพธ์จากเมธอด hashList.list จะแสดงผลลัพธ์ที่คล้ายกับรายการล่าสุด
การอัปเดตฐานข้อมูล
โดยไคลเอ็นต์จะเรียกเมธอด hashList.get หรือเมธอด hashLists.batchGet เป็นประจำเพื่ออัปเดตฐานข้อมูล เนื่องจากไคลเอ็นต์ทั่วไปต้องการอัปเดตหลายรายการพร้อมกัน เราจึงขอแนะนำให้ใช้เมธอด hashLists.batchGet
ระบบจะไม่เปลี่ยนชื่อรายการ นอกจากนี้ เมื่อรายการปรากฏขึ้นแล้ว ระบบจะไม่นำรายการนั้นออก (หากรายการไม่มีประโยชน์แล้ว รายการจะว่างเปล่าแต่จะยังคงอยู่ต่อไป) ดังนั้น การเขียนโค้ดชื่อเหล่านี้แบบฮาร์ดโค้ดในโค้ดไคลเอ็นต์ Google Safe Browsing จึงเหมาะสม
ทั้งเมธอด hashList.get และเมธอด hashLists.batchGet รองรับการอัปเดตแบบเพิ่ม การใช้การอัปเดตแบบเพิ่มจะประหยัดแบนด์วิดท์และปรับปรุงประสิทธิภาพ การอัปเดตแบบเพิ่มจะทำงานโดยการส่งค่า Delta ระหว่างรายการเวอร์ชันของลูกค้ากับรายการเวอร์ชันล่าสุด (หากติดตั้งใช้งานไคลเอ็นต์ใหม่และไม่มีเวอร์ชันใดๆ ให้เลือก ให้อัปเดตแบบสมบูรณ์) การอัปเดตแบบเพิ่มมีดัชนีการนำออกและการเพิ่ม ลูกค้าจะต้องนำรายการในดัชนีที่ระบุออกจากฐานข้อมูลในเครื่องก่อน แล้วจึงใช้รายการที่เพิ่ม
สุดท้าย ไคลเอ็นต์ควรตรวจสอบข้อมูลที่จัดเก็บเทียบกับการตรวจสอบผลรวมที่เซิร์ฟเวอร์ระบุไว้เพื่อป้องกันความเสียหาย เมื่อใดก็ตามที่การตรวจสอบผลรวมไม่ตรงกัน ลูกค้าควรทำการอัปเดตอย่างเต็มรูปแบบ
การถอดรหัสเนื้อหารายการ
การถอดรหัสแฮชและคํานําหน้าแฮช
ระบบจะส่งรายการทั้งหมดโดยใช้การเข้ารหัสพิเศษเพื่อลดขนาด การเข้ารหัสนี้ทํางานโดยพิจารณาว่ารายการ Google Safe Browsing มีชุดแฮชหรือคำนำหน้าแฮช ซึ่งแยกแยะไม่ได้จากจำนวนเต็มแบบสุ่มทางสถิติ หากเราจัดเรียงจำนวนเต็มเหล่านี้และนำผลต่างที่อยู่ติดกัน ผลต่างที่อยู่ติดกันดังกล่าวควรจะ "เล็ก" ในบางแง่ จากนั้น การเข้ารหัส Golomb-Rice จะใช้ความเล็กนี้
สมมติว่าต้องส่งนิพจน์คำนำหน้าเส้นทางที่มีนามสกุลของโฮสต์ 3 รายการ ได้แก่ a.example.com/, b.example.com/ และ y.example.com/ โดยใช้คำนำหน้าแฮช 4 ไบต์ ต่อไปสมมติว่าพารามิเตอร์ Rice ซึ่งแสดงด้วย k มีค่าเป็น
- เซิร์ฟเวอร์จะเริ่มด้วยการคำนวณแฮชแบบเต็มสำหรับสตริงเหล่านี้ ซึ่งได้แก่
291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03 y.example.com/
จากนั้นเซิร์ฟเวอร์จะสร้างคำนำหน้าแฮช 4 ไบต์สําหรับรายการข้างต้นแต่ละรายการ ซึ่งเป็น 4 ไบต์แรกของแฮชแบบเต็ม 32 ไบต์ ซึ่งตีความเป็นจำนวนเต็ม 32 บิตแบบ Big Endian รูปแบบ Big Endian หมายถึงการที่ไบต์แรกของแฮชแบบเต็มกลายเป็นไบต์ที่มีนัยสำคัญมากที่สุดของจำนวนเต็ม 32 บิต ขั้นตอนนี้จะทำให้เกิดจำนวนเต็ม 0x291bc542, 0x1d32c508 และ 0xf7a502e5
เซิร์ฟเวอร์จำเป็นต้องจัดเรียงคำนำหน้าแฮช 3 รายการนี้ตามลําดับตัวอักษร (เทียบเท่ากับการจัดเรียงตัวเลขใน Big Endian) และผลลัพธ์ของการจัดเรียงคือ 0x1d32c508, 0x291bc542, 0xf7a502e5 ระบบจะจัดเก็บคำนำหน้าแฮชแรกไว้โดยไม่มีการเปลี่ยนแปลงในช่อง first_value
จากนั้นเซิร์ฟเวอร์จะคํานวณผลต่าง 2 รายการที่อยู่ติดกัน ซึ่งได้แก่ 0xbe9003a และ 0xce893da3 ตามลําดับ ในกรณีที่เลือก k เป็น 30 เซิร์ฟเวอร์จะแยกตัวเลข 2 ตัวนี้ออกเป็นส่วนผลหารและส่วนเศษที่มีความยาว 2 และ 30 บิตตามลำดับ สำหรับตัวเลขแรก ส่วนผลหารคือ 0 และส่วนที่เหลือคือ 0xbe9003a ส่วนตัวเลขที่ 2 ส่วนผลหารคือ 3 เนื่องจาก 2 บิตที่มีค่ามากที่สุดคือ 11 ในฐาน 2 และส่วนที่เหลือคือ 0xe893da3 สำหรับผลหาร q หนึ่งๆ ระบบจะเข้ารหัสเป็น (1 << q) - 1 โดยใช้บิต 1 + q บิตพอดี ส่วนเศษจะเข้ารหัสโดยตรงโดยใช้บิต k ส่วนผลหารของจำนวนแรกเข้ารหัสเป็น 0 และส่วนเศษที่เหลือเป็นฐาน 2 001011111010010000000000111010 ส่วนผลหารของจำนวนที่ 2 เข้ารหัสเป็น 0111 และส่วนเศษที่เหลือคือ 001110100010010011110110100011
เมื่อตัวเลขเหล่านี้อยู่ในรูปแบบสตริงไบต์ ระบบจะใช้รูปแบบ Little Endian ในทางแนวคิด คุณอาจจินตนาการได้ง่ายขึ้นว่าสตริงบิตยาวๆ สร้างขึ้นโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด โดยเราจะนำส่วนเศษของตัวเลขแรกไปไว้ข้างหน้าส่วนเศษของตัวเลขแรก จากนั้นนำส่วนเศษของตัวเลขที่ 2 ไปไว้ข้างหน้าส่วนเศษของตัวเลขแรก ซึ่งควรให้ผลลัพธ์เป็นตัวเลขขนาดใหญ่ต่อไปนี้ (มีการเพิ่มการแบ่งบรรทัดและคําอธิบายเพื่อให้ชัดเจน)
001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part
เมื่อเขียนเป็นบรรทัดเดียวจะมีลักษณะดังนี้
00111010001001001111011010001101110010111110100100000000001110100
ตัวเลขนี้มากกว่า 8 บิตที่มีให้ในไบต์เดียวอย่างเห็นได้ชัด จากนั้นการเข้ารหัส Little Endian จะนำบิตที่มีนัยสำคัญน้อยที่สุด 8 บิตของตัวเลขนั้น และแสดงผลเป็นไบต์แรกซึ่งเป็น 01110100 เพื่อความชัดเจน เราจะจัดกลุ่มสตริงบิตข้างต้นเป็นกลุ่มละ 8 บิตโดยเริ่มจากบิตที่มีนัยสำคัญน้อยที่สุด
0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100
จากนั้นการเข้ารหัส Little Endian จะนําไบต์แต่ละรายการจากด้านขวาไปใส่ไว้ในสตริงไบต์
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"
}
ลูกค้าเพียงทำตามขั้นตอนข้างต้นย้อนกลับเพื่อถอดรหัสคำนำหน้าแฮช
การถอดรหัสดัชนีการนำออก
ดัชนีการนําออกได้รับการเข้ารหัสโดยใช้เทคนิคเดียวกันกับด้านบนโดยใช้จำนวนเต็ม 32 บิต
ความถี่ในการอัปเดต
ไคลเอ็นต์ควรตรวจสอบค่าที่เซิร์ฟเวอร์แสดงผลในฟิลด์ minimum_wait_duration และใช้ค่าดังกล่าวเพื่อกำหนดเวลาการอัปเดตฐานข้อมูลครั้งถัดไป ค่านี้อาจเป็น 0 (ช่อง minimum_wait_duration หายไปโดยสมบูรณ์) ซึ่งในกรณีนี้ ลูกค้าควรทำการอัปเดตอีกครั้งทันที