Google regverdig die beperking van die webRequest API wat deur advertensieblokkeerders gebruik word

Chrome-blaaier-ontwikkelaars probeer het regverdig staking van ondersteuning vir die blokkeermodus van die webRequest API, wat jou toelaat om die inhoud wat ontvang word op die oomblik te verander en aktief gebruik word in byvoegings om advertensies te blokkeer,
beskerming teen wanware, uitvissing, spioenasie op gebruikersaktiwiteit, ouerkontroles en privaatheid.

Google se motiewe:

• API-blokkeermodus webVersoek lei tot hoë hulpbronverbruik.
  Wanneer hierdie API gebruik word, stuur die blaaier eers die byvoeging al die data vervat in die netwerkversoek, die byvoeging ontleed dit en gee 'n gewysigde weergawe terug vir verdere verwerking in die blaaier of gee blokkeringsinstruksies uit. In hierdie geval ontstaan ​​die hoofvertragings nie in die stadium van die verwerking van verkeer deur die byvoeging nie, maar as gevolg van die oorhoofse koste van die koördinering van die uitvoering van die byvoeging. In die besonder, sulke manipulasies vereis die bekendstelling van 'n aparte proses om aan te vul, sowel as die gebruik van IPC om interaksie met hierdie proses en data serialisering meganismes;

• Die byvoeging beheer alle verkeer heeltemal op 'n lae vlak, wat groot geleenthede vir misbruik en privaatheidskendings oopmaak. Volgens Google-statistieke het 42% van alle bespeurde kwaadwillige byvoegings die webRequest API gebruik. Daar word opgemerk dat elke maand pogings om gemiddeld 1800 XNUMX kwaadwillige byvoegings te plaas in die Chrome Webwinkel-katalogus geblokkeer word. Ongelukkig laat hersiening ons nie toe om alle kwaadwillige byvoegings sonder uitsondering op te vang nie, so om beskerming te verbeter, is besluit om byvoegings op die API-vlak te beperk. Die hoofgedagte is om byvoegings te voorsien met toegang nie tot alle verkeer nie, maar slegs tot die data wat nodig is om die beoogde funksionaliteit te implementeer. In die besonder, om inhoud te blokkeer, is dit nie nodig om die byvoeging volle toegang tot alle vertroulike gebruikersdata te gee nie;
• Voorgestelde vervanging verklarende API declarativeNetRequest sorg vir al die werk van hoëprestasie-inhoudfiltrering en vereis slegs byvoegings om filterreëls te laai. Die byvoeging kan nie met verkeer inmeng nie en die gebruiker se private data bly onaantasbaar;
• Google het baie van die opmerkings oor die gebrek aan funksionaliteit van die declarativeNetRequest API in ag geneem en die limiet op die aantal filterreëls uitgebrei van die aanvanklik voorgestelde 30 duisend per uitbreiding tot 'n globale maksimum van 150 duisend, en ook die vermoë bygevoeg om dinamies verander en voeg reëls by, verwyder en vervang HTTP-opskrifte (Referer, Cookie, Set-Cookie) en versoek parameters;
• Vir ondernemings is dit moontlik om die blokkeringsmodus van die webRequest API te gebruik, aangesien die beleid vir die gebruik van byvoegings bepaal word deur 'n administrateur wat die kenmerke van die infrastruktuur verstaan ​​en bewus is van die risiko's. Die gespesifiseerde API kan byvoorbeeld in ondernemings gebruik word om werknemersverkeervloei aan te teken en met interne stelsels te integreer;
• Google se doel is nie om byvoegings vir advertensieblokkering te ondermyn of te onderdruk nie, maar om die skepping van veiliger en kragtiger advertensieblokkeerders moontlik te maak;
• Die onwilligheid om die blokkeermodus van die werking van die webRequest API saam met die nuwe declarativeNetRequest te verlaat, word verklaar deur die begeerte om die toegang van byvoegings tot vertroulike data te beperk. As jy die webRequest API net so laat, sal die meeste byvoegings nie die veiliger declarativeNetRequest gebruik nie, aangesien wanneer jy tussen sekuriteit en funksionaliteit kies, sal die meeste ontwikkelaars gewoonlik funksionaliteit kies.

Besware ontwikkelaars toevoegings:

• Uitgevoer deur byvoegingsontwikkelaars toetse toon 'n onbeduidende algehele impak op die werkverrigting van advertensieblokkerende byvoegings (tydens toetsing is die werkverrigting van verskeie byvoegings vergelyk, maar sonder inagneming van die bokoste van 'n bykomende proses wat die uitvoering van hanteerders in die blokkeermodus van die webRequest API);
• Dit is nie prakties om heeltemal op te hou om 'n API te ondersteun wat aktief in byvoegings gebruik word nie. In plaas daarvan om dit te verwyder, kan jy 'n aparte toestemming byvoeg en die toereikendheid van die gebruik daarvan in byvoegings streng beheer, wat die skrywers van baie gewilde byvoegings sal red om hul produkte heeltemal te herwerk en die sny van funksionaliteit te vermy;
• Om oorhoofse koste te verminder, kan jy nie die API uitvee nie, maar dit hermaak op grond van die Promise-meganisme, soortgelyk aan die implementering van webRequest in Firefox;
• Die voorgestelde alternatief, declarativeNetRequest, dek nie al die behoeftes van byvoegingsontwikkelaars vir advertensieblokkering en sekuriteit/privaatheid nie, aangesien dit nie volle beheer oor netwerkversoeke bied nie, nie die gebruik van pasgemaakte filteralgoritmes toelaat nie en nie toelaat nie die gebruik van komplekse reëls wat mekaar oorvleuel na gelang van die toestande;
• Met die huidige stand van die declarativeNetRequest API is dit onmoontlik om die bestaande funksionaliteit van die uBlock Origin en uMatrix-byvoegings onveranderd te herskep, en maak ook verdere ontwikkeling van 'n NoScript-poort vir Chrome sinloos;
• Kommer oor privaatheid is vergesog, aangesien die leesalleen, nie-blokkerende modus van die webRequest API in plek gelaat word en steeds kwaadwillige byvoegings toelaat om alle verkeer te beheer, maar nie die vermoë bied om daarmee in te meng op die vlieg (verander inhoud, plaas jou advertensies, voer mynwerkers uit en ontleed die inhoud van die invoervorms kan gebruik word nadat die bladsy klaar gelaai het);
• Blaaier ontwikkelaars Brave, Opera и Vivaldi, gebou op die Chromium-enjin, is van plan om ondersteuning vir die webRequest-blokkeermodus in hul produkte te laat.

Bron: opennet.ru