OK. Now I'm confused:

If you're saying that at some point during the contract you realise it's not working out, pay for the time spent and terminate early then that's fine. If you're saying that you'll pay based on some evaluation of the end product then the criteria for success need to be very clearly defined at the outset so that the contractor can assess the risk of failure and decide whether to take the contract.

I don't have any direct experience, I've just chatted to people who are contractors on other projects in our office and the people who hired them. They have been hired because there's an immediate need and no one available with either the time or skills required. The specification is written as well as it can be under the circumstances but it's never perfect. There are some very good contractors who keep getting rehired because they're trusted to deliver without a lot of management and there are some who are over their heads who get let go early. In the middle are the people who delivered as well as could be expected under the circumstances but the results aren't perfect and that's where it gets messy. There's a hard deadline to be met and so something has to be shipped, if the project gets funded for the next stage then they'll try to fix the bugs later, otherwise they'll stay.

You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code. You could also look over all their code, reject it for an arbitrary reason and then write your own implementation using all their best ideas.

The only way to enforce it would be to have objective criteria such as having the requirements completely specified in fine detail, QA tests to cover all situations and required coding conventions written into the contract before starting but most of the time that's not practical.

"In October 2007, the Swiss Federal Council decided that the distribution of ammunition to soldiers shall stop and that all previously issued ammo shall be returned. By March 2011, more than 99% of the ammo has been received. Only special rapid deployment units and the military police still have ammunition stored at home today.."

Serves me right for not RTFA.

Looks like they're slapping Chip&PIN on it.

Probably a more sensible option, but not the one I'd prefer.

Because you clone a mobile phone. It's trickier with newer GSM phones but not impossible (and there would be suddenly much more incentive to do so)

SMS messages just don't have the level of security a bank would require.

Wow, someone in the governent actually put 2+2 together.

I asked myself why they weren't piggy-backing a proper Public Key Infrastructure onto the ID scheme.

The main issue with PKS12 certificates is actually certifying who the end-user is. That normally involves physically going to someone and showing them some ID. This would elminate that step.

Once you have a .p12 file and that chain of trust then there's a well developed infrastructure to build on.

The government wouldn't be snooping on anything because they'd just be the Certificate Authority who would be verifying your identity as happens when you visit any SSL website.

It would open up many possible applications where you really need to make sure you know who the end-user is.

However my faith in the government getting it right are minimal and they are a bit fiddly to use so in the hands of an inexperienced web user they would probably either be not used or insecurely used.

This is the entire point of the argument. The ISPs are reselling BT Wholesale and have no equipment in the exchanges. As it's set up at the moment any ISP cache would be before it goes down BT's cable and before they get charged.

It requires BT Wholesale to put the CDN in their exchanges which will both cost them money and decrease their revenue. Suprisingly I don't think they're that keen to pay which is why everyone is arguing.