In October we announced some changes to our BrowserModifier detection criteria. These changes were designed to keep a user in charge of their web browsers through consent and control. Since the changes were announced we have been working with software developers to align their programs with our criteria.

To provide more clarity, we are sharing our timeline for compliance. This blog sets an enforcement timetable and further clarifies our detection criteria.

Control

Our objective criteria states that a program should not:

Preventing control

Enforcement date: Immediate

The most common violations of this criteria are programs that disable browser extension controls. Some do this by disabling the controls in the Manage Add-ons dialog.

In Figure 1, the user should be able to disable this extension but their control has been removed.

Another way user control over a web browser is prevented is by the removal of proxy control.

In Figure 2, a user should be able turn off the proxy control.

These are not the only examples of programs preventing user browser control that we have seen. Nor are they the only two that we will enforce.

It has been six weeks since we changed our detection criteria to include behavior that impacts a user’s web browser control. We are now enforcing these new criteria in all our antimalware products.

Limiting control

Enforcement date: 1 January, 2015

Programs that limit a user’s ability to choose their default search provider will also be detected. This could be through additional questioning when a user tries to change their default search provider.

Figure 3: Examples of a settings change blocker

Figure 4: Internet Explorer confirmation dialog box

Figure 5: Program discouraging a user from changing their default search settings

From 1 January, 2015 we will detect behavior that limits a user’s ability to choose their default search provider. 

Programs should also not limit the user’s ability to change their default home page by adding additional questioning for the user.

Figure 6: Program discouraging a user from changing their home page settings

From 1 January, 2015 we will detect behavior that limits a user’s ability to choose their home page.

Consent

Enforcement Date: 1 January, 2015

Our objective criteria states that a program should not:

• Circumvent user consent dialogs from the browser or operating system.

This policy concerns the disabled-by-default model adopted by most web browsers. We will detect and block programs that bypass a browser’s built-in consent-to-enable feature. We will also detect and block programs that install themselves in a way that circumvents the browser’s consent dialog box from showing.

Figure 7: Contoso Toolbar "Enable" prompt

Similarly, programs should not bypass or try to supress any other of the browser's built in protection dialogs. As an example programs should not bypass Internet Explorer's default search permission dialog. 

Figure 8: An acceptable browser prompt

From 1 January, 2015 programs that interfere with a web browser's consent-to-enable feature will be detected by Microsoft Security Products.

Questions

If you have specific questions about your program and whether it complies with these criteria please contact us through our Developer Contact Form.

Michael Johnson
MMPC