Mozilla heeft aangekondigd dat het is begonnen met het testen van Firefox' implementatie van de derde versie van het Chrome-manifest, waarin de mogelijkheden en bronnen worden gedefinieerd die beschikbaar zijn voor add-ons die zijn geschreven met behulp van de WebExtensions API. Om de derde versie van het manifest in de bètaversie van Firefox 101 te testen, moet u de parameter "extensions.manifestV3.enabled" instellen op true en de parameter "xpinstall.signatures.required" op false op de about:config-pagina. Om add-ons te installeren, kunt u de about:debugging-interface gebruiken. De derde versie van het manifest zal naar verwachting eind dit jaar standaard worden ingeschakeld.
Vanaf versie 57 schakelde Firefox volledig over op het gebruik van de WebExtensions API voor het ontwikkelen van add-ons en stopte met de ondersteuning van XUL-technologie. De overgang naar WebExtensions maakte het mogelijk om de ontwikkeling van add-ons te verenigen met de Chrome-, Opera-, Safari- en Edge-platforms, vereenvoudigde het porten van add-ons tussen verschillende webbrowsers en maakte het mogelijk om de multi-procesmodus van werking (WebExtensions-add-ons kunnen worden uitgevoerd in afzonderlijke processen, geïsoleerd van de rest van de browser). Om de ontwikkeling van add-ons met andere browsers te verenigen, biedt Firefox vrijwel volledige compatibiliteit met de tweede versie van het Chrome-manifest.
Chrome werkt momenteel aan de overstap naar versie 2023 van het manifest, en de ondersteuning voor versie XNUMX wordt in januari XNUMX stopgezet. Omdat de derde versie van het manifest onder vuur is komen te liggen en veel inhoudsblokkerende en beveiligingsadd-ons zal doorbreken, heeft Mozilla besloten af te stappen van de praktijk van het garanderen van volledige compatibiliteit met het manifest in Firefox en een aantal wijzigingen op een andere manier door te voeren.
De belangrijkste ontevredenheid over de derde versie van het manifest houdt verband met de vertaling naar de alleen-lezen-modus van de webRequest API, die het mogelijk maakte om uw eigen handlers aan te sluiten die volledige toegang hebben tot netwerkverzoeken en verkeer on-the-fly kunnen wijzigen. Deze API wordt gebruikt in uBlock Origin en vele andere add-ons om ongepaste inhoud te blokkeren en beveiliging te bieden. In plaats van de webRequest API biedt de derde versie van het manifest een declarativeNetRequest API met beperkte mogelijkheden, die toegang biedt tot een ingebouwde filterengine die onafhankelijk blokkeerregels verwerkt, het gebruik van zijn eigen filteralgoritmen niet toestaat en geen maken het mogelijk om complexe regels in te stellen die elkaar overlappen, afhankelijk van de omstandigheden.
Bij de implementatie van de derde versie van het manifest dat in Firefox werd voorgesteld, werd een nieuwe declaratieve API voor inhoudsfiltering toegevoegd, maar in tegenstelling tot Chrome stopten ze niet met het ondersteunen van de oude blokkeermodus van de webRequest API. Andere kenmerken van de nieuwe manifestimplementatie in Firefox zijn onder meer:
- Het manifest definieert de vervanging van achtergrondpagina's door de optie Service Workers, die wordt uitgevoerd als achtergrondprocessen (Background Service Workers). Om compatibiliteit te garanderen zal Firefox deze vereiste implementeren, maar daarnaast een nieuw Event Pages-mechanisme aanbieden, dat meer bekend is bij webontwikkelaars, geen volledige herwerking van add-ons vereist en de beperkingen elimineert die gepaard gaan met het gebruik van Service Workers. Met Event Pages kunnen bestaande achtergrondpagina-toevoegingen voldoen aan de vereisten van de derde versie van het manifest, terwijl de toegang behouden blijft tot alle mogelijkheden die nodig zijn om met de DOM te werken. In de manifestimplementatie die beschikbaar is voor testen in Firefox, worden momenteel alleen Event Pages ondersteund, en er wordt beloofd dat ondersteuning voor een oplossing op basis van Service Workers later zal worden toegevoegd. Apple steunde het voorstel en implementeerde Event Pages in Safari Technology Preview 136.
- Het nieuwe gedetailleerde model voor toestemmingsverzoeken - de add-on kan niet voor alle pagina's tegelijk worden geactiveerd (de toestemming "all_urls" is verwijderd), maar werkt alleen in de context van het actieve tabblad, d.w.z. de gebruiker moet bevestigen dat de add-on voor elke site werkt. In Firefox worden alle verzoeken om toegang tot sitegegevens als optioneel beschouwd en wordt de uiteindelijke beslissing over het verlenen van toegang genomen door de gebruiker, die selectief kan beslissen welke add-on hij toegang verleent tot zijn gegevens op een bepaalde site.
- Wijziging in de afhandeling van Cross-origin-verzoeken - in overeenstemming met het nieuwe manifest zijn scripts voor inhoudsverwerking onderworpen aan dezelfde toestemmingsbeperkingen als voor de hoofdpagina waarin deze scripts zijn ingesloten (als de pagina bijvoorbeeld geen toegang heeft tot de location API, dan krijgen de script-add-ons deze toegang ook niet). Deze wijziging is volledig geïmplementeerd in Firefox.
- Op belofte gebaseerde API. Firefox ondersteunt deze API al en zal deze verplaatsen naar de naamruimte “chrome.*” voor de derde versie van het manifest.
- Het verbieden van de uitvoering van code die is gedownload van externe servers (we hebben het over situaties waarin de add-on externe code laadt en uitvoert). Firefox maakt al gebruik van externe codeblokkering en Mozilla-ontwikkelaars hebben aanvullende technieken voor het volgen van codedownloads toegevoegd die in de derde versie van het manifest worden aangeboden. Voor scripts voor inhoudverwerking wordt een afzonderlijk beleid voor beperking van de toegang tot inhoud (CSP, Content Security Policy) verstrekt.
Bron: opennet.ru