Long Wiki Edits Thread

Split done:

new wiki pages:

discussion here:

Google launches a spectrev1 test page using JS for Intel CPUs. Where should this be listed?

1 Like

Not sure this page should duplicate most contents:

Main page:

Related wiki template:

Split:

2 posts were split to a new topic: Finding Backdoors in Freedom Software vs Non-Freedom Software

A post was split to a new topic: Whonix Security Roadmap

A post was merged into an existing topic: OnionShare Whonix integration development discussion

A post was split to a new topic: Tor Myths and Misconceptions page

Firefox vs Chromium seems great in theory, but there are a few issues with that:

  • Chrome is non-freedom software → Avoid Non-Freedom Software
  • Chrome is NOT Chromium.
  • The conclusion “use Chromium instead” would have been wrong. See:
1 Like

I think you misunderstood my second point. Since it is on the Tor Myths and Misconceptions page, it is to highlight that any serious adversary would pwn your ass in two seconds flat if they wanted to. Many newbies or common users don’t understand that - so their misconceptions should be shattered.

I didn’t mean to insinuate that Chrome/Chromium is a suitable alternative, or should be run over Tor etc. If you read it that way, all that needs to be added at the bottom is this sentence:

Despite Tor Browser’s various security weaknesses, alternative browsers should not be used in the Whonix platform:

  • this would pose a serious fingerprinting risk
  • users may be vulnerable to critical unpatched vulnerabilities [ref]In recent history remotely exploitable vulnerabilities remained unpatched in Linux repositories for extended periods for alternative browsers (like Chromium).[/ref]
  • proprietary browsers like Chrome are antithetical to privacy
1 Like

Yes, I guess it could be misinterpreted that way.

That sounds good! Please add.

Done.

2 Likes

Page moved:

New page:

How do you like that documentation style?

Background:

Paraphrasing a user question “I didn’t update for a while and I wouldn’t update before enabling that feature but I don’t have that feature installed yet.”

But that’s not what that feature was supposed to communicate.

It’s okay. The information is good, but in terms of formatting - a lot of bullet points in succession I generally try to avoid. I prefer tables in that case for neater formatting.

1 Like

Undocumented, Untested or Unsupported Features could use some more friendly rewording:

Inspiration:

The unsupported label Undocumented, Untested or Unsupported Features is insufficient in some cases. It says:

This feature is either undocumented, untested, or unsupported. Please help us implement this feature by becoming a contributor.

Consider Free Support Principle.

It might be possible to get this feature implemented, documented, tested and/or supported by purchasing Professional Support.


Could use a stronger label declined. Or is there any better term than declined?

For example a user asked for VMware support. Then unsupported was misleading since the user asked for professional support which after consideration I wasn’t interested in either. Due to Whonix Policy On Non-Freedom Software it’s not a good direction to spend any time on.

declined:

This feature is declined. Either it is incompatible with the current project priorities, goals and/or policies.

It is not on the roadmap. It is unlikely ever being on the roadmap.

Any contributions would be refused.

Professional Support is also unavailable.

Rewording suggestions welcome.

Could also use more friendly wording as per Long Wiki Edits Thread - #1974 by Patrick.

Bug Reports, Software Development and Feature Requests