Update 3/11/2023: Kami meralat beberapa kesalahan ejaan dalam artikel ini. Selain itu, salah satu sponsor mengonfirmasi kepemilikan Stafbook atas layanan Hidentty. Artikel ini membahas tentang kontroversi yang baru saja muncul tentang Securivotes dan Hidentty. Karena beberapa teman saya yang mendukung, dan tak sedikit yang menolak, soal sistem ini. Sepertinya kali ini saya perlu memihak kepada salah satu dari mereka, berdasarkan sudut pandang yang objektif dan netral. Saat ini, ada beberapa masalah perlindungan data yang masih belum diselesaikan oleh kedua situs tersebut, yakni: 1. Informasi kepemilikan website/layanan yang tidak jelas (Securivotes). Simpel. Data WHOIS sengaja disembunyikan, dan kedua situs tersebut masih belum terdaftar PSE. Tapi mereka masih meminta data sensitif seperti NIK. Jadi, siapa yang bisa dipercaya? Data pemegang untuk situs Hidentty baru saja ditambahkan beserta Kebijakan Privasi mereka. Menurut informasi tersebut, situs ini dimiliki oleh PT. Stafbook Teknologi Asia. 2. Proses hashing NIK yang masih TIDAK AMAN. Situs Hidentty memiliki penjelasan resmi mengenai cara kerja teknologi mereka, terutama soal bagaimana cara mereka membuat hash ibarat kode unik yang dapat dimasukkan ke dalam Securivotes dan aplikasi lainnya. “Bagian mana yang tidak aman, mas?” Bagian di mana para pengguna harus mendaftarkan diri menggunakan akun Google, dan hanya akun Google. Artinya, hash yang berhasil dibuat tetap akan dapat dikaitkan kepada pemilik oleh 1 (satu) buah NIK dan 1 (satu) akun Google. Dengan kata lain, jika suatu saat situs Hidentty berhasil dibajak atau mengalami kebocoran data, para peretas dapat mengontak alamat Gmail dengan mudah hanya dengan mencocokkan nama dan NIK dengan hash di dalam database Hidentty yang mengalami kebocoran data, untuk kegiatan-kegiatan seperti phishing atau pengambilan akun lain secara paksa. Waduh, ngeri sekali! Oh iya, hal ini juga belum termasuk fakta bahwa situs Hidentty masih berpotensi mengumpulkan nomor NIK yang belum terenkripsi (lupain soal HTTPS seperti cara kampanye Google, deh!) Meskipun iya, mereka masih menyimpan data tersebut dalam format terenkripsi (alias sebagai hash), data NIK yang tidak terenkripsi ini masih dapat dicegat dalam sisi web server, dan masih dapat dibocorkan dengan membocorkannya ke dalam log sistem (alias console.log("NIK: " + nik) (#- )). Makanya, mayoritas aplikasi hash generator yang menggunakan blockchain, seperti alat pemulihan kunci privat berbasis BIP32/BIP39 dan Bitcoin paper wallet sama-sama merekomendasikan untuk: Mematikan koneksi internet saat menggunakan aplikasi ini Menggunakan sistem operasi yang bersih (tanpa ada program tambahan) untuk menghindari aplikasi malware dan sejenis untuk menyontek kata sandi dan hasil enkripsi Tidak merekomendasikan untuk menyimpan hasil dalam bentuk text/HTML/PDF Tidak merekomendasikan untuk mencetak hasil kepada printer di dalam jaringan/LAN (alias via AirPrint, IPP, SMB, dsb.) Dan dalam kasus ini aplikasi Hidentty tidak bisa dipakai dengan cara-cara di atas, karena proses verifikasinya pun tetap dilakukan di dalam server mereka. Dan satu lagi, hash yang diberikan oleh Hidentty kemudian akan dikemas menjadi sebuah JSON Web Token (JWT), yang artinya dalam sistem ini, hanya situs Hidentty.com lah yang berhak membuat dan mengecek apakah token-token tersebut valid. Hal ini bertentangan dengan salah satu prinsip blockchain, yaitu data-datanya dapat dibuktikan keabsahannya oleh siapapun termasuk pihak di luar Hidentty. Di satu sisi, hal seperti ini dapat menjamin integritas dari hash tersebut bagi aplikasi-aplikasi yang menggunakan Hidentty, hal ini juga berarti masyarakat tidak dapat membuktikan bahwa hash tersebut telah diproses dengan cara yang wajar dan sesuai dengan prosedur. Dan jangan-jangan, ada data selain NIK dan salt yang disisipkan oleh mereka di dalam hash ini. 3. Komitmen keamanan suara yang tidak setara dengan komitmen keamanan pemilik suara. Salah satu hal yang juga perlu diperhatikan adalah, Securivotes menjamin bahwa suara voting mereka akan dikawal secara transparan dan ketat berkat teknologi blockchain, dan dalam hal ini mereka menunjuk Polygon sebagai sistem blockchain yang dipakai. Namun, apakah mereka juga berjanji bahwa data pemilik suara juga aman? Sepertinya tidak, karena mereka lebih memprioritaskan "keakuratan data" dan marketing "yang tak tertandingi" seperti tertulis: Securivotes merupakan solusi survey unggulan yang menggabungkan teknologi blockchain yang aman dan transparan dengan antarmuka yang intuitif, memastikan keabsahan dan keakuratan data serta memberikan pengalaman survey yang terjamin keamanannya kepada semua pengguna. Lembaga survey perlu menggunakan layanan Securivotes karena platform ini memberikan jaminan keamanan data yang tak tertandingi melalui teknologi blockchain, menjaga integritas hasil survey dengan transparansi yang tinggi, serta menyederhanakan proses survey melalui antarmuka pengguna yang intuitif, sehingga menghasilkan data yang lebih dapat dipercaya dan akurat. Namun, bagaimana dengan Hidentty dan kebijakan privasi barunya? Mereka memang berjanji untuk: Hanya mengizinkan personel tertentu dengan prosedur pengamanan ketat untuk melihat dan memproses data Anda Melakukan penghapusan akun dan data pribadi jika diminta Namun, implementasi langkah-langkah pengamanan data pribadi dari kedua pihak tersebut masih belum dapat dibuktikan secara publik. Salah satu dari bukti tersebut dapat berupa whitepaper, baik dari Securivotes maupun Hidentty, yang mendeskripsikan keamanan yang tak tertandingi ini. Bahkan WhatsApp, meskipun dengan segudang kontroversinya (karena dimiliki oleh Facebook yang terang-terangan membagikan data untuk para pengiklan) juga mempublikasikan whitepapernya tentang bagaimana percakapan sesama akun itu diamankan sedemikian rupa. Sekian pendapat saya saat ini. Nanti kalau ada yang kurang, bisa ditampung dulu ke kebun digital ini sebelum diliput ke sini. Dan satu lagi, bagi mereka yang percaya bahwa seluruh internet harus terdesentralisasi, kami percaya bahwa desentralisasi tidak akan terbentuk tanpa sentralisasi, dan tanpa sentralisasi, desentralisasi tetap tidak akan bertahan hidup.

A week after we announced the new release of our site, we have finally added support for: oEmbed: Still the most basic ("type": "link") kind of oEmbed, so don't expect for fancy blockquotes or iframes to pop up when embedding from our site. GitHub commit 5103064 Open Graph, Twitter, and other SEO meta tags: GitHub commit 0deab0b Cover/Featured Images, because some of our blog posts, like this, used this feature to give some context to the post content. GitHub commit fc79861 We also changed our emphasis colors from blue to magenta (or officially "fuchsia" in our color palette) and violet, for bold and hyperlinks, respectively! A throwback to the days when Reinhart, as a consecutive class secretary, used magenta and violet whiteboard markers to write announcements to make it stand out from other, teacher-used marker colors (black, blue, red, and green)! ...or maybe not just for announcement, like *that* mobile game concept heavily inspired by Snapchat. Anyway, we have also fixed our sharing integration, which you can learn more on commit 773b8fa. TL;DR: No more random \n or ${titleAndDescription} appearing in the shared content. The latter was originally used for our Astro-based webapp, though. And lastly, we're committed to further improve our blog content caching process as well as optimizing our images for use in our home page. That why, current Lighthouse results shows that our home page now require shorter time to render all the resources, but with a consequence of higher Cumulative Layout Shift (CLS). That's all for now, back to work. Things that are currently prioritized so far are: Reimplement Pingbacks and Webmentions Encouraging people to "comment" directly through Webmentions Reimplement Search Reimplement RSS and Atom feed