What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.
Unless you were doing external vulnerability assessment, that granularity was a false sense of security. Rolling back sometimes re-introduced old bugs.
Granularity is impractical when applying patches is optional, as it drastically increases the number of applied patch combinations to QA.
But my point was more towards MS programatically alerting customers as to what programs and subsystems patches might effect.
As far as I've seen, they give you a file list, some brief notes on what the patch is for, and assurance that they internally QA'd it.
But I can't see why there's any technical reason that my system can't warn me that an MS library called into frequently by a particular program I use every day is modified in this patch.
Which is something I care about almost as much as "MS QA passed this patch" (side note: thanks so much to all the unloved, unknown internal QA folks out there, keeping things from breaking!).
What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.