Durante el último año, hemos participado activamente en las conversaciones con los proveedores de varias extensiones de bloqueo de contenido en torno a las maneras de mejorar la plataforma de extensiones MV3. Pudimos implementar mejoras significativas en función de estos debates, muchos de los cuales tuvieron lugar en el Grupo de la Comunidad de WebExtensions (WECG) en colaboración con otros navegadores.
Más conjuntos de reglas estáticos
Por lo general, los conjuntos de reglas de filtro se agrupan 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 la posibilidad de elegir entre 50 listas (o "conjuntos de reglas estáticas"), y que se habilitaran 10 de estas al mismo tiempo. En debates con la comunidad, los desarrolladores de extensiones proporcionaron evidencia convincente que demostraba que esto fue demasiado bajo para ciertos casos de uso. Después de analizar el rendimiento de la API en Chrome con estos debates en mente, ahora permitimos que se habiliten hasta 50 API de forma simultánea. (En particular, esto es significativamente más alto que el límite de 20 solicitados en el WECG). También permitimos 100 conjuntos de reglas en total. Este proceso se realizará en Chrome 120 y, por lo tanto, Firefox y Safari, que proporcionaron entradas anticipadas sobre esta propuesta, admiten el aumento de los límites.
Reglas más dinámicas
La mayoría de las reglas son “estáticas” y se envían con cada actualización de la 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 los desarrolladores tengan que subir una nueva versión de la extensión a Chrome Web Store.
Cuando una extensión puede modificar las solicitudes de forma dinámica en formas que no se verificaron durante la revisión de Chrome Web Store, se expone a los usuarios a riesgos de phishing o robo de datos. Por ejemplo, una regla de redireccionamiento podría usarse de forma inadecuada para insertar vínculos de afiliados sin consentimiento.
En consecuencia, solo permitimos que las extensiones agregaran hasta 5,000 reglas, lo que alentaron el uso de esta función con moderación y facilitaron la detección del abuso.
Sin embargo, los desarrolladores de extensiones, incluidos AdGuard y Adblock Plus, realizaron su propio análisis y compartieron datos que un límite más alto permitiría implementar reglas más actualizadas y a que los usuarios con una mayor cantidad de listas personalizadas migraran a Manifest V3. De hecho, AdGuard informó que se realizan más de 2,600 cambios en las listas populares cada semana y, del cinco por ciento de los usuarios que utilizan listas de filtros personalizados, uno de cada cuatro usuarios tiene un total combinado de más de 5,000 reglas dinámicas entre ellos (fuente). AdGuard notó que esto representaba un desafío importante para migrar su extensión a Manifest V3, y otros bloqueadores de contenido nos comentaron comentarios similares.
Determinamos que algunas reglas de filtro, como las que incluyen una acción de block o allow, son mucho más seguras y tienen menos probabilidades de que se abuse de ellas. También constituyen la gran mayoría de las reglas de filtro de bloqueo de anuncios. En función de esta información, 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 que permiten hasta 30,000 de ellas. Seguimos manteniendo un límite superior para evitar regresiones de rendimiento.
Esta propuesta fue compatible con el grupo de la comunidad de extensiones web, por lo que la implementamos. A partir de Chrome 121, se aplica el límite más alto de 30,000 reglas a las reglas de DNR seguras, que definimos como reglas con una acción de block, allow, allowAllRequests o upgradeScheme.
En función de los datos que comparte AdGuard, entre el 98 y el 99% de sus reglas deberían beneficiarse de este límite más alto. Las reglas restantes siguen siendo compatibles y pueden agregarse dentro del límite existente.
Está disponible en Chrome como la constante MAX_NUMBER_OF_DYNAMIC_RULES. El límite de todas las demás reglas de solicitudes netas dinámicas se mantiene en 5,000.
Se redujo el 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 vimos que la mayoría de los desarrolladores tenían un valor predeterminado diferente en su extensión. Por lo tanto, el valor tuvo que establecerse muchas veces. Con este cambio, los desarrolladores pueden lograr reducciones de tamaño significativas en sus conjuntos de reglas.
¿Qué sigue?
Nos comprometemos a seguir invirtiendo en la API de NNAPINetRequest para admitir tantos casos de uso como sea posible y esperamos seguir trabajando con la comunidad. En particular, queremos agradecerles a los miembros de WECG por su compromiso, incluido AdGuard por compartir una cantidad significativa de los datos que impulsaron este trabajo, y a todos los proveedores de navegadores que han sido una parte importante del diseño de esta API.
Seguiremos revisando los límites establecidos para realizar los ajustes necesarios. Para respaldar esto, planeamos compartir en un futuro cercano algunos de los datos que recopilamos como parte de este trabajo. Además, estamos trabajando para agregar funciones adicionales, como la capacidad de buscar coincidencias con los encabezados de respuesta, que es una solicitud común que observamos en las extensiones del lector de PDF. En todos los casos, seguiremos comunicando nuestro trabajo y usaremos el Grupo de la comunidad de Extensiones web de forma regular como un lugar para debatir ideas y acordar lo que nos gustaría ver a continuación.