The Evil Problem

Over on the IE Blog, a commenter made a very good point -- why is it that IE flags scripts as “potentially bad”? That’s very confusing to the average user, and they have no way of knowing whether or not the script really is bad or not (and therefore whether they should enable it or not).

Unfortunately, this is much harder to do than it sounds -- even for humans (let alone computers). If I told you about a program that deleted all the data off your hard disk, would you say that it was a “good” or a “bad” program? What if I told you the program was named “format.exe” and its only purpose in life was to wipe disks of all their data?

So it’s not easy πŸ™

By default, IE limits the capability of scripts running from internet web pages because it is highly unlikely that anyone trying to format your disk across the internet has good intentions. Nevertheless, if IE is asked to load a page from the local hard-drive, it might be the case that (eg) you have an HTML-based administration console for a locally-installed application, and you really do need to format a hard drive or perform some other potentially-dangerous operation. So in this case, instead of just outright blocking access to that functionality, IE disables it by default and uses the Information Bar (aka the "gold bar") to inform the user that if they want to run the script they can do so.

The idea here being that if the gold bar was unexpected, the user could simply ignore the notification / close the browser / navigate to another page / etc. and still be protected, but if the user was expecting "potentially bad things" to happen then they could click through the gold bar and still have access to the rich functionality of the administration application.

I entitled this post "The Evil Problem" because it's similar to "The Halting Problem", which is a famous problem in computer science that says it's not possible to algorithmically determine whether or not a particular program will halt (stop). The reason this is so is because if you assume such an algorithm exists, you write a program thusly:


while (DoesHaltingAlgorithmSayIWillHalt())

  ; // do nothing

Now if the algorithm says you will halt, you just loop forever (thus never halting). On the other hand, if the algorithm says you will never halt, you halt immediately. By this we see that such an algorithm can't exist. This mode of argument is called The Null Hypothesis and you could apply it to evil scripts thusly:


if (true == DoesEvilAlgorithmSayIAmEvil())

  ; // do nothing



Comments (6)

  1. zzz says:

    Locally you might be able to rollback things after the evil thing has happened. But I wonder why Outlook doesn’t do anything about the URLs in half of my emails that look like this: <; .. This kind URL spoof attempt is so easy to detect it really kills me that these get through Outlook spam filter.. And I’ve complained about this few times in msdn blogs in past 2 years and nothing is done.

  2. zzz,

    Another good question. This comes up from time to time internally, and there is always a lively debate about the problem πŸ™‚

    One thing to think about is that spammers will just start using images that contain the text of the URL (instead of the real text) and continue to fool users.

    Another is that often "legitimate" e-mails hide complex URLs behind friendly text — for example, you might see something like:

    Go to the <a href=""></a> to see our stuff!

    (Now you might claim that having click-through URLs in mails is bad, but that’s how a lot of opt-in commercial e-mail works. For example, Starbucks sends its mails through

  3. Unfortunately, halting lemma argument doesn’t hold here, as it is mixing program’s action with program’s intent. Halting is an action, while as malice is intent. The fact that malicious program doesn’t do harmful action due to execution content doesn’t change its intent (i.e. it is still a malicious program).

    And btw: it would be more correct to change your presentation of halting lemma to:

    if (DoesHaltingAlgorithmSayIWillHalt())


    (ie. halting algorithm should be consulted only once before making decision)


  4. Valery, thanks for the comment.

    I would disagree with the idea that a program can always be termed "malicious" though. The authors of some programs clearly had malice as their only intent (eg, viruses) and so you could say the program was, by extension, malicious. But in the case of good-but-buggy software being re-purposed, or in the case of general-purpose tools like file managent APIs being used for evil, then the malice comes from the user of the program, not the program itself.

    So you can’t algorithmically determine the intent of a program (good or evil); only whether or not it might perform actions that could be perceived as good (or evil). And since pretty much everything can be used for evil (eg, a phishing site that uses only text, images, and form fields but no script) that’s a pretty easy answer to give πŸ™

    The analogy with the halting problem was a stretch at best πŸ™‚

  5. Marcus says:

    Dear Peter Torr,

    Firstly, thank you for the comments. However, I think that the problem remains: it seems that the distinction between "BadScripts" and "GoodScripts" isn’t impossible — after all, are there not others browsers with marked less security issues episodes related to Scripting?!… Well, a considerable portion of the pre-SP2 exploits involved the execution of the ShortCut HH command within CHM files displayed through "window.showHelp([…])" or the yet renowned cross-Frame/Zone vulnerabilities ( code injections, mishandlings of multi-Zone situations, etc ). Now, this is past, but at what price?! IE denotes a perceptible power weakening: nearly none HTML document with some DHTML features can escape from the notorious "IE-XP/SP2 Information Bar"; meanwhile, it’s possible that end users, already satureted with so wide ( and a bit paranoid ) "precaution", are, at this time, tired and saying "yes", "yes"… without much ratiocination; by the way, the raise of the FireFox is really not merely incidental…

    Hearing about "enhanced security features" in IE7, I simply can not figure out what will be its exact behavior… Maybe, in the initialization, it will display: "Warning! — the execution of an Internet Browser can lead to potentially dangerous situations. Do you still want to proceed?"

    Hey, what about this other post, please?

  6. Marcus,

    Things like HTML Help were "just bugs", and we are removing them all as we find them. HTML Help (and other ActiveX controls) say "Hey, I’m safe!" and so IE lets script talk to them. All IE knows is whether script can access (i) no controls; (ii) "safe" controls, or (iii) all controls. It still doesn’t know "good" from "bad".

    Ideally you should not be prompted for day-to-day browsing of the web (one of the reasons why the "Information Bar" was added was to reduce the number of prompts customers had to respond to).

    You will also find that browser security bugs are, at the risk of sounding like a corporate marketdroid, "an industry problem." I am sure people are sick of us saying that, but it’s true. For example, Firefox itself has had cross-domain script injection bugs — see and the Mozilla page that it links to, for example.

    I don’t know about the HTML Help issue; I’ll forward to the IE team

Skip to main content