updating (app, extensions, ext cache) is not a privacy issue
- if you're willing to use Firefox but not trust updating, then I have two bricks to sell you: users who wish to disable it (to check changes first etc) and update in a timely manner, then that is on them - including any prompt fatigue
- same goes for extensions: the end-user installed them (and arkenfox only recommends a very select few) - the onus is on the end-user
The remaining ones I will deal with later
auto-updating is not a security nor a privacy risk, by default it should be enabled and it's on end-users if they want to disable it - does not affect windows users
- they require SWers which are already blocked by virtue of permissions being session only
- also remove "dom.push.userAgentID" as this means prefsCleaner resets it and would wipe user's subscriptions
- not adding "dom.push.userAgentID" to the cleanup script for the same reason
currently 3rd party service workers are blocked in FF95 when dFPI is enabled (which this version has should anyone update to 96-alpha)
- but I get an error even on first party - https://arkenfox.github.io/TZP/tzp.html#storage
- I get : service worker | test : enabled | failed: SecurityError
in FF96+ service workers they are covered by dFPI
- see https://bugzilla.mozilla.org/show_bug.cgi?id=1731999
we've never used these
- service workers are disabled (or soon to be covered by dFPI when enabled) and sanitizing is already done (or will be done via enhanced cookie cleaning)
- storage API, storage access API: we sanitize on close, and sites are isolated by eTLD+1
- in v94 we switched to cookies lifetime as session, so users could use site exceptions to retain selected cookies (to stay logged in one assumes)
- that mean not deleting all cookies on shutdown
- but some login methods/types require more than cookies and also need the "site data" part of "cookies + site data" - that's the offlineApps part
- note: all site data (and cookies) is still cleared on close except site exceptions
FYI: https://bugzilla.mozilla.org/1738372
There is a small privacy issue with shoulder surfers, but in reality, this just needs to happen IMO
- we already prompt where to save, but even if we didn't, we also know we clicked or initiated a download
- unless it's a drive by or user-gesture trickery - which is why we prompt
- the download icon is shown (if hidden) and the throbber/accent color go to work
- users can always click the icon to show entries (and open folder etc)
- this maintains the current behavior in FF94
anti-fingerprinting doesn't fit here: it's not a major component or priority of this user.js, and only a few prefs outside RFP (as a robust built-in browser solution that defeats naive scripts) have anything to do with it
move all sanitizing on exit prefs into 2800
switch to cookie lifetime as session
- now users can utilize exceptions (as allow)
- session cookies still block service workers (which we disable anyway)
- we still block 3rd party cookies (until we move to dFPI)
- we still have defense in depth for 3rd party cookies with 2803
- we still bulk sanitize offlineApps on exit: localStorage, service worker cache, QuotaManager (IndexedDB, asm-cache)
- i.e you get to keep the cookies only IF you add an exception
add `privacy.clearsitedata.cache.enabled`
The point was that google have said (stated in policy, but fuck knows where that is located these days) that it is anonymized and not used for tracking. It's an API used by **_4 billion devices_** - the API has privacy policies for use. If a whistleblower or someone else found out that google was using this to enhance their user profiling, then all hell would break loose. And they don't even need this to fuel their ad revenue. It is provided, gratis, to the web to help ensure security - they wouldn't dare taint it and get it caught up in a privacy scandal involving **+4 billion devices_**. And in all this time (since 2007), there has been no such whistleblower or proof it is used to track or announcements by google of changes to the contrary.
Anyway, a quick search brings up
- Here is their policy - https://www.google.com/intl/en_us/privacy/browsing.html - it's empty and points to
- https://www.google.com/intl/en/chrome/privacy/
- and if you scroll down to "Safe Browsing practices" it doesn't say anything about privacy policies for the API itself (or the owner of the API) - it just spells out what happens in chrome
- I'm not going to bother to look any further and find a history of policy changes
Anyway, this is Firefox and hashes are part hashes bundled with other real hashes - and we turned off real time binary checks. So this line can fuck the fuck off. It was meant to reassure those who want the security of real-time binary checks, that privacy "shouldn't" be an issue, but I'm not going to expand on it
