There are VMs that do that but still wouldn't recommend that to someone that doesn't understand tor and networking. Even inside such a VM you'd still use Torbrowser.

It combines Tor and app-level security/privacy measures in an accessible way.

I'm curious why you believe this, outside a few watering hole attacks, and the (now-patched) CMU attack. Given a known-good entry guard, where is Tor broken?

https://www.usenix.org/legacy/event/leet11/tech/full_papers/...

https://www.torproject.org/projects/torbrowser/design/

There's probably a more specific statement from the Tor Project that I'm forgetting at the moment that sets forth the idea that you should only use Tor with Tor-aware client software (that controls what privacy leakages may occur at the application layer).

Consider we have that system wide tor proxy instead of the torbrowser bundle. Now exit node operators get all your TCP traffic. It's fine if one knows what they're doing[0], but if that was the default way for the average user to get on Tor? A privacy and security disaster IMO. Not only would we not provide mediocre privacy, we'd actually endanger people.

[0] and you've got proper stream isolation, which I'm not sure how possible it is system-wide with unmodified software

In theory by bundling Tor with a browser that has sane defaults and then sand boxing that from the rest of your applications, one can isolate specific communications to Tor with lower potential exposure.

By bundling a separate browser, Tor can provide sensible defaults to protect users.

There are also tickets in Tor's TRAC issue tracker for Chrome. Once again, using Chrome securely would require several patches to source.

Actually, I'm pretty sure this is untrue. I'm reasonably certain we're actively working with the Tor Browser developers to get their patches merged into core (but preffed off) so that they don't have to maintain a stack of patches on top of Firefox.

(Disclaimer: Mozilla employee)

The default tor browser ensures most tor users look identical so malicious services cannot finger print individual users. It disables a small group of firefox features which make finger printing extremely trivia (RPC Chat, GPU access).

In most cases of people being de-anonimized on TOR they're normally running an alternative browser, or out of date TORbrowser.

isn't everyone using TOR today using tomorrow's out of date TORbrowser? Meaning that traffic today can be recorded and analysed for vulnerabilities tomorrow.

Its really hard to open an RPC chat session on packet logs. Or request GPU diagnostic information after the connection is terminated.

Most finger printing isn't just write/response times. Latency is a bad indicator of individuality. It's a lot more in depth and requires actively speaking to that browser and noting what features it does/doesn't present, how those features are unique, and how long certain tasks take to process.

Each individual piece of data is small (generally, some browser features make ID trivial), and common. But building up several can give you some confidence in an identity.