Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The crash database can be trawled after the hostile code is found in the wild.


Exactly. Many exploits rely on crashing components of the system. Depending on configuration settings a system may automatically be sending in watson reports for certain kinds of crashes. This makes it possible to track down the origin of a virus / worm after the fact. Step 1: take notice of the exploit in the wild. Step 2: determine it's method of operation. Step 3: correlate watson reports with exploit (likely there will be many of these). Step 4: backtrack to the oldest reports which might be from when the exploit was being developed, then dig out as much information from those reports as you can.

Certainly this doesn't work all the time, but even if it worked only very rarely it'd still be a pretty substantial payoff.


Yes, that must be it, thanks.

But then the same thing could apply to non-malicious/competitive code, too. Once it proves interesting to Microsoft, they could mine the past crash history for background info.

I can believe internal controls and culture mitigate this risk -- but sheer volume doesn't provide confidence of confidentiality for non-malware coders any more than it does for malware coders.


Look at it this way -- the Watson system is pretty important in improving the quality of Windows (let's assume that more quality -> more sales). If coders (most of whom work in a corporate environment) ever found out that Microsoft was looking through their code for a non-emergency reason, they'd immediately turn off error reporting on all of their systems (not to mention, file a few lawsuits), removing sources of crash errors from a sector that is vital to Microsoft (and leading to a decrease in the quality of Windows, and thus, fewer sales).

So it's in their best interests to keep those internal controls as strict as possible in order to avoid such a thing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: