Project

General

Profile

Bug #7502

Feature #14522: Make Tails usable for blind users

Unsafe Browser is not accessible

Added by meganet almost 5 years ago. Updated 4 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Accessibility
Target version:
-
Start date:
07/06/2014
Due date:
% Done:

20%

Feature Branch:
wip/feature-stretch-chroot-accessibility
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:
Unsafe Browser

Description

In Tails 1.0.1 and 1.1 RC1, the unsafe browser is fully inaccessible, probably because it's launched in chroot mode, and the variable "DBUS_SESSION_BUS_ADDRESS" isn't set.


Related issues

Related to Tails - Bug #9767: IBus input methods cannot be used in the chrooted browsers Confirmed 07/19/2015
Related to Tails - Bug #11755: Dogtail does not work for X applications running as non-amnesia users In Progress 08/31/2016
Related to Tails - Bug #7503: The Persistent Volume Assistant is not readable by Orca Confirmed 07/06/2014
Related to Tails - Bug #9051: Tor Launcher is not accessible In Progress 03/14/2015
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 09/02/2017

Associated revisions

Revision df96aed6 (diff)
Added by anonym about 3 years ago

Migrate from dogtail to sikuli for Tails Upgrader steps.

Tails Upgrader doesn't run as the amnesia user => lacks accessibility
support => dogtail cannot do its magic, as in #7502.

Refs: #7502

History

#1 Updated by geb almost 5 years ago

  • Status changed from New to Confirmed

#2 Updated by sajolida almost 5 years ago

  • Subject changed from Unsafe browser is just inaccessible. to Unsafe browser is not accessible
  • Priority changed from High to Normal

#3 Updated by intrigeri almost 5 years ago

  • Related to Bug #7503: The Persistent Volume Assistant is not readable by Orca added

#4 Updated by BitingBird over 4 years ago

  • Affected tool set to Unsafe Browser

#5 Updated by sajolida over 4 years ago

  • Related to Bug #9051: Tor Launcher is not accessible added

#6 Updated by BitingBird about 4 years ago

  • Subject changed from Unsafe browser is not accessible to Browsers are not accessible

All browsers are now confined -> enlarging the ticket (no sense in making one for each browser, since the solution for one will likely solve the problems for the others).

#7 Updated by intrigeri about 4 years ago

  • Subject changed from Browsers are not accessible to Chrooted browsers are not accessible

BitingBird wrote:

All browsers are now confined -> enlarging the ticket

Well, I'm almost certain I've made sure that Tor Browser's confinement didn't break at least the screen reader. If I'm wrong on that one, then feel free to revert to the more generic title you've set. Let's not state that things are broken before double-checking that they are.

#8 Updated by sajolida about 4 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 4 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.

#10 Updated by sajolida about 4 years ago

  • Related to Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it added

#11 Updated by sajolida about 4 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: #9260 and #9261.

#12 Updated by intrigeri almost 4 years ago

  • Related to Bug #9767: IBus input methods cannot be used in the chrooted browsers added

#13 Updated by emmapeel almost 4 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 almost 4 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 3 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:

#16 Updated by anonym about 3 years ago

In related news (copy-pasted from #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.

#17 Updated by anonym about 3 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

It seems that any process run as root can get accessibility via something like:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

I suspect that is because /etc/at-spi2/accessibility.conf contains:

[...]
<!-- Allow root to connect -->
<allow user="root"/>
[...]

because if I add
[...]
<allow user="clearnet"/>
[...]

(and restart GNOME, so we get new dbus sessions and that file is read and applied again, I suppose) and then run:
xhost +
pkexec --user clearnet env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

then it works! E.g. dogtail's sniff tool can see gedit!

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?), then I guess we can get at least get tails-upgrade-frontend to support accessibility/dogtail, and possibly also the chroot browsers, although we probably have to be more clever (i.e. make more stuff available in the chroot, perhaps /var/run/gdm3 due to XAUTHORITY?).

I'm calling this progress! But I'm not sure I feel comfortable being the assignee, since I indeed am very ignorant of these things.

#18 Updated by intrigeri about 3 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..

#19 Updated by anonym almost 3 years ago

  • % Done changed from 10 to 20
  • Feature Branch set to wip/feature-stretch-chroot-accessibility

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.

#20 Updated by intrigeri almost 3 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 #9260.

#21 Updated by intrigeri almost 3 years ago

  • Related to Bug #11755: Dogtail does not work for X applications running as non-amnesia users added

#22 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #9051: Tor Launcher is not accessible)

#23 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #7503: The Persistent Volume Assistant is not readable by Orca)

#24 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #9260: Orca reads neither Tor Browser nor Thunderbird if started after it)

#25 Updated by intrigeri almost 2 years ago

  • Parent task set to #14522

#26 Updated by intrigeri almost 2 years ago

  • Related to Bug #7503: The Persistent Volume Assistant is not readable by Orca added

#27 Updated by u over 1 year ago

  • Related to Bug #9051: Tor Launcher is not accessible added

#28 Updated by intrigeri 4 months ago

  • Subject changed from Chrooted browsers are not accessible to Unsafe Browser is not accessible

#29 Updated by intrigeri 4 months ago

#30 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Confirmed

Also available in: Atom PDF