Allow-sandbox request for torbrowser snap

store-requests
#1

torbrowser is a well known browser by Tor Project packed as a snap.
Build files are here https://github.com/iomezk/snap-torbrowser

At the moment, the snapped browser has no stability issues, it can play videos, open pdfs, etc.

About fingerprinting resistance, one of the main Tor Browser features

  • coveryourtracks.eff.org shows “strong protection against Web tracking” and the same data and level of uniqueness as in Tor Browser in Tails distribution
  • amiunique.org gives the same fingerprint data as in Tor Browser in Tails distribution

So, all this snap needs for providing the same isolation as non-snapped version is permission to use sandbox (auto-connect for browser-support plug with allow-sandbox: true).

#2

Hi @kotyk, thank you for the request.

torbrowser snap comes under well-known browser category to grant auto-connect of the browser-support interface, but allow-sandbox: true allow necessary access to use the browser’s sandbox functionality, which is privileged and is limited to trusted publishers only.

I would ask @Igor / @advocacy to perform publisher vetting.

if all goes well, +1 from me to grant auto-connect for browser-support plug with allow-sandbox: true

#3

Hello @kotyk are you associated with the Tor project?

#4

No, I’m not associated with the Tor project.
There is no other official distribution method than tarball with binaries, so I doubt they are interested in supporting snaps officially now.
At least all recent work on system HOME support should be finished first https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20497

#5

Since this is a highly sensitive piece of software, it would be good to have a chat with them first, see what their stance is, and then we can see what the next step should be.

3 Likes
#6

At least they are not against snaps

If you’re interested in the packaging patches for tor-browser-build this is something we could review and maintain going forward in the 13.5 alpha series (scheduled starting October 2023) but we don’t have capacity to investigate this for the foreseeable future.

1 Like
#7

@Igor, is this at a stage where we need more information?

#8

We need more information. @kotyk could you please invite someone from the Tor team into this discussion, or if they do not want to do it here, we can set up a different way of communication, to figure out the next steps. If they are too busy and would like to defer this until they can, that’s an option, too. With that in mind, if you’d like to maintain the snap, we’d also have to figure out exactly how this should be done in the best way possible, especially considering the privacy and security proposition of the Tor browser.

#9

Thanks for your interest to this project. Work on integration to tor-browser-build is in progress.

A little more info from the discussion is here. The maintainer asked for reproducible builds. I like that idea and it’s not impossible to implement. Latest 0d41e8f commit is reproducible with the same toolchain and “command-chain” scripts, but a final solution likely will not use the snapcraft tool.
Also I’ve made a proposal for a shared avcodec library which would reduce maintenance load much.

There is a trademark issue https://www.torproject.org/about/trademark/