Discourse updates

Website
1

Hi,

After some routine updates to Discourse, I identified some quirky regressions regarding the category logos and the header logo.

The category logo size issue is confirmed as an upstream regression and so we await a fix to land in the next release.

The header logo issue is another one of those onion-hostility changes that relates to forcing ‘https’ in the protocol, and absolute rather than relative URLs. If I switch on ‘force_https’ mode, I break the onion service entirely I think.

Nonetheless I was able to workaround both with some custom CSS and Nginx tweaks, so you hopefully don’t notice much if anything has changed.

There may be other (minor) impacts related to logo image sizes, other cases of assets being referenced via absolute URLs and its impact on .onion, though probably (hopefully) not. But I thought I’d get on the front foot by saying the usual disclaimer - please avoid making new topics about it or expecting any magic fixes due to Whonix budget constraints, as it’s unlikely we’ll be able to do much.

When Discourse fixes the image issue upstream, I can remove my custom CSS tweaks and then I’ll bin this post.

Obviously if you encounter massive show-stopping problems using the forums, let Patrick know. But the fact that I can add this post indicates things are basically fine.

Happy new year folks…

3 Likes
2

It is my opinion that sticking with Discourse will just add more and more similarly tedious work load to Whonix’s web-dev.

When resources are indeed limited, the right thing will be to move away from this platform.

Another one:

3

Limited resources is one of the issues that prevents changing to a different platform. Regardless of which platform Whonix uses some/many of the same problems will be encountered. Not only that but moving to an new platform will bring new problem.

It might sound good but its not that easy. Plus there might not be any interest by Whonix developers atm.

Related:

Related:

https://whonix.org/wiki/FAQ#Privacy_on_Whonix_Website

Due to the structure of Libre Software development and the limited funding available to Whonix it is economically infeasible to tackle most issues (usability, privacy, security) of these webapps.

1 Like
4

A knee jerk reaction and invalid / not-applicable when moving from a resource-draining platform to a simpler one actually makes more sense in a limited funding and manpower project.

Same automatic response was given about Whonix having to stay with KDE. And here, magically, we have XFCE which will actually save development resources in the future.

I am sure Whonix will eventually move away from Discourse. The only question is how many more hours to spend (down the drain) until the decision is made.

Now not only we have to allow JS, we also have to set security level to minimal to interact on the forum? others would raise eyebrows.

5

rhhhr:

Same automatic response was given about Whonix having to stay with KDE.
And here, magically, we have XFCE which will actually save development resources in the future.

Skill, hard work, many work hours, contribution by @Algernon. No magic.

I am sure Whonix will eventually move away from Discourse.

It’s already forum number 4 (sourceforge forum, mediawiki forum,
smfforum, discourse). So yeah, just wait enough years and you will be
right eventually whenever you say it for whatever reason. :slight_smile:

The only question is how many more hours to spend (down the drain)
until the decision is made.

It’s not like other forums before caused much less issues, specifically
wrt onions.

Now not only we have to allow JS, we also have to set security level to minimal to interact on the forum?

The forums are only a byproduct of Whonix. (As per
Frequently Asked Questions - Whonix FAQ ) In other
words, the forums are not the main product by Whonix. Since there is no
Freely (as in Licensing / Freedom) available forum software that aims
being compatible with security level minimal in Tor Browser or Tor
Browser compatibility at all, this cannot be a criteria by choosing the
forum software since any upgrades by the forum software could break this
feature leading to chase yet another forum software.

1 Like
6

Well, I like to be right, but a higher priority is to be safe. You know Patrick, that if servers / route (MITM) is somehow compromised (and that’s your basic premise - that they perhaps indeed compromised), then Whonix forums users are at a greater risk when forced to use:

  • Clearnet
  • JS
  • Lowest security level

I don’t need to explain why, you know that better than me (and a lot of the risks is documented on Whonix wiki).

Whonix isn’t a simple plug and play gadget. This is a complex project, and as such it requires active support and an community to thrive and grow, or otherwise will be used mostly by a handful of linux networking geeks. There is currently no such alternative for the forums.

Just imagine you chose Fedora rather than Debian as a base Distro for Whonix. Imagine the headaches you’d face with a distro that tries to be cutting edge rather than stable. In the same way, and while there are no guarantees, I think forum software for this project should place emphasis on simplicity and stability. Updates - mostly (or only) for security reasons rather than shiny features. I am not an expert on that. I just hope people keep an open mind to study the options.

7

Who told you that Whonix forum is not simple and stable and not secure? (you need proof on this claim)

Just because there is JS , doesnt make the forum magically malware. We dont recommended JS because it MAY emphasis a risk on the user because it can be used to in ways to harm users IF its used wrongly like similar what is been done by horrible companies like Google or Microsoft or Cloudflare …etc.

Also to attract the new users to know how to interact easily with our forum it NEEDS to be shiny and nice looking (because geeks dont care about shiny stuff like the average users).

And there is other channel Whonix provide inside whonix-workstation like IRC chat that is fully torrified.

What else? We have social media accounts only accessible while using Tor + free JS and we already have mentioned that in our social media list: (specially Galaxy3)

We have our Mailing list:

…etc So if the user want to avoid the forum in order to communicate with us then there many other ways to do that. And your point of not having shiny,simple forum is absolutely the opposite of how is that useful to new users.

8

I suggest you refer to Whonix’s wiki to learn some basics about security. Your reply undermines Whonix when you use “we” (as you did with your suggestions to Monero community).

Someone can mistakenly think your level of knowledge represents Whonix developers’ knowledge.

To other readers, JS is risky even when used by innocent and honest sites because it makes attacks by third parties easier to accomplish. For example, malicious JS can be injected by an exit node, with SSL certificate issues this translates directly into a malicious script running on browser side. All this is well documented on Whonix wiki.

Further I recommend you refer to Tor project documentation if you don’t understand the differences in the security levels.

Just a few weeks ago you demonstrated you don’t know the first thing about Whonix with your remark about Tor browser tabs not being stream isolated.

Then you give a link to a list of sites such as Facebook, Google+, YouTube.

Should I really explain the issues with Facebook and Google to a long term Whonix contributor?

Regarding alternatives on your list that may be better, there is no activity there, nothing like this forum.

Go and learn.

9

Never been , never claimed , not even my job.

Hows that related to whonix forum security while you said “malicious JS can be injected by an exit node, with SSL certificate issues” ? but its as i said it emphasis risk on the user.

Yes because i missed this info, now i know so whats the problem with that? im glad i have good community whos telling me what i missed.

Did i told you to communicate with Whonix through these sites if you want no JS? Please read carefully what i said.

now we come to “More Activity” not “More Secure” perspectives… Now i know that you just want to write any nonsense and nothing more than that.

10

It is generally accepted that the infrastructure should not be trusted and using any resources unnecessarily to shore up infrastructure would be a waste of time. qubes.os FAQ applies here.,

https://qubes-os.org/faq/#should-i-trust-this-website

Should I trust this website?

This website is hosted on GitHub Pages (why?). Therefore, it is largely outside of our control. We don’t consider this a problem, however, since we explicitly distrust the infrastructure. For this reason, we don’t think that anyone should place undue trust in the live version of this site on the Web. Instead, if you want to obtain your own, trustworthy copy of this website in a secure way, you should clone our website repo, verify the PGP signatures on the commits and/or tags (signed by the doc-signing keys), then either render the site on your local machine or simply read the source, the vast majority of which was intentionally written in Markdown so as to be readable as plain text for this very reason. We’ve gone to special effort to set all of this up so that no one has to trust the infrastructure and so that the contents of this website are maximally available and accessible.

https://qubes-os.org/faq/#what-does-it-mean-to-distrust-the-infrastructure

What does it mean to “distrust the infrastructure”?

A core tenet of the Qubes philosophy is “distrust the infrastructure,” where “the infrastructure” refers to things like hosting providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc. As a project, we focus on securing endpoints instead of attempting to secure “the middle” (i.e., the infrastructure), since one of our primary goals is to free users from being forced to entrust their security to unknown third parties. Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).

Users can never fully control all the infrastructure they rely upon, and they can never fully trust all the entities who do control it. Therefore, we believe the best solution is not to attempt to make the infrastructure trustworthy, but instead to concentrate on solutions that obviate the need to do so. We believe that many attempts to make the infrastructure appear trustworthy actually provide only the illusion of security and are ultimately a disservice to real users. Since we don’t want to encourage or endorse this, we make our distrust of the infrastructure explicit.

https://qubes-os.org/faq/#why-do-you-use-github

Why do you use GitHub? (Could be changed to “Why use Discourse?”)

Three main reasons:

  1. We distrust the infrastructure, including GitHub (though there are aspects we’re still working on).
  2. It’s free (as in beer). We’d have to spend either time or money to implement a solution ourselves or pay someone to do so, and we can’t spare either one right now.
  3. It has low admin/overhead requirements, which is very important, given how little time we have to spare.

Admin/overhead of Discourse (is ?) vs. What forum software did you say has lower Admin/overhead? better security? Works with onions? Will not have any/other problems not currently experienced on whonix.org?

A knee jerk reaction would be so assume that none of your concerns have been brought up or considered before. But just like everyone else you claim to have the answer but aren’t will to help move whonix.org in that direction. For starters this might include

  1. Finding suitable forum software to migrate to. Meaning requires low resources, low admin overhead. Tor/.onion compatible, no Java Scirpt…
  2. Testing this platform for whonix developers/sysadmin
  3. …

Everyday whonix deveopers have countless ideas brought to them by the good idea fairy but no one is willing to lift a finger to help. So my question:

If this i so important to you what would you be willing to do to make it happen. I mean if I want something done on whonix.org I have to take the initiative Although a very corny and cliche, “Talk is cheap actions speak” applies here.

1 Like
11

Excellent!

Frequently asked questions (FAQ) | Qubes OS with modifications would be a good addition for Placing Trust in Whonix ™ but we don’t have gpg signed documentation. We have GitHub - WhonixBOT/whonix-wiki-backup: Backup using git-mediawiki. Alternative to XML Backups https://github.com/WhonixBOT/WhonixWikiBackups in plain text but it’s just a backup. Plain text (yay!), but no functional links and no gpg signatures and many deprecated empty pages that now just redirect.

Frequently Asked Questions - Whonix ™ FAQ also applies.

12

Definitely a good addition with some mods. Just finishing up Wiki/Webmail. More specificaly finishing Encypted_Webmail documentation and I’ll put this to the head of the list. Won’t take to long. :wink:

1 Like
13

Done!

https://whonix.org/w/index.php?title=Trust&oldid=40211&diff=cur

Didn’t think you wanted (GitHub - WhonixBOT/whonix-wiki-backup: Backup using git-mediawiki. Alternative to XML Backups https://github.com/WhonixBOT/WhonixWikiBackups) with this since its just a backup. Was looking into a solution similar to how Qubes Os converts their docs to local machines. I’m sure its possible to install a parser or covert to .pdf if someone wanted to.

1 Like
14

Related:

15

Just reading the forums can already be achieved without JS, and while using the highest level of TBB security level. So, we distrust the infrastructure and can take the means to protect ourselves (at least to a certain extent) while browsing the forums.

Offline docs may further improve level of security, especially since the search feature here does require JS, but will not address the interaction issues. Not being able to click on the like button isn’t a major issue in my opinion, but not being able to post without JS is.

Very good points. How about support via mailing lists (maybe one, “support”, will suffice) as done by the aforementioned projects of Qubes and Tails, as well as by others such as Debian?

IRC: since past communication isn’t stored users ask the same questions again and again and do not benefit from past good replies. Clearly inferior in my opinion to searchable options.

A lazy, grumpy user complained a few days ago, now, as a result Whonix has better and clearer docs. Perhaps “thank you” is in order :wink:

16

Javascript is risky:

  1. It assists advanced fingerprinting techniques.
  2. It assists browser exploits.

Javascript on innocent, well meaning sites is still risky, because the risk of the content being tampered with by a third party is always there. If the content is tampered with when the browser is set to block JS, the potential damage to the user is lower than when JS is allowed.

That’s why blocking JS (on any site, even our own site) is certainly safer security-wise. Regarding fingerprinting, there are arguments to both sides (most users do not block JS so doing that puts one in a smaller group), but in my opinion the advanced fingerprinting allowed by JS is a greater threat than being in a smaller group. And, to the very least, the user needs to have the option of making the decision.

How can third parties inject Javascript to innocent sites?

  • By modifying the content on the server (hack)
  • By modifying the content of a component that gets updated
  • By using MITM (Man in the middle) attacks

What are MITM attacks, in this context?

  • Tor exit node injecting content into the requested page
  • Someone on your network that does ARP redirection injecting content to the requested pages (not possible with Tor?)
  • Any remote scripts used getting revised by above methods or others

Doesn’t SSL protect against tamper attempts? only to a certain extent. SSL can be stripped (user redirected to a non-SSL site). Or the MITM uses a different SSL certificate. Certificates can be forged or stolen. Or the CA (Certificate Authority) is malicious to begin with or otherwise compromised.

17

True, but some users would prefer both. Meaning having a choice of the two. A lot of work has already been done on offline docs (not by me). Haven’t decided whether to take this on but if I had some help…:wink: :wink:

Yes this seems to work for those projects. To he honest though, I use Qubes but don’t use the mailing list very often. Mostly because of usability - its always a trade off. Maybe I’m just spoiled with Whonix forums.

Tails used to have a support forum. So I actually see Tails mailing list as a regression of sorts.

Ha Ha . That “user” cut into my playtime because he/she was to lazy to do it him/ herself. I’ll tell you what, if that user would be willing to help out from time to time I’m sure there would be many thanks from the community including myself. Until then, that “user” will have to settle for patting him/herself on the back. :stuck_out_tongue_winking_eye:

18

There is / has been a whonix-users mailing list but always was been
underused. Not even a link to it anymore. Mailing lists are not well
searchable either. Wouldn’t want to duplicate answers.

Tor Project / Tails doesn’t provide a forum either. Let alone a
javascript-free one.

A mailing list is something that geeks appreciate. Non-geeks usually
don’t get it. Thing of the past, thing for geeks.

3 Likes
19

@paul Unfortunately JS is here to stay - not that I necessarily like that. It provides functionality that is impossible with plain HTML and is a better alternative than turds like Flash. Discourse is infinitely better than the buggy php stack that was before it.

We do take precautions and privde the most secure ways possible to access the forums whether through an onion or via clearnet with a Let’s Encrypt cert. In the case of the latter, no MITM will go unreported thanks to transparency.

2 Likes
20

Only if the cert. itself is problematic. But there are other ways to do MITM with SSL.

In some cases it is done selectively, so more difficult to spot.

And, your response, that tries to convey a degree of safety and security, is quite contrary to the “we distrust the infrastructure” approach as explained above.