It’s now effectively impossible to spend a month following IT (and not just) new and not hear of breaches, “hacks”, or general security fiascos. Some of these are tracked down to very basic mistakes in configuration or coding of software, including the lack of hashing of passwords in database. Everyone in the industry, including me, have at some point expressed the importance of proper QA and testing, and budgeting for them in the development process. But what if the problem is much higher up the chain?
Falsehoods Programmers Believe About Names is now over seven years old, and yet my just barely complicated full name (first name with a space in it, surname with an accent) can’t be easily used by most of the services I routinely use. Ireland was particularly interesting, as most services would support characters in the “Latin extended” alphabet, due to the Irish language use of ó, but they wouldn’t accept my surname, which uses ò — this not a first, I had trouble getting invoices from French companies before because they only know about ó as a character.
In a related, but not directly connected topic, there are the problems an acquaintance of mine keeps stumbling across. They don’t want service providers to attach a title to their account, but it looks like most of the developers that implement account handling don’t actually think about this option at all, and make it hard to not set a honorific at all. In particular, it appears not only UIs tend to include a mandatory drop-down list of titles, but the database schema (or whichever other model is used to store the information) also provides the title as an enumeration within a list — that is apparent by the way my acquaintance has had their account reverted to a “default” value, likely the “zeroth” one in the enumeration.
And since most systems don’t end up using British Airways’s honorific list but are rather limited to the “usual” ones, that appears to be “Ms” more often than not, as it sorts (lexicographically) before the others. I have had that happen to me a couple of times too, as I don’t usually file the “title” field on paper forms (I never seen much of a point of it), and I guess somewhere in the pipeline a model really expects a person to have a title.
All of this has me wondering, oh-so-many times, why most systems appear to want to store a name in separate entries for first and last name (or variation thereof), and why they insist on having a honorific title that is “one of the list” rather than a freeform (which would accept the empty string as a valid value). My theory on this is that it’s the fault of the training, or of the documentation. Multiple tutorials I have read, and even followed, over the years defined a model for a “person” – whether it is an user, customer, or any other entity related to the service itself – and many of these use the most basic identifying information about a person as fields to show how the model works, which give you “name”, “surname”, and “title” fields. Bonus points to use an enumeration for the title rather than a freeform, or validation that the title is one of the “admissible” ones.
You could call this a straw man argument, but the truth is that it didn’t take me any time at all to find an example tutorial (See also Archive.is, as I hope the live version can be fixed!) that did exactly that.
Similarly, I have seen sample tutorial code explaining how to write authentication primitives that oversimplify the procedure by either ignoring the salt-and-hashing or using obviously broken hashing functions such as crypt() rather than anything solid. Given many of us know all too well how even important jobs that are not flashy enough for a “rockstar” can be pushed into the hands of junior developers or even interns, I would not be surprised if a good chunk of these weak authentication problems that are now causing us so much pain are caused by simple bad practices that are (still) taught to those who join our profession.
I am afraid I don’t have an answer of how to fix this situation. While musing, again on Twitter, the only suggestion for a good text on writing correct authentication code is the NIST recommendations, but these are, unsurprisingly, written in a tone that is not useful to teach how to do things. They are standards first and foremost, and they are good, but that makes them extremely unsuitable for newcomers to learn how to do things correctly. And while they do provide very solid ground for building formally correct implementations of common libraries to implement the authentication — I somehow doubt that most systems would care about the formal correctness of their login page, particularly given the stories we have seen up to now.
I have seen comments on social media (different people on different media) about what makes a good source of documentation changes depending on your expertise, which is quite correct. Giving a long list of things that you should or should not do is probably a bad way to introduce newcomers to development in general. But maybe we should make sure that examples, samples, and documentation are updated so that they show the current best practice rather than overly simplified, or artificially complicated (sometimes at the same time) examples.
If you’re writing documentation, or new libraries (because you’re writing documentation for new libraries you write, right?) you may want to make sure that the “minimal” example is actually the minimum you need to do, and not skip over things like error checks, or full initialisation. And please, take a look at the various “Falsehoods Programmers Believe About” lists — and see if your example implementation make those assumptions. And if so fix them, please. You’ll prevent many mistakes from happening in real world applications, simply because the next junior developer who gets hired to build a startup’s latest website will not be steered towards the wrong implementations.
Honorific aside, not everyone has two names. A name field has to support free-form Unicode entry to be anywhere near accessible to everyone.You’ll need to go further back in a person’s education history to find the root of the problem. People need to be taught to question their own assumptions and to take the time to seek out more information about a subject before making decisions about it.I don’t believe that tutorials or documentation is to blame for this. In my opinion, the problem is that most people don’t know what questions they should be asking before they begin designing a system that will be used with people other than themselves. If you’re absolutely sure everyone has a given and a surname before you begin coding, then you’ll never stop to question “Does everyone have just one given name? Do some have zero or multiple surnames? What is a name?”
Regarding writing good documentations I recommend the following talk: https://www.youtube.com/wat…Regarding names: Don’t take yourself too serious. Yes, I would have a name like you I would want support for my name everywhere (hey, it is my name!). But c’mon, converting to ANSI works and isn’t always disrespectful. UTF still isn’t everywhere in 2017. Many larger application where written without UTF in mind. Changing something like a charset isn’t a trivial change you just do. There are better examples for things which are going wrong nowadays.A major problem is QA in general: There isn’t QA at all. In the past we tested an application and every change. We don’t do this anymore. Instead we created tools which allow us to deploy as often as we want. In the past you had your deadline like “Feature must be ready to ship until date X”. On date X you shipped a new major release which was fully tested. Today every team can push a new release to clients/customers whenever they change a single line. They don’t do integration testing. They don’t test at all. They just deploy when the thing they were working on seems ready. And if there is a problem, and there will be a problem!, they just fix this single problem from their point of view without a complete analysis and push a new build. The new fix is causing problems with another component? I am sorry, wasn’t tested before. Cycle will start again…That’s the problem! Shipping a new build is too easy for developers. Why should they test? If there will be a problem, it will get reported and then they fill eventually fix it.
Launch and iterate is fine, but security/runtime/QA/bug fixes should run on a separate, tighter loop than the new shiny product features loop (think of regression testing) … After all, software tends to spend way more time in use than in does in development.
I think you’re being dismissive of real world concern of naming problems as if they are just vanity issues. This is far from being the case, and if your name is ASCII-compatible and two words only, you probably never noticed how many issues exists.Let’s start with the fact that while you *could* make my name ASCII-compatible by using «o’» that loses quite a bit of information of how it’s encoded. As I said above, French and Irish know about «ó» but not «ò». The more correct (but not perfect) downgrade would be «o`» but the amount of systems that accept that can probably be counted on two hands, in my experience. I would venture a guess because names like «O’Something» are fairly common in the USA as well as Ireland, and so people remember about those sooner than Italian, Spanish or French names.But what about Japanese names? In which the sound and the characters don’t line up at all? There’s no way to encode those in ASCII, it’s not just a loss of some special character, is a whole lot of information loss.And why do we care about correctness of the names? Because so many places expect you have a name that can only be written one way! Airlines expect that you tell them your name as it’s written on your passport, but then they have their own validation rules that don’t appear to match the ones used by passports worldwide. Some airlines do normalisation of names on both the passports and their records when checking whether data match, but not all airlines use the same normalisation, and this lead to multiple problems for me when flying AirFrance and KLM, because they can’t connect my frequent flyer number, my passport and my ticket all at the same time. In at least one case this almost had me miss my flight because they wouldn’t let me use the priority check-in.And this gets even better in Ireland and UK where proof of address is the way you sign up for things. Credit history and a number of other reporting systems relies on the name and address to be matched; and while some of those do use fuzzy matching to find you, most of them don’t.So no, I’m not taking myself too seriously. I would say it’s you who don’t take people’s names and lives seriously enough.
Just wait until May 25th. After that it will be illegal. The GDPR requires the ability to correct personal data. It also requires the data collection to be sufficient and required. Clearly the use of a honorific (or even any form of gender identity) is not required for most purposes and therefore isn’t allowed to be processed.Will this be top priority for the ICO (and the other authorities) – most likely not. Most likely it will be like making your website accessible being a legal requirement. At least theoretically you could be fined up to 4% of global annual turnover – there is no fine on the disability act.
Its a difficult multi-pronged structural problem. There are a number of factors that accumulate but at its core its an incentives/disincentive imbalance.
The people making the decisions are doing so from a business perspective with whatever risk analysis methods they’ve developed over time (not always formal methodologies). Decisions are made often from an incomplete understanding and the current state of incentives/disincentives favors making compromises where the liability can be handled at a later date.
Very few companies are punished for continued negligence after an initial newsworthy incident, and that newsworthy incident may even increase the demand for some of their companies services.
In addition to this, there can be bias about the importance of various elements of a technical project between technical and non-technical decision makers in addition to a general trend of favoring short term benefits vs long term sustainability, specifically in the area liability mitigation (not always but often enough).
If the incentives/disincentives were adjusted appropriately to necessitate a solid business need for both initially hiring qualified people and providing self-enforcing methodologies during development and a products lifecycle, coupled with having solid, effective, and continuing accountability for incidents and their aftermath; there might be less of this in the news.
I then also wouldn’t have to hear about the $5bn Facebook fine press release that caused share prices to surge (upward).