Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Mozilla The Internet Security

Firefox Greasemonkey Extension Security Problem 443

Mr2001 writes "A recent thread on the Greasemonkey mailing list suggests that the popular Firefox extension is fatally insecure. It seems rogue pages can read any file from your disk and send it to any site, using an XmlHttpRequest. Time to uninstall GM?"
This discussion has been archived. No new comments can be posted.

Firefox Greasemonkey Extension Security Problem

Comments Filter:
  • by rockytriton ( 896444 ) on Tuesday July 19, 2005 @10:44AM (#13103344)
    It's about time people start writing some exploits for firefox! []
    • Re:It's about time (Score:4, Insightful)

      by Mantus ( 65568 ) on Tuesday July 19, 2005 @11:21AM (#13103733)
      I'm not sure why this post got modded as flamebait, It's somthing that will happen. As FF gets more popular more holes will be found, some won't get reported right away. MS aren't the only people that don't write 100% secure code.
  • gauntlet (Score:4, Funny)

    by Anonymous Coward on Tuesday July 19, 2005 @10:45AM (#13103352)
    Rogue pages???

    Quick, lets band together with a magician and a warrior and stomp those bow&arrow shootin mofos before they take over the internet!

  • Damn Microsoft! No doubt this can be traced to a Bill Gates directed consipracy against rebel browsers.

    • Although the "average user" won't be using the various plugins, Microsoft will still point to this as one more reason to say that FireFox isn't secure. Sure, FireFox has it's bugs. We need to get fixing them.

      I'm not saying that FireFox is perfect. Obviously, it's not, and this article is a case in point. It's still the browser I use. For me, this is a warning to fix things or wait for them to stable up (oh yeah -- that mindset shown, I am a Debian user). But just like we use any little IE thing to say "Se
      • by Zeinfeld ( 263942 ) on Tuesday July 19, 2005 @11:41AM (#13103917) Homepage
        Although the "average user" won't be using the various plugins, Microsoft will still point to this as one more reason to say that FireFox isn't secure. Sure, FireFox has it's bugs. We need to get fixing them.

        And the winner of the Slashdot "Who can be the first to blame Microsoft for a bug in FOSS is..."

        The problem is not bugs, the problem is that nobody designed their systems to deal with the real security threats presented in the Internet today.

        The principle cause of Microsoft's security problems today was their addiction to 'featuritis' in the 1990s. If you think that the open source community does not have the same problem you need to take a serious look at some FOSS programs.

        There is nothing that can't be fixed but first people have to realize that FOSS has just as much need to fix them. Everyone in the security community will tell you that making the source code available does not guarantee that your code will be secured. We have enough trouble getting engineers to review their own code.

        We need a new approach to writing secure code. Before that can happen a lot of FOSS people need to loose their complacency. Microsoft is not the enemy here, the criminal gangs are the enemy.

    • by wheany ( 460585 ) <> on Tuesday July 19, 2005 @11:01AM (#13103540) Homepage Journal
      Okay, how's this: Since Microsoft Internet Explorer has a dominant market share, people make pages that work on IE. Some of the pages do not work on Firefox since they use some functionality found only in IE. Greasemonkey can be used to alter some of those pages so that they work on Firefox again.

      It's Microsoft's fault that people have to install insecure extensions to make web work like it should have worked in the first place.
  • by ScentCone ( 795499 ) on Tuesday July 19, 2005 @10:45AM (#13103357)
    are going to produce some vulnerabilities along with the gee-whiz plugins of the moment. That's pretty spectacular, though.
  • More Ammo (Score:5, Insightful)

    by GuitarNeophyte ( 636993 ) on Tuesday July 19, 2005 @10:46AM (#13103365) Homepage Journal
    Just more ammo for the mega-powers to say, "See, when it becomes mainstream, it becomes more insecure. Come back to windows."


    Be smart. Teach others. []
  • Why Uninstall? (Score:5, Informative)

    by SenFo ( 761716 ) on Tuesday July 19, 2005 @10:47AM (#13103375) Homepage
    "Time to uninstall GM?"

    Why not just do what the article says and "Install Greasemonkey 0.3.5 []"
    • Re:Why Uninstall? (Score:5, Insightful)

      by DrEldarion ( 114072 ) <[moc.liamg] [ta] [0791uhcsm]> on Tuesday July 19, 2005 @10:51AM (#13103420)
      See, you're making the (frequently-made) mistake of assuming that people actually read anything but the headline of the articles they're referencing.
    • Re:Why Uninstall? (Score:5, Informative)

      by phasm42 ( 588479 ) on Tuesday July 19, 2005 @10:51AM (#13103427)
      Greasemonkey 0.3.5 is a "neutered" version of Greasemonkey, lacking any of the GM* APIs which make Greasemonkey scripts more powerful than regular HTML. This means that scripts which depend on GM* APIs will fail with Greasemonkey 0.3.5.
      • Re:Why Uninstall? (Score:3, Insightful)

        by tgd ( 2822 )
        I bet you a dollar those scripts won't work if you uninstall GreaseMonkey, too.
      • Re:Why Uninstall? (Score:5, Interesting)

        by jdavidb ( 449077 ) on Tuesday July 19, 2005 @11:19AM (#13103703) Homepage Journal

        I thought that GM was a way for me, the web user, to impose some scripted changes onto pages. I didn't realize it was used by site-designers to do anything HTML (+JavaScript, etc.) didn't allow.

        I don't want to give site-designers any more power, so if that's prevented by neutering GM, I'm fine with that.

        • Re:Why Uninstall? (Score:3, Informative)

          by Anonymous Coward
          The idea is that the scripts which you let loose on the page can use the GM API to do things which are beyond (unsigned) web scripting, like reading a preferences file. These capabilities are only meant to be used by GM scripts. The problem is that scripts don't work on the page "from the outside". They are injected into the page. The GM API can't properly tell a webscript from a GM script. Consequently webauthors can access the GM API from scripts which come with the webpage. It's cross site scripting, so
      • Re:Why Uninstall? (Score:4, Informative)

        by sketerpot ( 454020 ) <> on Tuesday July 19, 2005 @12:22PM (#13104286)
        This isn't a big deal. It means you lose: 1. Logging of GM script debug messages. Inconvenient if you're a script author, but not for anyone else. 2. Script-specific configuration values. I don't think these are commonly used, but they could be nice to have. Oh well, chances are your scripts will keep working. 3. Adding commands to the Tools->User Script Commands submenu. If, like me, you didn't know this submenu even existed, no loss. 4. Fancy GM_XmlHttpRequest. This is just like XmlHttpRequest but without domain restrictions. This may cause a few extensions to stop working (not many, but a few), but it also closes the security hole.
    • Well, this is the recommended course of action. However, Greasemonkey 0.3.5 is crippled. It does not contain the special GM_ functions so the majority of scripts will break.

      Anything that uses GM_XMLHttpRequest, GM_setValue or GM_getValue or GM_Log will not function. It was the developers attempt to make sure that no remote exploits popped up while they were working on the best possible fix.

      So, no. Don't install the update and expect things to function normally, they will not.

    • As far as any normal user is concerned, there is no GM update, since going to the Extensions manager and clicking update for GM yields "Firefox was not able to find any available updates" (this is the case for me at least).

      In fact, as far as anybody should be concerned there is no installable update. I'm not about to install some random-ass XPI just because it claims to be a GM "fix".

      As much as I like using it, I'm uninstalling. And this gives me the willies about all those semi-random but cool extensio
      • I take back the bit about the XPI being "random-ass" since it's linked from mozdev. I originally only read the first link in the article, not the second (and the link provided by the parent post didn't work for me).
  • by sykjoke ( 899173 ) on Tuesday July 19, 2005 @10:47AM (#13103376)
    The firefox guys should have realized that extensions are a HUGE security threat, possibly even worse than anything that's come out of IE. What they should have done is setup some permissions from the first place, so that you can allow or prevent extensions from performing sensitive operations. Something similar to the Java security model would have been good enough
    • by cybersaga ( 451046 ) on Tuesday July 19, 2005 @10:52AM (#13103440) Homepage
      This is why Firefox makes you whitelist a site before downloading an extension.

      Forcing you to intentionally accept extensions is not a big security threat at all.

      This is just a bug. Bugs happen. It's been fixed already.
      • Though the whitelist brings in its own problems when you want to install from a site that's not in the whitelist. Is there any way of doing a one-off installation from a site not in the whitelist? There are quite a few pages where I'd like to install a single extension but not allow the page to install whatever it likes on my computer!
      • by telecsan ( 170227 ) on Tuesday July 19, 2005 @12:01PM (#13104125)
        Even after you've installed an extension, you shouldn't be forced (by Firefox) to accept any and all behaviour it tries to produce. I should be able to install a toolbar and prevent it from calling home, for example. You should be able to set the permissions or at least the 'run-as' of the toolbar separately from the permissions of Firefox. Surely the security-conscious /. community should realize that.
    • by Buzz_Litebeer ( 539463 ) on Tuesday July 19, 2005 @11:01AM (#13103536) Journal
      That is incredibly uninformed. IE can run Browser Helper Objects, and they can (many times) be installed completely silently. A cleverly written BHO can steal all information you are entering into your computer, even if it is unrelated to actual browsing, depending how clever the person is in writing it. They are a pain to uninstall as well. Extensions for firefox are uninstallible from a menu, and they are whitelisted before they ever get to you, so that you can avoid some of the fly by installs that BHOS enjoy.

    • by Anonymous Coward
      I agree completely!

      I have stated it here before:

      Just like ActiveX controls proved a hole in IE, FireFox's extensions would eventually prove a hole in the XUL based 3rd party FireFox extensions arena now & this browser itself, & thus, your OS etc. as well via this gateway.

      This is/was 1 thing FireFox imo, had on Opera (my 'browsing weapon-of-choice' online because it wins the speed test comparisons between them all in the most areas typically, but also because it is the LEAST attacked browser as we
    • Exactly! (Score:3, Insightful)

      by GillBates0 ( 664202 )
      I would've typed in an almost identical comment had I not bothered to RTFC.

      No matter how secure the core Firefox code is, it is all meaningless with the current extensions model. With the current model (or lack of one) a malicious (or plain buggy) extension can turn Firefox into a bigger threat than IE.

      From my understanding, Firefox extensions aren't restricted from doing I/O or listening on sockets/etc. What's to prevent somebody from writing a seemingly harmless extension which silently dumps all act

      • by jfengel ( 409917 ) on Tuesday July 19, 2005 @11:20AM (#13103719) Homepage Journal
        Why would you say that a sandbox model is overly restrictive? The Java sandbox model has many routes out; it means that you can specify what permissions an application has, not forbid all of them. The Java model comes with nearly all permissions set to "no", but they can be opened.

        That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).

        Still, that's asking the user to make a lot of security judgments based on trust. Some extensions/applets/ActiveX should be allowed to modify your hard disk; most shouldn't. How can the user tell?

        It's a hard problem, one that I don't have a good answer to. I know Microsoft's solution (based purely on a yes/no trust decision) sucks. But I'd say the problem isn't the over-restrictiveness of the sandbox, but the difficulty of asking the user to manage his/her sandbox well.
    • The firefox guys should have realized that extensions are a HUGE security threat

      The Firefox guys did; fortunately this has very little to do with FF extensions! It's an issue with GreaseMonkey User Scripts, which are javascript files run by the Greasemonkey extension. Extensions are OK; certain Greasemonkey user scripts *may* not be.

      For anyone who's never heard of GreaseMonkey - DON'T PANIC! It doesn't affect you: nothing to see here, move along, please.

      For folk who use GreaseMonkey, continue to exer

      • It is a problem with Firefox allowing GM to have such privileges. Do you always log in as administrator or root? Have you edited the source code of postgress so that is can also run as root? So why should Firefox give root to any extension that comes along?
    • Hyperbole (Score:3, Insightful)

      While some kind of "security" layer sounds nice, I'd like to know what you suggest, specifically. A popup box saying "this site is requesting permission to read file X"? User clicks ok, every time, and they quit looking at it after a while. Then you wrote this:

      a HUGE security threat, possibly even worse than anything that's come out of IE.

      • You can always uninstall the extension (but you can't uninstall part of IE)
      • An extension only affects the portion of the installed base that uses it
      • The m
  • Fixed? (Score:2, Informative)

    According to Firefox extensions site [], you need to "uninstall or upgrade now." The post is from today.
    • Re:Fixed? (Score:2, Informative)

      From the GreaseBlog []:
      Greasemonkey 0.3.5 is a "neutered" version of Greasemonkey, lacking any of the GM* APIs which make Greasemonkey scripts more powerful than regular HTML. This means that scripts which depend on GM* APIs will fail with Greasemonkey 0.3.5.

  • Opera's answer... (Score:3, Informative)

    by TheJavaGuy ( 725547 ) on Tuesday July 19, 2005 @10:48AM (#13103386) Homepage
    Time to try out Opera's User JavaScript [].
  • by Nytewynd ( 829901 ) on Tuesday July 19, 2005 @10:48AM (#13103391)
    If you build an engine that allows you to write scripts that modify any page you view, there are obviously serious security flaws.

    Allowing scripts to open files and send them elsewhere is especially bad, but there was a huge security concern to me either way. I like the concept of GreaseMonkey, but choose not to install it.
  • by octaene ( 171858 ) <> on Tuesday July 19, 2005 @10:49AM (#13103394) Homepage

    Here are some more details from the posting thread, which explains why the exploit is so bad...

    This particular exploit is much, much worse than I thought. GM_xmlhttpRequest can successfully "GET" any world-readable file on your local computer. ile-leak.html [] returns the contents of c:\boot.ini, which exists on most modern Windows systems.

    But wait, it gets worse. An attacker doesn't even need to know the exact filename, since "GET"ting a URL like "file:///c:/" will return a parseable directory listing. (And Mac users don't get to gloat either; you're just as vulnerable, starting with a different root URL.)

    In other words, running a Greasemonkey script on a site can expose the contents of every file on your local hard drive to that site. Running a Greasemonkey script with "@include *" (which, BTW, is the default if no parameter is specified) can expose the contents of every file on your local hard drive to every site you visit. And, because GM_xmlhttpRequest can use POST as well as GET, an attacker can quietly send this information anywhere in the world.

    The above information posted originally by Mark Pilgrim []

    • OMG! I hope I don't get exploited... or the attackers may get hold of this exciting information:

      bin boot dev etc home initrd lib lost+found man media misc mnt opt proc root sbin selinux srv sys tftpboot tmp usr var
  • Here's TFA (Score:3, Informative)

    by RamboIII ( 899894 ) on Tuesday July 19, 2005 @10:49AM (#13103396)
    Important Announcement

    A severe security issue has been discovered in Greasemonkey versions prior to 0.3.5 as well as the early 0.4 alphas which some people may have installed.

    Install Greasemonkey 0.3.5 or uninstall Greasemonkey immediately.

    More information on Greaseblog.

    Greasemonkey is a Firefox extension which lets you to add bits of DHTML ("user scripts") to any web page to change its behavior. In much the same way that user CSS lets you take control of a web page's style, user scripts let you easily control any aspect of a web page's design or interaction.

    For example, you could:
    Make sure that all URLs displayed in the browser are clickable links Improve the usability of a site you frequent Route around common and annoying website bugs Use the Coral content network selectively.

    Getting started:
    Install Greasemonkey 0.3.5. Learn how to use Greasemonkey. Find useful scripts.

    Greasemonkey was heavily inspired by Adrian Holovaty's site-specific extension for All Music Guide and the conversation which ensued after he published it. There were tons of sites I wanted to create SSE's for, but fully-fledged firefox extensions proved too cumbersome. I wanted it to be as easy to create an SSE as it is to write DHTML.

    The current maintainers are Aaron Boodman and Jeremy Dunck with the invaluable help of an awesome community of user script enthusiasts.

    For questions or comments about greasemonkey, please send a message to the greasemonkey mailing list. Copyright © 2000-2005. All rights reserved. Terms of Use & Privacy Policy.

    Notice hoe they avoid explaining the problem/solution. They just want you to see these new exciting features, and download it now!

    • Be fair. The "More information" section is pretty standard copy for a press release format. Most press releases take that approach. If users want a more technical detailing of the problem, a media release isn't the place.
  • Our Fault (Score:5, Funny)

    by Comatose51 ( 687974 ) on Tuesday July 19, 2005 @10:49AM (#13103403) Homepage
    This is why God invented the tag.

    We can blame God for all kinds of things like hurricanes and Godzilla but it's a safe bet that we brought THAT scourge upon ourselves.

    • This is why God invented the tag.

      We can blame God for all kinds of things like hurricanes and Godzilla but it's a safe bet that we brought THAT scourge upon ourselves.

      Hey, now! We all know perfectly well that Godzilla was a result of the United States dumping radioactives into ocean waters, part of their plan to keep on supressing Japan after the war. After all, if Tokyo hadn't been leveled by Godzilla every 6 months, Japan would have taken its rightful place as ruler of the world!

  • Personally, someone could read my entire hard drive and it wouldn't bother me much. I don't keep sensitive information on my computer, because any computer connected to the internet should be considered insecure.
  • It's open source so millions of eyes have studied it to make sure it's secure...
  • Uninstall / Remove (Score:2, Interesting)

    by dhanes ( 735504 )
    After all of a quick 3 minute search of Pilgrim's site and Firefox, I can't find any directions as to how to actually uninstall or remove greasemonkey.

    Would anyone have that info to post?? Thanx

  • by Arthur B. ( 806360 ) on Tuesday July 19, 2005 @10:56AM (#13103485)
    Firefox burns greasemonkey cuz it's made of fat But Seamonkey beats firefox because it extinguishes the fire. Then Greasemonkey beats seamonkey because it can float in water AND walk on land. my 2.56 cents
  • Oh, wait I don't browse as root already!
    Guess it can't access "all" the files on my system then, can it?
  • by Anonymous Coward on Tuesday July 19, 2005 @10:59AM (#13103507)
    (MAN) Sirs, I am in dire need of a web-browser! The one thus furnished to me by Mr. Gates of Redmond is rickety and unsafe, and prone to inviting the most deadly of spy-ware into my parlor!
    (MOZILLA SOCIETY REPRESENTATIVE) Why, good sir, we shall help you forthwith! We have exactly the web-browser that you need! It has been engineered to the most careful of specifications, and its security is without compare!
    (MAN) Why then I shall have one immediately!


    (RANDOM STREET URCHIN) Sir, I see that you have this day procured a web-browser, which I see under your arm. May I convince you to also take this complex contraption of my own invention, which will attach to your web-browser as a "plug in"?
    (MAN) What, what? An inscrutable device of unclear ultimate function furnished by a stranger of whom I know nothing? Yes, yes, why not. Now run along, lad.


    (MAN) What's this? Oh, mama! The web-browser I have this very day recieved from the Mozilla Society has immolated, consuming my drapes and lighting my house aflame. They told me it was secure! Lies! Betrayal! Those Mozilla Society rapscallions! I'll give them what for!
    • Open source advocates do themselves no credit when they say "Spyware which takes advantages of weakness in the design of IE is Microsoft's problem, but spyware which takes advantages of weakness in the design of Firefox is the author's problem". If this were MSIE you can be 100% sure that somebody would be saying "Why, why, why does Windows even ALLOW users to run untrusted code?"
  • by Felinoid ( 16872 )
    "It's not a bug it's a feature" are quite likely words never actually spoken by any representive of Microsoft.
    However there is a reason for this attatude.

    Bug that makes it possable to run code on remote users box:
    Users say "Oh no bug bug. Get rid of it"
    Develupers say "Ohh feature feature keep it, expand it"
    Security experts say "Bug"

    If the develupers provide a strong enough argument the "bug" is classified as a feature and remains.

  • It seems rogue pages can read any file from your disk and send it to any site, using an XmlHttpRequest.

    Only if the browser has all the rights, which is a very dumb thing to do no matter the platform.

    On my main Un*x box, Firefox was installed in a normal user account (using the .tar.gz) and there's no way that a "Firefox expl0it" can access any file on my hard disk (and btw the risk for this particular exploit is zero: I don't use GM ;)

    I'm pretty sure that Firefox/GM installed in a non-privileged
  • 1986 (Score:5, Informative)

    by Spazmania ( 174582 ) on Tuesday July 19, 2005 @11:15AM (#13103672) Homepage
    In 1986 I wrote a Commodore 64 terminal program that allowed BBS' to download and run bits of assembly code onto the user's machine in order to enhance the user's experience. It took about 48 hours before someon posted a message that executed a jump to address 64738 -- system reset.

    Bad idea then. Worse idea now, no matter how much supposed security you surround it with.
  • by ded_guy ( 698956 ) on Tuesday July 19, 2005 @11:17AM (#13103685)
    I admit that I haven't yet tried out GreaseMonkey, but when I look at the exploit code it raises one really big question. Why isn't there some way to prevent non-user script from accessing the GreaseMonkey objects? Wouldn't this allow the user to retain all the ability they have now while rendering scripts from malicious sites harmless? Seeing as how GM is meant to be a means for the user to use scripts to modify pages, it seems very odd that anything outside of user script would be able to access its functionality.

    I realize it's likely due to the nature of Firefox's JS interpreter, but if this sort of separation isn't viable could someone enlighten me as to why?
    • by Rits ( 453723 ) on Tuesday July 19, 2005 @11:54AM (#13104058)
      Greasemonkey inserts the script directly in the pages, so the GM scripts have the same security context as the page itself. Or so I've understood, correct me if I'm wrong.

      In the really integrated solution like Opera has (as opposed to an extension like GM is), userscripts have their own security context. The really powerful functions in Opera's userscript are not available to the page author. All functions in GM, including the most powerful, are available to the page author, and Mark Pilgrim just found out this includes unlimited read access to your local file system.

      The GM developers are aware that this is a problem, but haven't developed a better way yet to inject the scripts in the page. So the newly secure release 0.3.5 removes the most powerful functions.

  • by sheldon ( 2322 ) on Tuesday July 19, 2005 @12:20PM (#13104263)
    I'm gonna get troll rated for this, but whatever.

    So basically... Mozilla is just as much of an insecure platform as IE, because they allow plug-ins.

    Yeah, yeah.. It's Greasemonkey... it's some stupid add-in piece that you have to explicitly install.

    But that's also the way most spyware get's on IE. People get prompted "Please download and install this, and make sure you say 'Yes' when prompted is that ok?"

    and people do it...

    why? Because they are promised free porn, free poker, free music, or a free trip to Nigeria to collect their $10 million.

    Welcome to the real world!
    • Mozilla is just as much of an insecure platform as IE, because they allow plug-ins.

      Not quite.

      The big problem with IE is not just that it has a plug-in mechanism, but it has a plug-in mechanism that's based on the HTML control (the actual browser component) assigning the right to install plugins to an object (the web page) based on an ad-hoc security model that's based on the location the object is believed to originate. Certificates, security dialogs, and so on... these are layered on top of this, but basically the HTML control is responsible for figuring out if a "dangerous" action should be allowed with no more than hints from the calling applications, and a jargon-filled dialog box that the user has to decide on RIGHT AWAY.

      I get calls from my users all the time that are variants on "this dialog box came up and I hit 'yes' without thinking".

      So... the control is pervasive, it's used by lots of applications, the API can't be significantly changed without creating a mass upgrade day for every app that uses it, responsibility is placed in the wrong place, and the user interaction encourages mistakes.

      Firefox's extension mechanism has a similar problem with its installer, but:

      The extension installation mechanism is part of Firefox, not the Gecko HTML display object, so applications using gecko aren't automatically exposed as well.

      The Firefox extension API does not depend on the installer's behaviour, it's possible for Firefox to switch to a more secure download-and-install design without breaking any applications.

      The user interaction requires three separate steps, and there's no path through those steps that simply answering "yes" by reflex will result in the extension being installed.

      In addition, in Windows, there have been a number of attacks that involved tricking the HTML control into thinking that a remotely downloaded object was local... or even already installed. This approach is not possible in Firefox because instead of allowing plugins to run from anywhere except the places it thinks are dangerous, it doesn't allow plugins to run from anywhere except a specific directory that's got a randomly generated name in its path so it can't be targeted by a download.

      I would still recommend using a shell other than Firefox around a Gecko- or KHTML- based browser. I use Camino (Gecko) and Safari (KHTML) on Mac OS X, but I'm sure there are equivalents to these for Windows. But regardless, the exposure from using Firefox is so far less than using IE that if Firefox and IE are your only choices... use Firefox.

      I do not recommend using the Netscape browser, because of the way it allows the use of either Gecko or the Microsoft HTML control.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington