In Chrome is begonnen met het testen van de derde versie van de manifest, die niet compatibel is met uBlock Origin

Google we zijn begonnen met het testen van de derde versie van het Chrome-manifest, die de werking van veel extensies voor het blokkeren van ongewenste inhoud en het waarborgen van de veiligheid verstoort. Ondersteuning voor het nieuwe manifest, dat de mogelijkheden en middelen die aan extensies worden verstrekt definieert, is toegevoegd aan experimentele builds Het nieuwe manifest is ontwikkeld in het kader van Chrome Canary.
de versterking van de veiligheid, privacy en prestaties van extensies (de belangrijkste doelstelling is het vereenvoudigen van de ontwikkeling van veilige en hoogpresterende extensies, en het bemoeilijken van de mogelijkheid om onveilige en trage extensies te creëren). van het initiatief Het manifest bevindt zich nog in een vroege alfa-testfase, is niet definitief en is toegevoegd om ontwikkelaars de kans te geven om te beginnen met experimenteren en hun extensies aan te passen.

De activering van het nieuwe manifest wordt volgend jaar verwacht. De datum waarop de ondersteuning voor de tweede versie van het manifest wordt stopgezet, is nog niet bepaald.
Om de migratie van extensies naar het nieuwe manifest te vereenvoudigen, is er een
controlelijst , inclusief wijzigingen waar ontwikkelaars van extensies op moeten letten.Laten we niet vergeten dat

de belangrijkste manifesten onvrede nieuwe verbonden zijn met de stopzetting van de ondersteuning voor de blocking mode van de webRequest API, die zal worden beperkt tot een alleen-lezen modus. Uitzonderingen worden gemaakt voor de Chrome-uitgave voor bedrijven (Chrome for Enterprise), waarin ondersteuning voor de webRequest API behouden blijft. Mozilla heeft besloten het nieuwe manifest niet te volgen en de volledige functionaliteit van de webRequest API in Firefox te behouden. In plaats van de webRequest API wordt in het nieuwe manifest een declaratieve API voorgesteld,

declarativeNetRequest. Als de webRequest API het mogelijk maakte om eigen handlers aan te sluiten, die volledige toegang hadden tot netwerkverzoeken en het verkeer on-the-fly konden wijzigen, biedt de nieuwe API declarativeNetRequest toegang tot een kant-en-klaar universeel ingebouwd filtermechanisme, dat zelfstandig blokkeringregels verwerkt, het gebruik van eigen filteralgoritmes niet toestaat en geen complexe regels die elkaar overlappen op basis van voorwaarden toestaat.In het nieuwe manifest zijn ook andere wijzigingen opgenomen die van invloed zijn op de compatibiliteit met extensies. Enkele hiervan zijn:

In het nieuwe manifest zijn ook andere wijzigingen opgenomen die van invloed zijn op de compatibiliteit met extensies. Daaronder:

• Overgang naar de uitvoering van Service Workers in de vorm van achtergrondprocessen, wat van ontwikkelaars vereist dat ze de code van bepaalde extensies aanpassen.
• Nieuw granular model voor toestemming aanvragen — een extensie kan niet meer meteen voor alle pagina's worden geactiveerd (de toestemming 'all_urls' is verwijderd), maar werkt nu alleen in de context van het actieve tabblad, dat wil zeggen dat de gebruiker toestemming moet geven voor de werking van de extensie op elke website.
• Wijziging in de verwerking van Cross-origin verzoeken — volgens het nieuwe manifest zullen dezelfde machtigingsbeperkingen van toepassing zijn op content scripts als die voor de hoofdpagina waarin deze scripts zijn ingebed (bijvoorbeeld, als de pagina geen toegang heeft tot de geolocatie-API, krijgt het extensiescript ook geen toegang).
• Verbod op het uitvoeren van code die van externe servers is geladen (betreffende situaties waarin een extensie externe code laadt en uitvoert).

Bron: opennet.ru