Aplikasi Mac Anda Memberi Akses Mikrofon — Lalu Melupakannya Setiap Kali Dibuka

Inilah bug yang membuat Anda meragukan mata Anda sendiri. Anda memasang GeekBye, ia meminta akses mikrofon, Anda mengeklik Izinkan, dan transkripsi berhasil. Bagus. Anda keluar, membukanya lagi keesokan paginya — dan ia meminta akses mikrofon lagi. Anda pergi memeriksa Pengaturan Sistem → Privasi & Keamanan → Mikrofon untuk memperbaikinya secara manual, dan GeekBye bahkan tidak ada di daftar. Tidak ditolak. Tidak diizinkan. Hanya tidak ada, seolah-olah ia tidak pernah meminta.

Setiap bagian tampak benar. Permintaannya nyata. Izinnya berfungsi saat itu. Aplikasi ditandatangani dan dinotarisasi dengan benar beserta string penggunaan yang tepat. Namun pemberian izin itu menguap setiap kali dibuka. GeekBye v2.0.6 memperbaikinya — dan akar penyebabnya adalah salah satu hal paling licik yang dilakukan macOS untuk melindungi Anda.

Fitur yang menyembunyikan aplikasi dari dirinya sendiri

Biang keladinya adalah macOS App Translocation, sebuah fitur keamanan Gatekeeper. Ketika Anda mengunduh aplikasi dan menjalankannya langsung dari DMG atau dari folder ~/Downloads — di mana pun ia masih "dikarantina" — macOS sebenarnya tidak menjalankannya dari tempat yang Anda lihat. macOS secara transparan menyalinnya ke jalur acak yang hanya-baca jauh di dalam /private/var/folders/.../AppTranslocation/… dan menjalankan salinan itu. Ini pertahanan yang baik: mencegah unduhan berbahaya mengutak-atik file di sebelahnya.

Tetapi di sinilah benturannya. Sistem izin macOS (TCC — hal yang melacak siapa yang boleh menggunakan mikrofon, kamera, layar Anda) mengidentifikasi aplikasi berdasarkan jalur dan identitas kodenya. Ketika aplikasi ditranslokasi, jalur itu acak dan sementara. Jadi ketika Anda memberi akses mikrofon, macOS dengan patuh mencatat pemberian izin — terhadap sebuah jalur yang tidak akan ada saat dibuka berikutnya. Buka kembali aplikasinya, macOS mentranslokasinya ke jalur acak yang berbeda, melihat aplikasi yang tidak ada catatannya, dan meminta lagi. Dan karena jalur hantu itu tidak pernah menjadi lokasi yang stabil, aplikasi tidak pernah memperoleh baris permanen di Pengaturan Sistem → Mikrofon.

Aplikasi itu memberikan izin kepada hantu.

Inilah juga sebabnya hanya sebagian orang yang mengalaminya. Jika salinan GeekBye Anda sudah berada di /Applications — karena Anda menyeretnya ke sana, atau karena ia sampai ke sana melalui pembaruan otomatis — tidak ada karantina, tidak ada translokasi, jalurnya stabil, dan semuanya bertahan dengan sempurna. Bug itu tak terlihat oleh kami dan oleh siapa pun yang sudah melewati pemasangan pertamanya, persis jenis bug yang bertahan paling lama.

Perbaikannya: beri aplikasi rumah yang sebenarnya

Karena seluruh masalahnya adalah jalur yang tidak stabil, perbaikannya adalah membawa aplikasi ke jalur yang stabil. v2.0.6 mendeteksi ketika GeekBye berjalan tertranslokasi (atau sekadar berjalan di luar /Applications) dan menawarkan satu klik "Move to Applications" — menggunakan panggilan relokasi macOS yang menyalin bundel ke /Applications dan meluncurkannya kembali dari sana. Sejak saat itu aplikasi memiliki identitas tetap: pemberian izin mikrofon melekat, perekaman layar melekat, dan GeekBye akhirnya muncul di Pengaturan Sistem tempat Anda mengharapkannya.

Permintaan itu bersikap sopan. Ia menawarkan Move to Applications, Not Now, dan Don't Ask Again — dan ia mengingat pilihan terakhir, sehingga aplikasi tidak pernah mengganggu seseorang yang punya alasan sengaja untuk menjalankannya dari tempat lain. Keputusan apakah perlu menampilkan permintaan itu sama sekali diisolasi ke dalam fungsi-fungsi kecil dan murni (apakah build ini tertranslokasi? apakah di luar /Applications? apakah pengguna menekannya?) sehingga logikanya diuji unit tanpa perlu meluncurkan build yang benar-benar dinotarisasi pada volume karantina yang sesungguhnya.

Rilis yang sama juga menyederhanakan pengalaman izin itu sendiri. GeekBye dulu memunculkan jendela izin dalam-aplikasi yang khusus dan buatan sendiri — beberapa ratus baris antarmuka yang mencoba menirukan sesuatu yang sudah dilakukan OS dengan baik. v2.0.6 menghapusnya dan bersandar pada permintaan izin macOS bawaan, didukung oleh spanduk tenang dan non-pemblokir yang muncul hanya ketika izin yang diperlukan benar-benar hilang. Lebih sedikit kode, dan perilaku yang sudah dikenali pengguna karena setiap aplikasi Mac lain bekerja dengan cara yang sama.

Bagian yang paling saya banggakan: kami membuktikannya sebelum meyakininya

Akan mudah untuk menebak translokasi dan merilis perbaikan. Sebaliknya, rilis itu menyediakan diagnostik saat mulai lebih dulu: saat diluncurkan, GeekBye kini melaporkan jalur file eksekusinya sendiri dan apakah ia tertranslokasi, apakah ia di dalam /Applications, dan status izin mikrofon dan layar saat ini. Telemetri itu mengubah teori yang masuk akal menjadi teori yang terkonfirmasi — data produksi menunjukkan bahwa sesi yang terdampak memang berjalan dari jalur tertranslokasi di luar /Applications, persis seperti yang diprediksi.

Urutan itu penting. "Permintaan muncul tetapi izin tidak melekat" punya beberapa penjelasan yang mungkin — masalah penandatanganan, string penggunaan yang hilang, masalah entitlement, keanehan basis data TCC. Kami menyingkirkan penyebab di tingkat API (jalur permintaan terbukti benar), lalu membiarkan data dunia nyata menunjuk ke lapisan identitas/jalur alih-alih merilis perbaikan penuh harapan dan berharap tiket dukungan berhenti.

Tiga hal yang diajarkan bug ini

1. Izin yang meminta tetapi tidak bertahan adalah masalah identitas, bukan masalah API. Jika kode permintaannya benar dan pemberian izinnya tetap lenyap, berhentilah menulis ulang permintaan itu. Tanyakan jalur dan identitas kode apa yang diikat OS pada izin itu — dan apakah identitas itu stabil di seluruh pembukaan.
2. Rilis diagnostik bersama (atau sebelum) perbaikan. Beberapa bidang — dari mana saya berjalan, apa status izin saya — mengubah tebakan berpengetahuan menjadi akar penyebab yang terverifikasi dan memberi tahu kami persis pengguna mana yang terdampak. Pasang instrumen pada batas yang Anda curigai sebelum menambalnya.
3. Bug yang bersembunyi dari pengembang adalah yang berjalan di lingkungan "yang salah". Milik kami tinggal di /Applications pada setiap mesin pengembang, jadi bug itu secara struktural tak terlihat oleh kami sementara menimpa pengguna pertama kali. Ketika sebuah laporan tidak dapat direproduksi, pertanyaan pertamanya adalah apa yang berbeda tentang tempat ia berjalan, bukan apakah pengguna keliru.

GeekBye v2.0.6 merilis permintaan relokasi dan diagnostik itu bersamaan. Untuk busur keandalan yang lebih luas tempat ini berada, lihat apa yang sebenarnya dibutuhkan sebuah versi 2 (v2.0.0) dan mengapa perekaman layar menangkap monitor yang salah (v2.0.10) — bug lain yang hanya muncul di lingkungan tertentu. Untuk rilis detail-kecil di sebelahnya, perangkat lunak yang tenang: perbaikan kedip dan chip mode-jawaban (v2.0.3 + v2.0.5).