Inferencium/website
1
0
Fork 0
Code Issues Activity

Website redesign finalisation.

Browse Source
This commit is contained in:
inference 2022-10-29 03:26:53 +01:00
parent ae0600a5df
commit 615a5244be
12 changed files with 309 additions and 228 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
about.html
View File

@ -16,6 +16,7 @@
<body>
<h1>About</h1>
<br>
<h3>About Me</h3>
<p>I am Inference, a cybersecurity researcher based in United Kingdom.<br>
<br>
<p>I write about my research and experience in cybersecurity and also physical
@ -25,9 +26,10 @@ about other aspects of my life.</p>
<p>I am an open source advocate for the preservation and modifiability of
source code. I believe source code should be considered human knowledge as
much as past knowledge and teachings were; it is how modern humanity
survives and runs. Source code being modifiable allows it to be adapted
for use by anyone, whether to add features, harden it, or provide
accessibility for disabled people.<br>
survives and runs.<br>
Source code being modifiable allows it to be adapted
for use by anyone, whether to add features, harden it for increased security
and/or privacy, or provide accessibility for disabled users.<br>
I am also a modular design advocate for the ability to securely and
robustly make changes to hardware and software without the entire system
being affected.</p>

23
blog.html
View File

@ -4,22 +4,29 @@
<title>Inferencium Network - Blog</title>
<link rel="stylesheet" href="infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="source.html">Source</a></div>
</div>
<body>
<h1>Blog</h1>
<br>
<h2>2022-06-30</h2>
<p>#2 - <a href="blog/untrusted-the-issue-with-decentralisation.html">Untrusted: The Issue with Decentralisation</a></p>
<h3>2022-06-30</h3>
<p>#2 - <a class="body-link" href="blog/untrusted-the-issue-with-decentralisation.html">Untrusted: The Issue with Decentralisation</a></p>
<br>
<br>
<h2>2022-01-29</h2>
<p>#1 - <a href="blog/systemd-insecurity.html">systemd Insecurity</a></p>
<h3>2022-01-29</h3>
<p>#1 - <a class="body-link" href="blog/systemd-insecurity.html">systemd Insecurity</a></p>
<br>
<br>
<h2>2022-01-27</h2>
<p>#0 - <a href="blog/foss-is-working-against-itself.html">FOSS is Working Against Itself</a></p>
<h3>2022-01-27</h3>
<p>#0 - <a class="body-link" href="blog/foss-is-working-against-itself.html">FOSS is Working Against Itself</a></p>
<br>
<br>
<br>
<a href="index.html">Back</a>
</body>
</html>

162
blog/foss-is-working-against-itself.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Blog - FOSS is Working Against Itself</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Blog - #0</h1>
<br>
@ -12,104 +21,107 @@
<h3>2022-01-27 (UTC+00:00)</h3>
<br>
<h4>Introduction</h4>
<p>The world has become a dangerous, privacy invading, human rights stripping,<br>
totalitarian place; in order to combat this, people are joining a growing,<br>
and dangerous, trend, which I will refer to in this post as the "FOSS<br>
movement".<br>
With that stated, I will now debunk the misinformation being spread inside<br>
<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 "FOSS
movement".
With that stated, I will now debunk the misinformation being spread inside
of this extremely flawed movement.</p>
<br>
<p>The FOSS movement is an attempt to regain privacy and control over our<br>
devices and data, but the entire concept of FOSS-only, at the current time,<br>
is severely, and dangerously, flawed. What the FOSS community does not seem<br>
to understand is the fact that most FOSS software cares not about security.<br>
"Security"; keep that word in mind as you progress through this article.<br>
What is security? Security is being safe and secure from adversaries and<br>
unwanted consequences; security protects our rights and allows us to<br>
protect ourselves. Without security, we have no protection, and without<br>
protection, we have a lack of certainty of everything else, including<br>
<p>The FOSS movement is an attempt to regain privacy and control 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 security.
"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>
<br>
<p>FOSS projects rarely take security into account; they simply look at the<br>
surface level, rather than the actual root cause of the issues they are<br>
attempting to fight against. In this case, the focus is on privacy and<br>
control. Without security mechanisms to protect the privacy features and<br>
the ability to control your devices and data, it can be stripped away as<br>
if it never existed in the first place, which, inevitably, leads us back to<br>
the beginning, and the cycle repeats. With this ideology, privacy and<br>
control will *never* be achieved. There is no foundation to build privacy<br>
or control upon. It is impossible to build a solid, freedom respecting<br>
<p>FOSS projects rarely take security into account; they simply look at the
surface level, rather than the actual root cause 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 ideology, 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>
<br>
<h4>Example: Smartphones</h4>
<p>A FOSS phone, especially so-called "Linux phones" are completely<br>
detrimental to privacy and control, because they do not have the security<br>
necessary to enforce that privacy. Unlocked bootloaders prevent the device<br>
from verifying the integrity of the boot chain, including the OS, meaning<br>
any big tech or government entity can simply inject malicious code into<br>
your software and you wouldn't have any idea it was there. If that's not<br>
enough of a backdoor for you to reconsider your position, how about the<br>
trivial evil maid and data extraction attacks which could be executed on<br>
your device, whether with coercion or not? With Android phones, this is<br>
bad enough to completely break the privacy and control the FOSS movement<br>
seeks, but "Linux phones" take it a step further by implementing barely any<br>
security, if any at all. Privilege escalation is trivial to achieve on any<br>
Linux system, which is the reason Linux hardening strategies often include<br>
restricting access to the root account; if you root your Android phone, or<br>
use a "Linux phone", you've already destroyed the security model, and thus<br>
privacy and control model you were attempting to achieve. Not only are<br>
these side effects of FOSS, so is the absolutely illogical restriction of<br>
not being able to, or making it unnecessarily difficult to, install and<br>
update critical components of the system, such as proprietary firmware,<br>
which just so happens to be almost all of them. "Linux phones" are not as<br>
<p>A FOSS phone, especially so-called "Linux phones" are completely
detrimental to privacy and control, because they do not have the security
necessary to enforce that privacy. Unlocked bootloaders prevent the device
from verifying the integrity of the boot chain, including the OS, meaning
any 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 evil maid and data extraction attacks which could be executed on
your device, whether with coercion or not? 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. Privilege escalation is trivial to achieve on any
Linux system, which is the reason Linux hardening strategies often include
restricting access to the root account; if you root your Android phone, 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 firmware,
which just so happens to be almost all of them. "Linux phones" are not as
free as they proclaim to be.</p>
<br>
<p>You may ask "What's so bad about using LineageOS?", to which I answer with<br>
<p>You may ask "What's so bad about using LineageOS?", to which I answer with
"What's not bad about it?".<br>
<br>
- LineageOS uses debug builds, not safe and secure release builds.<br>
- LineageOS requires an unlocked bootloader.<br>
- LineageOS does not install critically important firmware without manual<br>
flashing.<br>
- LineageOS does not implement rollback protection, meaning any adversary,<br>
including a goverment entity, can simply downgrade the OS to a previous<br>
version in order to exploit known security vulnerabilities.<br>
- 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.<br>
- 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.<br>
- LineageOS does not implement rollback protection, meaning any adversary,
from a stranger who picks up the device, to a goverment entity remotely, can
simply downgrade the OS to a previous version in order to exploit known
security vulnerabilities.<br>
<br>
LineageOS is not the only Android OS (commonly, and incorrectly, referred<br>
to as a "ROM") with such issues, but it is one of the worst. The only<br>
things such insecure OSes can provide you are customisation abilities, and<br>
a backdoor to your data. They are best suited as a development OS, not a<br>
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>
<br>
<h4>Solution</h4>
<p>What can you do about this? The answer is simple; however, it does require<br>
you to use logic, fact, and evidence, not emotion, which is a difficult<br>
pill for most people to swallow. Use your adversaries' weapons against<br>
them. The only way to effectively combat the privacy invasion and lack of<br>
control of our devices and data is to become a renegade and not take sides.<br>
Yes, that means not taking sides with the closed source, proprietary, big<br>
tech and government entities, but it also means not taking sides with any<br>
FOSS entities. The only way to win this war is to take *whatever* hardware<br>
<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 renegade 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>
<br>
<p>The only solution for phone security, privacy, and control, is to use<br>
a Google Pixel (currently, 4 series or newer) running GrapheneOS. Google<br>
Pixel phones allow you complete bootloader freedom, including the ability<br>
to lock the bootloader after flashing a custom OS (GrapheneOS includes a<br>
custom OS signing key to allow locking the bootloader and enabling verified<br>
boot to prevent malware persistence, evil maid attacks, and boot chain<br>
corruption), long device support lifecycles (minimum 3 years for Pixel 3a<br>
series to Pixel 5a, minimum 5 years for Pixel 6 series), and fast,<br>
guaranteed security updates for the entire support timeframe of the<br>
<p>The only solution for phone security, privacy, and control, is to use
a Google Pixel (currently, Pixel 4-series or newer) running GrapheneOS. Google
Pixel phones allow you complete bootloader freedom, including the ability
to lock the bootloader after flashing a custom OS (GrapheneOS includes a
custom OS signing key to allow locking the bootloader and enabling verified
boot to prevent malware persistence, evil maid attacks, and boot chain
corruption), long device support lifecycles (minimum 3 years for Pixel 3a
series to Pixel 5a, minimum 5 years for Pixel 6 series), and fast,
guaranteed security updates for the entire support timeframe of the
devices.</p>
<br>
<h4>Conclusion</h4>
<p>Use what you can, and do what you can. By neglecting security, you are,<br>
even if unintentionally, neglecting exactly what you are trying to gain;<br>
<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>
<br>
<br>
<br>
<a href="../blog.html">Back</a>
</body>
</html>

64
blog/systemd-insecurity.html
View File

@ -4,79 +4,85 @@
<title>Inferencium Network - Blog - systemd Insecurity</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Blog - #1</h1>
<br>
<h2>systemd Insecurity</h2>
<br>
<h3>2022-01-29 (UTC+00:00)</h3>
<p>Posted: 2022-01-29 (UTC+00:00)</p>
<p>Updated: 2022-10-29 (UTC+00:00)</p>
<br>
<p>Anyone who cares about security may want to switch from systemd as soon as<br>
possible; its lead developer doesn't care about your security at all, and<br>
makes the thing seem like an intentional government backdoor if I've ever<br>
seen one.</p>
<br>
<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>
<br>
<p>Poettering:<br>
"You don't assign CVEs to every single random bugfix we do, do you?"</p>
<br>
<p>My thoughts:<br>
Uhh... Yes, if they're security related.</p>
Yes, if they're security related.</p>
<br>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/pull/5998">https://github.com/systemd/systemd/pull/5998</a></p>
<a class="body-link" href="https://github.com/systemd/systemd/pull/5998">https://github.com/systemd/systemd/pull/5998</a></p>
<br>
<br>
<br>
<p>Poettering:<br>
"Humpf, I am not convinced this is the right way to announce this.<br>
We never did that, and half the CVEs aren't useful anyway, hence I am not<br>
sure we should start with that now, because it is either inherently<br>
incomplete or blesses the nonsensical part of the CVE circus which we<br>
"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..."</p>
<br>
<p>My thoughts:<br>
CVEs are supposed to be for security, and a log of when they were<br>
found and their severity, so yes, it *is* the correct way to announce it.<br>
It seems as if over 95 security concious people think the same.</p>
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>
<br>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/pull/6225">https://github.com/systemd/systemd/pull/6225</a></p>
<a class="body-link" href="https://github.com/systemd/systemd/pull/6225">https://github.com/systemd/systemd/pull/6225</a></p>
<br>
<br>
<br>
<p>Poettering:<br>
"I am not sure I buy enough into the security circus to do that though for<br>
"I am not sure I buy enough into the security circus to do that though for
any minor issue..."</p>
<br>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/issues/5144">https://github.com/systemd/systemd/issues/5144</a></p>
<a class="body-link" href="https://github.com/systemd/systemd/issues/5144">https://github.com/systemd/systemd/issues/5144</a></p>
<br>
<br>
<br>
<p>Poettering:<br>
"Yes, as you found out "0day" is not a valid username. I wonder which tool<br>
permitted you to create it in the first place. Note that not permitting<br>
numeric first characters is done on purpose: to avoid ambiguities between<br>
"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>
<br>
systemd will validate all configuration data you drop at it, making it hard<br>
to generate invalid configuration. Hence, yes, it's a feature that we don't<br>
permit invalid user names, and I'd consider it a limitation of xinetd that<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<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."</p>
<br>
<p>My thoughts:<br>
systemd was the thing that allowed root access just because a username<br>
started with a number.</p>
systemd was the thing that allowed root access just because a username
started with a number, then Poettering blamed the user.</p>
<br>
<p>Source:<br>
<a href="https://github.com/systemd/systemd/issues/6237">https://github.com/systemd/systemd/issues/6237</a></p>
<a class="body-link" href="https://github.com/systemd/systemd/issues/6237">https://github.com/systemd/systemd/issues/6237</a></p>
<br>
<br>
<br>
<a href="../blog.html">Back</a>
</body>
</html>

181
blog/untrusted-the-issue-with-decentralisation.html
View File

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

2
contact.html
View File

@ -40,6 +40,8 @@ need to use these services, use a preferred method instead.</p>
<p><img class="logo" src="contact/briar.png" width="30px" height="30px"/> <a class="body-link" href="contact/briar.html">Briar</a></p>
<p><img class="logo" src="contact/session.png" width="30px" height="30px"/> <a class="body-link" href="contact/session.html">Session</a></p>
<br>
<br>
<br>
<h2>Non-private Methods</h2>
<p>The following contact methods do not utilise end-to-end encryption,
or I do not use such functionality; they are suitable for public contact

11
contact/briar.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Contact - Briar</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Contact</h1>
<br>
@ -18,7 +27,5 @@ Unavailable
</pre>
<br>
<br>
<br>
<a href="../contact.html">Back</a>
</body>
</html>

11
contact/session.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Contact - Session</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Contact</h1>
<br>
@ -18,7 +27,5 @@
</pre>
<br>
<br>
<br>
<a href="../contact.html">Back</a>
</body>
</html>

11
contact/signal.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Contact - Signal</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Contact</h1>
<br>
@ -18,7 +27,5 @@
</pre>
<br>
<br>
<br>
<a href="../contact.html">Back</a>
</body>
</html>

11
contact/threema.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Contact - Threema</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Contact</h1>
<br>
@ -16,7 +25,5 @@
<img src="key-threema.png">
<br>
<br>
<br>
<a href="../contact.html">Back</a>
</body>
</html>

18
contact/xmpp.html
View File

@ -4,6 +4,15 @@
<title>Inferencium Network - Contact - XMPP</title>
<link rel="stylesheet" href="../infnet.css">
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="../source.html">Source</a></div>
</div>
<body>
<h1>Contact</h1>
<br>
@ -11,8 +20,8 @@
<br>
<p>Updated: 2022-10-13 (UTC+00:00)</p>
<br>
<p>Whenever possible, open the links to pin the fingerprint directly from<br>
this webpage. If that is not possible, manually verify the fingerprints.</p>
<p>Whenever possible, open the links to pin the fingerprint directly from this
webpage. If that is not possible, manually verify the fingerprints.</p>
<br>
<h3>inference@inferencium.net</h3>
<h4>Key</h4>
@ -22,7 +31,7 @@ this webpage. If that is not possible, manually verify the fingerprints.</p>
1bd03c6a 5e011655 2fafd697 da4fce70 63de5a83 a264a34a fcce78fe 6b06820c
</code>
</pre>
<a href="xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c">xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c</a>
<a class="body-link" href="xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c">xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c</a>
<br>
<br>
<h5>Desktop</h5>
@ -41,10 +50,9 @@ this webpage. If that is not possible, manually verify the fingerprints.</p>
9f9b50e4 3bb5ae5d 886213ad 43015719 7c40aa99 e436445d e0e360a9 24076015
</code>
</pre>
<a href="xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015">xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015</a>
<a class="body-link" href="xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015">xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015</a>
<br>
<br>
<br>
<a href="../contact.html">Back</a>
</body>
</html>

35
source.html
View File

@ -4,26 +4,35 @@
<title>Inferencium Network - Source</title>
<link rel="stylesheet" href=infnet.css>
</head>
<div class="sidebar">
<a class="title">Inferencium Network</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="source.html">Source</a></div>
</div>
<body>
<h1>Source</h1>
<br>
<p>Inferencium Network Git repository.</p>
<p>- <a href="https://codeberg.org/inference/">Git repository</a></p>
<h3>My Personal Source Code Repositories</h3>
<p>These repositories contain source code which is used on my personal
systems.<br>
No guarantees are made that they will work correctly on your systems, and are
not targeted towards a public release.<br>
Usage of these repositories is at your own risk.</p>
<br>
<p>Inferencium Network website source code.</p>
<p>- <a href="https://codeberg.org/inference/infnet-www/">Website</a></p>
<p>- <a class="body-link" href="https://git.inferencium.net/inference/cfg/">Configuration files</a></p>
<p>- <a class="body-link" href="https://git.inferencium.net/inference/scr/">Script files</a></p>
<br>
<p>My personal configuration files.</p>
<p>- <a href="https://codeberg.org/inference/cfg/">Configuration files</a></p>
<h3>Inferencium Network Source Code Repositories</h3>
<p>These repositories contain source code targeted at a public release and are
suitable for a wide range of systems.</p>
<br>
<p>My personal script files.</p>
<p>- <a href="https://codeberg.org/inference/scr/">Scripts</a></p>
<br>
<p>Inferencium Network Gentoo overlay.</p>
<p>- <a href="https://codeberg.org/inference/inferencium/">Inferencium Gentoo overlay</a></p>
<p>- <a class="body-link" href="https://git.inferencium.net/inference/inf-www/">Website</a></p>
<p>- <a class="body-link" href="https://git.inferencium.net/inference/mmd/">Gentoo - Multimedia</a></p>
<br>
<br>
<br>
<a href="index.html">Back</a></p>
</body>
</html>