avs Online

I needed to get semi-authentic Commodore 64 colours for a job, and thought that perhaps someone else needs them too. Here's the Commodore 64 colour palette in RGB as an Adobe Swatch Exchange (.ase) file.

The palette is taken from Philip Timmermann's excellent page on VIC-II colours. The colours will probably look a lot less vivid than you remember, for two reasons: 1) in PAL YUV, the original C=64 colour space, your telly just clipped the oversaturated colours, and this palette here is normalised to fit into the RGB gamut, and 2) if you use this in a CMYK job, there are out-of-gamut colours even in this RGB palette. Given the variety of 1980s family TVs that C=64s were hooked to, probably no-one saw the same colours anyway, so don't sweat it.

It is sometimes interesting to peek behind the references in various reports. Often one will find an entirely different fact that had been quoted. This is a story of one such occasion.

The European Commission are currently seeking comments to a report produced by a telco systems provider, on "Availability and Robustness of Electronic Communications Infrastructures". I was going through the pages, making notes on various missing or poorly commented items (systems monoculture, open source, information systems warfare), when I noticed the single occurrence of the term "open source" in the document. You can find it as Footnote 75 on page 78 of the report. It says (emphasis mine)

77% of subject matter experts confirm that open source software negatively impacts reliability and security. IEEE Communications, Quality and Reliability (CQR), "Proceedings of European Experts Workshop on Hardware & Software," Berlin, Germany, 11 October 2006.

Now, as a practicing open source security guy, I did not buy this. So, I wondered, what does the reference actually say? A quick Google search turned out this page of proceedings, especially these two slide sets.

There is no mention of open source in the slide set that is titled "proceedings", so I turned my attention to the one labeled "issues voting". It appears that the participants of this workshop (17 in total, of which seven came from the corporation that the authored the Commission report), did indeed conduct a poll on how they felt open source affected security. On slide 16, the big question is popped -

Open Source Software contributes to better reliability and security (emphasis mine)

- and the results are in: 77% vote yes, 23 % vote no.

This is exactly why open source is good. If you are curious, you can always go to the source. Hopefully the Commission will, too.

Sitting at RSA Europe, listening to Bruce 'BT' Schneier's keynote. Even though the picture implies handwaving, there was really none: it was Mr. Schneier's usual good stuff - nothing new though, but it was nice to see the man in real life.

In the beginning of his keynote, Schneier discussed whether safety is part of security or vice versa, and (being a security guy) decided that security is a superset of the two. This gives me a rare excuse to blog what I've been lately thinking about the difference between the two, and quality. I try to be brief.

Anyone who has stumbled upon quality engineering knows a bunch of varying definitions for quality. Usually, the definition goes along the lines that if a product fulfills its defined specifications, it is of high quality. (Hence, even a crappy product can have high quality if it was specified to be crap. There are other definitions such as those defining quality as the lack of negative externalities, but I am not using them here, although I like thinking in externalities.)

Then, if you have a look at various papers trying to define security, it is often defined as a system that fulfills its specifications in a hostile environment and under attack - or failing that, fails gracefully. So, security builds on the definition of quality and extends that with a notion of robustness.

What I believe is the key finding here is that safety is also often defined through a system that fulfills its specifications while misused in any foreseeable way - or again, fails gracefully. (What is important here is to note that safety engineering looks at purposeful, if not outright malicious, misuse, not only accidental misuse - which was the reason why Schneier classified safety as a subset of security.)

Therefore, both security and safety are special cases of quality. What's the difference? In most cases, security engineering tries to protect assets that have a (relatively) easily defined financial value, such as data confidentiality or system accessability. Safety, on the other hand, aims to protect wetware, which (even though many economists try) is very hard to place a dollar value on.

There are some crossovers, though. Obviously for example fire damage to physical assets (which is addressed by safety engineering) is easily transferred into megabucks, but what is interesting that security engineering also has areas such as privacy that may affect the flesh-and-blood target in ways that cannot easily be given a financial valuation.

Anyway, this is where I currently am with my thoughts on the relation of security and safety. I'll get back to this when I have thought more of it.

In a recent article in The Economist (excerpt available also as a Politech article), Novell's chief technologist Alan F. Nugent says: "I'm kind of a fan of eliminating anonymity, if that is the price for security." Now, probably all users of Ximian will start worrying (Novell acquired Ximian in August). In the same article, Stanford University "cyberlaw" professor Lawrence Lessig talks about preserving "freedom" by replacing anonymity with pseudonymity.

Lessig claims that the legal hurdles should be set high enough so that governments cannot abuse their power. Hey, come on. This reminds me of the time I was visiting a Swiss nuclear power station. An American kid asked the representative why we Europeans were so worried about Soviet nuclear reactors. After all, "doesn't the government make sure that they're safe", she asked. Everyone rolled their eyes and looked at her, the representative chuckling slightly. The point is: there are good governments and bad governments. In Europe alone, if you look back 50 years, you can find indeed many governments that would have liked to control all electronic communications (had it existed at the time), and not for the public good. It is a serious case of blue-eyed optimism if one thinks that the current democratic governments will stay everywhere this way. And even in the Western world, not all governments can be trusted with basic issues such as human rights (even Mr. Lessig's own government denies human rights from foreigners, as does the Blair government in the UK).

What is wrong with these people? Security does not equal control. Control can be used for providing a certain degree of security, but real security comes from creating a stable environment. Consider a convex surface and a ball bearing that sits on top of it. The ball bearing would roll off if someone would not exert control on it, for example, by holding it still. Now consider a concave cup. You can put the ball bearing inside the cup, and leave it there, and go shopping. When you get back, the ball bearing is still there, even if the cup had been slightly tilted by your cat while you were away.

Now, removing anonymity and introducing "real names", "verinymity" or even pseudonymity is very much akin to trying to fix the convex Internet world by exerting control. The right way to do things would be to transform the environment to a more organic, ecosystem-like, relatively stable form, where small problems will just disappear, much like copying errors in DNA replications are usually harmless. All the best business cases and systems work without control. Business cases that require control, such as Digital Rights Management, face great problems because they need to be constantly exerting control or else the system will fail.

Just let anonymity thrive and make the environment robust. Fix your software so that we do not have viruses. Use spam filters to make spam mail obsolete. Do not create new, controlling technologies that can (and will) be misused to decrease freedom.

Luckily I am not alone with my thoughts. This just in while I was writing this blog entry.