Durante el último año, participamos activamente en conversaciones con los proveedores de varias extensiones de bloqueo de contenido sobre cómo mejorar la plataforma de extensiones MV3. En función de estas discusiones, muchas de las cuales se llevaron a cabo en el grupo comunitario de WebExtensions (WECG) en colaboración con otros navegadores, pudimos implementar mejoras significativas.
Más conjuntos de reglas estáticos
Los conjuntos de reglas de filtro suelen agruparse en listas. Por ejemplo, una lista más genérica podría contener reglas aplicables a todos los usuarios, mientras que una lista más específica podría ocultar contenido específico de la ubicación que solo algunos usuarios desean bloquear. Hasta hace poco, permitíamos que cada extensión ofreciera a los usuarios una opción de 50 listas (o "conjuntos de reglas estáticos") y que 10 de ellas se habilitaran de forma simultánea. En las conversaciones con la comunidad, los desarrolladores de extensiones proporcionaron pruebas convincentes que demostraban que este valor era demasiado bajo para ciertos casos de uso. Después de analizar el rendimiento de la API en Chrome con estas discusiones en mente, ahora permitimos que se habiliten hasta 50 de forma simultánea. (Cabe destacar que esto es mucho más alto que el límite de 20 solicitado en el WECG). También permitimos 100 conjuntos de reglas en total. Esto se lanzará en Chrome 120, y Firefox y Safari, que proporcionaron comentarios anticipados sobre esta propuesta, admiten el aumento de los límites.
Más reglas dinámicas
La mayoría de las reglas son "estáticas" y se envían con cada actualización a una extensión. Sin embargo, para admitir actualizaciones más frecuentes y reglas definidas por el usuario, las extensiones también pueden agregar reglas de forma dinámica, sin que sus desarrolladores tengan que subir una versión nueva de la extensión a Chrome Web Store.
Cuando una extensión puede modificar solicitudes de forma dinámica de maneras que no se verificaron durante la revisión de Chrome Web Store, los usuarios se exponen a riesgos de phishing o robo de datos. Por ejemplo, se podría hacer un uso inadecuado de una regla de redireccionamiento para insertar vínculos de afiliados sin consentimiento.
Por lo tanto, solo permitimos que las extensiones agreguen hasta 5,000 reglas, lo que fomentó el uso moderado de esta funcionalidad y nos permitió detectar abusos con mayor facilidad.
Sin embargo, los desarrolladores de extensiones como AdGuard y Adblock Plus realizaron su propio análisis y compartieron datos que indican que un límite más alto permitiría que se implementen reglas más actualizadas y que los usuarios con una mayor cantidad de listas personalizadas migren al manifiesto V3. De hecho, AdGuard informó que se realizan más de 2,600 cambios en las listas populares cada semana y que, del cinco por ciento de los usuarios que usan listas de filtros personalizadas, uno de cada cuatro tiene un total combinado de más de 5,000 reglas dinámicas (fuente). AdGuard señaló esto como un desafío importante para migrar su extensión al manifiesto V3, y recibimos comentarios similares de otros bloqueadores de contenido.
Determinamos que algunas reglas de filtro, como las que tienen una acción de block o allow, son mucho más seguras y es menos probable que se abuse de ellas. También conforman la gran mayoría de las reglas de filtro de bloqueo de anuncios. En función de esto, redacté y compartí una propuesta en el grupo de la comunidad de extensiones web para definir un conjunto de reglas que consideramos de menor riesgo y permitir hasta 30,000 de ellas. Aún mantenemos un límite superior para evitar regresiones de rendimiento.
Esta propuesta recibió el apoyo del grupo de la comunidad de extensiones web, por lo que la implementamos. A partir de Chrome 121, el límite superior de 30,000 reglas se aplica a las reglas de DNR seguras, que definimos como reglas con una acción de block, allow, allowAllRequests o upgradeScheme.
Según los datos que compartió AdGuard, entre el 98 y el 99 por ciento de sus reglas deberían beneficiarse de este límite más alto. Las reglas restantes siguen siendo compatibles y se pueden agregar dentro del límite existente.
Está disponible en Chrome como la constante MAX_NUMBER_OF_DYNAMIC_RULES. El límite de reglas para todas las demás reglas de solicitud de red dinámica se mantiene en 5,000.
Reducción del tamaño del conjunto de reglas
En Chrome 118, cambiamos el valor predeterminado del campo isUrlFilterCaseSensitive a false en función de los comentarios de la comunidad. Este campo controla si una regla que filtra por URL distingue mayúsculas de minúsculas, y descubrimos que la mayoría de los desarrolladores tenían una configuración predeterminada diferente en su extensión. Por lo tanto, el valor se tuvo que establecer muchas veces. Con este cambio, los desarrolladores pueden lograr reducciones significativas de tamaño en sus conjuntos de reglas.
¿Qué sigue?
Nos comprometemos a seguir invirtiendo en la API de declarativeNetRequest para poder admitir la mayor cantidad posible de casos de uso y esperamos seguir trabajando con la comunidad. En particular, queremos agradecer a los miembros del WECG por su participación, incluido AdGuard por compartir una cantidad significativa de los datos que impulsaron este trabajo, y a todos los proveedores de navegadores que fueron una parte importante del diseño de esta API.
Seguiremos revisando los límites que tenemos establecidos para hacer los ajustes necesarios. Para respaldar esto, planeamos compartir algunos de los datos que recopilamos como parte de este trabajo en un futuro cercano. Además, estamos trabajando para agregar funciones adicionales, como la capacidad de hacer coincidir los encabezados de respuesta, que es una solicitud común que recibimos de las extensiones de visores de PDF. En todos los casos, seguiremos comunicando nuestro trabajo y usaremos el grupo de la comunidad de extensiones web con frecuencia como un lugar para analizar ideas y alinearnos en lo que nos gustaría ver a continuación.