There are no software 'glitches'

I led the team that developed the fraud detection software for the largest online auction house in the world.

Scammers sold products, did not deliver them to paid customers, then dropped off the site.  The perp then changed every identifier — name, address, credit card, phone, literally every ID — and rejoined the site.

Fraud detection software was blind because there was nothing in common between the bad guy and the newly listed same bad guy.  Neural nets were useless; there were no patterns.

This was a high-profile deal.  It was front-page national news for months.  The Secret Service, the FBI, about every fraud detection company was trying to solve it.  They could not.

We delivered a fraud technology that stopped auction fraud in its tracks.  The auction site publicly stated such, noting it in its annual report.

We know a little bit about fraud, cyber-security, computer programming, and "glitches."

Software is really stupid stuff.  It does not go off on its own, has no mind of its own, and there is no intelligence anywhere in code.  It performs instructions and does them over and over, exactly the same every time, no matter what.

Until something changes.

Something changing is not a "glitch."  It is a change.

Software does not wake up in the morning and suddenly shift 6,000 votes from candidate A to candidate B, as in Biden.  An electrical impulse hitting from that outdoor lightning strike does not make code do something different.  It may fry a hard drive, but it does not change vote counts.

Software leaves tracks.  These are called log files. 

This is a little geeky, but software runs on an operating system.  You have one on your phone, that thing that updates itself right in the middle of the phone call you need to take.

Operating systems need to track everything they do, so they write automatically to a log file for everything that happens.  The software vendor usually uses these log files to see what happened, when something that was not expected did happen.  Log files are really useful, and most serious applications use them.

Log files are huge.  They are really ugly.  If you saw a log file, it would look like thousand pages of random numbers and letters.  It would mean nothing...to you.

To a system that reads log files, it would mean everything.  A log file is the equivalent of having a social media post for every one of your eye blinks, heartbeats, finger movements, 24 hours a day — you get the picture. 

You can screw around with log files and modify them, but it is really hard.  It also leaves tracks, as any change to a log file is written to — you guessed it, that log file.

Some applications run on very constrained machines and do not create log files.  To create them is to eat up dear storage.  No log file means that an application problem is harder to find.  Think days of work, maybe a week.

If a computer system appears to wake up in the night, when a national election has stopped counting votes, and "glitches" votes from one candidate to another, guess what: it isn't the standard code.  Something changed and it is discoverable in the log files.  If there are no logs, it can usually be found in places where the application is writing to a database.

Whatever it was, and there are lots of choices, vote-counting software would be highly unlikely to do this during an election.  These kinds of problems are solved during the quality assurance testing as the first item one might check.  Such checks would be run over and over against every conceivable circumstance.

Vote-counting software — checking if it actually counts votes for the right guy is something one does pretty early in the process.  And if it works, it will continue to work — unless something changes.

So when you hear that there is a "glitch" in the dark of night and votes got moved around, you can bet it wasn't the lightning strike or a broken water pipe.  It was someone changing something.  It likely left some tracks. 

And my experience is there will be lots of tracks.  Competent forensic investigators know just where to look.  They are likely to find that someone changed something, and it was not a "glitch."

I led the team that developed the fraud detection software for the largest online auction house in the world.

Scammers sold products, did not deliver them to paid customers, then dropped off the site.  The perp then changed every identifier — name, address, credit card, phone, literally every ID — and rejoined the site.

Fraud detection software was blind because there was nothing in common between the bad guy and the newly listed same bad guy.  Neural nets were useless; there were no patterns.

This was a high-profile deal.  It was front-page national news for months.  The Secret Service, the FBI, about every fraud detection company was trying to solve it.  They could not.

We delivered a fraud technology that stopped auction fraud in its tracks.  The auction site publicly stated such, noting it in its annual report.

We know a little bit about fraud, cyber-security, computer programming, and "glitches."

Software is really stupid stuff.  It does not go off on its own, has no mind of its own, and there is no intelligence anywhere in code.  It performs instructions and does them over and over, exactly the same every time, no matter what.

Until something changes.

Something changing is not a "glitch."  It is a change.

Software does not wake up in the morning and suddenly shift 6,000 votes from candidate A to candidate B, as in Biden.  An electrical impulse hitting from that outdoor lightning strike does not make code do something different.  It may fry a hard drive, but it does not change vote counts.

Software leaves tracks.  These are called log files. 

This is a little geeky, but software runs on an operating system.  You have one on your phone, that thing that updates itself right in the middle of the phone call you need to take.

Operating systems need to track everything they do, so they write automatically to a log file for everything that happens.  The software vendor usually uses these log files to see what happened, when something that was not expected did happen.  Log files are really useful, and most serious applications use them.

Log files are huge.  They are really ugly.  If you saw a log file, it would look like thousand pages of random numbers and letters.  It would mean nothing...to you.

To a system that reads log files, it would mean everything.  A log file is the equivalent of having a social media post for every one of your eye blinks, heartbeats, finger movements, 24 hours a day — you get the picture. 

You can screw around with log files and modify them, but it is really hard.  It also leaves tracks, as any change to a log file is written to — you guessed it, that log file.

Some applications run on very constrained machines and do not create log files.  To create them is to eat up dear storage.  No log file means that an application problem is harder to find.  Think days of work, maybe a week.

If a computer system appears to wake up in the night, when a national election has stopped counting votes, and "glitches" votes from one candidate to another, guess what: it isn't the standard code.  Something changed and it is discoverable in the log files.  If there are no logs, it can usually be found in places where the application is writing to a database.

Whatever it was, and there are lots of choices, vote-counting software would be highly unlikely to do this during an election.  These kinds of problems are solved during the quality assurance testing as the first item one might check.  Such checks would be run over and over against every conceivable circumstance.

Vote-counting software — checking if it actually counts votes for the right guy is something one does pretty early in the process.  And if it works, it will continue to work — unless something changes.

So when you hear that there is a "glitch" in the dark of night and votes got moved around, you can bet it wasn't the lightning strike or a broken water pipe.  It was someone changing something.  It likely left some tracks. 

And my experience is there will be lots of tracks.  Competent forensic investigators know just where to look.  They are likely to find that someone changed something, and it was not a "glitch."