Inferencium/website
1
0
Fork 0
Code Issues Activity

Update webpage "Blog - #2" from version 5.0.0-beta.1+28 to 5.0.1-beta.1

Browse Source
This commit is contained in:
inference 2023-11-11 12:04:51 +00:00
parent b4e4ead496
commit 0b5581cead
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
1 changed files with 120 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

216
blog/untrusted_the_issue_with_decentralisation.html
View File

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