Register now for Android Dev Summit 2019!

Praktik terbaik untuk ID unik

Dokumen ini memberikan panduan untuk memilih ID yang sesuai untuk aplikasi Anda, berdasarkan kasus penggunaan.

Untuk pembahasan umum tentang izin Android, lihat Ringkasan izin. Untuk praktik terbaik khusus mengenai penggunaan izin Android, lihat Praktik terbaik untuk izin aplikasi.

Praktik terbaik untuk penggunaan ID Android

Saat menggunakan ID Android, ikuti praktik terbaik ini:

#1: Hindari menggunakan ID hardware. Dalam sebagian besar kasus penggunaan, Anda dapat menghindari penggunaan ID hardware, seperti SSAID (Android ID) dan IMEI, tanpa membatasi fungsi yang diperlukan.

#2: Hanya gunakan ID Iklan untuk kasus profiling pengguna atau penggunaan periklanan. Saat menggunakan ID Iklan, selalu hormati pilihan pengguna terkait pelacakan iklan. Selain itu, pastikan bahwa ID tidak dapat terhubung dengan informasi identitas pribadi (PII), dan hindari menjembatani penyetelan ulang ID Iklan.

#3: Gunakan ID Instance atau GUID yang disimpan secara pribadi jika memungkinkan untuk semua kasus penggunaan lainnya, kecuali pencegahan penipuan pembayaran dan telepon. Dalam banyak kasus penggunaan non-iklan, ID Instance atau GUID seharusnya mencukupi.

#4: Gunakan API yang sesuai pada kasus penggunaan Anda untuk meminimalkan risiko privasi. Gunakan DRM API untuk perlindungan konten bernilai tinggi dan SafetyNet API untuk perlindungan dari penyalahgunaan. SafetyNet API adalah cara termudah untuk menentukan apakah perangkat tersebut asli tanpa menyebabkan risiko privasi.

Bagian selanjutnya dari panduan ini menguraikan aturan tersebut dalam konteks mengembangkan aplikasi Android.

ID di Android 8.0 dan lebih tinggi

Alamat MAC bersifat unik secara global, tidak dapat disetel ulang pengguna, dan tidak dapat dihapus meski dilakukan reset ke setelan pabrik. Karena itu, biasanya tidak disarankan menggunakan alamat MAC untuk semua bentuk identifikasi pengguna. Di Android 6.0 (API level 23) dan versi lebih tinggi, alamat MAC perangkat lokal, seperti Wi-Fi dan Bluetooth, tidak tersedia melalui API pihak ketiga. Metode WifiInfo.getMacAddress() dan metode BluetoothAdapter.getDefaultAdapter().getAddress() akan menampilkan 02:00:00:00:00:00.

Selain itu, Anda harus memiliki izin berikut untuk mengakses alamat MAC dari perangkat eksternal di sekitar yang terlihat melalui pemindaian Bluetooth dan Wi-Fi:

Metode/Properti Izin yang Diperlukan
WifiManager.getScanResults() ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION

Menggunakan ID iklan

ID Iklan adalah ID yang dapat disetel ulang oleh pengguna dan sesuai untuk kasus penggunaan iklan. Namun, ada beberapa poin utama yang perlu diingat saat Anda menggunakan ID ini:

Selalu hormati maksud pengguna dalam menyetel ulang ID iklan. Jangan menjembatani penyetelan ulang pengguna menggunakan ID lain atau sidik jari untuk menautkan ID Iklan berikutnya secara bersama tanpa persetujuan pengguna. Kebijakan Konten Developer Google Play menyatakan berikut ini:

"...saat menyetel ulang, ID iklan baru tidak boleh terhubung dengan ID iklan sebelumnya atau data yang berasal dari ID iklan sebelumnya tanpa persetujuan eksplisit dari pengguna."

Selalu hormati flag Iklan yang Dipersonalisasi terkait. ID Iklan dapat dikonfigurasi sehingga pengguna dapat membatasi jumlah pelacakan yang terkait dengan ID. Selalu gunakan metode AdvertisingIdClient.Info.isLimitAdTrackingEnabled() untuk memastikan bahwa Anda tidak mengabaikan keinginan pengguna. Kebijakan Konten Developer Google Play menyatakan berikut ini:

"...Anda harus mematuhi setelan pengguna 'Tidak ikut iklan berbasis minat' atau 'Tidak Ikut Personalisasi Iklan'. Jika pengguna telah mengaktifkan setelan ini, Anda tidak boleh menggunakan ID iklan tersebut untuk membuat profil pengguna demi tujuan periklanan, atau untuk menargetkan pengguna dengan periklanan yang dipersonalisasi. Aktivitas yang diizinkan mencakup periklanan kontekstual, pembatasan frekuensi, pelacakan konversi, pelaporan dan keamanan, serta deteksi penipuan".

Waspadalah terhadap segala kebijakan keamanan atau privasi yang terkait dengan SDK yang Anda gunakan yang terkait dengan penggunaan ID iklan. Misalnya, jika Anda meneruskan true ke metode enableAdvertisingIdCollection() dari SDK Google Analytics, pastikan untuk meninjau dan mematuhi semua kebijakan SDK Analytics yang berlaku.

Perlu diketahui juga, bahwa Kebijakan Konten Developer Google Play mengharuskan ID Iklan "tidak boleh terhubung dengan informasi identitas pribadi atau terkait dengan ID perangkat persisten (misalnya: SSAID, alamat MAC, IMEI, dll.,)."

Misalnya, anggap saja Anda ingin mengumpulkan informasi untuk mengisi tabel database dengan kolom berikut:

TABLE-01
timestamp ad_id account_id clickid
TABLE-02
account_id name dob country

Dalam contoh ini, kolom ad_id dapat digabungkan ke PII melalui kolom account_id di kedua tabel, dan hal ini melanggar Kebijakan Konten Developer Google Play, jika Anda tidak mendapatkan izin eksplisit dari pengguna.

Perlu diingat bahwa hubungan antara ID Iklan dan PII tidak selalu eksplisit seperti ini. Dimungkinkan untuk memiliki “identifier-semu” yang terlihat pada tabel yang menyertakan PII dan ID Iklan, dan ini juga menyebabkan masalah. Misalnya, anggap saja kita mengubah TABLE-01 dan TABLE-02 sebagai berikut:

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

Dalam kasus ini, dengan peristiwa klik yang cukup jarang, masih mungkin untuk menggabungkan TABLE-01 ID Iklan dan PII yang ada di TABLE-02 menggunakan stempel waktu peristiwa dan model perangkat.

Meski sering kali sulit untuk menjamin bahwa tidak ada identifier-semu dalam set data, Anda dapat mencegah risiko penggabungan yang paling jelas dengan menggeneralisasi data yang unik jika memungkinkan. Dalam contoh sebelumnya, ini berarti mengurangi akurasi stempel waktu sehingga beberapa perangkat dengan model yang sama muncul untuk setiap stempel waktu.

Solusi lain mencakup berikut ini:

  • Tidak mendesain tabel yang secara eksplisit menghubungkan PII dengan ID Iklan. Dalam contoh pertama di atas, ini berarti tidak memasukkan kolom account_id pada TABLE-01.

  • Memisahkan dan memantau daftar kontrol akses untuk pengguna atau peran yang memiliki akses ke data yang menyertakan ID iklan dan PII. Dengan secara ketat mengontrol dan mengaudit kemampuan untuk mengakses kedua sumber secara bersamaan (misalnya, dengan melakukan penggabungan tabel satu ke tabel lainnya), Anda mengurangi risiko menghubungkan ID Iklan dengan PII. Secara umum, mengontrol akses artinya melakukan hal berikut:

    1. Menjaga agar daftar kontrol akses (ACL) untuk data yang menyertakan ID Iklan dan PII tetap terpisah untuk meminimalkan jumlah individu atau peran yang ada di kedua ACL.
    2. Mengimplementasikan pencatatan log akses dan audit untuk mendeteksi dan mengelola setiap pengecualian untuk aturan ini.

Untuk mengetahui informasi selengkapnya tentang bekerja dengan ID Iklan secara bertanggung jawab, lihat referensi AdvertisingIdClient API.

Menggunakan ID Instance dan GUID

Solusi termudah untuk mengidentifikasi instance aplikasi yang dijalankan di perangkat adalah dengan menggunakan Instance ID, dan ini merupakan solusi yang direkomendasikan dalam sebagian besar kasus penggunaan non-iklan. Hanya instance aplikasi yang telah disediakan yang dapat mengakses ID ini, dan itu relatif mudah untuk disetel ulang karena hanya bertahan selama aplikasi diinstal.

Hasilnya, ID Instance menyediakan properti privasi yang lebih baik dibandingkan ID hardware lingkup perangkat yang tidak dapat disetel ulang. Untuk mengetahui informasi selengkapnya, lihat referensi FirebaseInstanceId API.

Jika ID Instance kurang praktis, Anda juga dapat menggunakan ID unik global (GUID) untuk mengidentifikasi instance aplikasi secara unik. Cara termudah untuk melakukannya adalah dengan membuat GUID Anda sendiri menggunakan kode berikut

Kotlin

    var uniqueID = UUID.randomUUID().toString()
    

Java

    String uniqueID = UUID.randomUUID().toString();
    

Karena ID bersifat unik secara global, ID juga dapat digunakan untuk mengidentifikasi instance aplikasi tertentu. Untuk menghindari masalah yang terkait dengan menghubungkan ID ke berbagai aplikasi, simpan GUID di penyimpanan internal, bukan penyimpanan eksternal (bersama). Untuk informasi selengkapnya, lihat halaman Ringkasan penyimpanan data dan file.

Karakteristik ID

OS Android menyediakan sejumlah ID dengan karakteristik perilaku yang berbeda. ID yang harus Anda gunakan bergantung pada cara karakteristik berikut berfungsi dengan kasus penggunaan Anda. Namun, karakteristik tersebut juga disertai dengan implikasi privasi, jadi, penting untuk memahami cara karakteristik tersebut berinteraksi satu sama lain.

Cakupan

Cakupan identifier menjelaskan sistem mana yang dapat mengakses ID. Cakupan ID Android umumnya dibagi menjadi tiga kategori:

  • Satu aplikasi: Ini adalah ID internal aplikasi dan tidak dapat diakses oleh aplikasi lain.
  • Grup aplikasi: ID dapat diakses oleh grup aplikasi terkait yang telah ditentukan.
  • Perangkat: ID dapat diakses oleh semua aplikasi yang diinstal di perangkat.

Semakin luas cakupan yang diberikan ke ID, semakin besar risiko untuk digunakan demi tujuan pelacakan. Sebaliknya, jika ID hanya dapat diakses oleh instance satu aplikasi, dan tidak dapat digunakan untuk melacak perangkat di berbagai transaksi dalam aplikasi yang berbeda.

Kemampuan setel ulang dan persistensi

Kemampuan setel ulang dan persistensi menentukan masa aktif ID dan menjelaskan cara ID dapat disetel ulang. Pemicu setel ulang biasanya adalah: setel ulang dalam aplikasi, setel ulang melalui Setelan Sistem, setel ulang saat peluncuran, dan setel ulang saat penginstalan. ID Android dapat memiliki masa aktif yang berbeda, namun masa aktifnya biasanya terkait cara ID disetel ulang.

  • Khusus sesi: ID baru digunakan setiap kali pengguna menyetel ulang aplikasi.
  • Setel ulang saat instal: ID baru digunakan setiap kali pengguna meng-uninstal dan menginstal ulang aplikasi.
  • Setel ulang saat FDR: ID baru digunakan setiap kali pengguna melakukan reset ke setelan pabrik
  • Persisten saat FDR: ID tidak dapat dihapus meski telah dilakukan reset ke setelan pabrik.

Kemampuan setel ulang menyebabkan pengguna dapat membuat ID baru yang tidak terkait dengan informasi profil yang sudah ada. Semakin lama dan semakin andal suatu ID bertahan, seperti ID yang bertahan setelah beberapa kali reset ke setelan pabrik, semakin besar risiko pengguna mengalami pelacakan jangka panjang. Jika ID disetel ulang saat penginstalan ulang, tindakan ini mengurangi persistensi dan memberikan cara agar ID disetel ulang, meski tidak terdapat kontrol pengguna yang eksplisit untuk menyetel ulang dari dalam aplikasi atau Setelan Sistem.

Keunikan

Keunikan menciptakan kemungkinan konflik, yaitu bahwa ID yang identik ada dalam cakupan terkait. Pada tingkat yang paling tinggi, ID unik global tidak akan mengalami konflik, bahkan pada perangkat atau aplikasi lain. Jika tidak, tingkat keunikan tergantung pada entropi ID dan sumber acak yang digunakan untuk membuatnya. Misalnya, peluang konflik jauh lebih tinggi untuk ID acak yang ditambahi tanggal kalender penginstalan (seperti 2019-03-01) daripada untuk ID yang ditambahi stempel waktu Unix penginstalan (seperti 1551414181).

Secara umum, ID akun pengguna dapat dianggap unik. Artinya, tiap kombinasi perangkat/akun memiliki ID unik. Di sisi lain, semakin tidak unik suatu ID dalam populasi, semakin besar perlindungan privasi karena kurang berguna untuk melacak pengguna individu.

Perlindungan integritas dan non-repudiability

Anda dapat menggunakan ID yang sulit untuk di-spoofing atau diputar ulang untuk membuktikan bahwa perangkat atau akun terkait memiliki properti tertentu. Misalnya, Anda dapat membuktikan bahwa suatu perangkat bukan perangkat virtual yang digunakan oleh spammer. ID yang sulit untuk di-spoofing juga memberikan non-repudiability. Jika perangkat menandatangani pesan dengan kunci rahasia, akan sulit untuk mengklaim bahwa perangkat orang lain yang mengirim pesan tersebut. Non-repudiability dapat menjadi fitur yang diinginkan oleh pengguna, seperti saat mengautentikasi pembayaran, atau dapat menjadi properti yang tidak diinginkan, seperti saat mengirim pesan yang akan mereka sesali.

Kasus penggunaan umum dan ID yang sesuai untuk digunakan

Bagian ini menyediakan alternatif penggunaan ID hardware, seperti IMEI. Menggunakan ID hardware tidak disarankan karena pengguna tidak dapat menyetel ulang ID tersebut, dan cakupannya untuk perangkat. Dalam banyak kasus, ID lingkup aplikasi sudah cukup.

Melacak preferensi pengguna yang logout

Dalam kasus ini, Anda menyimpan status per perangkat di server tanpa akun pengguna.

Gunakan: Instance ID atau GUID

Mengapa rekomendasi ini?

Informasi yang tetap bertahan bahkan setelah dilakukan penginstalan ulang tidak direkomendasikan karena pengguna mungkin ingin menyetel ulang preferensi dengan menginstal ulang aplikasi.

Melacak preferensi pengguna yang logout di berbagai aplikasi dengan kunci penandatangan yang sama

Dalam kasus ini, Anda menyimpan status per perangkat di server dan mentransfernya ke aplikasi yang berbeda-beda yang ditandatangani dengan kunci yang sama di perangkat yang sama.

Gunakan: SSAID

Mengapa rekomendasi ini?

Di Android 8.0 (API level 26) dan lebih tinggi, SSAID menyediakan ID yang umum untuk berbagai aplikasi yang ditandatangani oleh kunci penandatangan developer yang sama. Ini memungkinkan Anda membagikan status antar-aplikasi tersebut tanpa mengharuskan pengguna untuk login ke akun.

Melacak perilaku pengguna yang logout

Dalam kasus ini, Anda telah membuat profil pengguna berdasarkan perilakunya di berbagai aplikasi/sesi pada perangkat yang sama.

Gunakan: ID Iklan

Mengapa rekomendasi ini?

Penggunaan ID Iklan bersifat wajib untuk kasus penggunaan periklanan menurut Kebijakan Konten Developer Google Play karena pengguna dapat menyetel ulangnya.

Membuat analisis pengguna yang logout atau anonim

Dalam kasus ini, Anda mengukur statistik penggunaan dan analisis untuk pengguna yang logout atau anonim.

Gunakan: Instance ID, atau GUID jika Instance ID tidak cukup

Mengapa rekomendasi ini?

Instance ID atau GUID memiliki cakupan untuk aplikasi yang membuatnya, sehingga mencegah ID digunakan untuk melacak pengguna di berbagai aplikasi. ID ini juga mudah disetel ulang, karena pengguna dapat menghapus data aplikasi atau menginstal ulang aplikasi. Proses pembuatan ID Instance dan GUID sangat mudah:

  • Membuat ID Instance: Lihat panduan Firebase Cloud Messaging.
  • Membuat GUID: Implementasikan logika di aplikasi Anda, seperti yang ditunjukkan dalam cuplikan kode berikut:

    Kotlin

        val uniqueID: String = UUID.randomUUID().toString()
        

    Java

        String uniqueID = UUID.randomUUID().toString();
        

Perlu diperhatikan bahwa jika Anda memberi tahu pengguna bahwa data yang Anda kumpulkan bersifat anonim, sebaiknya pastikan bahwa Anda tidak menghubungkan ID dengan PII atau ID lain yang mungkin dihubungkan dengan PII.

Anda juga dapat menggunakan Google Analytics untuk Aplikasi Seluler, yang menawarkan solusi analisis per aplikasi.

Melacak konversi pengguna yang logout

Dalam kasus ini, Anda melacak konversi untuk mendeteksi apakah strategi pemasaran berhasil.

Gunakan: ID Iklan

Mengapa rekomendasi ini?

Ini adalah kasus penggunaan yang terkait dengan periklanan yang mungkin memerlukan ID yang tersedia di banyak aplikasi yang berbeda sehingga penggunaan ID Iklan adalah solusi yang paling sesuai.

Menangani beberapa penginstalan di perangkat yang berbeda

Dalam kasus ini, Anda harus mengidentifikasi instance aplikasi yang benar saat diinstal di beberapa perangkat untuk pengguna yang sama.

Gunakan: Instance ID atau GUID

Mengapa rekomendasi ini?

Instance ID didesain secara eksplisit untuk tujuan ini; cakupannya terbatas pada aplikasi sehingga tidak dapat digunakan untuk melacak pengguna di aplikasi yang berbeda, dan akan disetel ulang saat aplikasi diinstal ulang. Dalam kasus yang jarang terjadi saat Instance ID tidak mencukupi, Anda juga dapat menggunakan GUID.

Pencegahan penipuan: Menerapkan batas konten gratis dan mendeteksi serangan Sybil

Dalam kasus ini, Anda ingin membatasi jumlah konten gratis, seperti artikel, yang dapat dilihat oleh pengguna di perangkat.

Gunakan: Instance ID atau GUID. Di Android 8.0 (API level 26) dan lebih tinggi, SSAID juga menjadi opsi, karena cakupannya untuk kunci yang menandatangani aplikasi.

Mengapa rekomendasi ini?

Penggunaan GUID atau Instance ID akan memaksa pengguna untuk menginstal ulang aplikasi untuk menghindari batasan konten, dan ini menjadi penghalang yang cukup besar bagi sebagian besar orang. Jika penggunaan ID tersebut tidak memberikan perlindungan yang memadai, Android menyediakan DRM API, yang dapat digunakan untuk membatasi akses ke konten, termasuk ID per APK, yaitu Widevine ID.

Fungsionalitas operator

Dalam kasus ini, aplikasi Anda berinteraksi dengan fungsi telepon dan SMS perangkat menggunakan akun operator.

Gunakan: IMEI, IMSI, dan Line1

Mengapa rekomendasi ini?

Pemanfaatan ID hardware dapat diterima jika diperlukan untuk fungsi terkait operator. Misalnya, Anda dapat menggunakan ID ini untuk beralih antara operator seluler atau slot SIM, atau untuk mengirim pesan SMS melalui IP (untuk Line1) - akun pengguna berbasis SIM. Namun, untuk aplikasi yang tidak memiliki hak istimewa, sebaiknya gunakan login akun untuk mengambil informasi perangkat dari server. Salah satu alasannya adalah bahwa, di Android 6.0 (API level 23) dan lebih tinggi, ID ini hanya dapat digunakan melalui izin runtime. Pengguna mungkin menonaktifkan izin ini, jadi aplikasi Anda dapat menangani pengecualian tersebut dengan baik.

Deteksi penyalahgunaan: Mengidentifikasi serangan bot dan DDoS

Dalam kasus ini, Anda mencoba mendeteksi beberapa perangkat palsu yang menyerang layanan backend.

Penggunaan: SafetyNet API

Mengapa rekomendasi ini?

ID yang terisolasi kurang membantu untuk menunjukkan bahwa sebuah perangkat adalah asli. Anda dapat memverifikasi bahwa permintaan datang dari perangkat Android asli—bukan sebuah emulator atau spoofing kode perangkat lain—menggunakan metode attest() SafetyNet API untuk memverifikasi integritas perangkat yang membuat permintaan. Untuk mengetahui informasi mendetail, lihat dokumentasi SafetyNet API.

Deteksi penipuan dan penyalahgunaan: Mendeteksi kredensial curian bernilai tinggi

Dalam kasus ini, Anda mencoba mendeteksi satu perangkat yang digunakan beberapa kali dengan kredensial curian bernilai tinggi, seperti untuk melakukan penipuan pembayaran.

Penggunaan: Biasanya, pencegahan penipuan memerlukan sinyal kepemilikan yang dapat berubah seiring waktu dan, oleh karena itu, berada di luar cakupan dokumen ini. Namun, perlu diperhatikan bahwa ID hardware, seperti IMEI dan IMSI, dapat dengan mudah diubah pada perangkat yang di-root atau diemulasikan, sehingga bukan merupakan indikator penipuan yang dapat diandalkan.