Now that the shoe has dropped (ITW malware is killing Safe Mode by deleting the registry content that defines it), I can be a bit more public about this concept - that if something is to be "safe", it can't be defined by editable baseline data. Examples:
- Web browser "blank" page
- Safe Mode startup axis
But XP's Safe Mode is flawed in several ways that create opportunities for malware:
- Entries can be added to (or persisted into) its startup axis
- It uses a different user account, therefore different per-account settings
- It runs a screensaver, which can be re-defined
- File associations now allow per-user overlay
- The "Cmd Prompt Only" shell can be re-defined
- The whole thing depends on a re-definable registry subtree
I have a case like this at the moment, and will be trying a "case 4" approach as I described as a comment to that blog entry. If it works, and I can remember the exact method I use, I may write that up as a new blog entry here :-)
A less-obvious example of the "Safe should be boilerplate" rule is the option not to use a password. Normally that's done as a "blank password", rather than a true boilerplate absence of a password - and that becomes absurd when coupled with the usual "to set a new password, first enter the current password".
The trouble with the "Safe should be boilerplate" rule is that it precludes any fix-it-later patching. You have to make your boilerplate perfect, even if that means simplifying your code towards triviality in order to approach that perfection!