Google ამართლებს რეკლამის ბლოკერების მიერ გამოყენებული webRequest API-ის შეზღუდვას

Chrome ბრაუზერის დეველოპერები შეეცადა ამართლებს webRequest API-ის ბლოკირების რეჟიმის მხარდაჭერის შეწყვეტა, რომელიც საშუალებას გაძლევთ შეცვალოთ მიღებული კონტენტი ფრენის დროს და აქტიურად გამოიყენება დანამატებში რეკლამის დაბლოკვისთვის,
დაცვა მავნე პროგრამებისგან, ფიშინგისგან, მომხმარებლის აქტივობის ჯაშუშობისგან, მშობელთა კონტროლისა და კონფიდენციალურობისგან.

Google-ის მოტივები:

• API ბლოკირების რეჟიმი ვებმოთხოვნა იწვევს რესურსების მაღალ მოხმარებას.
  ამ API-ს გამოყენებისას ბრაუზერი ჯერ აგზავნის დანამატს ყველა მონაცემს, რომელიც შეიცავს ქსელის მოთხოვნას, დანამატი აანალიზებს მას და აბრუნებს შეცვლილ ვერსიას შემდგომი დამუშავებისთვის ბრაუზერში ან გამოსცემს დაბლოკვის ინსტრუქციებს. ამ შემთხვევაში, ძირითადი შეფერხებები წარმოიქმნება არა დანამატის მიერ ტრაფიკის დამუშავების ეტაპზე, არამედ დანამატის შესრულების კოორდინაციის ხარჯების გამო. კერძოდ, ასეთი მანიპულაციები მოითხოვს ცალკე პროცესის დაწყებას, რათა შევსება, ასევე IPC-ის გამოყენებას ამ პროცესთან ურთიერთქმედების მიზნით და მონაცემთა სერიალიზაციის მექანიზმებთან;

• დანამატი მთლიანად აკონტროლებს მთელ ტრაფიკს დაბალ დონეზე, რაც ხსნის უზარმაზარ შესაძლებლობებს ბოროტად გამოყენებისა და კონფიდენციალურობის დარღვევისთვის. Google-ის სტატისტიკის მიხედვით, ყველა აღმოჩენილი მავნე დანამატების 42% იყენებდა webRequest API-ს. აღნიშნულია, რომ ყოველთვიურად, Chrome Web Store-ის კატალოგში იბლოკება საშუალოდ 1800 მავნე დანამატის განთავსების მცდელობები. სამწუხაროდ, განხილვა არ გვაძლევს საშუალებას დავიჭიროთ ყველა მავნე დანამატი გამონაკლისის გარეშე, ამიტომ დაცვის გასაძლიერებლად გადაწყდა დანამატების შეზღუდვა API დონეზე. მთავარი იდეა არის დამატებების მიწოდება არა ყველა ტრაფიკზე, არამედ მხოლოდ იმ მონაცემებზე, რომლებიც აუცილებელია განზრახული ფუნქციონირების განსახორციელებლად. კერძოდ, კონტენტის დასაბლოკად, არ არის აუცილებელი, რომ დანამატს მიეცეს სრული წვდომა მომხმარებლის ყველა კონფიდენციალურ მონაცემზე;
• შემოთავაზებული შემცვლელი დეკლარაციული API დეკლარაციული NetRequest ზრუნავს მაღალი ხარისხის შინაარსის ფილტრაციის ყველა სამუშაოზე და მოითხოვს მხოლოდ დანამატებს ფილტრაციის წესების ჩასატვირთად. დანამატი ვერ შეუშლის ხელს ტრაფიკს და მომხმარებლის პირადი მონაცემები ხელშეუხებელი რჩება;
• Google-მა გაითვალისწინა მრავალი კომენტარი დეკლარაციული NetRequest API-ს ფუნქციონირების ნაკლებობასთან დაკავშირებით და გააფართოვა ფილტრაციის წესების რაოდენობის ლიმიტი თავდაპირველად შემოთავაზებული 30 ათასიდან ერთ გაფართოებაზე გლობალურ მაქსიმუმ 150 ათასამდე, ასევე დაამატა დინამიურად წესების შეცვლა და დამატება, HTTP სათაურების ამოღება და ჩანაცვლება ( Referer, Cookie, Set-Cookie) და მოთხოვნის პარამეტრები;
• საწარმოებისთვის შესაძლებელია webRequest API-ის ფუნქციონირების დაბლოკვის რეჟიმის გამოყენება, რადგან დამატებების გამოყენების პოლიტიკა განისაზღვრება ადმინისტრატორის მიერ, რომელსაც ესმის ინფრასტრუქტურის მახასიათებლები და იცის რისკები. მაგალითად, მითითებული API შეიძლება გამოყენებულ იქნას საწარმოებში თანამშრომლების ტრაფიკის ნაკადების ჩასაწერად და შიდა სისტემებთან ინტეგრირებისთვის;
• Google-ის მიზანია არა შეარყიოს ან აღკვეთოს რეკლამის დაბლოკვის დანამატები, არამედ უზრუნველყოს უფრო უსაფრთხო და ძლიერი რეკლამის ბლოკერების შექმნა;
• WebRequest API-ის ბლოკირების რეჟიმის დატოვების უკმაყოფილება ახალ დეკლარაციულNetRequest-თან ერთად აიხსნება კონფიდენციალურ მონაცემებზე დანამატების წვდომის შეზღუდვის სურვილით. თუ თქვენ დატოვებთ webRequest API-ს ისე, როგორც არის, დანამატების უმეტესობა არ გამოიყენებს უფრო უსაფრთხო დეკლარაციულ NetRequest-ს, რადგან უსაფრთხოებისა და ფუნქციონალურობის არჩევისას, დეველოპერების უმეტესობა ჩვეულებრივ ირჩევს ფუნქციონირებას.

წინააღმდეგობები დეველოპერები დამატებები:

• ჩატარდა დანამატების დეველოპერების მიერ ტესტები აჩვენეთ უმნიშვნელო საერთო გავლენა რეკლამის დაბლოკვის დანამატების შესრულებაზე (ტესტირების დროს შეადარეს სხვადასხვა დანამატების შესრულება, მაგრამ დამატებითი პროცესის ზედნადების გათვალისწინების გარეშე, რომელიც კოორდინაციას უწევს დამმუშავებლების შესრულებას დაბლოკვის რეჟიმში webRequest API);
• პრაქტიკული არ არის API-ის მხარდაჭერის სრულად შეწყვეტა, რომელიც აქტიურად გამოიყენება დანამატებში. მისი ამოღების ნაცვლად, შეგიძლიათ დაამატოთ ცალკე ნებართვა და მკაცრად აკონტროლოთ მისი გამოყენების ადეკვატურობა დანამატებში, რაც გადაარჩენს მრავალი პოპულარული დანამატის ავტორებს პროდუქციის სრულად გადამუშავებისგან და თავიდან აიცილებს ფუნქციონირების შემცირებას;
• ზედნადები ხარჯების შესამცირებლად, თქვენ არ შეგიძლიათ წაშალოთ API, მაგრამ გადააკეთოთ იგი Promise მექანიზმის საფუძველზე, Firefox-ში webRequest-ის განხორციელების მსგავსად;
• შემოთავაზებული ალტერნატივა, დეკლარაციული NetRequest, არ მოიცავს დანამატების დეველოპერების ყველა საჭიროებას რეკლამის დაბლოკვისა და უსაფრთხოების/კონფიდენციალურობის შესახებ, რადგან ის არ უზრუნველყოფს სრულ კონტროლს ქსელის მოთხოვნებზე, არ იძლევა პერსონალური ფილტრაციის ალგორითმების გამოყენებას და არ იძლევა საშუალებას. რთული წესების გამოყენება, რომლებიც ერთმანეთს ემთხვევა პირობებიდან გამომდინარე;
• DeclarativeNetRequest API-ის ამჟამინდელი მდგომარეობით, შეუძლებელია uBlock Origin და uMatrix დანამატების არსებული ფუნქციონირების ხელახლა შექმნა უცვლელი, და ასევე უაზრო ხდის NoScript პორტის შემდგომ განვითარებას Chrome-ისთვის;
• კონფიდენციალურობის შესახებ შეშფოთება შორს არის, რადგან webRequest API-ის მხოლოდ წაკითხვის, არადაბლოკვის რეჟიმი ადგილზეა დარჩენილი და კვლავ საშუალებას აძლევს მავნე დანამატებს გააკონტროლონ მთელი ტრაფიკი, მაგრამ არ იძლევა მასში ჩარევის შესაძლებლობას. fly (შეცვალეთ შინაარსი, განათავსეთ თქვენი რეკლამები, გაუშვით მაინერები და გააანალიზეთ შეყვანის ფორმების შინაარსი, შეგიძლიათ გამოიყენოთ გვერდის ჩატვირთვის დასრულების შემდეგ);
• ბრაუზერის დეველოპერები მამაცი, ოპერისა и ვივალდიChromium-ის ძრავზე აგებული, აპირებენ დატოვონ მხარდაჭერა webRequest-ის დაბლოკვის რეჟიმისთვის მათ პროდუქტებში.

წყარო: opennet.ru