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à API Cập nhật phiên bản 4) là độ 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 ứng dụng 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 dẫn đến việc bỏ lỡ tính năng bảo vệ. Trong phiên bản 4, ứng dụng thông thường mất từ 20 đến 50 phút để tải phiên bản mới nhất của danh sách mối đe doạ. Đáng tiếc là các cuộc tấn công giả mạo lan truyền nhanh chóng: tính đến năm 2021, 60% số trang web thực hiện các cuộc tấn công chỉ tồn tại chưa đến 10 phút. Phân tích của chúng tôi cho thấy khoảng 25-30% trường hợp không được bảo vệ khỏi hành vi lừa đảo là do dữ liệu đó đã lỗi thời. Ngoài ra, một số thiết bị không được trang bị để quản lý toàn bộ danh sách mối đe doạ của tính năng Duyệt web an toàn của Google. Danh sách này ngày càng lớn hơn theo thời gian.

Nếu bạn đang sử dụng API Cập nhật phiên bản 4, thì 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 đặ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 nội dung cập nhật danh sách

Không giống như phiên bản 4, trong đó danh sách được xác định bằng bộ dữ liệu 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ạ đã bị xoá trong phiên bản 5.

Trong phiên bản 4, bạn sẽ sử 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á toàn bộ đố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 quy định để 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ỉ nên thêm mã ứng dụng khách ban đầu và phiên bản ứng dụng khách, phân tách bằng ký tự cách hoặc ký tự gạch chéo.
  2. Đối với mỗi đối tượng ListUpdateRequest v4: * Tìm tên danh sách v5 tương ứng trong bảng ở trên và cung cấp tên đó trong yêu cầu v5.
    • Xoá các trường không cần thiết 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 được gửi đến máy chủ bằ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 quy tắc ràng buộc v4, v5 sử dụng một phiên bản đơn giản có tên là SizeConstraints. Bạn nên xoá các trường bổ sung như region.

Bạn cần thực hiện các thay đổi sau đối với phản hồi:

  1. Enum ResponseType của phiên bản 4 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. Nếu có, ứng dụng sẽ được yêu cầu gửi ngay một yêu cầu khác. Điều này chỉ xảy ra khi ứng dụng chỉ định trong SizeConstraints một quy tắc ràng buộc nhỏ hơn về kích thước cập nhật tối đa so với kích thước cơ sở dữ liệu tối đa.
  3. Bạn cần điều chỉnh thuật toán giải mã Rice cho số nguyên 32 bit. Điểm khác biệt là dữ liệu được mã hoá được mã hoá bằng một thứ tự byte khác. Trong cả phiên bản 4 và 5, tiền tố hàm băm 32 bit được sắp xếp theo thứ tự bảng chữ cái. Tuy nhiên, trong phiên bản 4, các tiền tố đó được coi là little endian khi được sắp xếp, trong khi ở phiên bản 5, các tiền tố đó được coi là big endian khi được sắp xếp. Điều này có nghĩa là ứng dụng không cần phải sắp xếp, vì việc sắp xếp theo thứ tự bảng chữ cái giống với việc sắp xếp theo số với big endian. Bạn có thể xem ví dụ về loại này trong quá trình triển khai phiên bản 4 của Chromium tại đây. Bạn có thể xoá cách sắp xếp như vậy.
  4. Bạn cũng cần triển khai thuật toán giải mã Rice cho các độ dài băm khác.

Chuyển đổi nội dung tìm kiếm bằng hàm băm

Trong phiên bản 4, bạn sẽ sử dụng phương thức fullHashes.find để nhận hàm 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. Sắp xếp mã để chỉ gửi tiền tố hàm băm có độ dài chính xác là 4 byte.
  2. Xoá toàn bộ đố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 quy định để 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ỉ nên thêm mã ứng dụng khách ban đầu và phiên bản ứng dụng khách, phân tách bằng ký tự cách hoặc ký tự 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 cần thực hiện các thay đổi sau đối với phản hồi:

  1. Đã xoá trường minimum_wait_duration. Ứng dụng khách luôn có thể đưa ra yêu cầu mới khi cần.
  2. Đối tượng ThreatMatch phiên bản 4 đã được đơn giản hoá thành đối tượng FullHash.
  3. Tính năng lưu vào bộ nhớ đệm đã được đơn giản hoá thành một thời lượng 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.