The problem is that updates are truly essential for the security of both you and your device. That is why we’ve worked hard on providing “incremental updates” for the Avira Scout browser. This is a key technology that enables us to keep you more secure and also reduces your pain to getting an update.
Even more, from both your point of view as a computer user and our point of view as a software developer, this is a win-win situation. Your point of view: you could be sitting behind a slow internet connection and don’t want to waste it on updates … but you still want the newest features and fixed bugs. Avira point of view: The size of an update limits our motivation to roll out browser updates on security fixes or when we have new features. Browsers are large (40 MB installation archive). With lots of customers, this results in lots of bandwidth being used. And bandwidth is money – so it’s a no-go for a free product.
You actually don’t need the whole update. You’ve already had most of the code pushed to your computer with full feature updates so you’ve got all of those things that did not change in your Scout. You only need the new bytes.
Incremental updates do just that, they fit the update to meet your needs.
They send three things:
- The new bytes
- A manual for your computer, telling it where to apply those new bytes
- A check to run after the construction. If anything fails, you will automatically get the full download of Scout
This is exactly what we need to run frequent updates for new features and bug fixes.
Chromium already has the parts required for this technology approach. Getting it to run in Avira and in the Scout context was the tricky part. Here is a short list of the major components that have been worked with which enable this incremental update approach.
Courgette – The Chromium tool that takes two versions of a software, identifies the new bytes and creates the manual.
Server – The software running on the server is a bit more complicated with incremental updates. It has to be able to handle incremental requests and also full browser requests (just in case anything fails or there is no incremental update path from the user’s (very old) version to the current one)
Omaha Client side updater – This has to be able to find the proper data set to apply on top of the current Scout. After that come a couple steps:
- Verify….maybe download the full Scout on fail?
- Notify the user that Scout needs to be restarted
The incremental updates add more complexity to our automated test scenarios.
- What happens if we update version A to B?
- Does the fallback to the full download work?
- What happens on a buggy network connection?
- Does the user interface behave properly – even under strange or esoteric circumstances?
The code is written once, but the tests need to be run for every single update. Creating automatic tests was just the thing we wanted here.
I did some research on this a few months ago, but the real work has been done by Evgeny, Stefan and the rest of the Scout team. And the Chromium team at Avira. Credits go to them for making the big steps needed for us to make those incremental updates.
We are standing on the shoulders of giants.