Inferencium/website
1
0
Fork 0
Code Issues Activity

Update blog #2 to version 3.2.0.13.

Browse Source
This commit is contained in:
inference 2023-03-14 05:55:59 +00:00
commit 63db90350b
Signed by: inference
SSH Key Fingerprint: SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
1 changed files with 135 additions and 100 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
blog/untrusted_the_issue_with_decentralisation.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2022-2023 Jake Winters --> <!-- Copyright 2022-2023 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause-Clear --> <!-- SPDX-License-Identifier: BSD-3-Clause-Clear -->
<!-- Version: 2.0.0.10 --> <!-- Version: 3.2.0.13 -->
<html> <html>
@ -33,13 +33,38 @@
<body> <body>
<h1>Blog - #2</h1> <h1>Blog - #2</h1>
<br> <br>
<br>
<br>
<h2>Untrusted: The Issue with Decentralisation</h2> <h2>Untrusted: The Issue with Decentralisation</h2>
<br> <br>
<p class="update_date">Posted: 2022-06-30 (UTC+00:00)</p> <p class="update_date">Posted: 2022-06-30 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p> <p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
<br> <br>
<h4>Introduction</h4> <!-- Table of contents. -->
<h2 id="toc"><a href="#toc" class="h2"
>Table of Contents<a/></h2>
<ul>
<li><a href="#introduction" class="body-link"
>Introduction</a></li>
<li><a href="#examples" class="body-link"
>Examples</a></li>
<ul>
<li><a href="#examples-messaging" class="body-link"
>Messaging</a></li>
</ul>
<li><a href="#solution" class="body-link"
>Solution</a></li>
<li><a href="#conclusion" class="body-link"
>Conclusion</a></li>
</ul>
<br>
<br>
<br>
<h2 id="introduction"><a href="#introduction" class="h2"
>Introduction</a></h2>
<p>A recent trend is seeing people move towards decentralised services and platforms. While this is <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 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; thinking about the possible consequences of doing so. The issue with decentralisation is trust;
@ -47,7 +72,12 @@ there is no way to pin a key to a specific person, to ensure that you are commun
same person you are supposed to be communicating with. In this article, I will discuss some of 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> security issues with the decentralised model.</p>
<br> <br>
<h4>Example: Messaging</h4> <br>
<h2 id="examples"><a href="#examples" class="h2"
>Examples</a></h2>
<h3 id="examples-messaging"><a href="#examples-messaging" class="h3"
>Messaging</a></h3>
<p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook, <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. 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 This approach makes it impossible to log in as a specific user without their password, should it be
@ -71,7 +101,10 @@ literally no way to know if the person you are communicating with is the real pe
there is no root of trust. This point is fatal; game over. The only way to establish trust again 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> would be to physically meet and exchange keys.</p>
<br> <br>
<h4>Solution</h4> <br>
<h2 id="solution"><a href="#solution" class="h2"
>Solution</a></h2>
<p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation <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 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 it lack of trust of a specific company? Is it the possibility of centralised platforms going
@ -90,27 +123,29 @@ 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 <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> multiple layers of security:<br>
<br> <br>
0. I have provided identification to my domain name registrar, to ensure I can access the website I <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 rightfully own, should it be compromised, by providing identification to the domain name
registrar.<br> registrar.</li>
<br> <li>I have provided identification to my virtual private server host, to ensure I can access the
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 virtual private servers I rightfully rent, should they be compromised, by providing identification
to the virtual private server host.<br> to the virtual private server host.</li>
<br> <li>I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a
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 trusted party to manage TLS certificates and ensure ownership of the domain when connecting to
it.<br> 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>
<br> <br>
3. I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you <p>While not the most secure implementation of a root of trust, it is the most secure implementation
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 most secure implementation
currently available to me. While the domain name registrar or virtual private server host could 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 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> form, decentralisation would make this impossible to implement in any form.</p>
<br> <br>
<h4>Conclusion</h4> <br>
<h2 id="conclusion"><a href="#conclusion" class="h2"
>Conclusion</a></h2>
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it <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 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 else to hold your keys, without them taking control of them and dictating what you can and cannot do