Inferencium/website
1
0
Fork 0
Code Issues Activity

Update Blog #2 webpage from version 4.1.1.24 to 4.2.0.25

Browse Source
This commit is contained in:
inference 2023-09-02 17:20:27 +01:00
parent 83bbe17284
commit a8d74aa348
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
blog/untrusted_the_issue_with_decentralisation.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 4.1.1.24 -->
<!-- Version: 4.2.0.25 -->
<html>
@ -34,19 +34,19 @@
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc" class="h2">Table of Contents<a/></h2>
<h2 id="toc"><a href="#toc">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>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#examples">Examples</a></li>
<ul>
<li><a href="#examples-messaging" class="body-link">Messaging</a></li>
<li><a href="#examples-messaging">Messaging</a></li>
</ul>
<li><a href="#solution" class="body-link">Solution</a></li>
<li><a href="#conclusion" class="body-link">Conclusion</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" class="h2">Introduction</a></h2>
<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;
@ -55,9 +55,9 @@
security issues with the decentralised model.</p>
</section>
<section id="examples">
<h2 id="examples"><a href="#examples" class="h2">Examples</a></h2>
<h2 id="examples"><a href="#examples">Examples</a></h2>
<section id="examples-messaging">
<h3 id="examples-messaging"><a href="#examples-messaging" class="h3">Messaging</a></h3>
<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
@ -82,7 +82,7 @@
</section>
</section>
<section id="solution">
<h2 id="solution"><a href="#solution" class="h2">Solution</a></h2>
<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
@ -118,7 +118,7 @@
form, decentralisation would make this impossible to implement in any form.</p>
</section>
<section id="conclusion">
<h2 id="conclusion"><a href="#conclusion" class="h2">Conclusion</a></h2>
<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