While posting about usability of alert, I was chatting with a friend who saw it not just as a minor nuisance, but a greater threat. Since alerts interfere in user activity in other tabs, we have a basic case of client side DoS, he said.
After thinking about it, I’m inclined to agree.
Older browsers didn’t have this problem: they were not multi-tabbed. And window switching is certainly not disabled by any modal pop-ups.
Browsers evolved, tabs arrived. Today I have 15 tabs opened in my browser. And then say someone sends me a nicely obfuscated script which simplifies to this:
javascript:eval("for(i=0;i<554;i++) alert(123)");
Works nicely in FireFox. Stops me from accessing other tabs altogether till I succumb to the pressure 554 times (and I might not even know the actual figure if its jumbled code)
And lets not forget that this error can be caused without malicious intent. Say some webpage gives out two or three alert messages in a loop, and the loop counter goes haywire because of a corner case which wasn’t tested. It still is a block on all activity in the browser, whether the user likes it or not.
I’m not saying this is some awesome loophole in browser security. But it certainly is more than an irritant if I’ve paid by credit card in another tab, and the site is waiting for me to perform the next step.
The graceful solution for this is to have dialog boxes modal with respect to their own tab. This satisfies all legacy requirements of an alert as well. Currently, browsers have just provided a knife to play with.
Update: This problem has been reported in Mozilla as a bug, verified as a FireFox DoS as early as November 2000.
I think this is really a common problem for web-developers. I’ve fallen into this trap several times myself (accidentally created an infite loop around my debugging alert()). But instead of aborting all scripts, I’d like to have something similar to the “A script on this page is causing Mozilla to run slow” message with the option to abort the script.
Another user writes:
The page in the URL (don’t open it unless you know what you’re doing!) “locks” the user in an endless stream of JavaScript alerts. There is no way out; closing the popup just opens a new one; UI is unresponsive in *any* place except the popup; you can’t cancel the loading of the page (or do something like ESC to stop the script) since the UI is blocked by the popup. The perfect anti-Mozilla DoS.
January 17th, 2009 at 7:56 pm
Don’t think modal boxes in tab-contexts would help.
You could still deny access to the parent window … If I have a browser with no tabs, I don’t get access to the parent window in an infinite loop of alert.
You could argue that I could kill it/spawn another, but it’s still a DoS. Think of it on an embedded/mobile platform … Killing an app isn’t as easy too … WM 6 in fact ships with an updates IE with JS support.
To top it all, what if you have an add-on (or by default behavior) open up previous page on respawn (after kill)?
alert originated as a debugger’s tool, keep it that way. Handle bad-behavior internally.
January 19th, 2009 at 9:57 am
Agreed. I never thought about mobile platform.
Need a wider perspective. Need a PDA as my birthday gift