Long Wiki Edits Thread

To be honest, I hadn’t thought about it too much - I just preferred that phrasing. Happy to go either way.

It would be good if you can edit the stable release notes going forward, and just reference it in your forum post. Saves a lot of time. Then I’ll just do any finer edits later on.

1 Like

This will be done that way from now. I’ve adjusted the changelog auto generator to use your chosen format. Example:

grub-live:

  • Fixed grub-live (initramfs-tools version).

([archive] link is added by a mediawiki extension.)

Any idea how/where to document this?

//cc @adw

Thanks.

As some dipshit keeps editing the “Contact” wiki page with spam, suggest you lock that page to contributors only.

Nobody should really be adding things there anyhow except for a few select people.

1 Like

Done.

I don’t understand why this was removed:

A rule of thumb is to select Y or I for packages coming from {{project_name}}, and N for packages coming from other distributions. Otherwise settings affecting anonymity, privacy and security might be lost.

Users will inevitably come across this issue and won’t know whether to a) accept (Y or I), b) select N (possibly losing anonymity etc benefits in the process) or c) flip a coin. :wink:

If it doesn’t belong on that page, then where? Or are you saying this is no longer an issue?

No longer an issue.

A rule of thumb is to select Y or I for packages coming from {{project_name}}, and N for packages coming from other distributions.

No longer an issue.

This:

A rule of thumb is to select Y or I for packages coming from {{project_name}},

vs this:

and N for packages coming from other distributions.

Is no longer valid.

There is no more “coming from other distributions”. Since use of config-package-dev, Whonix can “steal” ownership if config files coming from “other distributions” (Debian “mostly” [except third party repo added by user]).

So recommended is I (install) in any case. Except the user has customized something the things get difficult. Then it’s up to user to merge this. One strategy would be to install and then re-add customization if still relevant. Or not do it and then check what Whonix changed and backport these if worth it (not worth it for trivial updates such as copyright year updates).

Maybe the latter two paragraphs are worth documenting? That would belong to Operating System Software and Updates?

“coming from other distributions” was from times in cases where Whonix was modifying config files owned by other packages when config-package-dev didn’t exist (or wasn’t used). So many releases ago that I’d have hard time to point out the release. :wink:

Now that we tried hard and went through several revisions on How-to: Install the Stable Version of Qubes-Whonix ™ 16… This cannot be clear enough… In an attempt to clarify things, do you think it’s a good idea to combine the 3 notices

  • Qubes version support notice
  • Qubes-Whonix ™ 15 to Qubes-Whonix ™ 16 Release Upgrade Notice:
  • Qubes-Whonix ™ 16 Notice

into a table of notices similar to how it’s presented on Release Upgrade Whonix 15 to Whonix 16 - Whonix?

new wiki page:

new wiki template:

Could you review Account and Mobile Security: Difference between revisions - Whonix please? @HulaHoop

1 Like

Is this a solution to 20 years of censorship of Tor exit nodes?

Bypassing Tor Exit Blocking

Tor exit blocking, in which websites disallow clients arriving from Tor, is a growing and potentially existential threat to the anonymity network. We introduce two architectures that provide ephemeral exit bridges for Tor which are difficult to enumerate and block. Our techniques employ a micropayment system that compensates exit bridge operators for their services, and a privacy-preserving reputation scheme that prevents freeloading. We show that our exit bridge architectures effectively thwart server-side blocking of Tor with little performance overhead.

Code here:

This repo contains two independent packages, eebt and hebtor. To be specific, eebt corresponds to our first publication, Ephemeral Exit Bridges for Tor (DSN2020), and hebtor corresponds to our second publication, Bypassing Tor Exit Blocking with Exit Bridge Onion Services (CCS2020). Both packages are fully open-sourced under GPLv2 license.

Maybe you could promote it on official social media accounts?

1 Like

Could you move this please to a separate forum thread in development forum?

Not really as adding a user payment system brings its own set of anonymity problems. Also providing a public database of exit nodes was a conscious decision by TPO. They claimed exit nodes could be enumerated by third parties anyway. The current workarounds we documented are more practical and work today.

Any reason not to delete https://www.whonix.org/wiki/Deprecated?

Reason: https://www.whonix.org/wiki/Special:SpecialPages has many reports such as for example https://www.whonix.org/wiki/Special:WantedPages. Easy tools to get clear overviews of what’s broken in the wiki. wiki/Deprecated shows a lot stuff that needs fixing but then isn’t worth fixing as currently not needed.

Maybe a better way to keep it would be to clear the page i.e. to remove all contents with nothing. Then it would be more accessible in the wiki history if needed again.

Viewing these special pages requires user account at least. Maybe even admin account. Deactivated for anon-users to reduce server load (some automated bots kept comparing every wiki history revision with every other wiki history revision which expands exponentially).

Thank you! However, to avoid duplicated discussion, I’d suggest for next time to move the existing post to a new forum topic (+ edit if desired). Can I delete it from here?

Sure - was looking for the move button, but couldn’t see it. :slight_smile:

1 Like