If Window-Eyes executes your script in-process, then the script is limited to those functions Window-Eyes makes the scripting engine aware of, plus the COM objects that can be accessed by any script running in Windows (Does this include things like WScript.Shell and WScript.FileSystemObject, does anyone know?). As far as whether using standard scripting languages like VBScript or JScript opens up more paths of attack, all Window-Eyes is doing is opening *ITS* properties, methods and events to COM clients (so, I suppose, the potential is there for a Window-Eyes virus that might break your settings, but negligibly more so, if at all, than a JAWS script written for the same purpose). JAWS, you'll note, is also a COM client, so that if it could create objects such as a FileSystemObject or a WScript.Shell object (which, I'm thinking, are only creatable within the context of the Windows Script Host (although I'll have to check some of the code I do testing on to verify)), one could do just as much damage as one could with a VBScript or JScript file written for Window-Eyes and executed in-process. From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of John Greer Sent: Monday, February 04, 2008 11:55 AM To: programmingblind@xxxxxxxxxxxxx Subject: Concern about the latest Window Eyes scripting move Once I got over the initial shock and amazement at GWMicro's decision to make Window Eyes scriptable. Especially in such a powerful way as to let it be scriptable with many different scripting languages, I began to think. Would that not also open Window Eyes and Windows up to a whole new world of script based viruses? VBScript and Java Script are after all 2 of the languages that have that sort of power. It just concerns me a bit that in GWMicro's rush to become the top screen reader, that they may have actually open the flood gates a bit too wide.