Add table of contents. Indent code to match coding style.
This commit is contained in:
parent
73e07b7258
commit
9ef8c5a8b4
@ -5,7 +5,7 @@
|
||||
<!-- Copyright 2022-2023 Jake Winters -->
|
||||
<!-- SPDX-License-Identifier: BSD-3-Clause-Clear -->
|
||||
|
||||
<!-- Version: 3.0.0.11 -->
|
||||
<!-- Version: 3.1.0.12 -->
|
||||
|
||||
|
||||
<html>
|
||||
@ -42,7 +42,29 @@
|
||||
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
|
||||
<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
|
||||
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;
|
||||
@ -50,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
|
||||
security issues with the decentralised model.</p>
|
||||
<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,
|
||||
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
|
||||
@ -74,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
|
||||
would be to physically meet and exchange keys.</p>
|
||||
<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
|
||||
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
|
||||
@ -113,7 +143,10 @@ currently available to me. While the domain name registrar or virtual private se
|
||||
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>
|
||||
<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
|
||||
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
|
||||
|
Loading…
x
Reference in New Issue
Block a user