Распрацоўнікі браўзэра Chrome спыненне падтрымкі блакавальнага рэжыму працы API webRequest, які дазваляе змяняць прыманы кантэнт на лета і актыўна ўжывальнага ў дадатках для блакавання рэкламы,
абароны ад шкоднаснага ПА, фішынгу, якая шпіёніць за карыстачамі актыўнасці, бацькоўскага кантролю і забеспячэнні прыватнасці.
Матывы Google:
- Блакуючы рэжым працы API прыводзіць да вялікага спажывання рэсурсаў.
Пры выкарыстанні дадзенага API браўзэр спачатку адпраўляе дадатку ўсе якія змяшчаюцца ў сеткавым запыце дадзеныя, дадатак аналізуе іх і вяртае для далейшай апрацоўкі ў браўзэры зменены варыянт або выдае інструкцыі па блакаванні. Пры гэтым асноўныя затрымкі ўзнікаюць не на стадыі апрацоўкі трафіку дадаткам, а з-за накладных выдаткаў на каардынацыю выканання дадатку. У прыватнасці, падобныя маніпуляцыі патрабуюць запуску для дапаўнення асобнага працэсу, а таксама прымянення IPC для ўзаемадзеяння з гэтым працэсам і механізмаў серыялізацыі дадзеных; - Дадатак цалкам кантралюе ўвесь трафік на нізкім узроўні, што адчыняе шырокія магчымасці для злоўжыванняў і парушэнняў прыватнасці. Па статыстыцы Google у 42% усіх выяўленых шкоднасных дадаткаў ужываўся API webRequest. Адзначаецца, што штомесяц у каталогу Chrome Web Store блакуюцца спробы размяшчэння ў сярэднім 1800 шкоднасных дадаткаў. Нажаль рэцэнзаванне не дазваляе адлоўліваць усё без выключэння шкоднасныя дадаткі, таму для ўзмацнення абароны было вырашанае абмежаваць дадаткі на ўзроўні API. Асноўная ідэя ў тым, каб даваць дадаткам доступ не да ўсяго трафіку, а толькі да тых дадзеных, якія неабходныя для рэалізацыі задуманай функцыянальнасці. У прыватнасці, для блакавання кантэнту не абавязкова прадастаўляць дапаўненню поўны доступ да ўсіх канфідэнцыйных дадзеных карыстальніка;
- Прапанаваны на замену дэкларатыўны API бярэ на сябе ўсю працу па высокапрадукцыйнай фільтрацыі кантэнту і толькі патрабуе ад дадаткаў загрузкі правіл фільтрацыі. Дадатак пры гэтым не можа ўмешвацца ў трафік і прыватныя дадзеныя карыстальніка застаюцца недатыкальнымі;
- Google улічыў шматлікія заўвагі ў стаўленні недастатковай функцыянальнасці API declarativeNetRequest і пашырыў ліміт на лік правіл фільтрацыі з першапачаткова прапанаваных 30 тысяч на кожнае пашырэнне да глабальнага максімуму ў 150 тысяч, а таксама дадаў магчымасці для дынамічнай змены і даданні правіл, выдаленні і замены HTTP-загалоўкаў ( Referer, Cookie, Set-Cookie) і параметраў запытаў;
- Для прадпрыемстваў пакінута магчымасць выкарыстання блакіруючага рэжыму працы API webRequest, бо палітыку прымянення дапаўненняў вызначае адміністратар, які разумее асаблівасці інфраструктуры і ўсведамляе рызыкі. Напрыклад, названы API можа прымяняцца на прадпрыемствах для ўліку патокаў трафіку супрацоўнікаў і інтэграцыі з унутранымі сістэмамі;
- Мэтай Google з'яўляецца не ўшчамленне і прыгнечанне дадаткаў для блакавання рэкламы, а прадастаўленне магчымасці стварэння больш бяспечных і прадукцыйных блакавальнікаў рэкламы;
- Нежаданне пакінуць блакуючы рэжым працы API webRequest нараўне з новым declarativeNetRequest тлумачыцца жаданнем абмежаваць доступ дадаткаў да канфідэнцыйных дадзеных. Калі пакінуць API webRequest як ёсць, то большасць дадаткаў не будуць выкарыстоўваць больш бяспечны declarativeNetRequest, бо звычайна пры выбары паміж бяспекай і функцыянальнасцю асноўная маса распрацоўнікаў абярэ функцыянальнасць.
:
- Праведзеныя распрацоўшчыкамі дапаўненняў паказваюць нікчэмны на агульным фоне ўплыў на прадукцыйнасць дадаткаў для блакавання рэкламы (пры тэставанні параўноўванне прадукцыйнасць розных дадаткаў, але без уліку накладных выдаткаў на працу дадатковага працэсу, які каардынуе выкананне апрацоўшчыкаў у блакавальным рэжыме API webRequest);
- Нямэтазгодна цалкам спыняць падтрымку API, актыўна выкарыстоўванага ў дадатках. Замест выдалення можна дадаць асобны дазвол і цвёрда кантраляваць адэкватнасць яго ўжывання ў дадатках, што дазволіла б пазбавіць аўтараў шматлікіх папулярных дадаткаў ад поўнай перапрацоўкі іх прадуктаў і пазбегнуць зразанні функцыянальнасці;
- Для зніжэння накладных выдаткаў можна не выдаляць API, а перарабіць на аснове механізму Promise, па аналогіі з рэалізацыяй webRequest у Firefox;
- Прапанаваная альтэрнатыва declarativeNetRequest не пакрывае ўсіх запатрабаванняў распрацоўнікаў дадаткаў для блакавання рэкламы і забеспячэнні бяспекі/прыватнасці, бо не падае поўнага кантролю за сеткавымі запытамі, не дазваляе выкарыстоўваць уласныя алгарытмы фільтрацыі і не дае магчымасць выкарыстоўваць складаныя правілы, якія перакрываюць адзін аднаго ў залежнасці ад умоў;
- Пры бягучым стане API declarativeNetRequest немагчыма ўзнавіць у нязменным выглядзе наяўную функцыянальнасць дадаткаў uBlock Origin і uMatrix, а таксама робіць бессэнсоўным далейшую распрацоўку порта NoScript для Chrome;
- Клопат аб прыватнасці надумана, бо які працуе ў рэжыме толькі для чытання неблакіруючы рэжым API webRequest пакінуты і па-ранейшаму дазваляе шкоднасным дадаткам кантраляваць увесь трафік, але не дае магчымасць на лёце ўмешвацца ў яго (змяніць змесціва, паставіць сваю рэкламу, запусціць майнеры і аналіз змесціва формаў уводу можна і пасля канчатка загрузкі старонкі);
- Распрацоўнікі браўзэраў , и , пабудаваных на рухавічку Chromium, маюць намер пакінуць у сваіх прадуктах падтрымку блакавальнага рэжыму працы webRequest.
Крыніца: opennet.ru