Don't Roll Your Own ... - Susam Pal
Don't Roll Your Own ...
By Susam Pal on 23 May 2026
Among computer programmers, and especially among those who work on<br>security-sensitive systems, there is a well-known maxim: Don't<br>roll your own crypto. Of course, you can roll your own crypto<br>for learning purposes. But if you are going to use cryptography in<br>software or services that serve others, you must never implement the<br>cryptographic primitives yourself, or, worse, develop your own<br>cryptographic algorithms and use them in your software. I have seen<br>several flawed home-grown RC4 implementations early in my career,<br>with issues like improper initialisation vectors, predictable<br>keystreams and partial leakage of plaintext into ciphertext, putting<br>users' sensitive data at risk. If you are considering cryptography<br>for software with actual users, the advice 'don't roll your own<br>crypto' is sound. You must always use an established, vetted<br>software package or tool to do the cryptography for you.
Fortunately, most of the industry does take the 'don't roll your own<br>crypto' advice quite seriously. No major e-commerce site or bank<br>uses home-grown cryptography for its web services. In fact, in<br>regulated domains such as payments, healthcare, government systems<br>and personal data processing, doing so could violate requirements<br>for strong cryptography, possibly leading to hefty financial<br>penalties.
I wish there were such a maxim for website design as well. There<br>are many aspects of websites where I think developers should not be<br>rolling their own X, where X is something that matters to users, and<br>yet many developers decide to implement X themselves. Here I<br>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<br>websites. I am used to how page scrolling responds to my mouse,<br>touchpad or keyboard input. When you override the default scrolling<br>behaviour of the web browser with your own implementation, it<br>'breaks' the page for me. The page now moves too slowly or too<br>quickly when I scroll. Keyboard scrolling may or may not work. You<br>take something I am so familiar with that I don't even think about<br>it, and turn it into something unfamiliar that I now have to think<br>about.
Custom link navigation is another pet peeve of mine. Web browsers<br>can already handle links very well. You could say that this is the<br>whole reason web browsers even exist. Following links is their<br>bread and butter. You shouldn't have to mess with that behaviour at<br>all. If you think you need to, reconsider what you are trying to<br>achieve and if it is really so important as to disrupt normal link<br>navigation. The worst offender I have found here is GitHub. When<br>you click on a link on GitHub, say, a file link or an issue link, it<br>triggers a massive piece of functionality implemented in JavaScript<br>that handles the link click for you. If you don't believe me, visit<br>your favourite project on GitHub using Firefox or Chrome,<br>type F12 to open the browser's developer tools, then go<br>to the 'Debugger' or 'Sources' tab, find 'Event Listener<br>Breakpoints' on the left sidebar, expand 'Mouse' and select 'click'.<br>Then click on a link on GitHub and see what happens.
I'm sure I am not the only one who has noticed that, on GitHub, a<br>clicked link sometimes takes too long to load. Often it is easier to<br>open the link in a new tab than to wait for GitHub's JavaScript code<br>to handle the navigation in the current tab.
A custom password input field is another such hazard. Fortunately,<br>custom password input fields have become rarer over the years. The<br>password input field that comes with the web browser is generally<br>well equipped to handle passwords. It can offer to save passwords,<br>fill them in later and generate strong passwords for new accounts.<br>It can also warn when a password is submitted over an insecure HTTP<br>connection, work well with password managers and autofill, and<br>cooperate with mobile keyboards and accessibility tools. If you<br>replace the browser's password field with your own fake version, you<br>may break all of that. You may also end up using an ordinary text<br>field and masking it yourself, in which case the password may be<br>treated by the browser, the operating system or assistive tools as<br>ordinary visible text rather than as a password, thereby exposing<br>the password in ways you did not intend.
Custom date pickers are another common annoyance. I know that<br>does not help you select a<br>date range. But that is okay. You can provide two date input<br>fields, one for the start date and one for the end date. I am<br>willing to pay the small price of using two different inputs to<br>select a date range if that means I can use dates the same way<br>everywhere. What I am not willing to do is learn ten different ways<br>of...