Profobuf(2022): Mendekode dan menghapus iklan untuk memblokir iklan YouTube di Apple TV

 (ericdraken.com)
1 poin oleh GN⁺ 2025-03-19 | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah PoC yang menempatkan proxy MITM berbasis pfSense di antara Apple TV dan internet untuk mendekripsi HTTPS, lalu memodifikasi respons Protobuf yang dikirim YouTube agar slot iklan tidak terdaftar di perangkat Apple
  • Pemblokir DNS yang ada dan routing VPN terbentur keterbatasan seperti DNS TTL, ketidakcocokan IP, error 403, dan kebocoran ASN, karena iklan YouTube dan video utama memakai domain serta infrastruktur yang sama
  • Eksperimen Squid dihentikan karena masalah performa dan konfigurasi, lalu beralih ke pendekatan yang mendekripsi trafik TLS dengan mitmproxy/mitmdump di jail FreeBSD dan langsung memperbaiki respons JSON serta Protobuf
  • YouTube web memungkinkan penghapusan adPlacements, playerAdParams, URL pagead, dan lainnya dari JSON, tetapi aplikasi YouTube iOS menyertakan slot iklan dan informasi pelacakan dalam respons application/x-protobuf, sehingga perlu menangani struktur Protobuf
  • Metode akhir adalah pemindaian linear dan modifikasi 1 byte: mencari field tag secara mundur di sekitar string /pagead/, lalu mengubah tag seperti 50195462 menjadi target_field_tag - 1; ini menghasilkan performa yang cocok untuk pemrosesan real-time tanpa decoding penuh

Tujuan dan desain jaringan awal

  • Tujuannya adalah membuat router berbasis FreeBSD dan pfSense untuk memblokir iklan YouTube pre-roll, mid-roll, dan end-roll di Apple TV serta iPhone pada seluruh jaringan
  • Dengan menempatkan proxy man-in-the-middle di antara Apple TV dan internet eksternal, trafik HTTPS dapat didekripsi dan data Protocol Buffer yang digunakan Google untuk mengisi iklan YouTube dapat dibaca
  • Setelah menerapkan pemblokiran iklan YouTube selama beberapa bulan, penulis mulai berlangganan YouTube Premium, sambil menyatakan bahwa “bisa dilakukan” dan “harus dilakukan” adalah dua hal berbeda
  • Alasan memblokir iklan dan pelacakan mencakup pelacakan privasi, pemborosan bandwidth, clickbait, dan cryptojacking
    • Penulis memperkirakan 25–40% trafik jaringan bisa berupa iklan, skrip pelacakan, fingerprint.js, googletagmanager.js, dan loader analitik real-time seperti Hotjar
    • JavaScript crypto-mining seperti CoinHive.js dijelaskan dapat membuat komputer terlalu panas atau disalahgunakan untuk menghasilkan uang receh

Hardware pfSense dan pengaturan dasar

  • Untuk melindungi seluruh jaringan SMB, VM, image Docker, atau Raspberry Pi dianggap kurang bertenaga, sehingga diperlukan hardware khusus yang hanya menangani routing paket, dekripsi, dan pemantauan
  • Hardware router yang digunakan adalah mini PC dengan set instruksi AES-NI, RAM DDR4, SSD mSATA, dan USB drive untuk flashing pfSense
    • Contoh konfigurasi: mini PC J4125, RAM DDR4 32 GiB, SSD mSATA 128 GiB
    • Penyimpanan 128 GB dianggap cukup untuk log, pengurangan keausan SSD, packet capture, serta edge cache NPM dan Docker
  • Image instalasi pfSense berukuran sekitar 360 MB dan dapat di-flash ke USB drive dengan Etcher AppImage
  • Setelah pengaturan pertama, AES-NI ditampilkan sebagai “Yes (inactive)”, sehingga diaktifkan manual lewat System › Advanced › Miscellaneous
  • Untuk memanfaatkan RAM 32 GiB, RAM disk dialokasikan cukup besar untuk /var dan /tmp, sementara SSD 128 GiB diharapkan mendapat manfaat dari wear-leveling dan backup RAM-disk dikonfigurasi berjalan setiap jam
  • Di Dashboard, widget S.M.A.R.T. ditambahkan agar anomali SSD dapat terdeteksi

Pemblokiran DNS, pemisahan jaringan, dan pfBlockerNG

  • Sebelumnya, Pi-hole di Raspberry Pi digunakan sebagai pemblokir iklan tingkat DNS, dan di pfSense dipasang pfBlockerNG-devel untuk mencoba pemblokiran iklan, konten berbahaya, serta geo-blocking
  • Jika layanan pfb_dnsbl tidak berjalan atau tab status menampilkan [ Missing CRON task ], disarankan mencoba menghapus file kosong /var/run/booting
  • Dengan memanfaatkan 3 port Gigabit pada mini PC, dibuat jaringan fisik, bukan VLAN, dan perangkat “phoning-home” seperti Alexa dan Apple TV dipisahkan dari jaringan utama
    • Perangkat untrusted ditempatkan di jaringan privat 172.31.1.0/24
    • LAN trusted dipertahankan di 192.168/16
    • LAN hardware untuk IoT melewati adblocker, dan kueri DNS hard-coded seperti 1.1.1.1 serta 9.9.9.9 dicegat agar YouTube tidak dapat melewati pemblokir DNS
  • Aturan NAT dikonfigurasi agar semua klien di belakang pfSense memakai server Unbound DNS lokal
    • Pemblokiran DNS over TLS dianggap perlu dilakukan terlebih dahulu agar intersepsi kueri DNS dimungkinkan
    • iPhone dapat menampilkan Privacy Warning terkait pemblokiran trafik DNS terenkripsi, tetapi permintaan DNS upstream disebut tetap dienkripsi ke Cloudflare
    • NAT reflection harus dinonaktifkan agar internet eksternal tidak dapat mengakses server DNS
  • Alias firewall Non_WAN dibuat untuk mengalihkan kueri DNS lokal port 53 pada antarmuka selain WAN ke localhost
  • Karena YouTube mengirimkan iklan dan video utama dari domain yang sama, sulit memfilter hanya iklan dengan pemblokir nama domain seperti pfBlockerNG atau Pi-hole

Eksperimen bypass VPN dan titik kegagalan

  • Selain memblokir iklan, dilakukan juga eksperimen untuk mengecoh algoritme iklan YouTube agar pengguna tampak kurang menarik bagi pengiklan
    • Trafik pelacakan lokasi YouTube coba dirutekan lewat VPN ke wilayah dengan jumlah penonton lebih sedikit menggunakan router pfSense
    • Targetnya adalah membuat akun YouTube dikenali sebagai “pria 70 tahun, tinggal di Italia”
  • Di pfSense, WireGuard digunakan alih-alih OpenVPN untuk eksperimen dasar yang mengirim seluruh trafik Apple TV lewat VPN
    • Paket WireGuard FreeBSD dipasang, lalu tunnel ditambahkan dan diaktifkan
    • Untuk konfigurasi NordLynx, private key diperiksa di VM Linux dengan sudo wg showconf nordlynx, lalu dipindahkan ke pfSense
  • Hasil pengujian menunjukkan Google di laptop tampil dalam bahasa Italia, dan YouTube di Apple TV juga berubah menjadi bahasa Italia
    • Iklan masih muncul sebagian, tetapi disebut lebih sedikit daripada sebelumnya
    • Netflix dan Amazon Prime mengalami masalah; file CSS atau font tampaknya diblokir, atau thumbnail tidak dimuat
    • Penulis memperingatkan agar tidak mengirim seluruh trafik Apple TV lewat VPN, dan menilai Netflix serta Prime cukup baik mendeteksi provider VPN dan geofencing
  • Selanjutnya, untuk memasukkan hanya trafik YouTube dari Apple TV ke VPN, dibuat firewall policy rule yang menargetkan www.youtube.com, youtube.com, googlevideo.com, accounts.google.com, googleapis.com, gstatic.com, dan lainnya
    • Hasilnya, YouTube melihat pengguna berada di Milan, sementara Netflix dan Prime Video melihat pengguna berada di Kanada
    • Iklan berkurang hingga tingkat “jarang sekali”
  • Sehari kemudian muncul DNS race condition
    • Alias hostname pfSense secara default di-resolve setiap 300 detik
    • DNS TTL YouTube bisa 1.440 detik, yakni 24 menit
    • Jika IP yang di-resolve Alias Daemon berbeda dari IP yang diterima klien sebenarnya, policy bisa gagal men-tunnel trafik YouTube
  • Beberapa video YouTube tidak dapat diputar dengan 403 Forbidden
    • YouTube disebut menyematkan IP pengguna ke setiap permintaan googlevideo.com
    • Jika domain turunan seperti r5---sn-hpa7kn76.googlevideo.com tidak ditunnel, permintaan keluar dari IP yang salah dan menimbulkan masalah
    • Yang dibutuhkan adalah tunneling wildcard *.googlevideo.com, tetapi NAT dan firewall rule bekerja dengan IP, bukan hostname wildcard

PoC pelacakan IP berbasis kueri DNS

  • Untuk merutekan *.googlevideo.com melalui VPN, dipikirkan metode pembajakan kueri DNS Google Video
    • Caranya adalah melacak log kueri DNS secara berkala dan menambahkan kueri *.googlevideo.com ke daftar alias
    • Jika tiap video menggunakan domain yang unik dan berubah-ubah, metode ini dianggap tidak akan bekerja kecuali dilakukan refresh untuk setiap video
  • Target baru adalah memantau kueri DNS dengan Python 3 dan pfSense REST API untuk menangkap IP, menahan respons sebentar, lalu menambahkan IP ke aturan VPN tunneling dan melepas DNS reply
  • Setelah memasang pfSense REST API, alias VPN_domains dilihat dengan mengirim request GET ke https://pfsense/api/v1/firewall/alias
  • Modul Python untuk Unbound DNS Resolver ditelusuri dan berhasil digunakan untuk mencatat pesan kueri DNS
    • Versi Python saat itu adalah 3.8
    • Contoh modul Python Unbound berbasis Python 2.4, sehingga diperkirakan mungkin perlu 2to3 atau pemformatan
  • Skrip PoC mengekstrak IP record A/AAAA dari respons DNS dan menambahkannya ke alias pfSense
    • Record A diproses dengan ipaddress.IPv4Address(d.rr_data[j][2:]).exploded
    • Record AAAA diproses dengan ipaddress.IPv6Address(d.rr_data[j][2:]).exploded
    • TTL alias diatur 1 jam, capacity diatur 500
  • Keesokan harinya Unbound DNS Resolver mengalami segfault, dan setiap kali menambahkan IP aturan pfSense harus di-reload sehingga pfSense menjadi sangat lambat

Beralih dari Squid ke mitmproxy

  • Target baru berubah menjadi meneliti dan memasang proxy keluarga Squid, membuat sertifikat CA palsu yang tepercaya, lalu mendekripsi traffic TLS
  • Dalam eksperimen Squid, diuji apakah proxy squid3 yang disediakan sebagai package pfSense memenuhi kebutuhan
    • Folder khusus /squid_cache dibuat dan ukuran cache diatur 8GiB
    • Transparent HTTPS support diharapkan tersedia
  • Setelah mengonfigurasi Squid dan SquidGuard selama sehari, akhirnya menyerah
    • Kecepatannya sangat lambat
    • Pengaturan ACL merepotkan
    • Ada issue terkait https://http/*
    • Pembaruan daftar filter URL SquidGuard memakan waktu sangat lama
    • UI Squid kurang memadai
  • Setelah itu diputuskan memakai mitmproxy yang ditulis dengan Python
    • mitmproxy dipilih daripada SSLSplit karena ekstensibilitas hook Python dan UI-nya
    • Versi FreeBSD pada pfSense adalah 12.2-Stable, build 64-bit
  • Karena jail dinonaktifkan di lingkungan default pfSense, ezjail dipasang manual dan jail untuk mitmproxy dibuat
    • Jail dibuat dengan ezjail-admin create mitmproxy 'lo0|127.0.1.1'
    • Untuk transparent proxy mode, allow.raw_sockets=1 diatur
    • Jika raw socket diblokir, bisa muncul error seperti Transparent mode failure atau Cannot open connection, no hostname given.
  • Menjalankan binary tarball Linux gagal di FreeBSD
    • Muncul ELF interpreter /lib64/ld-linux-x86-64.so.2 not found
    • libdl.so.2, libz.so.1, libpthread.so.0, dan libc.so.6 juga tidak ditemukan
  • Di dalam jail, pkg install mitmproxy dijalankan; instalasinya membutuhkan 50 package, ruang tambahan 206MiB, dan unduhan 33MiB
  • Agar MITMProxy dapat diakses dari LAN, virtual IP 127.0.1.1 ditempelkan ke localhost, lalu dengan aturan NAT [Private IPs]:8080 diteruskan sementara ke 127.0.1.1:8080
  • File CA PEM yang dibuat otomatis oleh MITMProxy adalah ~/.mitmproxy/mitmproxy-ca-cert.pem, dan CA cert ini dipasang ke Trusted Root Store pada perangkat uji
  • mitmproxy memakai banyak CPU meski idle, dan pembuatan sertifikat TLS real-time per request serta logging berlebihan dianggap sangat memperlambat kinerja
    • mitmdump dianggap memiliki beban CPU lebih rendah karena menghilangkan UI dan logging berlebihan

Menghapus iklan JSON YouTube web

  • Certificate Pinning adalah teknik ketika server atau client sudah mengetahui fingerprint sertifikat yang diharapkan, sehingga pemalsuan sertifikat MITMProxy tidak berhasil
  • Host yang bermasalah dapat dibuat melewati proxy dengan opsi --ignore-hosts
    • Sebagai contoh, apple.com:443 dan icloud.com:443 di-ignore
  • Saat mengakses YouTube, page ads terlihat di MITMProxy bersama header yang tidak terenkripsi, dan kemungkinan pemblokiran regex sederhana ditinjau
  • Untuk menerapkan skrip pemblokiran iklan YouTube, --scripts "youtube.py" ditambahkan ke mitmdump
  • Filter smoke-test memblokir request iklan berdasarkan substring URL
    • youtube.com: /pagead/, /log_event?, /stats/ads, /stats/qoe?, /ptracking?, /generate_204, el=adunit, adformat=, /activeview?
    • google.com, google.ca: /pagead/
    • ggpht.com: .
  • Request yang hendak diblokir tampak benar-benar diblokir di MITMProxy dan panel Network DevTools, tetapi ads tetap muncul, dan terkadang ads melakukan skip sendiri atau gagal diputar
  • Setelah itu ditemukan cukup banyak URL terkait iklan di dalam payload JSON
  • Setelah menganalisis UI YouTube dan workflow HTTP hingga cookies dan service workers, dikatakan bahwa pre-roll, post-roll, dan mid-video ads semuanya bisa dihapus
  • Pada tahap ini, router sudah bisa menghapus ads dari payload JSON iklan YouTube web

Masalah iOS YouTube dan Protobuf

  • Aplikasi YouTube iOS menampilkan data yang sangat mirip pada versi Protobuf dari API call yang sama seperti versi web
  • Di Protobuf, key berupa angka dan bisa berubah, sehingga cara mencari advertisement section dengan JSONPath tidak bisa digunakan
  • YouTube mengirimkan daftar besar ads yang akan ditonton ke dalam payload, dan ketika daftar itu habis, daftar besar lain akan segera datang
  • Dalam payload Protobuf terlihat string seperti “Telus,” “Samsung TV,” “Boxing Week,” “Buy now”
  • Protokol YouTube iOS berbeda dari traffic web
    • Pada versi web, ad video dan video yang diinginkan sampai batas tertentu bisa dibedakan dengan melihat URL dan query parameter range
    • Protokol iOS tidak memakai query parameter range maupun header Range, dan menggunakan counter seperti &nr=2, &nr=3 pada video chunk
    • Untuk memblokir iklan YouTube di iOS, Protobuf response harus di-reverse-engineer
  • Pada decoded Protobuf message ditemukan item has_unlimited_entitlement: False dan has_premium_lite_entitlement: False, tetapi alih-alih men-toggle-nya, pendekatannya kembali ke heuristics
  • Mendecode Protobuf mentah sekitar 500KiB dengan Python pure implementation sangat lambat
    • Di desktop i7-6700, hasil Python sekitar 2,06–2,11 detik
    • Di router pfSense, hasil Python sekitar 22,8–24,2 detik
    • C++ protoc --decode_raw sekitar 0,017–0,022 detik di desktop, dan sekitar 0,12–0,14 detik di router pfSense

Upaya decoding Protobuf dan ekstraksi skema

  • Karena raw Protobuf decoding tidak didukung di Python, alih-alih memakai C++ libprotobuf.so secara langsung, dipilih cara berkomunikasi dengan binary C++ protoc melalui subprocess.Popen
  • Saat mem-fuzzing respons video iklan, dicoba 200 kosong, 404, 503, response body yang terpotong, menjadikan sebagian video iklan null, dan sebagainya, tetapi aplikasi iOS melambat lalu crash atau berhenti di layar iklan
  • Pemblokiran URL memicu perilaku respons aplikasi, dan chunk respons video juga berisi session metadata
  • blackboxprotobuf untuk Burp Suite memungkinkan decode raw Protobuf wire message, menyuntikkan konten, lalu meng-encode ulang untuk memeriksa perilaku endpoint Protobuf
    • Disarankan memakai versi Burp Suite asli, bukan fork PyPI
    • Sebagian fork memiliki masalah stack overflow atau infinite recursion karena deep recursion
    • Jika memakai C++ bindings, raw Protobuf sekitar 500KiB dapat di-transcode dalam beberapa detik
  • Skema yang dihasilkan tidak sempurna, besar, dan bersarang sangat dalam, serta pretty-print lambat, tetapi cukup untuk menemukan detail iklan
  • Untuk mengekstrak file .proto atau skema sebenarnya dari APK YouTube Android, dicoba PBTK, Apktool, dex2jar, dan Java Decompiler
    • Yang diekstrak PBTK hanya proto file 59-byte
    • Di Java terdapat Protobuf classes dan getter/setter, tetapi true schema files tidak didapatkan sehingga upaya dihentikan

Titik balik akhir: mengubah 1 byte field tag Protobuf

  • Berdasarkan decrypted network traffic dan hasil fuzzing Protobuf, iklan diamati sebagai struktur yang didaftarkan ke slots pada video tertentu
    • Jenis slot mencakup pre-roll, mid-roll, end-roll, full-page, dan ad pods
    • Jika URL iklan diblokir, muncul error semacam “iklan yang tidak ada telah memesan slot” dan UI mengalami panic
  • Jika decode, edit, lalu re-encode dilakukan tanpa schema asli, encoding yang dimodifikasi akan dihasilkan; karena tidak bisa diketahui apakah ZigZag digunakan atau apakah tipe angka seperti int32, int64, sint32/64, varint dipakai, dan object field order juga biasanya nondeterministic, ini dianggap bermasalah
  • Kemungkinan bypass ditemukan dari backward compatibility Protobuf dan perilaku UnknownFieldSet
    • Saat old software membaca message dengan field baru yang ditambahkan, unknown field dapat muncul
    • Jika key field tertentu diubah ke nilai lain, seluruh sub-structure yang berisi informasi iklan dan tracking dapat dibuat menjadi unavailable
  • Sebagai contoh, diajukan ide mengubah field key 49399797 menjadi 49399796 agar sub-structure iklan/tracking tersebut diperlakukan seperti unknown field
  • Field key 49399797 tidak bisa ditemukan dengan pencarian hex sederhana; varint/tag encoding harus dipertimbangkan
    • Wire type-nya 2, yang berarti nested string/message dengan length-delimited
    • Urutan byte tag untuk target field key 49399797 menjadi AA FF B8 BC 01
    • Dengan 395198378 >> 3 untuk menghapus 3 bit wire type, diperoleh field key asli 49399797
  • Dari bytes Protobuf, signature URL iklan klasik seperti /pagead/ dicari untuk menentukan rentang field search, lalu dari posisi itu bergerak mundur untuk menemukan field tag dan field key yang akan diubah
  • Pada contoh log intercept, dalam respons application/x-protobuf 1,87MiB untuk request POST youtubei.googleapis.com:443/youtubei/v1/browse?key=..., key 49399797 ditemukan di posisi 4465, dan key 50195462 di posisi 4477
  • Pada smoke test O(n), data Protobuf 1,8MiB di-scan satu kali tanpa memory tambahan
    • Target ditemukan pada byte ke-30.593 dari 1,8MiB
    • Dengan backtracking sekitar 600 byte, field key yang akan di-denature ditemukan
  • Setelah metode ini berhasil, tidak perlu lagi memblokir URL yang berisi *.googleadservices.com atau /pagead/, dan request tersebut sejak awal tidak lagi terjadi

Struktur skrip add-on MITMProxy

  • Skrip add-on MITMProxy disediakan sebagai proof of concept untuk memblokir iklan YouTube pada Apple device yang terhubung ke jaringan
    • Nama filenya youtube.py
    • Contoh eksekusi: mitmdump --listen-port 8080 --listen-host 127.0.0.1 -s "youtube.py"
    • Prasyarat FreeBSD adalah pkg install protobuf, pkg install py38-pip, pip install jsonpath-ng
  • Skrip tersebut mencakup fairness function yang mengizinkan 5% iklan demi mendukung pembuat konten
    • in_allowed_ads_window() melewati pemblokiran iklan jika waktu saat ini berada di antara menit ke-0 hingga ke-2 setiap jam
  • YouTubeAdBlocker meng-intercept domain terkait YouTube dan memodifikasi response JSON atau Protobuf untuk menghapus informasi iklan
    • Regex host target intercept adalah \.youtube\.com|google\.(com|ca)|googleapis\.com|googleadservices\.com|googlevideo\.com
    • String untuk deteksi iklan Protobuf adalah b"/pagead/"
    • Batas pencarian adalah 80_000 byte
    • Tag field target adalah 50195462
  • Daftar blokir pada tahap request mencakup pagead/, log_event?, stats/ads, stats/qoe?, ptracking?, generate_204, error_204, adformat=, activeview?, _ad_, ai?, sw.js, dan lainnya pada host YouTube
  • Replacement JSON untuk YouTube web menghapus atau menonaktifkan field terkait iklan
    • yt_ad diubah menjadi "0"
    • adPlacements diubah menjadi []
    • adPlacementRenderer, adPlacementConfig, playerAdParams, gutParams diubah menjadi {}
    • adVideoId diubah menjadi ""
    • showCompanion, showInstream, useGut diubah menjadi False
  • Hook load() menonaktifkan HTTP/2 dan menetapkan anticomp=True, mode="transparent"
  • Hook running() memperbarui allow_hosts agar intercept hanya diterapkan pada domain terkait YouTube
  • Hook response() mencari /pagead/ di dalam 80.000 byte pertama body response jika content-type mengandung protobuf
    • Jika ditemukan, ia membuat byte tag target dengan TagBytes(self.target_field_tag, WIRETYPE_LENGTH_DELIMITED)
    • Ia membuat byte tag untuk target_field_tag - 1 sebagai byte baru
    • Ia melakukan reverse search ke arah sebelum posisi /pagead/ untuk menemukan tag target
    • Byte di posisi tersebut diganti dengan byte yang sesuai dengan target_field_tag - 1
    • Konten Protobuf yang telah dimodifikasi dimasukkan kembali dengan flow.response.set_content(bytes(body))
  • Komentar kode menyatakan bahwa PoC ini sudah memblokir 90% iklan, dan menambahkan bahwa ada field key lain di bagian lain serta mungkin ada beberapa section iklan yang perlu dinonaktifkan

Performa, keterbatasan, dan pengguna target

  • Teknik akhir memanfaatkan kemampuan Protobuf yang mengizinkan unknown field agar perubahan schema tetap backward-compatible, serta sensitivitas single-byte edit pada format compact
  • Dengan mengubah 1 byte di critical spot sehingga section yang tersarang dalam tampak seperti milik future schema version, Protobuf dapat mengabaikannya dan informasi iklan bisa dihapus
  • Google mengembalikan response Protobuf besar yang mencakup hingga layout aplikasi iOS, dan contoh payload-nya berukuran 1,8 MiB
  • Untuk mem-parse seluruh payload dibutuhkan native code seperti C++/Swift, sementara decoding dengan Python disebut lebih lambat beberapa digit dan menyebabkan connection timeout
  • JSON berbasis web harus mem-parse, mengedit, dan melakukan re-serialize seluruh payload, tetapi teknik Protobuf hanya melakukan linear scan dan backtrack cepat, sehingga diproses dalam satuan mikrodetik, cocok untuk real-time adblocking, dan tidak memerlukan blocklist
  • Semua URL *.googleadservices.com dan /pagead/* pada Apple device berasal dari payload Protobuf; jika ad data hilang dari payload, request tersebut juga otomatis hilang
  • Aplikasi YouTube tidak mencoba fetch URL iklan, sehingga terasa lebih cepat, dan karena iklan tidak didaftarkan ke video slot, konten langsung diputar
  • Metode ini disajikan sebagai teknik yang sangat terspesialisasi untuk memblokir iklan YouTube di Apple device atau traffic tracker Instagram, WhatsApp, dan Facebook
  • Kebutuhan CPU untuk mendekripsi/mengenkripsi ulang traffic HTTPS disebut jauh melampaui kemampuan Raspberry Pi
  • Karena ditujukan bagi pemilik Apple device yang tidak ingin meng-compromise OS, basis penggunanya dianggap lebih sempit

YouTube Premium dan eksperimen biaya iklan

  • Penulis menilai belum jelas apakah harga YouTube Premium sebesar CAD $9.99/mo atau CAD $11.99/mo, sekitar CAD $13.43/mo termasuk pajak, masuk akal
  • Ia melakukan eksperimen paparan iklan dengan menonton YouTube secara sporadis selama satu hari menggunakan laptop bersih dan private browsing
    • Dalam riwayat tontonan, video yang “ditonton” hanya 10
    • Saat menonton sebagian dari 10 video itu, ia terpapar 8 iklan
    • Hanya 2 iklan yang bisa dilewati, dan keduanya dilewati
  • Jika CPV kasar diasumsikan USD $0.15, 8 iklan per hari berarti biaya pengiklan sebesar 8 x $0.15 = $1.20, dan jika diekstrapolasi ke sebulan menjadi sekitar USD $36/mo
  • Ia juga menyajikan perhitungan berdasarkan data Statista dengan membagi belanja iklan AS dengan total jumlah view
    • Pada 2019, pengiklan AS membelanjakan $15.1 billion di YouTube
    • Penduduk AS disebut menonton 916 billion video
    • Rata-ratanya adalah $15.1B / 916B = USD $0.0165 per view
    • Untuk kasus penulis, ia menghitungnya setara dengan biaya pengiklan sekitar USD $0.13 per hari, atau sekitar USD $3.96 per bulan
  • Selama eksperimen iklan, ia menggunakan hardware mute dan sering mengalihkan pandangan, sehingga menilai belanja iklan yang ditargetkan kepadanya terbuang percuma
  • Meski begitu, ia mengatakan ingin mendukung kreator dan akan mencoba trial Premium 3 bulan sambil terus memantau apa saja yang dilacak Google tentang dirinya
  • Ia khawatir bahwa sejak DMCA claim diterima, seluruh pendapatan iklan bisa mengalir ke claimant, bukan kreator, dan menambahkan bahwa tidak mengherankan jika banyak kreator berpindah ke Patreon

Ringkasan akhir

  • Ia menyiapkan router hardware dari awal dan memisahkan LAN menjadi zona trusted/untrusted
  • Ia menyiapkan pemblokiran iklan DNS tradisional
  • Ia menambahkan transparent MITM proxy
  • Pada akhirnya, ia mengatakan berhasil memblokir iklan YouTube dengan performa baik pada perangkat Apple yang terhubung ke jaringan
  • Ia menulis bahwa karena bagian sulitnya sudah selesai, ia akan mempertimbangkan untuk membayar YouTube Premium, tetapi menambahkan bahwa tracker tetap diblokir dengan ketat

Bacaan terkait

1 komentar

 
GN⁺ 2025-03-19
Opini Hacker News

  • Ini tampaknya bukan cacat pada format Protobuf, melainkan penulis mengganti nomor field ke nomor besar yang belum digunakan.
    Caranya adalah mencari signature URL iklan seperti /pagead/ di byte Protobuf untuk menentukan rentang field, lalu bergerak mundur dari sana untuk menemukan tag field target dan key field, kemudian menonaktifkannya. Ini lebih dekat ke perilaku yang memang dimaksudkan daripada sebuah cacat.
    Jika sudah mau bersusah payah mencari tag, membaca panjang varint tepat di sebelahnya dan melewati byte terkait juga bukan pekerjaan tambahan yang besar. Memang mungkin perlu menyalin buffer atau menggeser byte, tetapi skrip PoC juga harus melakukan penyalinan karena bytes yang dikembalikan API mitmproxy bersifat immutable.

    • Di level protokol, ini bekerja seperti yang diharapkan, tetapi celahnya tampak ada pada cara Google tidak mengeluarkan error ketika ada field tak dikenal di struktur data iklan, melainkan memprosesnya seolah-olah tidak ada iklan.
      Google tentu akan merilis aplikasi baru terlebih dahulu sebelum mengubah protokol sampai iklan sama sekali tidak muncul di versi aplikasi lama, jadi metode pemblokiran ini bisa langsung dicegah hanya dengan certificate pinning dasar atau decoding yang kurang toleran saat ekstraksi informasi iklan gagal. Jika saya di tim YouTube, bagian seperti ini mungkin akan dianggap sebagai cacat.
    • Objek bytes memang immutable, tetapi objek bytearray tidak immutable.

  • Proxy C++/Go kecil pun bisa melakukan hal yang sama dengan overhead jauh lebih rendah. Untuk pekerjaan yang terdefinisi sejelas ini, pendekatan itu lebih stabil dan lebih sedikit repot daripada bergulat dengan mitmproxy.
    Jika semua traffic dikirim melalui proxy, performa akan turun meski memakai intersepsi SNI. pfSense juga sama; server Linux sederhana dengan aturan iptables sederhana bisa menanganinya tanpa harus melawan lapisan abstraksi pfSense.
    Cukup tulis field proto hasil reverse engineering yang dibutuhkan ke file .proto, generate kode secara otomatis, lalu ubah flag-nya. Ini lebih murah daripada implementasi Python dan lebih mudah diperbarui meskipun proto berubah. Mengabaikan tag field yang tidak dikenal adalah fitur penting Protobuf, dan memungkinkan perubahan skema yang kompatibel tanpa merusak deployment lama.

    • Mungkin justru bagus jika pengalaman YouTube sengaja dibuat lebih lambat dan perpindahan video juga lebih pelan. Sepertinya itu akan cukup mengurangi sifat adiktif Shorts.
    • Saya akan menantikan posting blog yang membagikan secara rinci cara melakukannya.
    • Akan bagus jika Anda sendiri menulis panduan tentang di mana letak inefisiensinya dan bagaimana meredakannya dengan software yang lebih sederhana.
      Penulis tampaknya sudah menyadari sebagian besar poin dalam komentar, dan tulisannya juga cukup menyeluruh. Ia melakukan benchmark dengan Python dan C++, dan implementasi akhirnya bahkan tidak melakukan decoding Protobuf. Ia juga mencoba beberapa solusi mitm, dan pfSense dipakai bukan sekadar sebagai router keamanan sederhana, melainkan untuk menargetkan hanya traffic Apple TV dengan VLAN dan VPN.
      Komentar ini terasa terlalu murahan dan merendahkan. Artikel aslinya tidak seperti itu, jadi kalau mau berkata demikian, sebaiknya buktikan sendiri untuk komunitas.
    • Saya penasaran apakah ada rekomendasi proxy ringan yang bisa berjalan di macOS dan juga melayani perangkat lain di rumah.

  • Kalau membayar YouTube Premium, apakah itu mendukung kreator? Kalau ya, saya penasaran seberapa besar dibanding dukungan langsung seperti Patreon.

    • Dibanding Patreon mungkin tidak banyak, tetapi juga sulit mengharapkan seseorang berlangganan Patreon semua YouTuber yang mereka tonton.
      Pendapatan dari satu langganan YouTube Premium untuk masing-masing kreator mungkin kecil, tetapi tetap lebih baik daripada menonton video dengan pemblokir iklan aktif.
    • Konon kreator mendapat porsi lebih besar dari tayangan YouTube Premium dibanding dari tayangan iklan biasa, karena jika iklan dilewati tidak ada pendapatan. Namun karena pengguna Premium sedikit, batasannya tetap ada.
    • Informasi terbaru jarang, tetapi saat pertama kali diluncurkan sebagai Youtube Red, biasanya nilainya jauh lebih besar daripada pendapatan iklan per view.
    • Lebih banyak daripada iklan dan lebih sedikit daripada Patreon.
      Dasarnya bukan impresi iklan, melainkan waktu tonton, jadi kreator yang membuat konten format panjang lebih diuntungkan.

  • Akun YouTube pacar saya anehnya tidak menampilkan iklan di perangkat mana pun saat login. Termasuk Apple TV, bukan Premium, dan juga tidak pernah pernah Premium.
    Saya penasaran apakah ada flag internal yang disetel sehingga iklan dimatikan.

    • Kirim username dan email akun lewat DM, nanti saya cek dan perbaiki.
    • Pacar Anda pada dasarnya sepertinya masuk kelompok kontrol untuk iklan. Itu bisa dipakai untuk memahami pengaruh iklan terhadap pengguna dengan membandingkan perilakunya dengan orang-orang yang melihat iklan.
    • Bisa juga ia masuk holdback experiment. Untuk melihat dampak fitur seperti penayangan iklan terhadap metrik, sebagian pengguna sering ditempatkan di kelompok holdback, dan saat bekerja di Google saya juga pernah menjalankan eksperimen seperti itu.
    • Dulu kalau punya langganan Google Music, iklan YouTube dimatikan. Bahkan setelah layanannya dihentikan atau langganan dibatalkan, iklan YouTube tidak muncul lagi selama lebih dari 6 bulan.
      Baru saat itulah saya merasa mengerti mengapa orang-orang mengeluh.
    • Saya mengalami hal yang sama di Twitch.
      Meski tidak memakai pemblokir iklan, begitu login, iklan tidak muncul di mana pun, baik di situs web maupun aplikasi mobile. Saya juga tidak punya Twitch Turbo dan sudah tidak punya Amazon Prime. Manfaat Turbo lain juga tidak ada, jadi akun saya tidak sepenuhnya ditandai sebagai Turbo.
      Entah apakah profil akun saya tanpa sengaja rusak karena dulu saya mengutak-atik banyak hal saat bug bounty, tetapi jika mereka membiarkan manfaat ini tetap ada, saya bisa memberikan informasi lebih rinci.
      Yang aneh, saya ingat dulu ketika di rumah sakit, dalam kondisi dibius obat dan kesakitan, saya hanya ingin menonton TV, tetapi iklan Twitch sangat parah sampai hampir membuat saya breakdown. Lalu 1–2 tahun kemudian, tiba-tiba saya sadar bahwa saya tidak melihat iklan selama bertahun-tahun.
      Mungkin ada A/B test tanpa iklan yang sudah lama terlupakan dan dibiarkan karena tidak layak dibereskan. Berkat itu saya mendapat keuntungan selama bertahun-tahun dan menonton Twitch lebih banyak daripada platform lain mana pun. Twitch Turbo di Inggris £12 per bulan, sekitar $15,50, jadi termasuk mahal secara global, dan dibanding $12/€12 di AS dan Eropa, harganya terasa cukup merugikan.

  • Cukup mengejutkan bahwa menempatkan proxy man-in-the-middle antara Apple TV dan internet eksternal bisa mendekripsi trafik HTTPS
    Biasanya saya pikir ini seharusnya tidak berfungsi, lalu kemudian saya kembali terkejut setelah tahu bahwa CA bisa ditambahkan ke certificate store Apple TV. Ini tulisan yang sangat rinci dan menelusuri seluruh stack

    • Kalau menebak alasan Apple mendukung penambahan sertifikat, kemungkinan besar untuk menyesuaikan kebutuhan TI dan manajemen perangkat di lingkungan perusahaan atau pendidikan yang memakai Apple TV sebagai kotak AirPlay
      Misalnya di universitas, agar perangkat bisa terhubung ke Wi-Fi, alamat MAC harus dimasukkan ke allowlist atau sertifikat harus dipasang
    • Google bisa dengan mudah memblokir cara ini hanya dengan memeriksa CA yang menandatangani sertifikat SSL di aplikasi YouTube
      Namun kalau begitu, YouTube bisa rusak di banyak lingkungan perusahaan, jadi belum tentu mereka benar-benar akan melakukannya. Tetap saja, sayangnya ini sangat mudah diblokir
    • Saya tidak menyangka CA bisa ditambahkan ke Apple TV. Mungkin saya tidak tahu karena belum pernah mengakses resource yang tidak memiliki rantai sertifikat valid lewat Apple TV
    • Sebagian besar perangkat mengizinkan penambahan CA, tetapi sekarang hampir semua aplikasi memakai certificate pinning sehingga mengabaikan certificate store sistem. Sangat mengejutkan bahwa YouTube tidak melakukannya
    • Ironisnya, Android TV setidaknya pada versi 7.x tidak mengizinkan ini. Saya mengetahuinya dengan susah payah saat mencoba melewati sertifikat Let's Encrypt yang tidak dipercaya

  • Saya sudah beberapa kali mencoba mengimplementasikannya di Apple TV, tetapi sama sekali tidak berhasil. Sepertinya YouTube sekarang sudah menambahkan certificate pinning ke aplikasinya, atau semacam itu. Penasaran apakah ada orang yang belakangan ini berhasil membuatnya berjalan

  • Saya suka semua upaya untuk memblokir di seluruh jaringan layanan online buruk yang terpaksa kita pakai
    Pemblokiran iklan juga bagus, tetapi saya berharap ada cara yang lebih mudah dan lebih banyak untuk memblokir scroll tak terbatas yang agresif seperti YouTube Shorts atau Instagram Reels di seluruh jaringan
    Di Instagram saya hanya ingin melihat postingan dan story dari orang yang saya ikuti, bukan direkomendasikan video bodoh yang dirancang untuk mencuri perhatian. Mungkin ini menunjukkan kurangnya kemauan, tetapi saya sering akhirnya menonton beberapa dan kehilangan 15 menit hidup saya

    • Tidak ada yang memaksa memakainya. Bisa tidak digunakan, atau bisa membayar
      Pengguna internet pada umumnya memilih tidak ingin membayar, jadi ada pihak lain yang menanggung biayanya. Secara keseluruhan, pengguna internet tidak memberi imbalan kepada pihak yang tidak menampilkan iklan. Mereka menginginkan konten, tetapi umumnya menginginkannya gratis
    • Hapus aplikasinya, pakai halaman web, dan gunakan browser yang mengizinkan user script
      Saya menemukan script yang mengubah halaman Instagram menjadi seperti tag gambar biasa sehingga hanya foto yang bisa dilihat: https://greasyfork.org/en/scripts/5014-un-instagram
    • Menurut saya taktik seperti ini mengeksploitasi rasa ingin tahu alami kita dan estetika di sekitarnya
      Jadi ini tampaknya bukan sekadar kurangnya kemauan, melainkan lebih mirip ketidakpekaan yang telah kita bangun, dan itu cukup buruk. Upaya dan kreativitas untuk mengembalikan keadaan agar kitalah yang memakai platform, bukan platform yang membuat kita memakainya, patut dihargai
    • Sebagai orang tua, saya sangat bisa merasakannya. Sulit melihat anak-anak terseret ke dalam algoritma
      Saya rutin membicarakannya dengan anak-anak, dan mereka juga setuju bahwa itu berbahaya, tetapi terlalu sulit untuk dilawan. Saya sendiri pun kadang terseret doomscrolling
      Di tempat yang memungkinkan, saya sudah mengatur pemfilteran iklan dengan Pi-hole, tetapi saya tidak ingin memblokir YouTube sepenuhnya. Meski begitu, demi melindungi keluarga, sepertinya ke depan saya akan mempertimbangkannya secara serius
    • Aplikasi ini sangat cocok untuk menghentikan infinite scroll di Instagram: https://www.distractionfreeapps.com/index.html

  • Rekayasanya bagus, tetapi agak menyedihkan bahwa kita harus sampai sejauh ini agar bisa memakai hardware atau software sendiri seolah-olah kita memilikinya, bahkan hanya sampai tingkat tertentu

    • Dalam kasus ini, perangkatnya memang dimiliki. Namun tampaknya tidak ada dasar untuk mengklaim memiliki YouTube atau kontennya juga
    • Ini hal yang sudah hampir 10 tahun bisa dilakukan dengan memasang NewPipe APK di Android box seharga 30 dolar

  • Memangnya ada iklan di YouTube? Browser saya memblokirnya dengan sangat baik sampai saya tidak tahu
    Masalah sebenarnya adalah pengalaman Apple TV jauh lebih buruk daripada pengalaman browser web biasa. Apple mengunci hardware terlalu ketat, sehingga strukturnya lebih menguntungkan pendapatan iklan YouTube daripada konsumen akhir yang sudah membayar untuk membelinya

    • Di Linux, Windows, dan Android, saya sama sekali tidak melihat iklan. Saat sesekali mencoba menonton YouTube di iPad, saya terkejut betapa sering dan menyebalkannya iklan
      Hal yang sama terjadi saat menjelajah web dengan iPad di luar jaringan Pi-hole rumah. Saya tidak tahu bagaimana orang bisa menahannya setiap hari
      iPad itu perangkat kerja yang diberikan kantor, jadi saya tidak sering memakainya untuk keperluan pribadi, tetapi setiap kali dipakai saya kembali diingatkan betapa menyebalkannya
      Anehnya, sebelum menerima iPad saya mengira perangkat itu hanya berguna untuk konsumsi konten, tetapi kenyataannya sangat praktis untuk remote access cepat ke resource kerja, sementara untuk browsing web biasa dan streaming media, perangkat itu terasa terjebak di gurun tandus yang dipenuhi iklan

  • Kalau butuh YouTube tanpa iklan, pakai https://yewtu.be atau instance Invidious lain https://docs.invidious.io/instances/
    Ada perlombaan senjata antara YouTube dan Invidious, dan kadang Invidious tidak berfungsi, tetapi timnya selalu menemukan cara baru untuk melewati YouTube dan mengirimkan video tanpa iklan

    • Ada alasan judulnya memuat “on AppleTV”. Klien atau frontend alternatif tidak berjalan di sana
    • Di tempat seperti Roku TV, tidak ada browser, jadi cara ini tidak berlaku