That's great to hear! Does that include Firefox Nightly for Android too?
On Wednesday, November 11, 2020 at 4:15:17 PM UTC-8, Martin Thomson wrote: > Great news JC. > > I've been watching this with interest. It's one of those rare cases > where we get a win-win-win. Faster page loads, better security > through more reliable revocation information, and better privacy. > > It's taken a lot of effort, but it's definitely worth it. > On Thu, Nov 12, 2020 at 8:08 AM J.C. Jones <j...@mozilla.com> wrote: > > > > CRLite ships compressed revocation information for the public Web to > > Firefox users, four times a day. We have a blogpost series on CRLite at the > > Security Blog <https://blog.mozilla.org/security/tag/crlite/> (with another > > post coming later this month), there’s additional information at Github > > <https://github.com/mozilla/crlite>, and for the Gecko-side, a meta-bug > > <https://bugzilla.mozilla.org/show_bug.cgi?id=crlite>. > > > > We’ve been collecting telemetry on how much CRLite can speed up first TLS > > connections > > <https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/> > > > > all year. Since August, we’ve been publishing the datasets consistently > > four times per day, with “stashes” (delta updates) averaging about 66 kB. ( > > https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters > > > > ) > > > > If you’d like to poke around inside the filter data, see > > https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter > > > > Nightly is now preferring CRLite <https://github.com/mozilla/crlite> for > > revocation information, meaning fresh TLS connections will skip OCSP when > > CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2, > > “Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY > > telemetry: it’s mostly expected to speed up the outliers in the graph, > > since revocation checks get cached, and it is likely to have the largest > > effects for Firefox users with slower network connections. > > > > We don’t expect breakage from this change, as we’ve grown fairly confident > > in the dataset, but this is going to remain in Nightly for now. > > > > After this speed-up testing, our likely next step is to add telemetry to > > compare live OCSP results against CRLite’s results for outlier-accuracy > > (encountering revocations is rare, so care is needed). We’ll ultimately run > > both the accuracy and the speedup tests in early Beta as well. > > > > We’ll develop Release-path plans based on early Beta testing and telemetry. > > > > For more information, come see us in #crlite in Slack or > > #crlite:mozilla.org > > on Matrix > > <https://matrix.to/#/!zSwoVqWeXUHRiaIFvk:mozilla.org?via=mozilla.org&via=matrix.org> > > > > . > > > > - J.C. on behalf of Mozilla Crypto Engineering > > _______________________________________________ > > dev-platform mailing list > > dev-pl...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
