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

I highly doubt the fingerprint would be much different with the hardening enabled, if at all. The sandboxing shouldn’t be visible to websites as it doesn’t affect anything internally. hardened_malloc might change the fingerprint (you can see differences in about:memory) but I doubt websites can detect this.

The warning with the sandboxed-tor-browser project is likely because that sandboxing was part of the actual browser and not some external thing like firejail.

I also think we should be using something like bubblewrap for sandboxing for reduced attack surface but that’s a whole other discussion.

I am using hardening here as a an umbrella term to include hardened malloc, firejail and also apparmor.

Linux · Wiki · The Tor Project / Applications / Tor Browser · GitLab which says “There are several unresolved issues that affect security and fingerprinting.” was based on bubblewrap, which is similar to firejail.

Would be interesting to know why Tor Project deprecated its bubblewrap based sandbox. References and this might help to re-vitalize bubblewrap based sandbox:

If discussion on bubblewrap isn’t mostly about web fingerprinting, please create a separate forum thread.

Btw I went with firejail, because:

1 Like

Probably lack of interest and contributors.

I could volunteer for bubblewrap. The only problem is that you need to manually create seccomp filters with actual C code and I don’t know how to do that.

1 Like

Looks too difficult to invent, review, maintain then.

1 Like

The rest of the sandboxing (namespaces, filesystem stuff, capabilities etc.) is fine and easy to use. It’s just we can’t filter syscalls with seccomp easily.

1 Like

I made sandboxed tor browser work with TB8.x but I had to disable some things like seccomp, I could not find the right permissions.


Can bubblewrap be combined with firejail / apparmor / hardened malloc? Useful?

Or is combination with firejail for example unnecessary and bubblewrap is to be seen as a replacement for firejail?

Keep using firejail for that?

Could you create a pull request / comparison against Tor Browser original please?
Not to get it merged, but to see the diff against last version by Tor Project.

Could you please consider discussing your fork on a mailing list by Tor Project (probably tbb-dev Info Page)?

1 Like

There are several unresolved issues that affect security and fingerprinting. Do not assume that this is perfect, merely “an improvement over nothing”.

Maybe you know more about this?

1 Like

It would likely just add attack surface and not really be useful. I’ve messed around with running firejail in bubblewrap before and it was hard to actually get it going and it required root.

A combination is unnecessary at best. It would likely degrade security. bubblewrap is meant to be a replacement.

If we do start using bubblewrap, I’d still recommend we keep firejail. It has lots of pre-made profiles we can use. We can configure bubblewrap sandboxes for a few programs ourselves and use firejail for any others. Firejail would also be much easier for a user to use as it can just be done like firejail program but we can create our own scripts so bubblewrap can be used like that.

Yes. Unless the seccomp is somehow made easier.

1 Like

Yes, they talk about the perfect sandbox and making sure this sandbox does not leak “we are in a sandbox”. But in a world where the main security thread for Tor Browser is to “ping home” and deanon a user, that fingerprint/knowing you use a sandbox is nothing if you can stop hackers from pinging home.

@madaidan @Patrick
Bubblewrap is like Firejail, but implemented in Golang (memory safe). And they use Linux namespaces for isolation + seccomp + capabilities + Apparmor (optional).

Hardened malloc could be used? IDK, it is something apart.

1 Like

I’m not aware of any way for a website to detect the browser is in a sandbox unless the sandbox is poorly implemented or the website attempts to give you malware.

No, bubblewrap is in C and doesn’t use AppArmor. sandboxed-tor-browser is in golang so that’s probably where you got confused.

It’s a hardened memory allocator. See GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.

1 Like

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