ID Cards - Ha Ha Ha Ha Ha

Are they politically suicidal??? They have now abandoned everything about the ID scheme that they could possibly have found useful, either on the theory that they are sincerely trying to prevent a few dozen people a year dying in a terrorist attack, or the theory that they are just snooping authoritarian scumbags. And yet they keep enough of the scheme in place that it remains an easy political fact to frighten the voters away from them with? It makes no sense for anybody.

They would be better off, for their own sake, abandoning the scheme entirely, and letting it stand for decades to come as a warning to Labour or Conservative governments never to try such a thing again, as the poll tax was the Conservatives' contribution to Great Cautionary Tales About How Much The Electorate Will Stand For.

This is like Iraq, isn't it? An emotional monkey trap that the perpetrator/victims just cannot withdraw from, even though it lies within their power to do so?

I'm really happy to see this start to die. The disgraceful idea of foistering these onto the british people by way of passports, perhaps the only way they would have been at least partially successful in signing people up.

It will / would've been interesting to see the mass protests against this.

Now we just have to make sure it dies permanently.

Tom. Sorry, but I'm shocked at your statement about linking databases. Linking databases is in fact extremely easy! Step 1) Ensure the nuts and bolts and data structures of the databases are identical Step 2) ensure each record of each data base carries a unique database key, e.g. database 1 has record keys A0000000000, database 2 has keys B0000000000 etc. Data merge/de-merge is almost seamless. Perhaps you have experience of linking two independently evolved databases together with different data structures? That is more difficult, but still overall, easy to achieve.

I say the criminal government is simply employing the drip-drip method to have their ID card goal realised. ID cards and biometric data must be stubbornly refused. In cases (which are rare and massively over publicised) of ID theft, it should be the fat bloated corporations that cover any personal loss a victim may experience.

I refuse to have my liberty taken away from me or the liberty of my children and their children etc., so that corporations do not have to cover any losses (by having to set up investigative units) to identify and prosecute the few ID thieves who are already determined and organised criminals. Nor do I accept the outcome that the Govt and corporations greater ease with which to spy on me and in the worse case scenario use my 'data' for political and murderously political means, which having studied the utterly perverse way the British and US governments have conducted themselves over the last 100 years or so I fully believe they will use this data for that purpose.

Imagine if we had RFID cards, the government would magically be able to ‘produce’ data streams ‘proving’ those accused of the 7-7 bombings had indeed taken the precise journey mentioned in any the govt narrative of the event. This is the point. Computer data is grossly easy to synthesise. As proved in the voting frauds in the last 2 US elections via/ electronic voting machines. The ID card isn’t the full stop at the end of the sentence, it’s the comma on the way to a whole string of other unpalatable methods such as PAPERLESS VOTING., a CASHELSS SOCIETY. RESIST ALL STEPS to these conclusions. The only result will be a massive fraud under Fascism.

The only words we should accept from these crooks and crims is "There will be no ID card. We will ensure that our foreign policy does not engage in economic slavery and physical slaughter to ensure that we do not need to undertake state terrorism to justify that very economic slavery and physical slaughter"

Excellent news on this. As an Irishman living in the UK ( and paying against my will for an illegal war) I can now tell them to shove their ID cards, seeing as how I will no reside on none of their databases. I only hope the rest of the this fiasco can be scrapped so no one else has to have this Orwellian nightmare foist upon them.

Perhaps you have experience of linking two independently evolved databases together with different data structures?

Er, yes. In fact, I do very little all day except deal with the fallout of linking large independently evolved databases together, which is why I know it's not extremely easy at all. In fact, in another window I'm trying to figure out which of four databases is causing a major headache at work - to whit, which one hasn't got the information the other three have got. This is not proving easy. They all cost a lot, they all contain millions of rows of data, they are all run by different people, three of them were put in by external contractors who have mostly sodded off, and I think they all run different back-end software. This is, however, trivial compared with what Reidy and the boys are proposing.

Luckily, I know Perl.

Guys, I work as a DBA in my company and if you say linking 2 databases together, over the wire, is easy then you are talking out of your arse.

For a start you have the problems of maintaining a secure 24/7 network connection between the databases, one which can handle the throughput of X amount of transactions per minute from 9AM - 5PM. Tell me, do the government have a secure intranet that can do this? One that has backup and failover that works?

Up here in Scotland we have HealthNet, but I am not sure if it is secure.

Secondly you have to ensure that registration data is created in an atomic transaction. You can't have half of a ID card holder's info persisted on one database but the other half missing, can you? Doing this on linked servers spread across the land - well rather you than me mate.

Thirdly you have to ensure that any errors occurring in the above are logged and raised to the relevant administrator(s) and dealt with promptly. Given my dealings with PA consulting and SEMA I'm not confident this will be the case..

Tom. More detail is needed before specific solutions to your problem can be suggested. I'd be willing to throw a few ideas your way if you could tell me more about the data structure and the db's your working with. You must have a key field which spans all db's. Please say yes.

Otherwise, you may be able to get some inspiration from the case studies by a company called legacy software (NSC group) {URL: http://www.legacysd.com/?section=Case_Studies} and formally send the bods there some request for help - with the suggestion of course that you would use their services at a later date ;) hehehe.

Anyway, the government, with the knowledge of what all these 'split' databases would be used for, i.e. essentially their policing (which these days = political) needs, they would streamline the databases with future encorporation in mind.

The point is: The STRUCTURE of the proposed government database isn't particularly disturbing, but that there WILL BE a database and what it will be used for, I simply cannot believe any of the greatest collection of crook and crims with the shamelessness to walk through the corridors of Westminster, say on the issue, knowing their history.

If I had my way I'd totally destroy the police database. They simply cannot be trusted to erase info of innocent victims (as has been proved already).

Where is V? We so desperately need him.

I echo Andy's comment saying he wants his country back. So do I from these riff raff that passes off as our representitives.

Scott.

I'm rushing right now but what your talking about isn't the same as the government plan. If the db's are created for merger or access along the tentacles of the civil service that that automatically kills problems.

It will be easy for the Govt to merge db's because all it has to do is import them into a new front end - a super db if you will. This is why the Govt are so insistent on acquiring biometric data because it will allow the rapid flow from one db to the other.

In the hopeful event they can't get this data, the govt won't give a damn if different records become linked. Who will know? Nobody will be able to independently scrutinize it. It will also give them the 'incompetence' excuse next time they execute people by firing clips of bullets into the back of their skull.

Backups:
One would design a db of this nature to automatically send multiple copies of each record accessed to a buffer for modification and archiving later on.

I also have a wee bit of info on both the size of the general problem, and the likely specific systems.

The govt does indeed have a secure network for this kind of stuff - how do you think DWP systems work? It's all managed (databases, servers, networks) by EDS on *real* iron (DB2 plus z/OS).

But thinking it's a matter of linking A with B using foreign keys is a bit ambitious. This was the heart of the original proposal - the NIR was to be a set of foreign keys to all govt databases (which is why the "what's to be on the card?" question was a bit pointless - it doesn't matter if your genetic info is there if there's a foreign key to the NHS db where it normally lives).

Now they're going to have to rely on linking keys in the source DBs, by which I assume they're probably going to rely on NINo. Which isn't great once you step outwith DWP's control, and it becomes the honeypot that SSNs are in the US. So there's no overall glue of the NIR, there's no clean data source (the deduping work alone fills me with a sense of horror), and HMG are still expecting it to come in within original budget.

Even given the rather nice capabilities of Ascential, it's still going to be non-trivial.

(sidenote - I've *never* seen a political upside for ID Cards - it was a suicide mission from day 1)

As the title notes: Ha Ha Ha Ha Ha
(not leaving details for 'not getting fired' reasons)

EDS - rofl. I've got a tidy bit of information on those bastards tucked away in the memory hole, awaiting a time to splurge (yes, it's DWP related, yes, it's a costly IT fuckup).

Thanks for the comment, Anonymous. I suggest checking out SpyBlogs advice to whistleblowers - we don't want people getting the tin tack just before Christmas for posting on here.

It may not be technically intractable (though I doubt it would run smoothly and the government's record on I.T is not good) I think the more important issues revolve around that the justifications that the govenment cite for introducing such a scheme are fraudulent. The winners will be the contractors and the collectivists who don't like the idea of individual freedom from the control and gaze of the state.

Tom highlight no2id in his original post and that is a good organisation to join. I am guessing that most of us are professional people and it will be interesting to see how many of "us" are prepared to stand up and fight this (expensive)nonsense when the time comes.

How many good uses are there for the billions that will be poured down this drain?

If I was wealthy I could stand a few months of porridge to protest against this, but what will we who are not wealthy do when push comes to shove?

Oh thank God. Now I see that all the problems I've had with implementing, and more importantly maintaining a data warehouse of information from disparate sources were all imaginary. Not.

I'm stilling wiping away the tears of laughter from the thought of the government trying to 'Ensure the nuts and bolts and data structures of the databases are identical'. I can guarantee they won't be. So your game plan would be to rewrite three gigantic and disparate databases from scratch, and what...? Transform and import the records of millions of people? Rewrite the client applications for all three databases, creating amazing levels of disruption across goverment departments? If that was the approach to take, why not just go ahead and create a unified database, as you're creating all of the problems with none of the benefits.

I'm sad to say that the attitude of certain managerial types echoes yours precisely, one of the many reasons government IT projects always fail or are at least heavily delayed and ruinously expensive.

News flash. It doesn't work like that in the real world.

Oh thank God. Now I see that all the problems I've had with implementing, and more importantly maintaining a data warehouse of information from disparate sources were all imaginary. Not.

I'm stilling wiping away the tears of laughter from the thought of the government trying to 'Ensure the nuts and bolts and data structures of the databases are identical'. I can guarantee they won't be. So your game plan would be to rewrite three gigantic and disparate databases from scratch, and what...? Transform and import the records of millions of people? Rewrite the client applications for all three databases, creating amazing levels of disruption across goverment departments? If that was the approach to take, why not just go ahead and create a unified database, as you're creating all of the problems with none of the benefits.

I'm sad to say that the attitude of certain managerial types echoes yours precisely, one of the many reasons government IT projects always fail or are at least heavily delayed and ruinously expensive.

News flash. It doesn't work like that in the real world.