Op 21 november begint de AMO-directory (addons.mozilla.org) met het accepteren en digitaal ondertekenen van add-ons met behulp van versie 109 van het Chrome-manifest. Deze add-ons kunnen worden getest in nachtelijke builds van Firefox. In stabiele releases wordt ondersteuning voor manifestversie 17 ingeschakeld in Firefox 2023, gepland voor 2023 januari XNUMX. De ondersteuning voor de tweede versie van het manifest zal in de nabije toekomst worden gehandhaafd, maar eind XNUMX, na beoordeling van de dynamiek van het overbrengen van toevoegingen aan de derde versie van het manifest, zal de mogelijkheid bestaan om de ondersteuning voor de tweede versie van het manifest af te schaffen. zal worden overwogen.
Het Chrome-manifest definieert de mogelijkheden en bronnen die beschikbaar zijn voor extensies die zijn geschreven met behulp van de WebExtensions API. 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 2024 van het manifest, en de ondersteuning voor versie XNUMX wordt in januari XNUMX stopgezet. Het belangrijkste doel van de wijzigingen in de nieuwe versie is om het gemakkelijker te maken om veilige en krachtige add-ons te maken, en om het moeilijker te maken om onveilige en langzame add-ons te maken. Omdat de derde versie van het manifest onder vuur is komen te liggen en veel inhoudsblokkerende en beveiligingsadd-ons zal doorbreken, heeft Mozilla besloten om niet meer volledig compatibel te zijn 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.
Onder de kenmerken van de implementatie van het nieuwe manifest in Firefox:
- Er is een nieuwe declaratieve contentfilter-API toegevoegd, maar in tegenstelling tot Chrome is de ondersteuning voor de oude blokkeermodus van de webRequest API niet stopgezet.
- Het manifest definieert de vervanging van achtergrondpagina's door de optie Service Workers, die wordt uitgevoerd als achtergrondprocessen (Background Service Workers). Om compatibiliteit in de toekomst te garanderen, zal Firefox Service Workers ondersteunen, maar momenteel worden ze vervangen door een nieuw Event Pages-mechanisme, dat bekender is bij webontwikkelaars, geen volledige herwerking van add-ons vereist en de beperkingen elimineert die gepaard gaan met het gebruik van servicemedewerkers. 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.
- 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.
Om machtigingen te beheren is een nieuwe knop ‘Unified Extensions’ aan de interface toegevoegd, die al kan worden getest in nachtelijke builds van Firefox. Met de knop kunt u direct bepalen tot welke sites elke add-on toegang heeft: de gebruiker kan de toegang van een add-on tot elke site verlenen of intrekken. Toestemmingsbeheer is alleen van toepassing op add-ons die zijn gebaseerd op de derde versie van het manifest; voor add-ons die zijn gebaseerd op de tweede versie van het manifest wordt geen granulaire toegangscontrole tot sites uitgevoerd.
- 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 en zal voor de derde versie van het manifest deze naar de naamruimte “chrome.*” verplaatsen.
- 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 gebruik van externe codeblokkering en de 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