No “digging” is not required in properly structured guides.
I just went through the Proxy after Tor page. I looked at it in the past, it seemed too complicated. Now I was determined so I tried again. It took me about 2 hours, all I wanted was to find out “how to use a proxy after tor, for the specific case of tor browser”. And you know what? now that I understand, if I need to explain it to someone, verbally or in writing, it would not take me 2 hours. It would take me exactly 2 minutes.
This page contains all possible methods for every tool whatsoever, and it contains methods that are “untested, please report!” or “unfortunately don’t work” (followed by a detailed account of the steps for the method that doesn’t work!). It contains references to disputes and fights between developers of proxychains, it mixes technical steps with doubts about motivation to use tools, I couldn’t have written a more cluttered page if I tried.
Whonix works. It can be improved but it is good. Reading the docs is like looking for a needle in a haystack. Not complicated:
- A user isn’t a search engine that can index all the info by DFS or BFS tree scan. Too much info can be as damaging as too little info.
- A user isn’t a compiler either that requires block inside a block inside a block inside a block.
- Start by concentrating on the most common issue, and on the simplest solution! 80% of or more the readers need just that!
- If there are methods that are untested or are not working at all, don’t put them in the middle of the document! if you must include them at all, do that at the very bottom or better as a link at the bottom! Don’t put “TODO” notes in the middle of a guide that everybody read! isn’t there meta-info for a page or a better place?
- Understand to clearly separate stuff an average user can do and material for advanced or even “testers only” info.
I can go on and on. It is frustrating.
The more you save the further away you get from security. This should be clear to all users. If you have a reference to a case of malware that was found in a Tails USB device in a hidden folder that will be an interesting read.
I don’t see how FDE solves any of that. The data is there and in many cases the attacker can either get to it independently or through you. When you have logs, browsing records and traces every application leaves, (in the case of Whonix) versus saving only the data you absolutely have to (in the case of Tails), there is a big difference.
I wouldn’t be so sure. It’s not only what you store, it’s everything you type, put into the clipboard, view, everyone you communicate with (some of those people will not maintain any OPSEC at all…) and so on. Unless you keep a completely fictitious identity inside each and every action this tracking can deanonymize you.
Of course, a malware in Tails will quickly get your IP. It may make more sense to use a remote connection with Tails.
Shared clipboard settings allow that.
Points I didn’t mention before:
- Attack surface. Tails users are discouraged from adding more applications, Tails project makes a lot of effort to include enough tools, good tools, for most users. Whonix, that does not have an amnesic issue contains less tools, but encourages users to install others. This potentially can create a much larger attack surface in Whonix-Workstation.
- Whonix-Gateway is mininal, but we have here 2 different systems that can be compromised, plus the host, plus the hypervisor. Is this a smaller or larger attack surface?