Het afgelopen jaar zijn we actief betrokken geweest bij discussies met de leveranciers achter verschillende extensies voor het blokkeren van inhoud over manieren om het MV3-extensieplatform te verbeteren. Op basis van deze discussies, waarvan er vele plaatsvonden in de WebExtensions Community Group ( WECG ) in samenwerking met andere browsers, hebben we aanzienlijke verbeteringen kunnen doorvoeren.
Meer statische regelsets
Sets filterregels worden meestal gegroepeerd in lijsten. Een meer algemene lijst kan bijvoorbeeld regels bevatten die op alle gebruikers van toepassing zijn, terwijl een meer specifieke lijst locatiespecifieke inhoud kan verbergen die slechts enkele gebruikers willen blokkeren. Tot voor kort stonden we toe dat elke extensie gebruikers de keuze bood uit 50 lijsten (of “statische regelsets”), en dat er 10 daarvan tegelijkertijd konden worden ingeschakeld. In gesprekken met de community hebben ontwikkelaars van extensies overtuigend bewijs geleverd waaruit blijkt dat dit voor bepaalde gebruiksscenario's te laag was. Nadat we met deze discussies in gedachten naar de prestaties van de API in Chrome hebben gekeken, staan we nu toe dat er maximaal 50 tegelijk worden ingeschakeld. (Dit is met name aanzienlijk hoger dan de limiet van 20 die in de WECG wordt gevraagd.) We staan ook in totaal 100 regelsets toe. Dit wordt geleverd in Chrome 120 en het verhogen van de limieten wordt ondersteund door zowel Firefox als Safari, die beide al vroeg input hebben geleverd over dit voorstel.
Meer dynamische regels
De meeste regels zijn ‘statisch’ en worden bij elke update van een extensie verzonden. Om frequentere updates en door de gebruiker gedefinieerde regels te ondersteunen, kunnen extensies echter ook dynamisch regels toevoegen, zonder dat hun ontwikkelaars een nieuwe versie van de extensie naar de Chrome Web Store hoeven te uploaden.
Wanneer een extensie verzoeken dynamisch kan wijzigen op manieren die niet zijn gecontroleerd tijdens de beoordeling van de Chrome Web Store, stelt dit gebruikers bloot aan het risico van phishing of gegevensdiefstal. Een omleidingsregel kan bijvoorbeeld worden misbruikt om zonder toestemming affiliatelinks te injecteren.
Daarom hebben we uitbreidingen van maximaal 5.000 regels toegestaan, waardoor we deze functionaliteit spaarzaam konden gebruiken en gemakkelijker misbruik konden opsporen.
Ontwikkelaars van extensies als AdGuard en Adblock Plus voerden echter hun eigen analyse uit en deelden gegevens zodat een hogere limiet het mogelijk zou maken dat de regels up-to-date zijn en dat gebruikers met een groter aantal aangepaste lijsten naar Manifest V3 zouden kunnen migreren. AdGuard rapporteerde zelfs dat er elke week meer dan 2600 wijzigingen worden aangebracht in populaire lijsten, en van de vijf procent van de gebruikers die aangepaste filterlijsten gebruiken, heeft één op de vier van deze gebruikers een totaal van meer dan 5000 dynamische regels ( bron ). AdGuard noemde dit een aanzienlijke uitdaging bij het migreren van hun extensie naar Manifest V3 en we hoorden soortgelijke feedback van andere inhoudblokkers.
We hebben vastgesteld dat sommige filterregels, zoals de regels met de actie block of allow , veel veiliger zijn en minder snel worden misbruikt. Ze vormen ook de grote meerderheid van de filterregels voor advertentieblokken. Op basis hiervan heb ik een voorstel opgesteld en gedeeld in de Web Extensions Community Group om een reeks regels te definiëren die naar onze mening een lager risico vormen en er maximaal 30.000 van toestaan. We hanteren nog steeds een bovengrens om prestatieregressies te voorkomen.
Dit voorstel werd ondersteund in de Web Extensions Community Group, dus hebben we het geïmplementeerd. Vanaf Chrome 121 is de hogere limiet van 30.000 regels van toepassing op veilige DNR-regels, die we definiëren als regels met de actie block , allow , allowAllRequests upgradeScheme .
Op basis van de gegevens die door AdGuard worden gedeeld, zou tussen 98 en 99 procent van hun regels moeten profiteren van deze hogere limiet. Eventuele resterende regels worden nog steeds ondersteund en kunnen binnen de bestaande limiet worden toegevoegd.
Dit is beschikbaar in Chrome als de constante MAX_NUMBER_OF_DYNAMIC_RULES . De regellimiet voor alle andere regels voor dynamische nettoverzoeken blijft op 5.000.
Kleinere regelsetgrootte
In Chrome 118 hebben we de standaardwaarde voor het veld isUrlFilterCaseSensitive gewijzigd in false op basis van feedback van de community. Dit veld bepaalt of een regel die filtert op URL hoofdlettergevoelig is, en we hebben ontdekt dat de meeste ontwikkelaars een andere standaard in hun extensie hadden. De waarde moest dus vele malen opnieuw worden ingesteld. Door deze wijziging door te voeren, kunnen ontwikkelaars hun regelsets aanzienlijk verkleinen.
Wat is het volgende?
We zijn vastbesloten om te blijven investeren in de declarativeNetRequest API, zodat we zoveel mogelijk gebruiksscenario's kunnen ondersteunen, en kijken ernaar uit om met de gemeenschap te blijven samenwerken. In het bijzonder willen we de leden van de WECG bedanken voor hun betrokkenheid, waaronder AdGuard voor het delen van een aanzienlijke hoeveelheid gegevens die dit werk hebben gestimuleerd, en alle browserleveranciers die allemaal een belangrijk onderdeel hebben gespeeld bij het ontwerpen van deze API.
We zullen de limieten die we hebben ingesteld blijven evalueren om waar nodig aanpassingen aan te brengen. Om dit te ondersteunen, zijn we van plan om in de nabije toekomst enkele van de gegevens die we als onderdeel van dit werk hebben verzameld, te delen. Daarnaast werken we aan het toevoegen van extra mogelijkheden, zoals de mogelijkheid om te matchen met responsheaders, een veel voorkomend verzoek dat we hebben gezien bij PDF-viewerextensies. In alle gevallen zullen we ons werk blijven communiceren en de Web Extensions Community Group regelmatig gebruiken als een plek om ideeën te bespreken en af te stemmen op wat we hierna willen bekijken.