In what's become a common practice for Microsoft, the company has again set a milestone and then backtracked a bit, giving customers more time to comply.
Just last week, Microsoft told customers that it would make design changes to Internet Explorer during the upcoming Patch Tuesday. The changes would give Internet Explorer the ability to block out-of-date ActiveX controls, to ensure things like Java would be stopped from running if the component did not fall within a supported, secure state. The move is an attempt to better secure web browsing and bring customization features so companies can identify and block potentially dangerous web controls.
In an addendum to the announcement, Microsoft has stated it will give customers an additional 30 days before it starts automatically blocking ActiveX controls. The feature will still roll out during Patch Tuesday, setting the stage for the 30 day deadline.
The feature will be included in the August Internet Explorer Cumulative Security Update, and once installed, customers will still have the ability to use it using GPO and registry modifications, it's just that Microsoft won't start automatically blocking what it deems dangerous until September. Microsoft is providing the 30 day window to allow customers time to get their house in order in preparation of Microsoft centrally managing block lists. The feature, out-of-date ActiveX control blocking, will be handled much like Windows updates and Antivirus signature files are today. A single XML file (versionlist.xml), sitting on the local computer, is used to provide Internet Explorer with the information to block specific controls. When new controls should be blocked, per Microsoft's conviction, the XML file will be updated with the new information. Internet Explorer, itself, is the mechanism used to actually check in with Microsoft for new versions of the file and will download it when updates are available.
In September, when Microsoft begins managing the XML file update, only older Oracle Java ActiveX controls will be blocked, with more exclusions on the way as Microsoft deems them unsafe.
The versionlist.xml file can obviously be altered by those in charge of security in the business environment to add locally determined, flawed components, however, once Internet Explorer detects a new versionlist.xml file, those changes will be overwritten. So, good luck trying to manage the list. It would be like trying to empty a bucket full of water with a cup while it's raining.
One piece about this that seems to be a bit off-kilter, is that administrative access is not required to successfully remove the versionlist.xml file and disable the feature. The new feature is designed to better protect Internet Explorer users, so not requiring administrative rights to enable and disable seems a bit contrary to the intent. And, even more, Microsoft provides the steps to successfully disable the feature in a blog post, including code that can be copied directly from the web page.