Sure, I will prepare an exit strategy so Whonix no longer hosts the list in the near future, but I need to state some important information before this plan is set into motion:
The KYC Not repository upstream has not responded to any of my contributions since March 20th, either on Codeberg or on their instance itself.
The self-hosted KYC Not instance, assuming there are no LICENSE issues, will not be advertised/broadcasted by default.
Implications:
If my contributions upstreams are not being reviewed in a timely manner (up to one month from the initial commit), then I will not bother backporting any changes upstream either, as mentioned in step #6, because I have already pre-established a sustainable monthly updating cadence from the Whonix Wiki.
When the self-hosted KYC Not instance is ready, I will signal its availability status in this topic, but will not provide a URL unless explicitly authorized in advance or requested afterwards.
Due to conflict of interest concerns, I will not be updating the respective Whonix Wiki page after signalling the self-hosted KYC Not instance status, so any references to the instance URL, other than the second implication, will either be voluntarily provided by you on behalf of Whonix, or manually reviewed by you from third-party contributions on the Whonix Forum and/or Whonix Wiki.
Note: From my perspective you’re not bound to any “upstream first” as the list would be your project with full editorial freedom with no oversight from the Whonix project. (Upstream first, collaborate editing is generally preferable but not a standard we can hold external projects to.)
Right, but my work can greatly benefit myself as well as others, especially the Tor Project’s Good Bad ISP page. Improving that resource upstream will improve the quality of the Tor network, which in turn improves Kicksecure and Whonix, which I use daily. I will need to add additional attributes to the KYC Not repository used on the Tor Project’s Good Bad ISP page, such as “Tor non-exit relays permitted”, “Tor exit relay with reduced exit policy permitted” or similar to directly address Tor relay operators’ concerns.
I have contacted @pluja via email about the LICENSE issue for the KYC Not repository and will update this topic when I have received a response back from them. Also, the last update on the bitcoin-vps.com website as of this writing was March 26th.
A LICENSE file has been added to the KYC Not repository, but it is completely unusable for our use case:
I have no incentive to contribute to their repository now, so I need to figure out another sustainable solution for myself and Whonix. I am aiming to formulate one before the next monthly update due near the end of April. The last update on the bitcoin-vps.com website as of this writing was April 9th.
A custom drop-in replacement is now available, superceding these headers on the Whonix Wiki page:
Anonymous third-party hosting providers
Onion webspace
Drawback:
OR conditions are either explicitly enumerated or entirely dropped (email address or XMPP address, Tether on $X or $Y blockchain, etc.) in favour of simple taxonomies (email-address, xmpp-address, tether)
Known issues:
Whonix Wiki migration (ignoring three previously removed entries) has been completed, but no entries have been reverified/reviewed up to the checkout process’ invoice for April yet (all still currently assigned pending status)
No text description comprehensively explaining monthly or yearly update cadence at the hosting directory
No CI/CD runner pipelines to automatically reset all entries’ statuses to pending near the end of each month or year
Thumbnail file formats vary (.png, .svg, etc.) and could benefit from standardization/sanitization
Various minor visual bugs and text string placeholders
Benefit:
In other words, I can do anything/everything in post #37 and more.
Okay, this will be a very big and impactful post, so we will start with the custom drop-in solution (fully migrated from the maintained list on the Whonix Wiki for April 2026, but not from the beginning of this topic nor the historical archived list):
Relevant repositories:
There are currently four statuses:
Verified, which means I have personally used the service, either before or now
Approved, which means I have personally reviewed the entire website up until the checkout process and generated invoice
Pending, an unreviewed entry, but also includes reviewed broken checkout processes (instead of removing the entry until the next month)
Rejected, failing the Whonix Wiki criteria outright and is deferred any status update until the beginning of next year’s Firefox release
Every Firefox release, any entries with “verified” or “approved” status becomes automatically changed to “pending”, acting as the successor to the monthly Whonix Wiki cadence. This is enforced through a Forgejo Runner job from upstream-sync.yml in the FlawlessFox repository:
That is the high-level summary, so are are my suggestions for you from this point onwards:
Remove the “Anonymous Third-Party Hosting Providers” and “onion Webspace” headers in the respective Whonix Wiki page, including all contents within it
Keep the historic deprecated list and this entire topic available/intact for me to fully and manually recrawl/rescrape every entry after the next Firefox release around May 19th, 2026, along with extracting every good idea to implement into the Hosting Directory on the next round.
Decide a name for your (next) Firefox fork (currently based on Mozilla’s GitHub Firefox repository upstream, not from the Tor Project’s GitLab repository).
The current tenative name is “BaseSecure” (derived from Base Browser, which no longer exists, and Kicksecure), but I have also considered “BrowSEC” and various variations involving these two, from extending “SEC” to “Secure”, to truncating the names themselves (“BaseSEC” → “BaSEC”). Currently, “Secure” in “BaseSecure” is capitalized because Firefox forks historically practice this (LibreWolf, GNU IceCat, etcetera). If you want it super simple, then we reuse “SecBrowser” again (or SecureBrowser, etcetera). Once you have decided, then after letting me know, you will likely want to either create a new topic or add to an existing topic about this Firefox fork on the Kicksecure Forum, depending on your decision.
The headers, vendor-independent, neutral mostly timeless information can stay but the vendor list can be removed and replaced with established external provider review list(s).
As far as Kicksecure is concerned, we don’t want to get into in-house browser development. Documented in wiki chapter: In-House Browser Development
I am happy to share my opinion on browser naming.
SecBrowser was a horrible name choice of mine. I would suggest to avoid anything starting with or easily abbreviated using Sec. It’s just 1 letter away, last letter replaced by x. This was confusing search engines. Instead of Sec, search engines referred the version with x.
Sad that search engines are so stupid but this would be an unnecessary slow down for the project. Typically sec also does not seem to be a popular abbreviation in the security community.
Capitalization is reasonable. Which are the most successful projects coming to mind and their names?
I do discourage that. SecBrowser being a bad name choice and also SecBrowser was confusing, already has a history that might interfere. Search engines actually have quite some mentions of SecBrowser nowadays.
There are also unrealted, non-browser projects with the same name. (SPPM SecBrowser / secbrowser simple interface to interact with SEC fillings / Sec Web Browser android app)
Clean source code: If using a fork of an existing browser, any anti-features (like adware, trackers, or DRM modules) must be removed from the source code entirely - not just disabled in settings. Otherwise, there’s a risk they could be re-enabled by accident or after an update.
The important part is “removed from the source code entirely”.
Open Source / Freedom Software requires people courageous enough to get started and work on complicated problems. It requires to start small, be persistent and keep going. I applaud all efforts towards making browsers less awful.
Meanwhile, more realistic and also a vacuum might be to become a softfork or hardfork of arkenfox to fix some or all the very unfortunate arkenfox issues listed here and to audit it.
The only one off the top of my head that is maintained now and is close to Kicksecure’s criteria, other than my fork, is LibreWolf. I suppose the other approach is to look at what SecBrowser was actually deriving from originally:
Base Browser
Mullvad Browser
Tor Browser
These names simply have “Browser” at the end, so half of the equation is already done for you with this interpretation, although I would not necessarily use “Base”, “Kick”, or “Secure” as the initial word in this pairing.
It does not require a hard fork, and this is already done now, so I will explain in simple terms:
Building Firefox requires selecting or omitting compile arguments, along with values, typically Boolean(-like) in nature, or an empty string
Those arguments define what code to compile or not
Here is an example of DRM being compiled out, meaning that the entire source code tree referencing it is completely removed from the build process (#L1930-L1952):
That is the easy part, I already reviewed all of the build options (including implied options), and for FlawlessFox and BaseSecure (tenative name), they are identical at compile time, so they share identical maintenance. In a nutshell:
Mozilla releases a new Firefox version
I manually merge the new tagged version
Then two situations:
No compile options changed between versions, remaining CI/CD pipeline passes automatically without manual intervention (expected)
Compile options has been changed between versions, I manually audit/review them, commit, then CI/CD build passes (fallback, very easy maintenance)
I did all of the initial work upfront, so neither of us have to do much about compile options long-term.
On my way there, not a problem, adversarial suite is near the end of the roadmap, dynamic analysis will be addressed around there in due time, here is a sneak peek:
### Milestone 7: Dynamic analysis foundation
**Goal**: Runtime observation validates static configuration.
- Wire monitor system into automated testing
- Marionette/WebDriver BiDi scenarios
- LINDDUN + STRIDE category coverage
- Adversarial test suite
- Cross-validation against static configuration claims
**Deliverable**: Automated dynamic analysis confirming privacy properties at runtime.
It does not, it only takes one person, one CI detection runner triggering a cron job at 6 UTC everyday (upstream-sync.yml), and one Python script (upstream-sync.py) to create an issue for me to manually merge the new upstream tag.
I was already maintaining my own runtime preference files, but after I decided to start a Firefox fork, it made sense to consolidate them:
It is not very clear nor obvious from reading any Mozilla documentation, but there are multiple priorities that can override each other from the runtime files:
Arkenfox “only” maintains a comprehensive user.js file, but ignores the compile and other runtime layers, whereas my Firefox fork will address every layer and every parent-child dependency between and within them, all the way down to the C++/Rust source code for complete static analysis defense-in-depth.
However, the devil is in the details. Some preferences are hard-coded into the C++/Rust source code and cannot be changed by any layer’s configuration files. GNU IceCat realized this and applied explicit source transformations during the compile process, but line-oriented sed is fragile and unmaintainable because there is no registry to keep track of every new, changed, or deprecated parameter. My solution to handle the entire stack is simple and is already successfully implemented at the compiler layer:
Scan every parameter toggled by any preference in the source code
Dump/merge it into options-registry.yml (complete) and prefs-registry.yml (about:config, no C++/Rust source code yet)
Map all dependencies between and within all layers
Audit all of them manually
Patch the rest
The best part is that I already have all of the experience I will ever need because of the Whonix Wiki. Auditing preferences every month is hardly any different from auditing entries every month from my perspective. The only hard part is deciding on a ideal name for the Kicksecure browser, because that is simply not my decision to make.
After you have decided on a name, let me know so I can mass replace a bunch of text strings in the code, unless you agree with BaseSecure. For any/all other inquiries, read the WORKFLOW.md first, which is a more detailed technical breakdown of what I have concisely explained in this post:
Also important: Binary Build Locations? Project Controlled Builds or Third-Party Controlled Builds?
I am not sure Kicksecure could require project controlled builds as a criteria because other browser projects may also not have this feature. If it was an in-house browser project, then the criteria would be more stringent and this would be a criteria.
It’s not a criteria yet for Kicksecure default browser choice because I didn’t survey yet how other browser projects handle this.
Simple and brilliant. Yeah. Why not add “Browser” as the second word.
You can also widen the search. What are successful project names generally? Microsoft? 2 words only. Simple. But hard to argue its success is based on that since they existed for decades already.
Interesting.
I mean, yeah, if it works…
Sounds good.
Excellent.
Long-term maintainability: The browser project should be active and well-funded (or backed by a strong community), with regular security updates. If it’s abandoned or poorly maintained, users could be left vulnerable to known exploits. Also, switching browsers is hard for some users. Therefore, the default browser must be a stable choice for years.
This criteria is more about the “bus factor”.
Very cool.
Great!
Yeah, I am very much expecting a rabbit holes.
Interesting. Got any references?
Yes, that sounds super fragile and unmaintainable.
For now it’s your decision to make.
I don’t have the bandwith for In-House Browser Development and would prefer if this is maintained as an independent project and gains traction. I do depend on the wider community to scrutinize the project.
Okay, once the project is out of pre-release status, I will create a new topic in the Kicksecure Forum, and assume approval of its establishment unless informed otherwise.
Yes, the entire scaffolding, just so I can manually audit everything that matters. The hand-crafted user.js and policies.json files were originally migrated from a Codeberg repository that no longer exists.
No.
1 hour and about 39 minutes without ccache=scache enabled, I will need to carefully consider the security implications of having the cache enabled in a rootless Podman Quadlet container to accelerate the Firefox build itself before deploying it.
Everything is self-hosted on a dedicated server from Hetzner, and I control everything about the infrastructure otherwise. All of this is directly derived from my (previous) work on the Whonix Wiki, which is also what enforces sustainably updating my Hosting Directory long-term.
The main tooling itself is mach, which is what essentially automates the entire Firefox build process:
Not anymore, but this commit URL below is already obsoleted by the following URLs:
Understood, working on it:
We could, I just do not have a primary word to pair it with. If you want it super simple, “Hardened” could be used.
Right, I do not have an answer for that at this point in time, I am still only thinking about how to get from point A to B. The entire repository is only based on the Firefox release/stable tag, not Beta or Nightly, so I have the entire upstream repository in a frozen snapshot until May 19th.
Yes, right from the source code itself:
Here are a bunch of relevant lines:
Lines 116-153: sed wrapper and sedhelper
Lines 155-168: rename_files
Lines 170-208: remove_if_block, sort_inner_list helpers
Lines 314-321: configure() - EME disable, healthreport
Lines 324-325: Custom privacy statement link
Lines 330-348: Activity stream anti-features (sed lines)
Lines 350-385: Top sites JSON replacement with here-doc
Lines 391: Remote settings server blanked
Lines 400-413: Search DDG modifications
Lines 415: process-json-files.py (Python processing)
Lines 419-435: Mobile confvars sh modification
Lines 451-459: Branding files replacement
Lines 461: Disable preprocessor branding flag
Lines 468-470: remove_if_block_in_file for bookmarks
Lines 472-476: Legal pages rebranding
Lines 496-544: apply_batch_branding - massive sed
Lines 546-549: Fingerprinting resistance disabled
Lines 551-553: User agent kept as Firefox
Lines 557-560: Migrator scripts
Lines 562-566: Cargo.toml/Cargo.lock fixes
Lines 568-572: Sort inner list fixes
Lines 580-585: Final confvars and profile icecat.js
And here is where FlawlessFox/BaseSecure (tenative name) and GNU IceCat stand now:
Sure, I will keep the tenative name for now, but remain open to any profound inspirations.
No problem, that is still the only plan. Scrutiny is fine by me, I already constantly do it internally.
A browser project requires advanced or expert knowledge in the programming languages it’s written in. Otherwise, if bugs or security issues are reported, there is no human who can distinguish between AI hallucinations and real issues. It also doesn’t allow for proactive self-auditing and bug fixing.
The problem with pure AI without human programmer oversight is also that it can introduce security issues or even malicious backdoors.
I don’t consider hetzner self-hosted. It’s just a different cloud provider.
It does not, my browser project is more closer to a scaled-up Arkenfox than a hard-forked Firefox, of which the latter is not within any feasible plan nor scope against my resources. Here is a summary of Arkenfox v144 today:
345 preferences, including 28 parrot preferences used for syntax checking
Otherwise, 317 preferences, no duplicates
My browser project is only focusing on the human-readable information, with the most notable difference being that I will be manually auditing far more than 317 preferences:
This preference dump file of 5,578 preferences and 119 policies is just the start, because the scanner is unable to detect C++/Rust source code preferences at the moment. Despite what appears to be an enormous number, this is all ultimately feasible because regressions are limited in impact and scope, and every preference manually audited now, on average, is a positive investment towards not modifying it again later against any future Firefox release. I am reusing the same logic and reasoning that @Thorin is using with Arkenfox, but for a complete, comprehensive, and curated map of every layer, not just user.js.
Before I continue on, it is also important to understand the power dynamic at play upstream, against me alone downstream:
Mozilla has access to Claude Mythos Preview
I do not
My browser project is ambitious, but pragmatic. Instead of “just” 317 preferences, I want access to every option and preference, even implied ones, and if there are any preferences without hooks or toggles, I can force access to them using surgical source transform patches. However, I am not going to reach for the stars and rewrite swathes of Firefox source code itself. Instead, I will be leaving that for Mozilla to deal with upstream at every Firefox release. Firefox 150, which is what FlawlessFox/BaseSecure (tenative name) are currently based on, is the result of Mozilla using Claude Mythos Preview, finding 271 bugs, and patching them:
My position in this downstream project is very clear. I only manually audit options and preferences, not code itself. I cannot claim to understand C++/Rust, but both of us, and more than just us, can claim to understand network.dns.disablePrefetch=true means DNS queries are not prefetched, instead they must be explicitly fetched by the user. If you can imagine reading a preference like that over 5,000 times, with minor variations, then you can understand how someone like me, with zero C++/Rust knowledge, can achieve manually auditing Mozilla’s build options and runtime preferences against every Firefox release, now and in the future.
Fair point, but not a fair argument. If I had to interpret your statement towards its logical conclusion, then I would need to have my own datacentre with myself as its sole tenant, have my own dark fibre network, become my own ISP, have my own AS number, handle my own BGP routing, and have separate root servers, minimum. Instead, it is more productive to flip the interpretation on its head, back to my previous statements:
Using Hetzner is better than using AWS, Azure, Cloudflare, GitHub, and other Big Tech infrastructure
I am managing the entire infrastructure otherwise
If I chose to continue seeing every flaw about either of ourselves and/or our situations, then I would have not bothered working towards any solution at all and permanently lurked in the shadows, praying for someone with ample resources and a generous character to come forward, getting everything perfectly done right the first time without any of our inputs. Instead, I am choosing to challenge myself and Mozilla to strive for a better today, regardless of resources, because I understand that I need to become the change I want to see in the world now, not later. Waiting around for Mozilla to actually be on our side, to seriously start considering using OpenPGP to resign 20+ years of code commits and towards strict compliance with the Kicksecure Digital Signature Policy is a fantasy that will ultimately get us both nowhere. In contrast, I am open to accommodating everything Kicksecure needs and/or prefers, as long as it is achievable and realistic without significant external financial support, and I will certainly endeavour to put in the time and work to realize this project’s full potential.
This has been a great discussion so far, but I have important updates:
FlawlessFox and BaseSecure (tenative name) for Linux have been successfully built, so here is what is left short-term:
This is a bit speculative, but if you decide to want your browser on Android later, then my agenda now will have already covered it against Kicksecure’s Digital Signature Policy. Also, the way I am working now, I am more likely to create a name for your browser and the Kicksecure Forum topic as the very last step on the entire roadmap, since I care more about getting my agenda and roadmap done first.
There’s no need for that. How at least Kicksecure, Qubes (and many others) are doing it is distrusting the infrastructure.
Hardware is trusted (unfortunately, unavoidably);
cryptographic signing keys stay local on our own computers only;
source code stays local where only we have write access and review every merge request;
binary builds are created on our own local computers.
third-party software is digital signature verified or reviewed before execution.
With that we have a chain of trust where no malicious server company staff can infect our source code or binaries. That’s very realistic, has been accomplished and does not require a datacentre, dark fibre network, own ISP, etc.
The policy is elaborate but I am just spelling out what “goes without saying” for many other projects. Kicksecure, Qubes, all merge commits are signed. Debian requires each Debian Maintainer upload to Debian to be signed. Many other projects have similar policies or act in similar ways.
DRM/EME disabled at compile time (–disable-eme), telemetry vars empty in confvars