diff --git a/about.html b/about.html index 2086c0f..5e2be8a 100644 --- a/about.html +++ b/about.html @@ -16,6 +16,7 @@

About


+

About Me

I am Inference, a cybersecurity researcher based in United Kingdom.

I write about my research and experience in cybersecurity and also physical @@ -25,9 +26,10 @@ about other aspects of my life.

I am an open source advocate for the preservation and modifiability of source code. I believe source code should be considered human knowledge as much as past knowledge and teachings were; it is how modern humanity -survives and runs. Source code being modifiable allows it to be adapted -for use by anyone, whether to add features, harden it, or provide -accessibility for disabled people.
+survives and runs.
+Source code being modifiable allows it to be adapted +for use by anyone, whether to add features, harden it for increased security +and/or privacy, or provide accessibility for disabled users.
I am also a modular design advocate for the ability to securely and robustly make changes to hardware and software without the entire system being affected.

diff --git a/blog.html b/blog.html index 9238b3d..c89e06c 100644 --- a/blog.html +++ b/blog.html @@ -4,22 +4,29 @@ Inferencium Network - Blog +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Blog


-

2022-06-30

-

#2 - Untrusted: The Issue with Decentralisation

+

2022-06-30

+

#2 - Untrusted: The Issue with Decentralisation



-

2022-01-29

-

#1 - systemd Insecurity

+

2022-01-29

+

#1 - systemd Insecurity



-

2022-01-27

-

#0 - FOSS is Working Against Itself

+

2022-01-27

+

#0 - FOSS is Working Against Itself



-
-Back diff --git a/blog/foss-is-working-against-itself.html b/blog/foss-is-working-against-itself.html index 28826c8..e0abc7c 100644 --- a/blog/foss-is-working-against-itself.html +++ b/blog/foss-is-working-against-itself.html @@ -4,6 +4,15 @@ Inferencium Network - Blog - FOSS is Working Against Itself +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Blog - #0


@@ -12,104 +21,107 @@

2022-01-27 (UTC+00:00)


Introduction

-

The world has become a dangerous, privacy invading, human rights stripping,
-totalitarian place; in order to combat this, people are joining a growing,
-and dangerous, trend, which I will refer to in this post as the "FOSS
-movement".
-With that stated, I will now debunk the misinformation being spread inside
+

The world has become a dangerous, privacy invading, human rights stripping, +totalitarian place; in order to combat this, people are joining a growing, +and dangerous, trend, which I will refer to in this post as the "FOSS +movement". +With that stated, I will now debunk the misinformation being spread inside of this extremely flawed movement.


-

The FOSS movement is an attempt to regain privacy and control over our
-devices and data, but the entire concept of FOSS-only, at the current time,
-is severely, and dangerously, flawed. What the FOSS community does not seem
-to understand is the fact that most FOSS software cares not about security.
-"Security"; keep that word in mind as you progress through this article.
-What is security? Security is being safe and secure from adversaries and
-unwanted consequences; security protects our rights and allows us to
-protect ourselves. Without security, we have no protection, and without
-protection, we have a lack of certainty of everything else, including
+

The FOSS movement is an attempt to regain privacy and control over our +devices and data, but the entire concept of FOSS-only, at the current time, +is severely, and dangerously, flawed. What the FOSS community does not seem +to understand is the fact that most FOSS software cares not about security. +"Security"; keep that word in mind as you progress through this article. +What is security? Security is being safe and secure from adversaries and +unwanted consequences; security protects our rights and allows us to +protect ourselves. Without security, we have no protection, and without +protection, we have a lack of certainty of everything else, including privacy and control, which is what the FOSS movement is seeking.


-

FOSS projects rarely take security into account; they simply look at the
-surface level, rather than the actual root cause of the issues they are
-attempting to fight against. In this case, the focus is on privacy and
-control. Without security mechanisms to protect the privacy features and
-the ability to control your devices and data, it can be stripped away as
-if it never existed in the first place, which, inevitably, leads us back to
-the beginning, and the cycle repeats. With this ideology, privacy and
-control will *never* be achieved. There is no foundation to build privacy
-or control upon. It is impossible to build a solid, freedom respecting
+

FOSS projects rarely take security into account; they simply look at the +surface level, rather than the actual root cause of the issues they are +attempting to fight against. In this case, the focus is on privacy and +control. Without security mechanisms to protect the privacy features and +the ability to control your devices and data, it can be stripped away as +if it never existed in the first place, which, inevitably, leads us back to +the beginning, and the cycle repeats. With this ideology, privacy and +control will *never* be achieved. There is no foundation to build privacy +or control upon. It is impossible to build a solid, freedom respecting platform on this model.


Example: Smartphones

-

A FOSS phone, especially so-called "Linux phones" are completely
-detrimental to privacy and control, because they do not have the security
-necessary to enforce that privacy. Unlocked bootloaders prevent the device
-from verifying the integrity of the boot chain, including the OS, meaning
-any big tech or government entity can simply inject malicious code into
-your software and you wouldn't have any idea it was there. If that's not
-enough of a backdoor for you to reconsider your position, how about the
-trivial evil maid and data extraction attacks which could be executed on
-your device, whether with coercion or not? With Android phones, this is
-bad enough to completely break the privacy and control the FOSS movement
-seeks, but "Linux phones" take it a step further by implementing barely any
-security, if any at all. Privilege escalation is trivial to achieve on any
-Linux system, which is the reason Linux hardening strategies often include
-restricting access to the root account; if you root your Android phone, or
-use a "Linux phone", you've already destroyed the security model, and thus
-privacy and control model you were attempting to achieve. Not only are
-these side effects of FOSS, so is the absolutely illogical restriction of
-not being able to, or making it unnecessarily difficult to, install and
-update critical components of the system, such as proprietary firmware,
-which just so happens to be almost all of them. "Linux phones" are not as
+

A FOSS phone, especially so-called "Linux phones" are completely +detrimental to privacy and control, because they do not have the security +necessary to enforce that privacy. Unlocked bootloaders prevent the device +from verifying the integrity of the boot chain, including the OS, meaning +any big tech or government entity can simply inject malicious code into +your software and you wouldn't have any idea it was there. If that's not +enough of a backdoor for you to reconsider your position, how about the +trivial evil maid and data extraction attacks which could be executed on +your device, whether with coercion or not? With Android phones, this is +bad enough to completely break the privacy and control the FOSS movement +seeks, but "Linux phones" take it a step further by implementing barely any +security, if any at all. Privilege escalation is trivial to achieve on any +Linux system, which is the reason Linux hardening strategies often include +restricting access to the root account; if you root your Android phone, or +use a "Linux phone", you've already destroyed the security model, and thus +privacy and control model you were attempting to achieve. Not only are +these side effects of FOSS, so is the absolutely illogical restriction of +not being able to, or making it unnecessarily difficult to, install and +update critical components of the system, such as proprietary firmware, +which just so happens to be almost all of them. "Linux phones" are not as free as they proclaim to be.


-

You may ask "What's so bad about using LineageOS?", to which I answer with
+

You may ask "What's so bad about using LineageOS?", to which I answer with "What's not bad about it?".

- LineageOS uses debug builds, not safe and secure release builds.
-- LineageOS requires an unlocked bootloader.
-- LineageOS does not install critically important firmware without manual
-flashing.
-- LineageOS does not implement rollback protection, meaning any adversary,
-including a goverment entity, can simply downgrade the OS to a previous
-version in order to exploit known security vulnerabilities.
+- LineageOS requires an unlocked bootloader. Even when installed on devices +which support custom Android Verified Boot (AVB) keys, the bootloader cannot +be locked due to lack of the OS being signed.
+- LineageOS does not install critically important firmware without manual +flashing, requiring users to perform a second update to install this firmware; +this likely causes users to ignore the notification or miss firmware +updates.
+- LineageOS does not implement rollback protection, meaning any adversary, +from a stranger who picks up the device, to a goverment entity remotely, can +simply downgrade the OS to a previous version in order to exploit known +security vulnerabilities.

-LineageOS is not the only Android OS (commonly, and incorrectly, referred
-to as a "ROM") with such issues, but it is one of the worst. The only
-things such insecure OSes can provide you are customisation abilities, and
-a backdoor to your data. They are best suited as a development OS, not a
+LineageOS is not the only Android OS (commonly, and incorrectly, referred +to as a "ROM") with such issues, but it is one of the worst. The only +things such insecure OSes can provide you are customisation abilities, and +a backdoor to your data. They are best suited as a development OS, not a production OS.


Solution

-

What can you do about this? The answer is simple; however, it does require
-you to use logic, fact, and evidence, not emotion, which is a difficult
-pill for most people to swallow. Use your adversaries' weapons against
-them. The only way to effectively combat the privacy invasion and lack of
-control of our devices and data is to become a renegade and not take sides.
-Yes, that means not taking sides with the closed source, proprietary, big
-tech and government entities, but it also means not taking sides with any
-FOSS entities. The only way to win this war is to take *whatever* hardware
+

What can you do about this? The answer is simple; however, it does require +you to use logic, fact, and evidence, not emotion, which is a difficult +pill for most people to swallow. Use your adversaries' weapons against +them. The only way to effectively combat the privacy invasion and lack of +control of our devices and data is to become a renegade and not take sides. +Yes, that means not taking sides with the closed source, proprietary, big +tech and government entities, but it also means not taking sides with any +FOSS entities. The only way to win this war is to take *whatever* hardware and software you can, and use it tactically.


-

The only solution for phone security, privacy, and control, is to use
-a Google Pixel (currently, 4 series or newer) running GrapheneOS. Google
-Pixel phones allow you complete bootloader freedom, including the ability
-to lock the bootloader after flashing a custom OS (GrapheneOS includes a
-custom OS signing key to allow locking the bootloader and enabling verified
-boot to prevent malware persistence, evil maid attacks, and boot chain
-corruption), long device support lifecycles (minimum 3 years for Pixel 3a
-series to Pixel 5a, minimum 5 years for Pixel 6 series), and fast,
-guaranteed security updates for the entire support timeframe of the
+

The only solution for phone security, privacy, and control, is to use +a Google Pixel (currently, Pixel 4-series or newer) running GrapheneOS. Google +Pixel phones allow you complete bootloader freedom, including the ability +to lock the bootloader after flashing a custom OS (GrapheneOS includes a +custom OS signing key to allow locking the bootloader and enabling verified +boot to prevent malware persistence, evil maid attacks, and boot chain +corruption), long device support lifecycles (minimum 3 years for Pixel 3a +series to Pixel 5a, minimum 5 years for Pixel 6 series), and fast, +guaranteed security updates for the entire support timeframe of the devices.


Conclusion

-

Use what you can, and do what you can. By neglecting security, you are,
-even if unintentionally, neglecting exactly what you are trying to gain;
+

Use what you can, and do what you can. By neglecting security, you are, +even if unintentionally, neglecting exactly what you are trying to gain; privacy and control.



-
-Back diff --git a/blog/systemd-insecurity.html b/blog/systemd-insecurity.html index abea3e0..64660d0 100644 --- a/blog/systemd-insecurity.html +++ b/blog/systemd-insecurity.html @@ -4,79 +4,85 @@ Inferencium Network - Blog - systemd Insecurity +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Blog - #1


systemd Insecurity


-

2022-01-29 (UTC+00:00)

+

Posted: 2022-01-29 (UTC+00:00)

+

Updated: 2022-10-29 (UTC+00:00)


-

Anyone who cares about security may want to switch from systemd as soon as
-possible; its lead developer doesn't care about your security at all, and
-makes the thing seem like an intentional government backdoor if I've ever
-seen one.


+

Anyone who cares about security may want to switch from systemd as soon as +possible; its lead developer doesn't care about your security at all.


Poettering:
"You don't assign CVEs to every single random bugfix we do, do you?"


My thoughts:
-Uhh... Yes, if they're security related.

+Yes, if they're security related.


Source:
-https://github.com/systemd/systemd/pull/5998

+https://github.com/systemd/systemd/pull/5998




Poettering:
-"Humpf, I am not convinced this is the right way to announce this.
-We never did that, and half the CVEs aren't useful anyway, hence I am not
-sure we should start with that now, because it is either inherently
-incomplete or blesses the nonsensical part of the CVE circus which we
+"Humpf, I am not convinced this is the right way to announce this. +We never did that, and half the CVEs aren't useful anyway, hence I am not +sure we should start with that now, because it is either inherently +incomplete or blesses the nonsensical part of the CVE circus which we really shouldn't bless..."


My thoughts:
-CVEs are supposed to be for security, and a log of when they were
-found and their severity, so yes, it *is* the correct way to announce it.
-It seems as if over 95 security concious people think the same.

+CVEs are supposed to be for security, and a log of when they were +found and their severity, so yes, it *is* the correct way to announce it. +It seems as if over 95 security-concious people think the same.


Source:
-https://github.com/systemd/systemd/pull/6225

+https://github.com/systemd/systemd/pull/6225




Poettering:
-"I am not sure I buy enough into the security circus to do that though for
+"I am not sure I buy enough into the security circus to do that though for any minor issue..."


Source:
-https://github.com/systemd/systemd/issues/5144

+https://github.com/systemd/systemd/issues/5144




Poettering:
-"Yes, as you found out "0day" is not a valid username. I wonder which tool
-permitted you to create it in the first place. Note that not permitting
-numeric first characters is done on purpose: to avoid ambiguities between
+"Yes, as you found out "0day" is not a valid username. I wonder which tool +permitted you to create it in the first place. Note that not permitting +numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.

-systemd will validate all configuration data you drop at it, making it hard
-to generate invalid configuration. Hence, yes, it's a feature that we don't
-permit invalid user names, and I'd consider it a limitation of xinetd that
+systemd will validate all configuration data you drop at it, making it hard +to generate invalid configuration. Hence, yes, it's a feature that we don't +permit invalid user names, and I'd consider it a limitation of xinetd that it doesn't refuse an invalid username.

-So, yeah, I don't think there's anything to fix in systemd here. I
+So, yeah, I don't think there's anything to fix in systemd here. I< understand this is annoying, but still: the username is clearly not valid."


My thoughts:
-systemd was the thing that allowed root access just because a username
-started with a number.

+systemd was the thing that allowed root access just because a username +started with a number, then Poettering blamed the user.


Source:
-https://github.com/systemd/systemd/issues/6237

+https://github.com/systemd/systemd/issues/6237



-
-Back diff --git a/blog/untrusted-the-issue-with-decentralisation.html b/blog/untrusted-the-issue-with-decentralisation.html index 8312b91..f4a9d98 100644 --- a/blog/untrusted-the-issue-with-decentralisation.html +++ b/blog/untrusted-the-issue-with-decentralisation.html @@ -4,128 +4,135 @@ Inferencium Network - Blog - Untrusted: The Issue with Decentralisation +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Blog - #2


Untrusted: The Issue with Decentralisation


Posted: 2022-06-30 (UTC+00:00)

-

Updated: 2022-06-30 (UTC+00:00)

+

Updated: 2022-10-29 (UTC+00:00)


Introduction

-

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; there is no way to pin a key to a specific person, to ensure that
-you are communicating with the same person you are supposed to be
-communicating with. In this article, I will discuss some of the security
+

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; there is no way to pin a key to a specific person, to ensure that +you are communicating with 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.


Example: Messaging

-

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 strong enough to not be guessed, whether via personal guessing
-or exhaustive search. The trust in this centralised model is the high
-security these platforms have. It is extremely unlikely that anyone other
-than a government would be able to access the accounts stored on such
-platforms' servers, which makes the physical security trusted. As for
-remote security, should a user's password be compromised, it can typically
-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
+

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 strong enough to not be guessed, whether via personal guessing +or exhaustive search. The trust in this centralised model is the high +security these platforms have. It is extremely unlikely that anyone other +than a government would be able to access the accounts stored on such +platforms' servers, which makes the physical security trusted. As for +remote security, should a user's password be compromised, it can typically +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 introduces 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,
-there 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
+

In the decentralised model, keys are kept on the users' devices, in their +possession. While this soveriegnty is welcomed, it introduces 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, +there 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.


Solution

-

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
-offline? Only by thinking logically and tactically can you solve both the
-issue of centralisation and decentralisation. Often, one size fits all is
+

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 +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
-some sort of identification to ensure that the user changing their keys is
-really the same person who initially signed up for the platform, using a
-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
+

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 +some sort of identification to ensure that the user changing their keys is +really the same person who initially signed up for the platform, using a +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,
+

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
-can access the website I rightfully own, should it be compromised, by
+0. 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 registrar.

-2. 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 to the virtual private
+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 to the virtual private server host.

-3. I have pinned my website to a globally trusted certificate authority,
-Let's Encrypt, which is a trusted party to manage TLS certificates and
+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 it.

-4. 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
+3. 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.

-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
+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.


Conclusion

-

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 (Twitter's misinformation policy comes to mind). If a platform
-is not listening to your or other people's concerns about how it is being
-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 is not 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
+

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 (Twitter's misinformation policy comes to mind). If a platform +is not listening to your or other people's concerns about how it is being +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 is not 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.



-
-Back diff --git a/contact.html b/contact.html index c9d1a28..71bb000 100644 --- a/contact.html +++ b/contact.html @@ -40,6 +40,8 @@ need to use these services, use a preferred method instead.

Briar

Session


+
+

Non-private Methods

The following contact methods do not utilise end-to-end encryption, or I do not use such functionality; they are suitable for public contact diff --git a/contact/briar.html b/contact/briar.html index 00a6992..2c89522 100644 --- a/contact/briar.html +++ b/contact/briar.html @@ -4,6 +4,15 @@ Inferencium Network - Contact - Briar +

+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Contact


@@ -18,7 +27,5 @@ Unavailable

-
-Back diff --git a/contact/session.html b/contact/session.html index 08da090..16cdb58 100644 --- a/contact/session.html +++ b/contact/session.html @@ -4,6 +4,15 @@ Inferencium Network - Contact - Session +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Contact


@@ -18,7 +27,5 @@

-
-Back diff --git a/contact/signal.html b/contact/signal.html index 11b5a00..8f6c829 100644 --- a/contact/signal.html +++ b/contact/signal.html @@ -4,6 +4,15 @@ Inferencium Network - Contact - Signal +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Contact


@@ -18,7 +27,5 @@

-
-Back diff --git a/contact/threema.html b/contact/threema.html index acddb0b..910cdf9 100644 --- a/contact/threema.html +++ b/contact/threema.html @@ -4,6 +4,15 @@ Inferencium Network - Contact - Threema +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Contact


@@ -16,7 +25,5 @@

-
-Back diff --git a/contact/xmpp.html b/contact/xmpp.html index 635659c..5e3d4f0 100644 --- a/contact/xmpp.html +++ b/contact/xmpp.html @@ -4,6 +4,15 @@ Inferencium Network - Contact - XMPP +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Contact


@@ -11,8 +20,8 @@

Updated: 2022-10-13 (UTC+00:00)


-

Whenever possible, open the links to pin the fingerprint directly from
-this webpage. If that is not possible, manually verify the fingerprints.

+

Whenever possible, open the links to pin the fingerprint directly from this +webpage. If that is not possible, manually verify the fingerprints.


inference@inferencium.net

Key

@@ -22,7 +31,7 @@ this webpage. If that is not possible, manually verify the fingerprints.

1bd03c6a 5e011655 2fafd697 da4fce70 63de5a83 a264a34a fcce78fe 6b06820c -xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c +xmpp:inference@inferencium.net?omemo-sid-1586888206=1bd03c6a5e0116552fafd697da4fce7063de5a83a264a34afcce78fe6b06820c

Desktop
@@ -41,10 +50,9 @@ this webpage. If that is not possible, manually verify the fingerprints.

9f9b50e4 3bb5ae5d 886213ad 43015719 7c40aa99 e436445d e0e360a9 24076015 -xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015 +xmpp:inference@plus.st?omemo-sid-1890454018=9f9b50e43bb5ae5d886213ad430157197c40aa99e436445de0e360a924076015


-Back diff --git a/source.html b/source.html index 5e2ddc6..5e51a0b 100644 --- a/source.html +++ b/source.html @@ -4,26 +4,35 @@ Inferencium Network - Source +
+Inferencium Network
+
+
+
About
+
Contact
+
Blog
+
Source
+

Source


-

Inferencium Network Git repository.

-

- Git repository

+

My Personal Source Code Repositories

+

These repositories contain source code which is used on my personal +systems.
+No guarantees are made that they will work correctly on your systems, and are +not targeted towards a public release.
+Usage of these repositories is at your own risk.


-

Inferencium Network website source code.

-

- Website

+

- Configuration files

+

- Script files


-

My personal configuration files.

-

- Configuration files

+

Inferencium Network Source Code Repositories

+

These repositories contain source code targeted at a public release and are +suitable for a wide range of systems.


-

My personal script files.

-

- Scripts

-
-

Inferencium Network Gentoo overlay.

-

- Inferencium Gentoo overlay

+

- Website

+

- Gentoo - Multimedia



-
-Back