[QUOTE] Originally posted here by pooh sun tzu
Fine, you want to get snotty? Let's get snotty. I'll take the trollbait.[/qiote]
Take it however you like, by just stating that you disagree with no reason ads no value to the conversation. I gather by your more complete response my being "snotty" helped you see the light... so it's all good. ;)
I am not sure what you are saying here, how does running IE under the guest user not use the login information? If you find some way to have an application's DLLs not be limited to the user account it is running under... well you should publish that because you will have completely broken Windows security. Outside of that... I cannot think of any functionality issues this would prevent with the possible exception of not being able to save webpages to directories lacking guest access, which is easily dealt with.
1. Running anything on a guest level still requires systemwide DLL acess for IE to function. Thus, on a guest level system specific DLL's are still called upon in code functions. Their access to read/write is not controlled per system application but by user login. Running IE at guest privleges would not only HINDER everyday usage, but prove uneventuful in halting exploitating of code, URLs, and exploitation of built in IE components.
Why are you hung up on the settings being default? The settings should be such that they fit most appropriately within the system. Locking a system down (hardening) has more easily calculated consequences than disabling security features, this is why high security systems ship in a completely unhardened state and provide a TFM for the system owners/custodians to harden as appropriate. The fact is IE has the functionality to be locked down, default or not is unimportant.
2. Settings are settings. If you wanted default secure settings, you should have used a different browser.
So... a local attacker or exploit (that perhaps effects another application and then manipulates IE) can't use IE? I am sure you don't think this.
3. If IE is not running (and preloaded DLL's do not count) then IE will not be exploited. If a second browser is installed then the second browser alone is prone to exploits, and not to an exe that is not running. Memory footprint of the dll's loaded for IE are not just IE only DLL's and are thus system wide DLL's. Thus it is not the browser but the DLL's the system uses to tie multiple applications into. Whether you use one browser or two, the risk is not elevated.
Ah the open source argument... did you know that the average lifespan of a Linux source level bug is nearly 2 years. Woo "incredibly fast"... no doubt. (I'll send you my documentation from the Stanford CSL if you doubt this fact) Open source is an inferior development model, (stage 1 on http://www.sei.cmu.edu/cmm/cmm.html )
4. Being OpenSource, FireFox has the uncanny ability to learn from the competetors mistakes, namely IE. This means responce time for patches and fixing are incredibly fast for any OS release, including Windows. So while you run a crippled version of IE, Firefox will still be fully functional and secured because of it's default code base.
Ok, you hate closed source, we get it. Also just so you know in a closed source product, the code isn't "embedded" it is just "code." In computer science "embedded" means to put something within something different... like compiled SQL being embedded into a C++ build. Not just C++ embedded within C++.
5. You can change all the settings you want, but you can not alter embedded code within a closed source project, making IE still vunerable.
There is no reason to alter the IE source, I already explained how the two types of browsing threats it faces can be defeated, the only remaining issue is the effect it has on overall security... wherein the computer security universal truth of simplicity prevails and having two browsers is less secure than one.