The software architecture to use for faster security hole patching: Web Applications

Frederick Giasson

Security holes can be found everywhere in software. It can be a problem by the way a programming language is used; it can be a problem with the conception or the use of an un-secure protocol; it can also be a problem of interaction with other software or libraries; it can be a problem with his interaction with the operating system, or it can be a problem with the way users use it.

These problems are real, and many people and billion dollars are spent to try to cope with them. However nothing is perfect and the result is currently seen as marvel by someone and terrible by others.

If a security problem is found, you can bet that an advisory will follow; a patch of the software in cause will be distributed. Software developers thought about developing systems to ease the burden of software updating imposed to users. Some systems are good, others are more debatable. In a case or another, the problem is the same: users need to perform some type of task to patch their software to secure their systems. With the number of software they daily used, they can hardly keep them up-to-date, with or without having the will to do it.

What if they do not own, on their computer, the software they are using? It is sure that not owning them on their computer does not make the code surer, but will the updates be faster? You bet. Think about it. You are using certain functionalities given by a certain web services, web application, API, etc. Someone find a security hole in the thing, and then wrote and publish an advisory about the found security hole. Normally, thousands or millions of people would need to download and install a patch to get rid of the bug and re-secure their systems. But if the same code is use by all these users, you only have to change that code to automatically patch all users. It is probably the greatest security advantage we have by using such online software.

I recently unintentionally tested the concept with Bloglines. I found a bug in their system (in fact it was the relation between a bug in their system and the use of another web service), published an advisory, then the system was patched 1 or 2 days later by the Bloglines developers. Then all the users were patched and secured at the same time.

Technorati: | | | | | | | | | | |

From Business Cards to Blogging Cards

Frederick Giasson

There is the first draft of my Blogging Card:

 

 

I will start using this card when I will go to India in 2 months. I will not have any permanent address or phone numbers. The only permanent thing I know that I will have is this domain name. This card will be good for years, as long as I pay 9$ per years to keep the domain name.

Why using that card? Nowadays, what is important is the development of our social and relation network. This card is a way to aggregate new nodes to my network. People to whom I will leave that “blogging card” will be able to know where I am, what I am working on and will be able to contact me anytime, independent of where I am in the world. These little informative cards can be seen as paper link to this website. I think that website can become the core node of my professional, social and relation network.

Why do I use the name “Blogging Cards”? For what “blogging” signify to me. This is not just a Business card, it is much more. If I give it to someone, it is because I hope to keep a contact with him, not only a business contact, but a social and professional one. It is why I call it a “Blogging Card”, because blogging is a social activity, an activity of socialization, of knowledge sharing and ideas exploration. If I give that card to someone, it is because I wish to redirect him into that place, to discuss and share that knowledge and these ideas.

Technorati: [] [] [] [] [] []