Jonathan Proulx:
How this got off into TorBrowser puzzles me. Presumably the goal for clients is to reach them where they are. Certainly providing a diversity of clients is a "good goal" but beyon dreaching more users I fail to see how it helps the network writ large. I suppose indvitual users woudl be mroe secure with a wider array of clients available, but that's generally true of the Windows monculture in desktop computers. And as we shift to Android moblie devices as people primary internet connection many of those issues will likely follow, but I digress...
With TB as a client, I just mentioned the development end in an earlier email. There's certainly more to it.
There are certainly weaknesses in a client monoculture that differs from the network/node side on some levels, as the client software is in some chases the user base.
But it always seem to me users sometimes use the OS that provide the applications they want. TB matters insofar as one of those applications, I tend to think.
On the whole, one needs to consider that the same single vulnerability that weakens an OS on the network level could also affect the desktop.
For relay diversity it's more obvious. If you can sabotage 93.6% of the band width because a Linux specific bug either in TOR or just the OS that's a huge problem (from https://torbsd.github.io/oostats/relays-bw-by-os.txt, sorry I forget who to credit but if you read the thread you will see...).
And if you compromise the vast majority of desktop users, you don't just implicate those users with the vulnerability, but a big drop in the majority client OS would mean the crowd, so desperately needed for an anonymity solution, thins out.
Credit? Yes... us at TDP (https://torbsd.github.io/)
I run https://atlas.torproject.org/#details/A53C46F5B157DD83366D45A8E99A244934A14C... which in it's current incarnation is FreeBSD 11 since January 2017 or so. Though for most of it's life had been Debian or Ubuntu.
I'm definitely a "Linux Weenie" specifically of the Debian family so I enjoy what "unattended upgrades" can do interms of when and what you automatically upgrade and when/if to reboot if needed, but really the 98% of that that really matters you can do with a small shell script + cron. Installing TOR isn't really appreciably harder either "pkg install tor" is just as easy as "apt install tor" for people who want to live in a packed rather than source world. So I don't think the complecity barrier is real (though the perception of one may be a deterrent).
As I stated earlier, the tools for FreeBSD and OpenBSD are there.
utilities like syspatch on OpenBSD stable can be put into a regular cron job.
Same with pkg and freebsd-update on FreeBSD.
Note the BSDs provide daily/weekly/monthly emails by default, and any notifications are already or could easily be integrated into those emails.
Looking at https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_server... it seems TOR relay OS's while skewed toward Linux and away from Windows aren't that far off from at least soem studies of "Internet based servers' market share". I debate the accuracy of these in general but within some largish margin of error they are probably not untrue.
Monoculture isn't just a TOR problem. I think we should advocate for it but I don't think we can solve it just in a TOR context. So yes if you run relays go learn some underserver Operating Systems the BSDs are a little weird at first coming from Linux but you're clever you'll manage or maybe go way out there to one of the Firefly (OpenSolaris) variants...but diversify all the things nto just TOR.
I'm a little confused by that paragraph, but I do think it's possible to rectify the situation to a large extent. A large number of firms use BSD in their infrastructure or code (WhatsApp, NetFlix, Juniper...). What if some started to run relays or bridges? What if there was a list of BSD virtual private server firms that allowed Tor relays/bridges? I can go on and on, but those are the type of approaches we are trying at TDP.
Giving up on network diversity for Tor is essentially allowing it to remain vulnerable to a single kernel weakness.
On a side note, there's a reason why computing systems tend to monocultures. They are easier to build, maintain and develop on. It's more efficient to make the same exact widget out of a machine than it is to make six variations. That doesn't apply to the many current and potential relays operators out there.
g