Skip to content

headsup: I intend to relax some prefs #1707

@Thorin-Oakenpants

Description

@Thorin-Oakenpants

this will get rid of 4 3 (Ipv6 wasn't listed) of the common items in the wiki

speak if you want to


DRM - move to optional hardening

I have lived without DRM in my everyday main FF since we first disabled it. I do not stream any content (Netflix, Disney, Hulu etc). But I do read a lot, and some of that is news, and some of that news comes with video, and sometimes that shit won't work (not always because its DRM - I use a pretty hard uBO), and all I end up doing is flicking over to my nightly (which is default + uBO + sanitizing on close) and fucking loading it anyway.

I get that DRM is a propriety and closed source, but honestly, for our threat model, disabling it is just a PITA and massive overkill. If this is your issue, then use Tor Browser. And I'm sure I'm the exception not the norm re streaming, so I know I've said users could just use a secondary browser, but that's not always easy for some people if they want a second gecko, dealing with profiles and installs and running concurrently.

So heads up, this WILL be moved to optional hardening. Those who do not want DRM can easily add an override

/* 2022: disable all DRM content (EME: Encryption Media Extension)
 * Optionally hide the setting which also disables the DRM prompt
 * [SETUP-WEB] e.g. Netflix, Amazon Prime, Hulu, HBO, Disney+, Showtime, Starz, DirectTV
 * [SETTING] General>DRM Content>Play DRM-controlled content
 * [TEST] https://bitmovin.com/demos/drm
 * [1] https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-we-just-lost-web-what-we-learned-it-and-what-we-need-do-next ***/
user_pref("media.eme.enabled", false);
   // user_pref("browser.eme.ui.enabled", false);

referer.XOriginPolicy - make inactive move to optional hardening

I plan to relax this. I don't see any real benefit for value 1, it will unbreak fuck all IMO. So I am going to make the pref inactive. Those who want to harden can do so in their overrides. At the end of the day, most navigational "tracking" is harmless (i.e the same for everyone) and effectively blocking cross site referers just breaks "everything"

I am also going to remove any reference to Smart Referer, as I consider it abandoned. Plus it's not a good idea re CSRF see #1433 and for this reason I will not be recommending ANY referer extensions

Also, mask your IP, you dirty filthy animals

/* 1601: control when to send a cross-origin referer
 * 0=always (default), 1=only if base domains match, 2=only if hosts match
 * [SETUP-WEB] Breakage: older modems/routers and some sites e.g banks, vimeo, icloud, instagram
 * If "2" is too strict, then override to "0" and use Smart Referer extension (Strict mode + add exceptions) ***/
user_pref("network.http.referer.XOriginPolicy", 2);

keyword - make inactive move to optional opsec

Considering the default FF does not show the searchbar, the urlbar IS the searchbar. So disabling keyword is more of an obstacle than a help. I also think the chances you do a typo or leak a secret are slim to none (I think I've caught myself with about 2 in 10 years), and you would still leak that typo/secret if you used the searchbar and hit enter. And the advice "Override this if you trust and use a privacy respecting search engine" is a little weird - if users are that privacy conscious (e.g. I still use google in nightly because it gets me my results) then they would have already changed engines. In other words, users are going to use the search engine they want to, and we can't change that, so to dictate out advice for keyword based on their search engine is a bit on odd, kinda. Anyway, I don't see this as anything more than user hostile for our threat model - even TB doesn't bother, because usability matters.

once again, those who wish to override it, can do so

/* 0801: disable location bar using search
 * Don't leak URL typos to a search engine, give an error message instead
 * Examples: "secretplace,com", "secretplace/com", "secretplace com", "secret place.com"
 * [NOTE] This does not affect explicit user action such as using search buttons in the
 * dropdown, or using keyword search shortcuts you configure in options (e.g. "d" for DuckDuckGo)
 * [SETUP-CHROME] Override this if you trust and use a privacy respecting search engine ***/
user_pref("keyword.enabled", false);

IPv6: make inactive - move to optional hardening

This is only an issue IMO for those using a VPN. And VPN users should be using a system wide reputable VPN like e.g. Mullvad (full disclosure, Mullvad sponsors Tor Project, and I work with them both - in fact I will be at Mullvad headquarters for a week in late October). I'm not a VPN expert, so Mullvad is the only name I could think of that I know is reputable. I assume Mullvad covers IPv6 properly (IANAE on networking shit, that's the 🐟 ). I also wonder, and IANAE, is that if the VPN fell over, you would be leaking your real IP anyway, so big deal with the mac addy? rhetorical q, don't answer

I think this line sums it up "If you are not masking your IP, then this won't make much difference."

again, users can override

/* 0701: disable IPv6
SNIP
 * [1] https://www.internetsociety.org/tag/ipv6-security/ (Myths 2,4,5,6) ***/
user_pref("network.dns.disableIPv6", true);

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions