Compania Mozilla a publicat planul de implementare în Firefox a celei de-a treia versiuni a manifestului Chrome, care definește oportunitățile și resursele oferite extensiilor. A treia versiune a manifestului a fost criticată pentru întreruperea funcționării multor extensii menite să blocheze conținutul unerupt și să asigure securitatea.
Firefox intenționează să implementeze aproape toate funcționalitățile și restricțiile noului manifest, inclusiv API-ul declarației pentru filtrarea conținutului (declarativeNetRequest), dar, spre deosebire de Chrome, în Firefox nu va fi oprit suportul pentru vechiul mod de operare blocant al API-ului webRequest, cel puțin până când noul API nu va răspunde în totalitate nevoilor dezvoltatorilor de extensii care utilizează API-ul webRequest. Această abordare va permite compatibilitatea cu extensiile Chrome fără a afecta compatibilitatea cu extensiile bazate pe API-ul webRequest.
Să reamintim că principalul nemulțumire legată de noul manifest provine din tranziția API-ului webRequest în modul de lectură, care permitea conectarea propriilor manipulatoare, având acces complet la cererile de rețea și capabile să modifice traficul în timp real. Acest API este utilizat în uBlock Origin și în multe alte extensii destinate să blocheze conținutul unerupt și să asigure securitatea. În loc de API-ul webRequest, este propus un API declarativNetRequest, limitat în funcționalități, care oferă acces la motorul încorporat pentru filtrarea conținutului, gestionând singur regulile de blocare, fără a permite utilizarea propriilor algoritmi de filtrare și fără a permite stabilirea de reguli complexe care să se suprapună în funcție de condiții.
În Firefox, suportul pentru a treia versiune a manifestului Chrome este planificat să fie disponibil pentru testare la sfârșitul anului 2021, iar implementarea noului manifest este programată pentru începutul anului 2022. Printre caracteristicile implementării noului manifest în Firefox se numără:
- Oferirea API-ului declarativeNetRequest, dar cu păstrarea posibilității de utilizare a vechiului API webRequest.
- Modificarea procesării cererilor Cross-origin - conform noului manifest, restricțiile de permisiuni care se aplică scripturilor de procesare a conținutului vor fi aceleași cu cele pentru pagina principală în care aceste scripturi sunt integrate (de exemplu, dacă pagina nu are acces la API-ul de localizare, atunci scriptul complementului nu va obține nici el acest acces). O parte din modificările asociate cu restricțiile cererilor Cross-origin sunt deja disponibile pentru testare în versiunile nightly ale Firefox (în dezvoltare, ca parte a proiectului Fission, care poate fi activat în about:preferences#experimental) și se prevăd pentru implementare pe scară largă în al treilea trimestru al anului 2021.
- Pagini de fundal vor fi înlocuite de Service workers, care vor funcționa în formă de procese de fundal. Modificarea nu este încă pregătită pentru testare.
- API bazat pe Promise. Firefox sprijină deja acest tip de API în spațiul de nume „browser.*” și pentru a treia versiune a manifestului îl va muta în spațiul de nume „chrome.*.”
- Un nou model granular de cerere a permisiunilor - complementul nu va putea fi activat imediat pentru toate paginile (permisiunea „all_urls” a fost eliminată), ci va funcționa doar în contextul tab-ului activ, adică utilizatorul va trebui să confirme activarea complementului pentru fiecare site. Compania Mozilla lucrează la întărirea controlului accesului, dar intenționează să ofere utilizatorilor posibilitatea de a decide dacă doresc să permită complementelor să funcționeze cu diferite tab-uri.
- Interzicerea executării codului încărcat din surse externe servere (vorbind despre situațiile în care un complement încarcă și execuță cod extern). Firefox folosește deja blocarea codului extern, iar dezvoltatorii Mozilla sunt pregătiți să adauge tehnici suplimentare de urmărire a încărcărilor de cod, propuse în a treia versiune a manifestului. Va fi introdusă o politică separată de restricționare a accesului la conținut (CSP, Content Security Policy) pentru scripturile de procesare a conținutului, iar API-urile existing userScripts și contentScripts vor fi reproiectate pentru a sprijini extensiile bazate pe Service worker.
Sursa: opennet.ro
