Viitorul Manifest V3 pentru extensiile Google Chrome va schimba modul în care funcționează blocanții de anunțuri pe Chrome. Este aceasta calea corectă pentru blocatorii de anunțuri și pentru Google?
Google Chrome este cel mai popular browser web multiplatform disponibil pe piață chiar acum, pretinzând 62,7% din cota globală de utilizare a browserului până în mai 2019, Safari de la Apple ocupând locul al doilea cu 15,89% și Firefox de la Mozilla pretinzând 5,07%. Datorită ponderii sale, cele mai mici schimbări pe care Google Chrome le întreprinde pentru platforma sa ajung să afecteze milioane de utilizatori din întreaga lume. Deci, când Google a anunțat următoarea versiune de manifest a extensiilor sub forma Manifest V3 pentru Google Chrome Extensions, am știut că aveau câteva schimbări majore, mai ales când a ieșit la lumină că Google construia un API de blocare a conținutului în Chrome în sine.
Ce este Manifest V3?
Dacă sunteți un utilizator Chrome activ, utilizați fără îndoială câteva extensii. Extensiile sunt mici programe software care personalizează experiența de navigare folosind
API-urile oferite de browser, permițând utilizatorilor să adapteze funcționalitatea și comportamentul pentru a se potrivi nevoilor și preferințelor lor individuale. Aceste extensii sunt distribuite în principal prin intermediul Magazinul web Chrome, care găzduiește peste 180.000 de extensii.De cand la sfarsitul anului trecut, Google a lucrat la „Manifest V3”, un set de modificări propuse pentru platforma Chrome Extensions care pot fi clasificate drept „schimbări de ultimă oră”. Dupa cum document de discuție publică pentru Manifest V3, versiunea manifestului de extensie este un mecanism de restricționare a anumitor capabilități la o anumită clasă de extensii. Aceste restricții pot fi sub forma unei versiuni minime sau a unei versiuni maxime. Restricționarea la o versiune minimă permite ca API-urile sau capabilitățile mai noi să fie disponibile numai pentru extensiile mai noi în timp ce restricționarea la o versiune de manifest maxim permite ca API-urile sau capabilitățile mai vechi să fie treptat depreciat.
În termeni mai simpli, o nouă versiune de manifest permite Chrome să restricționeze API-urile și funcțiile la această nouă versiune de manifest, în pentru a forța dezvoltatorii de extensii să migreze de la anumite API-uri mai vechi din cauza impactului lor negativ asupra utilizatorului experienţă. Implementarea unei extensii în Manifest V3 ar trebui, teoretic, să ofere garanții mai puternice din perspectiva securității, confidențialității și performanței.
Deși există o gamă largă de modificări subliniate în Manifest V3, cea mai controversată schimbare se referă la decizia Google de a limita abilitățile de blocare prezente în versiunea existentă. chrome.webRequest API (și concentrați API-ul în jurul observației în loc de blocare) și apoi prezentați aceste abilități de blocare printr-un nou chrome.declarativeNetRequest API. Această schimbare specială are a inflamat comunitatea deoarece ajunge să vizeze mecanismul de blocare a reclamelor al celebrei extensii de blocare a reclamelor, uBlock Originși afectează direct peste 10 milioane de utilizatori.
Înainte de a aborda această problemă, să aruncăm o privire la modul în care webRequest API se compară cu declarativeNetRequest API.
Web Request API și Declarative Net Request API
Prezentul
Descrierea oficială a Web Request descrie API-ul după cum urmează:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
Cu Web Request, Chrome trimite toate datele dintr-o rețea solicită extensiei care o ascultă. Extensia are apoi șansa de a evalua solicitarea și de a instrui Chrome despre ce să facă cu cererea: permiteți-o, blocați-o sau trimiteți-o cu unele modificări.
Urmați secvența evenimentelor pentru a înțelege ce se întâmplă atunci când extensiile folosesc API-ul Web Request. Când un utilizator cu o extensie Web Request instalată face clic pe un link, Chrome informează extensia că a fost făcută o solicitare de date înainte ca cererea să ajungă la server. Extensia poate alege să modifice cererea în această etapă. Serverul răspunde apoi, dar răspunsul trece din nou prin extensie, iar extensia poate dicta dacă răspunsul trebuie modificat. Apoi Chrome redă pagina și utilizatorul poate vedea rezultatul acțiunii sale de clic.
Pe măsură ce Chrome predă toate datele dintr-o cerere de rețea, extensiile care utilizează API-ul Web Request au acces pentru a citi și modifica tot ceea ce face un utilizator pe web. Deci, în timp ce blocanții de conținut precum uBlock Origin utilizează cu înțelepciune potențialul acestui API, Google susține că alte extensii cu intenții rău intenționate au abuzat de același lucru pentru a obține acces la personalul utilizatorilor informație. Potrivit Google, 42% dintre extensiile rău intenționate au folosit API-ul Web Request din ianuarie 2018. Google mai susține că există „costuri semnificative de performanță” implicate cu API ca versiune de blocare necesită un proces persistent și adesea de lungă durată, care este fundamental incompatibil cu „leneș” proceselor.
Cu Manifest V3, Google își propune să limiteze acest API în forma sa de blocare. Ca alternativă, Google oferă API-ul Declarative Net Request.
Viitorul
Descrierea oficială a Declarative Net Request descrie API-ul după cum urmează:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Cu Declarative Net Request, Chrome nu trebuie să trimită toate informațiile despre o solicitare către extensia de ascultare. În schimb, extensia înregistrează reguli cu Chrome care spun browserului în prealabil ce să facă dacă sunt văzute anumite tipuri de solicitări.
Extensia își specifică regulile în prealabil. Solicitarea utilizatorilor este apoi comparată cu această regulă de către browser (și nu extensia), iar acțiunea este întreprinsă și de browser, iar pagina este redată ulterior. Google menționează că acest lucru le permite să asigure eficiența, deoarece pot exercita controlul asupra algoritmului care determină rezultatul și pot preveni sau dezactiva regulile ineficiente. Prezintă, de asemenea, garanții de confidențialitate mai bune pentru utilizatorul final, deoarece detaliile cererii de rețea nu sunt expuse extensiei. Deoarece procesele persistente și de lungă durată nu mai sunt necesare (deoarece regulile sunt înregistrate în prealabil), Google susține că această abordare aduce, de asemenea, îmbunătățiri ale performanței, care vor face extensiile mult mai viabile, cu resurse limitate platforme.
Declarative Net Request va fi disponibilă atât pentru Manifest V2 (actuală) cât și pentru Manifest V3, dar acesta va fi modalitatea principală prin care Google va permite ca solicitările de rețea să fie modificate în Manifest V3.
Controversa
Modificările Google par să aibă sens până când auziți cealaltă parte a poveștii, în principal cea a blocatorilor de anunțuri. Această migrare specială a API-ului este văzută ca modalitatea Google de a elimina blocanții de anunțuri, deoarece schimbă fundamental modul în care funcționează unul dintre cei mai populari blocanți de anunțuri. Acest lucru se leagă de „teoria” conform căreia Google este motivat către această schimbare mai mult din perspectiva afacerii decât din perspectiva securității utilizatorilor. La urma urmei, Google se bazează în mare măsură pe publicitate pentru veniturile sale, iar blocanții de reclame sunt percepuți ca o amenințare directă pentru clienții Google în acest sens, așa cum a fost dezvăluit prin Depunerea formularului SEC 10-K din Alphabet din 2018 (prin intermediul Registrul):
Tehnologiile noi și existente ar putea afecta capacitatea noastră de a personaliza reclamele și/sau ar putea bloca anunțurile online, ceea ce ne-ar dăuna afacerii.
Tehnologiile au fost dezvoltate pentru a face reclamele personalizabile mai dificile sau pentru a bloca complet afișarea anunțurilor și unii furnizori dintre serviciile online au tehnologii integrate care ar putea afecta funcționalitatea de bază a digitalului terță parte publicitate. Majoritatea veniturilor noastre Google provin din taxele plătite nouă în legătură cu afișarea de anunțuri online. Drept urmare, astfel de tehnologii și instrumente ar putea afecta negativ rezultatele noastre operaționale.
Google a trebuit emite o declarație pentru a aborda acest lucru, reiterându-și poziția conform căreia schimbarea este în interesul confidențialității utilizatorilor și nu un atac direct împotriva blocanților de anunțuri:
Nu împiedicăm dezvoltarea agenților de blocare a reclamelor și nici nu împiedicăm utilizatorii să blocheze reclamele. În schimb, dorim să ajutăm dezvoltatorii, inclusiv blocanții de conținut, să scrie extensii într-un mod care să protejeze confidențialitatea utilizatorilor.
Trebuie făcută referire la două dintre cele mai populare blocare de anunțuri disponibile pe Google Chrome: uBlock Origin și Adblock plus, ambele adoptând abordări diferite pentru a obține același rezultat al blocării conținutului. uBlock Origin se bazează în mare măsură pe Web Request API, iar comunitatea a preferat această extensie de-a lungul anilor. Adblock Plus și alte extensii de blocare a conținutului se bazează, de asemenea, pe porțiunea de blocare a cererii web, așa că modificările aduse acestui API vor ajunge să afecteze majoritatea blocanților de conținut în cel puțin o anumită capacitate.
Forța Google de a renunța la cererea web va ucide, în esență, uBlock Origin în formatul său actual, ceva care într-adevăr va afecta mulți utilizatori. În timp ce utilizatorii fără loialitate (și fără intenția de a se deranja cu modul în care se realizează blocarea anunțurilor) vor găsi soluții alternative care vin cu propriile lor dezavantaje, va deveni imposibil. pentru loialiștii și entuziaștii să vină cu noi modele de motoare de filtrare pentru a ocoli diferitele tehnici pe care site-urile web le vor veni în cele din urmă pentru a combate blocarea anunțurilor pe acest API specific.
Declarative Net Request a fost, de asemenea, propus să fie un motor de filtrare destul de limitat, așa cum era planificată inițial să aibă o limită de 30.000 de reguli pentru regulile de filtru static per extensie (reguli care sunt declarate în timpul instalării); și limita de 5.000 de reguli pentru regulile de filtru dinamic per extensie (reguli care pot fi adăugate după instalare). Orice reguli în exces vor fi ignorate, ceea ce este o problemă, deoarece EasyList pentru Adblock Plus în sine are 70.000 de reguli, în timp ce uBlock Origin poate fi configurat să ruleze cu peste 100.000 de reguli. După reacțiile inițiale din partea comunității, Google a răspuns prin promisiunea de a modifica limita de reguli statice de la 30.000 de reguli per extensie la un maxim global de 150.000 de reguli. Acest lucru are apoi efectul secundar de a împiedica utilizatorii să folosească alte scripturi cu reguli grele în combinație cu un blocant de anunțuri, astfel încât utilizatorii vor trebui să jongleze cu preferințele lor.
În afară de limita limitată de filtrare, Declarative Net Request poate redirecționa numai către adrese URL statice, deci nu este inclus suport pentru potrivirea modelelor. uBlock Origin se bazează în mare măsură pe potrivirea modelelor și pe dezvoltatorul extensiei a declarat că nu este posibilă modernizarea algoritmul de potrivire al extensiei sale pentru a îndeplini cerințele API-urilor. API-ul ar necesita, de asemenea, o actualizare completă a extensiei pentru a actualiza pur și simplu lista de filtre, ceea ce ar fi o activitate mult prea frecventă având în vedere frecvența cu care sunt actualizate aceste liste de filtre. Desigur, aceste actualizări ar depinde și de criteriile și procesele de examinare a extensiilor Google.
Pe de altă parte, Google și-a menținut întotdeauna poziția conform căreia intenția sa de a se îndepărta de Web Request este de la a perspectiva securității, deoarece API-ul Web Request este prea puternic în forma sa actuală și lasă deschisă o cameră foarte largă pentru abuz. Acest abuz nu este doar teoretic, deoarece Google a menționat că 42% dintre extensiile rău intenționate au abuzat de acest API. Apple Safari API Content Blocker a fost conceput ca Declarative Net Request din motive similare, deoarece există mai puțin loc pentru un dezvoltator necinstiți de exploatat. Pe cererea web nerfed, cererile de rețea ar fi în continuare observabile, dar ar avea nevoie de permisiuni pe gazdele relevante. Cu Manifest V3, permisiunile de gazdă se schimbă, de asemenea, semnificativ și nu mai pot fi acordate într-un mod general în momentul instalării.
Google a folosit, de asemenea, cheltuielile generale de performanță ca motivație pentru schimbare. Evaluarea solicitărilor de rețea are loc în firul JavaScript al extensiei, ceea ce poate fi costisitor pentru performanță. Ca o respingere, dezvoltatorul uBlock Origin menționează că extensia sa nu suportă nicio penalizare semnificativă de performanță chiar și atunci când aveți până la 140.000 de filtre statice de aplicat. Costurile suportate sunt pretinse a fi ușor recuperate de resursele care sunt împiedicate să fie descărcate de pe servere la distanță și, prin urmare, nu sunt procesate de browser.
Chiar dacă Google nu folosește acest raționament, un argument împotriva Web Request poate fi prezentat și pentru eficiența blocării anunțurilor. Cu Web Request, dacă o extensie nu răspunde la timp (din cauza unei întârzieri sau a unui blocaj), cererea de gestionare a rețelei este permisă, ceea ce permite reclamelor să treacă prin blocarea anunțurilor. Declarative Net Request, pe de altă parte, nu ar suferi de acest dezavantaj. În schimb, reclamele vor trece dacă nu sunt prinse în regulile statice, iar acest lucru se va întâmpla de cele mai multe ori.
Concluzie
Din explicațiile de mai sus, este clar că Declarative Net Request nu este o clonă de funcționalitate 1:1 pentru blocare. capabilitățile API-ului Web Request, iar dezvoltatorii de extensii vor fi deranjați atunci când munca lor grea va fi handicapată de astfel de schimbări. Dar raționamentul Google are și o greutate -- Web Request este prea puternică, iar puterile sale trebuie să fie restrânsă în interesul mai larg al comunității de utilizatori (care cuprinde utilizatori medii împreună cu entuziaști).
Trecerea către Declarative Net Request ar fi putut fi și o mișcare de PR pozitivă -- la urma urmei, Google adaugă în Chrome un API de blocare a conținutului încorporat! Dar, din moment ce noul API vine cu propriile sale restricții grele, comunitatea consideră pe bună dreptate acest lucru ca pe o tăiere a aripilor lor. Într-o lume ideală, Google ar fi trebuit să exploreze funcționarea blocatorilor de anunțuri precum uBlock Origin înainte de a lansa noul API. Așa cum se află acum, noul API ar putea folosi mai multe relaxări ale limitelor regulilor sale pentru a se adapta la scenarii în care utilizatorii ar dori să folosească două extensii cu filtre grele.
Conform Registrul, primele versiuni cu modificări Manifest V3 vor fi disponibile din iulie 2019. Sperăm că Google acceptă feedbackul primit de la comunitatea dezvoltatorilor de extensii cu aceste versiuni.
Mulțumiri speciale editorului șef al XDA, Mishaal Rahman, pentru contribuții și asistență!
Editare: articolul a echivalat incorect funcționarea Adblock Plus cu cea a API-ului Declarative Net Request. Articolul a fost modificat în consecință. Adblock Plus va fi, de asemenea, afectat de eliminarea capabilităților de blocare ale API-ului Web Request.