Google-ը արդարացնում է webRequest API-ի սահմանափակումը, որն օգտագործվում է գովազդային արգելափակումների կողմից

Chrome բրաուզերի մշակողներ փորձեց արդարացնել webRequest API-ի արգելափակման ռեժիմի աջակցության դադարեցում, որը թույլ է տալիս արագորեն փոխել ստացված բովանդակությունը և ակտիվորեն օգտագործվում է գովազդի արգելափակման հավելումներում,
պաշտպանություն չարամիտ ծրագրերից, ֆիշինգից, օգտատերերի գործունեության լրտեսությունից, ծնողական վերահսկողությունից և գաղտնիությունից:

Google-ի դրդապատճառները.

• API-ի արգելափակման ռեժիմ webRequest հանգեցնում է ռեսուրսների մեծ սպառման:
  Այս API-ն օգտագործելիս զննարկիչը սկզբում ուղարկում է հավելումը ցանցի հարցումում պարունակվող բոլոր տվյալները, հավելումը վերլուծում է դրանք և վերադարձնում փոփոխված տարբերակը՝ հետագա մշակման համար բրաուզերում կամ թողարկում է արգելափակման հրահանգներ: Այս դեպքում հիմնական ուշացումներն առաջանում են ոչ թե հավելման կողմից տրաֆիկի մշակման փուլում, այլ հավելման կատարման համակարգման վերին ծախսերի պատճառով: Մասնավորապես, նման մանիպուլյացիաները պահանջում են լրացնելու համար առանձին գործընթացի մեկնարկ, ինչպես նաև այս գործընթացի և տվյալների սերիալացման մեխանիզմների հետ փոխազդեցության համար IPC-ի օգտագործումը.

• Հավելվածը ամբողջությամբ վերահսկում է ամբողջ երթևեկությունը ցածր մակարդակով, ինչը բացում է հսկայական հնարավորություններ չարաշահումների և գաղտնիության խախտումների համար: Google-ի վիճակագրության համաձայն՝ հայտնաբերված բոլոր վնասակար հավելումների 42%-ն օգտագործել է webRequest API-ը: Նշվում է, որ ամեն ամիս Chrome Web Store կատալոգում արգելափակվում են միջինը 1800 վնասակար հավելումներ տեղադրելու փորձերը։ Ցավոք, վերանայումը մեզ թույլ չի տալիս առանց բացառության բռնել բոլոր վնասակար հավելումները, ուստի պաշտպանությունն ուժեղացնելու համար որոշվեց սահմանափակել հավելումները API մակարդակով: Հիմնական գաղափարն այն է, որ հավելումները հասանելի լինեն ոչ բոլոր տրաֆիկներին, այլ միայն այն տվյալներին, որոնք անհրաժեշտ են նախատեսված գործառույթն իրականացնելու համար: Մասնավորապես, բովանդակությունը արգելափակելու համար անհրաժեշտ չէ հավելմանը լիարժեք հասանելիություն տալ օգտատիրոջ բոլոր գաղտնի տվյալներին.
• Առաջարկվող փոխարինող դեկլարատիվ API-ն դեկլարատիվ NetRequest հոգ է տանում բարձր արդյունավետությամբ բովանդակության զտման բոլոր աշխատանքների մասին և պահանջում է միայն հավելումներ՝ զտման կանոնները բեռնելու համար: Հավելվածը չի կարող խանգարել երթևեկությանը, և օգտատիրոջ անձնական տվյալները մնում են անձեռնմխելի.
• Google-ը հաշվի է առել շատ մեկնաբանություններ՝ կապված declarativeNetRequest API-ի ֆունկցիոնալության բացակայության հետ, և ընդլայնել է զտման կանոնների քանակի սահմանաչափը սկզբնապես առաջարկված 30 հազարից մեկ ընդլայնման համար մինչև 150 հազար գլոբալ առավելագույնը, ինչպես նաև ավելացրել է դինամիկ կերպով: փոխել և ավելացնել կանոններ, հեռացնել և փոխարինել HTTP վերնագրերը (Referer, Cookie, Set-Cookie) և պահանջել պարամետրերը.
• Ձեռնարկությունների համար հնարավոր է օգտագործել webRequest API-ի գործունեության արգելափակման ռեժիմը, քանի որ հավելումների օգտագործման քաղաքականությունը որոշվում է ադմինիստրատորի կողմից, ով հասկանում է ենթակառուցվածքի առանձնահատկությունները և տեղյակ է ռիսկերին: Օրինակ, նշված API-ն կարող է օգտագործվել ձեռնարկություններում՝ աշխատակիցների երթևեկության հոսքերը գրանցելու և ներքին համակարգերի հետ ինտեգրվելու համար.
• Google-ի նպատակն է ոչ թե խափանել կամ ճնշել գովազդի արգելափակման հավելումները, այլ հնարավորություն տալ ստեղծել ավելի անվտանգ և հզոր գովազդային արգելափակումներ.
• WebRequest API-ի արգելափակման ռեժիմից դուրս գալու դժկամությունը նոր դեկլարատիվ NetRequest-ի հետ միասին բացատրվում է հավելումների մուտքը գաղտնի տվյալներին սահմանափակելու ցանկությամբ: Եթե ​​դուք թողնեք webRequest API-ն այնպես, ինչպես կա, հավելումների մեծ մասը չի օգտագործի ավելի ապահով declarativeNetRequest-ը, քանի որ անվտանգության և ֆունկցիոնալության միջև ընտրություն կատարելիս մշակողների մեծ մասը սովորաբար ընտրում է ֆունկցիոնալությունը:

Առարկություններ մշակողները լրացումներ:

• Իրականացվում է հավելումների մշակողների կողմից Թեստեր ցույց տալ աննշան ընդհանուր ազդեցությունը գովազդի արգելափակման հավելումների կատարման վրա (փորձարկման ընթացքում համեմատվել է տարբեր հավելումների կատարումը, բայց առանց հաշվի առնելու լրացուցիչ գործընթացի գերբեռնվածությունը, որը համակարգում է կարգավորիչների կատարումը արգելափակման ռեժիմում. webRequest API);
• Գործնական չէ ամբողջությամբ դադարեցնել API-ի աջակցությունը, որն ակտիվորեն օգտագործվում է հավելումներում: Այն հեռացնելու փոխարեն, դուք կարող եք ավելացնել առանձին թույլտվություն և խստորեն վերահսկել դրա օգտագործման համապատասխանությունը հավելումներում, ինչը կփրկի շատ հայտնի հավելումների հեղինակներին իրենց արտադրանքը ամբողջությամբ վերամշակելուց և կխուսափի ֆունկցիոնալության կրճատումից.
• Ընդհանուր ծախսերը նվազեցնելու համար դուք չեք կարող ջնջել API-ն, այլ վերափոխել այն Promise մեխանիզմի հիման վրա, որը նման է Firefox-ում webRequest-ի իրականացմանը.
• Առաջարկվող այլընտրանքը՝ declarativeNetRequest-ը, չի ծածկում հավելումների մշակողների բոլոր կարիքները գովազդի արգելափակման և անվտանգության/գաղտնիության համար, քանի որ այն չի ապահովում ամբողջական վերահսկողություն ցանցի հարցումների նկատմամբ, թույլ չի տալիս օգտագործել հատուկ զտման ալգորիթմներ և թույլ չի տալիս: բարդ կանոնների օգտագործումը, որոնք համընկնում են միմյանց՝ կախված պայմաններից.
• DeclarativeNetRequest API-ի ներկա վիճակի դեպքում անհնար է վերականգնել uBlock Origin և uMatrix հավելումների առկա ֆունկցիոնալությունը անփոփոխ, ինչպես նաև անիմաստ է դարձնում NoScript պորտի հետագա զարգացումը Chrome-ի համար.
• Գաղտնիության վերաբերյալ մտահոգությունները հեռու են, քանի որ webRequest API-ի միայն կարդալու, չարգելափակող ռեժիմը մնացել է տեղում և դեռ թույլ է տալիս վնասակար հավելումներին վերահսկել ողջ երթևեկությունը, բայց չի ապահովում դրան միջամտելու հնարավորությունը: թռչել (փոխել բովանդակությունը, տեղադրել ձեր գովազդները, գործարկել հանքագործներ և վերլուծել մուտքագրման ձևերի բովանդակությունը, կարող են օգտագործվել էջի բեռնումն ավարտելուց հետո);
• Բրաուզերի մշակողներ խիզախ, Opera и Vivaldi, որը կառուցված է Chromium շարժիչի վրա, մտադիր է իրենց արտադրանքներում թողնել webRequest արգելափակման ռեժիմի աջակցություն:

Source: opennet.ru