Inferencium/website
1
0
Fork 0
Code Issues Activity

Merge branch 'blog' into alpha

Browse Source
This commit is contained in:
inference 2023-10-26 01:01:39 +00:00
commit 3ff9f0a3e8
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
4 changed files with 516 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

175
blog/foss_is_working_against_itself.html Normal file
View File

@ -0,0 +1,175 @@
<!DOCTYPE html>
<!-- Inferencium - Website - Blog - #0 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 5.0.0-alpha.1+31 -->
<html>
<head>
<title>Inferencium - Blog - FOSS is Working Against Itself</title>
<link rel="stylesheet" href="../main.css">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<!-- Navigation bar -->
<div class="sidebar">
<a href="../index.html"><img src="../asset/img/logo-inferencium-no_text.png" width="110px" height="110px"></a>
<a href="../index.html" class="title">Inferencium</a><br>
<br>
<br>
<div><a href="../about.html">About</a></div>
<div><a href="../contact.html">Contact</a></div>
<div><a href="../blog.html">Blog</a></div>
<div><a href="../documentation.html">Documentation</a></div>
<div><a href="../source.html">Source</a></div>
<div><a href="../key.html">Key</a></div>
<div><a href="../changelog.html">Changelog</a></div>
</div>
<body>
<h1>Blog - #0</h1>
<section id="blog">
<h2>FOSS is Working Against Itself</h2>
<p class="update_date">Posted: 2022-01-27 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-11-09 (UTC+00:00)</p>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc">Table of Contents<a/></h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#examples">Examples</a></li>
<ul>
<li><a href="#examples-smartphones">Smartphones</a></li>
</ul>
<li><a href="#solution">Solution</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
</section>
<section id="introduction">
<h2 id=introduction"><a href="#introduction">Introduction</a></h2>
<p>The world has become a dangerous, privacy invading, human rights stripping, totalitarian place;
in order to combat this, people are joining a growing, and dangerous, trend, which I will refer to
in this post as the "Free and Open Source (FOSS) movement". With that stated, I will now debunk the
misinformation being spread inside of this extremely flawed movement.</p>
<p>The
<a href="https://en.wikipedia.org/wiki/Free_software">FOSS</a>
movement is an attempt to regain
<a href="https://en.wikipedia.org/wiki/Privacy">privacy</a>
and
<a href="https://en.wikipedia.org/wiki/Control_(psychology)">control</a>
over our devices and data, but the entire concept of FOSS-only, at the current time, is
severely, and dangerously, flawed. What the FOSS community does not seem to understand is the fact
that most FOSS software cares not about
<a href="https://en.wikipedia.org/wiki/Security">security</a>.
"Security"; keep that word in mind as you progress through this article. What is security? Security
is being safe and secure from adversaries and unwanted consequences; security protects our rights
and allows us to protect ourselves. Without security, we have no protection, and without protection,
we have a lack of certainty of everything else, including privacy and control, which is what the
FOSS movement is seeking.</p>
<p>FOSS projects rarely take security into account; they simply look at the surface level, rather
than the actual
<a href="https://en.wikipedia.org/wiki/Root_cause_analysis">root cause</a>
of the issues they are attempting to fight against. In this case, the focus is on
privacy and control. Without security mechanisms to protect the privacy features and the ability to
control your devices and data, it can be stripped away as if it never existed in the first place,
which, inevitably, leads us back to the beginning, and the cycle repeats. With this
<a href="https://en.wikipedia.org/wiki/Ideology">ideology</a>,
privacy and control will *never* be achieved. There is no foundation to build privacy
or control upon. It is impossible to build a solid, freedom respecting platform on this model.</p>
</section>
<section id="examples">
<h2 id="examples"><a href="#examples">Examples</a></h2>
<section id="examples-smartphones">
<h3 id="examples-smartphones"><a href="#examples-smartphones">Smartphones</a></h3>
<p>A FOSS phone, especially so-called
<a href="https://en.wikipedia.org/wiki/Linux_for_mobile_devices#Smartphones">"Linux phones"</a>
are completely
detrimental to privacy and control, because they do not have the security necessary to enforce that
privacy.
<a href="https://en.wikipedia.org/wiki/Bootloader_unlocking">Unlocked bootloaders</a>
prevent the device from
<a href="https://source.android.com/docs/security/features/verifiedboot/">verifying the integrity of the boot chain</a>,
including the OS, meaning any adversary, whether a
stranger who happens to pick up the device, or a big tech or government entity, can simply inject
malicious code into your software and you wouldn't have any idea it was there. If that's not enough
of a backdoor for you to reconsider your position, how about the trivial
<a href="https://en.wikipedia.org/wiki/Evil_maid_attack">evil maid</a>
and data extraction attacks which could be executed on your device, without coercion?
With Android phones, this is bad enough to completely break the privacy and control the FOSS
movement seeks, but "Linux phones" take it a step further by implementing barely any security, if
any at all.
<a href="https://en.wikipedia.org/wiki/Privilege_escalation">Privilege escalation</a>
is trivial to achieve on any Linux system, which is the reason Linux
<a href="https://en.wikipedia.org/wiki/Hardening_(computing)">hardening</a>
strategies often include restricting access to the root account; if you
<a href="https://en.wikipedia.org/wiki/Rooting_(Android)">root your Android phone</a>,
or use a "Linux phone", you've already destroyed the security model,
and thus privacy and control model you were attempting to achieve. Not only are these side effects
of FOSS, so is the absolutely illogical restriction of not being able to, or making it unnecessarily
difficult to, install and update critical components of the system, such as proprietary
<a href="https://en.wikipedia.org/wiki/Firmware">firmware</a>,
which just so happens to be almost all of them. "Linux phones" are not as free as
they proclaim to be.</p>
<p>You may ask "What's so bad about using
<a href="https://lineageos.org/">LineageOS</a>?",
to which I answer with "What's not bad about it?".</p>
<ul>
<li>LineageOS uses
<a href="https://github.com/LineageOS/hudson/blob/master/lineage-build-targets">debug builds</a>,
not safe and secure release builds.</li>
<li>LineageOS requires an unlocked bootloader. Even when installed on devices which support custom
Android Verified Boot (AVB) keys, the bootloader cannot be locked due to lack of the OS being
signed.</li>
<li>LineageOS does not install critically important firmware without manual flashing, requiring users
to perform a second update to install this firmware; this likely causes users to ignore the
notification or miss firmware updates.</li>
<li>LineageOS does not implement
<a href="https://source.android.com/docs/security/features/verifiedboot/verified-boot#rollback-protection">rollback protection</a>,
meaning any adversary, from a stranger who physically picks up the device,
to a goverment entity remotely, can simply downgrade the OS to a previous version in order to
exploit known
<a href="https://en.wikipedia.org/wiki/Vulnerability_(computing)">security vulnerabilities</a>.</li>
</ul>
<p>LineageOS is not the only Android OS (commonly, and incorrectly, referred to as a "ROM") with such
issues, but it is one of the worst. The only things such insecure OSes can provide you are
customisation abilities, and a backdoor to your data. They are best suited as a development OS, not
a production OS.</p>
</section>
</section>
<section id="solution">
<h2 id="solution"><a href="#solution">Solution</a></h2>
<p>What can you do about this? The answer is simple; however, it does require you to use logic,
fact, and evidence, not emotion, which is a difficult pill for most people to swallow. Use your
adversaries' weapons against them. The only way to effectively combat the privacy invasion and lack
of control of our devices and data is to become a
<a href="https://en.wikipedia.org/wiki/Turncoat">renegade</a>
and not take sides. Yes, that means not taking sides with the closed source,
proprietary, big tech and government entities, but it also means not taking sides with any
FOSS entities. The only way to win this war is to take *whatever* hardware and software you can, and
use it tactically.</p>
<p>The only solution for phone security, privacy, and control, is to use a Google Pixel (currently,
Pixel 4a-series or newer) running
<a href="https://grapheneos.org/">GrapheneOS</a>.
Google Pixel phones allow you complete bootloader freedom, including the
<a href="https://android.googlesource.com/platform/external/avb/+/master/README.md#pixel-2-and-later">ability to lock the bootloader after flashing a custom OS</a>
(GrapheneOS includes a custom OS signing key to allow locking the bootloader and enabling verified
boot to prevent
<a href="https://en.wikipedia.org/wiki/Malware">malware</a>
persistence, evil maid attacks, and boot chain
<a href="https://en.wikipedia.org/wiki/Data_corruption">corruption</a>),
<a href="https://support.google.com/nexus/answer/4457705">long device support lifecycles</a>
(minimum 3 years for Pixel 4a-series to Pixel 5a, minimum 5
years for Pixel 6-series and newer), and
<a href="https://source.android.com/docs/security/bulletin/pixel/">guaranteed monthly security updates</a>
for the entire support timeframe of the devices.</p>
</section>
<section id="conclusion">
<h2 id="conclusion"><a href="#conclusion">Conclusion</a></h2>
<p>Use what you can, and do what you can. By neglecting security, you are, even if unintentionally,
neglecting exactly what you are trying to gain; privacy and control.</p>
</section>
</section>
</body>
</html>

100
blog/systemd_insecurity.html Normal file
View File

@ -0,0 +1,100 @@
<!DOCTYPE html>
<!-- Inferencium - Website - Blog - #1 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 5.0.0-alpha.1+28 -->
<html>
<head>
<title>Inferencium - Blog - systemd Insecurity</title>
<link rel="stylesheet" href="../main.css">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<!-- Navigation bar -->
<div class="sidebar">
<a href="../index.html"><img src="../asset/img/logo-inferencium-no_text.png" width="110px" height="110px"></a>
<a href="../index.html" class="title">Inferencium</a><br>
<br>
<br>
<div><a href="../about.html">About</a></div>
<div><a href="../contact.html">Contact</a></div>
<div><a href="../blog.html">Blog</a></div>
<div><a href="../documentation.html">Documentation</a></div>
<div><a href="../source.html">Source</a></div>
<div><a href="../key.html">Key</a></div>
<div><a href="../changelog.html">Changelog</a></div>
</div>
<body>
<h1>Blog - #1</h1>
<h2>systemd Insecurity</h2>
<p class="update_date">Posted: 2022-01-29 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-11-14 (UTC+00:00)</p>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc">Table of Contents<a/></h2>
<ul>
<li><a href="#issue0">Issue #0 - Against CVE Assignment</a></li>
<li><a href="#issue1">Issue #1 - CVEs Are Not Useful</a></li>
<li><a href="#issue2">Issue #2 - Security is a Circus</a></li>
<li><a href="#issue3">Issue #3 - Blaming the User</a></li>
</ul>
</section>
<p>Anyone who cares about security may want to switch from systemd as soon as possible; its lead
developer doesn't care about your security at all.</p>
<section id="issue0">
<h2 id="issue0"><a href="#issue0">Issue #0 - Against CVE Assignment</a></h2>
<br>
<blockquote>"You don't assign CVEs to every single random bugfix we do, do you?"</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<p>My thoughts:<br>
Yes, if they're security-related.</p>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/pull/5998#issuecomment-303782334">systemd GitHub Issue 5998</a></p>
</section>
<section id="issue1">
<h2 id="issue1"><a href="#issue1">Issue #1 - CVEs Are Not Useful</a></h2>
<blockquote>"Humpf, I am not convinced this is the right way to announce this. We never did that, and half the
CVEs aren't useful anyway, hence I am not sure we should start with that now, because it is either
inherently incomplete or blesses the nonsensical part of the CVE circus which we really shouldn't
bless..."</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<p>My thoughts:<br>
CVEs are supposed to be for security, and a log of when they were found and their severity, so yes,
it *is* the correct way to announce it. It seems as if over 95 security-concious people think the
same.</p>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/pull/6225#issuecomment-311739869">systemd GitHub Issue 6225</a></p>
</section>
<section id="issue2">
<h2 id="issue2"><a href="#issue2">Issue #2 - Security is a Circus</a></h2>
<blockquote>"I am not sure I buy enough into the security circus to do that though for any minor
issue..."</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/issues/5144#issuecomment-276740654">systemd GitHub Issue 5144</a></p>
</section>
<section id="issue3">
<h2 id="issue3"><a href="#issue3">Issue #3 - Blaming the User</a></h2>
<blockquote>"Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create
it in the first place. Note that not permitting numeric first characters is done on purpose: to
avoid ambiguities between numeric UID and textual user names.
<br>
systemd will validate all configuration data you drop at it, making it hard to generate invalid
configuration. Hence, yes, it's a feature that we don't permit invalid user names, and I'd consider
it a limitation of xinetd that it doesn't refuse an invalid username.<br>
<br>
So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but
still: the username is clearly not valid."</blockquote>
<p>- Lennart Poettering, systemd lead developer</p>
<p>My thoughts:<br>
systemd was the thing that allowed root access just because a username started with a number, then
Poettering blamed the user.</p>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/issues/6237#issuecomment-311900864">systemd GitHub Issue 6237</a></p>
</section>
</body>
</html>

99
blog/the_chromium_monopoly.html Normal file
View File

@ -0,0 +1,99 @@
<!DOCTYPE html>
<!-- Inferencium - Website - Blog - #3 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 5.0.0-alpha.1+24 -->
<html>
<head>
<title>Inferencium - Blog - The Chromium Monopoly</title>
<link rel="stylesheet" href="../main.css">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<!-- Navigation bar -->
<div class="sidebar">
<a href="../index.html"><img src="../asset/img/logo-inferencium-no_text.png" width="110px" height="110px"></a>
<a href="../index.html" class="title">Inferencium</a><br>
<br>
<br>
<div><a href="../about.html">About</a></div>
<div><a href="../contact.html">Contact</a></div>
<div><a href="../blog.html">Blog</a></div>
<div><a href="../documentation.html">Documentation</a></div>
<div><a href="../source.html">Source</a></div>
<div><a href="../key.html">Key</a></div>
<div><a href="../changelog.html">Changelog</a></div>
</div>
<body>
<h1>Blog - #3</h1>
<h2>The Chromium Monopoly</h2>
<p class="update_date">Posted: 2022-12-20 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-12-20 (UTC+00:00)</p>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc">Table of Contents<a/></h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#solution">Solution</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
</section>
<section id="introduction">
<h2 id="introduction"><a href="#introduction">Introduction</a></h2>
<p>It's no secret that I'm an advocate of Chromium and will use it for the foreseeable future. It is
a highly secure web browser which provides strong protection against malicious wesbites and the code
they run, and, while I am not too interested in high performance, it is a very performant web
browser, despite its security features.</p>
<p>However, the intention of this blog post is not to promote Chromium for any reason, but rather show
an issue with it; an issue which is larger than may be realised by web-surfing users. That issue is
the large monopoly Chromium has in the web browser market;
<a href="https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_tables">Chromium's market share is around 65%</a>,
making it the largest slice of the cake. The issue becomes even deeper and more problematic when you
realise that the second-place web browser, Safari, has only an 18% market share.</p>
<p>The main issue with this type of monopoly is the large amounts of power and influence it gives
Chromium, which can lead to, and is leading to, excessive authority of how the web should work, and
the standards which are implemented, which all other web browsers must comply with in order to have
a fully working web.</p>
</section>
<section id="solution">
<h2 id="solution"><a href="#solution">Solution</a></h2>
<p>In order to combat the Chromium monopoly, users typically go over to Chromium's classical rival,
Firefox. However, Firefox is dying and has lost almost all of its userbase over the last 2-3 years;
the reason for this is a tale of selfishness and greed, caused by Firefox's parent company to go off
course and lose its original goal of providing a freedom-respecting, open web. Mozilla caused
self-inflicted damage which it cannot recover from, and, to me, is already dead. The vultures are
simply waiting for the final, small group of users to abandon the project before Firefox finally
succumbs to its own demise; the demise it caused itself.</p>
<p>If attempting to increase Firefox's market share to previous levels will be in vain, what is the
solution? How can we prevent Chromium from completely taking over the web and dictating everything
we do and how the web should be designed and used?</p>
<p>To find the answer to these important but difficult questions, we must go to the alternatives which
still have a fighting chance. Safari, developed by Apple, is based on WebKit, an engine completely
independent of Chromium and Firefox.</p>
<p>Just using a non-Chromium-based web browser is not enough; the choice must already have enough
market share to still be relevant, and be capable of gaining new users. Safari, being preinstalled
on Apple devices including iPhone and Mac, already has a great advantage over Firefox. Apple
devices, especially iPhone, is abundant in streets everywhere on the planet. Safari is the default
choice for Apple users and has a large market share simply because of how widespread it is.
Exploiting this fact is the only way to gain more market share and take down Chromium before it is
too late; the clock is ticking, and Apple are the only ones preventing Chromium from completely
taking over the web. Backing Safari instead of Firefox will keep the WebKit market share from
falling to a critically low percentage, making it impossible to make a comeback, as has happened to
Firefox. Sometimes, directly supporting a political party is not the way to get them into power,
supporting the second-place alternative is, in order to keep the one you don't want out of power,
giving the party you do want in power an advantage. To win this war against the Chromium monopoly,
we must be tactical, not emotional.</p>
</section>
<section id="conclusion">
<h2 id="conclusion"><a href="#conclusion">Conclusion</a></h2>
<p>Supporting Safari is the first step in supporting WebKit and promoting usage of the independent
web engine. Buying time while supporting and contributing to WebKit browser projects is the best and
only chance anyone has at competing with Chromium, and preventing it from increasing its dominance
to unstoppable levels, at which point there will be no return.</p>
</section>
</body>
</html>

142
blog/untrusted_the_issue_with_decentralisation.html Normal file
View File

@ -0,0 +1,142 @@
<!DOCTYPE html>
<!-- Inferencium - Website -- Blog - #2 -->
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 5.0.0-alpha.1+27 -->
<html>
<head>
<title>Inferencium - Blog - Untrusted: The Issue with Decentralisation</title>
<link rel="stylesheet" href="../main.css">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<!-- Navigation bar -->
<div class="sidebar">
<a href="../index.html"><img src="../asset/img/logo-inferencium-no_text.png" width="110px" height="110px"></a>
<a href="../index.html" class="title">Inferencium</a><br>
<br>
<br>
<div><a href="../about.html">About</a></div>
<div><a href="../contact.html">Contact</a></div>
<div><a href="../blog.html">Blog</a></div>
<div><a href="../documentation.html">Documentation</a></div>
<div><a href="../source.html">Source</a></div>
<div><a href="../key.html">Key</a></div>
<div><a href="../changelog.html">Changelog</a></div>
</div>
<body>
<h1>Blog - #2</h1>
<h2>Untrusted: The Issue with Decentralisation</h2>
<p class="update_date">Posted: 2022-06-30 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc">Table of Contents<a/></h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#examples">Examples</a></li>
<ul>
<li><a href="#examples-messaging">Messaging</a></li>
</ul>
<li><a href="#solution">Solution</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
</section>
<section id="introduction">
<h2 id="introduction"><a href="#introduction">Introduction</a></h2>
<p>A recent trend is seeing people move towards decentralised services and platforms. While this is
reasonable and I can understand why they are doing such a thing, they are seemingly doing it without
thinking about the possible consequences of doing so. The issue with decentralisation is trust;
there is no way to pin a key to a specific person, to ensure that you are communicating with the
same person you are supposed to be communicating with. In this article, I will discuss some of the
security issues with the decentralised model.</p>
</section>
<section id="examples">
<h2 id="examples"><a href="#examples">Examples</a></h2>
<section id="examples-messaging">
<h3 id="examples-messaging"><a href="#examples-messaging">Messaging</a></h3>
<p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook,
the keys are pinned to that user account, using the user's password as the method of identification.
This approach makes it impossible to log in as a specific user without their password, should it be
strong enough to not be guessed, whether via personal guessing or exhaustive search. The trust in
this centralised model is the high security these platforms have. It is extremely unlikely that
anyone other than a government would be able to access the accounts stored on such platforms'
servers, which makes the physical security trusted. As for remote security, should a user's password
be compromised, it can typically be reset if the user can prove they are the owner of the account
via some form of identification; this is where the trust issue of decentralisation occurs.</p>
<p>In the decentralised model, keys are kept on the users' devices, in their possession. While this
soveriegnty is welcomed, it introduces a critical flaw in the security of communicating with anyone
via a decentralised platform; should a user's device be lost, stolen, or otherwise compromised,
there is no way to know it happened and what the new keys really are, and if the same user generated
those keys. There is no centralised point where anyone can go to check if the compromised user has
updated their keys, which means there must already have been at least one other secure channel in
place before the compromise occurred. Even if there was, the security of endpoint devices,
especially typical users, is much lower than a well protected corporation's servers, making even
those secure channels questionable to trust. Should all secure channels be compromised, there is
literally no way to know if the person you are communicating with is the real person or an imposter;
there is no root of trust. This point is fatal; game over. The only way to establish trust again
would be to physically meet and exchange keys.</p>
</section>
</section>
<section id="solution">
<h2 id="solution"><a href="#solution">Solution</a></h2>
<p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation
is to design your threat model and think about your reasoning for avoiding centralised platforms. Is
it lack of trust of a specific company? Is it the possibility of centralised platforms going
offline? Only by thinking logically and tactically can you solve both the issue of centralisation
and decentralisation. Often, one size fits all is never the correct approach, nor does it typically
work.</p>
<p>In order to avoid the issue of loss of trust due to lack of root of trust, all users' keys must
be stored in a centralised location where all contacts are able to go to in case of compromise or to
periodically check the state of keys and to see if they have changed. This centralised location
requires some sort of identification to ensure that the user changing their keys is really the same
person who initially signed up for the platform, using a trust-on-first-use (TOFU) model, which
isn't much different than what today's centralised platforms are already doing; the only difference
is who is controlling the location; trust is still present and required.</p>
<p>In order to have a root of trust, I have posted my keys to my website, which is protected by
multiple layers of security:<br>
<br>
<ol>
<li>I have provided identification to my domain name registrar, to ensure I can access the website I
rightfully own, should it be compromised, by providing identification to the domain name
registrar.</li>
<li>I have provided identification to my virtual private server host, to ensure I can access the
virtual private servers I rightfully rent, should they be compromised, by providing identification
to the virtual private server host.</li>
<li>I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a
trusted party to manage TLS certificates and ensure ownership of the domain when connecting to
it.</li>
<li>I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you
believe you're connecting to it when you're actually connecting to someone else's.</li>
</ol></p>
<p>While not the most secure implementation of a root of trust, it is the most secure implementation
currently available to me. While the domain name registrar or virtual private server host could
tamper with my domain and data, they are the most trustworthy parties available. In its current
form, decentralisation would make this impossible to implement in any form.</p>
</section>
<section id="conclusion">
<h2 id="conclusion"><a href="#conclusion">Conclusion</a></h2>
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it
impossible to have a root of trust, and is typically never necessary. It is possible for someone
else to hold your keys, without them taking control of them and dictating what you can and cannot do
(Twitter's misinformation policy comes to mind). If a platform is not listening to your or other
people's concerns about how it is being run, show those platforms that you will not stand for it,
and move to a different one. This may not be ideal, but it's not different to moving from one
decentralised platform to another. Centralisation is not what is evil, the people in control of the
platforms are what is potentially evil. Carefully, logically, and tactically, choose who to trust.
Decentralisation doesn't do much for trust when you must still trust the operator of the
decentralised platform, and are still subject to the possibly draconian policies of that
decentralised platform. If government is what you are trying to avoid, there is no denying it is
feasibly impossible to avoid it; a government could always take down the decentralised platform,
forcing you to move to another, and they could also take down the centralised key storage site
mentioned earlier in this article. A government is not something you can so easily avoid.
Decentralisation does not solve the government issue. In order to live a happy, fun, and fulfilled
life, while protecting yourself against logical threats, there are only two words you must live by:
Threat model.</p>
</section>
</body>
</html>