How do network traces of Fennec‑F‑Droid and IronFox differ when loading common web pages (what endpoints are contacted)?
Executive summary
Fennec‑F‑Droid and IronFox are both Firefox‑based Android browsers that position themselves as privacy‑oriented, but the available reporting does not include actual packet captures or enumerated network endpoints for either app, so any claim about exact endpoints contacted must be framed as inference rather than measured fact [1] [2]. Public discussion and project descriptions indicate Fennec‑F‑Droid is a Firefox build with many proprietary bits and telemetry removed, whereas IronFox is an explicit Mull fork aiming for a privacy‑centric stance—implying different default contacts (Mozilla services vs. a smaller set of fork‑maintainer endpoints), but definitive network traces are not published in the provided sources [1] [3] [2].
1. What the sources actually say about each browser’s network behaviour
Fennec‑F‑Droid is described on F‑Droid as a Firefox‑based browser that “allows the app to view information about network connections” and retains the Gecko engine while removing some proprietary pieces; that description implies the app retains standard browser network capabilities and may still have code paths that interact with network services unless explicitly disabled [1]. Community writeups and reviews portray Fennec as “close to Firefox” with telemetry stripped but not necessarily every automatic connection eliminated, and users are advised to check about:config settings to turn off crash or telemetry features—an implicit admission that default builds could reach Mozilla endpoints unless configured [3]. IronFox, by contrast, is presented in community forums as a Mull continuation fork that markets itself for privacy and aims to avoid upstream Mozilla telemetry, but the sources are discussion threads and project issue pages, not forensic traces [2] [4].
2. What endpoints one might expect to see and why—based on project lineage and user reports
Because Fennec is built from Firefox sources, typical endpoints that any Firefox derivative historically contacted include Mozilla update, telemetry, crash reporting, Safe Browsing, and add‑on update services; Fennec’s packaging and community comments suggest many of these have been removed or are configurable, but the F‑Droid metadata still shows network permissions, which enables such connections if present or reintroduced by configuration [1] [3]. Community remarks about having to “turn off Mozilla data collection during setup” for other forks suggest that some forks expose Mozilla data‑collection toggles during first run, implying the possibility of automatic calls to Mozilla domains unless users opt out [5]. IronFox’s Mull heritage suggests it intentionally curtails those Mozilla endpoints and may instead call a narrower set of endpoints: the fork’s update/check endpoints (GitLab or a custom repo), any third‑party blocklist/update hosts it bundles, and standard web hostnames when loading pages; however, the public issue tracker and forum posts do not publish a host list or capture [2] [4].
3. Practical difference users should expect in network traces
In practice, based solely on the documented project aims and community reports, a network trace of Fennec‑F‑Droid loading common web pages might show the usual web server connections (origin sites, CDNs, ad/tracker domains depending on blocking rules) plus potentially calls to Mozilla services unless telemetry/crash settings are disabled, whereas IronFox would likely minimize or avoid Mozilla‑specific service calls and instead only contact origin sites, CDNs, and whatever update/blocklist servers the fork uses [1] [3] [2]. This is inferential: none of the provided sources contains recorded PCAPs or endpoint enumerations to confirm which exact domains are contacted by default [1] [2].
4. What is missing and how to verify concretely
The reporting lacks empirical network captures, host lists, or lab measurements; community threads, F‑Droid metadata and project repos establish intent and permissions but not real network traces [1] [2] [4]. To know precisely what endpoints each browser contacts when loading common pages requires controlled testing: enable packet capture or DNS logging on a test device, load identical pages in each browser with default settings, and compare contacted hostnames (the sources recommend checking build/config and about:config for telemetry toggles but do not supply results) [3].
5. Bottom line and practical advice
The likely difference is not a change in the ordinary set of web endpoints (sites, CDNs, trackers) but in ancillary contacts: Fennec‑F‑Droid may retain or expose Mozilla‑related service calls unless explicitly disabled by configuration, while IronFox aims to reduce or replace those with its own update/config endpoints, though exact domains are not listed in the reporting; users seeking certainty must perform their own network captures or consult a verified trace because the cited community and project sources do not publish packet‑level evidence [1] [2] [4].