Menghindari Karakter yang Secara Visual Ambigu dalam ID

 (gajus.com)
4 poin oleh GN⁺ 2024-04-24 | 3 komentar | Bagikan ke WhatsApp
  • Dalam proses ketika manusia membaca dan menyampaikan ID, seperti laporan bug, memasukkan kode diskon, atau melacak pengiriman, ambiguitas visual seperti O/0 dan I/l/1/7 mudah berujung pada kesalahan input
  • Kebingungan makin besar bergantung pada font dan tulisan tangan, dan kombinasi yang batas pembedanya menjadi kabur seperti 5/S, 2/Z, 8/B, 6/G, 9/q/g muncul berulang
  • Untuk ID yang ditangani langsung oleh manusia, seperti dukungan pelanggan, ID error, dan ID produk, memilih himpunan karakter yang mudah dibaca lebih penting bagi kualitas penggunaan nyata daripada sekadar memakai himpunan karakter besar
  • Jika membedakan huruf besar-kecil, ID 5 karakter dapat menghasilkan 418,195,493 kombinasi, tetapi jika tidak membedakannya jumlahnya turun menjadi 5,153,632, sehingga diperlukan kompromi antara panjang dan keamanan
  • ID yang membedakan huruf besar-kecil mudah dibuat lebih pendek, tetapi sebagian sistem atau protokol pihak ketiga dapat bekerja secara case-insensitive, sehingga bisa menimbulkan masalah pada tahap integrasi

Kebingungan karakter pada ID yang dibaca manusia

  • Saat ID ditulis atau disampaikan dalam interaksi sistem seperti laporan bug, input kode diskon, dan pelacakan pengiriman, kebingungan karakter yang sebenarnya bisa dihindari dapat merusak pengalaman pengguna
  • Kombinasi karakter ambigu secara visual yang umum adalah sebagai berikut
    • O / 0: pada angka 0 tanpa garis miring atau titik, huruf O dan angka 0 bisa terlihat mirip
    • I / l / 1 / 7: huruf besar I, huruf kecil l, angka 1, dan angka 7 sulit dibedakan di berbagai materi cetak dan tulisan tangan
    • 5 / S, 2 / Z, 8 / B, 6 / G, 9 / q / g: dapat tertukar pada font tertentu, font bergaya, dan tulisan tangan
  • Contoh string 9qg6G8B2Z5SIl170O digunakan sebagai pembanding pada berbagai font sistem seperti Arial, Helvetica, Courier, Times, Verdana, Georgia, Tahoma, Impact, dan Comic Sans
  • Beberapa kombinasi seperti I dan l dapat terus terlihat ambigu di banyak font, dan ada juga kombinasi seperti 9qg yang makin membingungkan saat ditulis tangan langsung

    • Jenis ID yang masalahnya menjadi sangat besar

    • Kode diskon yang dipertukarkan dalam dukungan pelanggan
    • Kode pelacakan yang digunakan dalam pengiriman atau logistik
    • ID error yang diperlukan untuk mereproduksi masalah dan menangani pertanyaan
    • ID produk yang digunakan untuk identifikasi produk

Kompromi antara pembedaan huruf besar-kecil dan himpunan karakter

  • Apakah ID memperlakukan abc dan ABC sebagai nilai yang sama harus diputuskan bersama saat menetapkan aturan pembuatannya
  • Jika membedakan huruf besar-kecil sambil mengecualikan karakter yang secara visual ambigu, karakter yang dapat dipilih berjumlah 53
  • Jika tidak membedakan huruf besar-kecil, karakter yang dapat dipilih berkurang menjadi 22
  • Jumlah kombinasi yang mungkin menurut panjang ID adalah sebagai berikut
    • 5 karakter, membedakan huruf besar-kecil: 53^5 = 418,195,493
    • 5 karakter, tidak membedakan huruf besar-kecil: 22^5 = 5,153,632
    • 8 karakter, membedakan huruf besar-kecil: 53^8 = 62,259,690,411,361
    • 8 karakter, tidak membedakan huruf besar-kecil: 22^8 = 54,875,873,536
  • Pada akhirnya, pilihannya adalah keseimbangan antara ID yang pendek tetapi lebih mungkin membingungkan dan ID yang panjang tetapi mudah dibaca
  • Jika memakai huruf besar dan kecil sekaligus, suatu saat Anda bisa menemui perilaku tak terduga pada sistem atau protokol pihak ketiga yang tidak membedakan huruf besar-kecil
    • Sebuah sistem komersial memungkinkan pengguna memilih iD dan id sebagai ID yang berbeda, tetapi saat mencari ID yang tidak ada, sistem melakukan pencocokan case-insensitive sehingga mengembalikan data yang salah
    • Untuk bug tersebut, jawabannya adalah bahwa perilaku itu dibuat demi “kenyamanan”

Mungkin perlu menghindari kombinasi, bukan hanya satu karakter

  • Ada juga kasus ketika kombinasi karakter itu sendiri terlihat seperti karakter lain
    • rn dapat terlihat seperti m
    • vv dapat terlihat seperti w
  • Jika mengecualikan banyak karakter hanya karena alasan ini, himpunan karakter yang dapat dipilih bisa menjadi terlalu kecil, sehingga pendekatan yang lebih realistis adalah hanya menghindari kombinasi tertentu pada tahap pembuatan
  • Dalam situasi ketika ID disampaikan secara lisan, kemiripan bunyi juga dapat dipertimbangkan
    • Misalnya, b dan p bisa terdengar mirip saat diucapkan

Pendekatan yang sudah ada dan patut dirujuk

  • Base32 dari Crockford mendekode karakter ambigu sebagai nilai yang sama dan juga mempertimbangkan masalah ungkapan cabul yang tidak disengaja
  • Open Location Code menggunakan himpunan karakter 23456789CFGHJMPQRVWX
    • Himpunan karakter ini dipilih untuk menghindari karakter yang secara visual ambigu dan juga menghindari ejaan kata dalam bahasa umum
    • Namun, himpunan ini tetap mencakup 6 dan G, serta 9 dan Q

Bacaan terkait

3 komentar

 
roxie 2025-01-29

Ini juga terlihat bagus: https://stackoverflow.com/a/58098360/8556340
 
roxie 2025-01-29

Bahkan pengucapannya pun ikut dipertimbangkan, benar-benar menakjubkan.
 
GN⁺ 2024-04-24
Komentar Hacker News

  • Di tempat kerja, kami pernah mengirimkan nomor seri pada jutaan perangkat tanpa mengecualikan karakter atau angka yang membingungkan sama sekali, sehingga pelanggan sangat kesulitan membacanya dengan benar
    Kami sampai harus membuat skrip regex yang menghasilkan semua kemungkinan kombinasi salah ketik berdasarkan nilai yang diucapkan pelanggan dan hanya menampilkan yang cocok dengan database pabrik, lalu membandingkan informasi lain seperti tanggal untuk menebak nomor seri yang sebenarnya
    Yang lebih ironis, beberapa digit tidak pernah berubah sama sekali, dan ada posisi tertentu yang hanya perlu memakai 0, 1, 2 untuk membedakan pabrik, jadi dari awal sebenarnya tidak perlu seluruh himpunan karakter. Seolah-olah mereka yakin akan membuat 8 kuadriliun unit

    • Mencegah kebocoran informasi bisnis dari nomor seri sering kali berguna, atau setidaknya dianggap berguna
      Misalnya, jika produk diberi nomor berurutan seperti 1, 2, 3, total penjualan bisa diperkirakan cukup mudah hanya dari sampel kecil. Kadang ini juga membantu mencegah penyalahgunaan refund dengan membuat nomor seri yang valid sulit ditebak
      Tentu, meski ada kekhawatiran seperti itu, tetap bisa sekaligus menghindari karakter yang sulit dibaca. Malah jika ini berarti seseorang benar-benar memikirkan skema penomorannya, mereka seharusnya lebih sadar akan masalah ini. Kenyataannya, besar kemungkinan seseorang cuma berpikir sekitar 30 detik lalu berkata, “kalau digitnya sebanyak ini pasti tidak akan habis, selesai”
    • Setelah dipikir-pikir, mungkin ini juga alasan, atau setidaknya salah satu faktornya, kenapa nomor seri Apple tidak punya huruf vokal
      Nomor seri perangkat tampaknya hanya memakai konsonan dan angka

  • Encoding seharusnya disesuaikan dengan pengguna. Base32, khususnya Crockford dan RFC 4648, bagus untuk representasi singkat dan punya alfabet yang tidak ambigu beserta alasannya
    Tapi jika pengguna harus mengucapkannya, representasi daftar kata seperti s/key RFC 1751, misalnya “TIDE ITCH SLOW REIN RULE MOT”, mungkin lebih baik
    Jangan membuat daftar kata sendiri. Idiom, homofon, dialek, dan jebakan tersembunyi lainnya tidak ada habisnya. Jangan sampai tanpa sengaja membuat bencana besar seperti “wet clam butterfly”

    • Sayangnya, contoh itu juga bisa terdengar sebagai “TIED HITCH SLOE REIGN RULE MOW”. Dengan hanya 2 parity bit, kita bahkan tidak bisa yakin penguraian ini salah
      RFC 1751 [0] tempat contoh ini berasal tidak mengasumsikan encoding untuk penyampaian lisan, melainkan bertujuan agar pengguna lebih mudah “membaca, mengingat, dan memasukkan”
      Untuk penyampaian lisan antaraprofesional, pilihan yang masuk akal adalah memakai 26 huruf kapital saja dan mengandalkan alfabet fonetik NATO. Namun masalah menerima kode dalam lingkungan lisan yang bising dari pengguna yang tidak terlatih masih belum terselesaikan
      [0] https://datatracker.ietf.org/doc/html/rfc1751
    • Karena ini terbit pada 1994, beberapa hal memang bisa dimaklumi, tapi tetap saja ini RFC yang lumayan buruk sampai terasa lucu
      Dari bagian yang mengatakan, “harus menggunakan keyed message digest algorithm MD5, dan itu cukup kuat,” saja sudah mengundang tawa
      Sampai kalimat “kebanyakan orang sulit membaca, mengingat, dan memasukkan ini” masih bagus, lalu berlanjut ke “kata-kata bahasa Inggris jauh lebih mudah diingat dan dimasukkan orang”. Masalahnya, kebanyakan orang tidak bisa bahasa Inggris. Saya sempat berpikir, bukankah daftar katanya tinggal diganti saja, tapi lalu tertulis bahwa “demi interoperabilitas, tidak diinginkan memiliki kamus terpisah per bahasa”
      Ujung-ujungnya logikanya seperti seluruh dunia sudah belajar 26 huruf alfabet Inggris, jadi menambah beberapa kata pun tidak masalah. Padahal di dalam char Wp[2048][4] = […] yang ada bukan kata umum yang cocok untuk pemula, melainkan hal-hal seperti “WAD, BESS, MERT...”. Bahkan ada juga “ORR? AGEE EGAN HAAS!!”, “GAUL FLAM! DRAB!”
    • Saya penasaran, jenis ID seperti ini disebut apa

  • Cerita ini mengingatkan saya pada kejadian lama. Saat sedang sakit, untuk mengalihkan pikiran dari rasa tidak enak badan saya membuat modul mainan untuk aritmetika basis arbitrer, dan karena gampang saya unggah ke CPAN
    Modul itu adalah https://metacpan.org/pod/Math::Fleximal
    Dari hal-hal kecil yang pernah saya buat, saya pikir yang ini pasti tidak akan pernah mendapat permintaan dukungan, tapi ternyata ada. Soalnya saya menyertakan contoh mengubah heksadesimal menjadi kode alfanumerik, dan seseorang mendapat ide cemerlang untuk memakainya apa adanya guna mengubah angka panjang menjadi kode yang lebih mudah dibaca
    Modulnya bekerja dengan baik, tapi fakta bahwa ini masuk ke production di suatu tempat terasa cukup absurd

  • Tulisan itu menekankan agar menghindari karakter yang sulit dibedakan bahkan dalam tulisan tangan, tetapi tabel contohnya memasukkan angka 7. Saya tak terhitung berapa kali mengalami sulit membedakan 7 milik seseorang dengan 1
    Membuat garis silang pada 7 memang membantu, tetapi banyak orang tidak menulisnya begitu, jadi kadang sulit yakin itu 7 atau 1 berserif

    • Tulisan itu memang menyebut “B” (Bravo) dan “P” (Papa), yang sulit dibedakan lewat suara, tetapi “F” (Foxtrot) dan “S” (Sierra) yang terdengar jauh lebih mirip justru tidak disebut
      Keduanya kadang hampir tak bisa dibedakan. Kita bisa memakai alfabet standar NATO/penerbangan (Alpha, Bravo, Charlie, Delta...), tetapi kecuali basis pelanggan sangat dibatasi ketat, itu tidak banyak membantu. Kombinasi seperti ini juga sebaiknya dihindari
      Meski string ID jadi sedikit lebih panjang, jauh lebih baik memaksimalkan kemudahan membaca, mengucapkan, dan mendengar karakter, dan ini menghemat jauh lebih banyak waktu serta kekesalan
    • Saya belum pernah mengalami tulisan tangan di mana 1 terlihat seperti 7. Biasanya I atau l yang tertukar dengan 1
      Saya penasaran gaya tulisan tangan seperti apa yang membuat 1 mirip 7. Garis horizontal atas pada 7 rasanya sudah cukup untuk membedakannya
    • Memang tidak muncul di bagian awal, tetapi di bagian “kamus ambigu visual”, 1 dan 7 memang sama-sama tidak ada

  • Jika memakai huruf besar dan kecil sekaligus, cepat atau lambat Anda kemungkinan akan terkena sistem atau protokol pihak ketiga yang tidak membedakan huruf besar-kecil
    Saya pernah melihat sistem komersial yang membiarkan pengguna memilih ID peka huruf besar-kecil sehingga iD dan id dianggap berbeda, tetapi saat mencari ID yang tidak ada, sistem itu melakukan pencocokan tanpa membedakan huruf besar-kecil dan mengembalikan data yang salah
    Ketika bug ini dilaporkan, jawabannya adalah bahwa itu “fitur untuk kenyamanan”

  • Saat memasukkan nomor seri DLC di Nintendo Switch, tombol untuk karakter ambigu dinonaktifkan di keyboard layar, dan menurut saya itu pengalaman pengguna yang cukup bagus.
    Artinya nomor seri tersebut sejak awal dibuat tanpa karakter ambigu. Saya tidak yakin apakah UX ini tertanam di sistem operasi, atau hanya ada di game yang sedang saya mainkan, Mario + Rabbids Sparks of Hope

  • Pengelola kata sandi open source KeepassXC menggunakan warna agar kata sandi lebih mudah dibaca. Caranya adalah memakai warna berbeda untuk tiap jenis karakter seperti huruf besar, huruf kecil, angka, dan simbol.
    Ini ide yang sangat sederhana, tetapi sangat membantu terutama untuk kata sandi acak, bahkan jika sudah memakai font dengan keterbacaan tinggi

    • Bitwarden juga memakai font yang tidak ambigu dan tiga warna. Huruf memakai warna dasar, angka biru, dan simbol merah, dan itu benar-benar bagus.
      Sulit dipahami mengapa perangkat lunak yang berfokus pada kata sandi membiarkan karakter dirender dengan font ambigu tanpa pembedaan warna sama sekali
    • Di generator kata sandi KeepassXC, daftar karakter yang dikecualikan juga bisa ditambahkan dengan mudah.
      Saat memasukkan kata sandi panjang lewat antarmuka seperti remote TV lalu sadar bahwa l1|I tertukar itu sangat menjengkelkan, jadi saya mengecualikannya sendiri
    • Sebagai orang dengan buta warna, saya tidak suka ide ini

  • Tulisan ini enak dibaca karena membahas masalah yang sering saya temui sehari-hari.
    Setiap kali menulis kode cadangan autentikasi dua faktor di kertas, saya selalu cemas saat melewati karakter seperti o/0, v/u, 5/S. Karena itu saya sengaja menuliskannya dengan sedikit modifikasi agar tampak berbeda.
    Bagian tentang “kemiripan bunyi” mengingatkan saya saat memilih kata sandi Wi-Fi. Saya ingin sesuatu yang tidak ambigu meski dibagikan dalam satu kalimat, bisa dieja bahkan oleh anak kelas 3 SD, dan berupa kata umum yang memiliki beberapa konsonan, lalu akhirnya memilih “vacation”

    • Aturan saya adalah memberi titik di bawah semua angka. Dengan begitu masalah seperti 5/S, 0/O, 8/B bisa teratasi. Pasangan yang benar-benar bermasalah sebenarnya berbeda-beda tergantung tulisan tangan masing-masing.
      Jika masih benar-benar tidak yakin, saya juga menambahkan alfabet NATO/penerbangan [1]. Misalnya kalau ada U, saya mulai dari U lalu menulis Uniform secara diagonal.
      Hanya perlu sedikit disiplin. Saya sudah melakukannya lebih dari 10 tahun, dan belum pernah sekalipun kehilangan kode 2FA.
      [1] Silakan kirim perdebatan remeh tentang perbedaan sebenarnya antara kode NATO dan penerbangan ke /dev/null
    • Sulit dipercaya masih ada orang yang menuliskan hal seperti ini dengan tangan di atas kertas.
      Otak jadi bottleneck-nya

  • Saya suka percakapan seperti ini. Mungkin ini bukan topik yang paling mutakhir atau mendebarkan, tetapi cukup bermakna dan kuat dalam membuat hidup manusia maupun mesin lebih mudah.
    Ini juga termasuk ranah praktik terbaik yang justru tidak disadari siapa pun saat dilakukan dengan baik. Sangat disayangkan bahwa perhatian dan ketulusan pada detail sering dianggap “sudah semestinya begitu” sehingga tidak mendapat pujian khusus

  • Kalau mau menunjukkan kesalahan di artikelnya, pada 9qg6G8B2Z5SIl170O (ariel), nama font-nya bukan Ariel melainkan Arial. Putri duyung tidak ada di sini