To understand Protected Mode first we need to understand how browser security and session works in browser.A browser session was represented by a single instance of the browser process executable.

How IE6 maintain single instance for entire session?

A framework for driving IE could instantiate the browser as COM object using CoCreateInstance(), or could easily get the COM interfaces to a running instance by using the presence of ActiveAccessibility and sending a WM_HTML_GETOBJECT message to the appropriate IE window handle. Once the framework had a pointer to the COM interface, you could be sure that they'd be valid for lifetime of the browser. It also meant you could easily attach to the events fired by the browser through the DWebBrowserEvents2 COM interface.

Problem with this process

Browser can run all type of scripting without failing which leads to installation malicious software and different type of viruses in system. Hacking possible too

Introduction of Protected Mode

Then in Window Vista with IE-7 introduced Protected Mode, which comes with Mandatory Integrity Control in Windows to prevent actions initiated IE, usually initiated by client side scripting, from being able to access the operating system the way it could in prior releases. While this was generally a welcome development for most users of IE. Then it created main problem for IE-Automation.

Session Problem with Protected Mode

Navigating from an internal intranet website to one on the internet, IE has to create a new process, because it can't change the Mandatory Integrity Control level of the existing process which leads to session problem with COM Object and then this create problem in automation.

How we can fix it?

Now if our navigating page will cross protected mode then we will get session issue.so if we change the Protected mode settings in the browser to be the same, either enabled or disabled, it doesn't matter which, for all zones. This way, it doesn't matter what navigation occurs, it won't cross the protected mode boundary and wont trigger session problem.

How Automation tools check this protected mode

All Protected Mode Setting basically stored in Window registry, and checked when the browser is instantiated.

INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS property used in Selenium Tool which basically bypasses this registry checking so I think we should not use this property during automation which makes your code unreliable.

UFT strictly follow this property in registry that's why we don't have any procedure to bypasses registry in IE.

Why we didn't get any Protected Mode problem in Other Browsers

Google-Chrome : Chrome's virtual JavaScript machine, called V8. Google's Chromium team built its own virtual environment for all JavaScript execution. V8 even converts JavaScript code into native machine language (to speed up Web-page loading) and has its own memory garbage-collection processes, source-code inspector, and debugger. V8 significantly limits what can be accomplished by JavaScript against the user's system, including preventing the normal JavaScript pop-ups. In testing, Chrome did pretty well against pop-up ads but suffered from UI problems and slowness on some of the JavaScript modal tests.