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
else
DoSomethingEvil();
Comments
- Anonymous
August 05, 2005
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: http://www.microsoft.com/BuyOffice/ <http://www.mircosoft.com/Buy0fflce/> .. 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. - Anonymous
August 05, 2005
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="www.some_marketing_company.com/client=www.example.com/redir.aspx?guid=123456789">www.example.com</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 chtah.com) - Anonymous
August 06, 2005
The comment has been removed - Anonymous
August 07, 2005
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 :-) - Anonymous
August 08, 2005
The comment has been removed - Anonymous
August 08, 2005
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 http://blogs.msdn.com/ie/archive/2005/05/09/415800.aspx 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