Long Wiki Edits Thread


No idea. I was hoping someone else would understand better than me. :slight_smile:


vfemail will have to be replaced in Encrypted Email with Thunderbird and Enigmail due to destructive hackers.

@tempest mentioned that TNT had a reasonable suggestion with https://danwin1210.me/mail/

Haven’t really looked at this provider but will very shortly. Then update the wiki.


Added notice not to use vfemail to the wiki



"should be changed to

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo


Can someone with template editing powers please change this in the tox template? I was about to, but I don’t have the power to edit templates at the minute…


OK - I’ve just been doing general edits here and there as you probably noticed.

I gather you mightn’t like the Warrant Canary stuff (?). Basically, canaries are speculative, cause more angst than benefit, and probably protect against minimal threats in the Whonix case (open source etc.), even in the event of an NSL. So worth fleshing that out a bit.

That was the point. Unless you think some German court is going to force you to backdoor your own product (baby) and destroy the Whonix brand in the process. Wholly unlikely, since I think you’d go into early retirement before doing that.


Was raided and temporarily shutdown in the past, but he’s up and running now.


Placeholder for template edits (reminder for later):

  1. Tox template:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

  1. Tunnel Support template:

Update “Chaining Anonymizing Networks” link (currently points to old Advanced Security Guide)

  1. Download table:

Replace the hideous old 1990s retro table with the pretty new table in the Download Table template (?) - see pending edit



Do you / we / I need to update the OnionShare page now that v2 of the software has been released?


e.g. Maybe pointing to v2 in git steps, noting ephemeral onions are now preferred by default etc.? Prob also affects the config section of that wiki entry.


Time to update this section I think (blank at the minute).


So, I can trawl through Phabricator and check for closed issues from 6 August 2018 onwards and note them there if you like.


so, i’ve finished up a new beta version of the guide i worked on, which uses danwin1210.me as the e-mail provider. so far, the mail service has worked quite well.


Sure, I’ll propose some adjustments. I don’t think much needs to change really: just the tag number, and maybe a short blurb about the new ‘Receive Mode’ in OnionShare 2. As usual I advocate for linking off to as much 3rd party docs as possible so that the wiki doesn’t fall out of date. However we also need to write official docs for Receive Mode too :slight_smile:


@HulaHoop in KVM method i think you missed mentioning the ability to check the images signatures with the keys no ?

Qubes has full complete guide about it:


Good point.

@Patrick doesn’t a signature mismatch imply that the images was modified maliciously or download corrupted? Wouldn’t also checking the sha256 hash be just another redundant step if the image checks out with the signing key?



Yes, redundant. We choose to trust OpenPGP / gpg. It internally uses hashing also. If OpenPGP / gpg is broken, the internet is in bigger trouble anyhow. And from a threat model perspective, hash files don’t provide higher security than images downloads. If the image download was corrupted by an attack, why wouldn’t the hash file also be corrupted by an attacker. OpenPGP signatures are a way out of this.

Why do we provide hash files anyhow? Good question.

  • was a feature request
  • no extra maintainance work anymore since the process of creation, verification test and upload is automated
  • to convince oneself a file really is corrupted and that it’s not a gpg bug



It is inadvisable to consider paying for ‘Lantern Pro’ since the available payment methods cannot be used without damaging user privacy and/or anonymity.

Well, by connecting to lantern for free, doesn’t this already privacy and/or anonymity?

What’s the threat model?

An advanced adversary seeing that a user connects to lantern? This is sane to assume anyhow that this gets logged and later found out.

Quote https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP

Some pluggable transports may seek to obfuscate traffic or to morph it. However, they do not claim to hide that you are using Tor in all cases but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing.

So consistent, efficient hiding of Tor

Is a payment trail worse than that?

We might keep this discouragement of payments but we’d have to give better reasons. Also I am not sure if the statement as is would be a target for libel. Unclear what it entails. Could you please elaborate on it more?


Tor Browser without Tor has been updated



Will fix that.

Also thanks mig5 (can’t like any posts for some reason).

PS 0brand - those are some nice edits (and commits!) my man. More please.


The only downside as I see it with the banner change (“This website uses cookies” etc.) is that search box is no longer visible if JavaScript is disabled. And the banner can’t be dismissed by clicking ‘OK’ without JavaScript.

However, the search function can still be accessed with the Special:Search paramter added to the URL, so no big deal for editing purposes I guess (when searching for something).

@0brand Re: your post in the other thread. Happy to do a full edit on all your VPN hard work once it’s finished. Just give me the heads up when you are done - as I see you are still working on various things.
It’s all coming together nicely. +1


An alternative to https://www.mediawiki.org/wiki/Extension:CookieWarning would be desirable. Perhaps either a different mediawiki extension. or CSS tricks or some way to inject different dismissable banner code into mediawiki header.


I don’t think there is any solution for a dismissable banner with html/css only, haven’t seen that anywhere online yet.

Just now moved the banner down a few pixels so it doesn’t block our menu bar.


I noticed that the new version of Tor automatically detects that you changed your physical location based on IP(?) and uses a new guard node pinned to that hotspot location. This protects against the threat mentioned in the chapter: location tracking privacy of using Tor.

I don’t know the details of how it works but it’s pretty cool and worth mentioning for those who are worried about this.