URLs and Hashing

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

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

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

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

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

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

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

หากต้องการทำให้ชื่อโฮสต์เป็นรูปแบบมาตรฐาน ให้ทำดังนี้

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

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

วิธีกำหนดเส้นทาง

  1. แก้ไขลําดับ /../ และ /./ ในเส้นทางโดยแทนที่ /./ ด้วย / และนํา /../ ออกพร้อมกับคอมโพเนนต์เส้นทางก่อนหน้า
  2. แทนที่เครื่องหมายทับที่ต่อเนื่องกันด้วยเครื่องหมายทับเดี่ยว

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

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

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

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

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

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

  • หากชื่อโฮสต์ไม่ใช่ IPv4 หรือ IPv6 ที่เป็นตัวอักษรล้วน ชื่อโฮสต์จะประกอบด้วยโดเมน eTLD+1 และส่วนประกอบนำที่ตามต่อกันได้สูงสุด 4 รายการ การระบุ eTLD+1 ควรอิงตามรายการคำต่อท้ายสาธารณะ ตัวอย่างเช่น a.b.example.com จะทำให้เกิดโดเมน eTLD+1 ของ example.com รวมถึงโฮสต์ที่มีคอมโพเนนต์โฮสต์เพิ่มเติม b.example.com 1 รายการ
  • ชื่อโฮสต์ที่ถูกต้องใน 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 ความยาวของแฮชที่เซิร์ฟเวอร์ส่งจะได้รับการเข้ารหัสภายในแบบแผนการตั้งชื่อของรายการซึ่งมีส่วนต่อท้ายที่ระบุความยาวแฮช ดูรายละเอียดเพิ่มเติมได้ที่ส่วนรายการที่ใช้ได้