Don't Roll Your Own …

Summary

Don't Roll Your Own ... By Susam Pal on 23 May 2026 Among software developers, and especially among those who work on security-sensitive systems, there is a well-known maxim: Don't roll your own crypto. Of course, you can roll your own crypto for learning purposes. But if you are going to use cryptography in software or services that serve others, you must never implement the cryptographic primitives yourself, or, worse, develop your own cryptographic algorithms and use them in your software. I have seen several flawed home-grown RC4 implementations early in my career, with issues like improper initialisation vectors, predictable keystreams and partial leakage of plaintext into ciphertext, putting users' sensitive data at risk. If you are considering cryptography for software with actual users, the advice 'don't roll your own crypto' is sound. You must always use an established, vetted software package or tool to do the cryptography for you. Fortunately, most of the industry does take the 'don't roll your own crypto' advice quite seriously. No major e-commerce site or bank uses home-grown cryptography for its web services. In fact, in regulated domains such as payments, healthcare, government systems and personal data processing, doing so could violate requirements for strong cryptography, possibly leading to hefty financial penalties. I wish there were such a maxim for website design as well. There are many aspects of websites where I think developers should not be rolling their own X, where X is something that matters to users, and yet many developers decide to implement X themselves. Here I present a list of such X. Don't roll your own page scrolling. Don't roll your own link navigation. Don't roll your own text selection. Don't roll your own context menu. Don't roll your own copy and paste. Don't roll your own password field. Don't roll your own date picker. The one that bothers me the most is custom scroll behaviour on websites. I am used to how page scrolling ...