You’re right. It was a brief brainstorm about an idea to make a more censorship robust notification system and it doesn’t belong on here, but on the permanent take-down threat ticket. As for the mmdebstrap steps below it, i have no idea how those got here (weren’t added by me I think) or how they help in installing the thing itself.
I was never able to get it to work and still don’t know why.
Not in news forums disadvantage: someone really digging through news wouldn’t find it. Otherwise burried since posts in news forums aren’t bumped for new replies. But perhaps is OK if this moves to documentation instead.
If in development forums advantage: the thread gets bumped, more visible.
Dev/Issues Tracker wiki entry could do with an update to show your preference in I assume this order:
GitLab
GitHub
Phabricator
Also, I see The Tor Project GitLab issues trackers all have an onion address, but the Whonix one doesn’t. It would be great to set that up if possible from your end for interested devs & advanced users who want to check out issues.
Using DispVMs for both the Whonix ™ Gateway and Workstation in Qubes R4 does not increase security without any corresponding privacy downside, for the following reasons: [17] [18] [19]
DispVMs are not amnesic. In practice this means traces of their activity can be left on storage or in memory, making them vulnerable to forensic operations. [20]
Using a DispVM for the Whonix-Gateway ™ results in non-persistent entry guards to the Tor network; behavior unlike the default configurations for Whonix ™, Tor, and the Tor Browser Bundle. Mathematically speaking, end-to-end correlation attacks are more likely to succeed when a user chooses many random entry and exit points in the Tor network, rather than semi-permanent entry guards which are only rotated every few months. [21] [22]
2FA can also be useful for advanced users the have the capability to easily detect any phishing attempt. That is because even if the e-mail address used to sign-up for a (financial) service got hacked because of the e-mail service got hacked, attackers could still not login into the user’s accounts due to lack of 2FA.
Advanced users sometimes have the mindset “I know how to detect phishing therefore I am not in the target group of people who could benefit frrom 2FA” but then even their e-mail account could get hacked without their fault (malicious employee, database leak) and in this cases they’d be better off with 2FA protected logins for everything else. Then a simple password recovery request wouldn’t suffice to hack all of their logins.
Not sure that point was made on that page?
Not really. My best understanding of 2FA benefit is for web services. 2FA “strengthens any password” and makes a hacked e-mail address less painful.