Google terus bersikeras untuk membatasi API yang diperlukan dalam pemblokir iklan

Simeon Vincent, yang bertanggung jawab atas interaksi dengan pengembang ekstensi di tim Chrome (memegang posisi Advokat Pengembang Ekstensi), berkomentar Posisi Google saat ini mengenai manifesto Chrome edisi ketiga, melanggar bekerja banyak add-on untuk memblokir konten yang tidak pantas dan memastikan keamanan. Perusahaan tidak bermaksud untuk membatalkan rencana awalnya untuk berhenti mendukung mode pemblokiran API webRequest, yang memungkinkan Anda mengubah konten yang diterima dengan cepat. Pengecualian hanya akan dibuat untuk Chrome edisi perusahaan (Chrome untuk Perusahaan), yang mana dukungan untuk webRequest API akan dipertahankan seperti sebelumnya.

Untuk pengguna Chrome API biasa Permintaan web akan dibatasi pada mode read-only. API deklaratif telah diusulkan untuk menggantikan API webRequest untuk pemfilteran konten deklaratifNetRequest, yang hanya mencakup sebagian kecil dari kemampuan yang digunakan dalam pemblokir iklan modern. Intinya, alih-alih penangan berpemilik yang memiliki akses penuh ke permintaan jaringan, ditawarkan mesin pemfilteran bawaan universal siap pakai yang memproses aturan pemblokiran sendiri. Misalnya, API deklaratifNetRequest tidak mengizinkan Anda menggunakan algoritme pemfilteran Anda sendiri dan tidak mengizinkan Anda membuat aturan rumit yang tumpang tindih satu sama lain bergantung pada kondisi.

Pengembang add-on pemblokiran iklan telah bersama-sama mempersiapkannya daftar komentar, yang mencantumkan kekurangan dari DeclarativeNetRequest API. Google setuju dengan banyak komentar dan menambahkan deklaratifNetRequest API. Secara khusus, dukungan telah ditambahkan untuk mengubah dan menambahkan aturan secara dinamis, dan dimungkinkan untuk menghapus header HTTP, tetapi hanya yang ada di daftar putih (Referer, Cookie, Set-Cookie). Kami berencana untuk menerapkan dukungan untuk menambah dan mengganti header HTTP (misalnya, untuk substitusi Set-Cookie dan arahan CSP) dan kemampuan untuk menghapus dan mengganti parameter permintaan.

Versi awal manifes versi ketiga, yang menentukan daftar kemampuan dan sumber daya yang disediakan untuk add-on Chrome, rencananya akan digunakan untuk pengujian dalam versi eksperimental Chrome Canary dalam beberapa bulan mendatang.

Pada saat yang sama, motivasi untuk melarang perubahan pada konten yang diterima melalui webRequest API masih belum sepenuhnya jelas. Klaim bahwa mode pemblokiran API webRequest berdampak negatif pada kinerja karena browser menunggu penanganan add-on menyelesaikan pekerjaannya sebelum merender halaman tidak tahan terhadap kritik. Sebelumnya dilakukan tes Kinerja add-on pemblokiran iklan telah menunjukkan bahwa penundaan yang ditimbulkannya dapat diabaikan. Rata-rata, penggunaan pemblokir memperlambat eksekusi permintaan hanya sepersekian milidetik, yang dapat diabaikan dibandingkan dengan latar belakang keseluruhan.

Argumen kedua, terkait dengan keinginan untuk melindungi pengguna dari akses tidak terkendali add-on ke konten, juga tidak terlihat meyakinkan, karena alih-alih menghapus fungsionalitas yang sudah lama ada dan tersebar luas di add-on yang sah, ada kemungkinan untuk menambahkan yang baru. jenis otoritas dan memberi pengguna pilihan akhir untuk menginstal add-on dengan akses penuh ke permintaan jaringan atau tidak. Selain itu, Google telah meninggalkan dukungan untuk menggunakan webRequest API dalam mode baca-saja, yang memungkinkan pemantauan lalu lintas penuh tanpa intervensi tingkat rendah.
Add-on dapat mengubah konten halaman web yang dimuat melalui API lain (misalnya, add-on berbahaya masih dapat menayangkan iklannya, meluncurkan penambang, dan menganalisis konten formulir masukan).

Raymond Hill, penulis sistem uBlock Origin dan uMatrix untuk memblokir konten yang tidak diinginkan, cukup ketat berkomentar tanggapan dari perwakilan Google dan mengisyaratkan hasutan dan permainan di balik layar di mana Google, dengan kedok peluang bagus, mencoba memajukan kepentingan bisnisnya di bidang periklanan Internet, mendapatkan kendali atas mekanisme penyaringannya, dan membenarkan tindakan ini di mata masyarakat umum.

Dia tidak pernah menerima argumen yang meyakinkan tentang perlunya menghentikan API yang tersebar luas dan populer di kalangan pengembang add-on. Menurut Raymond, penurunan kinerja bukanlah suatu argumen, karena halaman dimuat dengan lambat karena kembungnya, dan bukan karena penggunaan mode pemblokiran webRequest pada add-on yang diterapkan dengan benar. Jika Google benar-benar peduli dengan kinerja, mereka akan mendesain ulang webRequest berdasarkan mekanismenya Janji, dengan analogi dengan penerapan permintaan web di Firefox.

Menurut Raymond, strategi Google adalah menentukan keseimbangan optimal antara perluasan basis pengguna Chrome dan kerusakan bisnis yang disebabkan oleh penggunaan pemblokir konten. Pada tahap pertama ekspansi Chrome, Google terpaksa menggunakan pemblokir iklan sebagai salah satu add-on paling populer di kalangan pengguna. Namun setelah Chrome memperoleh dominasi, perusahaan mencoba memberikan keseimbangan dan mendapatkan kendali atas pemblokiran dengan melakukan promosi prakarsa untuk mengintegrasikan fungsi pemblokiran iklan yang tidak pantas ke dalam Chrome. API webRequest menggagalkan tujuan ini karena kendali atas pemblokiran konten saat ini berada di tangan pengembang pemblokir iklan pihak ketiga.

Sumber: opennet.ru

Tambah komentar