Wednesday, July 29, 2009

Security (Bug Fixes) is now a Major Industry

Have you noticed that Microsoft and other software vendors think bugs are a natural common place?

What I mean by that is that they EXPECT USERS to EXPECT BUGS in their products. I've been a software producer for nearly 30 years now, selling and supporting customers over the years and I don't expect BUGS to be a natural part of the process.

That said, yet, it is well understood bugs do happen and no software is 100% perfect, regardless on how great your are. While some products are managed by highly trained engineers (as myself) and QA is very important, there are times where a bug is discovered by others. "Shit happens!"

The problem is that BUGS have become so pervasive in the industry and in mindset of this generation of software developers, there is a whole industry developed around it, especially in the security area or bugs that cause security problems.

Its become so bad, companies like Microsoft has a regular scheduled BUG FIX update, like every month - and they have trained the mindset of the industry to accept this modus operandi of software product development,

Another problem is that vendors, especially Microsoft use the "BUGS FIX OF THE MONTH" schedule to ship and include new technology they wish to enforce on the user base. And these new technologies are not always top quality and will be part of future Bugs Fixes updates!

Its a tough situation because as a software product producer, we can understand the situation. But we are not one to play this poor QA game to begin with and that is my beef.

Why did it happen?

Well, its hard to point fingers but I have my take on it:
  • Open source market,
  • More complexity,
  • Higher Dependency on 3rd party software,
  • Smarter IDEs,
  • Scattered support process,
  • Developer are less trained as Engineers - problem solvers,
  • And too much FREE software!
Overall, when you have less control of your software development, libraries and tools, you are prone to suffer the issues that are within the software you less understand and did not developed.

For example, for the Wildcat! Interactive Net Server product line, there are a few millions lines of code. We developed nearly 99% of it all in house. We hardly ever use 3rd party software, and in the rare case we do use 3rd party technology, we only do so with 100% complete understanding of what it does and what issues it has. Doing the design process, we know what every function call does. There are no surprises or unknowns. Its not a guessing game in how a function, blackbox or component is going to behavior. When you don't fully understand something, the risk is higher for problems.

So much of the software products out there are open source, and worst based on other open source. So if one part is broken, all of those products using the broken open source, is broken as well. A good example of this is WebKit which many browsers use. If webkit is broken, all of these browsers are broken. And this is just one small example. There are thousands of examples out there.

There are good and top notch open source software, so that is not a big part of the issue.

A bigger part is the complexity, less documentation. Since you didn't write it, you will spend a lot of time figuring it out. Good developers will roll up their sleeves and figure things out. Unfortunately most do not because of the complexity and when help is needed, many times help and support is unofficial, based on user-support forums and extremely time consuming. For example of this, most vendors have Newsgroup Support Groups and if you ask the question in a way people can understand, many times you get help. You may have to wait a few days and its a pop luck if you do get the help. That's because the vendors have push the support process to the users - users help users. A good low cost idea to help solve vendor QA problems!

It has become so complex, you need smart Interactive Development environment to assist you in putting together applications. Its like a puzzle. Take many parts, including open source, logically put it all together, press a button and viola - you have a product executable!

For many, that's good enough! they do a little testing, package it up and distribute it. It is far cheaper today to let users find problems and report them to you. After all, its no chip off your shoulder. Users expect it.

Only the good developers will use the feedback and solve the problems. Others will use either ignore it or wait for others to complain. After all, its free! How dare you complain and expect fixes!?

But overall, it happens because many developers have lost control of their design, development, quality testing, documentation and production - the traditional five stages in Software Engineering! The smarter IDEs allow kids 10 - 16 years old to write great software - but they are generally BUGGY AS HELL!

If you are not getting paid, they is less incentive to fix problems - yet, the software is "good enough" to release to the world for others to use and propagate the issue!

The industry has been molded to accept this practice!

Hector Santo, CTO
Santronics Software, Inc

Tuesday, July 28, 2009

Getting a FaceList

Well folks, I finally swallowed my pride and join FaceBook. Primarily to get together with the family who are ALL on FaceBook, but also to learn of its features.

So what is the secret of FaceBook?

Well, its complete sharing of information.

Duh, you might say.

Right. But sharing information was always considered a taboo - a violation of privacy rights so older software, such as our 25 year old Wildcat! Interactive Net Server hosting package, it never allowed sharing of information.

But that will change, Wildcat! 7.0 promises to bring sharing for customers who want to have their "own Facebook" like system. Heather, my daughter, helped me realized that I have change with the times in order to survive. Heather and I are starting a new business where you can collect all your electronic messages in one area. Its really nothing new, but it will be done via the web and it will have FaceBook and Twitter features too. We have a demo at

Well, facebook is fun I must say. You have to give up some of your privacy, but that seems to be the norm today. So be it. My cousin Tara had a favorite word today on Facebook - UPDATE! What is exactly how I feel - I must UPDATE to conform. :-)


Tuesday, September 23, 2008

Removing Chrome Spying Activity

Chrome is interesting fast browser (well, starts fast), but it has enough attraction that will probably begin to lure people.

The problem is that while Google touts it as a "Safe Browser" that is only stopping others from malicious and unethical activity - but not unethical activity that Google does itself.

This is like a neighbor getting your mail, opening it up for you, checking that it doesn't have any anthrax, but also records who send it, why, what information it had to sell to others, and then before it gives the mail to you, it will re-seal the letters as if it was never open.

Well, there are a number of things you can do to remove the spying. One will require you to rebuild Chrome.

Under Wrench | Options | General

Click the Default Search Manage option and unclick

  [_] Use a suggestion service to help complete searches.....

Under Wrench | Options | Under the Hood, turn off the following options:

  [_] Help Make Chromium Better........

  [_] Show Suggestions for navigation

  [_] Use DNS Pre-Fetching ...........

  [_] Enable Phishing and malware protection

For Cookie Settings use

  [Restrict how third-party cookies can be used]

This will stop all by one last call home spy ware feature.

The last one requires a recompile of the Chrome source code.  Add a single line of code in the c/c++ file:

    File: src\chrome\browser\
    Function: function StartUrlRequest()

void URLFetcher::Core::StartURLRequest()  {
DCHECK(MessageLoop::current() == io_loop_);

return; // <--- STOP SPY WARE

request_ = new URLRequest(original_url_, this);

Adding the return statement will stop all unsolicited background call home, monitoring done by Google.

Wednesday, September 03, 2008

Google Chrome - Open SPYWARE

Folks, as much as I admire Google, we need to be careful with what Google is done with their new browser - Chrome.

It is effectively Google "Spy ware" and attempt to take control of the user' PC, oops, I mean "device" in the same with Apple has done with iPhone.

I will have more to say on this, but I believe its time we need to get an organization that will help put a STOP to the rampant unethical practice of installing software that collects, spies and sends info to centralized systems, and also takes control of what you install.

People need to call/contact the FCC, FTC, state senators.

More to come...

Friday, February 22, 2008

Poison Pills: The death of DKIM SSP

For those who remember the classic ending in Planet Of the Apes, where Heston finally realizes he never left earth seeing the crumbled Statue of Liberty sticking out of the beach sand, he cries in despair:

"They finally did it! Oh no! Those Bastards finally did it!"

Its exactly how I felt when the DKIM working group was commandeered by a handful of business related concerns to finally destroy the DKIM SSP protocol proposal.

The way they did it was nothing short of a brilliant strategy in injecting a poison pill.

For awhile there, it seemed the momentum was on the side of SSP. The SSP-01 specification was making sense, developers began to feel confidence to implement it feeling there was no way in hell, it will change much more.

But all of sudden BANG - a competitive specification called ASP was introduce - a poison pill. ASP was so BAD, it is fairly obvious no one will use it.

But the ASP group was powerful enough to get the SSP authors to rewrite their own SSP specification with nearly all the same content!! It made you wonder WHO copied WHO!

ASP is so bad, not even the ASP principal author is supporting it his new Reputation $$$$ business services. Its not part of the VBR specification!. You wonder why? Well, Anything SSP related would water this VBR system. Most system would simply not need this REPUTATION service.

In some way, I am happy it happen. Now I can move on. The ASP people should be given credit for killing SSP. I just wonder if they have enough sleeping pills on hand - they are going to need it.

Liar! Liar! Pant on fire! Clemens Busted!

Roger "Steroid Dodger" Clemens is busted!

If the new photos of Roger at this Canseco party isn't enough to prove this big bum is a freaking liar, I don't know what else is. Who needs the DNA results from this needle shots up his a-hole? Anyone who think this guy is telling the truth about not using steroids must also believe O.J. never chopped up his wife! Whats wrong with you people!

Just in case anyone is asking why Clemens would lie in our faces, I need only to say two words: PETE ROSE!!

Tuesday, December 04, 2007

Is DKIM safe without a strong policy framework? Part 2

Last year, I touched based with the DKIM securities issues and it major lack of tieing in policy considerations (SSP):

Is DKIM safe without a strong policy framework?

Since last year, the SSP spec has evolved to something that is surreal in terms of its functional specifications. It is overly complex and quite frankly, I don't think even a PHD can understand its purpose.

Today, believe it not, it is still being rehashed, same debates, same arguments, same people on one side of the SSP (CONS) and same people on the other side of SSP (PROS). It is like nothing was accomplished. And just like it existed on day 1, the same problems with DKIM sans SSP, exist today. Its only coming up again now because it will be on the table at the next IETF meeting.

When I wrote the alternative SSP protocol called DSAP, it was specifically written to address all the key security issues.

After discussions with the author of SSP and the IETF-DKIM chairs, I agree to support SSP if it covered all the basic security issues. The author did add the consideration's (although in extremely complex ways), so I opted to abandon any follow ups to my far simply, more concise DSAP I-D proposal.

Today, I am seriously considering of revisiting the DSAP proposal. If the IETF and the IETF-DKIM can't get SSP ratisfied (even with its complexities), I might just throw in this monkey wrench and see how it flies.

Sunday, August 26, 2007

Improving jQuery Timers Applications

A recent discovery about how jQuery is using AJAX using timer dispatch functions opened up a can of worms about the engineering reasoning used for the jQuery AJAX timer design.

I won't rehash the fine details. If you want to follow the discussion, read the thread at jQuery Support Group.

What I will show is how any jQuery applicaiton that has timers involved can behave differently depends on the user's PC machine timer resolution.

If you have a jQuery application that is sensitive with timers, you owe it to yourself to test it with the test C/C++ utility.


source code: fastsleep.cpp
zip exe/source:

Run the utility and then start to test your jQuery application. Make sure it works with as you expect it. Then hit M in the utility to change the resolution on the PC and retest your jQuery application to see if you see any negative or positive effect.

You might be surprise at what you see. Even if you don't see any visual difference or broken behavior using a PC 1ms timer resolution, your jQuery application could be using excessive overhead. To measure this, you will need to use the FireBug Profiler to see how many times a portion of code was run.


I'll keep it short, last year I can across this interesing submission at

How Yahoo! speeds up your application

For me, what was the ultimate discovery is that any application running on your PC, including any browser plugin, who changes the PC's multi-media resolution with a call to timeBeginPeriod(1), the change applies across the entire PC system.

This means all applications, including the browser and any javascript with timers are all affected by the system timer resolution change.

Go ahead and play with this. I am highly interesting to see any reports with timer resolution sensitivity in jQuery applications.