De Google-udviklere, der har ansvaret for "Google Chrome"-webbrowseren har annonceret optagelsen i Chrome 88 (forventes udgivet den 19. januar 2021) af den tredje udgave af manifestet, som har forårsaget en masse konflikter blandt udviklere af browserudvidelser, på grund af overtrædelsen af arbejdet med mange tilføjelser til at blokere upassende indhold og sikkerhed.
Det skal bemærkes, at kompatibilitet med plugins ved hjælp af den anden version fra manifestet bliver i nogen tid. Slut på support til Manifest V2 er endnu ikke fastlagt, men migreringsperioden til det nye manifest vil vare mindst et år.
Som en påmindelse, Chrome-manifestet definerer de muligheder og ressourcer, der leveres af plugins.
Det nye manifest er en del af et initiativ, der skal forbedre sikkerheden, privatliv og plug-in ydeevne. Hovedmålet med ændringerne er at gøre det nemmere at bygge sikre, højtydende plugins og sværere at bygge langsomme, usikre plugins.
Med introduktionen af Manifest V3 vil vi ikke længere tillade fjernhostet kode. Denne mekanisme bruges som en angrebsvektor af dårlige aktører til at omgå Googles malware-detektionsværktøjer og udgør en betydelig risiko for brugernes privatliv og sikkerhed.
Den største utilfredshed med det nye manifest er relateret til slutningen af support for webRequest API lockdown-tilstand, som vil være begrænset til skrivebeskyttet tilstand.
En undtagelse vil kun blive gjort for Chrome for Enterprise-udgaven, som fortsat vil være kompatibel med webRequest API. Mozilla har besluttet ikke at følge det nye manifest og vil beholde Firefox fuldt ud ved at bruge webRequest API. I stedet foreslog webRequest API'et til at filtrere indhold i det nye manifest en declarative API declarativeNetRequest.
Den nye declarativeNetRequest API giver adgang til en universel indbygget out-of-the-box filtreringsmotor, der uafhængigt behandler blokeringsregler, tillader ikke brugen af brugerdefinerede filtreringsalgoritmer og tillader ikke opsætning af komplekse og overlappende regler afhængigt af forhold.
Som en grund til at skifte til declarativeNetRequest API, bekymringer om privatlivets fred bemærket: Med den nye API vil plugins miste ubegrænset adgang til alle datastrømme, som kan omfatte følsomme brugeroplysninger.
Google har forsøgt at afbøde nogle af de udtrykte problemer under diskussion med plugin-udviklere, som vil blive påvirket af declarativeNetRequest API (for eksempel uBlock Origin, hvis forfatter mener, at declarativeNetRequest-funktionaliteten er utilstrækkelig til, at plugin'et fungerer korrekt), vil det holde op med at virke.
I overensstemmelse med ønsker fra plugin-udviklere, sTilføjet support til brug af declarativeNetRequest for flere statiske regelsæt skal du filtrere efter regulære udtryk, ændre HTTP-headere, ændre og tilføje regler dynamisk, fjerne og erstatte anmodningsparametre.
Det nye manifest introducerer også følgende ændringer, der påvirker plugin-kompatibilitet:
- Overgangen til at køre servicearbejdere i form af baggrundsprocesser, som vil kræve, at udviklere kode nogle tilføjelser.
- Ny granuleret model til at anmode om tilladelser: plugin'et vil ikke være i stand til at blive aktiveret for alle sider på én gang ("all_urls"-tilladelsen er blevet fjernet), men det vil kun fungere i sammenhæng med den aktive fane, dvs. brugeren vil have for at bekræfte pluginnets arbejde for hvert websted.
- Ændringer i behandling af anmodninger på tværs af oprindelse: Ifølge det nye manifest vil indholdsbehandlingsscripts være underlagt de samme tilladelsesbegrænsninger som for den overordnede side, hvori disse scripts er indlejret (f.eks. hvis siden ikke har adgang til placeringen API, så vil script-plugins heller ikke have denne adgang).
- Forhindrer udførelse af kode, der er downloadet fra eksterne servere (når pluginnet indlæser og udfører ekstern kode).
Endelig hvis du vil vide mere om det af noten, kan du konsultere den originale publikation I det følgende link.