Praktik terbaik untuk ID unik

Dokumen ini memberikan panduan 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), tanpa membatasi fungsionalitas yang diperlukan.

   Android 10 (API level 29) menambahkan batasan untuk ID yang tidak dapat disetel ulang, yang mencakup IMEI dan nomor seri. Aplikasi Anda harus berupa perangkat atau aplikasi pemilik profil, memiliki izin operator khusus, atau memiliki izin hak istimewa READ_PRIVILEGED_PHONE_STATE untuk mengakses ID ini.

2. Hanya gunakan ID Iklan untuk profiling pengguna atau kasus penggunaan iklan. Saat menggunakan ID Iklan, selalu hargai pilihan pengguna terkait pelacakan iklan. Selain itu, pastikan bahwa ID tidak dapat terhubung dengan informasi identitas pribadi (PII), dan hindari mengaitkan ID Iklan dengan yang lain saat dilakukan reset.

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

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 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.

Menggunakan ID iklan

ID Iklan adalah ID yang dapat di-reset 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 mereset ID iklan. Jangan mengaitkan suatu tindakan reset pengguna dengan menggunakan ID lain atau sidik jari untuk menautkan beberapa ID Iklan yang digunakan berurutan tanpa persetujuan pengguna. Kebijakan Konten Developer Google Play menyatakan berikut ini:

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

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

"...Anda harus mematuhi setelan 'Memilih tidak ikut periklanan menurut minat' atau 'Memilih tidak ikut Personalisasi Iklan' pengguna. 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 pengiklanan kontekstual, pembatasan frekuensi, pelacakan konversi, pelaporan dan keamanan, serta deteksi penipuan".

Waspadalah terhadap segala kebijakan keamanan atau privasi terkait SDK yang Anda gunakan dan terkait dengan penggunaan ID iklan. Misalnya, jika Anda meneruskan true ke dalam 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:

Dalam contoh ini, kolom ad_id dapat digabungkan dengan PII melalui kolom account_id di kedua tabel, yang merupakan pelanggaran terhadap 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 “ID-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:

Dalam kasus ini, dengan peristiwa klik yang cukup jarang, masih mungkin untuk menggabungkan antara 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 ID-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 menautkan PII dengan ID Iklan. Pada contoh pertama di atas, ini berarti tidak menyertakan 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 logging akses dan audit untuk mendeteksi dan mengelola setiap pengecualian untuk aturan ini.

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

Menggunakan ID Instance dan GUID

Solusi termudah untuk mengidentifikasi instance aplikasi yang dijalankan di perangkat adalah dengan menggunakan ID Instance, 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 di-reset karena hanya bertahan selama aplikasi diinstal.

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

Dalam kasus 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 sendiri menggunakan kode berikut:

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

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.

Jangan menggunakan alamat MAC

Alamat MAC bersifat unik secara global, tidak dapat di-reset pengguna, dan tidak dapat dihapus meski dilakukan reset ke setelan pabrik. Karena itu, biasanya tidak direkomendasikan menggunakan alamat MAC untuk semua bentuk identifikasi pengguna. Perangkat yang menjalankan Android 10 (API level 29) dan yang lebih tinggi melaporkan alamat MAC acak ke semua aplikasi yang bukan aplikasi pemilik perangkat.

Antara Android 6.0 (API level 23) dan Android 9 (API level 28), alamat MAC perangkat lokal, seperti Wi-Fi dan Bluetooth, tidak tersedia melalui API pihak ketiga. Baik metode WifiInfo.getMacAddress() maupun metode BluetoothAdapter.getDefaultAdapter().getAddress() menampilkan 02:00:00:00:00:00.

Selain itu, antara Android 6.0 dan Android 9, Anda harus memiliki izin berikut untuk mengakses alamat MAC perangkat eksternal di sekitar yang tersedia melalui pemindaian Bluetooth dan Wi-Fi:

Karakteristik ID

OS Android menyediakan sejumlah ID dengan karakteristik perilaku 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 ID 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, ID tidak dapat digunakan untuk melacak perangkat di berbagai transaksi dalam aplikasi yang berbeda.

Kemampuan reset dan persistensi

Kemampuan reset dan persistensi menentukan masa aktif ID dan menjelaskan cara ID dapat di-reset. Pemicu reset umum mencakup: reset dalam aplikasi, reset melalui Setelan Sistem, reset saat peluncuran, dan reset saat penginstalan. ID Android dapat memiliki masa aktif yang berbeda, tetapi masa aktifnya biasanya terkait dengan cara ID di-reset.

• Khusus sesi: ID baru digunakan setiap kali pengguna memulai ulang aplikasi.
• Reset saat instal: ID baru digunakan setiap kali pengguna meng-uninstal dan menginstal ulang aplikasi.
• Reset 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 reset 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 di-reset saat penginstalan ulang, tindakan ini mengurangi persistensi dan memberikan cara agar ID di-reset, meski tidak terdapat kontrol pengguna yang eksplisit untuk mereset 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 bergantung 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, setiap perangkat/kombinasi 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 guna 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 mereset 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 sisi server tanpa akun pengguna.

Gunakan: ID Instance atau GUID

Mengapa rekomendasi ini?

Informasi yang tetap bertahan bahkan setelah dilakukan penginstalan ulang tidak direkomendasikan karena pengguna mungkin ingin mereset 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 sisi 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 meresetnya.

Membuat analisis pengguna yang logout atau anonim

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

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

Mengapa rekomendasi ini?

ID Instance atau GUID dicakupkan ke aplikasi yang membuatnya, sehingga mencegah ID digunakan untuk melacak pengguna di berbagai aplikasi. ID ini juga dapat di-reset dengan mudah, karena pengguna dapat menghapus data aplikasi atau menginstal ulang aplikasi. Proses pembuatan Instance ID 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 ditautkan 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: ID Instance atau GUID

Mengapa rekomendasi ini?

ID Instance dirancang secara eksplisit untuk tujuan ini; cakupannya terbatas pada aplikasi sehingga tidak dapat digunakan untuk melacak pengguna di aplikasi yang berbeda, dan akan di-reset saat aplikasi diinstal ulang. Dalam kasus yang jarang terjadi saat ID Instance 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: ID Instance atau GUID. Di Android 8.0 (API level 26) dan lebih tinggi, SSAID juga menjadi opsi, karena dicakup ke kunci penandatanganan aplikasi.

Mengapa rekomendasi ini?

Penggunaan GUID atau ID Instance 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 fungsionalitas telepon dan SMS perangkat menggunakan akun operator.

Gunakan: IMEI, IMSI, dan Line1

Mengapa rekomendasi ini?

Pemanfaatan ID hardware dapat diterima jika diperlukan untuk fungsionalitas 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 berasal dari perangkat Android asli—bukan emulator atau kode lain yang melakukan spoofing perangkat lain—menggunakan metode attest() SafetyNet API untuk memverifikasi integritas perangkat yang melakukan permintaan. Untuk informasi yang lebih 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.