Hi Mihai, On 25.09.2018 20:21, Mihai Hanor wrote: > Hi Klaus, > > When you say that the devs have been working on it, are you referring > to the 5.2.18 release build, the testing builds or the svn? I've build > today a svn on Windows 10 and the Windows Narrator is not able to read > the VM window menu controls. All I hear for it is "pain"/"main" or > something similar, I'm not sure what it's saying. It's only able to > read the VM window title. The same thing happens with 5.2.18.
The work on accessibility has been during the 5.2 development mainly (requiring a new approach since Qt5 manages accessibility quite differently than Qt4). And one of our GUI devs just confirmed that both Microsoft Narrator and NVDA do a reasonable job with reading the majority of the manager UI (which has been the topic so far) from the latest 5.2.19 test build (actually a more recent one which isn't available publicly, but there were no significant changes in a while). "Reasonable job" means that they're correctly reading the text for UI elements where the mouse cursor is hovering. So we'd need more details about what aspect of accessibility isn't behaving adequately. > From my perspective (building VirtualBox and crashing things), the > fact that the OS or the debugger are unable to get a "handle" on the > hardened process, it's something missing. WER just lets the process > exit, because it can't attach to it. Windbg also can't attach to the > process. I'm only able to save a dump when there's no default > debugger, when the OS puts a message box that the process has crashed, > then I start Process Explorer as admin and dump the process. I haven't > found a way to do automatic process memory saving. That's the > experience I remember, because I haven't had a crash in some time. A > build-in crash handler could help users report crashes, it could be > useful. Debuggers simply have no business in a process doing virtualization work (just like random, untrusted DLLs which some applications inject into every executable, some of them totally destroying any remaining bit of security, interestingly mostly done by apps promising to increase security). They could corrupt the state of the VM which can end up trashing kernel memory, i.e. being a security issue. So this "loss" is entirely intentional (i.e. that the VM process handle which is passed to other parties is seriously stripped down). It's a different question what to do for post-mortem dumping, because at that point the VM is already effectively dead. But IIRC Windows adds a new thread to it, kind of bringing it partially back from the dead. Which would again end up being questionable from the security perspective. Klaus > > Regards, > Mihai > > On Tue, Sep 25, 2018 at 8:52 PM Klaus Espenlaub > <[email protected] <mailto:[email protected]>> wrote: > > Wait... is it really confirmed that Narrator can't work with > (hardened) VirtualBox either? That would mean our devs must have > been testing the wrong thing for quite a while now. It certainly > hasn't reached my attention so far. > > For many reasons we cannot recommend that random people run > non-hardened builds. What might be a way out (not with the current > builds, they would be affected by hardening) is to ship an > additional compilation of the VM UI which is not subject to > hardening and can be used solely with the "separate VM/UI process" > option which VirtualBox has already. Would bring some minor > feature losses, but if that would bring back full accessibility I > can see a good justification for spending the necessary time. > > Klaus > > On 25.09.2018 19:26, Mihai Hanor wrote: >> Hello, >> >> I'm not a developer, but I have some experience with VirtualBox. >> The reason why not even Microsoft's narrator is able to work with >> VirtualBox is the hardening of the VirtualBox process, which is >> enforced to protect the VM from eavesdropping (I think). You can >> look at the VirtualBox SDK, but you'll probably not find what >> you're looking for. Also, integrating the NVDA client controller >> is probably not going to happen and it doesn't look useful, >> because it requires VirtualBox to send stuff to NVDA (by looking >> at the C example), which would require considerable effort to >> rewrite the GUI. The most achievable task might be to build >> VirtualBox OSE for Windows, without hardening. A much harder task >> would be to separate the the frontend/GUI part from the VM >> process and make the frontend run in a normal process. In the >> upcoming major release of VirtualBox, it looks like the devs have >> made a move to separate the VM process, but I'm don't know to >> what end. The frontend still runs in a hardened process. >> >> Regards, >> Mihai Hanor >> >> On Fri, Sep 21, 2018 at 12:30 PM Илья Пащук >> <[email protected] <mailto:[email protected]>> wrote: >> >> helo. >> >> >> I'm a nvda (nvaccess.org <http://nvaccess.org>) screenreader >> addon developer >> >> I need the way to get some object text in vbox gui, that >> unaccessable by >> standard methods. >> >> are there any api interface to get this info from vbox gui? >> >> >> i'm using python. >>
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
