Mga developer ng Chrome browser paghinto ng suporta para sa blocking mode ng pagpapatakbo ng webRequest API, na nagpapahintulot sa iyo na baguhin ang natanggap na nilalaman sa mabilisang at aktibong ginagamit sa mga add-on para sa pagharang sa advertising,
proteksyon laban sa malware, phishing, pag-espiya sa aktibidad ng user, kontrol ng magulang at privacy.
Mga motibo ng Google:
- API blocking mode humahantong sa mataas na pagkonsumo ng mapagkukunan.
Kapag ginagamit ang API na ito, ipinapadala muna ng browser ang add-on sa lahat ng data na nakapaloob sa kahilingan sa network, sinusuri ito ng add-on at nagbabalik ng binagong bersyon para sa karagdagang pagproseso sa browser o naglalabas ng mga tagubilin sa pagharang. Sa kasong ito, ang mga pangunahing pagkaantala ay lumitaw hindi sa yugto ng pagpoproseso ng trapiko ng add-on, ngunit dahil sa mga overhead na gastos sa pag-coordinate ng pagpapatupad ng add-on. Sa partikular, ang mga naturang manipulasyon ay nangangailangan ng paglulunsad ng isang hiwalay na proseso upang umakma, gayundin ang paggamit ng IPC upang makipag-ugnayan sa prosesong ito at mga mekanismo ng serialization ng data; - Ganap na kinokontrol ng add-on ang lahat ng trapiko sa mababang antas, na nagbubukas ng malalaking pagkakataon para sa pang-aabuso at mga paglabag sa privacy. Ayon sa istatistika ng Google, 42% ng lahat ng nakitang nakakahamak na add-on ay gumamit ng webRequest API. Napansin na bawat buwan, ang mga pagtatangkang maglagay ng average na 1800 malisyosong add-on ay na-block sa catalog ng Chrome Web Store. Sa kasamaang palad, ang pagsusuri ay hindi nagpapahintulot sa amin na makuha ang lahat ng mga nakakahamak na add-on nang walang pagbubukod, kaya upang mapahusay ang proteksyon, napagpasyahan na limitahan ang mga add-on sa antas ng API. Ang pangunahing ideya ay upang magbigay ng mga add-on na may access hindi sa lahat ng trapiko, ngunit sa data lamang na kinakailangan upang maipatupad ang nilalayong pagpapagana. Sa partikular, upang harangan ang nilalaman, hindi kinakailangang bigyan ang add-on ng ganap na access sa lahat ng kumpidensyal na data ng user;
- Iminungkahing kapalit na declarative API nangangasiwa sa lahat ng gawain ng pag-filter ng content na may mataas na pagganap at nangangailangan lamang ng mga add-on upang mag-load ng mga panuntunan sa pag-filter. Ang add-on ay hindi maaaring makagambala sa trapiko at ang pribadong data ng user ay nananatiling hindi nalalabag;
- Isinasaalang-alang ng Google ang marami sa mga komento tungkol sa kakulangan ng functionality ng declarativeNetRequest API at pinalawak ang limitasyon sa bilang ng mga panuntunan sa pag-filter mula sa unang iminungkahing 30 thousand bawat extension hanggang sa global na maximum na 150 thousand, at nagdagdag din ng kakayahang dynamic na baguhin at magdagdag ng mga panuntunan, alisin at palitan ang mga header ng HTTP ( Referer, Cookie, Set-Cookie) at humiling ng mga parameter;
- Para sa mga negosyo, posibleng gamitin ang blocking mode ng pagpapatakbo ng webRequest API, dahil ang patakaran para sa paggamit ng mga add-on ay tinutukoy ng isang administrator na nauunawaan ang mga feature ng imprastraktura at alam ang mga panganib. Halimbawa, ang tinukoy na API ay maaaring gamitin sa mga negosyo upang itala ang mga daloy ng trapiko ng empleyado at isama sa mga panloob na system;
- Ang layunin ng Google ay hindi upang pahinain o sugpuin ang ad blocking add-on, ngunit upang paganahin ang paglikha ng mas ligtas at mas malakas na ad blocker;
- Ang pag-aatubili na umalis sa blocking mode ng pagpapatakbo ng webRequest API kasama ang bagong declarativeNetRequest ay ipinaliwanag sa pamamagitan ng pagnanais na limitahan ang pag-access ng mga add-on sa kumpidensyal na data. Kung iiwan mo ang webRequest API, hindi gagamit ng mas secure na declarativeNetRequest ang karamihan sa mga addon, dahil kapag pumipili sa pagitan ng seguridad at functionality, kadalasang pipili ng functionality ang karamihan sa mga developer.
:
- Isinasagawa ng mga add-on na developer nagpapakita ng hindi gaanong makabuluhang epekto sa pagganap ng mga add-on sa pag-block ng ad (sa panahon ng pagsubok, inihambing ang pagganap ng iba't ibang mga add-on, ngunit nang hindi isinasaalang-alang ang overhead ng karagdagang proseso na nag-coordinate sa pagpapatupad ng mga humahawak sa blocking mode ng ang webRequest API);
- Hindi praktikal na ganap na ihinto ang pagsuporta sa isang API na aktibong ginagamit sa mga add-on. Sa halip na alisin ito, maaari kang magdagdag ng hiwalay na pahintulot at mahigpit na kontrolin ang kasapatan ng paggamit nito sa mga add-on, na magliligtas sa mga may-akda ng maraming sikat na add-on mula sa ganap na muling paggawa ng kanilang mga produkto at maiwasan ang pagputol ng functionality;
- Upang mabawasan ang mga gastos sa overhead, hindi mo maaaring tanggalin ang API, ngunit gawing muli ito batay sa mekanismo ng Pangako, katulad ng pagpapatupad ng webRequest sa Firefox;
- Ang iminungkahing alternatibo, declarativeNetRequest, ay hindi sumasaklaw sa lahat ng pangangailangan ng mga add-on na developer para sa ad blocking at seguridad/privacy, dahil hindi ito nagbibigay ng ganap na kontrol sa mga kahilingan sa network, hindi pinapayagan ang paggamit ng mga custom na filtering algorithm, at hindi pinapayagan ang paggamit ng mga kumplikadong alituntunin na magkakapatong sa isa't isa depende sa mga kondisyon;
- Sa kasalukuyang estado ng declarativeNetRequest API, imposibleng muling likhain ang kasalukuyang functionality ng uBlock Origin at uMatrix add-on na hindi nagbabago, at ginagawang walang kabuluhan ang karagdagang pagbuo ng isang NoScript port para sa Chrome;
- Ang mga alalahanin tungkol sa privacy ay malayo, dahil ang read-only, non-blocking mode ng webRequest API ay naiwan sa lugar at pinapayagan pa rin ang mga nakakahamak na add-on na kontrolin ang lahat ng trapiko, ngunit hindi nagbibigay ng kakayahang makagambala dito sa lumipad (baguhin ang nilalaman, ilagay ang iyong mga patalastas, patakbuhin ang mga minero at pag-aralan ang mga nilalaman ng mga form ng pag-input na maaaring magamit pagkatapos ng pag-load ng pahina);
- Mga developer ng browser , ΠΈ , na binuo sa Chromium engine, ay naglalayong mag-iwan ng suporta para sa webRequest blocking mode sa kanilang mga produkto.
Pinagmulan: opennet.ru