Spybot 2.0: updating concepts

Updating is an area where we feel quite torn, because it just cannot be solved perfectly. On the one hand, privacy paranoia should require all Internet connections to be established on explicit user request and choice. Background downloads are often among malware criteria, and as such, we wanted to avoid them for a long time.

On the other hand, there's user comfort. The average user does not want to be disturbed by having to actively care about his security software too much, and we can't blame him for that. Allowing an application to download at will requires (or at least should require) a lot of trust really. Of course, allowing a software to tell the user what it thinks is malware means a lot of trust as well already, so the trust may still be there. No reason to use it without a lof of thinking though.

The compromise we're going to approach is a dual approach. We'll still need manual updating for situations like running Spybot from a bootable CD, where background service downloads are not an option. So a kind of manual updater for such situations will persist. At the same time, we'll offer a no-interaction-required background download service.

The next issue with updates is about version checking. Currently, downloaded.ini is used to check which updates have already been downloaded. If you delete this file, it gets recreated based on file dates of archives in the updates folder. And if you install updates through a manual updater, it should get updated as well. Still, this method is far from perfect as soon as the user "plays" around in the Updates folder, e.g. to clean up old archives or create a portable edition - something he should be able to do without having to pay attention to the ini files in there. The 2.0 updating will therefore use dedicated updates per file instead of combining files in archives, and determine which are needed based on each files property (version resource for executables and libraries, other parts for data files).

Another side-effect of having one update per file is that it can easily support the new integrity checks, which would allow to replace single destroyed/corrupted files with originals.

On NT+ (2k, XP, Vista, ...) systems, a system service is the next point that we needed to discuss. On the one hand, a service would allow users with restricted rights to update Spybot. On the other hand, updaters are a field where many an antivirus application had security holes in the past. Since system services have system privileges, the interface for this needed to be tight, not comfortable (speaking from the developers standpoint, not a user one).

No screenshots here since this is mostly technical background stuff.

To sum up a few things:

  • No more shutdown of all updates while new updates are uploaded.
  • Fallbacks if main server is not available.
  • Background updating.
  • File-by-file updates to support integrity checks.
  • More safety measures to ensure authenticity of updates.
 
Click to expand...
Hi,

I would be great if spybot integrates all the detection bases (trojan,worms,rouges,etc.) into a single file. Something similar to Avira's VDF. One file all detection bases. :)

Moreover, instead of providing multiple file update downloads, how about Avira's updating technique. All the increment updates are downloaded as a single file.

And last but not the least, merge and re-shuffle the signatures. For example: All the virtualmonde detection patters should coincide with each other. As of now the malware the comes under the same category gets scanned in the order of the sequence of the updates.
 
Could you please elaborate why that would be great?

If just one database file would be accepted, that would make the open detection database (OpenSBI) void. Some of our guys will really thank you for suggesting to destroy two years of work, as will everyone who is a fan of open source.

Updating will suddenly need the full file to be updated each week, making updates so expensive that Spybot would no longer be freeware.

Or updates would be incremental as you said, in which case the client would have to be able to encrypt as well as decrypt, which is an unnecessary security risk.

Memory consumption for holding the full database in memory would increase as well of course.

Alpha and beta testers could no longer do a simple alpha/beta only scan, but would have to do a full scan for testing, which means these would take so much more time that we might loose testers, thus reducing the quality. Same goes for Distributed Testing, we might suddenly be back to a few dozens instead of thousands of machines to test on.

And all those disadvantages for having the list displayed in alphabetical order without jumps between files?
 
Spybot's updates are often scattered all around the hard drive, if there is no defragmentation.

PepiMk, from now on I will post negligible suggestions. Unless I thoroughly understand the working mechanism of Spybot, I will not post any suggestion to avoid contradiction. :lip:

Happy now? :red:

Well, I think this last suggestion may also generate differences in opinions.:rolleyes: How about compressing the increment updates, Spybot installer kit,etc with 7ZIP archive?

To be more clear I am referring to compression mechanism that Mozilla Firefox's installation kit as well as the increment updates uses. :FF:
 
Last edited:
7zip is indeed quite fine. It uses lzma compression, something InnoSetup (the installer engine we use) uses as well (and I think NSIS, used for the manual updates, as well), so in terms of the installer, we already do that.

As for the updates, the data files are compressed before getting encrypted, and encrypted files cannot be compressed any further, so the packing algorithm does not make a difference here. In fact, we decided far .cab instead of .zip in 2.0, since .cab archives are supported native by the Operating System (even in 9x where no zip viewing support existed). For the executable files though, 7z/lzma might indeed show a difference, thanks for the point :)
 
You must log in or register to reply here.
Back
Top