Durante el último año, participamos de forma activa en conversaciones con los proveedores detrás de varias extensiones de bloqueo de contenido sobre formas de mejorar la plataforma de extensiones de MV3. Gracias a estos debates, muchos de los cuales tuvieron lugar en el grupo de comunidad de WebExtensions (WECG) en colaboración con otros navegadores, pudimos implementar mejoras significativas.
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 incluir reglas aplicables a todos los usuarios, mientras que una lista más específica podría ocultar el contenido específico de una ubicación que solo algunos usuarios desean bloquear. Hasta hace poco, permitimos que cada extensión ofreciera a los usuarios la posibilidad de elegir entre 50 listas (o "conjuntos de reglas estáticos"), y que 10 de ellas se habilitaran simultáneamente. En conversaciones con la comunidad, los desarrolladores de extensiones brindaron evidencia convincente que demostró que esta cifra era demasiado baja para ciertos casos de uso. Después de analizar el rendimiento de la API en Chrome teniendo en cuenta estos debates, ahora permitimos que se habiliten hasta 50 al mismo tiempo. (en particular, es significativamente más alto que el límite de 20 solicitado en WECG). También permitimos 100 conjuntos de reglas en total. Se implementará en Chrome 120, y el aumento de los límites es compatible con Firefox y Safari, que proporcionaron comentarios anticipados sobre esta propuesta.
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 nueva versión de la extensión a Chrome Web Store.
Cuando una extensión puede modificar solicitudes de forma dinámica de formas que no se verificaron durante la revisión de Chrome Web Store, se expone a los usuarios a riesgos de suplantación de identidad (phishing) o robo de datos. Por ejemplo, una regla de redireccionamiento podría usarse de manera inadecuada para insertar vínculos de afiliados sin consentimiento.
En consecuencia, solo permitimos que las extensiones agregaran un máximo de 5,000 reglas que fomentaban el uso de esta funcionalidad con moderación y nos facilitaron la detección de abusos.
Sin embargo, los desarrolladores de extensiones como AdGuard y Adblock Plus realizaron su propio análisis y compartieron datos que un límite más alto permitiría tener reglas más actualizadas y a los usuarios con una mayor cantidad de listas personalizadas migrar a Manifest 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 usuarios tiene un total combinado de más de 5,000 reglas dinámicas entre ellos (fuente). AdGuard notó que esto era un desafío importante para migrar su extensión a Manifest 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. Además, constituyen la gran mayoría de las reglas de filtro de bloqueo de anuncios. En base a esto, redacté y compartí una propuesta en el grupo comunitario de extensiones web para definir un conjunto de reglas que consideramos de menor riesgo y permitir hasta 30,000 de ellas. Seguimos manteniendo un límite superior para evitar regresiones de rendimiento.
Esta propuesta se apoyó en el grupo comunitario de extensiones web, así que la implementamos. A partir de la versión 121 de Chrome, se aplica el límite más alto de 30,000 reglas a las reglas de DNR seguras, que definiremos como reglas con una acción de block, allow, allowAllRequests o upgradeScheme.
En función de los datos compartidos por AdGuard, entre el 98 y el 99% de sus reglas deberían beneficiarse de este límite más alto. Se admitirán las demás reglas y se podrán agregar dentro del límite existente.
Está disponible en Chrome como la constante MAX_NUMBER_OF_DYNAMIC_RULES. El límite para todas las demás reglas de solicitudes netas dinámicas se mantiene en 5,000.
Tamaño reducido del conjunto de reglas
En Chrome 118, cambiamos el valor predeterminado del campo isUrlFilterCaseSensitive a false según 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. En consecuencia, el valor se debía establecer muchas veces. Con este cambio, los desarrolladores pueden lograr reducciones de tamaño significativas en sus conjuntos de reglas.
Pasos siguientes
Nos comprometemos a seguir invirtiendo en la API declarativeNetRequest para poder admitir tantos casos de uso como sea posible y esperamos seguir trabajando con la comunidad. En particular, queremos agradecer a los miembros de WECG por su compromiso, incluido AdGuard por compartir una cantidad significativa de 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 establecimos para hacer los ajustes necesarios. Para ello, planeamos compartir próximamente algunos de los datos que recopilamos como parte de este trabajo. Además, estamos trabajando para agregar funciones adicionales, como la coincidencia con los encabezados de respuesta, una solicitud común que observamos en las extensiones de visualizador de PDF. En todos los casos, continuaremos comunicando nuestro trabajo y usaremos el grupo de la comunidad de extensiones web para debatir ideas y ponernos de acuerdo respecto de lo que nos gustaría examinar a continuación.