Re: Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox
toggle quoted messageShow quoted text
It is there as part of a foundation for a very huge work that’ll fundamentally change how screen readers think about communicating with web browsers. The story goes like this (and if you want, please do pass this onto others):
In the early days of web accessibility for screen reader users (back when there was no UIA, no visible standards organizations for accessibility, etc.), the only effective way for screen readers to present web content was sending out “scouts” who’ll bring back envelopes containing the entire HTML code for a webpage. These scouts would use a highway called “code injection” to speed up their travel. Once the envelopes are opened, screen readers will thread the contents together into a “navigable document”. In other words, a web document was constructed twice for you: once on the web browser window, and rendered by your screen reader a second time on top of that.
The advantage of this method is that screen readers knew where things were, because they had a “map” in front of them that pointed to where the next given element was, listing postings with routes to links on the document and so on. This meant navigating around a page was simple and very fast. However, this opened a chasm: if a screen reader was walking along a path and was “kidnapped” one day, the “kidnapper” would force the screen reader to give commands to “scouts”, whose only job was to fetch something on behalf of their leader.
Fast forward almost two decades, and current screen reader and web browser landscape is filled with those who travel by the code injection highway, and those who send and receive “letters” and “beacons”. The former is the case with Internet Explorer and older versions of Firefox, and the latter is for Microsoft Edge. These days, more web browsers are asking screen readers to send more letters than scouts, which has huge implications for users and developers.
Technical (if you want, please do send this out to others): first, some definitions:
With this in mind, the geeky version is as follows:
When MSAA first came out in late 1990’s, it was designed to let screen readers receive information about program controls, mostly static ones. Hence, it wasn’t really designed for places such as web browsers where document content can change without notice. For this case, screen readers will inject part of their code (typically in the form of a DLL) inside a web browser process to monitor events such as when a website is being loaded. Once the DLL realizes that you’ve navigated to a new page, it’ll fetch the entire HTML code for that page and send it back to main screen reader code. This main code, typically in the form of a document formatting library, will construct (technically, reconstruct) a webpage according to rules it knows best.
But imagine a malware comes along and takes over a screen reader (which can actually happen if a malware holds special privileges and exploits a weakness in screen readers). Unless the malware doesn’t know about it, it now has a way to inject itself into other processes (not just web browsers) in the form of a screen reader DLL or redirecting the DLL’s operation to the malware module. This is made more possible by the fact that screen readers are deemed TRUSTED by operating systems, which means screen readers can perform tasks other programs are envious of (including starting early). This is perhaps one of the most critical security holes that can be opened by anyone (besides taking over an operating system routine or an important DLL or a driver). In theory, you can get around this by starting a pristine (clean) screen reader, but even that can be attacked if the malware wishes to do so.
These days, web browsers are taking the initiative to close the code injection gateway. An early start was some old browsers, including Internet Explorer 7, but even then, screen readers have found a way to open the gateway. Due to security concerns, Microsoft Edge will not allow code injection; instead, screen readers are asked to use UIA to communicate with Edge and to yield document navigation routines to Edge itself. Same will happen with a future version of Firefox, but we don’t know when that’ll happen. NV Access is taking this possibility seriously and are actively working with Mozilla to rectify this as soon as possible (also, don’t forget that a former NVDA developer is now working for Mozilla Foundation, and NV Access and Mozilla have a good relationship regarding mutual support, especially when it comes to web standards and accessibility).
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Gene New Zealand
Sent: Wednesday, October 25, 2017 9:23 PM
Subject: Re: [nvda] Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox
Why would they put in such a setting?
I am guessing if checked it would speed up the browser for the sighted but be use less if checked for us.
On 10/26/2017 4:50 PM, Joseph Lee wrote:
Check out my website for NVDA tutorials and other blindness related material at http://www.accessibilitycentral.net Regardless of where you are in New Zealand if you are near one of the APNK sites you can use a copy of the NVDA screen reader on one of their computers. To find out which locations (or location) is near to you please visit http://www.aotearoapeoplesnetwork.org/content/partner-libraries (Aotearoa People's Network Kaharoa). To find an NVDA certified expert near you, please visit the following link https://certification.nvaccess.org/. The certification page contains the official list of NVDA certified individuals from around the world, who have sat and successfully passed the NVDA expert exam.