Menerobos Perlindungan Fingerprinting Audio Canggih di Safari 17

 (fingerprint.com)
1 poin oleh GN⁺ 2024-03-11 | 1 komentar | Bagikan ke WhatsApp
  • Safari 17 menambahkan noise acak pada setiap sampel Audio API dalam mode privat untuk mengacaukan fingerprint audio, tetapi FingerprintJS meresponsnya dengan algoritme fingerprint baru yang mengurangi efek tersebut
  • Metode lama memakai jumlah dari 500 sampel audio sebagai pengenal, sehingga rentang noise Safari menjadi lebih besar daripada perbedaan antar-browser dan kehilangan stabilitas
  • Metode baru membuat sejumlah besar salinan ber-noise dari sampel audio yang sama, lalu mengurangi fluktuasi nilai dengan (min+max)/2 dan pembulatan angka signifikan
  • Dengan menghubungkan square OscillatorNode, DynamicsCompressorNode, dan BiquadFilterNode, perbedaan antar-browser diperbesar; selisih minimum pada sampel ke-3396 dari browser yang dipilih meningkat hingga 0.0014%
  • Algoritme baru menggantikan fingerprint audio lama mulai FingerprintJS 4.2.0; waktu komputasinya naik 1,5–2 kali, tetapi tetap selesai dalam waktu singkat bahkan di perangkat kelas bawah

Cara Safari 17 Mengacak Fingerprint Audio

  • Fingerprinting audio adalah metode yang merender sinyal audio dengan Audio API dan OfflineAudioContext milik browser, lalu menjumlahkan sampelnya menjadi satu angka pengenal
  • Pengenal ini memiliki stabilitas karena tidak berubah meskipun cookie dihapus atau pengguna beralih ke mode incognito, tetapi keunikannya tidak tinggi karena banyak pengguna dapat berbagi nilai yang sama
  • Perlindungan fingerprint tingkat lanjut di Safari 17 secara default aktif dalam mode privat dan nonaktif dalam mode biasa, serta berlaku di desktop maupun mobile
  • Perlindungan ini juga memengaruhi Screen API dan Canvas API, tetapi di sini hanya Audio API yang dibahas
  • Saat perlindungan aktif, Safari mengalikan setiap sampel audio dengan noise acak masing-masing
    • Sampel yang diberi noise berada di antara sample*(1-magnitude) dan sample*(1+magnitude)
    • Distribusinya adalah distribusi uniform
    • Karena pengembangan Safari terus berjalan, detail implementasinya dapat berubah seiring waktu

Titik Audio API yang Dikenai Noise

  • Safari menerapkan noise pada beberapa antarmuka yang dapat membaca sinyal audio
  • Noise berubah setiap kali diterapkan, sehingga di mode privat Safari 17 fingerprint audio berubah setiap kali dihitung
  • Di Safari 17 pada M1 MacBook Air, fingerprint berfluktuasi antara 124.03516 dan 124.04545, dengan selisih sekitar 0.008%
  • Selisih terkecil di antara fingerprint audio lama antar-browser adalah 0.0000023%, jauh lebih kecil daripada rentang noise Safari
  • Untuk menghilangkan noise, nilai perlu dibulatkan hingga sekitar satu digit desimal, tetapi jika menyisakan kurang dari 6 digit, sebagian browser menjadi sulit dibedakan sehingga keunikan menurun

Tiga Tahap Algoritme Baru

  • Algoritme fingerprint audio baru dari FingerprintJS melalui tiga tahap untuk mengurangi noise yang ditambahkan Safari
    • Mengurangi varians noise
    • Memperbesar jarak antar-angka pengenal browser
    • Menghapus sisa noise dengan pembulatan
  • Fingerprint audio lama adalah jumlah dari 500 sampel audio, sehingga ketika noise berdistribusi uniform ditambahkan ke tiap sampel, noise fingerprint keseluruhan mendekati distribusi normal
  • Rata-rata distribusi normal harus diestimasi dari rata-rata banyak sampel, tetapi rata-rata distribusi uniform dapat diestimasi lebih presisi dari lebih sedikit sampel dengan (min+max)/2 menggunakan min dan max
  • Dalam kode eksperimen, distribusi normal membutuhkan 524,288 sampel pada kondisi presisi yang sama, sedangkan distribusi uniform cukup dengan 4,096 sampel
  • Metode baru beralih dari fingerprint berbasis penjumlahan ke pengumpulan satu sampel audio saja agar dapat menangani noise berdistribusi uniform
  • Karena perubahan ini, fingerprint baru tidak kompatibel dengan fingerprint lama, dan diperlukan pendekatan terpisah untuk bermigrasi tanpa kehilangan pengenal pengunjung

Membuat Salinan Ber-noise dari Sampel Audio yang Sama

  • Cara memanggil getChannelData berkali-kali pada instance AudioBuffer tidak berhasil
    • Noise diterapkan satu kali untuk setiap instance AudioBuffer
    • getChannelData pada instance yang sama mengembalikan sinyal yang sama
  • Menjalankan seluruh proses pembuatan sinyal audio berkali-kali dapat membuat banyak instance AudioBuffer, tetapi terlalu lambat untuk perhitungan fingerprint
    • Untuk 6.000 sampel ber-noise, waktu tercepat di M1 MacBook adalah 7 detik
    • Pada 60.000 sampel, Safari tidak dapat menyelesaikan tugasnya
  • Cara yang lebih baik adalah membuat instance AudioBuffer yang mengulang sinyal audio yang sama
    • Render sinyal audio pertama, tetapi jangan panggil getChannelData
    • Buat OfflineAudioContext kedua yang lebih panjang dan gunakan sinyal asli sebagai AudioBufferSourceNode
    • Ulangi sebagian sinyal asli dengan loop, loopStart, dan loopEnd
    • Setelah pengulangan, Safari menambahkan noise, sehingga diperoleh salinan dari sampel audio yang sama dengan noise berbeda
  • Dengan cara ini, jumlah salinan ber-noise yang dibutuhkan dapat dibuat hanya dengan 2 kali rendering audio
  • Noise tidak hilang sepenuhnya, tetapi variansnya menjadi lebih kecil dibanding sampel audio asli
    • 8,192 salinan: rentang hasil dari 100 kali eksekusi 0.000387%, 2.6ms pada M1 MacBook
    • 65,536 salinan: 0.0000123%, 4.1ms
    • 262,144 salinan: 0%, 7.5ms

Memperbesar Perbedaan Sampel Audio Antar-browser

  • Mengurangi jumlah salinan memang meningkatkan performa, tetapi memperbesar varians hasil; karena itu sinyal dasar diubah untuk memperbesar perbedaan sampel audio antar-browser
  • Setelah bereksperimen dengan berbagai node audio bawaan, rantai pembuatan sinyal yang memperbesar perbedaan sampel antar-browser adalah sebagai berikut
  • Sampel ke-3396 dari sinyal audio memiliki perbedaan antar-browser paling besar; nilai ini ditemukan dengan membandingkan semua sampel dari beberapa browser
  • Dalam sampel browser yang dipilih, selisih terkecil untuk sampel baru ini adalah 0.0014%
    • Lebih besar daripada selisih terkecil fingerprint lama, yaitu 0.0000023%
    • Berkat ini, penghilangan noise dan pembulatan yang lebih kasar dapat diterapkan

Menstabilkan Fingerprint dengan Pembulatan

  • Meski rentang noise pada satu sampel sudah mengecil, nilainya masih berfluktuasi, sehingga pembulatan diperlukan agar dapat dipakai sebagai fingerprint akhir
  • Karena noise diterapkan relatif terhadap nilai sampel audio, bukan sebagai nilai absolut, pembulatan dilakukan berdasarkan angka signifikan, bukan jumlah digit desimal
  • Untuk membedakan browser yang dipilih, 5 angka signifikan sudah cukup, tetapi karena tidak mungkin memeriksa semua browser dan perubahan di masa depan, digunakan jumlah digit yang lebih banyak
  • Jumlah salinan yang dibutuhkan untuk stabilisasi menurut presisi pembulatan di mode privat Safari 17 adalah sebagai berikut
    • 6 angka signifikan: 15,000 salinan, 3ms pada Safari 17 di M1 MacBook dalam kondisi warm
    • 7 angka signifikan dengan digit terakhir dibulatkan ke kelipatan 5: 30,000 salinan, 4ms
    • 7 angka signifikan dengan digit terakhir dibulatkan ke bilangan genap terdekat: 70,000 salinan, 6ms
    • 7 angka signifikan atau lebih: 400,000 salinan, 12ms
  • Pilihan akhir adalah 7 angka signifikan dengan digit terakhir dibuat menjadi 0 atau 5, dan jumlah salinan dinaikkan menjadi 40,000 untuk meningkatkan stabilitas
  • Angka yang dibulatkan seperti ini menjadi fingerprint audio baru yang tidak berubah meskipun perlindungan fingerprint tingkat lanjut Safari 17 aktif
  • Fingerprint baru dinilai memiliki keunikan yang sama dengan fingerprint audio lama

Performa dan Batasan Eksekusi

  • Pada browser warm di halaman kosong, algoritme baru umumnya lebih lambat daripada algoritme lama
    • MacBook Air 2020 Safari 17.3: lama 2ms, baru 4ms
    • MacBook Air 2020 Chrome 120: lama 5ms, baru 8ms
    • iPhone 13 mini Safari 17.3: lama 8ms, baru 12ms
    • Galaxy J7 Prime Chrome 120: lama 33ms, baru 45ms
    • BrowserStack Windows 11 Firefox 121: lama 10ms, baru 18ms
  • Performa algoritme baru memburuk 1,5–2 kali dibanding yang lama, tetapi waktu komputasinya tetap singkat bahkan di perangkat kelas bawah
  • Karena browser mendelegasikan sebagian pekerjaan ke thread OfflineAudioRender, halaman tetap responsif selama sebagian besar perhitungan fingerprint audio
  • Web Audio API tidak dapat digunakan di web workers, sehingga fingerprint audio tidak bisa dihitung di worker
  • Untuk meningkatkan performa, situs dapat memeriksa apakah browser adalah Safari 17 atau lebih baru melalui string user agent, menggunakan algoritme baru hanya di Safari 17 ke atas, dan mempertahankan algoritme lama di browser lain

Perbedaan Tor dan Brave

  • Tor menonaktifkan Web Audio API sepenuhnya, sehingga fingerprinting audio tidak mungkin dilakukan
  • Brave menambahkan noise pada sinyal audio seperti Safari 17, tetapi caranya berbeda
  • Safari mengalikan setiap sampel audio dengan nilai acak terpisah
  • Brave membuat pengali acak yang disebut fudge factor satu kali dan mengalikan semua sampel audio dengan nilai yang sama
    • Nilai ini dipertahankan di dalam halaman
    • Nilai hanya berubah pada sesi reguler baru atau sesi incognito baru
  • Di Brave, sebanyak apa pun salinan sampel audio dibuat, noise yang sama diterapkan ke semua salinan, sehingga metode penghilangan noise matematis untuk Safari tidak bekerja
  • Namun, metode penghilangan noise Brave sebelumnya tetap bekerja, dan metode pembuatan sinyal baru yang memperbesar perbedaan fingerprint antar-browser dapat memperlebar toleransi kesalahan

Penerapan di FingerprintJS

  • Algoritme fingerprint audio baru menggantikan metode lama di FingerprintJS dan pertama kali dirilis pada 4.2.0
  • Kode implementasi lengkap tersedia di repositori GitHub FingerprintJS
  • Fingerprint audio adalah salah satu dari banyak sinyal yang digunakan library open-source ini untuk membuat fingerprint browser
  • FingerprintJS tidak serta-merta memasukkan semua sinyal yang dapat diperoleh dari browser; stabilitas dan keunikan tiap sinyal dianalisis secara terpisah untuk menilai dampaknya terhadap akurasi fingerprint
  • Fingerprint audio dinilai hanya sedikit berkontribusi pada keunikan, tetapi karena stabilitasnya tinggi, ia menjadi sinyal yang sedikit meningkatkan akurasi fingerprint secara keseluruhan

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-11
Komentar Hacker News

  • Teknik menarik lain untuk mengidentifikasi pengguna secara online adalah fingerprinting GPU, yang diperkenalkan pada 2022 dengan nama kode "DrawnApart"
    Caranya adalah menghitung jumlah dan kecepatan unit eksekusi GPU lewat WebGL, serta mengukur waktu penyelesaian rendering vertex dan pemrosesan fungsi stall

    1. https://www.bleepingcomputer.com/news/security/researchers-u...
    • Secara default browser seharusnya memakai software renderer, dan saat membuka jalur rendering GPU hardware, situs harus meminta izin pengguna seperti mikrofon atau kamera

  • Belakangan ini, terutama jika melihat minat terhadap serangan side-channel, menurut saya pendekatan menambahkan noise seragam ke nilai yang membocorkan data hampir pasti tidak akan berhasil
    Karena dengan mengumpulkan lebih banyak sampel, noise bisa dihilangkan. Saya tidak tahu mengapa Safari menambahkan ini. Mungkin bisa membuat fingerprinting lebih merepotkan, tetapi seperti tulisan ini, pada akhirnya tampaknya secara umum bisa ditembus dalam bentuk tertentu

    • Menurut saya cukup banyak fitur privasi Apple belakangan ini lebih mirip pemasaran
      Rasanya seperti teater privasi, ketika yang lebih penting adalah apakah bisa menyampaikan cerita yang terdengar meyakinkan kepada publik, bukan apakah secara teknis efektif

  • Bisa jelaskan mengapa hasilnya berbeda sejak awal? Misalnya saya penasaran mengapa audio fingerprinting bisa dilakukan

    • Intinya tampaknya ada pada Web Audio API yang memiliki algoritme dengan banyak operasi matematika, implementasinya sedikit berbeda di tiap browser, dan hasil persisnya juga bergantung pada sistem operasi dan CPU
      Jika membuat sinyal kecil dengan Web Audio API, semua browser menghasilkan hasil yang hampir sama, tetapi perbedaan yang sangat kecil bisa digunakan untuk membedakan satu sama lain
    • Mirip teknik serupa yang dipakai di WebGL, menurut saya ini seperti banyak entropi yang berasal dari driver kartu grafis PC dan hardware itu sendiri
      Menyedihkan bahwa developer browser harus menambahkan noise ke pemrosesan buffer audio untuk mencegah hal ini
    • Itu juga yang pertama kali terpikir oleh saya, dan dibahas lebih rinci di sini: https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...
      Ringkasnya, bahkan dalam basis kode yang sama, jalur kode yang berbeda, misalnya varian SIMD, dapat menghasilkan hasil floating-point yang sedikit berbeda. Ini tampaknya terkait dengan fakta bahwa operasi floating-point lebih sensitif dari yang diperkirakan terhadap urutan operasi dan hal-hal sejenisnya
    • Kemungkinan besar karena detail implementasi dan optimisasi compiler. Misalnya, penjumlahan floating-point tidak komutatif
      Bahkan jika algoritme dan rumus yang sama diimplementasikan dengan benar, hasilnya bisa sedikit berbeda

  • Koreksi saya kalau salah. Alasan bypass fingerprinting di sini berhasil tampaknya bermuara pada pilihan dalam spesifikasi Web Audio API yang membiarkan cara penanganan anti-aliasing OscillatorNode seperti ini
    "Ada berbagai pendekatan praktis yang dapat diambil implementasi untuk menghindari aliasing ini. Terlepas dari pendekatannya, sinyal audio digital waktu-diskret yang ideal didefinisikan dengan baik secara matematis. Kompromi implementasi terletak pada biaya implementasi dari sisi penggunaan CPU dan seberapa setia implementasi mendekati ideal ini. Implementasi diharapkan cukup berhati-hati untuk mencapai ideal ini, tetapi pada hardware kelas rendah masuk akal untuk mempertimbangkan pendekatan dengan kualitas lebih rendah dan biaya lebih rendah."
    Menurut saya ini berarti output OscillatorNode yang dieksploitasi di sini hampir pasti tidak deterministik antar-browser, bahkan pada browser yang sama di hardware berbeda. Ketidakdeterministikan itu didasarkan pada metode anti-aliasing yang dipilih browser, atau berbagai jalur yang dipilih dalam browser yang sama tergantung hardware. Ini juga mencakup perubahan atau revisi pada algoritme anti-aliasing yang sama
    Saya tidak begitu paham mengapa anti-aliasing diserahkan kepada browser. Aplikasi atau library audio berkualitas tinggi akan ingin mengontrol sepenuhnya cara menghindari aliasing pada sinyal yang mereka hasilkan, dan tidak akan memakai oscillator bawaan. Sebaliknya, jika sebuah web app mau menerima algoritme anti-aliasing arbitrer beserta perbedaan antar-browser yang menyertainya, kemungkinan besar ia tidak akan terlalu peduli apakah algoritmenya berupa instruksi SIMD yang di-hardcode atau framework helper JavaScript Web Audio berukuran 20MB
    1: https://webaudio.github.io/web-audio-api/#OscillatorNode
    Saya juga penasaran apakah solusi yang sama seperti yang dipakai Hixie saat menstandardisasi parser HTML5 bisa diterapkan di sini. Misalnya, seorang pakar bidang tertentu menetapkan algoritme anti-aliasing yang presisi dan deterministik yang bekerja cukup baik, lalu setelah itu semua browser menggunakannya. Penurunan performa yang terukur tampaknya hanya akan terlihat pada tutorial Web Audio API yang menghasilkan sinyal dengan oscillator anti-aliasing bawaan

    • Anti-aliasing berkualitas tinggi itu mahal
      Karena itu implementasi ingin diberi kebebasan menentukan berapa banyak sumber daya komputasi, baterai, dan sebagainya yang akan dipakai

  • Memasukkan API audio node graph ke browser adalah tindakan bodoh. Seharusnya hanya ada AudioWorklet

  • Menjijikkan

    • Menurutku juga persis begitu. Menarik, tapi menjijikkan
      Dari awal aku tidak paham kenapa Audio API bisa dipakai tanpa izin situs web. Rasanya ini mudah diperbaiki dengan dialog sederhana seperti "Situs ini ingin menggunakan perangkat suara"
    • Membuatku bertanya apakah network stack saat ini layak dipakai untuk 100 tahun ke depan
      Internet dalam bentuknya sekarang sudah banyak merusak impian komputasi personal. Karena perusahaan dan negara terlalu kuat secara asimetris dibanding individu. Apakah teknologiku memang harus bisa mengirim data ke server tanpa persetujuan eksplisit?
    • Betul. Sulit dipercaya orang-orang ini bangga dengan hal ini
      Di sisi lain, setelah aku menghapus cache browser dan menyalakan VPN, mereka memang keliru mengenaliku sebagai pengunjung baru. Tetap saja model bisnis-nya busuk
    • Karena namanya fingerprint.com, menurutku ada ironi tertentu. Mirip seperti munculnya situs web yang memopulerkan celah untuk menghindari beban pajak, lalu dunia merasa jijik dan menutup celah itu
      Bahkan kalau itu tafsir yang terlalu optimistis, ada nilai besar dalam memublikasikan dan mengekspos riset seperti ini. Daripada khawatir semua orang akan lebih banyak mencuri hanya karena ada tulisan bahwa ransel hijau merek tertentu membantu pencurian, aku lebih condong bahwa toko-toko akan lebih mampu mengenali modus tersebut

  • Alih-alih menambahkan nilai acak ke setiap sampel, Safari sepertinya juga bisa menambahkan noise deterministik berdasarkan kunci yang berubah setiap jam
    Jika dibuat sebagai fungsi dari sampel audio dan kunci, noise-nya akan sama dalam sesi yang sama, tetapi menjadi tidak berguna untuk pelacakan satu jam kemudian

    • Kalau 10 sampel seperti itu dirata-ratakan, pada akhirnya hasilnya akan mendekati nilai sebenarnya dari perangkat. Semakin banyak sampel, akan semakin dekat
      Untuk memperbaiki ini, kebocoran informasinya sendiri harus dihilangkan; sekadar menutupinya dengan lapisan deviasi acak tidak cukup
    • Bukankah akan membantu jika noise yang ditambahkan bersifat deterministik berdasarkan origin? Dengan begitu, ia tidak bisa dihilangkan dengan mengambil rata-rata lewat sampling berlebihan
      Misalnya dengan cara seperti RNG_SEED = HMAC_SHA256(PERSISTENT_SECRET,Location.origin)

  • Sekarang aku benar-benar siap menjadi "orang itu" yang menjelajah web dengan JavaScript dimatikan

    • Masalahnya, hanya dengan menjadi "orang itu" saja, kamu mungkin sudah menyerahkan lebih dari 10 bit untuk identifikasi
      Jika mereka mengorek beberapa bit lagi dari tempat lain, kamu bisa diidentifikasi secara unik. Tetap saja, menurut standarku, orang-orang ini boleh dikirim bersama sisa industri adtech ke Golgafrinchan Ark B
    • Semoga berhasil. Mengejutkan betapa sedikitnya HTML lama yang benar-benar layak di web sekarang
      Sebuah situs web yang baru-baru ini kukunjungi memang memakai markup, tetapi bukannya dikompilasi menjadi HTML dan disajikan secara statis, malah dirender dengan JavaScript di sisi klien. WTF
    • Ayo lakukan bersama, ini benar-benar bisa dicoba. Ada ekstensi Firefox bagus bernama uMatrix yang memudahkan mematikan JavaScript tidak hanya per situs, tetapi juga per subdomain, dan mudah menyalakannya lagi di situs yang rusak tanpa JavaScript
    • Semoga berhasil. Belakangan aku menyerah dalam pertarungan ini. Karena hampir semua situs web yang kukunjungi mengharuskanku menyalakan JavaScript lagi untuk melihat kontennya
      Bukan cuma pemeriksaan DDoS seperti Cloudflare; sekarang bahkan hal-hal yang seharusnya ada di HTML halaman pun dimuat lewat JavaScript
    • Justru karena alasan inilah Tor Browser seharusnya mematikan JavaScript
      Semakin internet berubah menjadi makin bermusuhan, pilihan ini menjadi semakin tepat

  • Aku kurang paham bagaimana metode ini bisa menghasilkan lebih dari beberapa ribu kombinasi unik
    Jenis browser × versi browser × versi sistem operasi × versi akselerator × … apa lagi? Rasanya tidak ada cukup variasi untuk bisa disebut unik dari jarak jauh

    • Kombinatorika adalah nyonya yang kejam

  • Apakah teknik ini membuat fingerprint berdasarkan perbedaan hardware, driver, dan sistem operasi dalam pemrosesan audio, atau hanya melihat software browser saja?
    Kurasa pernah ada, atau masih ada, teknik serupa yang mengekspos perbedaan perangkat grafis di bawahnya

    • Caranya mirip. Algoritme audio sering memanggil fungsi sistem operasi dan memanfaatkan optimasi CPU
      Salah satu contoh yang disebut dalam tulisan adalah transformasi Fourier cepat (FFT). Semua sistem operasi memiliki versi fungsi ini, tetapi biasanya dioptimalkan seiring waktu, dan sering kali berperilaku berbeda antar-CPU tergantung instruksi SIMD yang tersedia