Re: Concern about the latest Window Eyes scripting move

  • From: "Raul A. Gallegos" <raul@xxxxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Mon, 11 Feb 2008 11:18:13 -0500


Whether the Window-Eyes script is running in process or out of process doesn't degrade or enhance what the script can and can not communicate with. The benefit of being in process is it is able to communicate with Window-Eyes much fast as cross-process calls are not necessary but you lose nothing at all by being in process. So you would not lose access to WScript.Shell or WScript.FileSystemObject as you specifically listed.

Regarding the Window-Eyes method being more prone to having a virus is not true as you mentioned, Any script can have a virus no matter what just as any attachment in you email can have a virus. I never open an attachment from a source I don't trust and I wouldn't run a script from a source I don't trust. Window-Eyes will have the ability to only run signed scripts with the ability to allow you to sign a script that is only valid on your machine. Security is taken very seriously by GW Micro and we will take every step necessary to keep malicious people from taking advantage of this new powerful ability within Window-Eyes.

Hope this helps.

Chris Meredith said the following on 2/10/2008 3:18 PM:
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.

Raul A. Gallegos -- GW Micro Technical Support
Voice: 260-489-3671 -- Fax: 260-489-2608
View the list's information and change your settings at

Other related posts: