მომავალი Manifest V3 Google Chrome გაფართოებებისთვის შეცვლის, თუ როგორ მუშაობს რეკლამის ბლოკატორები Chrome-ზე. არის ეს სწორი გზა რეკლამის ბლოკერებისთვის და Google-ისთვის?
გუგლ ქრომი არის ყველაზე პოპულარული კროს-პლატფორმული ვებ ბრაუზერი, რომელიც ხელმისაწვდომია ბაზარზე ახლა, გლობალური ბრაუზერის გამოყენების წილის 62.7%-ს 2019 წლის მაისამდე მეორე ადგილზეა Apple-ის Safari 15,89%-ით, ხოლო Mozilla-ს Firefox-ი 5,07%-ით. მისი ლომის წილის გამო, უმცირესი ცვლილებები, რომლებსაც Google Chrome ახორციელებს თავისი პლატფორმისთვის, საბოლოოდ აისახება მილიონობით მომხმარებელზე მთელს მსოფლიოში. ასე რომ, როდესაც Google-მა გამოაცხადა შემდეგი გაფართოებების მანიფესტის ვერსია Manifest V3-ის სახით Google Chrome-ის გაფართოებებისთვის, ჩვენ ვიცოდით, რომ დიდი ცვლილებები იყო, განსაკუთრებით მაშინ, როდესაც გაირკვა, რომ Google აშენებდა კონტენტის ბლოკერის API-ს Chrome-ში თავად.
რა არის Manifest V3?
თუ Chrome-ის აქტიური მომხმარებელი ხართ, უდავოდ იყენებთ რამდენიმე გაფართოებას. გაფართოებები არის მცირე პროგრამული უზრუნველყოფის პროგრამები, რომლებიც არეგულირებენ დათვალიერების გამოცდილებას
API-ები, რომლებსაც ბრაუზერი უზრუნველყოფს, რაც მომხმარებლებს საშუალებას აძლევს მოარგონ ფუნქციები და ქცევა მათ ინდივიდუალურ საჭიროებებსა და პრეფერენციებზე. ეს გაფართოებები ნაწილდება ძირითადად მეშვეობით Chrome Web Store, სადაც განთავსებულია 180000-ზე მეტი გაფართოება.მას შემდეგ, რაც გასული წლის ბოლოს, Google მუშაობდა „Manifest V3“-ზე, შემოთავაზებული ცვლილებების ნაკრები Chrome Extensions პლატფორმაზე, რომელიც შეიძლება კლასიფიცირებული იყოს, როგორც „არღვევი ცვლილებები“. როგორც საჯარო განხილვის დოკუმენტი Manifest V3-ისთვის გაფართოების მანიფესტის ვერსია არის მექანიზმი, რომელიც ზღუდავს გარკვეული შესაძლებლობების გაფართოებების გარკვეულ კლასს. ეს შეზღუდვები შეიძლება იყოს როგორც მინიმალური, ასევე მაქსიმალური ვერსიის სახით. მინიმალური ვერსიით შეზღუდვა საშუალებას აძლევს ახალ API-ებს ან შესაძლებლობებს ხელმისაწვდომი იყოს მხოლოდ ახალი გაფართოებებისთვის ხოლო მანიფესტის მაქსიმალურ ვერსიაზე შეზღუდვა საშუალებას იძლევა უფრო ძველი API-ები ან შესაძლებლობები თანდათანობით იყოს მოძველებული.
უფრო მარტივი სიტყვებით რომ ვთქვათ, ახალი მანიფესტის ვერსია საშუალებას აძლევს Chrome-ს შეზღუდოს API-ები და ფუნქციები ამ ახალი მანიფესტის ვერსიით იმისათვის, რომ აიძულოთ გაფართოების დეველოპერები, გადაადგილდნენ გარკვეული ძველი API-ებიდან მომხმარებელზე მათი უარყოფითი გავლენის გამო გამოცდილება. Manifest V3-ში გაფართოების დანერგვამ თეორიულად უნდა უზრუნველყოს უფრო ძლიერი გარანტიები უსაფრთხოების, კონფიდენციალურობისა და შესრულების პერსპექტივიდან.
მიუხედავად იმისა, რომ Manifest V3-ში არის ასახული ცვლილებების ფართო სპექტრი, ყველაზე საკამათო ცვლილება დაკავშირებულია Google-ის გადაწყვეტილებასთან, შეზღუდოს არსებული ბლოკირების შესაძლებლობები. chrome.webRequest API (და API-ის ფოკუსირება დაკვირვების ირგვლივ დაბლოკვის ნაცვლად) და შემდეგ წარმოადგინეთ ეს დაბლოკვის შესაძლებლობები ახალი საშუალებით chrome.declarativeNetRequest API. ამ კონკრეტულ ცვლილებას აქვს ანთებდა საზოგადოებას რადგან ის მიზნად ისახავს ცნობილი რეკლამის დაბლოკვის გაფართოების რეკლამის დაბლოკვის მექანიზმს, uBlock Originდა პირდაპირ გავლენას ახდენს მის 10 მილიონ+ მომხმარებელზე.
სანამ ამ საკითხს განვიხილავთ, მოდით შევხედოთ როგორ ვებმოთხოვნა API ადარებს დეკლარაციული NetRequest API.
Web Request API და Declarative Net Request API
აწმყო
ვებ მოთხოვნის ოფიციალური აღწერა აღწერს API-ს შემდეგნაირად:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
ვებ მოთხოვნით Chrome აგზავნის ყველა ქსელის მონაცემები ითხოვს გაფართოებას, რომელიც უსმენს მას. შემდეგ გაფართოებას აქვს შესაძლებლობა შეაფასოს მოთხოვნა და დაავალოს Chrome-ს, თუ რა უნდა გააკეთოს მოთხოვნასთან: დაუშვას, დაბლოკოს ან გაგზავნოს გარკვეული ცვლილებებით.
მიჰყევით მოვლენების თანმიმდევრობას, რათა გაიგოთ, რა ხდება, როდესაც გაფართოებები იყენებენ Web Request API-ს. როდესაც მომხმარებელი, რომელსაც აქვს დაინსტალირებული Web Request გაფართოება, დააწკაპუნებს ბმულზე, Chrome აცნობებს გაფართოებას, რომ მონაცემთა მოთხოვნა განხორციელდა მანამ, სანამ მოთხოვნა სერვერამდე მიაღწევდა. გაფართოებას შეუძლია აირჩიოს მოთხოვნის შეცვლა ამ ეტაპზე. შემდეგ სერვერი პასუხობს, მაგრამ პასუხი კვლავ გადის გაფართოების მეშვეობით და გაფართოებას შეუძლია უკარნახოს საჭიროა თუ არა პასუხის შეცვლა. შემდეგ Chrome საბოლოოდ ასახავს გვერდს და მომხმარებელს შეუძლია ნახოს თავისი დაწკაპუნების მოქმედების შედეგი.
როგორც Chrome გადასცემს ქსელის მოთხოვნის ყველა მონაცემი, გაფართოებებს, რომლებიც იყენებენ Web Request API-ს, აქვთ წვდომა, წაიკითხონ და შეცვალონ ყველაფერი, რასაც მომხმარებელი აკეთებს ინტერნეტში. ასე რომ, სანამ კონტენტის ბლოკატორები, როგორიცაა uBlock Origin გონივრულად იყენებენ ამ API-ს პოტენციალს, Google ამტკიცებს, რომ მავნე განზრახვების მქონე სხვა გაფართოებებმა იგივე ბოროტად გამოიყენეს მომხმარებლების პერსონალურზე წვდომის მისაღებად ინფორმაცია. Google-ის მონაცემებით, მავნე გაფართოებების 42%-მა გამოიყენა Web Request API 2018 წლის იანვრიდან. Google ასევე აცხადებს, რომ არსებობს "მნიშვნელოვანი შესრულების ხარჯები" დაკავშირებული API-სთან, როგორც დაბლოკვის ვერსიასთან ეს მოითხოვს მუდმივ და ხშირად ხანგრძლივ პროცესს, რომელიც ფუნდამენტურად შეუთავსებელია "ზარმაცი" პროცესები.
Manifest V3-ით Google გვთავაზობს შეზღუდოს ეს API მისი დაბლოკვის ფორმით. როგორც ალტერნატივა, Google უზრუნველყოფს დეკლარაციული Net Request API-ს.
Მომავალი
დეკლარაციული Net Request-ის ოფიციალური აღწერა აღწერს API-ს შემდეგნაირად:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
დეკლარაციული ქსელის მოთხოვნით Chrome-ს არ სჭირდება მოთხოვნის შესახებ ყველა ინფორმაციის გაგზავნა მოსმენის გაფართოებაზე. ამის ნაცვლად, გაფართოება არეგისტრირებს წესებს Chrome-თან, რომლებიც წინასწარ ეუბნებიან ბრაუზერს, თუ რა უნდა გააკეთოს, თუ გარკვეული ტიპის მოთხოვნები გამოჩნდება.
გაფართოება წინასწარ განსაზღვრავს თავის წესებს. შემდეგ მომხმარებლების მოთხოვნა შეესაბამება ამ წესს ბრაუზერის მიერ (და არა გაფართოების) მიერ, ასევე მოქმედებას ახორციელებს ბრაუზერი და გვერდის შემდგომი რენდერი. Google აღნიშნავს, რომ ეს მათ საშუალებას აძლევს უზრუნველყონ ეფექტურობა, რადგან მათ შეუძლიათ განახორციელონ კონტროლი შედეგის განსაზღვრის ალგორითმზე და შეუძლიათ თავიდან აიცილონ ან გამორთონ არაეფექტური წესები. ის ასევე წარმოადგენს კონფიდენციალურობის უკეთეს გარანტიებს საბოლოო მომხმარებლისთვის, რადგან ქსელის მოთხოვნის დეტალები არ ექვემდებარება გაფართოებას. ვინაიდან მუდმივი და ხანგრძლივი პროცესები აღარ არის საჭირო (რადგან წესები წინასწარ არის რეგისტრირებული), Google აცხადებს, რომ ამ მიდგომას ასევე მოაქვს მუშაობის გაუმჯობესება, რაც გაფართოებებს მნიშვნელოვნად უფრო სიცოცხლისუნარიანს გახდის რესურსებით შეზღუდულ პირობებში პლატფორმები.
დეკლარაციული წმინდა მოთხოვნა ხელმისაწვდომი იქნება როგორც Manifest V2 (მიმდინარე), ასევე Manifest V3-ისთვის, მაგრამ ეს იქნება მთავარი გზა, რომლითაც Google დაუშვებს ქსელის მოთხოვნების შეცვლას Manifest V3-ში.
დაპირისპირება
Google-ის ცვლილებები, როგორც ჩანს, აზრი აქვს მანამ, სანამ არ გაიგებთ ამბის მეორე მხარეს, ძირითადად რეკლამის ბლოკერებს. ეს კონკრეტული API მიგრაცია განიხილება, როგორც Google-ის გზა რეკლამის ბლოკატორების მოსაკლავად, რადგან ის ძირეულად ცვლის ერთ-ერთი ყველაზე პოპულარული რეკლამის ბლოკერის მუშაობის გზას. ეს უკავშირდება "თეორიას", რომ Google მოტივირებულია ამ ცვლილებისკენ უფრო ბიზნესის, ვიდრე მომხმარებლის უსაფრთხოების პერსპექტივიდან. ყოველივე ამის შემდეგ, Google დიდად არის დამოკიდებული რეკლამაზე თავისი შემოსავლისთვის და რეკლამის ბლოკატორები აღიქმება, როგორც პირდაპირი საფრთხე Google-ის კლიენტებისთვის ამ ფრონტზე, როგორც ეს გამოვლინდა Alphabet-ის 2018 SEC ფორმა 10-K შეტანა (მეშვეობით რეესტრი):
ახალმა და არსებულმა ტექნოლოგიებმა შეიძლება გავლენა მოახდინოს რეკლამის მორგების ჩვენს უნარზე და/ან დაბლოკოს რეკლამები ონლაინ, რაც ზიანს აყენებს ჩვენს ბიზნესს.
შემუშავებულია ტექნოლოგიები, რათა გაართულოს კონფიგურირებადი რეკლამები ან მთლიანად დაბლოკოს რეკლამების ჩვენება და ზოგიერთი პროვაიდერი ონლაინ სერვისებს აქვთ ინტეგრირებული ტექნოლოგიები, რამაც შეიძლება პოტენციურად შეაფერხოს მესამე მხარის ციფრული სისტემის ძირითადი ფუნქციონირება სარეკლამო. ჩვენი Google-ის შემოსავლების უმეტესი ნაწილი მიიღება ჩვენთვის გადახდილი გადასახადებიდან ინტერნეტში რეკლამების ჩვენებასთან დაკავშირებით. შედეგად, ასეთმა ტექნოლოგიებმა და ინსტრუმენტებმა შეიძლება უარყოფითად იმოქმედოს ჩვენს ოპერაციულ შედეგებზე.
გუგლს მოუწია გაავრცელეთ განცხადება ამის გადასაჭრელად, გაიმეორეთ მისი პოზიცია, რომ ცვლილება მომხმარებლის კონფიდენციალურობის ინტერესებშია და არა პირდაპირი თავდასხმა რეკლამის ბლოკერებზე:
ჩვენ არ ვაბრკოლებთ რეკლამის ბლოკერების განვითარებას და არ ვაჩერებთ მომხმარებლებს რეკლამის დაბლოკვისგან. ამის ნაცვლად, ჩვენ გვინდა დავეხმაროთ დეველოპერებს, მათ შორის კონტენტის ბლოკერებს, დაწერონ გაფართოებები ისე, რომ დაიცვან მომხმარებლების კონფიდენციალურობა.
მინიშნება უნდა გაკეთდეს Google Chrome-ზე ხელმისაწვდომი ორ ყველაზე პოპულარულ რეკლამის ბლოკერზე: uBlock Origin და Adblock Plus, ორივე მათგანი იყენებს განსხვავებულ მიდგომას კონტენტის დაბლოკვის ერთი და იგივე შედეგის მისაღწევად. uBlock Origin დიდწილად ეყრდნობა Web Request API-ს და საზოგადოებამ წლების განმავლობაში ამ გაფართოებას ანიჭებს უპირატესობას. Adblock Plus და კონტენტის დაბლოკვის სხვა გაფართოებები ასევე ეყრდნობა ვებ მოთხოვნის დაბლოკვის ნაწილს, ამიტომ ამ API-ში ცვლილებები გავლენას მოახდენს კონტენტის ბლოკერების უმეტესობაზე, სულ მცირე, გარკვეული ტევადობით.
Google-ის მცდელობა, გააუქმოს ვებ მოთხოვნა, არსებითად მოკლავს uBlock Origin-ს მის ამჟამინდელ ფორმატში, რაც ნამდვილად იმოქმედებს უამრავ მომხმარებელზე. მიუხედავად იმისა, რომ მომხმარებლები, რომლებსაც არ აქვთ ლოიალობა (და არ აპირებენ საკუთარი თავის შეწუხებას იმის შესახებ, თუ როგორ მიიღწევა სარეკლამო ბლოკი) იპოვიან ალტერნატიულ გადაწყვეტილებებს, რომლებსაც აქვთ საკუთარი ნაკლოვანებები, ეს შეუძლებელი გახდება. ლოიალისტებმა და ენთუზიასტებმა შეიმუშავონ ახალი ფილტრაციის ძრავის დიზაინი, რათა თავიდან აიცილონ სხვადასხვა ტექნიკა, რომლებსაც ვებსაიტები საბოლოოდ გამოიმუშავებენ ამ კონკრეტულ API-ზე რეკლამის ბლოკერებთან საბრძოლველად.
დეკლარაციული წმინდა მოთხოვნა ასევე შემოთავაზებული იყო საკმაოდ შეზღუდული ფილტრაციის ძრავად, როგორც ეს იყო თავდაპირველად დაგეგმილი გქონდეთ 30000 წესის ლიმიტი თითო გაფართოების სტატიკური ფილტრის წესებზე (წესები, რომლებიც დეკლარირებულია ინსტალაციის დროს); და 5000 წესის ლიმიტი თითო გაფართოების დინამიური ფილტრის წესებზე (წესები, რომლებიც შეიძლება დაემატოს ინსტალაციის შემდეგ). ნებისმიერი ზედმეტი წესი იგნორირებული იქნება, რაც ცოტა პრობლემაა, რადგან თავად Adblock Plus-ისთვის EasyList-ს აქვს 70 000 წესი, ხოლო uBlock Origin-ის კონფიგურაცია შესაძლებელია 100 000-ზე მეტი წესით. საზოგადოების თავდაპირველი გამოხმაურების შემდეგ, Google-მა უპასუხა სტატიკური წესების ლიმიტის შეცვლის დაპირებით 30000 წესიდან თითო გაფართოებაზე გლობალურ მაქსიმუმ 150000 წესამდე. შემდეგ ამას აქვს გვერდითი ეფექტი, რაც ხელს უშლის მომხმარებლებს სხვა წესებით მძიმე სკრიპტების გამოყენებაში რეკლამის ბლოკერთან ერთად, ასე რომ მომხმარებლებს მოუწევთ ჟონგლირება თავიანთი პრეფერენციებით.
ფილტრაციის შეზღუდული ლიმიტის გარდა, დეკლარაციული წმინდა მოთხოვნა შეუძლია მხოლოდ სტატიკურ URL-ებზე გადამისამართება, ასე რომ, შაბლონის შესატყვისი მხარდაჭერა არ შედის. uBlock Origin დიდწილად ეყრდნობა შაბლონების შესაბამისობას და გაფართოების შემქმნელს განაცხადა, რომ გადაკეთება შეუძლებელია მისი გაფართოების შესატყვისი ალგორითმი API-ების მოთხოვნების დასაკმაყოფილებლად. API ასევე მოითხოვს გაფართოების სრულ განახლებას ფილტრების სიის უბრალოდ განახლებისთვის, რაც ძალიან ხშირი აქტივობა იქნება სიხშირით, რომლითაც ეს ფილტრების სიები განახლდება. რა თქმა უნდა, ეს განახლებები ასევე დამოკიდებული იქნება Google-ის გაფართოების განხილვის კრიტერიუმებსა და პროცესებზე.
მეორეს მხრივ, Google ყოველთვის ინარჩუნებდა თავის პოზიციას, რომ მისი განზრახვა გადავიდეს ვებ მოთხოვნიდან არის უსაფრთხოების პერსპექტივა, რადგან Web Request API ძალიან მძლავრია ამჟამინდელი სახით და ტოვებს ძალიან ფართო სივრცეს ბოროტად გამოყენება. ეს ბოროტად გამოყენება არ არის მხოლოდ თეორიული, რადგან Google-მა აღნიშნა, რომ მავნე გაფართოებების 42%-მა ბოროტად გამოიყენა ეს API. Apple Safari Content Blocker API შეიქმნა დეკლარაციული ქსელის მოთხოვნის მსგავსად, მსგავსი მიზეზების გამო, რადგან თაღლითი დეველოპერებისთვის ნაკლები ადგილია გამოსაყენებლად. ნერფირებული ვებ მოთხოვნის შემთხვევაში, ქსელის მოთხოვნები კვლავ იქნება დაკვირვებადი, მაგრამ მათ დასჭირდებათ ნებართვები შესაბამის ჰოსტებზე. Manifest V3-ით, მასპინძლის ნებართვები ასევე მნიშვნელოვნად იცვლება და მათი ინსტალაციის დროს აბსოლუტური მინიჭება აღარ არის შესაძლებელი.
Google-მა ასევე გამოიყენა შესრულების ზედნადები, როგორც გადართვის მოტივატორი. ქსელის მოთხოვნების შეფასება ხდება გაფართოების JavaScript თემაში, რაც შეიძლება ძვირი დაჯდეს შესრულებაზე. როგორც უარყოფა, uBlock Origin-ის დეველოპერი აღნიშნავს, რომ მისი გაფართოება არ ითვალისწინებს რაიმე მნიშვნელოვან ჯარიმას მაშინაც კი, როცა 140,000-მდე სტატიკური ფილტრი აქვს გასატარებლად. გაწეული ხარჯები ადვილად ანაზღაურდება იმ რესურსებით, რომლებიც არ არის ჩამოტვირთული დისტანციური სერვერებიდან და, შესაბამისად, არ მუშავდება ბრაუზერის მიერ.
მიუხედავად იმისა, რომ Google არ იყენებს ამ მსჯელობას, Web Request-ის წინააღმდეგ ერთი არგუმენტი ასევე შეიძლება იყოს ეფექტურობისთვის რეკლამის დაბლოკვით. ვებ მოთხოვნის შემთხვევაში, თუ გაფართოება დროულად არ პასუხობს (დაყოვნების ან ავარიის გამო), ქსელის დამუშავების მოთხოვნა აშკარად დაშვებულია, რაც რეკლამებს საშუალებას აძლევს გადაიჩეხოს რეკლამის ბლოკერით. დეკლარაციული წმინდა მოთხოვნა, მეორე მხრივ, არ განიცდის ამ ნაკლოვანებას. ამის ნაცვლად, რეკლამები გაივლის, თუ ისინი არ მოხვდებიან სტატიკური წესების ფარგლებში და ეს უფრო ხშირად მოხდება, ვიდრე არა.
დასკვნა
ზემოთ მოყვანილი ახსნა-განმარტებიდან ირკვევა, რომ დეკლარაციული წმინდა მოთხოვნა არ არის 1:1 ფუნქციონალური კლონი დაბლოკვისთვის Web Request API-ის შესაძლებლობები და გაფართოების დეველოპერები დაზარალდებიან, როდესაც მათი შრომისმოყვარეობა შეფერხდება ასეთი ცვლილებები. მაგრამ Google-ის მსჯელობას ასევე აქვს წონა - Web Request ძალიან ძლიერია და მისი უფლებამოსილება უნდა იყოს შემცირდა მომხმარებელთა საზოგადოების უფრო დიდი ინტერესებიდან გამომდინარე (რომელიც მოიცავს საშუალო მომხმარებლებს და ენთუზიასტები).
Declarative Net Request-ისკენ სვლა ასევე შეიძლება ყოფილიყო პოზიტიური PR ნაბიჯი - ბოლოს და ბოლოს, Google ამატებს ჩაშენებულ კონტენტის ბლოკერის API-ს Chrome-ში! მაგრამ ვინაიდან ახალ API-ს გააჩნია თავისი მძიმე შეზღუდვები, საზოგადოება სამართლიანად ხედავს ამას, როგორც მათი ფრთების ამოკვეთას. იდეალურ სამყაროში, Google-ს უნდა შეესწავლა რეკლამის ბლოკატორების მუშაობა, როგორიცაა uBlock Origin, სანამ ახალ API-ს გამოაქვეყნებდა. როგორც ახლა დგას, ახალ API-ს შეუძლია გამოიყენოს შემდგომი რელაქსაციები თავისი წესების ლიმიტებზე, რათა მოერგოს სცენარებს, სადაც მომხმარებლებს სურთ გამოიყენონ ორი ფილტრით მძიმე გაფართოება.
Მიხედვით რეესტრი, Manifest V3 ცვლილებებით პირველი ნაგებობები ხელმისაწვდომი იქნება 2019 წლის ივლისიდან. ჩვენ ვიმედოვნებთ, რომ Google დაეთანხმება გაფართოების დეველოპერების საზოგადოებისგან მიღებულ გამოხმაურებას ამ ნაგებობებით.
განსაკუთრებული მადლობა XDA-ს მთავარ რედაქტორს მიშაალ რაჰმანს წვლილისა და დახმარებისთვის!
რედაქტირება: სტატიამ არასწორად გაათანაბრა Adblock Plus-ის მუშაობა დეკლარაციული Net Request API-სთან. მუხლი შესაბამისად შეიცვალა. Adblock Plus ასევე გავლენას მოახდენს Web Request API-ის დაბლოკვის შესაძლებლობების მოხსნაზე.