Namespaces Continue to Annoy Me

commentary::namespace

I do not know who this guy is, but I dropped this into a quotes file long ago. Because he obviously had a better handle on the situation long before I did.

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

 There are a couple of other things that I cannot really validate, related to personal names. Such as an ancient note reminding me that a full name can consist of a single ASCII 'a' (doubtless transliterated)', which can occur in Indonesia. That note is really old, does not include a source reference, and I am sadly lacking Indonesian friends.

As a personal aside, I have to mention that you might be sad too, if you both knew how wonderful Indonesian cuisine can be, and lacked a source of ethnic Indonesians friends to mooch off of. That is pretty sad state of affairs, but I digress.

A 2010 post listing 40 potential errors related to just personal names, opened my eyes, and not just to the current madness I am contending with. I don't know the guy, but was impressed enough to drop into the reference system. Falsehoods Programmers Believe About Names is still entirely relevant.

What makes it truly FUBAR is that this doesn't just touch on security fundamentals. It goes to the roots of how authentication and authorization is done. In my experience it is easy to find errors related to this problem, to the extent that it gets a bit boring. So, all you SysAdmins, DBAs, Web developers, etc., please take note

Also, please do not forget about multi-byte character representations v ASCII. There are a lot of problems with libraries that lead to issues with sanitizing input. The world thanks you in advance.

Knock-on Effects of This Problem, as Related to Policy

1. It can effect the usefulness of the entire concept of policy. Requiring username standards such as firstname.lastname can become silly, and be easily seen as silly. Breeding contempt for policy is probably not your goal, so please do not do this.
2.  The effects of item 1 require weird workarounds for the people in the trenches, doing the admin work. Policy flaws have now propagated from users to admins. This is not a win.
3. The combination of 1 and 2 can build into a situation where it is is impossible to audit who has access to what. As different groups will establish different workarounds, recovering from a breach becomes more difficult. That is pretty much the last thing you want.
4. Even minimal security training for new employees becomes difficult, as you are effectively indoctrinating them in the belief that security policy is something to be circumvented.