Mga developer sa Chrome browser paghunong sa suporta alang sa blocking mode sa operasyon sa webRequest API, nga nagtugot kanimo sa pag-usab sa nadawat nga sulod sa langaw ug aktibo nga gigamit sa mga add-on alang sa pagbabag sa advertising,
pagpanalipod batok sa malware, phishing, pagpaniid sa kalihokan sa user, kontrol sa ginikanan ug pribasiya.
Mga motibo sa Google:
- API blocking mode modala ngadto sa taas nga konsumo sa kapanguhaan.
Kung gigamit kini nga API, ang browser una nga nagpadala sa add-on sa tanan nga mga datos nga naa sa hangyo sa network, ang add-on nag-analisar niini ug nagbalik sa usa ka giusab nga bersyon alang sa dugang nga pagproseso sa browser o mga isyu sa pag-block sa mga panudlo. Sa kini nga kaso, ang mga nag-unang mga paglangan mitungha dili sa yugto sa pagproseso sa trapiko pinaagi sa add-on, apan tungod sa mga overhead nga gasto sa pag-coordinate sa pagpatuman sa add-on. Sa partikular, ang ingon nga mga manipulasyon nanginahanglan sa paglansad sa usa ka bulag nga proseso aron makompleto, ingon man ang paggamit sa IPC aron makig-uban niini nga proseso ug mga mekanismo sa serialization sa datos; - Ang add-on hingpit nga nagkontrol sa tanan nga trapiko sa usa ka ubos nga lebel, nga nagbukas sa daghang mga oportunidad alang sa pag-abuso ug mga paglapas sa privacy. Sumala sa estadistika sa Google, 42% sa tanang namatikdan nga malisyoso nga mga add-on migamit sa webRequest API. Namatikdan nga matag bulan, ang mga pagsulay nga magbutang ug aberids nga 1800 ka malisyosong mga add-on gibabagan sa katalogo sa Chrome Web Store. Ikasubo, ang pagrepaso wala magtugot kanamo sa pagdakop sa tanang malisyosong mga add-on nga walay eksepsiyon, mao nga aron mapalambo ang proteksyon, nakahukom nga limitahan ang mga add-on sa lebel sa API. Ang nag-unang ideya mao ang paghatag og mga add-on nga adunay access dili sa tanan nga trapiko, apan sa datos lamang nga gikinahanglan aron mapatuman ang gituyo nga pagpaandar. Sa partikular, aron babagan ang sulud, dili kinahanglan nga hatagan ang add-on nga hingpit nga pag-access sa tanan nga kompidensyal nga datos sa tiggamit;
- Gisugyot nga puli nga deklaratibo nga API nag-atiman sa tanang buluhaton sa high-performance content filtering ug nagkinahanglan lamang og mga add-on aron makarga ang mga lagda sa pagsala. Ang add-on dili makabalda sa trapiko ug ang pribado nga datos sa user nagpabilin nga dili malapas;
- Giisip sa Google ang daghang mga komento bahin sa kakulang sa pag-andar sa declarativeNetRequest API ug gipalapdan ang limitasyon sa gidaghanon sa mga lagda sa pagsala gikan sa una nga gisugyot nga 30 ka libo matag extension hangtod sa global nga maximum nga 150 ka libo, ug gidugang usab ang abilidad sa dinamikong paagi. usba ug idugang ang mga lagda, tangtangon ug ilisan ang mga ulohan sa HTTP ( Referer, Cookie, Set-Cookie) ug hangyoa ang mga parameter;
- Alang sa mga negosyo, posible nga gamiton ang blocking mode sa operasyon sa webRequest API, tungod kay ang palisiya sa paggamit sa mga add-on gitino sa usa ka administrador nga nakasabut sa mga bahin sa imprastraktura ug nahibal-an ang mga peligro. Pananglitan, ang gipiho nga API mahimong magamit sa mga negosyo aron irekord ang mga agianan sa trapiko sa empleyado ug i-integrate sa mga internal nga sistema;
- Ang tumong sa Google dili ang pagdaot o pagsumpo sa ad blocking add-on, apan aron makahimo sa paghimo sa mas luwas ug mas gamhanan nga ad blockers;
- Ang pagpanuko sa pagbiya sa blocking mode sa operasyon sa webRequest API uban sa bag-ong declarativeNetRequest gipatin-aw sa tinguha nga limitahan ang access sa mga add-on sa confidential data. Kung imong biyaan ang webRequest API sama sa, kadaghanan sa mga addon dili mogamit sa mas luwas nga deklaratiboNetRequest, tungod kay kung magpili tali sa seguridad ug gamit, kadaghanan sa mga developer kasagarang mopili sa pagpaandar.
:
- Gidumala sa mga add-on nga developer nagpakita sa usa ka gamay nga kinatibuk-ang epekto sa performance sa ad blocking add-on (sa panahon sa pagsulay, ang performance sa lain-laing mga add-on gitandi, apan sa walay pagtagad sa overhead sa usa ka dugang nga proseso nga coordinate sa pagpatuman sa mga handler sa blocking mode sa ang webRequest API);
- Dili praktikal ang hingpit nga paghunong sa pagsuporta sa usa ka API nga aktibong gigamit sa mga add-on. Imbis nga tangtangon kini, mahimo nimong idugang ang usa ka bulag nga pagtugot ug higpit nga kontrolon ang pagkaigo sa paggamit niini sa mga add-on, nga makaluwas sa mga tagsulat sa daghang sikat nga mga add-on gikan sa hingpit nga pagtrabaho pag-usab sa ilang mga produkto ug malikayan ang pagputol sa pagpaandar;
- Aron makunhuran ang gasto sa overhead, dili nimo mapapas ang API, apan i-remake kini base sa mekanismo sa Saad, susama sa pagpatuman sa webRequest sa Firefox;
- Ang gisugyot nga alternatibo, declarativeNetRequest, wala maglakip sa tanan nga mga panginahanglan sa mga add-on developers alang sa ad blocking ug seguridad/privacy, tungod kay wala kini naghatag og hingpit nga kontrol sa mga hangyo sa network, wala magtugot sa paggamit sa custom filtering algorithms, ug dili motugot ang paggamit sa komplikado nga mga lagda nga nagsapaw sa usag usa depende sa mga kondisyon;
- Uban sa kasamtangan nga kahimtang sa declarativeNetRequest API, imposible nga mabuhat pag-usab ang kasamtangan nga gamit sa uBlock Origin ug uMatrix add-on nga wala mausab, ug naghimo usab nga dugang nga pagpalambo sa usa ka NoScript port para sa Chrome nga walay kapuslanan;
- Ang mga kabalaka bahin sa pagkapribado layo ra kaayo, tungod kay ang read-only, non-blocking mode sa webRequest API gibilin sa lugar ug gitugotan gihapon ang mga malisyosong add-on nga makontrol ang tanan nga trapiko, apan wala maghatag ug katakus nga makabalda niini sa langaw (bag-o ang sulod, ibutang ang imong mga advertisement, pagdagan sa mga minero ug analisa ang mga sulod sa mga porma sa pag-input nga mahimong gamiton human mahuman ang pagkarga sa panid);
- Mga developer sa browser , ΠΈ , nga gitukod sa Chromium nga makina, nagtinguha nga ibilin ang suporta alang sa webRequest blocking mode sa ilang mga produkto.
Source: opennet.ru