From d1ebc1e933757232953a4d799a18dbfd52d48577 Mon Sep 17 00:00:00 2001
From: inference Inferencium website. All content is licensed under BSD-3-Clause-Clear license*.Website
-
-
-Licensing
-
-
-*Exceptions:
-
-
All files are checked for security issues; however, it is always the user's responsibility to
-audit the code before installing and/or executing it.
-
-Inferencium takes no responsibility for any security issues which may arise due to usage of this
-repository.
Development branch. All pre-alpha development and alpha testing happens here.
-
-
Beta branch. All beta testing happens here.
-Stable branch. Complete and stable versions are stored here.
-
diff --git a/about.html b/about.html
deleted file mode 100644
index 9a27dfd..0000000
--- a/about.html
+++ /dev/null
@@ -1,413 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
I am Jake Winters, also known by my pseudonym "Inference", a cybersecurity researcher based in
- United Kingdom.
- I am the founder, lead developer, and administrator, of Inferencium.
- All opinions are my own, and are not necessarily shared with projects or people I am
- affiliated with.
-
-
I write about my research and experience in cybersecurity and also physical security. - Most of my postings are security-related, but I occasionally post 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 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.
If you want to contact me for any reason, you can use my - contact methods.
-Type | -Hardware | -Description | -Source model - - (License - SPDX) |
-
Smartphone | -![]() - - Google Pixel |
- Google Pixel devices are the best Android devices available on the market for
- security and privacy. - - They allow locking the bootloader with a - custom Android Verified Boot (AVB) key in order to preserve security and privacy - features when installing a custom operating system, such as - verified boot which verifies that the OS has not been corrupted or tampered with, - and - rollback protection which prevents an adversary from rolling back the OS or - firmware version to a previous version with known security vulnerabilities. - - They also include a - hardware security module (Titan M2, improving on the previous generation - Titan M) which is extremely resistant to both remote and physical attacks due to - being completely isolated from the rest of the system, including the operating system. - Titan M2 ensures that the device cannot be remotely compromised by requiring the side - buttons of the device to be physically pressed for some sensitive operations. Titan M2 - also takes the role of - Android StrongBox Keymaster, - a hardware-backed Keystore containing sensitive user keys which are unavailable to - the OS or apps running on it without authorisation from Titan M2 itself. - Insider attack resistance ensures that Titan M2 firmware can be flashed only if the - user PIN/password is already known, making it impossible to backdoor the device without - already knowing these secrets. - - Google Pixel device kernels are compiled with - forward-edge control-flow integrity and - backward-edge control-flow integrity to prevent code reuse attacks against the - kernel. MAC address randomisation is - implemented well, along with minimal probe requests and randomised initial sequence - numbers. - - Google releases - guaranteed monthly security updates, ensuring Google Pixel devices are up-to-date - and quickly protected against security vulnerabilities. - - Pixel 6-series and 7-series devices are a large improvement over the already very - secure and private previous generation Pixel devices. They replace ARM-based Titan M - with RISC-V-based Titan M2, reducing trust by removing ARM from the equation. Titan M2 - is more resiliant to attacks than Titan M, and is - AVA_VAN.5 certified, the highest level of vulnerability assessment. Google's - in-house Tensor SoC includes Tensor Security Core, further improving device security. - - Pixel 6-series and 7-series devices are supported for a - minimum of 5 years from launch, an increase from previous generations' - support lifecycles of 3 years. |
-
Type | -Software | -Description | -Source model - - (License - SPDX) |
-
Operating system | -![]() - - Gentoo Linux |
- Gentoo Linux is a highly modular, source-based Linux-based operating system which
- allows vast customisation to tailor the operating system to suit your specific needs.
- There are many advantages to such an operating system, with the most notable being the
- ability to optimise the software for security, privacy, performance, or power usage;
- however, there are effectively unlimited other use cases, or a combination of multiple
- use cases. - - I have focused on security hardening and privacy hardening, placing performance below - those aspects, although my system is still very performant. Some of the hardening I - apply includes - stack protection, - signed integer overflow wrapping, and GrapheneOS' - hardened_malloc memory allocator. - - You can find my personal Gentoo Linux configurations in my personal - configuration respository. |
- Open source - - (GPL-2.0-only) |
-
Web browser | -![]() - - Chromium |
- Chromium is a highly secure web browser which is often ahead of other web browsers - in security aspects. It has a dedicated security team and a very impressive - security brag sheet. - Chromium's security features include a strong - multi-layer sandbox, - strong site isolation, - Binding Integrity memory hardening, and - control-flow integrity (CFI). | -Open source - - (BSD-3-Clause) |
-
Type | -Software | -Description | -Source model - - (License - SPDX) |
-
Operating system | -![]() - - GrapheneOS |
- GrapheneOS is a security-hardened, privacy-hardened, secure-by-default
- Android-based operating system which implements extensive, systemic security and privacy
- hardening to the Android Open Source Project used as its base codebase. Its hardening
- includes closing gaps for apps to access sensitive system information, a secure app
- spawning feature which avoids sharing address space layout and other secrets AOSP's
- default Zygote app spawning model would share,
- hardened kernel, hardened memory allocator
- (hardened_malloc) to protect against common memory corruption vulnerabilties,
- hardened Bionic standard C library,
- stricter SELinux policies, and local and remote hardware-backed attestation
- (Auditor) to ensure the OS has not been corrupted or tampered with. - - GrapheneOS only supports - high security and well-supported devices which receive full support from their - manufacturers, including firmware updates, long support lifecycles, secure hardware, and - overall high security practices. - - For an extensive list of features GrapheneOS provides, visit its - official features list which provides extensive documentation. |
- Open source - - (MIT) |
-
Web browser | -![]() - - Vanadium |
- Vanadium is a security-hardened, privacy-hardened Chromium-based web browser which
- utilises GrapheneOS' operating system hardening to implement stronger defenses to the
- already very secure Chromium web browser. Its hardening alongside Chromium's base
- security features includes
- disabling JavaScript just-in-time (JIT) compilation by default,
- stubbing out the battery status API to prevent abuse of it, and
- always-on Incognito mode as an option. - - Vanadium's source code, including its Chromium patchset, can be found in its - official repository. |
- Open source - - (GPL-2.0-only) |
-
Messenger | -![]() - - Molly |
- Molly is a security-hardened, privacy-hardened
- Signal client which hardens Signal by using a variety of
- unique features, allowing
- locking the database when not in use, and
- utilising Android StrongBox to protect user keys using the device's hardware
- security module. - - Molly is available in - 2 flavours: -
- |
- Open source - - (GPL-3.0-only) |
-
Messenger | -![]() - - Conversations |
- Conversations is a well-designed Android - XMPP client which serves as the de facto XMPP reference client and has great - usability. | -Open source - - (GPL-3.0-only) |
-
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.
-- I have phased out usage of obsolete, insecure PGP for all contact methods.
-- I have phased out usage of email, including TLS-encrypted email.
-Whenever possible, use the following contact methods; they allow verification to mitigate man-in-the-middle
- attacks, have high security, and reasonable privacy.
-
-
Use the
- keys for each contact method to verify my devices.
- Note: Verification does not verify a person, only their devices, and can be defeated via coercion or other
- force.
Signal
-
- +447549902964
-
XMPP
-
- inference@inferencium.net
- (Key)
-
-
-
-
-
If metadata leakage is an issue for you, you can use the following contact methods.
-
- Note: These services do not have verification functionality and will be treated as less secure; unless
- you really need to use these services, use a preferred method instead.
Briar
-
- Unavailable
Session
-
- Unavailable
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
-
- Note: Verification does not verify a person, only their devices, and can be defeated via coercion or other - force.
-Updated: 2023-01-13 (UTC+00:00)
-Whenever possible, open the links to pin the fingerprints 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
-
- Updated: 2023-01-13 (UTC+00:00)
-
- SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
-
-
- ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINs8UH2hVmNSg0qKig/9ZQt07IuOHsorRfw1doEgMuJ8
-
-