Don't Roll Your Own …
79 points by susam
79 points by susam
Don't roll your own page scrolling.
Correct. You cannot make it work as well as native. The closest I will grant to an exception is for things like maps, where it is customary for scrolling to map to zoom.
Don't roll your own link navigation.
Strongly disagree with this being a rule. I would instead say: reconsider using client-side routing (CSR). For general content sites, I would strongly discourage it, but for some sorts of apps I would strongly encourage it; and things like GitHub sit somewhere in the middle.
The one part I would insist upon is that you must always use real <a href> elements, so that native browser functionality works. But for some sorts of apps it’s perfectly reasonable to intercept plain clicks and handle the routing on the client side.
Things like webmail clients should definitely do CSR (unless they want to go all in on frames preferably combined with a service worker providing the responses; this honestly is an option, though I’ve never seen it done).
Things like GitHub should be improved by it, and when it was done lightly in the past it was generally improved by it. But it’s been degrading significantly with their new approach to frontend.
The trouble is that far too often it’s not done well, and it’s almost never made robust to bad network conditions, whereas the browser is robust in that way. There are also other details that the browser can do that client-side routing can’t, such as showing that a tab as loading. Also client-side routing gets in the way of some browser optimisations like the bfcache.
Don't roll your own text selection.
Minor exceptions for very specific types of web apps mostly on mobile—some kind of annotation thing where you want to let your finger act as a highlighter; on desktop you’d just use the mouse, but native selection may be too clumsy on mobile.
But other than that, I’d actually go further, and add “never use ::selection”. That feature was just a bad idea, and it’s awful how adding ::selection{} to a page’s stylesheets makes selection invisible. I don’t think any other selector breaks things merely by being mentioned?
Don't roll your own context menu.
Disagree. For various sorts of apps, you definitely want your own context menu items; email client, file manager, even word processor. If the browser provided a way of doing that, it’d be great, but no one else wanted to so Firefox eventually ripped its implementation out, and a fully custom context menu is now your only option, and the pragmatic choice.
Again, context menus that people add are not always appropriate, but there are plenty that are.
In Firefox, Shift+RightClick opens the native context menu forcibly, which is good to still have.
Don't roll your own copy and paste.
I wish for clarification before judging this. I can think of interpretations I would agree with and interpretations I would disagree with.
Don't roll your own password field.
… I honestly can’t remember ever coming across that outside of a technical demo. Well, and ones that add a show/hide button that switches the <input type> from password to text. But I don’t feel that counts.
Don't roll your own date picker.
Disagree. For a couple of reasons, actually. I want to encourage people to use the native one, but it has some distressingly large caveats and we’ve seen very little interest in the last decade in fixing them.
The native control is very limited and inconsistent. You can’t augment the picker with information (which is an extremely common desire). Picking a time long ago (e.g. date of birth) can be abominable on some platforms (e.g. Safari's date-picker is the cause of 1/3 of our customer support issues).
Custom-rolled date pickers tend to be problematic for accessibility, but frequently better for normal people. And a lot of the time you really just can’t use the native control because you need functionality it doesn’t include.
For a simple date picker, I prefer the native one to most of what people will replace it with, because I use a browser where that will let me type in the date, and their replacement may well not. But for a lot of these cases, most people aren’t so well served by the native one, unfortunately.
Definitely a date range will be significantly worse for most people if you use two <input type=date> fields, even if I might actually like it.
this is an informative and well written comment, and i hope this response is not taken in an overly negative way, but
Custom-rolled date pickers tend to be problematic for accessibility, but frequently better for normal people.
contrasting people who benefit from or need accessibility considerations with “normal” people is a good way to alienate some of your audience. my sense from reading most of your comments is that you do care quite a bit about the experience and needs of people who use accessibility accommodations, which is probably the only reason i feel compelled to respond.
I contemplated the word “normal” as I wrote it (and was mildly uncomfortable with it) but decided that precision would take too many words and distract from the point. This may or may not have been correct. Thanks for pointing it out, I’ll reflect more carefully. (I’ve been deliberately striving for conciseness recently, as I tend to excessive and distracting precision.)
It’s unfortunate when you have to trade such things off; much happier when improvements for the long tail also help those not in the tail.
Also I think that it’s only that custom date pickers tend to be problematic, though I’ve never personally tried using Accessibility Tech to use one, or watched someone doing so.
Thank you for the detailed comment. It is always a joy to read your very informative comments. I always look forward to them. On the topic of date pickers, I just tried the date picker in Safari and realised how limited it is.
By the way, I have always wondered why websites replace the native date picker with a calendar widget. Why couldn't the calendar widget sit alongside the native widget? I can see that the user interface may look a bit confusing. There would appear to be two ways to enter the input instead of one, but surely there must be a clever way to resolve that, say, by using proper labels that highlight that one of them is an advanced date picker. That way, I do not have to lose the native date picker that I find quite convenient, whereas people using browsers with an inadequate date picker can still get some relief from the advanced date picker.
I know context menus are deemed necessary for some types of web applications, such as document authoring tools and diagram creators, but I still find it inconvenient when I right-click to do something that the browser would normally let me do and find that the normal context menu has disappeared. So I typically set dom.event.contextmenu.enabled = false in my Firefox configuration. As a result, when I right-click, I end up with two context menus, the Firefox one on top and the web application one just behind it. Although distracting, the native context menu is functional, so it is an okay workaround for me. I would much rather use the web application's menu bar, if one exists, to do such operations, so that the browser's native context menu remains unaffected. The Shift + RightClick tip is a good solution too. Thank you for that.
Custom-rolled date pickers tend to be problematic for accessibility, but frequently better for normal people.
Ouch. People who need accessible controls are normal.
Good points on web forms. Leaning on the browser there is the simplest, fastest, and almost always the most consistent thing to do.
On the cryptography side though… Granted, writing correct cryptographic code isn’t trivial. But it’s not impossible either, and in some circumstances the available options are few enough that writing your own is actually the best you can do.
My problem with the security orthodoxy here is it’s tendency to assert that writing new cryptographic code requires being in their in-group. If you can’t show your PhD in cryptography or your internship with DJB or Dan Boneh, then you shouldn’t be allowed to write cryptographic code. Oh sure it’s okay if it’s "just for learning", but God forbid if you try to apply that new knowledge for real. Some of them even have serious difficulty recognising actual competence from the out-group. (Interestingly, the overlap between the security orthodoxy and actual cryptographers (the ones who write papers), seem to be very small.)
And they’re expanding. Now we should not write anything in memory unsafe languages. 70% of critical vulnerabilities, sure, but what was actually at fault there? I bet most problems happen when using malloc() (or explicit new) for every little object that’s not on the stack, or dealing with null terminated strings. Had we used arenas and slices instead, we’d have much fewer such problems. (I do reckon some high-stakes scenarios require eliminating some classes of bugs altogether. In those cases memory safety is king.)
What’s next, don’t write anything that’s processing untrusted input? Don’t reinvent the wheel, even if the current ones are all square? Though I believe you wouldn’t take much issue with people rolling their own web framework, as long as they avoid JavaScript bloat and use the forms provided by the browser.
I think the original sin for C is arrays losing their upper limit and decaying to a pointer when passed around.
I've always interpreted "don't roll your own crypto" as a firm warning, not an absolute statement. I think you're making a good point that you don't need a PhD to implement crypto safely, but there is still a ton of learning needed. If you're just meticulously implementing a spec, you can get by with much less. But most software wants fast cryptographic implementations and that really ramps up the complexity. The Monocypher vulnerability you linked seems like a good example: suddenly need to know about birational equivalence and how that relates to the Edwards point and Montgomery ladders.
Credentials like a PhD help everyone else trust that you know what you're doing. Auditing is another route: I see Monocypher was audited by two PhDs from Cure53. The problem is that most programmers aren't equipped to determine if a cryptographic library is safe, so we fall back to non-technical means like your credentials (or the credentials of your auditors). I'd love it if there was a more direct way, but credentials work decently.
But it’s not impossible either, and in some circumstances the available options are few enough that writing your own is actually the best you can do.
Obviously it is possible to write your own crypto. If it was not, cryptographic libraries wouldn't be there. The point is not whether it can be done. Everyone knows it can be done. The point is whether I would trust your hand-rolled crypto or my hand-rolled crypto to hash users' passwords and protect their private data in production. I wouldn't.
I wouldn't.
I trust my own crypto code. The trick is to avoid inventing new crypto, and instead implement existing standards. It takes time, it takes care, but it’s doable. I have done it in fact, and have quite a few happy users as a result.
Also, some primitives, like hashes, are very easy. Any student can get it right on their first try, given a suite of test vectors.
Do you trust that you’ll be able to avoid all known timing and side-channel attacks? Because that’s the part I don’t trust myself on: the knowledge is quite deep in places and I have merely dabbled, knowing enough to know that I don’t know enough. If you don’t worry about those hazards, implementing existing algorithms is easy; but it’s not reasonable to ignore them in general-purpose scenarios.
You seem to be someone who is qualified to roll your own crypto. Which is great because someone needs to develop it. So thank you for your service.
But truthfully not everyone is qualified like you. I wouldn't trust myself doing crypto. When people say don't roll your own crypto, they mean that if doing crypto is not your core business, you should leave the matter in the hands of the experts.
i think part of what u/Loup-Vaillant is saying (and please correct me if i’m wrong!) is that they were not, a priori, someone with some inherent aptitude for cryptography. they learned what they know by practical experimentation and implementing things!
that process of experimentation and implementation is all that is really required for someone to “become” a crypto person. i would think that anyone who is already writing code AND is sufficiently motivated to want to write crypto code would be in a position to get there, given the right amount of effort.
There is absolutely nothing wrong with experimenting or implementing it yourself. I have studied crypto and written my own implementation back in the days. It was fun but it also made one thing very clear - getting it right is hard. Timing attacks are no joke.
I fully support people experimenting with cryptography and implementing it themselves to learn or for their own stuff. I just would not use that code in production software. In production, I would use a well-reviewed, widely used cryptographic library maintained by people who do this as serious work.
I ended up needing to reimplement MD5 at a previous job because some ageing code was using it for license checks and we needed to validate in an environment where we couldn't run the decrepit C++ code. I tried finding a preexisting library, but none of them supported changing the IV.
I probably wouldn't dare to roll my own crypto, but it seems the security scene has taken it further to say you shouldn't even do your own auth, which is taking it a bit too far imo.
I know that
<input type="date">does not help you select a date range. But that is okay. You can provide two date input fields, one for the start date and one for the end date.
This is a cumbersome and even unintuitive solution for date ranges. You'd have two separate, visually unrelated views for what's conceptually one thing.
Also, missing date ranges are just one of the problems with <input type="date">. For example, it doesn't allow you to exclude single dates which makes it a non-starter for pretty much any service that offers reservations.
I am willing to pay the small price of using two different inputs to select a date range if that means I can use dates the same way everywhere.
I doubt this reflects the mainstream position on the issue. The average user hates fields—and what's worse than one field is two fields. I'm also not convinced by the familiarity argument; native date inputs, in my experience, are rare on the web.
I've seen far more than one website that used two copies of a custom and poorly-working calendar widget for date range start and end dates, to add insult to injury. ;)
Yeah, I also disagreed with the date range section — I regularly use date ranges as an example of how complex what is conceptually a single control can be, and how the mantra of "always use the native control" can make the experience worse for users if you can offer a better control that is more specific to the problem at hand.
Another example of a useful feature of date/date range controls that can't be implemented natively is pricing — it's really useful when I'm looking at flights or hotels to be able to see what days are cheaper or more expensive. A native control means I need to click a lot more times to see that information, or look it up in a separate table, but a custom control can add that sort of metadata about each date to the date picker itself.
The other classic example here is submitting a date of birth. Date pickers are terrible for this, because they default to showing a single month, often the month of the current day, but that's usually not anywhere near to what you want. You can use a custom control here, but often a combination of text boxes is better. I guess this isn't quite rolling your own control, because it's still using a combination of native controls, but the point is that there's no "one-size-fits-all" date picker that handles all cases well.
Don't roll your own date picker.
I need to re-check this because it's been a few years but there used to be a very unfortunate reason to roll your own date picker instead of using the html5 one: some browsers used to ship UIs for <input type=date> which were absolutely terrible.
edit:
Don't roll your own context menu.
These are rare but super useful when it comes up. e.g. if you are making something like say a diagram editor inside a web page, please do create a custom context menu so I can do useful things by clicking on nodes in the diagrams rather than every interaction having to go through an only-left-click UI like alternating clicking on a palette of actions and clicking on nodes in the diagrams.
Everything else on that list, I strongly agree with.
I don't know how to interpret the example of cryptography and then the issue of scroll behaviour, feels like two very very different type of areas.
But I do agree with the general point of websites doing too much. But that behaviour depends on the user and the goal of the website as well tho.
Maybe a prefers-user-scroll similar to prefers-reduced-motion could be a meet-me-in-the-middle solution?
There is no legitimate use case for scrolljacking to implement a vertical scrolling area. It’s code that should never have been written.
(I restrict my statement to vertical scrolling areas, because there are use cases for scrolljacking to remap scrolling to non-scrolling, though it’s still very problematic, and there are arguably use cases for scrolljacking to remap verticaal to horizontal in vertical scripts, and there may be one or two other legitimate use cases, even though the way people actually implement it is still normally wrong.)
Yea, that all tracks and makes sense, I was thinking wrong there in my initial comment. Thanks for the explanation!
The tone is off. It would be much more productive if people were informed and fully understand when they don't need to re-invent the wheel and why.
The post does a good job explaining why, but it would be much better of with the dogmatic wording of don't roll your own.
I find the whole dont roll your own crypto dogma to be just that. A dogma. Who are those experts that know how to write it? Who appointed them? Have you looked into the code yourself before you say that? Have you looked at exploits like the Heart bleed bug and notice how newbie mistakes they actually are?
Who are those experts that know how to write it? Who appointed them? Have you looked into the code yourself before you say that?
They are people who have dedicated their lives to cryptography. Nobody appointed them. They earned their credentials by publishing useful research and having it scrutinized by other people who know the field.
The algorithms are published, reviewed, attacked openly, refined, and standardized. This is not happening behind closed doors. The papers are public. The code is public. You can look at it whenever you like. That you haven't looked does not mean nobody has looked. People look into and try it break it. We use them because they have survived breaking.
Have you looked at exploits like the Heart bleed bug and notice how newbie mistakes they actually are?
And your solution is what? Reimplement OpenSSL yourself? I guarantee you that the OpenSSL you implement will have fifty Heartbleeds for every Heartbleed you find in the real OpenSSL. The difference is that the real OpenSSL gets reviewed, tested, audited, attacked and fixed by people who know what they are doing. Yours will just sit there being wrong in private.
the OpenSSL you implement will have fifty Heartbleeds for every Heartbleed you find in the real OpenSSL
No it won’t, because I’ll be using a memory-safe language. My implementation will almost certainly be a good deal slower, and I may introduce things like timing attacks, but I won’t have any Heartbleed-style bugs.
Touché. Fair point. Yeah, not Heartbleed-style bugs, but other kinds of bugs. Timing attacks are no joke. I took a course in this field ages ago and even that was enough to make it clear that defending against timing attacks needs incredible care.
They are people who have dedicated their lives to cryptography. Nobody appointed them. They earned their credentials by publishing useful research and having it scrutinized by other people who know the field.
No, they are not. Commonly used cryptographic libraries and other software are very rarely written by researchers that publish invent algorithms. Some algorithms have even been published without s sample implemented POC.
Cryptographic software we use are either community driven efforts or products developed at large software houses like Google, Microsoft, Apple, Oracle, etc.
My point is that someone had to start these projects. Someone had the initial initiative to write their own. Who gave them that legitimacy to start with? Why were they not subject to that silly dogma of "do not roll your own"?
And your solution is what? Reimplement OpenSSL yourself?
My solution, which really should be anyone's, is simply know what you are doing and have technical knowledge of the software you use. Understand the risks and the tradeoffs. Everything is a tradeoff. Of course I use OpenSSL because the benefit of it outweighs the associated risk I incur by using it.
Relying on some mystical god like experts that are somewhere in their ivory towers and write code that would be unattainable for a mortal like me and you... That is what always backfires spectacularly. It's not even amusing anymore.
Take the example of the heartbleed bug. How do you reconciliate their claims of people that "earned their credentials" with a blatant beginner mistake like that? Where did all of their credentials gone all of the sudden? It certainly didn't past through a basic introductory C programming course for absolute beginners. We all make mistakes and we are all fallible. Let's stop this silliness of fanboying around some allegedly u touchable people. Certainly the code speaks for itself regardless of who have written it...?
I don't know if I understand what you are getting at. There is nothing in your second comment that I disagree with. I found myself nodding along with every sentence you wrote. So apparently we agree.
But in your first message, you objected to this:
I find the whole dont roll your own crypto dogma to be just that. A dogma.
So which is it? Is it dogma? or is it just best practice? Because you use open source crypto libraries yourself, right? Why? Because of dogma? Or because it is the sane thing to do? What exactly makes your recommendation to use crypto libraries "best practice" when you say it but "dogma" when TFA says it?
"Best practice" is the dogma. Best practice according to who? For whom?
I use specific software because I know what it does, and how it does to the extent I find reasonable and practical. I have made the decision myself. Not because someone online decided that this or that is a best practice.
I think the advice in the article is spor on, but the tone is silly IMO. I avoid using overcomplicated costum html widgets, because I understand the advantages of using reliable browser native functionality. Not because of an arbitrary principle such as "don't roll your own".
The point isn't that there are flawless experts who know how to invoke an AES call without fear. Rather it's that if you use a popular wrapper that is things safely, when it has bugs those can be found and fixed in one place. When new side channels are discovered those can be found and fixed in one place. Anything you did yourself only gets there improvements if you spend full time listening for new attacks.
This is a rant about people using the tools of the web poorly. It would be more interesting if you tried to engage with the use-cases where it makes sense to implement things yourself, that way people can learn something useful rather than creating a childish model in the reader's head of never doing things yourself.
Mastery is having the knowledge and skills to roll your own, mixed with the wisdom of knowing when (not) to do so.
With that being said, I'm sympathetic to your complaints, as I've shared many myself. I think the problem is that there hasn't been much of an effort put into thoroughly documenting web interactions exhaustively in a way that is easily referenced by web developers. There's a serious issue in how programming-adjacent knowledge fails to get properly documented and transferred to newer generations, so they end up rediscovering the same problems over and over. Usually within an industry a standard set of behaviors / interactions will emerge victorious, and nobody will bother writing them down.
Don't roll your own page scrolling Hard agree on this one, heard a very interesting talk at KotlinConf where the speaker outlined the difficulties they had with scrolling in Compose Multiplatform for Web.
One of the issues was that web browsers send over less scroll events than native apps, so their algorithm for calculating a scroll direction failed (they "draw a parabola" through all points and use the slope at the last point, which with too few points can result in a reversed scroll direction).
When porting things from other platforms or generally reimplementing these types of interactions, it's easy to start out with false assumptions or forget some "odd" behaviours that browsers ship by default.