one could send each message as PGP-signed or PGP-encrypted, so as to prevent involuntary modifications and putting malicious words into one’s mouth, or allow only certain recipients decrypt it.
How does that work for a public discussion board (forum)?
Do this:
nslookup www.qubes-os.org
What do you see?
P.S. Sorry, resolved in a different qube. Here is the address from the example (still the same owner):
user@host:~ > whois 104.21.64.1 | grep Organization
Organization: Cloudflare, Inc. (CLOUD14)
You did not pay attention to my previous reply. These are entirely different:
nslookup qubes-os.org
nslookup www.qubes-os.org
Web site has a www. Doesn’t it?
For the information of anyone who is reading this thread:
subdomain1.example.com, subdomain1.example.com and example.com are entirely different. Each sub-domain could be hosted by a different host (e.g. one could be on Amazon, one or Microsoft, one is self-hosted, one is behind a CDN, …). Please read about CNAME, A and other DNS record types.
We have
www.qubes-os.org
forum.qubes-os.org
openqa.qubes-os.org
yum.qubes-os.org
deb.qubes-os.org
archlinux.qubes-os.org
and many others. Each of them could be self-hosted or hosted by a different company.
If you send an HTTP request to qubes-os.org, it hits CF and is 301-redirected to www.qubes-os.org, at least for the home page. It’s common for users to miss out the www for the first request if typing in the address. If they don’t trust the CF certificate then that will break.
If there are other services that expect qubes-os.org to be CF then you can’t just change the DNS record to point to the same place as www., and in that case the 301-redirect is probably the most you can reduce users’ exposure to CF. In the other case, it should be trivial to move over.
No opinion from me on whether to use CF at all, but cutting out odd edge cases like this is worth doing when it’s clean and easy.
You did not pay attention to my previous reply.
I did. I do. Just for some reason your reply (with an earlier date) came to my email after mine, so I have obviously replied before even receiving yours.
These are entirely different:
nslookup qubes-os.org nslookup www.qubes-os.orgWeb site has a www. Doesn’t it?
Yes, indeed. I didn’t pay attention to this as I always type without www and don’t check if the IP addresses match for every website. I believe that’s what most people do (as @nokke explained too), so one first connects to CF, then gets HTTP redirected to the www (301 != CNAME).
I guess that (and not the onion) solves/cancels the MITM concern if one explicitly types www, which is good. However the rest of the CF-related concerns remain. - Yes, CF does browser fingerprinting. It is even in a PDF written by them:
“Fingerprint HTTP requests to
protect sites against known
and emerging botnets with
automatic mitigation rules”
I have read other docs about it through the years, so anyone can search for oneself for more info.
Security vs privacy isn’t a real thing. Security enables privacy.
Privacy is a decision to either keep something completely secret (only known to oneself) or to restrain knowledge to a certain group of people and/or purposes. Security is about whether or not a malicious actor can violate that decision once made.
For example, I use a password database. Privacy is my decision to not let anyone else see that database. Security is whether or not a person could see that database anyway, through remote hacking, physically stealing my computer, etc.
QubesOS provides security by sandboxing the database in a VM that has no internet connection, protecting the integrity of my privacy decision. So QubesOS is not directly about privacy - it does not make the decisions for me - but it empowers my privacy by providing additional security.
Some folks may not be aware (or may have forgotten) that we strive to distrust the infrastructure, which means we certainly don’t expect you to trust the website. That’s why we’ve intentionally set up the website and documentation as Git repos that you can download. You can then verify the PGP signatures directly on the Git tags or commits. As usual, the relevant keys are in the qubes-secpack. This setup allows you to use the same chain of trust that you use for verifying Qubes ISOs to verify the website and documentation. Next, you can either serve the website locally or simply read the plain text directly in a terminal or text editor. This was one of the main motivations for setting up the website and documentation as Git repos, PGP-signing tags/commits in those repos, and writing as much of it as possible in Markdown.
Some folks may not be aware (or may have forgotten) that we strive to distrust the infrastructure, which means we certainly don’t expect you to trust the website.
Then why link to it?
Why link to what? The FAQ entry about trusting the website? In order to make readers aware of it, of course.
If you don’t want to trust the live website, then you can, as just explained, get your own local, PGP-verified copy of it and read the same FAQ entry there. But I can’t link to your local copy, because it is a local copy, so the next best thing is to show you where it is on the live website. Then, you can navigate to the same place in your local copy.
What is your suggested alternative course of action? Refrain from linking to the website at all? But then how would readers know where to look, even if they have their own local, PGP-verified copies? How would they be aware that such content even exists? Do you really expect them to do an exhaustive search by reading the entire website and intuitively recalling the relevant contents whenever anyone references something contained therein?
I wonder if you realize the Catch-22 in this whole thing:
A distrusted message on a distrusted web forum links to a distrusted website which is supposed to inform how to download data from another distrusted website (which is well known to be unreachable in whole countries), then verify a PGP signature using software and keys downloaded from the same distrusted (and potentially unreachable) infrastructure.
Parallel to that, you admit that “we actually trust GitHub quite a bit”, and one reads that there is some supposedly ongoing work (deprioritized and left behind for 6+ years), i.e. that in some indeterminate future there may be actual distrust, but meanwhile it is just theoretical. IOW, from the 3 items listed in the last link, the only one that stands out as actuality is the free beer.
What is your suggested alternative course of action?
The only alternative to contradiction is the lack of it.
Privacy is also a contradictory subject.
This is not exactly true: you can get the keys from various, independent places and compare them until you are convinced: There is no way to validate Qubes Master Signing Key
What you quoted is exactly true, as it does not involve independent places (like T-shirts).
Are you saying that the keyservers of Ubuntu and GNUPG are dependent on Github?
I love the discussion we are having in this topic, I’m learning a lot from all your smart people, even if it’s not going exactly the direction I tried to start the topic off as but that’s ok.
Let me summarize my perspective because I am after all the OP.
I think the main goal of this topic isn’t understood by everyone. My experience in this forum is that there are a lot of people who believe qubes os is security only, and then there are a lot of people who think it’s security and privacy. There is in my experience a lot of arguing about this. That’s what this topic is about. I hope we can at least come to some kind of “official” stance on if qubes os is security only or if its security and privacy.
Keep in mind that this is not about if qubes os has done a good job with adding privacy features to qubes os. I know that adding whonix support to qubes os is great for privacy even though I got the impression this was done for security of updates and installs but regardless of what the reason behind it was, it’s still great for privacy.
The people who have the opinion that qubes os should not be about security and privacy make 99% of their arguments against privacy when the topic is about privacy. Some people have difficult to detect this even though I think it’s very obvious. For example, if someone makes a post that says tor is more secure than https and quotes the whonix docs with the reasons why tor is more secure than https, then the anti-privacy people will not make any replies that support the suggestion of making the forum .onion. They will make arguments against it such as tor is not e2ee if you use whonix because its not encrypted between whonix workstation and whonix gateway.
Then the question comes to my mind if they are really honest users or are they working for usa’s deep state who hates privacy for the people. They fund people to mislead projects so they don’t get better privacy. USA’s deep state would go crazy angry if all the FOSS projects websites and all surrounding communities started using .onion and staying inside tor because that makes it more difficult to attack and mass surveillance.
Just keep this in your minds from now, are they arguing against privacy or are they making supporting arguments?
It’s great you smart people have great eye for details and understand the most advanced stuff but it seems sometimes like you get lost a bit by thinking to deep. It’s not actually that complicated to understand that .onion is both more secure and better privacy than clearnet with tls. Be careful to not argue against this statement. If you are neutral then at least give both a argument against and also a supporting argument. But if you are a real freedom fighter then stick to just supporting arguments.
Just to link to the respective discussions:
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.
That is not what I am saying but what the Qubes team is saying.
What I am saying is that suggestions to look for trusted places in a distrusted infrastructure is a logical contradiction. If you distrust the whole thing, you distrust its parts as well.
Sorry for going off-topic myself by replying to other off-topic.
Hopefully the smart people will answer your questions.
It’s not a catch-22 at all, because there are ways to authenticate the Qubes Master Signing Key independently using whatever means are acceptable to you (e.g., the PGP Web of Trust).
If you had bothered to actually read the issue you’re linking to, you’d realize that it doesn’t apply to this conversation at all, since it doesn’t affect trusting the PGP-signed tags/commits on any of the repos.
You’re taking that quotation out of context by intentionally dropping the rest of the sentence. The part you cut off says, “…we actually trust GitHub quite a bit for workflow and issue tracking,” which also makes it clear that it doesn’t apply to this conversation. This is deliberately misleading and arguing in bad faith.
That’s not true, and that’s not even what the FAQ entry says. It says, “We distrust the infrastructure including GitHub (though there are aspects we’re still working on).” GitHub is already distrusted (and has been) in many important ways, but it’s not 100% distrusted yet. The actual percentage is not quantifiable, but for the sake of illustration, let’s say it’s 80%. If we’re 80% of the way there, but not 100%, then it’s incorrect to say, “meanwhile it is just theoretical.” You are effectively saying, “Until you are 100% done, I will treat you as being 0% done.” This is a misleading misrepresentation.
No, all three are true and accurate, and you’ve provided no good evidence or reason to think otherwise.
In other words, you’re not able or willing to provide any suggested alternative courses of action or any constructive feedback in general.
Making an onion service for the forum has nothing to do with making Qubes OS more private or whether Qubes OS is for privacy in addition to security.
Suppose you’re a detective investigating a crime. You’re trying to find out what happened, so you start interviewing witnesses. You won’t blindly trust what any one witness tells you, since they might be lying or misremembering. You also won’t trust any pair of witnesses, even if their stories match, since they could be in cahoots. But what if you get the same story from ten unrelated witnesses? Or a hundred? At some point, it becomes improbable that they’re all in cahoots or all misremembering in exactly the same way. The simplest explanation is that they’re reporting what they witnessed. A similar principle applies here.