[[_TOC_]] # Rationale Using [desktop portals](https://github.com/flatpak/xdg-desktop-portal) in Tor Browser allows users to open files which Tor Browser usually doesn't have access to (#10422) and provides better integration into the desktop via other portal interfaces like the [settings interface](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Settings) (see #19328). We have these PoCs: - **pseudo** flatpak Tor Browser (!1025) using `flatpak run` - **fake** flatpak Tor Browser (!1933) which basically is a lighter version of the above not using `flatpak run` but based on bubblewrap # Problems with the FileChooser portal These regressions affect both the **fake** and **pseudo** flatpak Tor Browsers. They only affect target directories that are inaccessible to Tor Browser itself, so e.g. `~/Tor Browser` is not affected. For this reason they are not strict regressions compared to Tor Browser without Desktop portals since these directories are completely inaccessible then, but they certainly are new UX issues that our users will encounter. * After saving a file to some directory, opening the file chooser dialog again will not default to the same directory, but to the directory under `/run/user/1000/doc/` that was used by the document portal. * Upstream ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1775497 (closed 2023-10-20, resolved with "In xdg-desktop-portal 1.18.0 and later this problem should be fixed" * Works on a Debian Sid (up-to-date as of 2024-02-12) with xdg-desktop-portal 1.18.4-2, xdg-desktop-portal-gnome 47.2-1, xdg-desktop-portal-gtk 1.15.2-1 (tested with both backends), org.mozilla.firefox (flatpak) 135.0. * "Save Page As" is broken in two ways: it will always initially fail, but you can work around it by clicking "retry" in the Downloads widget. And while it then reports succes it just manages to save the HTML document but fails to save the `_files` directory: * Upstream ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1814851 * Reproducible with on Debian Sid (up-to-date as of 2024-02-12) with xdg-desktop-portal 1.18.4-2, xdg-desktop-portal-gnome 47.2-1, xdg-desktop-portal-gtk 1.15.2-1 (reproducible with both backends), org.mozilla.firefox (flatpak) 135.0. # Other issues * Opening a HTML document via double-click on nautilus fails. * Works perfectly in both Tor Browser **pseudo** _and_ **fake** flatpaks if the directory the HTML document is located in is unrestricted by AppArmor. When it is restricted the HTML file is opened properly through file forwarding, but no files it might reference is forwarded, so any local images etc are missing, but this is (I believe) a fundamental restriction of Desktop Portals, and also affects the official Firefox flatpak. * ~~Also `/usr/local/bin/tails-documentation`~~ * Works in both Tor Browser **pseudo** _and_ **fake** flatpaks since we don't restrict access to `//usr/share/doc/tails/website/` * drag&drop from directories other than `~/Tor Browser` (and other directories that are shared into the chroot) doesn't work, Tor Browser tries to open the path directly without involving the document portal. * Implemented in GTK 4, will probably not be backported to GTK 3: https://github.com/flatpak/xdg-desktop-portal/issues/99#issuecomment-565264246 * Upstream Mozilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1950034 * This is about drag&dropping a file in order to **open** it with Tor Browser. So don't confuse this with what some webpages to with the HTML Drag and Drop API, like `https://share.riseup.net`, because that magically works in both the Tor Browser **pseudo** _and_ **fake** flatpaks. # User-visible improvements * They can now open/save files unrestricted by AppArmor (#10422) * Settings like the window manager's button layout (minimize maximize buttons, #19328), cursor size (#19572), accessibility options (#19266) are respected * Whatever other portals Tor Browser uses (not clear) # Comparison of **pseudo** flatpak and **fake** flatpak Advantages of **pseudo** flatpak over **fake** flatpak: * Less NIH: we will get rid of most our own code to sandbox applications (and still allow them access to the resources which they do need access to) * Probably avoid bugs like #18485, which we suspect is caused by buggy D-Bus proxy handling on our side. Things like that would be taken over by Flatpak. * `flatpak` has a nice debugging interface, much nicer than what we have now * In perspective, Flatpak will allow us to restrict AppArmor more → more security, but not now. * In perspective, Flatpak is a "requirement" to ship Signal #14567 Disadvantages of **pseudo** flatpak over **fake** flatpak: * More code * Even more complexity in the already complex context we run Tor Browser in. `flatpak run` does a lot of stuff, while what we do with bubblewrap for the **fake** flatpak is pretty straightforward and explicit. * Worse sandboxing (no namespace isolation) due to flatpak restricting privileged/user namespaces (https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1025#note_253036). But we can [patch flatpak](https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1025#note_253595) to fix this. # Archive <details><summary>Copied from #10422</summary> > _Originally created by @sajolida on_ #10422 [_(Redmine)_](https://public-redmine-archive.tails.boum.org/code/issues/10422) > > In https://mailman.boum.org/pipermail/tails-ux/2015-September/000645.html we’re been discussing the idea of granting Tor Browser access to files if and only if the user decide to open or otherwise access it. > > This would improve on the current control access policy based on a set of folders (/Tor Browser and /Persistent/Tor Browser). This idea is inspired by “Guidelines and Strategies for Secure Interaction Design” by Ka-Ping Yee and also seems to be of interest to GNOME as “Implicit permission grants from interactive operations”: > > https://mail.gnome.org/archives/gnome-os-list/2015-March/msg00010.html > > We should follow-up on the plans of GNOME regarding this but there’s not much we can do ourselves for the time being. > > Existing WIP and discussions: > > * https://trac.torproject.org/projects/tor/ticket/25578 > * https://github.com/flathub/flathub/pull/1135 > * https://github.com/micahflee/torbrowser-launcher/issues/407 > * https://bugzilla.redhat.com/show_bug.cgi?id=1731284 > * https://discussion.fedoraproject.org/t/tor-browser-on-silverblue/2032/12 > > Blueprints: > > * Blueprint: https://tails.boum.org/blueprint/Linux_containers/ > * https://tails.boum.org/contribute/design/application_isolation/ > > Parent Task: tails/tails#15678 </details>