# About

## About Me

I am Jake Winters, also known by my pseudonym "Inference", a security 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.

I run multiple XMPP channels; a directory of channels can be found on the directory webpage.

If you wish to contact me for any reason, you can use my contact methods.

## Date and Time

All dates and times across my services are ISO 8601-compliant. The short-form format `YYYY-MM-DD` is used for dates, and `hh:mm:ss` is used for times, with display of seconds being based on required level of accuracy. The full expression may be used when necessary; `YYYYMMDDThhmmssZ` (UTC without offset), `YYYYMMDDThhmmss+hhmm` (with positive offset), or `YYYYMMDDThhmmss-hhmm` (with negative offset).

## Languages

### Markup

The following markup languages are used in my code, with rationale provided for the usage of each language.

Note that derivations of non-Inferencium codebases, such as forks, may not contain the markup languages listed here due to the work involved in replacing all code, but will be rewritten whenever possible, and new code will be written in my preferred languages whenever possible.

#### XHTML

XHTML is preferred for most content due to its HTML-based design and syntax, with advantages over HTML, including strict parsing checks which assist with achieving code-correctness, and being XML-compliant to allow widespread usage even outside of the intended HTML-based use case.

HTML has multiple flaws, including allowing broken code to be loaded in the user's web browser, not informing the developer of broken code or mismatching tags, and using non-standard, highly-permissive syntax which is non-portable. XHTML mitigates or completely fixes these issues via its XML namespace.

#### AsciiDoc

AsciiDoc is used when portability is a concern, as it allows easy conversion to other file formats, including HTML and PDF. AsciiDoc can also be read as-is, due to it having clean markup and high readability when viewed as plaintext.

### Programming

The following programming languages are used in my code, with rationale provided for the usage of each language.

Note that derivations of non-Inferencium codebases, such as forks, may not contain the programming languages listed here due to the work involved in replacing all code, but will be rewritten whenever possible, and new code will be written in my preferred languages whenever possible.

#### Rust

Rust is a partially object-oriented programming language with a focus on security and performance. It has strict compile-time checks to verify the memory-safety and thread-safety of code, is memory-efficient, has no garbage collection, is highly portable, has great support for integration with other languages, and is suitable for both high-level and low-level code.

Rust is the modern replacement for C++.

#### Go

Go is a functional programming language with a focus on performance. It is easy to use, has garbage collection, allows clean codebases, and is suitable for high-level code.

Go is the modern replacement for C.

## Licensing

I care about upstreaming and sharing code, strongly preferring licenses which have high license compatibility in order to permit sharing code with as many other projects as possible; for this reason, permissive licenses are my preferred choice, while avoiding copyleft licenses and other licenses which place restrictions on how my code may be used, and prevent me from including important proprietary code, such as firmware, which can patch security vulnerabilities, privacy issues, and stability issues.

All of my code is and will be permissively-licensed unless specific circumstances make it impractical or infeasible to do so. My goal is to share code which has the least amount of restrictions as possible, to allow wider propagation of my code and allow more use cases and possibilities, as well as ensuring proprietary code, whenever required, is permitted to be included and/or linked to.

ISO 5962:2021 is used for licensing, in the format `SPDX-License-Identifier: <license>`; see the SPDX License List for the full list of available licenses under this standard.

My preferred licenses and rationale for using them are below; any licenses not listed are chosen on a case-by-case basis.

### Code

#### BSD 3-Clause License

SPDX License Identifier: `BSD-3-Clause`

Type: Permissive

BSD 3-Clause License is a highly-permissive license which allows content licensed under it to be used in any way, whether in source or binary form, and allows sublicensing under a different license, with the only restrictions being the original copyright notice must be kept in order to attribute the original creator of the licensed content, and the name of the project and/or its contributors may not be used to endorse or promote products derived from the original project.

#### GNU General Public License v2.0

SPDX License Identifier: `GPL-2.0-only`

Type: Copyleft

GNU General Public License v2.0 is a strong copyleft license which restricts use of content licensed under it by requiring all source code of the content to be publicly available, making binary-only form and inclusion of proprietary code impossible, requiring all derivatives to be licensed under the same license (allowing sublicensing under only newer GPL licenses if `GPL-2.0-or-later` is specified in the SPDX License Identifier), and requiring the original copyright notice to be kept in order to attribute the original creator of the licensed content.

Due to the restrictive and invasive nature of this license, it is avoided unless such restrictions would be beneficial to my code; whenever this is the case, the GNU General Public License v2.0 will be used, rather than the more restrictive GNU General Public License v3.0, and relicensing derivatives under the GNU General Public License v3.0 will be disallowed.

### Non-code

#### Creative Commons Attribution 4.0 International

SPDX License Identifier: `CC-BY-4.0`

Type: Permissive

Creative Commons Attribution 4.0 International is a highly-permissive license which allows content licensed under it to be used in any way, in any medium, with the only restriction being the original copyright notice must be kept in order to attribute the original creator of the licensed content.

### Do I Distinguish Between Open Source and Free Software?

No. If code is not released under an open-source license and places restrictions on how the code may be used, it is either source-available (if viewing the code is permitted) or proprietary. "Free software" only causes confusion and exists to push an ideology by a specific group of people. If software isn't "free", it's not open-source, either.

## Versioning

### What is the Numbering Scheme?

All code uses Semantic Versioning. The numbering scheme is divided into 3 blocks (herein referred to as Block 0, Block 1, and Block 2, in left-to-right order); the version blocks are separated by periods. When a version number block is incremented, all blocks to the right of it are reset to 0. The legacy versioning scheme was a similar numerical versioning scheme which lacked standardisation.

Block 0 contains the `MAJOR` version; this number is incremented whenever an API-incompatible change is made to the code.

Block 1 contains the `MINOR` version; this number is incremented whenever an API-compatible, substantial change is made to the code, such as adding a feature.

Block 2 contains the `PATCH` version; this number is incremented whenever an API-compatible, unsubstantial change is made to the code, such as fixing or optimising the code.

Development and pre-release versions are suffixed with a hyphen, followed by their phase, a period, then the version of that phase; for example, `-alpha.n` for an alpha version, `-beta.n` for a beta version, and `-rc.n` for a release candidate version, with `n` being a positive integer beginning at 1. Stable versions have no suffix.

### What Are the Phases?

There are 4 phases of development. Each phase typically has its own branch in each source code repository. The phases are as follows:

1. Alpha: Pre-alpha development and alpha-testing occurs in this phase. Features are added, modified, and/or removed. Fixes and optimisations may also occur if they are caught during this phase. This is where the majority of changes occur and where the fine-grained commits can be found. Breakage is highly likely within this phase as it makes no attempt to be stable or usable due to being where the most rapid development occurs. Code is tested internally in a fine-grained manner and is moved to the next phase only when it is deemed feature-complete and reasonably stable for broader public testing. If you would like to assist in testing code in this phase, you must use the code and/or tags from the source code repositories due to it not being available publicly outside of them.
2. Beta: Feature-complete testing occurs in this phase. Only bug fixes and optimisations occur in this phase, such as stability and security fixes. This phase is classified as stable enough for broad public testing and is made available publicly in many cases without having to use the source code repositories. Since this phase contains only feature-complete code, no features will be added, modified, or removed in this phase.
3. Release candidate (RC): Feature-complete testing occurs in this phase. Code in the RC phase is often stable enough for production usage, but is not yet completely acceptable to be classified as stable by my standards. This phase is often skipped due to most bugs being caught in the beta phase, but will be used should the need arise for finer-grained testing beyond what the beta phase can provide. Like the beta phase, code in this phase is available publicly without requiring usage of the source code repositories.
4. Stable: Feature-complete and well-tested code is moved to this phase. Code in this phase is deemed to be stable enough for production usage and full support is provided.

When development of a new version has begun, the code within the alpha phase is rebased onto the most recent code from the stable phase before work commences. This cycle continues for the lifetime of the code.

## Services

This list contains the policies and practices of my services.

My policies and practices are heavily security-focused and privacy-focused, with improvements made on an ongoing basis as new technologies, hardware, software, and protocols become available.

### Websites

- Unnecessary logging avoided (only logs required for security and debugging purposes)
- All server logs purged every 14 days
- User IP addresses used only for security and debugging purposes (purged along with logs)
- All connections made via TLS 1.3 only to ensure the most secure AEAD ciphers are used, along with forward secrecy
- All connections made via high-security AEAD ciphers, preferring AES-256-GCM for devices with AES hardware-acceleration, and ChaCha20-Poly1305 for devices without AES hardware-acceleration, with AES-128-GCM as a fallback (AES-128-GCM is mandated for TLS 1.3 by IETF RFC8446 section 9.1)
- All connections are made via high-security key exchange protocols, preferring X25519, with secp256r1 as a fallback (secp256r1 is mandated for TLS 1.3 by IETF RFC8446 section 9.1)
- Domain Name System Security Extensions (DNSSEC) enabled to provide a root-of-trust for encryption and authentication for domain and server configuration
- Certification Authority Authorization (CAA) records enabled to prevent all certificate authorities other than Let's Encrypt from issuing TLS certificates for my domains
- Secure Shell fingerprint (SSHFP) records enabled to provide a DNS-based root-of-trust for SSH connections to my domains
- Referrer headers disabled to prevent knowing where a user was redirected from
- All content sourced from my own domains, with third-party content prohibited via Content Security Policy configuration
- All servers physically under my control (no VPS or other hosting providers)
- No proprietary services, ensuring I have complete control over my services, and vendor lock-in does not occur

## Recommendations

### Hardware

#### Smartphone

Type | Hardware | Description | Source model (SPDX License Identifier)
--- | --- | --- | ---
Smartphone | Google Pixel | ##### Security/Privacy 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 System-on-Chip includes Tensor Security Core, further improving device security. Pixel 8-series includes Armv9's Memory Tagging Extension, which dramatically increases device security by eliminating up to 95% of all security issues caused by memory-unsafety. ##### Support Pixel 5a is supported for a minimum of 3 years from launch. Pixel 6-series, Pixel 7-series, Pixel Fold, and Pixel Tablet are supported for a minimum of 5 years from launch. Pixel 8-series is supported for a minimum of 7 years from launch. | Proprietary (NONE)

### Software

#### PC

Type | Software | Description | Source model (SPDX License Identifier)
--- | --- | --- | ---
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 trapping, and GrapheneOS' hardened_malloc memory allocator. You can find my Gentoo Linux configurations in my configuration respository. | Open-source (GPL-2.0-only)
C Standard Library | musl | musl is a lightweight C standard library which aims to be correct, standards-compliant, and safe. Unlike glibc, it greatly conforms to POSIX standards, deviating very little by keeping its own non-standard extensions to a minimum, and takes care to not break such conformity. Also unlike glibc, due to its lightweight and standards-compliant design, musl is portable and well-suited for use in any system, whether desktop, server, or embedded. | Open-source (MIT)
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)
Version Control | Git | Git is highly-flexible and feature-rich version control software which allows fast, cheap branching for any source code development use case, allowing rapid, flexible development in either centralised or decentralised configurations, whether client-server model or peer-to-peer. | Open-source (GPL-2.0-only)
Gitea | Gitea is an all-in-one development platform with Git hosting, code review, team collaboration, package registry and CI/CD. | Open-source (MIT)

#### Smartphone

Type | Software | Description | Source model (SPDX License Identifier)
--- | --- | --- | ---
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 heap memory corruption vulnerabilities and reduce the lifetime of data in memory due to zero-initialising memory on it being freed, Arm's Memory Tagging Extension to provide protection against heap memory bugs such as use-after-free and buffer overflow (MTE-supporting devices only), 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. | 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 patch-set, 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: Molly: Includes the same proprietary Google code as Signal to support more features Molly-FOSS: Removes the proprietary Google code to provide an entirely open-source client | Open-source (AGPL-3.0-only)
Conversations | Conversations is a well-designed Android XMPP client which serves as the de facto XMPP reference client and has great usability. It supports the latest and most important XMPP extensions (XEPs), including, but not limited to: XEP-0384 (OMEMO Encryption): Provides end-to-end encryption with perfect forward secrecy XEP-0065 (SOCKS5 Bytestreams): Allows file transfers behind network address translation and firewalls XEP-0198 (Stream Management): Allows XMPP to survive small network outages and changes of the underlying TCP connection XEP-0215 (External Service Discovery): Facilitates peer-to-peer audio and video calls via STUN/TURN XEP-0280 (Message Carbons): Allows synchronising messages across different XMPP clients and sessions XEP-0313 (Message Archive Management): Allows storing messages on, and synchronising messages with, the server, which is useful for scenarios such as being offline XEP-0363 (HTTP File Upload): Allows sharing files in multi-user chats and with offline contacts | Open-source (GPL-3.0-only)
Viewer | Gallery | Gallery is a lightweight image and video viewer with image editing capabilities. It has a clean and modern design without including unnecessary features, and runs smoothly. It provides both individual image and video file view, and folder view. | Open-source (Apache-2.0)
Calculator | OpenCalc | OpenCalc is a simple, lightweight calculator with optional scientific features. | Open-source (GPL-3.0-only)

### Music

For a curated list of music I enjoy, visit my music page.

## Is it GNU/Linux or Just Linux?

It's just Linux. GNU is unrelated to Linux, which is a kernel developed by Linus Torvalds. Linux can be used entirely without GNU software in userspace, and the kernel can be compiled without the use of GNU tools. Just because GNU tools were used to initally develop and compile the kernel, and were initially the only available tools for userspace, does not make this true today, and it never made GNU a part of Linux itself at any point of time.

Where are all of the other forward-slashes for every other piece of software on a Linux-based system which makes it just as usable? If a system is running "GNU/Linux", it should be using more than a single forward-slash when there is more to the system than only GNU.

Sitemap