Mozilla gaat aanvullen van de derde versie van het Chrome-manifest accepteren

Op 21 november zal de AMO-catalogus (addons.mozilla.org) beginnen met het accepteren en verifiëren van digitale handtekeningen voor extensies die gebruikmaken van versie drie van het manifest van Chrome. De desbetreffende extensies zullen getest kunnen worden in nachtbouwingen van Firefox. In de stabiele versies zal de ondersteuning van versie drie van het manifest worden ingeschakeld in Firefox 109, dat is gepland voor 17 januari 2023. Ondersteuning voor versie twee van het manifest zal op korte termijn behouden blijven, maar eind 2023 zal, na evaluatie van de migratie van extensies naar versie drie van het manifest, de mogelijkheid worden overwogen om de ondersteuning voor versie twee van het manifest als verouderd te beschouwen.

Het Chrome-manifest definieert de mogelijkheden en middelen die beschikbaar zijn voor extensies die zijn geschreven met behulp van de WebExtensions API. Sinds versie 57 is Firefox volledig overgestapt op het gebruik van de WebExtensions API voor de ontwikkeling van extensies en is de ondersteuning voor de XUL-technologie stopgezet. De overstap naar WebExtensions heeft het mogelijk gemaakt om de ontwikkeling van extensies te uniformeren met platforms als Chrome, Opera, Safari en Edge, het porteren van extensies tussen verschillende webbrowser te vereenvoudigen en volledig gebruik te maken van de multiprocess-modus (WebExtensions-extensies kunnen in afzonderlijke processen draaien, geïsoleerd van de andere delen van de browser). Voor de uniformiteit in de ontwikkeling van extensies met andere browsers wordt in Firefox bijna volledige compatibiliteit met de tweede versie van het Chrome-manifest gewaarborgd.

Momenteel is Chrome bezig met de overstap naar versie drie van het manifest, terwijl de ondersteuning voor versie twee in januari 2024 zal worden beëindigd. Het hoofddoel van de wijzigingen in de nieuwe versie is het vereenvoudigen van het maken van veilige en krachtige extensies, en het moeilijker maken om onveilige en trage extensies te creëren. Aangezien versie drie van het manifest onder kritiek staat en zal leiden tot het niet functioneren van veel extensies voor het blokkeren van ongewenste inhoud en het waarborgen van de veiligheid, heeft Mozilla besloten om niet volledig compatibel te blijven met het manifest in Firefox en sommige wijzigingen anders te implementeren.

De belangrijkste onvrede over versie drie van het manifest heeft te maken met de overstap naar een alleen-lezen modus voor de API webRequest, die het mogelijk maakte om eigen handlers aan te sluiten met volledige toegang tot netwerkverzoeken en die in realtime verkeer kon aanpassen. Deze API wordt toegepast in uBlock Origin en veel andere extensies voor het blokkeren van ongewenste inhoud en het waarborgen van de veiligheid. In plaats van de API webRequest is er in versie drie van het manifest een beperkt API declarativeNetRequest voorgesteld, dat toegang biedt tot de ingebouwde filterengine, die de blokkeringsregels zelfstandig verwerkt, geen eigen filteralgoritmen toestaat en geen complexe regels toestaat die elkaar kunnen overlappen afhankelijk van de voorwaarden.

Onder de kenmerken van de implementatie van het nieuwe manifest in Firefox:

• Er is een nieuwe declaratieve API voor contentfiltering toegevoegd, maar in tegenstelling tot Chrome is de ondersteuning voor de oude blocker-modus van de webRequest API niet stopgezet.
• In het manifest wordt de vervanging van achtergrondpagina's bepaald door een variant van Service Workers, die functioneren als achtergrondprocessen (Background Service Workers). Om toekomstige compatibiliteit te waarborgen, zal Firefox ondersteuning voor Service Workers implementeren, maar momenteel is er in plaats daarvan een nieuw mechanisme voor Event Pages voorgesteld, dat meer vertrouwd is voor webontwikkelaars, geen volledige herontwerp van extensies vereist en de beperkingen van Service Workers oplost. Event Pages stelt bestaande extensies met achtergrondpagina's in staat om te voldoen aan de vereisten van de derde versie van het manifest, terwijl alle noodzakelijke mogelijkheden voor DOM-interactie behouden blijven.
• Het nieuwe gedetailleerde machtigingsaanvraagmodel – een extensie kan niet meer direct voor alle pagina's worden geactiveerd (de machtiging 'all_urls' is verwijderd), maar werkt alleen in de context van het actieve tabblad, wat betekent dat de gebruiker het gebruik van de extensie voor elke website moet bevestigen. In Firefox worden alle verzoeken om toegang tot sitegegevens beschouwd als optioneel, en de uiteindelijke beslissing over het verlenen van toegang wordt genomen door de gebruiker, die selectief kan beslissen welke extensie toegang krijgt tot zijn gegevens op die of gene site.

  Voor het beheren van machtigingen is een nieuwe knop ‘Unified Extensions’ aan de interface toegevoegd, die al getest kan worden in de nachtelijke builds van Firefox. De knop biedt middelen voor directe controle over welke sites toegang hebben tot elke extensie - de gebruiker kan toegang tot elke site geven of intrekken. Het beheer van machtigingen is alleen van toepassing op extensies gebaseerd op de derde versie van het manifest; voor extensies op de tweede versie van het manifest is er geen gedetailleerd beheer van toegang tot sites.

  
• Wijzigingen in de afhandeling van Cross-origin verzoeken - volgens het nieuwe manifest zijn dezelfde machtigingsbeperkingen van toepassing op content-scripts als op de hoofdpagina waarin deze scripts zijn ingebed (bijvoorbeeld, als de pagina geen toegang heeft tot de API voor locatiebepaling, dan heeft het extensiescript ook geen toegang). Deze wijziging is volledig geïmplementeerd in Firefox.
• API op basis van Promise. Firefox ondersteunt deze API en zal deze voor de derde versie van het manifest naar de namespace ‘chrome.*’ verplaatsen.
• Verbod op het uitvoeren van code die van externe bronnen is geladen servers (het gaat over situaties waarin een extensie externe code laadt en uitvoert). In Firefox wordt externe code geblokkeerd en de ontwikkelaars van Mozilla hebben extra trackingtechnieken toegevoegd voor het laden van code, zoals voorgesteld in de derde versie van het manifest. Voor content scripts is er een aparte toegangsbeperkingspolitiek (CSP, Content Security Policy) geïntroduceerd.

Bron: opennet.ru