This is a story of my wife Wendy. She was surfing the net when her browser locked up with an error message on the screen and a repeated warning playing through the audio. It said her computer was infected, and she could get help by calling this number. Well she runs a mac, and they don't get viruses very often. It can happen, but not very often. No, it seemed to be web page specific. She runs chrome. We poked around for a while and realized it was stuck fast, and the only way out was a force quit. This is like the quit signal in unix, or control alt delete in windows. Chrome was blown out of the water. We brought it back up and it asked if we wanted to resume where we left off. "Hell no!", that's what caused the problem in the first place. So it came up fine. To be safe I cleared the cache and the internal temp files. She's been browsing since then with no trouble. So I don't think it was a virus in her machine, but rather, a carefully crafted and malicious web page.
This relates to our discussion of 1 or 2 processes. There are many advantages to one process, so many that it will probably win the day, but the biggest con, as Adam pointed out, is the way js could monopolize the cpu, whence all of edbrowse is locked up. I wonder though, is this what happened to Chrome? Did the bad web page simply put js in an infinite loop, so there it sits? I wanted to study it, but I didn't get the url of the page, and it's probably dynamic anyways, cause they don't want to get caught. We could make our own though, with an infinite js loop, and see how the various browsers deal with it. It would be nice if there was a flag that duktape checked from time to time, and if set, duktape would stop execution. This flag would be set by the signal handler for SIGINT. Then we would have a breakout mechanism. I don't think duktape does that, but we have lots of native methods, I wonder if any of those could watch for this flag and somehow stop execution. That won't help if the infinite loop is while(true) ; but if it's a complex runaway loop creating nodes or running timers or innerHTML or such, then we might be able to stop it. Definitely something to think about. Karl Dahlke
_______________________________________________ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
