- Inferencium-
-
- - - - - -
Posted: 2022-01-27 (UTC+00:00)
-Updated: 2022-11-09 (UTC+00:00)
-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 "Free and Open Source (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 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 platform on this model.
-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 adversary, whether a -stranger who happens to pick up the device, or a 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, without coercion? -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 "What's not bad about it?".
-
-- LineageOS uses
-debug builds, not safe and secure release builds.
-- 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 physically 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 production OS.
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, -Pixel 4a-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 4a-series to Pixel 5a, minimum 5 -years for Pixel 6-series and newer), and -guaranteed monthly security updates for the entire support timeframe of the devices.
-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.
-Posted: 2022-01-29 (UTC+00:00)
-Updated: 2022-11-14 (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.
-Poettering:
-"You don't assign CVEs to every single random bugfix we do, do you?"
My thoughts:
-Yes, if they're security-related.
Source:
-systemd GitHub Issue 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 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.
Source:
-systemd GitHub Issue 6225
Poettering:
-"I am not sure I buy enough into the security circus to do that though for any minor issue..."
Source:
-systemd GitHub Issue 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 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 it doesn't refuse an invalid username.
-
-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, then
-Poettering blamed the user.
Source:
-systemd GitHub Issue 6237
Posted: 2022-12-20 (UTC+00:00)
-Updated: 2022-12-20 (UTC+00:00)
-It's no secret that I'm an advocate of Chromium and will use it for the foreseeable future. It is
-a highly secure web browser which provides strong protection against malicious wesbites and the code
-they run, and, while I am not too interested in high performance, it is a very performant web
-browser, despite its security features.
-
-However, the intention of this blog post is not to promote Chromium for any reason, but rather show
-an issue with it; an issue which is larger than may be realised by web-surfing users. That issue is
-the large monopoly Chromium has in the web browser market;
-Chromium's market share is around 65%,
-making it the largest slice of the cake. The issue becomes even deeper and more problematic when you
-realise that the second-place web browser, Safari, has only an 18% market share.
-
-The main issue with this type of monopoly is the large amounts of power and influence it gives
-Chromium, which can lead to, and is leading to, excessive authority of how the web should work, and
-the standards which are implemented, which all other web browsers must comply with in order to have
-a fully working web.
-
-
In order to combat the Chromium monopoly, users typically go over to Chromium's classical rival,
-Firefox. However, Firefox is dying and has lost almost all of its userbase over the last 2-3 years;
-the reason for this is a tale of selfishness and greed, caused by Firefox's parent company to go off
-course and lose its original goal of providing a freedom-respecting, open web. Mozilla caused
-self-inflicted damage which it cannot recover from, and, to me, is already dead. The vultures are
-simply waiting for the final, small group of users to abandon the project before Firefox finally
-succumbs to its own demise; the demise it caused itself.
-
-If attempting to increase Firefox's market share to previous levels will be in vain, what is the
-solution? How can we prevent Chromium from completely taking over the web and dictating everything
-we do and how the web should be designed and used?
-To find the answer to these important but difficult questions, we must go to the alternatives which
-still have a fighting chance. Safari, developed by Apple, is based on WebKit, an engine completely
-independent of Chromium and Firefox.
-
-Just using a non-Chromium-based web browser is not enough; the choice must already have enough
-market share to still be relevant, and be capable of gaining new users. Safari, being preinstalled
-on Apple devices including iPhone and Mac, already has a great advantage over Firefox. Apple
-devices, especially iPhone, is abundant in streets everywhere on the planet. Safari is the default
-choice for Apple users and has a large market share simply because of how widespread it is.
-Exploiting this fact is the only way to gain more market share and take down Chromium before it is
-too late; the clock is ticking, and Apple are the only ones preventing Chromium from completely
-taking over the web. Backing Safari instead of Firefox will keep the WebKit market share from
-falling to a critically low percentage, making it impossible to make a comeback, as has happened to
-Firefox. Sometimes, directly supporting a political party is not the way to get them into power,
-supporting the second-place alternative is, in order to keep the one you don't want out of power,
-giving the party you do want in power an advantage. To win this war against the Chromium monopoly,
-we must be tactical, not emotional.
-
Supporting Safari is the first step in supporting WebKit and promoting usage of the independent
-web engine. Buying time while supporting and contributing to WebKit browser projects is the best and
-only chance anyone has at competing with Chromium, and preventing it from increasing its dominance
-to unstoppable levels, at which point there will be no return.
-
-
-
-
-
diff --git a/blog/untrusted_the_issue_with_decentralisation.html b/blog/untrusted_the_issue_with_decentralisation.html
deleted file mode 100644
index 9e76a11..0000000
--- a/blog/untrusted_the_issue_with_decentralisation.html
+++ /dev/null
@@ -1,135 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
Posted: 2022-06-30 (UTC+00:00)
-Updated: 2022-10-29 (UTC+00:00)
-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.
-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 meet and exchange keys.
-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 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:
-
-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.
-
-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.
-
-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.
-
-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 implement in any form.
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.
-Updated: 2022-11-15 (UTC+00:00)
-
- Unavailable
-
- Updated: 2022-11-15 (UTC+00:00)
-
- Unavailable
-
- Updated: 2022-11-14 (UTC+00:00)
-
- +447549902964
-
- Updated: 2022-12-05 (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.
-
- 1bd03c6a 5e011655 2fafd697 da4fce70 63de5a83 a264a34a fcce78fe 6b06820c
-
-
- bf2aa069 2bb90210 aee7e17c e3d90127 cfe3502a 6450f8ab e76dbbb0 e5864b7a
-
-