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.
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).
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 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 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.
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 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.
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.
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.
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
- 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.
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.
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.
All code uses
- Semantic Versioning.
- The numbering scheme 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
- non-negative integer. Stable versions have no suffix.
There are 4 phases of development. Each phase typically has
- its own branch in each source code repository. The phases are as
- follows:
-
-
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.
-
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.
-
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.
-
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.
This list contains the policies and practices of my services.
-
My policies and practices are heavily security- and privacy-focused, with
- improvements made on an ongoing basis as new technologies, protocols, and
- software become available.
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)
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 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.
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.
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).
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 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 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.
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 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.
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.
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 mypreferred 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.
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
+ 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.
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.
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.
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 non-negative integer. Stable versions have no suffix.
There are 4 phases of development. Each phase typically has its own branch in each source
+ code repository. The phases are as follows:
+
+
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.
+
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.
+
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.
+
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.
This list contains the policies and practices of my services.
+
My policies and practices are heavily security- and privacy-focused, with improvements made on an
+ ongoing basis as new technologies, protocols, and software become available.
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)
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 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.
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.
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
- vulnerabilities,
- 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.
Molly, which includes the same
- proprietary Google code as Signal to
- support more features
-
Molly-FOSS, which removes the
- proprietary Google code to provide an
- entirely open-source client
-
-
-
- Open-source
- (GPL-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.
-
-
- 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.
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.
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.
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 vulnerabilities,
+ 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.
Molly, which includes the same proprietary Google
+ code as Signal to support more features
+
Molly-FOSS, which removes the proprietary Google
+ code to provide an entirely open-source client
+
+
+
+ Open-source
+ (GPL-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.
+
+
+ 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.
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.
- 
