mirror of
https://github.com/daijro/camoufox.git
synced 2026-09-12 00:00:48 +00:00
Jake WriterandClaude Opus 5
2b08ae0c51
Two one-line pref changes in settings/camoufox.cfg. 1. browser.sessionhistory.max_entries: 0 -> 50 (F1, #326, #196) Setting this to 0 was grouped under "turn off bfcache", but it is not what disables bfcache -- fission.bfcacheInParent=false (line 487) and max_total_viewers=0 do that. What max_entries=0 does is leave the session history with no entries at all, so window.history.length reports 0. The HTML spec guarantees a browsing context always retains at least its current entry, so history.length >= 1 in every real browser. 0 is therefore a zero-false-positive automation tell that any page script can read with no timing and no heuristics. It also makes page.go_back() a silent no-op. Measured on the shipped 152.0.4-beta.28 binary, three navigations: entries=0, viewers=0 history.length=0 go_back: no-op bfcache: unused entries=50, viewers=0 history.length=3 go_back: works bfcache: unused entries=50, viewers=-1 history.length=3 go_back: works bfcache: unused So 50 (Firefox's stock default) restores correct history semantics and working back-navigation without bfcache ever serving a page. This is also why the existing `enable_cache=True` workaround for #196 works: CACHE_PREFS in utils.py already resets max_entries to 10. 2. privacy.partition.network_state: false -> true (#577) This is Firefox's stock default and the documented mitigation for the favicon-cache supercookie; disabling it also un-partitions the HTTP cache, connection pool, DNS cache and HSTS store. Being straight about the evidence: on FF152 I could NOT demonstrate an open channel. With a working same-site control (cached: 1 fetch), a shared third-party subresource loaded from two different top-level sites produced 2 fetches and 2 distinct TCP sockets with the pref BOTH false and true -- the HTTP cache and the connection pool are already partitioned either way. So this is a stock-default/consistency change and defense-in-depth for the channels the pref still governs (DNS, HSTS, TLS session resumption, favicon cache) that I have no probe for -- not a demonstrated leak fix. It measured as behaviour-neutral in both directions, so the performance risk that presumably motivated disabling it looks negligible on FF152. Worth re-checking against the build-tester score. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>