diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html
index 1252fe2..8937d14 100644
--- a/blog/untrusted-the-issue-with-decentralisation.html
+++ b/blog/untrusted-the-issue-with-decentralisation.html
@@ -37,7 +37,7 @@ 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.
In the decentralised model, keys are kept on the users' devices, in their
possession. While this soveriegnty is welcomed, it indroduces 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,
@@ -63,7 +63,7 @@ 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.
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
@@ -73,7 +73,7 @@ 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.
In order to have a root of trust, I have posted my keys to my website,
which is protected by multiple layers of security:
1. I have provided identification to my domain name registrar, to ensure I
@@ -98,29 +98,31 @@ 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.
+implement in any form.
Do not demand anonymity; demand privacy and control of your own data.
-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 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 isn't 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.