About

This webpage contains personal information about me, including who I am and what I do, as well as information regarding my policies and practices, such as software-development practices.

Me

My avatar, which is currently a pixel-art, anime-style right-half of a face, with bright-blue eyes and dark-brown, naturally-messy hair, staring determinedly at the viewer. A medium-blue hoodie is being worn, with the hood down.

I am Jake Winters, also known by my pseudonym "Inference", a computer-science researcher focussing on security, based in Durham, 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 experiences in security. Most of my postings are security-related, but I occasionally post about other aspects of 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 SimpleX groups and channels; a directory of groups and channels can be found on the Directory webpage.

If you wish to contact me for any reason, you can find my contact methods on the Contact webpage.

Am I a Weeb?

Yes. Most of what I watch is anime, and a lot of what I read is manga. I love the anime art style; all of my avatars/profile-pictures are anime-style, reflecting this.

Which Types of Music Do I Enjoy?

I mostly enjoy electronic dance music (EDM), but I also enjoy other genres, dependent on the music. For a curated list of music I enjoy, visit the Music webpage.

What Are My Political Opinions and Affiliations?

For information about my political opinions and affiliations, visit the Politics webpage.

Am I Religious?

I am not religious in the supernatural sense and do not believe in the existence of a god or similar entities. For more information about my religious affiliations, visit the Religion section of the Politics webpage.

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.

Where Else Can I Be Found?

You can find me also on the following third-party services:

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 multi-paradigm 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 will be used when the code must be compiled into a binary and/or the performance of the code is critical.

Licensing

I care about upstreaming and sharing code, strongly preferring licences which have high licence compatibility in order to permit sharing code with as many other projects as possible; for this reason, permissive licences are my preferred choice, while avoiding copyleft licences and other licences 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: <licence>; see the SPDX License List for the full list of available licences under this standard.

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

I encourage people to share my code, and create derivatives of my code for their own needs and circumstances. I explictly permit these actions via the unrestrictive licences I use.

Code

MIT License

SPDX License Identifier: MIT

Type: Permissive

MIT License is a highly-permissive licence which allows content licensed under it to be used in any way, whether in source or binary form, and allows sublicensing under a different licence, with the only restrictions being the original copyright notice must be kept in order to attribute the original creator of the licenced content.

As branding is a separate issue to content licensing, this licence superseded BSD 3-Clause License on 2025-12-05 in order to simplify licensing.

BSD 3-Clause License

SPDX License Identifier: BSD-3-Clause

Type: Permissive

BSD 3-Clause License is a highly-permissive licence which allows content licensed under it to be used in any way, whether in source or binary form, and allows sublicensing under a different licence, with the only restrictions being the original copyright notice must be kept in order to attribute the original creator of the licenced 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.

This licence was superseded by MIT License on 2025-12-05.

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 licence which restricts use of content licenced 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 licenced 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 licenced content.

Due to the restrictive and invasive nature of this licence, 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 licence which allows content licenced 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 licenced content.

Versioning

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.

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.

Version Control

My code is managed via Git, a popular, battle-tested version-control system used by almost all other developers and projects, including Linux.

My web-based Git management is performed via Gitea, an all-in-one development platform with Git hosting, code review, team collaboration, package registry and CI/CD.

All of my code is developed openly on my Gitea server.

All commits use Conventional Commits, a standardised specification for writing commit messages and descriptions. Each commit begins with its type, from the following list:

Following the type is the scope, which is omitted in the case of multiple scopes being modified via the commit. The scopes used vary by project; consult each project's source-code repository for their specific scope declarations.

In the case of a breaking-change, ! is suffixed to the type or scope; whichever is last; and a description of the breaking-change will be included in the commit description. A breaking-change is equivalent to a MAJOR version increase.

The final component of the commit message is :, followed by a space and a string explaining the changes made via the commit. There may also be a commit description, if more information than only the commit message is required to understand the commit; the commit description is mandatory in the case of a breaking-change.

Conventional Commits works alongside Semantic Versioning to provide a clear, semantic overview of changes being made to the codebase, and allows for easy automation of changelogs due to the relationship between the two specifications.

Infrastructure

Primary

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

Sitemap