[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Long Wiki Edits Thread

I’ll replace the footnote in entry guards chapter.

Additional fingerprinting content was added to “Tor entry guards”. Maybe add some of that content under a new “Entry Guards” subheading in “fingerprinting” and “Data Collection” chapters.

I’ll get it done!

1 Like

torjunkie:

Trust page -> Fixed (and defluffed) :wink:

:slight_smile:

  • Verifiable builds. Not currently possible for Whonix I understand.

Correct.

1 Like

@0brand

An old attack was observed in the wild that exploited a JavaScript vulnerability in Firefox. [11] The observed version of the attack collected the hostname and MAC address of the victims’ computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a security slider in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings.

The real Q is would it have leaked the MAC address and hostname if successfully run in Whonix-Workstation? I gather not for MAC address, yes for generic Whonix-WS hostname, but that needs to be explicitly clarified I think.

Another nit, spacing on the templates that were edited. After bullet points or mboxes, an extra carriage return is usually required so it doesn’t look bunched up.

@Patrick this Whonix History page on the main ToC is severely outdated i.e. doesn’t show versions beyond 0.4.5.

http://kkkkkkkkkk63ava6.onion/wiki/History

Since we are nearly at Whonix 14, I think this should be removed from the main ToC, and simply sit in a link somewhere stating “Users can read more about the early history of Whonix here.”

Either that, or insert descriptions for > 0.4.5 -> Whonix 13. Which seems a lot of work for very little benefit.

Another option, we just keep the top “history” section, and put all the version info in a separate “Whonix Version” wiki page, since it is ancient and almost nobody will care / read it anyhow.

2 Likes

In the “Comparison with Others” chapter, it refers to “Qubes OS TorVM” as part of all the comparison.

It is deprecated, see:

https://www.qubes-os.org/doc/torvm/

On that basis, recommend we:

  1. Note that; or
  2. Delete all the stuff related to TorVM in the wiki page; or
  3. Send all that info to a deprecated page for posterity, since it’s not a fair comparison if the project is dead. Then I would footnote: “QubesOS TorVM was previously part of this comparison, but it has been deprecated. Interested readers can refer to the historical comparison here [embedded link].”
1 Like

While clean-up & dusting out the Whonix attic is on the cards:

1. The entire page of Dev/Old Changelog should be moved back to the dev backroom where it belongs and moved out of the Whonix Overview section IMO.

It is strictly dev interest only, old and out-of-date for recent developments, badly needs editing, and is probably only read very occasionally.

A leaner, focused ToC page increases readibility and reduces overall complaints e.g. as noticed with various forum topics decreasing in frequency as documentation became clearer or was created to fill a void.

2. There is also a need to manage the size of documentation “chunks” in the most extreme cases. Right now, some of those Tor pages could easily be collapsed into a single page, while the Security etc pages could have a entire section of their own on the main TOC.

The Security Guide in particular has a logical structure to break down into 5 or 6 chunks (pages) e.g. security by platform/VM (host, Whonix-WS, Whonix-GW, Qubes-Whonix) and a couple of other miscellaneous bits (operating system / software package updates, repositories, etc.) that would nicely round out a section on the main TOC, called “Basic Security Guide”.

The same method can be repeated for “Advanced Security Guide”, which is far too long. Now we have a “collapsible” ToC, the impact is negligible, but the improvement will be great.

2 Likes

Please add.

1 Like

Add zerofree -> fixed.

TODO reminder:

  • Remove Dev/Old Changelog from ToC
  • Note no leak of MAC address with that Tor Browser attack
  • Split history page from ancient Whonix version info OR link only to History page (TBD) and remove from ToC
  • Full screen fingerprinting issue
  • Guard fingerprint note
  • Minor template nits
  • Add some (more) shit to Email section
  • Clean up the remainder of the Whonix Overview section harshly
  • Cleave Security Guide into chunks
  • Add remainder of Whonix 14 changes to release notes (from link)
  • Merge some Tor pages in Whonix Overview section
  • Finish Whonix Comparison nit edits (I’ll just note Qubes TorVM is deprecated and kept for comparison purposes only - easiest solution)
2 Likes

Note to self: should use this link https://www.whonix.org/wiki/VirtualBox_Testers_Only_Version more now that I created it a while ago. Just created and then didn’t put it into use.

There is now a separate wiki page for stable and testers-only VirtualBox version.

Should not share the link https://download.whonix.org as it clearly says:

This page is intended for developers only!
Regular users should vist https://www.whonix.org/download/ instead.

My mistake.

I guess we need the same for KVM. @HulaHoop

1 Like

Requests by Patrick

  • Add wiki Libre Software
    development vs development inside a company works -> wiki faq
  • Add to use curl in Whonix users should use curl.anondist-orig -> Dev/anon-ws-disable-stacked-tor

Would like to complete at some point

Working on Libre development for 2 week or so. Unfortunately I’ve been having some creative difficulties. Writers block? I’m close to finishing and normally I would say I’ll have it done latter on today. However, its most likely going to take me a few more days with the way progress is going. As soon as this it finished (all edits are complete and pushed to wiki) I should be able to complete my backlog rather quickly.

I apologize for the delay

2 Likes

I look forward to seeing it. :slight_smile:

-> All done, except:

  • Add some (more) stuff to Email section
  • Clean up the remainder of the Whonix Overview section harshly (Comparison & Authorship pages only left)
  • Cleave Security Guide into chunks
  • Add remainder of Whonix 14 changes to release notes (from link)

Also needed:

  • Any Qubes R4 adjustments for DisposableVMs (sounds like 0brand kinda stuff :wink: )
2 Likes


https://www.whonix.org/wiki/Template:KVM

2 Likes

Cleaned up https://whonix.org/wiki/Template:TorBrowser_Proxy_Configuration based on what we did with custom Tor Browser lately and removed Foxyproxy references.

Needs testing but should work.

3 Likes

Does this still apply…?

Due to a bug in Tor Browser, [1] extra steps are required to use proxies.

This…?

Note: This action will break both the Stream Isolation for Tor Browser and Tor Browser’s tab isolation by socks user name. This worsens the web fingerprint and causes the user to be pseudonymous, rather than anonymous. To mitigate these risks, consider using More than one Tor Browser in Whonix, or better yet, Multiple Whonix-Workstations.

So the fact that we allow other proxies at all would alter the fingerprint. Stream isolation isn’t effective because all connections are headed to the same proxy IP and so use the same circuit.

The part about SOCKS proxies isn’t relevant since we don’t endorse them anyhow.

Based on:

https://sks-keyservers.net/overview-of-pools.php#pool_tor

Tor hidden service

An experimental Tor OnionBalance hidden service is running as hkp://jirk5u4osbsr34t5.onion consisting of the servers marked with Tor support in the status list as backend.

And TorBirdy also using it:

https://trac.torproject.org/projects/tor/wiki/torbirdy/preferences

Use the recommended proxy settings for TorBirdy (Tor)

When this option is selected, TorBirdy will change the proxy settings of Thunderbird to configure it to use the Tor network. The settings this options changes are:

SOCKS host: 127.0.0.1
SOCKS port: 9150
Keyserver: hkp://jirk5u4osbsr34t5.onion 

This is the default option when TorBirdy is installed.

We should probably point any wiki keyserver steps (i.e. key search and uploading keys) to default to the hkp://jirk5u4osbsr34t5.onion instead?

1 Like

Hmm looks like we should put this straight into the wiki somewhere appropriate, since we don’t have proper instructions right now on doing this procedure properly? (And will apply somewhat to future versions of Qubes-Whonix).

https://github.com/Qubes-Community/Contents/blob/master/docs/misc/iaq.md#manually-install-whonix-14-templates

Manually install Whonix 14 templates

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-core-admin-addon-whonix

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw-14
qvm-create sys-whonix-14 --class AppVM --template whonix-gw-14 --label black
qvm-prefs sys-whonix-14 provides_network True
qvm-tags whonix-gw-14 a whonix-updatevm

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws-14
qvm-features whonix-ws-14 whonix-ws 1
qvm-create whonix-ws-dvm-14 --class AppVM --template whonix-ws-14 --label green
qvm-features whonix-ws-dvm-14 appmenus-dispvm 1
qvm-prefs whonix-ws-dvm-14 template_for_dispvms true
qvm-prefs whonix-ws-dvm-14 netvm sys-whonix-14
qvm-prefs whonix-ws-dvm-14 default_dispvm whonix-ws-dvm-14
qvm-tags whonix-ws-14 a whonix-updatevm

To use the new sys-whonix-14 for your UpdateVM, perform the following steps:

qubes-prefs updatevm sys-whonix-14

Then, edit /etc/qubes-rpc/policy/qubes.UpdatesProxy and modify the top lines:

$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix

to become:

$type:TemplateVM $default allow,target=sys-whonix-14
$tag:whonix-updatevm $default allow,target=sys-whonix-14

1 Like

https://www.whonix.org/wiki/Stream_Isolation#Nested_Execution

Done! Please let me know if any changes need to be made. Maybe a little to long?

@torjunkie Since most if not all of my wiki contribs require edits. Would it make more sense for you to make edits in place i.e just make edits to my post? I don’t mind and this would cut down on (sometimes large) semi-duplicate posts. Plus the edit history is still available.

BTW thanks for helping out with my edit backlog :slight_smile:

Libre Software Development VS. Development in a Company

The method used to development of Libre/free software can vary greatly between projects and factors such as software type and design goals of the project play an important roll when deciding which methodology to use. When developing proprietary software a more tradition method is typically used which used a centralized approach. In this model all aspects of the project are tightly managed and participants are given clearly defined rolls with in the project. Only a select few developers have access to the source code and its not uncommon to have many participants dedicated to core development, project management, implementation and bug tracking.

In stark contrast is the Libre[1] model which uses a decentralized style encouraging the users themselves to become involved in the development of the project. In this model participants are loosely managed and the source code is publicly available. This model solves many of the issues faced with closed-source development by integrating users into the developmental process. Since Libre users have the freedom to use and improve the software any way they like[ref]https://en.wikipedia.org/wiki/Free_software#Definition_and_the_Four_Freedoms[/ref], they make ideal candidates to also assume the role of a “developer” of the project.

[blockquote]The terms user and developer here refer to someone’s relationship to the open source software project in question, not to her identity in the world at large.

For example, if the open source project is a Javascript library intended for use in web development, and someone is using the library as part of her work building web sites, then she is a “user” of the library (even though professionally her title might be “software developer”). But if she starts contributing bugfixes and enhancements back upstream[2] – that is, back into the project – then, to the extent that she becomes involved in the project’s maintenance, she is also a “developer” of the project[ref]https://producingoss.com/en/getting-started.html[ref] [end/blockquote].

The relationship between users and developers can be very porous: every user is a potential developer. This principle is apparent in the Libre developmental model.

  • Users should be treated as co-developers - Users are treated like co-developers. As such they should have access to the source code of the software. Furthermore, users are encouraged to contribute additional code , bug reports, bug patches etc. By having more co-developers, the rate in which bugs are found and fixed increases substantially. Note that some users have advanced programming skills, and furthermore, each user’s machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug. This in turn allows the software to evolve at a quicker rate. This concept is termed as Linus’ Law[3] which states:

    [blockquote]“Given enough eyeballs all bugs are shallow.”[/blockquote]

  • Early releases - Since many volunteers are attracted to help develop the software based on the early release. This first version should be released as early as possible. This increases the chances of finding co-developers.

    At least two versions of software should be available

      • Stable version - This version has fewer features than the developmental version but has been thoroughly tested and most identified bugs have been fixed.
      • Developmental version - For users that desire the use of the latest features not found in the stable version. Since this version has not been thoroughly tested, users must being willing to accept the risk of using a version that does not yet have all bugs patched. users can act as co-developers, providing bug reports and submitting bug patches for the developmental version.
  • Use a highly modular structure - The structure of the software should be modular allowing for parallel development on independent interchangeable components.

  • Frequent code integration - Code changes should be merged into a shared code base as often as possible to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds[4] where integration is done automatically on a daily basis.

  • Dynamic decisions making structure - There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors.

Development in a Company
Developing Libre/free software can not not be accomplished using a more traditional method. With a decentralize approach participants have much more flexibility in the developmental process which allows the software to be developed according to technical guidelines. Although this allows for companies to adapt according to different developmental needs. There are elements that can influence the overall outcome of software.

Third Party Software

For companies that only use software that is developed from within there company, the design goals which users expect can be met with less difficulty. However, this may not be the case for companies that also use software developed by other Libre/free companies. This software is developed according to the design goals of the third party project which may run counter to that of the company that uses the software. This applies not only to packages integrated into the software but also to the standalone software that may be used to support development. Changes to third party software can be time consuming and costly and smaller companies may not not have the necessary resources.

This simple illustration shows third party software used by Whonix. Note that some of the third party software also uses packages from other 3rd party project. Many of these companies do not share the same design goals as Whonix (advanced security and anonymity).

   Firefox Web Browser --- Tor Browser ---                            --- Phabricator (bug/issue tracker)
                                          \                          /
                                           Whonix ---> Infrastructure --- MediaWiki
                                          /                          \
                             Debian OS ---                            --- Discource (forum software)
                             /                                                     \  
   Many software packages ---                                                       --- Google search engine 

Company Size
The size of the company has a significant impact on development. Although Libre companies use the same methodology in development, the developmental practices used to achieve these goals is difference across companies of different sizes.

Large Companies

Many large companies employ many full-time employees and may receive contributions from hundreds[ref]The Linux kernel has about 200-250 companies on average per release contributing patches[/ref] of companies which use and depend upon the software, as well as hobbyist and research developers. Many of these companies also integrate third party packages into their software. If design changes are needed in this software the resources are available to either assign an employee to develop, test and submit a patch, or if necessary sponsor the third party company to make the desired changes.

Small Companies

Since small companies have limited resources they do not have full-time employees akin to larger companies (if they have them at all). Its not uncommon for these companies to have a 1 or possibly 2 core developers along with a small number of community members that make contributions towards development. Quite often, due to limited resources these companies must remain focused on core development which leaves less time to develop new features. This in turn prevents developers from presenting users with a unified experience[11] when using their software.

Making Changes to a Third Party Software

Its common for companies to use third party packages in their infrastructure and also integrated into their software. Although they may provide many benefits to the company, they are not always developed with identical design goals. This can lead to software not functioning as a user expects or may even break other packages. There are several options if changes are wanted in the third party software all of which require time and/or resources

  • Polity ask the company to make the changes

  • Submit a Patch that makes sense from their point of view

  • Fork the software and add your own patches

  • Use software from an alternate third party project

The methods used to change software is identical whether the request is from a large company or collaborator from a small community. When requesting changes try look at the software from the perspective of the third party project. The developers are more likely to accept the changes if they also benefit the design goals of the project. If significant workload is added with little benefit to the project, the changes would likely be rejected. Many project have instructions specifying how to submit patches on their web site. Whonix Patches Welcome[12]

The last option is to fork the software and add your own patch. Since maintaining an additional software package could increase the workload substantially. Forking software is usually not an option for small companies with little resources. The better option would be to submit a patch so all users of the software would benefit, not just users of software from one company.

Links

[1] https://en.wikipedia.org/wiki/Free_software

[2] https://en.wikipedia.org/wiki/Upstream_(software_development)

[3] https://en.wikipedia.org/wiki/Linus's_Law

[4] https://en.wikipedia.org/wiki/Nightly_build

[5] https://en.wikipedia.org/wiki/Electronic_mailing_list

[6] https://en.wikipedia.org/wiki/Internet_forum

[7] https://en.wikipedia.org/wiki/Git_(software)

[8] https://en.wikipedia.org/wiki/Mercurial

[9] https://www.discourse.org/

[10] https://en.wikipedia.org/wiki/User_experience

1 Like

My plan is to complete:

to use curl in Whonix users should use curl.anondist-orig

Then start working on:

Qubes R4 adjustments for DisposableVMs

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]