If JAWS or any other Windows screen reader is speaking at the login screen it has effectively been given privileges to run anywhere in a Windows XP, Vista or 7 system. Rumor says that MS has stopped this possibility in Windows 7 but I've only gossip to cite as a source and probably won't look for more about it as it doesn't really effect me.
JAWS can write to any place on your system with write privileges. About 10 lines of JAWS Script code can probably do the whole job. Window-Eyes and VoiceOver have much more protections around their script facilities as they are common parts of the OS and the architects make them as secure as possible. I don't know how orca does it but they have excellent security as well. Deep in the bowels of some programs like JAWS, HAL and Zoomtext are some really cool albeit unsecure hacks. This code, when it was really important, was really fun to make as it required changing Windows itself which was altogether too cool. We did such things for good, virus hackers and other vandals use similar techniques to do their evil. cdh On Sep 9, 2009, at 10:27 AM, James & Nash wrote: > > How would we know if JFW was reading in the Desktop user area and > what is > it? Also, where would JFW write the file? > ----- Original Message ----- > From: "Chris Hofstader" <c...@hofstader.com> > To: <macvisionaries@googlegroups.com> > Sent: Wednesday, September 09, 2009 1:07 PM > Subject: OSM Screen Reading was: Re: Voice Over with Apple Scripts, > must get > this off my chest > > > > Hi, > > Yes, it is indeed true that NVDA is the only Windows based screen > access utility that has no Off Screen Model (OSM) in any traditional > sense of the word. On GNU/Linux, orca functions without an OSM but > mouse cursor (review cursor) mode using a simulated OSM acts kind of > strange sometimes. VO does so well because of its tight integration > with the OS and because the Apple accessibility API is so damn good > that little that would require an OSM on another system is available > to the screen reader kind of by default. > > Over the past year and a half or so, NVDA has matured into a solid > little screen reader. Using MSAA, iAccessible2, some application DOM > information and possibly some of the Sun Java accessibility stuff, it > can create something of a tree like view of the screen contents. > People who work closely with sighted colleagues probably should look > for a different solution as NVDA speaks items in a logical manner and > not in any way related to the order which items appear on screen. > > NVDA, though, with help and money from Mozilla, IBM, Microsoft and > Adobe, is really growing up quickly. Because of the iAccessible2 API > (free software from IBM), NVDA works with virtually all of OpenOffice > and the other members of the gecko UI (Firefox for instance) family > of programs. MSAA gives them all of the really basic stuff but, > unlike Apple, many applications that ship with Windows use non- > standard techniques for drawing UI and, therefore, do not work > properly with NVDA. > > Mozilla keeps the boys pushing forward on Firefox andother useful free > software. Microsoft used its money to pay the guys to support user > interface automation (UIA) which will be its primary accessibility > system in Windows 7) and Adobe is paying them to support its peculiar > MSAA inplimentation that, when accessed properly, has the potential to > do a good job on Windows at least. > > The OSM solutions give application vendors a bit of a freel ride. > Before Apple added MSAA to iTunes, a JAWS user would have to buy > scripts from Brian Hartgen (a great guy by the way) to use the program > as Brian was able to hack around the video information and, from > there, build something that actually worked. Thus, if Apple never > contracted GW Micro to help with the accessibility of their Windows > version of iTunes, Brian would still be making money selling his > scripts and Apple could point to him as their accessibility solution > if anyone complained. > > The other side of the OSM coin, though, is that capturing all of those > loose bits and bytes can add a lot of instability to the overall > system. Without getting into the boring details, I'll recommend that > someone turn on JAWS on a nice XP or Vista box. Then, turn off the > screen saver, walk away and every hour or so go to the system > resources dialogue and see how much memory, handles and CPU usage that > JAWS is consuming. For all intents and purposes, these values should > be identical or at least close to identical at every visit. > Unfortunately, you will see these numbers grow at what seems like a > fairly regular pace (assuming no one has done anything else to the > computer). These strange side effects slow things down, sometimes > garble the OSM and happen for no reason anyone in or out of FS can > figure (the FS JAWS hackers would fix this in a New York minute if > they could actually figure out why and where it happens). > > > Overall, given the power of the Apple Accessibility API, the gnome and > Java accessibility stuff, MSAA, iAccessible2 and UIA, the OSM is > moving rapidly toward a long awaited death. People who work on such > things say that Windows 7 will not support a mirror driver nor any of > the other ways screen readers build an OSM. So, with luck and > believing MS and some of my friends (usually a reliable bunch of > nerds) even JAWSVID.DLL will go away pretty soon. > > The death of the OSM probably has the GW Micro and FS guys pulling > their hair out. Without the driver hooks, which caused the terible > stability problems we all know and love on Windows with the top two, > players is going to either force the mainstream application developers > to add the appropriate accessibility information using the documented > API or they will need to update their VPAT to say "not accessible to > people with vision impairment on Windows 7 or newer," which kind of > tosses a monster monkey in the fraud that has been Section 508 until > now. > > Lastly, an OSM/operating system hooking solution like JAWS and WE, > create cavernous security holes in the entire system. If my screen > reader can speak in the desktop user space (not the desktop you > interact with but, rather, a low level bit of Windows), it means that > my screen reader can see almost everything and all of the keystrokes, > mouse movememnts and clicks, and such and it can catalogue them in a > file somewhere on your system and, when you try to use your email > program, it can send the attachment with all of the high security > information anywhere it cares to. So, if you want to use a screen > reader to login to Windows, you better have some hardcore ways of > knowing that no one wrote a little but evil JAWS script to start > hacking your system. > > Scary.... > > Happy Hacking, > cdh > > > PS: On cup number 2... ) > > > On Sep 7, 2009, at 4:31 PM, Mike Arrigo wrote: > >> >> Hey Chris, it's interesting that you mention the whole off screen >> model, actually I'm amazed that voice over does as well as it does >> without one, I wonder if windows screen readers will ever be able to >> move away from this approach, I think the only screen reader that >> does >> not have one is NVDA, and from what I've heard, it's fairly limited. >> On Sep 7, 2009, at 9:09 AM, Chris Hofstader wrote: >> >>> >>> Hi, >>> >>> Probably because I was once a VP at Freedom Scientific, I see the >>> value in and strongly support adding scripting to VO. >>> >>> I agree that using scripts to launch applications from within a >>> screen >>> reader should be discouraged and I agree that some other things you >>> mention in your email should be avoided as there are other >>> techniques >>> to get the same job. >>> >>> The fear that "VO will turn into JAWS for Macintosh," is mostly >>> unfounded though. The reason JAWS needs scripts for virtually every >>> application it supports is that they have an OSM and, given relative >>> screen coordinates can tease the text drawn directly without MSAA or >>> iAccessible2 involved. This helps make the completely inaccessible >>> into something that is marginally and sometimes very accessible. >>> >>> VO has no OSM. Even with the new scripting facility, it cannot >>> correct the owner drawn interfaces (I've been trying to get VO and >>> MacSpeech Dictate to talk and its a hemorrhoid of a project). What >>> AppleScript gives us is the ability to add features to a combination >>> of programs where the authors did a decent job of making their >>> software accessible but the user would benefit from some very deep >>> contextual information that would be very difficult for a generic >>> API >>> to deliver. >>> >>> I read a post (I think on this list) about reading table headers in >>> the iWork spreadsheet. the post said it works great if the headers >>> are on the top row but starts to fail if they are elsewhere. >>> >>> So, why not write a script that allows multiple tables, each with >>> their own headings to exist in a single spreadsheet? No API is >>> smart >>> enough to do this but, I would think that a script driven >>> communication system between VO and the worksheet could do it in a >>> fairly straight forward manner. This script could also "mangle" the >>> worksheet file name in a manner that is unique so, if you reload the >>> same document, your headers will be there for you. Even cooler, if >>> you open a spreadsheet with a very similar name (Sales Report >>> 1/1/2009, Sales Report 2/1/2009, etc.) they will probably have the >>> same format and the user can be offered the opportunity to load last >>> month's headers. >>> >>> There are lots of ideas that can be expressed in scripts that a >>> generic screen reader cannot understand. >>> >>> Happy Curt Flood Day, >>> cdh >>> On Sep 7, 2009, at 8:52 AM, Jes Smith wrote: >>> >>>> >>>> Hi all. >>>> >>>> I am greatly concerned that voice over now has support for >>>> scripting. >>>> Especially now that you can make voice over launch an application >>>> with >>>> a single script. I'm not talking about glancing at the time or >>>> seeing >>>> how many unread messages you have in mail. I'm talking about >>>> opening >>>> up apps like mail or Safari from within Voice OVer. I am concerned >>>> that voice over is starting to become a bit like Jaws, and that if >>>> we >>>> don't get a grip on it now, voice over will become Jaws for >>>> Macintosh. >>>> I, like Mike Arrigo, don't feel that launching apps is something >>>> that >>>> should be implemented in a screen reader. Also, I fear that the use >>>> of >>>> apple scripts will replace the responsibility of an application >>>> developer to make their application accessible right out of the >>>> box. >>>> On the Windows side, if something isn't accessible with Jaws, you >>>> just >>>> download scripts for it. What if you go to another person's >>>> computer >>>> and they don't have the scripts for the app you are trying to use? >>>> It's my belief that a certain article from the NFB prompted this >>>> scripting support. Folks, the thing I like about voice over is that >>>> it >>>> gives the blind user the same conceptual layout and information as >>>> it >>>> appears on the screen to a sighted user. No other screen reader >>>> does >>>> this, and we should keep voice over as a screen reader, and let it >>>> be. >>>> If we don't, eventually, when we try and contact an Apple >>>> developer, >>>> they will either ignore us, or will say, "Well, just download the >>>> scripts for my application and you will have access." >>>> Any thoughts? If someone disagrees with me, I'd love to hear your >>>> arguments, not so that I can persuade you to agree with me, but so >>>> that I can have a new perspective. >>>> >>>> Jes >>>> >>>> >>>>> >>> >>> >>>> >> >> >>> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To post to this group, send email to macvisionaries@googlegroups.com To unsubscribe from this group, send email to macvisionaries+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/macvisionaries?hl=en -~----------~----~----~----~------~----~------~--~---
