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