Category: Tech

Posted on

Child Monitoring Software

For my job, I write corporate employee monitoring software. Some people see it as Big Brother software, and it could certainly be abused in the wrong hands. I believe that technology itself isn’t good or evil; instead it is subject to ethical and unethical use by individuals.

There are many aspects of security. One of them is auditing, the purpose of which is to verify the trust we have placed in an individual. It’s a way of managing risk. The people in whom we place the most trust can do the most damage to us and to our organization. In many cases, we have no choice but to trust. To be distrustful of everyone and everything would be unproductive. I’ve heard the saying “Trust, but verify”, and that’s where our software comes in, because it allows companies to verify the trust they place in their employees — to pinpoint and mitigate risk.

Our software is a great solution in the corporate environment, but it’s not designed nor priced for home and small business use. In particular, I wondered what solutions exist for parents who want to reduce risk to their children who use the internet. I’ll get to that in a moment, because I believe that technology alone will never be a complete solution.

First and foremost, I believe we must teach our children correct principles of safety and responsibility. Teach them what is expected of them when they go online, and what dangers to avoid.

Second, place the computer in a public, high-traffic area in the home.

Third, talk to children about what they do online.

Fourth, since it’s not always possible to be at home monitoring what they do, consider using child monitoring software. As I understand it, it’s legal to monitor children under the age of 18 without their consent.

Fifth, review what the monitoring software collects.

The most complete website I’ve found about child monitoring software is www.1-spy-software.net.
The most mature and industry recognized solution, as far as I could tell from my google research, is Spectorsoft, which is available for Windows and Mac OS X computers.

I haven’t used child monitoring software (my children are too young to use the Internet), so I can’t vouch for its quality, its ease of use, or its effectiveness. What would I look for in a home solution?

  1. Trustworthy.
  2. Widely recognized and mature. Easy to use.
  3. Doesn’t transfer collected information to a remote server.
  4. Available from a local retail store.
  5. Cost effective.

Posted on

The E-Voting Iceberg

Bruce Schneier writes in Forbes about electronic voting:

Electronic voting is like an iceberg; the real threats are below the waterline where you can’t see them. The problem is software — programs that are hidden from view and cannot be verified by a team of Republican and Democrat election judges, programs that can drastically change the final tallies. And because all that’s left at the end of the day are those electronic tallies, there’s no way to verify the results or to perform a recount. Recounts are important.

This isn’t theoretical. In the U.S., there have been hundreds of documented cases of electronic voting machines distorting the vote to the detriment of candidates from both political parties: machines losing votes, machines swapping the votes for candidates, machines registering more votes for a candidate than there were voters, machines not registering votes at all. I would like to believe these are all mistakes and not deliberate fraud, but the truth is that we can’t tell the difference. And these are just the problems we’ve caught; it’s almost certain that many more problems have escaped detection because no one was paying attention.

For the most part, and throughout most of history, election fraud on a massive scale has been hard; it requires very public actions or a highly corrupt government — or both. But electronic voting is different: a lone hacker can affect an election. He can do his work secretly before the machines are shipped to the polling stations. He can affect an entire area’s voting machines. And he can cover his tracks completely, writing code that deletes itself after the election.

You can even do away with the electronic vote-generation machines entirely and hand-mark your ballots like we do in Minnesota. Or run a 100% mail-in election like Oregon does. Again, paper ballots are the key.

Paper? Yes, paper. A stack of paper is harder to tamper with than a number in a computer’s memory. Voters can see their vote on paper, regardless of what goes on inside the computer. And most important, everyone understands paper. In today’s world of computer crashes, worms and hackers, a low-tech solution is the most secure.

Posted on

Magical Tech Support

For my first computer job, I did half tech support and half programming at Brigham Young University. I enjoyed helping people because they were appreciative when I could solve their computer problems.

It was interesting that about a third of the time, all I had to do was walk into the office of the professor that was having a computer problem, and the problem would be solved. I didn’t have to do anything. It was like magic. The same scenario occurred for the other tech support guys.

That was in 1992, and I had forgotten about that magical aspect of computer support. Last night, however, I was reminded when I went to a neighbor’s house to help with a printer that wouldn’t print. I didn’t expect to find an iMac. It seems like most people have Windows computers. Here was an exception. The first task was to power it on. Where was the power button? I felt foolish that I couldn’t find it. Although I programmed in 4D and Foxpro for four years on a Mac, the experience with legacy systems didn’t help me with today’s hardware. I searched for the power button on the keyboard, on the monitor, and on the base of the iMac. Somehow, I missed the nearly invisible power button located near the back of the base. Fortunately, the 10 year old son showed up and powered it on. He also turn on the printer. I had him print a test page, and it worked. The 10 year old was shocked. It hadn’t worked before. He had tried fiddling with USB cables, etc., but to no avail. Once I showed up, it worked, magically.

Now I hope it continues to work.

Posted on

Stages of Security in the life of computer software

Is your client-server software secure? You may be surprised to find that even mature software, sporting the use of standard encryption, could be putting your mission-critical data at risk. Why is that? It has to do with economics and the lifecycle of software. Here are the stages.

Prototype. No one cares about the security of the client-server communication.

First release. Althought the system (likely little more than an improved prototype) has been shipped, it may not be usable, and if it is, it lacks mission-critical features. Security is low on the priority list. If encryption and authentication were implemented, it is most likely minimal, brittle and insufficient. If the security is robust, the product is not functional and likely never will be because the ISV will go out of business.

Second or third release. If the ISV has survived long enough to release a second or third version, customers likely demanded the use of standard encryption. In the old days (the 1990s), this means the ISV would have switched from XOR “encryption” to DES or 3DES. These days, standard encryption probably means use of SSL/TLS without certificate checks. Note that customers probably won’t ask about the security of the authentication mechanisms.

Unfortunately, use of a standard encryption algorithm doesn’t mean communication is secure. Software is likely to be vulnerable to man-in-the-middle attacks and have authentication bugs. The customer isn’t likely to know this, and neither is the ISV. If the ISV does know, they won’t fix the problems. This shouldn’t be surprising — the risk tolerance is different for the ISV versus their customers. The software vendor isn’t the one that is going to suffer losses due to information disclosure or breach of integrity.

At this stage, customers usually apply more pressure to implement new features than to focus on security. Of course, this is based on ignorance of the actual situation. The vendor isn’t likely to want to pay the price to improve security… unless the customer knows and applies pressure to get it fixed.

Eventually, a security-conscious customer (i.e. a financial institution or a government) hires someone to evaluate the software, and they start asking hard questions of the ISV. Most of the ISV’s software engineers won’t know the answers because the security mechanism is transparent to their daily work — it stays out of sight, and out of mind. Eventually, people figure out that the encryption is vulnerable to man-in-the-middle attacks or authentication bugs. At first, customers may be reluctant to believe that the security holes are serious, and then they will panic. They will apply pressure to the ISV to get it fixed.

Take-away points:

  • SSL without certificate checks is vulnerable to Man in the Middle attacks.
  • Almost no ISV gets encryption right the first time, and they won’t fix problems unless their feet are held to the fire.
Posted on

Tim Bray tells us what’s awesome about Ruby

Tim Bray explains what is to like about the Ruby programming language:

I’ll jump to the conclusion first. For people like me, who are proficient in Perl and Java, Ruby is remarkably, perhaps irresistibly, attractive. Over the last week I’ve got an unreasonable amount of work done in a ridiculously short period of time, with lots of interruptions, in a language I previously didn’t know. It’s intuitive enough that I’ve often found myself guessing at a syntax or a method or a usage and getting it right first time.

Maybe the single biggest advantage is readability. Once you’ve got over the hump of the block/yield idiom, I find that a chunk of Ruby code shouts its meaning out louder and clearer than any other language. Anything that increases maintainability is a pearl beyond price.

I’ve been programming in C and Java for a quarter-century and I find Ruby easier to read, only a week in. Of course, a language’s culture is often more important than all that technical crap. I’ve found the ruby-talk mailing list to be a fount of wisdom and friendly to ignorant newbies too.

http://www.tbray.org/ongoing/When/200x/2006/07/24/Ruby

Follow the link to find out “What’s Lame” about Ruby.

Posted on

Best of Breed, or Best of Mediocrity?

Having worked for some time as a software engineer in the enterprise security
software world, I know that customers (enterprises) look for “best of breed”
software. For a large company customer, this usually means that a software
solution distinguishes itself in some way that makes it work well in their
environment. Often, this translates to reliability, cross-platform support,
person-to-person support and the ability to function beyond what is advertised.

As many are aware, there is “consolidation” going on in the security market.
Big fish are swallowing smaller fish, and it’s lucrative, in the short term,
for everyone except customers. Supposedly, the consolidation means that two
separate products can be “integrated”, or unified. Never mind the previous
competitive relationship that may have existed between the product teams and
their management. For some reason, people seem to think that competition
evaporates and that the two product teams will happily work together to build
the next generation “Best of Breed” software solution.

Not so.

In any big corporation or software company, there are constant power plays
being made. You could call this “decision making”, and if you have uncommonly
good leaders, you might even say good decisions are being made.
Unfortunately, it is human nature for most people to misuse and abuse positions
of power. Instead of making product decisions that are best for their merged
customer base, they make decisions that keep themselves in a position of power.

So, we have two best of breed products: Overdog and Underdog. Underdog is
easier to manage, but isn’t as complete in its offerings. Overdog is more
complete, but is more expensive to deploy and manage. Overdog has the advantage
of being used in Fortune 500 companies. Underdog, on the other hand, is trying
to break into that market space.

Enter Big Fish — a.k.a. Consolidator. Consolidator buys Overdog, and a few
years later, buys Underdog. We take two products, both “Best of Breed” in
different ways, and expect to see them merged together to make something “next
generation” — better, faster, stronger, and easier to use.

Whenever there is a consolidation, talented people get fired, and their
creative ideas and abilities are lost. Product integration never happens as
easily as anyone would like to believe (if it happens at all). And in the end, customers end up with a
product that we can best label as “Best of Mediocrity”. Consolidation means
that customers lose their “Best of Breed” solutions.

What can you expect from Software Consolidators? Mediocre solutions. Look
elsewhere for excellence.

Posted on

Principles of Reputation

One of my past professors, Phil Windley, posted some principles of reputation:

  • Reputation is one of the factors upon which trust is based
  • Reputation is someone else’s story about me – this means that I can’t control what you say about me although I may be able to affect the factors you based your story on. Also, every person should be able to have their own story about me.
  • Reputation exists in the context of community – this is different than saying “communities have a reputation about someone.”
  • Reputation is based on identity – reputation, as someone else’s story, isn’t part of your identity, but is based on an identity or set of identities.
  • Reputation is a currency – while you can’t change it, reputation can be used as a resource. Paul Resnick has a paper showing the value of a positive eBay reputation.
  • Reputation is narrative – you have to apply metaphor to interpret, reputation is dynamic becase the factors that affect it are always changing, reputation may require weaving together of plot lines.
  • Reputation is based on claims (verified or not), transactions, ratings, and endorsements. – this brings up the issue of evidence, recourse for slander or mistakes, etc.
  • Reputation is muti-level – a reputation isn’t just based on facts, but is also based on other’s beliefs about the target of that reputation. This requires some way of signaling beliefs to others.
  • Mutiple people holding the same opinion increases the weight o that opinion – repeat behavior is also another way of weighting reputation.

Posted on

Is Data Mining Fools Gold?

Here’s a thought provoking article about the problems of large-scale data mining by
governments. It’s written by a person living in the UK.

“Data-mining is complicated, and the more data you are mining, the more
false positives your software will throw up. If you act upon a false
positive for a motoring offence, it’s an inconvenience for the motorist,
but for an alleged case of child abuse, it can rip the family apart and
ruin the child’s life.”

“Furthermore, gathering large amounts of data is inherently dangerous.
Whatever information governments find interesting will also draw the
attention of criminals. Databases can be hard to keep secure, and it’s
not necessarily hackers that we should be worried about, but
unauthorised access by employees of the agencies that use these
databases. Equally, the more data you have, the more difficult it is to
maintain accuracy. In 2000, an audit of the Police National Computer
found that 86% of records contained errors, 85% of those errors were
serious, and some were libellous.”

“Technology can be a very powerful tool, but what it can’t do is replace
real human beings or traditional investigative work. Designed badly or
used poorly, databases are the technological equivalent of fools gold.”

Posted on

Article: Crash-only software

Crash-only software: More than meets the eye
by Valerie Henson July 12, 2006:
http://lwn.net/Articles/191059/

Properly implemented, crash-only software produces higher quality, more
reliable code; poorly understood it results in lazy programming. Probably
the most common misconception is the idea that writing crash-only software
is that it allows you to take shortcuts when writing and designing your
code. Wake up, Sleeping Beauty, there ain’t no such thing as a free lunch.
But you can get a more reliable, easier to debug system if you rigorously
apply the principles of crash-only design.