Opened 3 years ago

Closed 13 months ago

#20774 closed enhancement (wontfix)

Support foreign language input where possible.

Reported by: yawning Owned by: yawning
Priority: Medium Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The sandboxed-tor-browser sandbox creates new NET and IPC namespace, breaking most foreign language input methods. This will require figuring out how the input method communicates with X and the client app, and writing code to bridge the host system and the firefox sandbox.

Eg: IBus based input methods use D-Bus for communication. Simply allowing host D-Bus access is extremely suboptimal and is not something I'm currently considering.

Child Tickets

Change History (8)

comment:1 Changed 3 years ago by yawning

Priority: MediumHigh

Bump up the priority on things I think are important for 0.0.2.

comment:2 Changed 3 years ago by yawning

I might be able to get away with supporting XIM instead of IBus since IBus supports that protocol, but I'll be really sad when Wayland takes over the world (though this appears to be easier).

Either way, I need to include shared objects from /usr/lib/gtk-2.0/2.10.0/immodules along with a sensible /usr/lib/gtk-2.0/2.10.0/immodules.cache in the container. Just the shared object changes.

comment:3 Changed 3 years ago by yawning

Well, XIM is a no go because XIM support is broken in Tor Browser even without the sandbox. If #15908 is any indication, this has been totally broken for a while. Sigh.

comment:4 Changed 3 years ago by yawning

Priority: HighMedium

Re-prioritizing things that won't make the 0.0.3 cut due to time constraints.

comment:5 Changed 3 years ago by yawning

To checkpoint what I have managed to figure out:

  • XIM support is totally broken, otherwise that would be the easiest way to get basically everything to work. When Tor Browser switches to Gtk_3, this may be worth revisiting, but will most likely go away with Wayland, so isn't a long term viable solution.
  • I-Bus appears to be the most common (and is what I use). At a first glance it involves, giving the container access to org.freedesktop.IBus on the session D-Bus (and only that service), along with giving access to the I-Bus abstract socket (See .config/ibus/bus/<blah>). Making this resilient to things that the user can do external to the sandbox (eg: Restarting the ibus daemon) adds further complexity.
  • Fcitx support would also be nice, but is probably on the order of complexity of supporting I-Bus and is less popular.
  • SCIM and uim probably don't have the userbase anymore to justify development time.

comment:6 Changed 2 years ago by yawning

Looks like D-Bus might get changes to make this less painful, in which case this will be easier to do on systems with modern D-Bus. So basically, assuming I wait on this, Debian stable users will get sandboxed-tb foreign language support sometime in the 2020s.

https://smcv.pseudorandom.co.uk/2017/dbus_and_containers/

comment:7 Changed 2 years ago by yawning

I don't think this is actually possible to do safely without spending a few months carefully pouring over the I-Bus/D-Bus code to ensure that enabling any of this doesn't create a sandbox escape that allows for code execution or data exfiltration.

So while important I'm tempted to WONTFIX this.

comment:8 Changed 13 months ago by yawning

Resolution: wontfix
Status: newclosed

This project is deprecated, and none of these will ever be fixed.

Note: See TracTickets for help on using tickets.