Jangan Membuat Sendiri …

• Prinsip Don't Roll Your Own ... berlaku bukan hanya untuk kriptografi tetapi juga untuk UI web, dan kita tidak seharusnya mengganti fitur yang sudah disediakan browser secara andal tanpa perlu
• Mengganti perilaku dasar seperti scroll, penanganan tautan, pemilihan teks, salin-tempel, dan semacamnya dapat merusak respons input yang sudah akrab sehingga pengguna harus kembali memikirkan cara mengoperasikannya
• Seperti tautan file dan issue di GitHub, ketika JavaScript mencegat navigasi tautan, terkadang membuka di tab baru justru lebih cepat daripada menunggu diproses di tab saat ini
• Kolom kata sandi bawaan dan <input type="date"> bekerja sama dengan autocomplete, pengelola kata sandi, alat aksesibilitas, dan keyboard seluler, sehingga jika diganti dengan UI palsu fungsinya bisa rusak
• Tata letak dan kontrol formulir yang berubah tiap beberapa bulan membuat pengguna menghabiskan waktu untuk belajar ulang alih-alih bekerja, sehingga lebih baik mempertahankan perilaku default browser yang stabil

---

Penerapan prinsip “jangan membuat sendiri” pada UI web

• Larangan mengimplementasikan kriptografi sendiri adalah prinsip agar perangkat lunak operasional yang melindungi data sensitif tidak bergantung pada implementasi privat yang belum terverifikasi
• Ini bukan berarti tak seorang pun boleh menulis kode kriptografi, melainkan lebih dekat pada anjuran untuk sebisa mungkin menggunakan paket dan alat yang sudah ditinjau dan diverifikasi
• Sekitar 20 tahun lalu, benar-benar ada implementasi RC4 buatan sendiri dengan masalah seperti vektor inisialisasi yang tidak tepat, keystream yang dapat diprediksi, dan kebocoran sebagian plaintext
• Saat ini, situs e-commerce besar atau bank pada umumnya tidak memakai kriptografi buatan sendiri untuk layanan web, dan di area yang diatur seperti pembayaran, layanan kesehatan, dan pemrosesan data pribadi, pelanggaran persyaratan kriptografi yang kuat dapat berujung pada denda besar
• Desain situs web tidak sama dengan kriptografi, tetapi jika kita mengimplementasikan ulang fungsi yang sudah ditangani dengan baik oleh browser dan diandalkan pengguna setiap hari, pengalaman pengguna bisa memburuk

Masalah yang muncul saat mengganti fitur bawaan browser

• Jika scroll halaman diimplementasikan sendiri, respons yang sudah akrab terhadap input mouse, touchpad, dan keyboard bisa rusak
• Jika perilaku scroll bawaan ditimpa, halaman bisa bergerak terlalu lambat atau terlalu cepat, dan scroll dengan keyboard mungkin tidak berfungsi
• Ketika perilaku yang biasa dipakai tanpa disadari berubah menjadi perilaku yang terasa asing, pengguna harus kembali memperhatikan cara mengoperasikan halaman itu sendiri
• Fitur representatif yang sebaiknya tidak diimplementasikan sendiri mencakup navigasi tautan, pemilihan teks, menu konteks, salin-tempel, kolom kata sandi, dan pemilih tanggal
• Saat menambahkan fungsi antarmuka pengguna ke situs web yang dipakai untuk pekerjaan serius, perlu bersikap konservatif dalam memutuskan apakah akan menambah fitur mencolok atau menyerahkannya pada perilaku bawaan browser

Navigasi tautan dan kasus GitHub

• Browser web sudah sangat baik dalam mengikuti tautan, dan navigasi tautan adalah fungsi inti browser
• Jika terasa perlu mengganggu perilaku tautan yang normal, ada baiknya meninjau kembali apakah tujuan yang ingin dicapai memang cukup penting untuk merusak navigasi tautan yang umum
• Di GitHub, ketika tautan file atau tautan issue diklik, fitur besar yang diimplementasikan dengan JavaScript mengambil alih penanganan klik
• Di Firefox atau Chrome, Anda dapat membuka alat pengembang dengan F12, lalu di Debugger atau tab Sources, pilih click di Event Listener Breakpoints bagian Mouse, kemudian klik tautan GitHub untuk melihat perilaku ini
• Di GitHub, terkadang membuka tautan di tab baru lebih cepat daripada menunggu pemrosesan navigasi JavaScript di tab saat ini

Input kata sandi dan pemilih tanggal

• Kolom input kata sandi browser dapat menyediakan penyimpanan kata sandi, pengisian otomatis, dan pembuatan kata sandi kuat untuk akun baru
• Kolom kata sandi bawaan juga memberi peringatan saat kata sandi dikirim melalui koneksi HTTP yang tidak aman, serta bekerja sama dengan pengelola kata sandi, autocomplete, keyboard seluler, dan alat aksesibilitas
• Jika diganti dengan kolom kata sandi palsu, fungsi-fungsi ini bisa rusak, dan jika kolom teks biasa dimasking secara manual, browser, sistem operasi, dan alat bantu dapat memperlakukan kata sandi seperti teks biasa yang terlihat
• <input type="date"> memang tidak secara langsung mendukung pemilihan rentang tanggal, tetapi dengan menyediakan dua kolom input tanggal untuk tanggal mulai dan tanggal akhir, kita tetap bisa mempertahankan pemilih tanggal bawaan browser
• Pemilih tanggal kustom berbeda-beda menurut implementasi; pengguna mungkin harus memperbesar ke tampilan tahun, menekan tombol tahun sebelumnya puluhan kali untuk memilih tahun lahir, atau bahkan tidak bisa mengetik tanggal secara langsung
• Jika widget kalender diperlukan untuk browser yang dukungan pemilih tanggal bawaannya kurang baik, lebih baik menambahkannya sebagai widget pendamping yang memanipulasi field yang sama, bukan menggantikan <input type="date">

Biaya perubahan UI yang terlalu sering

• Mengubah kontrol formulir sembarangan hampir selalu menyelesaikan masalah lama sekaligus memperkenalkan masalah baru
• Jika tata letak dan antarmuka situs web diubah tiap beberapa bulan, sebagian pengguna mungkin bisa beradaptasi, tetapi pengguna yang lebih tua akan merasakan beban seperti harus mempelajari alat baru setiap kali
• Jika banyak situs web terus-menerus mengubah antarmukanya, pengguna harus menghabiskan banyak waktu untuk mempelajari ulang hal yang sudah akrab tanpa manfaat fungsional yang berarti
• Seperti distro Linux yang merombak semua perintah inti dan opsi baris perintah setiap beberapa bulan, atau susunan tombol mesin cuci yang berubah setiap pagi, penataan ulang UI yang berulang adalah pengalaman yang tidak menyenangkan
• UI web adalah alat yang dipakai pengguna untuk menyelesaikan pekerjaannya, sehingga sebaiknya tidak mengganti secara tidak perlu perilaku yang sudah akrab dan stabil yang telah disediakan browser

[kirinonakar]

Sepertinya tidak banyak negara yang memiliki begitu banyak enkripsi buatan sendiri dan program keamanan buatan sendiri seperti negara kita.

[GN⁺]

Pendapat di Lobste.rs

• Saya setuju bahwa scroll halaman tidak sebaiknya diimplementasikan sendiri. Mustahil membuatnya sebaik native, dan pengecualian yang masih bisa diterima paling-paling kasus seperti peta, ketika scroll memang lazim dipetakan ke zoom in/out

  Saya sangat menolak menjadikan larangan mengimplementasikan navigasi tautan sendiri sebagai sebuah aturan. Untuk situs konten biasa, saya memang tidak akan merekomendasikan client-side routing (CSR), tetapi pada beberapa aplikasi justru bisa sangat dianjurkan, dan layanan seperti GitHub ada di tengah-tengah

  Namun tetap harus selalu memakai elemen `` yang nyata agar fitur native browser tetap berfungsi. Aplikasi seperti klien webmail memang cocok memakai CSR, dan GitHub juga sempat membaik saat dulu menerapkannya secara ringan, tetapi pendekatan frontend mereka belakangan ini cukup memburuk

  Masalahnya, CSR terlalu sering diimplementasikan dengan asal-asalan dan tidak dibuat tangguh terhadap kondisi jaringan yang buruk. Browser justru kuat dalam situasi seperti ini, dan optimisasi seperti indikator pemuatan tab atau bfcache juga bisa terganggu oleh CSR

  Implementasi pemilihan teks sendiri mungkin hanya bisa dikecualikan untuk kasus yang sangat khusus seperti aplikasi anotasi di ponsel yang memakai jari seperti stabilo. Bahkan saya ingin menambahkan agar ::selection pun jangan dipakai. Hanya dengan menambahkan ::selection{} ke stylesheet hingga area seleksi jadi tidak terlihat itu adalah desain yang buruk

  Saya tidak setuju dengan larangan membuat menu konteks sendiri. Dalam aplikasi seperti klien email, file manager, atau word processor, item khusus aplikasi memang diperlukan, dan karena browser tidak menyediakan cara untuk memperluasnya, menu kustom sepenuhnya saat ini adalah pilihan yang praktis. Untungnya di Firefox, menu native bisa dipaksa muncul dengan Shift+klik kanan

  Larangan mengimplementasikan copy/paste sendiri bisa saya setujui atau tolak tergantung maknanya, jadi perlu diperjelas

  Saya hampir tidak pernah melihat implementasi field password sendiri di luar demo teknis. Mengganti `` dari password ke text lewat tombol tampil/sembunyikan menurut saya tidak termasuk di sini

  Saya juga tidak setuju dengan larangan membuat date picker sendiri. Saya ingin merekomendasikan kontrol native, tetapi keterbatasan dan inkonsistensinya besar sekali, dan selama 10 tahun terakhir nyaris tidak ada minat untuk memperbaikinya. Kita tidak bisa menambahkan informasi ke picker, dan tindakan memilih tanggal lama seperti tanggal lahir terasa mengerikan di beberapa platform. Contoh: Safari's date-picker is the cause of 1/3 of our customer support issues

  Date picker kustom memang punya banyak masalah aksesibilitas, tetapi bagi pengguna biasa sering kali justru lebih baik, dan sering juga kita tidak bisa memakai kontrol native karena butuh fitur yang memang tidak ada di sana. Untuk pemilihan tanggal sederhana saya lebih suka native karena di browser yang saya pakai bisa diketik langsung, tetapi bagi banyak pengguna native masih belum cukup baik. Rentang tanggal yang dibuat dengan `` dua buah kemungkinan besar akan terasa jauh lebih buruk bagi kebanyakan orang

  • Ungkapan yang membandingkan orang yang membutuhkan pertimbangan aksesibilitas atau yang mendapat manfaat darinya dengan “orang biasa” mudah membuat sebagian pembaca merasa disisihkan. Saya ingin menyorot ini justru karena Anda tampaknya cukup peduli pada pengalaman dan kebutuhan orang yang memakai bantuan aksesibilitas

  • Setelah mencoba sendiri date picker Safari, saya jadi paham betapa terbatasnya ia. Tetapi saya selalu penasaran mengapa situs web mengganti date picker native dengan widget kalender

    Apakah tidak bisa meletakkan widget kalender berdampingan dengan widget native? Memang UI bisa membingungkan karena tampak seperti ada dua cara input, tetapi mungkin itu bisa diatasi dengan label yang tepat, misalnya menandai salah satunya sebagai pemilih tanggal lanjutan. Dengan begitu, orang yang nyaman memakai date picker native tidak kehilangan apa pun, dan orang yang merasa date picker browser kurang memadai juga bisa terbantu

    Saya paham bahwa context menu dibutuhkan di web app seperti alat penulisan dokumen atau pembuat diagram, tetapi saat menu browser biasa hilang ketika klik kanan, itu tetap terasa tidak nyaman. Karena itu saya biasanya mengatur Firefox dengan dom.event.contextmenu.enabled = false. Akibatnya menu Firefox muncul di depan dan menu web app di belakang, tetapi karena menu native tetap berfungsi, ini jadi jalan memutar yang lumayan. Kalau bisa, lebih baik memakai menu bar web app dan tidak mengutak-atik context menu native browser. Tip Shift+klik kanan juga solusi yang bagus

  • Orang yang membutuhkan kontrol yang aksesibel juga orang normal

  • Contoh field password yang diimplementasikan sendiri bisa ditemukan di hampir semua bank di Peru

    Untuk date picker, saya juga ingin memakai native, tetapi dari pihak implementor tampaknya minat untuk memperbaikinya sangat kecil. Firefox punya issue terkait UI pemilih waktu/jam, dan progresnya lambat: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• Ini poin yang bagus untuk web form. Mengandalkan browser adalah cara yang paling sederhana, paling cepat, dan hampir selalu paling konsisten

  Tapi untuk kode kriptografi, ceritanya berbeda. Menulis kode kripto yang benar memang tidak mudah, tetapi bukan tidak mungkin. Dalam beberapa situasi pilihannya terlalu sedikit sehingga membuat sendiri bisa jadi pilihan terbaik

  Yang jadi masalah di sini adalah kalangan ortodoks keamanan yang cenderung menganggap bahwa untuk menulis kode kripto baru Anda harus termasuk kelompok internal mereka. Kalau Anda tidak bisa menunjukkan gelar doktor kriptografi atau pengalaman magang di bawah DJB atau Dan Boneh, Anda dianggap tidak boleh menulis kode kripto. “Untuk belajar” sih boleh, tetapi begitu ingin menerapkan yang dipelajari ke dunia nyata, katanya tidak boleh. Bahkan kadang mereka juga tampak kesulitan mengenali kemampuan nyata orang di luar kelompok mereka. Menariknya, irisan antara ortodoks keamanan seperti ini dan kriptografer sungguhan yang menulis paper tampaknya sangat kecil

  Sekarang ini bahkan mulai melebar jadi seruan agar jangan menulis apa pun dalam bahasa yang tidak memory-safe. Kalaupun 70% kerentanan fatal memang berasal dari sana, apa sebenarnya penyebab nyatanya? Menurut saya sebagian besar masalah muncul karena memakai malloc() atau new eksplisit untuk setiap objek kecil yang tidak ada di stack, atau karena menangani string null-terminated. Jika memakai arena dan slice, masalah seperti itu akan jauh lebih sedikit. Tentu, dalam beberapa skenario berisiko tinggi, kelas bug tertentu memang harus dihapus total, dan pada saat itu memory safety menjadi prioritas utama

  Lalu apa berikutnya, jangan menulis apa pun yang memproses input tidak tepercaya? Jangan menemukan kembali roda walaupun semua roda yang ada berbentuk kotak? Meski begitu, kalau tujuannya menghindari JavaScript yang membengkak dan memakai form yang sudah disediakan browser, saya rasa saya juga tidak akan terlalu mempermasalahkan sampai membuat framework web sendiri

  • Menurut saya dosa asal C adalah ketika melewatkan array, informasi batas atas hilang dan runtuh menjadi pointer

  • Selama ini saya memahami “jangan buat kripto sendiri” bukan sebagai kebenaran mutlak, melainkan peringatan keras. Memang benar bahwa implementasi aman masih mungkin dilakukan tanpa gelar doktor, tetapi tetap membutuhkan pembelajaran yang sangat besar

    Kalau hanya mengimplementasikan spesifikasi dengan sangat teliti, kebutuhannya mungkin jauh lebih kecil. Tetapi kebanyakan software ingin implementasi kripto yang cepat, dan di situlah kompleksitas melonjak besar. Kerentanan Monocypher yang ditautkan juga contoh yang bagus. Tiba-tiba Anda harus memahami bagaimana twisted birational equivalence, titik Edwards, dan Montgomery ladder saling berhubungan

    Kualifikasi seperti gelar doktor membantu orang lain percaya bahwa Anda tahu apa yang sedang Anda lakukan. Audit juga jalur lainnya. Monocypher tampaknya telah diaudit oleh dua doktor dari Cure53. Masalahnya, kebanyakan programmer tidak siap menilai apakah sebuah library kripto aman, sehingga mereka akhirnya bergantung pada sinyal nonteknis seperti kualifikasi atau kualifikasi auditor. Akan bagus kalau ada cara yang lebih langsung, tetapi kualifikasi bekerja cukup baik

  • Bahwa menulis kripto sendiri itu mungkin jelas benar. Kalau tidak mungkin, tidak akan ada library kripto. Intinya bukan apakah itu bisa dilakukan, tetapi apakah kripto buatan tangan Anda atau saya bisa dipercaya dalam lingkungan operasional yang meng-hash password pengguna dan melindungi data pribadi. Saya tidak percaya

  • Di tempat kerja lama, ada kode tua yang memakai MD5 untuk pemeriksaan lisensi, dan karena kami harus memverifikasinya di lingkungan yang tidak bisa menjalankan kode C++ lama, saya harus mengimplementasikan ulang MD5. Saya sempat mencari library yang ada, tetapi tidak ada yang mendukung pengubahan IV

  • Saya tidak punya keberanian untuk membuat kripto sendiri, tetapi menurut saya industri keamanan sekarang agak kelewatan sampai mengatakan bahwa autentikasi sendiri pun tidak boleh dibuat

• Akan menyenangkan jika browser menyediakan field multi-select yang layak dipakai tanpa harus kita implementasikan sendiri

  • Sebenarnya ada, tetapi jelek sekali

• Pendekatan menerima tanggal mulai dan tanggal selesai dengan `` dua buah itu merepotkan dan juga tidak intuitif untuk rentang tanggal. Sesuatu yang secara konsep satu justru dibagi menjadi dua tampilan terpisah yang secara visual tampak tidak saling terkait

  Ketiadaan rentang tanggal hanyalah salah satu dari banyak masalah ``. Misalnya, kita juga tidak bisa mengecualikan tanggal tertentu, sehingga untuk hampir semua layanan reservasi kontrol itu pada dasarnya sudah tidak bisa dipakai sejak awal

  Saya ragu pendapat mayoritas adalah bahwa layak menanggung biaya kecil berupa dua input demi memakai tanggal dengan cara yang sama di mana-mana. Pengguna rata-rata tidak suka field, dan yang lebih buruk dari satu field adalah dua field. Logika “karena sudah familiar” juga kurang meyakinkan. Dalam pengalaman saya, input tanggal native di web justru jarang

  • Saya pernah melihat beberapa situs yang memasang dua widget kalender kustom yang sama-sama tidak bekerja dengan benar, satu untuk tanggal mulai dan satu untuk tanggal selesai. Benar-benar menambah masalah di atas masalah

  • Saya juga tidak setuju dengan bagian tentang rentang tanggal. Rentang tanggal sering saya pakai sebagai contoh kontrol yang secara konsep tunggal tetapi dalam praktik bisa sangat kompleks. Slogan “selalu gunakan kontrol native” justru bisa memperburuk pengalaman pengguna ketika kita sebenarnya bisa menyediakan kontrol yang lebih baik dan lebih spesifik untuk masalah tertentu

    Salah satu fitur berguna dari kontrol tanggal/rentang tanggal yang tidak bisa dibuat dengan native adalah menampilkan harga. Saat mencari tiket pesawat atau hotel, sangat berguna kalau di dalam date picker langsung terlihat hari mana yang lebih murah atau lebih mahal. Dengan kontrol native, untuk melihat informasi itu Anda harus jauh lebih banyak klik atau melihat tabel terpisah, sedangkan kontrol kustom bisa menempelkan metadata seperti itu pada setiap tanggal

    Contoh klasiknya adalah input tanggal lahir. Date picker biasanya default menampilkan bulan saat ini, yang hampir tidak ada hubungannya dengan tanggal yang diinginkan sehingga terasa paling buruk. Di sini kita bisa memakai kontrol kustom, tetapi kombinasi textbox sering kali lebih baik. Itu memang lebih berupa gabungan kontrol native daripada kontrol sepenuhnya buatan sendiri, tetapi poin utamanya adalah tidak ada date picker “serbaguna” yang bagus untuk semua kasus

• Ini kejadian beberapa tahun lalu jadi saya perlu cek lagi, tetapi ada alasan menyedihkan mengapa kami terpaksa mengimplementasikan sendiri alih-alih memakai html5 date picker. UI `` di beberapa browser benar-benar mengerikan

  Implementasi context menu sendiri memang jarang, tetapi saat dibutuhkan, itu sangat berguna. Misalnya jika kita membuat editor diagram di dalam halaman web, saya justru ingin ada custom context menu saat mengklik node diagram agar tindakan yang berguna bisa dilakukan. Tidak bagus kalau semua interaksi dipaksa masuk ke UI klik kiri saja, misalnya harus bolak-balik klik palet aksi lalu klik node

  Untuk sisa item di daftar itu, saya sangat setuju

• Saya tidak tahu bagaimana contoh kriptografi dan masalah perilaku scroll harus dibaca bersama. Keduanya terasa seperti ranah yang sangat berbeda

  Saya setuju dengan poin umum bahwa situs web melakukan terlalu banyak hal. Hanya saja perilaku yang tepat tetap bergantung pada tujuan pengguna dan tujuan situs

  Mungkin pengaturan seperti prefers-reduced-motion bisa punya solusi tengah, misalnya prefers-user-scroll?

  • Tidak ada use case yang sah untuk memakai scrolljacking demi mengimplementasikan area scroll vertikal. Kode seperti itu sejak awal memang seharusnya tidak pernah ditulis

    Tapi ini khusus untuk area scroll vertikal. Jika scroll dipetakan ulang ke perilaku non-scroll, memang ada use case, dan itu tetap sangat bermasalah, tetapi untuk sistem tulisan vertikal pun pemetaan vertikal ke horizontal masih bisa dibahas. Mungkin ada satu-dua use case sah lainnya, tetapi cara implementasinya di dunia nyata biasanya tetap salah

• Saya sangat setuju dengan larangan implementasi scroll halaman sendiri. Di KotlinConf saya mendengar presentasi menarik tentang sulitnya implementasi scroll di Compose Multiplatform for Web

  Salah satu masalahnya adalah browser web mengirim event scroll lebih sedikit dibanding aplikasi native, sehingga algoritme perhitungan arah scroll mereka gagal. Caranya adalah menggambar parabola yang melewati semua titik lalu memakai kemiringan di titik terakhir, tetapi jika titiknya terlalu sedikit, arah scroll justru bisa terbaca terbalik

  Saat melakukan porting dari platform lain atau mengimplementasikan ulang interaksi seperti ini, mudah sekali memulai dengan asumsi yang keliru atau melupakan perilaku “aneh” yang sudah disediakan browser secara bawaan

  • Saya penasaran event scroll itu dipakai untuk apa di aplikasi aslinya sampai harus direplikasi juga di konteks web. Saya agak curiga terhadap pola memakai scroll sebagai input penggerak sesuatu

• Nasihat “andalkan platform” itu benar, tetapi terus mengikuti perkembangan platform itu sulit. Ada hal-hal seperti enterkeyhint atau inputmode yang keberadaannya kira-kira kita tahu, tetapi efeknya gampang terlupa

  Minggu ini tim kami merilis [0] untuk membantu hal itu. Isinya praktik terbaik implementasi dalam bentuk skill. Dokumentasinya juga cukup enak dibaca manusia. Contoh: [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

• Nada tulisannya terasa meleset. Akan jauh lebih produktif jika dijelaskan kapan dan mengapa orang tidak perlu menemukan kembali roda sampai pembaca benar-benar paham

  Tulisan itu sebenarnya menjelaskan alasannya dengan baik, tetapi jadi kurang bagus karena memilih ungkapan dogmatis seperti “jangan buat sendiri”

  Slogan “jangan buat kripto sendiri” pada akhirnya juga terasa seperti doktrin. Siapa sebenarnya para ahli yang katanya boleh memakainya, dan siapa yang mengangkat mereka? Apakah sebelum berkata begitu mereka benar-benar sudah melihat langsung kodenya? Bukankah dari kerentanan seperti Heartbleed kita justru tahu bahwa masalah nyatanya adalah kesalahan yang sangat mendasar?

  • Mereka adalah orang-orang yang mendedikasikan hidupnya pada kriptografi. Tidak ada yang “mengangkat” mereka; mereka memperoleh kualifikasi itu dengan menerbitkan riset yang berguna dan lolos verifikasi dari orang-orang yang memahami bidang tersebut

    Algoritme dipublikasikan, ditinjau, diserang secara terbuka, diperbaiki, lalu distandardisasi. Ini bukan sesuatu yang terjadi di balik pintu tertutup. Paper tersedia terbuka dan kodenya juga terbuka. Anda bisa melihatnya kapan saja. Hanya karena Anda belum melihatnya bukan berarti tidak ada orang yang melihat. Orang-orang memang memeriksa dan berusaha memecahkannya. Kita memakainya karena ia sudah bertahan dari serangan

    Jika solusi yang Anda tarik dari Heartbleed adalah mengimplementasikan ulang OpenSSL sendiri, saya berani menjamin bahwa OpenSSL buatan Anda akan punya lima puluh Heartbleed untuk setiap satu Heartbleed di OpenSSL asli. Bedanya, OpenSSL yang asli ditinjau, diuji, diaudit, diserang, dan diperbaiki oleh orang-orang yang paham. Punya Anda hanya akan tetap salah dalam keadaan privat

  • Intinya bukan bahwa ada pakar sempurna yang tanpa takut tahu cara memanggil AES. Intinya, jika Anda memakai wrapper populer yang aman, bug kalaupun muncul bisa ditemukan dan diperbaiki di satu tempat

    Bahkan jika ditemukan serangan side-channel baru, responsnya bisa dipusatkan di satu tempat. Implementasi buatan sendiri tidak akan mendapat perbaikan seperti itu kecuali Anda mencurahkan waktu penuh untuk terus mengikuti serangan-serangan baru

• Ini terasa lebih seperti keluhan tentang orang yang memakai alat web dengan buruk. Akan lebih menarik kalau juga dibahas use case yang memang sah untuk implementasi sendiri. Dengan begitu pembaca bisa mempelajari sesuatu yang berguna alih-alih model kekanak-kanakan “jangan pernah lakukan sendiri”

  Kemahiran itu berarti memiliki pengetahuan dan keterampilan untuk membuat sendiri, sekaligus kebijaksanaan untuk tahu kapan tidak seharusnya melakukannya

  Meski begitu, saya tetap bisa berempati pada keluhannya. Saya juga punya banyak keluhan serupa. Masalahnya adalah belum banyak upaya untuk mendokumentasikan interaksi web secara cukup teliti dan menyeluruh agar mudah dijadikan rujukan oleh developer web. Ada masalah serius dalam pengetahuan yang berdekatan dengan pemrograman: tidak terdokumentasi dengan baik dan tidak diwariskan ke generasi berikutnya, sehingga masalah yang sama terus ditemukan ulang. Biasanya di dalam industri akan ada perilaku standar dan kumpulan interaksi yang akhirnya menang, tetapi tidak ada yang menuliskannya