Migration From V4

Một điểm cải tiến đáng kể của Google Safe Browsing phiên bản 5 so với phiên bản 4 (cụ thể là Update API phiên bản 4) là tính mới và phạm vi của dữ liệu. Vì tính năng bảo vệ phụ thuộc nhiều vào cơ sở dữ liệu cục bộ do máy khách duy trì, nên độ trễ và kích thước của bản cập nhật cơ sở dữ liệu cục bộ là yếu tố chính khiến tính năng bảo vệ bị bỏ lỡ. Trong phiên bản 4, ứng dụng khách thông thường mất từ 20 đến 50 phút để nhận được phiên bản danh sách mối đe doạ mới nhất. Thật không may, các cuộc tấn công giả mạo lan rộng rất nhanh: tính đến năm 2021, 60% trang web thực hiện các cuộc tấn công chỉ hoạt động dưới 10 phút. Kết quả phân tích của chúng tôi cho thấy khoảng 25-30% trường hợp thiếu tính năng bảo vệ khỏi hành vi lừa đảo là do dữ liệu cũ. Ngoài ra, một số thiết bị không được trang bị để quản lý toàn bộ danh sách các mối đe doạ của tính năng Duyệt web an toàn của Google. Danh sách này sẽ tiếp tục tăng lên theo thời gian.

Nếu hiện đang sử dụng Update API phiên bản 4, bạn có thể di chuyển liền mạch từ phiên bản 4 sang phiên bản 5 mà không cần phải đặt lại hoặc xoá cơ sở dữ liệu cục bộ. Phần này trình bày cách thực hiện việc đó.

Chuyển đổi thông tin cập nhật về danh sách

Không giống như phiên bản 4 (trong đó danh sách được xác định bằng bộ gồm loại mối đe doạ, loại nền tảng, loại mục nhập mối đe doạ), trong phiên bản 5, danh sách chỉ được xác định bằng tên. Điều này mang lại sự linh hoạt khi nhiều danh sách v5 có thể dùng chung cùng một loại mối đe doạ. Các loại nền tảng và loại mục nhập mối đe doạ sẽ bị xoá trong phiên bản 5.

Trong phiên bản 4, bạn có thể dùng phương thức threatListUpdates.fetch để tải danh sách xuống. Trong phiên bản 5, bạn sẽ chuyển sang phương thức hashLists.batchGet.

Bạn cần thực hiện những thay đổi sau đối với yêu cầu:

  1. Xoá hoàn toàn đối tượng ClientInfo v4. Thay vì cung cấp thông tin nhận dạng của ứng dụng bằng một trường chuyên dụng, bạn chỉ cần sử dụng tiêu đề User-Agent nổi tiếng. Mặc dù không có định dạng bắt buộc để cung cấp thông tin nhận dạng ứng dụng khách trong tiêu đề này, nhưng bạn chỉ cần thêm mã ứng dụng khách và phiên bản ứng dụng khách ban đầu, được phân tách bằng ký tự khoảng trắng hoặc ký tự dấu gạch chéo.
  2. Đối với mỗi đối tượng ListUpdateRequest phiên bản 4: * Tra cứu tên danh sách phiên bản 5 tương ứng trong các danh sách có sẵn và cung cấp tên đó trong yêu cầu phiên bản 5.
    • Xoá các trường không cần thiết, chẳng hạn như threat_entry_type hoặc platform_type.
    • Trường state trong phiên bản 4 tương thích trực tiếp với trường versions trong phiên bản 5. Bạn chỉ cần gửi cùng một chuỗi byte sẽ được gửi đến máy chủ bằng cách sử dụng trường state trong phiên bản 4 bằng cách sử dụng trường versions trong phiên bản 5.
    • Đối với các ràng buộc v4, v5 sử dụng một phiên bản đơn giản hoá có tên là SizeConstraints. Bạn nên bỏ các trường bổ sung như region.

Bạn nên thực hiện những thay đổi sau đối với phản hồi:

  1. enum ResponseType v4 chỉ được thay thế bằng một trường boolean có tên là partial_update.
  2. Giờ đây, bạn có thể đặt trường minimum_wait_duration thành 0 hoặc bỏ qua trường này. Nếu có, máy khách sẽ được yêu cầu đưa ra một yêu cầu khác ngay lập tức. Điều này chỉ xảy ra khi ứng dụng chỉ định trong SizeConstraints một ràng buộc nhỏ hơn về kích thước tối đa của bản cập nhật so với kích thước tối đa của cơ sở dữ liệu.
  3. Logic giải mã các hàm băm được mã hoá bằng Rice-Golomb cần có 2 điều chỉnh chính:
    • Tính chất Endian và Sắp xếp: Trong phiên bản 4, các hàm băm được trả về sẽ được sắp xếp dưới dạng các giá trị little-endian. Trong phiên bản 5, các giá trị này được coi là giá trị big-endian. Vì việc sắp xếp theo từ điển của các chuỗi byte tương đương với việc sắp xếp theo số của các giá trị big-endian, nên các ứng dụng không còn cần thực hiện một bước sắp xếp đặc biệt nữa. Bạn có thể xoá chế độ sắp xếp tuỳ chỉnh theo thứ tự little-endian, chẳng hạn như chế độ trong Chromium phiên bản 4, nếu đã triển khai trước đó.
    • Độ dài hàm băm thay đổi: Thuật toán giải mã phải được cập nhật để hỗ trợ nhiều độ dài hàm băm có thể được trả về trong trường HashList.compressed_additions, chứ không chỉ độ dài hàm băm 4 byte được dùng trong phiên bản 4. Bạn có thể xác định độ dài của các hàm băm được trả về trong phản hồi dựa trên HashList.metadata.hash_length được trả về từ hashLists.list. Ngoài ra, việc đặt tên cho danh sách băm được yêu cầu cũng cho biết kích thước băm dự kiến được trả về từ danh sách. Hãy xem trang Cơ sở dữ liệu cục bộ để biết thêm thông tin chi tiết về danh sách băm.

Chuyển đổi các cụm từ tìm kiếm có hàm băm

Trong phiên bản 4, người dùng sẽ sử dụng phương thức fullHashes.find để nhận các giá trị băm đầy đủ. Phương thức tương đương trong phiên bản 5 là phương thức hashes.search.

Bạn cần thực hiện những thay đổi sau đối với yêu cầu:

  1. Cấu trúc mã để chỉ gửi tiền tố băm có độ dài chính xác là 4 byte.
  2. Xoá hoàn toàn các đối tượng ClientInfo v4. Thay vì cung cấp thông tin nhận dạng của ứng dụng bằng một trường chuyên dụng, bạn chỉ cần sử dụng tiêu đề User-Agent nổi tiếng. Mặc dù không có định dạng bắt buộc để cung cấp thông tin nhận dạng ứng dụng khách trong tiêu đề này, nhưng bạn chỉ cần thêm mã ứng dụng khách và phiên bản ứng dụng khách ban đầu, được phân tách bằng ký tự khoảng trắng hoặc ký tự dấu gạch chéo.
  3. Xoá trường client_states. Dữ liệu này không còn cần thiết nữa.
  4. Bạn không cần phải thêm threat_types và các trường tương tự nữa.

Bạn nên thực hiện những thay đổi sau đối với phản hồi:

  1. Đã xoá trường minimum_wait_duration. Máy khách luôn có thể đưa ra yêu cầu mới khi cần.
  2. Đối tượng v4 ThreatMatch đã được đơn giản hoá thành đối tượng FullHash.
  3. Quy trình lưu vào bộ nhớ đệm đã được đơn giản hoá thành một khoảng thời gian lưu vào bộ nhớ đệm duy nhất. Hãy xem các quy trình ở trên để tương tác với bộ nhớ đệm.