There are many things that seem reasonable to the average rational person, but then there are some that just seem absurd.

First, a little background. Security is not just a playground for hackers and software companies. It seems that way sometimes, but security has become a rather potent industry in its own right since the days of the first well publicized viruses and Windows exploits. So much so that finding and reporting security exploits is now commonly a job rather than an underground, subculture activity. There is a bunch of people who are employed to do this now, and who effectively drive the standards for security by publishing bugs in various products.

Now, whenever something has value of some kind, simple economic principles naturally imply that it can be used in a trade. Security vulnerabilities indeed have certain value. By discovering a weakness in a product that noone else knows about, you stand to gain something if you decide to use it maliciously. If not, you may still consider selling it to someone who will use it maliciously. And if you're just not into that kind of evil, you still have a certain leverage over the vendor that sells this product, because you know more about it than they do. So you could easily contact them and say I found a weakness in your product, which allows people to steal your customers' data. Although I don't intend to abuse this personally, we both know there are plenty of people out there who do, and who work hard to find these bugs themselves. If this weakness in your software should remain intact, and abused by someone, you're gonna be in a lot of trouble. So how about you recompense the efforts of my research and I will hand it over?

As a vendor, this isn't the most pleasant email to get. But after all, this person has found something that is our fault, and we have only ourselves to blame for selling something that has such an obvious weakness in it (or we don't think it's serious and we'll just wing it, hoping noone gets burnt on this). Okay, raw deal for the vendor, but if you're selling something that your customers bought in good faith, and it turns out it could pose a threat to their data, it's definitely your fault.

Depending on how successfully this person is able to negotiate with the vendor, the outcome may be various. But if the [let's call him a] researcher isn't able to come to terms, the next best thing is just to make it public. Like we saw already, a vulnerability has a certain value. If you're not able to claim this in hard currency, you'll at least want the recognition for finding this bug so that you can hone your reputation as a security professional and maybe someone will give you a [better] job.

But there is a problem. As we know from every Hollywood corporation-vs-little-guy story, companies always respond to threats the same way: calling their lawyers. The lawyers always try the same thing: hush it up. So they send out lots of scary documents, trying to shut the guy up. And whatever your legal position is, you'll never win, cause corporations have armies of lawyers (armies of janitors too, actually, armies of everything). So chances are they will successfully silence you and your plan of publishing the vulnerability fails. You don't get any money, and you don't get any credit. The vulnerability remains intact, the vendor, even if they know how to fix it, probably won't do anything about it cause noone is pushing them to.

This is the bizzarre landscape in which an industry, which would otherwise seem absurd, somehow makes sense. These security researchers don't have protection against legal warfare, so there are actually certain companies now that trade in vulnerabilities. They will buy them from researchers and then try to reclaim a profit from the vendor, or even sort of broker the deal without putting the researcher in jeopardy. This way, the researcher can either get money for it, or if that fails, publish it.

Not surprisingly, vendors make a big stink about what they call "responsible disclosure" (ie. telling them first, hoping they don't try to silence you I guess), but the truth is they abhor these things being made public, as Jonathan Zdziarski explains at length.

*

Incidentally, if you're at all interested in security, you should check out some of the fascinating talks on security from various security events. Conferences like DefCon generally publish all the talks online. You'll be blown away by what's actually possible (and not just possible, probably being done right now) and your perception of how secure you should feel online will be changed forever. If you want to be both enlightened and entertained, try Dan Kaminsky, he likes to showboat.

In psychology, the term operant conditioning is used to describe a simple type of learning. The aim is to create a certain desirable behavior by reinforcing (ie. rewarding) it. In the alternate case, an undesirable behavior may be extinguished by punishing this behavior (ie. withdrawing a reward, or actual punishment of some kind).

Psychologists have long studied this behavior in animals in laboratories. A small rodent (apparently this is the their optimal kind of animal) is put into a confined space. The desired behavior (just for kicks) is for the rodent to press on a lever in that space. This behavior is reinforced by releasing a food pellet everytime the lever is pressed. After repeating this experiment a few times, the animal (presumed hungry or gluttonous) will press the lever, eat the food and exhibit no other behavior at all, it will immediately press down the lever again. The behavior has now been taught.

But what if you don't have any rats or cardboard? Well, there's a simpler way. Suppose you live in a house with 4 other people. There is a bathroom you all share that has a lock on the door, but no explicit visual indicator of when it's occupied. So in principle there is no way of knowing whether it's vacant, thus something (another way of checking vacancy) has to be learned in order to make this judgment. Okay, let's set up the experiment.

Behavior to extinguish: Blindly pushing down the door handle.
Punishment: Door doesn't open, it's locked from the inside.
Additional stimulus: Visual cues:
a) the door is either ajar or shut,
b) the lock is open or shut, observed in the crack between the door and the frame,
c) the light on the inside is on or off, observed through the crack between the door and the frame.

Demonstration
The subject approaches the bathroom door, pushes on the handle, only to find that the door doesn't open. For a person occupying the bathroom this is perceived as an attempted intrusion, and the subject is aware of this, having been on the other side before. (In addition, certain norms in society dictate that attempts at breaking into an occupied bathroom are not in good taste.) This causes mild embarrassment in the subject, who offers an awkward apology and leaves. In other words, this behavior is undesirable to the subject, who will attempt to avoid repeating it.

So we have the behavior of pushing down the handle, and a punishment which is the locked door. In order to extinguish this behavior, we have to learn how to determine whether the bathroom is occupied. In basic operant conditioning the door is either always open or always locked, and the response (reinforcement or punishment) will create the behavior that corresponds. In this case, the door is sometimes locked, and we need additional stimulation to achieve the corresponding behavior.

This additional stimulus exists in the form of visual cues. First, we need to establish whether the cues are useful.

The door is ajar or shut

Observation shows that the door is left ajar 60% of the time when the bathroom is vacant. It is always shut when the bathroom is occupied, so this cue will never mislead by correlating an open door with occupancy.
In terms of observability, a subject intending to enter the bathroom will always detect the state of the door being open or shut, because we are sufficiently conditioned to look at the door of the room we plan to enter.

The lock is open or shut

The state of the lock perfectly reflects the state of occupancy at all times. There's no way to lock the door from the outside, and all occupants lock the door.
The state of the lock is observable only when standing right in front of the door. The space between the door and the frame is wide enough to clearly determine whether the lock is open or shut. The likelihood of spotting this cue is 30%.

The light in the bathroom is on or off

Observation shows that the light is on 15% of the time when the bathroom is vacant. It also shows that an occupied bathroom always correlates with the light being on.
This cue is much less likely to be observed, for two reasons. Firstly, it is not as readily visible as that of an open door because of ambient light. Strong ambient light (ie. daylight) will make this cue visible only when the subject is positioned directly in front of the door. Secondly, the incentive for lighting the bathroom differs from that of using a locking mechanism. A lock prevents the occupant from being accosted, which would be a source of embarrassment to the occupant. Therefore, this incentive relates the question of occupancy directly to the question of locking, whereas the incentive for lighting the bathroom is a purely functional one. In other words, the subject is much more likely to look for a lock than to look for light on the inside. The likelihood of detecting this cue is 20%.

The task of learning to determine the occupancy status of the bathroom is therefore defined as the ability to spot and correctly interpret the visual cues. In this case we have several cues to draw the correct conclusion on. The state of the door will always be seen, and has a 60% accuracy rate in terms of revealing occupancy. Then there is the state of the lock, which in itself is enough to make the right determination. Finally, there is the bathroom light, which has an 85% accuracy rate. If this seems like a trivial task to you, you'd be mistaken. Real world observations show that out of the four subjects, two learned the correct behavior, while the other two, even over the course of several months, didn't.

According to the principles of operant conditioning, such a case requires a stronger punishment to extinguish the undesired behavior. In many of the experiments performed on animals, there was an element of electric shock involved. But since I don't have the equipment for it... ;)

So there you have it, a study of operant conditioning purely out of the naturally occurring circumstances in a house. No work at all had to be done to set up the experiment or prepare the subjects. Consequently, no bias could have been introduced by tampering with the circumstances. There's also another added advantage. Skeptics like to make the accusation that laboratory experiments cannot be extrapolated to the real world, because they were performed in an artificial environment. That argument has no stand here.

Another common case of operant conditioning is banging on your tv to make it work. People try it, it sometimes work, so they keep at it.

A local area man was brought up on stabbing charges today, after alarmed neighbors called the police about "sounds of violence" in the adjacent building. Officers arrived on the scene too late to intervene, but found the man in a state of exhaustion, clutching a screwdriver through a glove.

The man did not deny the charges, but upon inquiry, alleged the victim had "evaporated". The police forensic outfit failed to turn up any traces of a struggle.

The case was presumed insoluble until an amateur videotape surfaced, showing the man repeatedly stabbing his refrigerator. The victim is now suspected to have been a large block of ice, alleged to have made "unwelcome advances" toward the man's groceries, according to testimony.

When asked why he didn't simply empty the refrigerator and de-ice, the man stated that course of action could have caused "a diplomatic incident" due to the vast amounts of food products distributed among many owners.

Popular outrage broke out when police officials declined to hold the man. In a press release, the commissioner responded citing "acts of violence committed against elementary particles and their fundamental compounds does not constitute a felony in the greater state of Metropolis". Animal rights groups were soon to renounce the decision, warning that this was setting "a dangerous precedent".

The man was released this afternoon after paying a fine for Indecent Culinary Conduct.

Here's my perspective on it. We all have ideas, some good and some bad. Now it's understandable that people who have invested themselves into a bad idea, especially if they thought it was good, are reluctant to walk away from it. It's painful to have to realize that. But the flip side is that we have to maintain the myth of Santa Claus because, well, so many kids believe in him that we can't let them down. Bad ideas deserve to die for the good of everyone.

The first thing a good idea must have is a real problem to solve. OpenID does very well here. The point of OpenID is to solve our common problem of the internet age: many websites, many accounts, many usernames and passwords. This is probably why OpenID still appears to some people as being a good idea.

Here's how they do it. Instead of keeping track of your accounts on all the sites you're a member of, just let one site keep all your account records (sound ominous yet? it did to me). Now, whenever you want to login to one of your sites, instead of using your username/password for that site, you use your OpenID login, which looks like this: http://username.myid.net. This url is effectively your OpenID provider, ie. the site you use to keep track of all your accounts. So now the site you're logging into sends you to your provider, where you login with a username/password belonging to the account on the provider site, and that logs you into the site you were visiting. So in other words, your account on the provider is the gatekeeper to all your accounts. Sounds simple, right?

I remember when I first heard about this idea years ago. The first concern I had was that in order for this to work, I need a provider to keep track of all my accounts. So I asked myself the question: whom do I trust do this for me? The answer came back: myself. I don't know about you, but the idea of some third party storing all my logins doesn't make me feel warmy and cuddly. As it happens, the open in OpenID means you can choose any provider you want, including yourself. You just set up some php scritps and voila, you can use http://mysite.com as your provider. So basically, instead of storing your accounts in some "account manager" program on your computer, you do the same thing on your server. This is where the concept of OpenID died for me. I don't want to have to depend on my own OpenID provider to work in order to use other sites. I don't want to add a dependency on my ability to login to some other site contingent on the assumption that my own site is available and working properly at all times (which it isn't, I have a little downtime like everyone else).

If you don't want the hassle of being your own provider, you can pick a provider from a list. This is not an attractive fallback option, because now your account on the provider is your key to all your other accounts. If I have an account on some site and I forget my credentials, big deal, I only lose that one account. But if I lose my credentials on the provider, I lose everything.

In theory, OpenID tries to improve your overall security. The hassle of keeping track of accounts is known to us all, and we get around the problem by reusing the same (or similar) credentials on a lot of sites. This is obviously bad for security, because if someone gets your password to one site, they can access all your other accounts that use this password. So security people will always recommend that you use distinct credentials for every account. Suppose you do this, and you use OpenID to alleviate record keeping. Now, OpenID actually works against you. Your account on the OpenID provider is the key to everything. With a different password on every site, you're that much less likely to remember what it was, therefore your account on the provider is proportionally more valuable.

There is a strange irony at play here. Supposedly, the more accounts you manage with OpenID the more useful it is. But on the other hand, the more accounts you manage with it, the more you depend on it, and the more you make it the one gateway to all your online identities for a potential attacker or for abuse by a dishonest or incompetent provider.

Most importantly, however, OpenID's solution to the login problem isn't a very clever solution at all. Typing http://username.myid.net is not a big improvement over a username/password form. My browser already gives me the option to login without typing anything.

Those are my reasons why OpenID is a bad idea and should have died years ago. If you want more, Stefan Brands has an exhaustive laundry list of problems with OpenID.

Something is very wrong here. Right after starting a KDE session everything looks normal.

But after running for a day we have a different story. I'm assuming this isn't the expected behavior (if so I didn't expect it).

This time I specifically took a screenshot to prove it, but I've seen it eat up as much as 1.3gb of my memory, which is rather unnerving.

kwin-kde4        4:4.0.4-0ubuntu1

Bug report.