Re: Enabled CRLite in Nightly

[J.C. Jones]

About 10 times a year, the update will be a new filter, which is going to
be about 5-6 MB, which might be more an issue.

Also, CRLite depends on the metadata for Intermediate Preloading, which is
several megabytes of certificates -- but those change very, very rarely, so
once populated they won't be downloaded again.

Perhaps we should go ahead and experiment with these two features in Fenix
Nightly.

J.C.

On Tue, Nov 17, 2020 at 12:19 AM Henri Sivonen  wrote:

> On Fri, Nov 13, 2020 at 6:19 AM J.C. Jones  wrote:
> > Not yet, no. Neither this nor Intermediate Preloading (which CRLite
> depends
> > on) are enabled in Fenix yet, as we have outstanding bugs about "only
> > download this stuff when on WiFi + Power" and "that, but configurable."
>
> If the delta updates are averaging 66 KB, do we really need to avoid
> the updates over cellular data even when that's assumed to be metered?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabled CRLite in Nightly

[Henri Sivonen]

On Fri, Nov 13, 2020 at 6:19 AM J.C. Jones  wrote:
> Not yet, no. Neither this nor Intermediate Preloading (which CRLite depends
> on) are enabled in Fenix yet, as we have outstanding bugs about "only
> download this stuff when on WiFi + Power" and "that, but configurable."

If the delta updates are averaging 66 KB, do we really need to avoid
the updates over cellular data even when that's assumed to be metered?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabled CRLite in Nightly

[J.C. Jones]

Aha, I knew I left something out.

Not yet, no. Neither this nor Intermediate Preloading (which CRLite depends
on) are enabled in Fenix yet, as we have outstanding bugs about "only
download this stuff when on WiFi + Power" and "that, but configurable."

But yes, both CRLite and Intermediate Preloading will be, one day, a boon
to the Fenix architecture, too.

J.C.

On Thu, Nov 12, 2020 at 4:30 PM asf...@mozilla.com 
wrote:

> 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  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  (with
> another
> > > post coming later this month), there’s additional information at
> Github
> > > , and for the Gecko-side, a
> meta-bug
> > > .
> > >
> > > 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 
> 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=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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabled CRLite in Nightly

[asf...@mozilla.com]

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  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  (with another 
> > post coming later this month), there’s additional information at Github 
> > , and for the Gecko-side, a meta-bug 
> > . 
> > 
> > We’ve been collecting telemetry on how much CRLite can speed up first TLS 
> > connections 
> > 
> >  
> > 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  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 
> > 
> >  
> > . 
> > 
> > - 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

Re: Enabled CRLite in Nightly

[Martin Thomson]

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  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  (with another
> post coming later this month), there’s additional information at Github
> , and for the Gecko-side, a meta-bug
> .
>
> We’ve been collecting telemetry on how much CRLite can speed up first TLS
> connections
> 
> 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  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
> 
> .
>
> - J.C. on behalf of Mozilla Crypto Engineering
> ___
> dev-platform mailing list
> dev-platform@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

Enabled CRLite in Nightly

[J.C. Jones]

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  (with another
post coming later this month), there’s additional information at Github
, and for the Gecko-side, a meta-bug
.

We’ve been collecting telemetry on how much CRLite can speed up first TLS
connections

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  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

.

- J.C. on behalf of Mozilla Crypto Engineering
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform