sticky: items to investigate keep an eye on about user.js

I'm wondering about four about:config settings available on all Firefox versions and related to:

// 2404: disable JS storing data permanently
user_pref("dom.indexedDB.enabled", false);

If, when dom.indexedDB.enabled is set to true there are four related settings:

user_pref("dom.indexedDB.experimental", false); // Default=false 
user_pref("dom.indexedDB.logging.details", false); // Default=true
user_pref("dom.indexedDB.logging.enabled", false); // Default=true
user_pref("dom.indexedDB.logging.profiler-marks", false); // Default=false

As you see I've set second and third to false when their default is true

What do you think of these two default values?
When set to true (default) does it mean that, given dom.indexedDB.enabled is set to true, given a site uses dom.indexedDB it would be possible for that site to keep the user's login credentials in his dedicated storage folder?
If so, do you believe it is pertinent to set these settings to false as I do or is this insignificant?

[Atavic]

@earthlng pyllyukko/user.js#263 (comment)

[earthlng]

Firefox currently continues the connection

then why am I getting a hard fail? Can you test this yourself please

[Atavic]

OCSP Expect-Staple is @ScottHelme own proposal.

Security vs Privacy: schomery/privacy-settings#40 (comment)

[ScottHelme]

You can still set hard fail revocation checking in Firefox, have you perhaps configured this at any point? Go to about:config and check security.OCSP.require is set to false.

Depending on your build the OCSP request will currently timeout after 3s or 1s and load the page without completing the revocation check.

[ScottHelme]

In honesty I think we could probably get a long way there with sites supporting stapling. The OCSP response is valid for 7 days so a site only needs to refresh it every 24 hours and they can weather a 6 day outage of the responder.

On top of that, almost no CA actually runs their own responders without fronting them with a CDN. The OCSP request is just a HTTP GET and large providers like Akamai will front up OCSP responders and serve cached responses on behalf of the CA. I could understand historic concerns where the CA didn't have CDN support but it's 2017, I think we should be able to do OCSP properly.

[earthlng]

have you perhaps configured this at any point?

No, security.OCSP.require is and was set to false. I've tested 2 FF's, ESR52.2.1 + FF54.0.1, and I can't get your testsite to soft fail. I've also tried 2 different ways of blocking the OCSP server - HOSTS + uBlock Origin - same result.
It's actually the same behavior when security.OCSP.enabled is set to 0 (=disabled) ie

A required TLS feature is missing. Error code: MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

... no soft fail. IDK why. Maybe FF just doesn't soft fail atm?

but it's 2017, I think we should be able to do OCSP properly.

Would be nice. ATM IMHO OCSP without stapling seems worse than useless because of the privacy concerns. I would just set security.OCSP.enabled to 0 but I fear that would also disable OCSP stapling.

[ScottHelme]

Ah... wait. I just had a thought and this is a serious derp. The certificate has the OCSP Must-Staple flag set and I'm not stapling to for an online OCSP check...

https://report-uri.io/home/certificate_analyser/https%3A%2F%2Frevoked.scotthelme.co.uk

Yeah... I'm going to go fix this now.

[ScottHelme]

Ok I renewed without the OCSP Must-Staple flag and revoked, we're good :)

[ScottHelme]

It'd be awesome if you could use the link to my site 👍

[earthlng]

Ok I renewed without the OCSP Must-Staple flag and revoked, we're good :)

Thanks, now it works as expected ie soft-fail

@Thorin-Oakenpants what do you think, should we enable hard-fail by setting OSCP.require=true? IMO yes

[earthlng]

security.pki.certificate_transparency.mode

This is the meta ticket for Certificate Transparency

Btw atm they disabled it again because certificate transparency signature verifications negatively impact TLS handshake performance

Re-enable Certificate Transparency telemetry collection - NEW Unassigned

[earthlng]

@Thorin-Oakenpants totally OT but holy shit, just in case you missed the details of this as I did until today: (and it kinda fits in this issue of "to investigate / keep an eye on")

https://www.lgraham.senate.gov/public/_cache/files/4766f54d-d433-4055-9f3d-c94f97eeb1c0/testimony-of-sean-edgett-acting-general-counsel-twitter.pdf

With respect to #DNCLeak, approximately 23,000 users posted around 140,000 unique
Tweets with that hashtag in the relevant period. Of those Tweets, roughly 2% were from
potentially Russian-linked accounts. As noted above, our automated systems at the time
detected, labeled, and hid just under half (48%) of all the original Tweets with #DNCLeak. Of
the total Tweets with the hashtag, 0.84% were hidden and also originated from accounts that met
at least one of the criteria for a Russian-linked account.

TWITTER censored 48% of tweets with #DNCLeak and only 0.84% of those were from potentially Russian-linked accounts - WTF?! Thank god RT now needs to register as agents of a foreign country 🤦‍♂️
... and the bitch still lost - oh the irony xD

oh and that's not all:

In the two months preceding the election, around 57,000 users posted approximately 426,000 unique Tweets containing variations of the #PodestaEmails hashtag. Approximately one quarter (25%) of those Tweets received internal tags from our automation detection systems that hid them from searches.

[earthlng]

I started working on a NoRedirect replacement but there's no good way to stop refreshes yet.

[Atavic]

If true, it gives a pop-up like this: This web page is being redirected to a new location. Would you like to resend the form data you have typed to the new location?

It's companion entry is: accessibility.blockautorefresh

[Atavic]

About

/* 2421: disable Ion and baseline JIT to help harden JS against exploits such as CVE-2015-0817

...there are more recent exploits, listed here.

Source follows:
https://rh0dev.github.io/blog/2017/the-return-of-the-jit/

[Atavic]

This is bad:

Send telemetry events for each action on an extension

I posted in this issue, although I suggest to create a sticky for telemetry issues only.

[earthlng]

I suggest to create a sticky for telemetry issues only.

we have telemetry disabled in more ways than it's probably necessary so telemetry is really not an issue and we don't need a sticky for that.

[Atavic]

Regarding Certificates, there's a VPN Guide linked here where it says to remove the trust on the certificates you don't use.

[Atavic]

Entry:

plugin.disable_full_page_plugin_for_types

Value:

application/pdf,application/doc,application/xls,application/bat,application/ppt,application/mdb,application/mde,application/fdf,application/xfdf,application/lsl,application/lso,appliation/lss,application/iqy,application/rqy,application/xlk,application/pot,application/pps,application/dot,application/wbk,application/ps,application/eps,application/wch,application/wcm,application/wbi,application/wb1,application/wb3,application/rtf,application/wch,application/wcm,application/ad,application/adp,application/xlt,application/dos,application/wks

Source listed here

[earthlng]

nvm, I should have read the patch more carefully. The pref is still there and it's no longer hidden either. sorry about that

[Thorin-Oakenpants]

closing this locked topic - it's only used by myself, and I don't need it anymore