Trong năm qua, chúng tôi đã tích cực thảo luận với những nhà cung cấp sử dụng một số tiện ích chặn nội dung xoay quanh các cách cải thiện nền tảng phần mở rộng MV3. Dựa trên những cuộc thảo luận này, chúng tôi đã có được những cải tiến đáng kể diễn ra trong Nhóm cộng đồng WebExtensions (WECG) kết hợp với các trình duyệt khác.
Các quy tắc tĩnh khác
Nhóm quy tắc lọc thường được nhóm thành danh sách. Ví dụ: danh sách chung hơn có thể chứa các quy tắc áp dụng cho tất cả người dùng trong khi danh sách cụ thể hơn có thể ẩn nội dung theo vị trí cụ thể mà chỉ một số người dùng muốn chặn. Cho đến gần đây, chúng tôi cho phép mỗi tiện ích cung cấp cho người dùng lựa chọn gồm 50 danh sách (hay "bộ quy tắc tĩnh") và bật đồng thời 10 danh sách trong số này. Trong các cuộc thảo luận với cộng đồng, nhà phát triển tiện ích đã đưa ra bằng chứng thuyết phục cho thấy mức giá này quá thấp đối với một số trường hợp sử dụng nhất định. Sau khi xem xét hiệu suất của API trong Chrome dựa trên những thảo luận này, chúng tôi hiện cho phép bật đồng thời tối đa 50 API. (Đáng chú ý là con số này cao hơn đáng kể so với giới hạn 20 yêu cầu trong WECG.) Chúng tôi cũng cho phép tổng cộng 100 tập hợp quy tắc. Bản phát hành này được trình bày trong Chrome 120 và việc tăng giới hạn được cả Firefox và Safari đều hỗ trợ. Cả Firefox và Safari đều đã cung cấp thông tin đầu vào sớm về đề xuất này.
Các quy tắc linh động hơn
Hầu hết các quy tắc đều ở trạng thái "tĩnh" và đi kèm với mỗi bản cập nhật cho tiện ích. Tuy nhiên, để hỗ trợ các bản cập nhật thường xuyên hơn và quy tắc do người dùng xác định, tiện ích cũng có thể tự động thêm quy tắc mà không cần nhà phát triển phải tải phiên bản tiện ích mới lên Cửa hàng Chrome trực tuyến.
Khi một tiện ích có thể sửa đổi yêu cầu một cách linh động theo những cách chưa được kiểm tra trong quá trình xem xét của Cửa hàng Chrome trực tuyến, người dùng sẽ gặp rủi ro lừa đảo hoặc đánh cắp dữ liệu. Ví dụ: một quy tắc chuyển hướng có thể bị sử dụng sai mục đích để chèn các đường dẫn tiếp thị liên kết mà không có sự đồng ý.
Do đó, chúng tôi chỉ cho phép các tiện ích thêm tối đa 5.000 quy tắc nhằm khuyến khích việc sử dụng chức năng này một cách hạn chế và giúp chúng tôi dễ dàng phát hiện hành vi sai trái hơn.
Tuy nhiên, nhà phát triển của các tiện ích bao gồm AdGuard và Adblock Plus đã thực hiện việc phân tích và chia sẻ dữ liệu riêng của họ, đồng thời giới hạn cao hơn sẽ cho phép các quy tắc cập nhật hơn và người dùng có nhiều danh sách tuỳ chỉnh hơn có thể di chuyển sang Manifest V3. Trên thực tế, AdGuard báo cáo rằng có hơn 2600 thay đổi được thực hiện đối với danh sách phổ biến mỗi tuần và trong số 5% số người dùng sử dụng danh sách bộ lọc tuỳ chỉnh, 1/4 trong số đó có tổng cộng hơn 5.000 quy tắc động (nguồn). AdGuard ghi nhận đây là một thách thức lớn trong việc di chuyển tiện ích của họ sang Manifest V3 và chúng tôi đã nhận được ý kiến phản hồi tương tự từ các trình chặn nội dung khác.
Chúng tôi nhận thấy một số quy tắc lọc (chẳng hạn như các quy tắc có thao tác block hoặc allow) an toàn hơn nhiều và ít có khả năng bị sử dụng sai mục đích. Chúng cũng tạo thành phần lớn các quy tắc bộ lọc khối quảng cáo. Dựa trên đó, tôi đã soạn thảo và chia sẻ đề xuất trong Nhóm cộng đồng tiện ích web để xác định một bộ quy tắc mà chúng tôi cho là có rủi ro thấp hơn và cho phép tối đa 30.000 quy tắc. Chúng tôi vẫn giữ giới hạn trên để tránh hồi quy hiệu suất.
Đề xuất này được hỗ trợ trong Nhóm cộng đồng Tiện ích web, vì vậy, chúng tôi đã triển khai nó. Kể từ Chrome 121, giới hạn cao hơn là 30.000 quy tắc sẽ áp dụng cho các quy tắc DNR an toàn. Chúng tôi đang xác định các quy tắc này là các quy tắc bằng thao tác của block, allow, allowAllRequests hoặc upgradeScheme.
Dựa trên dữ liệu do AdGuard chia sẻ, 98 đến 99% các quy tắc của họ sẽ được hưởng lợi từ hạn mức cao hơn này. Hệ thống vẫn hỗ trợ mọi quy tắc còn lại và bạn có thể thêm trong hạn mức hiện có.
Tính năng này có sẵn trong Chrome dưới dạng hằng số MAX_NUMBER_OF_DYNAMIC_RULES. Giới hạn quy tắc cho tất cả các quy tắc yêu cầu ròng khác động vẫn ở mức 5.000.
Giảm kích thước bộ quy tắc
Trong Chrome 118, chúng tôi đã thay đổi giá trị mặc định cho trường isUrlFilterCaseSensitive thành false dựa trên ý kiến phản hồi của cộng đồng. Trường này kiểm soát xem một quy tắc lọc theo URL có phân biệt chữ hoa chữ thường hay không và chúng tôi nhận thấy rằng hầu hết các nhà phát triển đều có giá trị mặc định khác trong tiện ích của họ. Do đó, bạn phải đặt giá trị này nhiều lần. Khi thực hiện thay đổi này, nhà phát triển có thể giảm đáng kể kích thước của tập quy tắc.
Tiếp theo là gì?
Chúng tôi cam kết sẽ tiếp tục đầu tư vào declarativeNetRequest API để có thể hỗ trợ nhiều trường hợp sử dụng nhất có thể, đồng thời mong muốn tiếp tục hợp tác với cộng đồng. Cụ thể, chúng tôi muốn cảm ơn các thành viên của WECG vì đã tham gia, kể cả AdGuard vì đã chia sẻ một lượng lớn dữ liệu thúc đẩy công việc này cũng như tất cả các nhà cung cấp trình duyệt, những người đóng vai trò quan trọng trong quá trình thiết kế API này.
Chúng tôi sẽ tiếp tục xem xét các giới hạn hiện có để điều chỉnh khi cần thiết. Để hỗ trợ việc này, chúng tôi dự định chia sẻ một số dữ liệu mà chúng tôi thu thập được trong công việc này trong tương lai gần. Ngoài ra, chúng tôi cũng đang nỗ lực bổ sung các tính năng như khả năng so khớp với tiêu đề phản hồi. Đây là một yêu cầu phổ biến mà chúng tôi nhận thấy đối với các tiện ích trình xem PDF. Trong mọi trường hợp, chúng tôi sẽ tiếp tục truyền đạt công việc của mình và thường xuyên sử dụng Nhóm cộng đồng tiện ích web làm nơi thảo luận về các ý tưởng và thống nhất những gì chúng tôi muốn xem xét tiếp theo.