List of Hosting Providers That Accept Cryptocurrencies or Cash as Payment

General Tor and Anonymity Talk
50

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:

  1. Base Browser
  2. Mullvad Browser
  3. 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:

  1. Building Firefox requires selecting or omitting compile arguments, along with values, typically Boolean(-like) in nature, or an empty string
  2. 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):

  '--enable-eme':
    name: '--enable-eme'
    flag: '--enable-eme'
    type: enable
    default: eme_default
    help: '{Enable|Disable} support for Encrypted Media Extensions'
    source_file: toolkit/moz.configure
    platforms: [android, linux, macos, windows]
    valid_values:
      type: boolean
      registry_values: [enable, disable, default, skip]
      mozconfig_syntax: [ac_add_options --enable-eme, ac_add_options --disable-eme]
    upstream_default: 'yes'
    default_note: EME/DRM compiled in by default — Widevine CDM downloadable at runtime
    status: reviewed
    flawlessfox: disable
    flawlessfox_note: → disabled (explicit)
    basesecure: disable
    basesecure_note: → disabled (explicit)
    review_notes: Disabled at compile-time
    nargs: +
    choices: [<dynamic>]
    settable: mozconfig

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:

  1. Mozilla releases a new Firefox version
  2. I manually merge the new tagged version
  3. Then two situations:
    1. No compile options changed between versions, remaining CI/CD pipeline passes automatically without manual intervention (expected)
    2. 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.

And if you want a concise, technical overview:

Observation layers:  mitmproxy │ eBPF │ inotify │ pref monitor │ Marionette
                          ↕
Threat taxonomies:   LINDDUN (7 privacy categories)
                     STRIDE  (6 security categories)
                          ↕
Test suites:         Baseline → Category → Regression → Compliance → Adversarial
                          ↕
Metrics:             Asymptotic discovery curves per category (13 total)
                     Differential completeness between releases

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:

  1. Scan every parameter toggled by any preference in the source code
  2. Dump/merge it into options-registry.yml (complete) and prefs-registry.yml (about:config, no C++/Rust source code yet)
  3. Map all dependencies between and within all layers
  4. Audit all of them manually
  5. 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:

Note:

2 Likes