Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When v115 #1687

Closed
sh3ll4rpw opened this issue Jul 6, 2023 · 13 comments
Closed

When v115 #1687

sh3ll4rpw opened this issue Jul 6, 2023 · 13 comments

Comments

@sh3ll4rpw
Copy link

It's V115 already and arkenfox is still on v112. Being behind with version doesn't help against fingerprinting at all. What happened?

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Jul 6, 2023

Being behind with version doesn't help against fingerprinting at all

fingerprinting is not affected. We use RFP (which fools naive scripts at worst) and you get everything you need with each FF release. Besides, RFP has hardly changed in 4 years

arkenfox is still on v112

There was nothing to add in 113 (see #1674 and #1627) and no need to push a new release (I get it, the messaging is not there, but I expected to be on 114 by now). For 114 so far all I can see are a couple of deprecated prefs which we didn't use. But I am waiting on the diffs for 114 and now 115 from earthlng - IDK if or when they will ever come. The diffs help ensure we don't miss anything - but I do scan all (and read a lot of) the bugzillas per release (on an almost daily basis) = ~1k bugzillas per month

The fact is since the last ESR we have only added one two prefs that does anything

  • 114 likely just two deprecated which were inactive anyway - see v115 #1680
  • 113 nothing
  • 112 cosmetic
  • 111 added one inactive: alerts.useSystemBackend.windows.notificationserver.enabled
  • 110 cosmetic
  • 109 made two inactive and removed one
  • 108 added one active browser.urlbar.showSearchTerms.enabled
  • 107 made three inactive and remove one
  • 106 removed four (excluding the bulk of the personal section which was also removed)
  • 105 added one active: privacy.partition.always_partition_third_party_non_cookie_storage.exempt_sessionstorage which is now default false anyway
    • and removed three and made 4 inactive
  • 104 added one active: privacy.partition.always_partition_third_party_non_cookie_storage which is now default true anyway
    • and made eight inactive
  • 103 added one active: geo.provider.use_geoclue for linux
    • and made one inactive and deprecated two (and changed a couple due to sanitizing changes)

So to sum up ... in 11 releases we have added one two active prefs that flips the value (and that was 11 releases ago) - all the rest was cleaning up

to recap: https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain

Nothing of consequence (in the user.js) changes these days that will affect you in that time delay. Do not wait on arkenfox to update Firefox.


115 (and 114) will land when I'm ready - and so far I see nothing of consequence (deprecated prefs will just fail to do anything if used, so not super urgent). Meanwhile, waiting on diffs

@sh3ll4rpw
Copy link
Author

Ok so I was able to update to 114 all the time? If so, please let us know next time

@Thorin-Oakenpants
Copy link
Contributor

If so, please let us know next time

did you not read the wiki

to recap: https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain

Nothing of consequence (in the user.js) changes these days that will affect you in that time delay. Do not wait on arkenfox to update Firefox.

@Thorin-Oakenpants
Copy link
Contributor

PS: you should already be on 115 by now

@sh3ll4rpw
Copy link
Author

Thank you for your service

@ExceptionGit
Copy link

Nothing of consequence (in the user.js) changes these days that will affect you in that time delay. Do not wait on arkenfox to update Firefox.

Yes, do not wait, always do update, but..

  • 103 💣 geolocation enabled geoclue #1504
  • 113 💣🎉 non-disabled and forced pop-up ad https://news.ycombinator.com/item?id=36077360 (browser.vpn_promo.enabled=false)
  • 115 💣🎉💣 force disable extensions on some sites (extensions.quarantinedDomains.enabled) and clipboard leak (browser.tabs.searchclipboardfor.middleclick)
  • ??? force enable ''offline'' browser.translations with telemetry (browser.translations.enable)

If possible, please bump version and create releases even if there are no changes.

@Thorin-Oakenpants
Copy link
Contributor

not sure why you are listing

  • geoclue as something that was done on time and is a fallback (geo requires permission anyway)
  • browser.vpn_promo.enabled has nothing to do with this repo's objectives
  • extensions.quarantinedDomains.enabled as something that is this release cycle (FF115+) and currently ships with no domains. I will get into this when appropriate, but FF116 has a UI and I won't be disabling it - it's a security feature
  • browser.translations.enable is not enabled yet, and telemetry should be already covered under the master switch ( I will check when appropriate) - I'm not going to disable this either. The ability to download and translate locally is awesome, and Moz telemetry is not a bad thing - see explain telemetry better #1660

@esrk
Copy link

esrk commented Jul 8, 2023

currently ships with no domains

Not sure if this varies with usage/region, but my update shipped with some domains in the extensions.quarantinedDomains.list field. As I keep browser.safebrowsing.malware.enabled false at my end, I've turned this off as well.

@rusty-snake
Copy link
Contributor

The .list pref is updated at runtime. Setting extensions.quarantinedDomains.enabled=false sounds better (from the name, didn't looked at the code yet).

@Thorin-Oakenpants
Copy link
Contributor

sounds better

no it doesn't. This is a security feature - don't disable it

@rusty-snake
Copy link
Contributor

Of course it's not good to disable it. But playing with enabled/disabled prefs is usually better (but maybe still bad) than playing with list/url prefs.

@Thorin-Oakenpants
Copy link
Contributor

@rusty-snake oh right, yeah, use master switch prefs not runtimes :)

This has been under my watch for months, logged at Tor Project (by me), and discussed in depth in private with fxbrit. The issue is not one of trust or even removing user choice (we still have prefs, in FF116 we have a UI for exceptions or whatever) - the issue for Tor Browser is that they disable remote services, and so does LW - so the choice here is to ship with the set lists at build (same as they do for blocklists and other items, e.g. language packs for live language reload, etc).

the domain list is not regional, that makes no sense (locales don't control domain access)

and currently ships with no domains

my bad. I have seen the current list before, weeks ago (I think, maybe nightly testing or something) .. and it's been a little while since I looked at things in depth. I know it's runtime (remote services) - I was just going off some comments in some HN threads I perused a couple of days ago

@arkenfox arkenfox deleted a comment from mik0l Jul 8, 2023
@fxbrit
Copy link
Collaborator

fxbrit commented Jul 8, 2023

I took the liberty of deleting a comment that was pinging earthlng as it's bad netiquette

@arkenfox arkenfox locked as resolved and limited conversation to collaborators Jul 8, 2023
@earthlng earthlng unpinned this issue Jul 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

6 participants