+ 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 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.
+"You don't assign CVEs to every single random bugfix we do, do you?"+
- Lennart Poettering, systemd lead developer
+My thoughts:
+ Yes, if they're security-related.
Source:
+ systemd GitHub Issue 5998
"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..."+
- Lennart Poettering, systemd lead developer
+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
"I am not sure I buy enough into the security circus to do that though for any minor + issue..."+
- Lennart Poettering, systemd lead developer
+Source:
+ systemd GitHub Issue 5144
"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."
- Lennart Poettering, systemd lead developer
+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.
+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:
+
+
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.
+