Long Wiki Edits Thread

My first point is obsolete. I didn’t read:

# Take a snapshot and name it “Original”.

Well, if you made the revision, then this issue was inherited. I can see the original is unclear on that. Happy that it gets more visible now so we can clarify. :slight_smile:

Should we have

  1. another Tor entry guard per application “only”, OR
  2. another Tor entry guard per application and identity?

I can’t see how one could hold the position 1) while at the same time arguing against 2).

This snapshot should be used with <u>all</u> Whonix-Workstation snapshots related to/called “Email”, whether it is identity “John Doe”, “Jane Doe” and so on.

Could you please rewrite that one? E-mail for John Doe and Jane Doe should be using different entry guards.

Note the Workstations should also be generated separately from a clean baseline.

clean baseline may be unclear for readers. Users will wonder what’s clean, what’s dirty and what’s baseline. (Also inherited issue; just while we are at it.)

Transporting UDP Tunnels over Tor: Difference between revisions - Whonix

| If/when the VPN connection breaks down, direct Tor connections are made without the VPN.

Could you mention the fail closed mechanism please?

If the VPN/SSH server is adversary-controlled, Tor protection is weakened. [7]

Could you please elaborate with a quote or explanation?

Website Traffic Fingerprinting
VPN and SSH protocols are vulnerable to website traffic fingerprinting: [8]

Could you please put in context? In context of Tunnel UDP over Tor - Whonix it would mean, that the Tor exit relay could apply “website traffic fingerprinting” and then see - even though the user is using a VPN/SSH - which website the user is visiting. That may be quite minor in this context?

In another context, when the user is using only a VPN/SSH without Tor, “website traffic fingerprinting” seems a lot more impressive.

Background: TorPlusVPN · Wiki · Legacy / Trac · GitLab was written by me years ago. There is “website traffic fingerprinting”. Research papers show that which website is being visited but not what exact contents are transmitted is still visible when using VPN/SSH and perhaps (years ago?) even to a degree against Tor (this might be improved/fixed by now). I’ve made the argument there if “website traffic fingerprinting” is possible, then detecting Tor inside a VPN/SSH should be a piece of cake. While that’s not directly proven, it sounds convincing and no one ever challenged that.

Another nitpick: Tunnel UDP over Tor - Whonix talks about tunnels, but then the table talks about VPNs.

But I see due to the different contexts:

  • comparison with clearnet [1]
  • pre-Tor
  • post-Tor

a wiki template may be difficult.

[1] Whonix versus Proxies

No they must use the same entry guard since both are e-mail related activities.

But why? Can’t the argument made to use a separate Tor entry guards per activity be used to argue for separate Tor entry guards per identity or identity and activity?

We’ve been preaching stream isolation and now we’ll suggest to merge streams for different identities because they’re part of a similar activity.

So if it was instant messengering or a different e-mail (alike) client like bitmessage and a different identity, we’d suggest to isolate the streams but since it happens to be in a new category of activity, the streams should be merged?

Would still be handy to have.

1 Like

That’s to limit the amount of damage a particular app can expose you too if a guard is malicious. Tariq’s calculations deem that this is the safer way as opposed to running a different workstation for each identity with its own set of apps and guard.

Stream isolation is a great failsafe in case a user mistakenly signs on with an account on say, thunderbird, linked to his real identity while running other traffic. The main point of stream isolation is to prevent the Tor Exit from linking activities, not to protect from a bad acting guard. However in the scheme of protecting from malicious guards the 1 Guard/ 1 app technique was seen as best.

Isolating streams does not change the guards AFAICT so its not enough in this case. To keep in line with the advice, a user would need to run the IM within it’s own VM and guard node and Bitmessage with its own set. Whether a different identity or not.

1 Like

Anything we want to spread through https://www.whonix.org/wiki/Template:RandomNews?

Btw yes, we are still using the AOS moniker.

Quote Whonix - Overview

Privacy protection. Anonymity online. Anonymous Operating System.

But there is no reason to stick with anything forever just because it was used for a long time already. Once others started copying this and calling us that way (which has happen by now), for outreach purposes we can change our moniker / slogans from time to time, perhaps with SEO in mind.

I’ll go ahead and remove the Qubes onion repos from the wiki when I get a chance (later) since they are no longer maintained.

https://groups.google.com/forum/#!topic/qubes-users/MUZCxdYdi4A

Dear Qubes Community,

We regret to announce that the Qubes Tor onion services will no longer
be maintained due to lack of resources. This includes all Qubes onion
services, including the Qubes website onion mirror and the onion package
repos.

We would like to thank the Whonix Project for generously maintaining
these services for over a year. [1] Maintaining the Tor onion services
requires labor, servers, and bandwidth. Unfortunately, none of these
resources are available to the Qubes OS or Whonix projects in sufficient
quantities to allow us to continue offering these services.

We recommend that users who currently rely on any Qubes onion addresses
transition to the corresponding clearnet addresses immediately.

1 Like

i’ve redone the e-mail chapter in my latest version of the guide for danwin1210.me. so, that can happen shortly.

1 Like

Updated Onionizing repositories chapter. I left instructions to revert to http:// URI repositories. Might be a good idea to have for a little while. Less support requests.

https://whonix.org/w/index.php?title=Onionizing_Repositories&oldid=40841&diff=cur

1 Like
1 Like

Onionizing Repositories - Whonix is also looking at it from the wrong side. Users aren’t looking to onionizing Qubes,Whonix, Debian or Fedora packages. They’ll either want to onionize their Whonix templates or any other template as much as possible or un-onionize it due to issues.

Users usually often are not aware what repositories their templates are using. So would be good to make that page focused on the operating system plain, non-Qubes Debian, Non-Qubes-Whonix or templates debian-9, fedora, whonix; and dom0.

Also, not sure if realistic, cool would be an onionizer software tool. Looking for clearnet repositories and replacing them with onions and vice versa. Then documentation and manual steps could be greatly simplified.

Good point. I’ll work on that when I get a chance.

Would be much simpler. Especially with onion unreliability.

1 Like

We can remove anything Qubes R3.2 related if we stop something.

1 Like

Thanks tempest.

How about (new changes):

  1. Unified KVM tar.gz Whonix downloads

& Unified Virtualbox OVA Whonix downloads

  1. Whonix Warrant Canary

https://whonix.org/Trust#Whonix_Warrant_Canary

  1. New Forum Code of Conduct

https://whonix.org/Forum_Best_Practices#Code_of_Conduct

  1. Qubes R3.2 reaches EOL

{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text = Qubes R3.2 reached [Qubes OS 3.2 has reached EOL | Qubes OS EOL] on 28 March, 2019. It is strongly recommended to [Download Qubes OS | Qubes OS upgrade to Qubes R4.0] to stay safe.
}}

So to clarify (resolve the impasse), how about we add (you can add your math skills to calculate actual % if you like as an example):

Some users question why a different Tor guard is not configured for each identity within a specfic domain of activity, such as email accounts ‘Jane Doe’ and ‘John Doe’. Mathematically speaking, each “roll of the dice” (new Tor entry guard selection) increases the probability that a malicious, adversary-controlled guard is selected. Therefore, it is objectively safer to use one guard with different workstations for each identity, even though this comes with the (low) risk that a compromised guard is chosen for select activities and accounts.

Can we approve that Anon Connection Wizard edit on that page too please (still points to old software).

1 Like

Can’t see any not yet reviewed pages as per Permission error - Whonix.

With special:recentchanges

  • See 23 March 09:13

Another missed one

  • 17 March 10:24

Thinking about that Tor attacks stuff (Warning page, 16/17 March), why not create a page called “Speculative Tor Attacks” or similar? That way the title suggests we don’t vouch for it, but it at least highlights that there is a lot more than confirmation attacks to worry about (in theory).

1 Like

The math here is above my pay grade and it was a computer scientist who gave them. I don’t think user docs are a good place to debate matters. It should be a source of concise and authoritative info. If there are questions they are best asked to the professionals.

I am confident I understood his recommendations correctly and translated them into an opsec procedure. Original messages are referenced on there BTW. See if you have a different interpretation.

1 Like