Google-k justifikatzen du iragarkien blokeatzaileek erabiltzen duten webRequest APIaren murrizketa

Chrome arakatzailearen garatzaileak saiatu justifikatu webRequest APIaren funtzionamendu-moduaren laguntza etetea, jasotako edukia berehala aldatzeko aukera ematen duena eta publizitatea blokeatzeko gehigarrietan aktiboki erabiltzen dena,
malware, phishing, erabiltzaileen jarduera espioitza, gurasoen kontrolak eta pribatutasuna babestea.

Googleren arrazoiak:

• API blokeatzeko modua webEskaera baliabideen kontsumo handia dakar.
  API hau erabiltzean, nabigatzaileak lehenik sareko eskaeran jasotako datu guztiak bidaltzen dizkio gehigarriari, gehigarriak aztertu eta bertsio aldatu bat itzultzen du arakatzailean gehiago prozesatzeko edo blokeatzeko argibideak ematen ditu. Kasu honetan, atzerapen nagusiak ez dira gehigarriaren trafikoa prozesatzeko fasean sortzen, gehigarriaren exekuzioa koordinatzearen gainkostuengatik baizik. Hain zuzen ere, horrelako manipulazioek osagarri gisa prozesu bereizi bat abian jartzea eskatzen dute, baita prozesu horrekin elkarreragiteko IPC erabiltzea eta datuak serializatzeko mekanismoak ere;

• Gehigarriak guztiz kontrolatzen du trafiko guztia maila baxuan, eta horrek aukera zabalak irekitzen ditu tratu txarren eta pribatutasunaren urraketak egiteko. Google-ren estatistiken arabera, atzemandako gehigarri gaizto guztien % 42k webRequest APIa erabiltzen zuen. Kontuan izan da hilero, batez beste 1800 gehigarri gaizto jartzeko saiakerak blokeatzen direla Chrome Web Store katalogoan. Zoritxarrez, berrikuspenak ez digu uzten gaiztoko gehigarri guztiak harrapatzeko salbuespenik gabe, beraz, babesa hobetzeko, gehigarriak API mailan mugatzea erabaki zen. Ideia nagusia da gehigarriak ez trafiko guztirako sarbidea ematea, baizik eta nahi den funtzionaltasuna ezartzeko beharrezkoak diren datuetarako soilik. Bereziki, edukia blokeatzeko, ez da beharrezkoa gehigarriari isilpeko erabiltzailearen datu guztietarako sarbide osoa ematea;
• Proposatutako ordezko API deklaratiboa declarativeNetRequest errendimendu handiko edukia iragazteko lan guztiaz arduratzen da eta iragazketa-arauak kargatzeko gehigarriak baino ez ditu behar. Gehigarriak ezin du trafikoa oztopatu eta erabiltzailearen datu pribatuak ukiezinak dira;
• Google-k deklarativeNetRequest APIaren funtzionaltasun faltari buruzko iruzkin asko hartu zituen kontuan eta iragazketa-arau kopuruaren muga zabaldu zuen hasieran proposatutako 30 mila luzapen bakoitzeko 150 mila guztira, eta dinamikoki egiteko gaitasuna ere gehitu zuen. aldatu eta gehitu arauak, kendu eta ordezkatu HTTP goiburuak (Referer, Cookie, Set-Cookie) eta eskatu parametroak;
• Enpresentzat, posible da webRequest APIaren funtzionamendu blokeatzeko modua erabiltzea, gehigarriak erabiltzeko politika azpiegituraren ezaugarriak ulertzen dituen eta arriskuen berri duen administratzaile batek zehazten baitu. Adibidez, zehaztutako APIa enpresetan erabil daiteke langileen trafiko-fluxuak erregistratzeko eta barne-sistemekin integratzeko;
• Google-ren helburua ez da iragarkiak blokeatzeko gehigarriak ahultzea edo ezabatzea, iragarki-blokeatzaile seguruagoak eta indartsuagoak sortzea ahalbidetzea baizik;
• WebRequest APIaren funtzionamendu-modua blokeatzeko modua deklarativeNetRequest berriarekin batera uzteko errezeloa gehigarrien sarbidea datu konfidentzialetara mugatu nahiarekin azaltzen da. WebRequest APIa bere horretan uzten baduzu, gehigarri gehienek ez dute declarativeNetRequest seguruagoa erabiliko, izan ere, segurtasuna eta funtzionalitatea aukeratzerakoan, garatzaile gehienek normalean funtzionaltasuna aukeratuko dute.

Objekzioak garatzaileak gehigarriak:

• Gehigarrien garatzaileek egindakoa probak Erakutsi iragarkiak blokeatzeko gehigarrien errendimenduan eragin orokor hutsala (probetan zehar, hainbat gehigarriren errendimendua alderatu zen, baina blokeo moduan kudeatzaileen exekuzioa koordinatzen duen prozesu gehigarri baten kostua kontuan hartu gabe). webRequest APIa);
• Ez da praktikoa gehigarrietan aktiboki erabiltzen den API bat onartzen uztea. Kendu beharrean, aparteko baimen bat gehi dezakezu eta gehigarrietan erabileraren egokitasuna zorrozki kontrolatu, eta horrek gehigarri ezagun askoren egileei produktuak guztiz birmoldatzea eta funtzionalitatea moztea saihestuko luke;
• Gastu orokorrak murrizteko, ezin duzu APIa ezabatu, baizik eta Promise mekanismoan oinarrituta berregin, webRequest Firefoxen inplementatzearen antzera;
• Proposatutako alternatibak, declarativeNetRequest, ez ditu gehigarrien garatzaileen behar guztiak estaltzen iragarkiak blokeatzeko eta segurtasun/pribatutasunerako, ez baitu sareko eskaeren gaineko kontrol osoa ematen, ez du onartzen iragazketa algoritmo pertsonalizatuak erabiltzea eta ez baitu onartzen. baldintzen arabera elkarren gainjartzen diren arau konplexuak erabiltzea;
• DeclarativeNetRequest APIaren egungo egoerarekin, ezinezkoa da uBlock Origin eta uMatrix gehigarrien lehendik dauden funtzionalitateak aldatu gabe birsortzea, eta Chrome-rako NoScript ataka bat garatzea ere alferrikakoa da;
• Pribatutasunaren inguruko kezkak oso urrutikoak dira, webRequest APIaren irakurketa-soilik eta blokeatzeko modua bere horretan uzten baita eta oraindik ere gehigarri gaiztoek trafiko guztia kontrolatzeko aukera ematen baitute, baina ez baitu hori oztopatzeko gaitasunik ematen. hegan (edukia aldatu, iragarkiak jarri, meatzariak exekutatu eta sarrera inprimakien edukia aztertu orria kargatzen amaitu ondoren erabil daiteke);
• Arakatzaileen garatzaileak Ausarta, Opera и Vivaldi, Chromium motorra eraikita, beren produktuetan webRequest blokeatzeko moduaren laguntza uzteko asmoa dute.

Iturria: opennet.ru