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.
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
@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.
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?
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 Extension:CookieWarning - MediaWiki 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 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.
it doesn’t really specifically address that and explains this makes it more fingerprintable perhaps with a short footnote as explanation/reference with proof or authoritative source as backup of this claim?
The link to the Hidden Wiki is problematic. There is useful info on there but the fact it links to other illegal material might make us liable if we link to it directly.
I recommend pasting the contents of the email page to a pastebin (or alternative) then archiving that with Internet Archive: Wayback Machine then linking to that page instead while citing the source as the hidden wiki.
Probably better to just create a standalone ‘Onion Gaming’ page and link to it. Also, presumably more gaming stuff will become available over time.
2. Let me know if there’s something that needs fixing up on the email page updates i.e. re: the service provider changes. Effectively, some just go out of existence quite regularly it seems.
(It would be nice to have all those VFEmail pics replaced with a working alternative in the Email entry, but I’ll leave that to @tempest)
3. The added info on Tor attacks on the Warning page is to try and tighten up info - i.e. a ton of other (historical) attacks are possible against the client, server and/or network.
Good for reader to know it ain’t just confirmation attacks they need to worry about if the ‘big boys’ take an interest. Even Tor doesn’t list this out anywhere in one place that I remember seeing…
(haven’t forgotten the Whonix 14 Release Updates TODO; putting off the dull stuff)
Plan from here →
finish finer edits down to anonymous email section
tidy up/rejig that Mixmaster stuff
start some heavy edits on the Money section (good info, but structure/expression is wanting in several places there)