Google justifică restricția API-ului webRequest utilizat de blocanții de anunțuri

Dezvoltatorii browserului Chrome încercat fundamenta întreruperea suportului pentru modul de funcționare de blocare a API-ului webRequest, care vă permite să schimbați conținutul primit din mers și este utilizat în mod activ în suplimente pentru blocarea publicității,
protecție împotriva programelor malware, phishing, spionarea activității utilizatorilor, control parental și confidențialitate.

Motivele Google:

• Modul de blocare API webRequest duce la un consum mare de resurse.
  Când folosește acest API, browserul trimite mai întâi add-on-ului toate datele conținute în cererea de rețea, add-on-ul le analizează și returnează o versiune modificată pentru prelucrare ulterioară în browser sau emite instrucțiuni de blocare. În acest caz, principalele întârzieri apar nu în etapa de procesare a traficului de către add-on, ci din cauza costurilor generale de coordonare a execuției add-on-ului. În special, astfel de manipulări necesită lansarea unui proces separat pentru a completa, precum și utilizarea IPC pentru a interacționa cu acest proces și mecanisme de serializare a datelor;

• Suplimentul controlează complet tot traficul la un nivel scăzut, ceea ce deschide oportunități vaste pentru abuz și încălcări ale confidențialității. Conform statisticilor Google, 42% din toate suplimentele rău intenționate detectate au folosit API-ul webRequest. Se observă că în fiecare lună, încercările de a plasa în medie 1800 de suplimente rău intenționate sunt blocate în catalogul Chrome Web Store. Din păcate, revizuirea nu ne permite să surprindem toate suplimentele rău intenționate fără excepție, așa că pentru a îmbunătăți protecția, s-a decis să limităm suplimentele la nivel de API. Ideea principală este de a oferi suplimente cu acces nu la tot traficul, ci doar la datele necesare pentru implementarea funcționalității dorite. În special, pentru a bloca conținut, nu este necesar să se acorde suplimentului acces deplin la toate datele confidențiale ale utilizatorului;
• API declarativ de înlocuire propus declarativeNetRequest se ocupă de toată munca de filtrare a conținutului de înaltă performanță și necesită doar suplimente pentru a încărca regulile de filtrare. Suplimentul nu poate interfera cu traficul, iar datele private ale utilizatorului rămân inviolabile;
• Google a luat în considerare multe dintre comentariile privind lipsa de funcționalitate a API-ului declarativeNetRequest și a extins limita numărului de reguli de filtrare de la 30 de mii pe extensie propuse inițial la un maxim global de 150 de mii și a adăugat, de asemenea, capacitatea de a în mod dinamic modificați și adăugați reguli, eliminați și înlocuiți anteturile HTTP (Referer, Cookie, Set-Cookie) și solicitați parametri;
• Pentru întreprinderi, este posibil să se utilizeze modul de funcționare de blocare al API-ului webRequest, deoarece politica de utilizare a suplimentelor este determinată de un administrator care înțelege caracteristicile infrastructurii și este conștient de riscuri. De exemplu, API-ul specificat poate fi utilizat în întreprinderi pentru a înregistra fluxurile de trafic ale angajaților și pentru a se integra cu sistemele interne;
• Scopul Google nu este de a submina sau suprima suplimentele de blocare a reclamelor, ci de a permite crearea de blocare a reclamelor mai sigure și mai puternice;
• Reticența de a părăsi modul de funcționare de blocare a API-ului webRequest împreună cu noul declarativeNetRequest se explică prin dorința de a limita accesul suplimentelor la date confidențiale. Dacă lăsați API-ul webRequest așa cum este, majoritatea suplimentelor nu vor folosi declarativeNetRequest, mai sigur, deoarece atunci când alegeți între securitate și funcționalitate, majoritatea dezvoltatorilor vor alege de obicei funcționalitatea.

Obiecții dezvoltatori adaosuri:

• Realizat de dezvoltatori de suplimente teste arată un impact general nesemnificativ asupra performanței suplimentelor de blocare a reclamelor (în timpul testării, performanța diferitelor suplimente a fost comparată, dar fără a ține cont de suprasarcina unui proces suplimentar care coordonează execuția handler-urilor în modul de blocare a API-ul webRequest);
• Nu este practic să opriți complet suportarea unui API care este utilizat în mod activ în suplimente. În loc să o eliminați, puteți adăuga o permisiune separată și puteți controla cu strictețe caracterul adecvat al utilizării acesteia în suplimente, ceea ce i-ar scuti pe autorii multor suplimente populare de a-și reprelucra complet produsele și ar evita tăierea funcționalității;
• Pentru a reduce costurile generale, nu puteți șterge API-ul, ci îl puteți reface pe baza mecanismului Promise, similar cu implementarea webRequest în Firefox;
• Alternativa propusă, declarativeNetRequest, nu acoperă toate nevoile dezvoltatorilor de suplimente pentru blocarea anunțurilor și securitate/confidențialitate, deoarece nu oferă control deplin asupra solicitărilor de rețea, nu permite utilizarea algoritmilor de filtrare personalizați și nu permite utilizarea unor reguli complexe care se suprapun între ele în funcție de condiții;
• Cu starea actuală a API-ului declarativeNetRequest, este imposibil să recreați funcționalitatea existentă a suplimentelor uBlock Origin și uMatrix neschimbate și, de asemenea, face inutilă dezvoltarea ulterioară a unui port NoScript pentru Chrome;
• Preocupările cu privire la confidențialitate sunt exagerate, deoarece modul de numai citire, fără blocare al API-ului webRequest este lăsat pe loc și permite totuși suplimentelor rău intenționate să controleze tot traficul, dar nu oferă posibilitatea de a interfera cu acesta pe fly (schimbați conținutul, plasați reclamele dvs., rulați mineri și analizați conținutul formularelor de intrare pot fi folosite după ce pagina s-a terminat de încărcat);
• Dezvoltatori de browsere Curajos, Operă и Vivaldi, construit pe motorul Chromium, intenționează să lase suport pentru modul de blocare webRequest în produsele lor.

Sursa: opennet.ru