Tails

#8 Updated by sajolida about 10 years ago

I’m pretty sure that Orca wasn’t working in Tor Browser before AppArmor confinement, and that it kept on not working (not reading what’s on the web pages).

On the other hand, I understand that chrooted browsers and apparmor-confined and two different kind of beast that might require two different solutions, so I agree with intrigeri on keeping a more specific name about chrooting.

#9 Updated by intrigeri about 10 years ago

> I’m pretty sure that Orca wasn’t working in Tor Browser before AppArmor confinement, and that it kept on not working (not reading what’s on the web pages).

I’ve just verified that it works fine in Tails 1.3.2 when Tor Browser is started after Orca.

#11 Updated by sajolida about 10 years ago

Yes, Orca doesn’t see Tor Browser at all if Tor Browser is started before Orca.

If Tor Browser is started after Orca, the screen is read somehow but I made Tor Browser crash many times.

I created two tickets for those different issues: Bug #9260 and Bug #9261.

#13 Updated by emmapeel about 10 years ago

Meh. Just tested Tails/Jessie and Orca reads the alerts for the Unsafe Browser, but does not read the contents of the Browser screen at all… tested with

tails-i386-feature_jessie-1.5-20150731T0408Z-9946a87.iso, downloading a more recent now.

#14 Updated by intrigeri about 10 years ago

Thanks for the report!

> Meh. Just tested Tails/Jessie and Orca reads the alerts for the Unsafe Browser,

Not surprising, the warning dialog runs as the amnesia user.

> but does not read the contents of the Browser screen at all…

Not very surprising either (we did nothing to fix that in feature/jessie AFAIK).

#15 Updated by anonym about 9 years ago

While the chroot part might make this case harder, it is actually the case that any process running as a different user than amnesia is not “accessible” (poor wording, btw), e.g. Tails Upgrader. Beyond the obvious, i.e. that this is bad for people in need of a screen reader, it is also bad for our automated test suite, given that dogtail uses the same interface.

I’m tempted to change the subject of this title to “GUI applications running as non-amnesia lack accessibility support”.

Some related docs:

• http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atkat-spiat-spiond-bus#Multi-user_accessibility
• https://wiki.ubuntu.com/Accessibility/Specs/SudoAdminAtspi

#16 Updated by anonym about 9 years ago

In related news (copy-pasted from Feature #10900#note-8):

It’s worth noting that despite the fact that synaptic runs as root, dogtail can deal with it! Wow! Is this due to /usr/bin/synaptic-pkexec? It would be amazing if that is the case, and we can use that for the chroot browsers and other applications run as non-amnesia in the X session.

I tried this, which started the Unsafe Browser, but still no accessibility support:

pkexec \
    env DISPLAY=$DISPLAY \
        XAUTHORITY=$XAUTHORITY \
        SUDO_USER=$USER \
        PATH=$PATH:/usr/local/sbin:/sbin:/usr/sbin \
            /usr/local/sbin/unsafe-browser

with /usr/share/polkit-1/actions/com.tails.pkexec.unsafe-browser.policy (which is an adapted copy of synaptic’s) as:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

  <action id="com.tails.pkexec.unsafe-browser.policy">
    <message>Authentication is required to run the Synaptic Package Manager</message>
    <icon_name>unsafe-browser</icon_name>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/local/sbin/unsafe-browser</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>

But it didn’t yield accessibility. Perhaps the chroot further complicates things? Also, I’m admittedly completely ignorant of PolicyKit.

#18 Updated by intrigeri about 9 years ago

> So, if we find it acceptable to grant access to the AT-SPI bus to other users (aren’t we already assuming that these users has full access to the X session state?),

At first glance, I think we can indeed do that.

> then I guess we can get at least get tails-upgrade-frontend to support accessibility/dogtail, and possibly also the chroot browsers, […] I’m calling this progress!

Yes! :)

> But I’m not sure I feel comfortable being the assignee, since I indeed am very ignorant of these things.

Understood. But the thing is, AFAIK nobody on our team is less ignorant of them..

#20 Updated by intrigeri about 9 years ago

anonym wrote:
> I pushed a WIP branch where I did some minor progress. Essentially: I can start gedit in the chroot and have it accessible, but still not the browser.

Looks like it might be related to Bug #9260.

#31 Updated by zersiax about 5 years ago

Bump. Was any more work done on this one since the progress made a couple years ago?
While Tor Browser is likely preferable in most cases, nothaving the option is a problem, especially given that it apparently affects other applications as well