From 3e59bcc90d364e1353efb5d8672b7f0f910c5b58 Mon Sep 17 00:00:00 2001 From: inference Date: Sat, 2 Sep 2023 14:22:13 +0100 Subject: [PATCH] Remove redundant CSS classes --- blog/foss_is_working_against_itself.html | 74 +++++++++---------- blog/systemd_insecurity.html | 28 +++---- blog/the_chromium_monopoly.html | 18 ++--- ...usted_the_issue_with_decentralisation.html | 24 +++--- 4 files changed, 72 insertions(+), 72 deletions(-) diff --git a/blog/foss_is_working_against_itself.html b/blog/foss_is_working_against_itself.html index 2758513..07ec1db 100644 --- a/blog/foss_is_working_against_itself.html +++ b/blog/foss_is_working_against_itself.html @@ -5,7 +5,7 @@ - + @@ -35,33 +35,33 @@

Updated: 2022-11-09 (UTC+00:00)

-

Table of Contents

+

Table of Contents

-

Introduction

+

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 "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 + FOSS movement is an attempt to regain - privacy + privacy and - control + 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. "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, @@ -69,54 +69,54 @@ FOSS movement is seeking.

FOSS projects rarely take security into account; they simply look at the surface level, rather than the actual - root cause + 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, + 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.

-

Examples

+

Examples

-

Smartphones

+

Smartphones

A FOSS phone, especially so-called - "Linux phones" + "Linux phones" are completely detrimental to privacy and control, because they do not have the security necessary to enforce that privacy. - Unlocked bootloaders + Unlocked bootloaders prevent the device from - verifying the integrity of the boot chain, + 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 + 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 + Privilege escalation is trivial to achieve on any Linux system, which is the reason Linux - hardening + hardening strategies often include restricting access to the root account; if you - root your Android phone, + 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, + 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?", + LineageOS?", to which I answer with "What's not bad about it?".

  • LineageOS uses - debug builds, + 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 @@ -125,11 +125,11 @@ 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, + 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.
    • + 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 @@ -138,34 +138,34 @@

-

Solution

+

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 + 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. + GrapheneOS. Google Pixel phones allow you complete bootloader freedom, including the - ability to lock the bootloader after flashing a custom OS + 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 + malware persistence, evil maid attacks, and boot chain - corruption), - long device support lifecycles + 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 + guaranteed monthly security updates for the entire support timeframe of the devices.

-

Conclusion

+

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; privacy and control.

diff --git a/blog/systemd_insecurity.html b/blog/systemd_insecurity.html index 2f3c585..39b5d98 100644 --- a/blog/systemd_insecurity.html +++ b/blog/systemd_insecurity.html @@ -5,7 +5,7 @@ - + @@ -34,28 +34,28 @@

Updated: 2022-11-14 (UTC+00:00)

-

Table of Contents

+

Table of Contents

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.

-

Issue #0 - Against CVE Assignment

+

Issue #0 - Against CVE Assignment


"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

+ systemd GitHub Issue 5998

-

Issue #1 - CVEs Are Not Useful

+

Issue #1 - CVEs Are Not Useful

"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 @@ -66,18 +66,18 @@ 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

+ systemd GitHub Issue 6225

-

Issue #2 - Security is a Circus

+

Issue #2 - Security is a Circus

"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

+ systemd GitHub Issue 5144

-

Issue #3 - Blaming the User

+

Issue #3 - Blaming the User

"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. @@ -93,7 +93,7 @@ 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

+ systemd GitHub Issue 6237

diff --git a/blog/the_chromium_monopoly.html b/blog/the_chromium_monopoly.html index f3fcd5e..ae16748 100644 --- a/blog/the_chromium_monopoly.html +++ b/blog/the_chromium_monopoly.html @@ -5,7 +5,7 @@ - + @@ -34,15 +34,15 @@

Updated: 2022-12-20 (UTC+00:00)

-

Table of Contents

+

Table of Contents

-

Introduction

+

Introduction

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 @@ -50,7 +50,7 @@

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%, + 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 @@ -59,7 +59,7 @@ a fully working web.

-

Solution

+

Solution

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 @@ -88,7 +88,7 @@ we must be tactical, not emotional.

-

Conclusion

+

Conclusion

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 diff --git a/blog/untrusted_the_issue_with_decentralisation.html b/blog/untrusted_the_issue_with_decentralisation.html index 531da58..640d35d 100644 --- a/blog/untrusted_the_issue_with_decentralisation.html +++ b/blog/untrusted_the_issue_with_decentralisation.html @@ -5,7 +5,7 @@ - + @@ -34,19 +34,19 @@

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

-

Table of Contents

+

Table of Contents

-

Introduction

+

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; @@ -55,9 +55,9 @@ security issues with the decentralised model.

-

Examples

+

Examples

-

Messaging

+

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 @@ -82,7 +82,7 @@

-

Solution

+

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 @@ -118,7 +118,7 @@ form, decentralisation would make this impossible to implement in any form.

-

Conclusion

+

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