Tor Browser Hardening (hardened malloc, firejail, apparmor) vs Web Fingerprint

They mean with Javascript, like detecting installed Fonts and hardware and things like that.

Oh, yes, sorry, it is like that.

1 Like

The sandboxing wouldn’t affect that. The Tor Browser displays the same set of fonts regardless of the environment it’s in and the sandboxing doesn’t do anything with hardware.

I measured that Tor Browser without --hardening option is faster.
Tor Browser with --hardening is slower to start up, load default tab, and close.

Also hardened malloc acknowledges in its upstream readme that performance loss is possible.

Therefore I think it’s entirely plausible that such differences are measurable from remote.

1 Like

The Tor Browser protects against javascript performance fingerprinting so this shouldn’t be detectable.

(forum software says “post cannot be empty”)

In Hardened Malloc - Hardened Memory Allocator - #32 by Patrick I wrote:

1 Like

A user lost access to noscript due to wrong use of firejail.

Therefore quite likely fingerprintable.

1 Like

Probably only if it breaks something which if you use the proper profile (/etc/firejail/start-tor-browser.profile), is unlikely.

Cannot be foreseen how folder/file/seccomp call requirements are going to change with upgrades of Tor Browser.

1 Like

The Tor Browser firejail profile is managed by the firejail team upstream. They would hopefully fix any problems quickly.

There’s a gap between issue being identified, and fixed. On top of that, the firejail-profile package from packages.debian.org is only upgraded during Debian release upgrades, such as from Debian buster to Debian bullseye.

1 Like

Debian backports serious bug fixes. They’d likely fix any seriously broken profile before release upgrades.

Checked Debian changelog. I haven’t seen any upgrades of package apparmor-profiles or firejail-profiles ever that were uploaded to any other Debian suite other than unstable first, i.e. require a release upgrade until these flow into testing and the next stable release of Whonix.

Debian doesn’t ship Tor Browser. So is not responsible for that application which is upgraded outside of its repository.

Also very much dependent on the Debian maintainer. A lot variables. Too many.

1 Like

But how will a remote site be able to differentiate between performance loss caused by an allocator vs one attributable to just running TBB on a crappy computer?

1 Like

My goal is to fins out:

*If stacking Firejail and Apparmor us any better than just using firejail for TBB

*Find out who maintains the most current profile and see if we can cooridante with TPO to provide an officially maintained/unit tested version from their repos.

1 Like

Speculation: Could be because an allocator might influence non-linearly some feature more than another while a crappy computer influences it in a more linear way.

firejail man page talks a lot about apparmor.

Upstream firejail has a few Tor Browser related issues (might already be most if not all closed by now). Looks like upstream is quick to fix such. Looks like with apparmor upstream gives apparmor but leaves applications to application developers while firejail upstream provides a ton of firejail profiles. I might be wrong about this.

1 Like

It is. Firejail doesn’t offer nearly as good file path whitelisting than AppArmor does. Firejail also can’t do many things AppArmor can such as managing ptrace or signals.

It’s also good defense in depth. If there’s a vulnerability in Firejail which isn’t unlikely then AppArmor will still restrict the application or vice versa.

2 Likes

Discussion

1 Like

yet firejail can use xpra to isolate Tor Browser’s access to X

Firejail isn’t actually needed for this. You can just start xpra and start TBB with a custom DISPLAY variable pointing to xpra.

Firejail does make it much easier though and sandboxes xpra.

2 Likes

I figured out how to create seccomp filters with bubblewrap and can maintain sandboxes if needed. It isn’t actually that complicated.

2 Likes