| |||||||||||||
SQL injection vulnerabilities in PostgreSQLSQL injection vulnerabilities in PostgreSQLPosted Jun 1, 2006 8:15 UTC (Thu) by nim-nim (subscriber, #34454)Parent article: SQL injection vulnerabilities in PostgreSQL
Both of these problems would have been avoided if there was a development culture where i18n is not an afterthought and software writers validated their code with something else that english ASCII.
The year-2000 bug was a joke, the we've-developped-in-english-ascii-then-turned-i18n-on bug will continue striking for years.
And the worst part people are writing code *today* which assumes one char=one byte, and language=english. Even with a clear example of the consequences of this attitude your article manages to completely skip over this aspect.
i18n is *not* a translator problem.
(Another example of the way our software culture is profoundly conservative is the way GUI writers still think in terms of pixels and 75/96 dpi screens, while Dell and friends are maddly shipping whidescreen LCDs.)
(Log in to post comments)
afterthought i18n and the conservative software culture Posted Jun 1, 2006 17:43 UTC (Thu) by rfunk (subscriber, #4054) [Link] The problem is that the vast majority of Americans don't deal withanything but English (and Anglicized spellings) in their everyday lives, so i18n truly is an afterthought. Worse, most of them can't read or write any other languages either. As for a conservative software culture, part of it is developers who don't (have time to?) keep up with current issues, but there's also a strong culture of backward-compatibility. Enough people have old stuff that developing for the latest and greatest isn't necessarily a good idea. The trick is to be able to develop for both old and new at once, and that's often difficult (requiring even more learning than for just the new) or impossible.
afterthought i18n and the conservative software culture Posted Jun 1, 2006 18:21 UTC (Thu) by nim-nim (subscriber, #34454) [Link] So what ? You don't need to speak other langages to make the effort to learn and understand their technical requirements. Developpers have their software interact with hardware and software with much stranger and complex needs.
The problem is 100% cultural, and I don't mean cultural in the sense americans don't speak other langages, I mean cultural in the sense the software community collectively decided not to tackle some problems. The nationality of the software writer matters very little - they all code from the same textbooks which all present computers as manipulating strings of mono-byte characters. Likewise GUI writers all use the same reference material which assumes screen pixel density is a known stable variable. (Of course the fact a lot of these textbooks are written by people immersed in the american english-only worldview does not help.)
afterthought i18n and the conservative software culture Posted Jun 2, 2006 21:16 UTC (Fri) by tjc (subscriber, #137) [Link] The problem is 100% cultural, and I don't mean cultural in the sense americans don't speak other langages, I mean cultural in the sense the software community collectively decided not to tackle some problems.It's mostly a motivation problem. The people to whom it matters most are apparently not motivated enough, or insufficient in number, to do something about it. The reason that most free/open source software only supports the ISO-Latin-1 character set is because that's what most developer's use themselves. Just wanting to be PC isn't very motivating for most people. The same goes for listening to other people bitch about what one ought to be doing with one's free time.
afterthought i18n and the conservative software culture Posted Jun 3, 2006 8:50 UTC (Sat) by nim-nim (subscriber, #34454) [Link] > Just wanting to be PC isn't very motivating for most people.
I don't see where the PC angle is when it ends up in security bugs (and this is not an isolated case). You're just confirming what I wrote.
afterthought i18n and the conservative software culture Posted Jun 3, 2006 15:59 UTC (Sat) by tjc (subscriber, #137) [Link] Yeah, you're right about the security aspect.I was referring to the big political war that has dogged Unicode. It got ugly. It probably still is, but I don't seem to care anymore.
SQL injection vulnerabilities in PostgreSQL Posted Jun 2, 2006 0:41 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] frankly I want software that doesn't require i18n to be turned on. processing multi-byte characters is slower then processing single byte characters (for a number of reasons). I don't want to pay that overhead for systems that don't need it (and face it, most systems really don't need it, that's why the world survived with ascii for so long)
as for the gui folks, it's not the pixles that are the issue, but the assumption that the gui software has the right to take the entire screen. if they didn't assume that they had the entire screen then the shape of that screen wouldn't matter
internationalisation Posted Jun 2, 2006 2:33 UTC (Fri) by xoddam (subscriber, #2322) [Link] > frankly I want software that doesn't require i18n to be turned on.If the software supports internationalisation at all, then 'just ASCII thanks' is one particular localisation, and there's nothing to switch off. A little extra optimisation for this case wouldn't be a bad idea though. > processing multi-byte characters is slower then processing > single byte characters (for a number of reasons). UTF8 helps with this as long as the vast majority of your characters are in the ASCII range. But UTF8 has its own minor performance headaches, particularly in Eastern Asian locales where a 16-bit character is much more convenient. A significant annoyance and performance issue is when such things as font-measuring have per-character primitive methods that take a UCS32 parameter, and the string must be expanded repeatedly to its individual characters (or cached as an array of 32-bit values). Bringing the whole UTF (8 or 16) string right down to the lowest level might eliminate some of that overhead. > that's why the world survived with ascii for so long The world? For 'so long'? For how long exactly was the *American* Standard the sole character set encoding in *any* non-English-language environment? The earliest Japanese derivatives of ASCII began to be *standardised* in 1969 (JIS C 6220), while the US computing community was still worrying about converting between ASCII and ECBDIC.
SQL injection vulnerabilities in PostgreSQL Posted Jun 2, 2006 7:45 UTC (Fri) by nim-nim (subscriber, #34454) [Link] You would be right but for the internet.
When systems were not interconnected, or the interconnect was slow and limited, local encodings worked fine. Nowadays with dataflows all over the world local-encoding-only systems are the exception not the norm (show me an ascii-only system and I'm almost sure any serious investigation will find users frustrated by its encoding limitations)
And anyway optimising for the ascii case when you end up turning i18n anyway is wrong on so many levels (speed, security) I won't expand on it.
|
|||||||||||||