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: A new testing policy for code landing in mozilla-central

[Brian Grinstead]

Hi Jeff,
Thanks to help from Marco Castelluccio we now have an artifact in taskcluster 
that has metadata about all commits that land in m-c, which I've used to gather 
this data. We're still working on tooling to better understand patterns with 
different types of bugs & patches, but I'm happy to share what we already have.

Here's a spreadsheet showing weekly data since September: 
https://docs.google.com/spreadsheets/d/1xpm7V-zHCB3nyENdoVkG2ViT5iyg940SIpobY1fzR2g/edit.

A few notes:

* "none" is when a patch is reviewed/landed without a tag being applied. I've 
been hoping this would naturally get down to 0 as people get used to the policy 
and from the notifications we added in phabrictor. It dropped quickly to ~10% 
but is hovering right now. I've spoken with the Lando team about changing our 
warning checkbox into a hard blocker to enforce this.
* "unknown" counts revisions that don't have an accessible phabricator 
revision. This is mostly automated commits like wpt-sync (for example 
https://hg.mozilla.org/mozilla-central/rev/19b1604e8c8e) but also includes 
revisions with restricted permissions that aren't able to be loaded during 
generation time. For the sake of reporting I think these can be pretty much 
ignored.
* From most common to least common we see: “unchanged”, “approved”, “other”, 
“elsewhere”, “ui”. This has remained pretty stable across weeks. I’m not 
surprised that “unchanged” is common since it’s a bit overloaded - covering 
both (a) code that don’t ship to users and (b) code that’s being modified but 
keeping the same functionality.

Finally, I’m happy to hear feedback about how people think this has been going 
from a reviewer/author standpoint. Most of the feedback has been around 
ambiguity with “unchanged”. For example when “unchanged” versus “approved” 
should be applied when touching only tests: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1672439. Or if we should somehow 
split up “unchanged” to differentiate between code that already has tests and 
code that doesn’t. #testing-policy is a good channel for that discussion if you 
are interested in the topic.

Thanks,
Brian

> On Nov 12, 2020, at 8:21 AM, Jeff Muizelaar  wrote:
> 
> Brian,
> 
> Now that we've been doing this for a while, do we have any aggregated
> data on the testing tags? i.e. how often are we adding tests vs not.
> 
> -Jeff
> 
> On Tue, Sep 15, 2020 at 11:03 AM Brian Grinstead  
> wrote:
>> 
>> (This is a crosspost from firefox-dev)
>> 
>> Hi all,
>> 
>> We’re rolling out a change to the review process to put more focus on 
>> automated testing. This will affect you if you review code that lands in 
>> mozilla-central.
>> 
>> ## TLDR
>> 
>> Reviewers will now need to add a testing Project Tag in Phabricator when 
>> Accepting a revision. This can be done with the “Add Action” → “Change 
>> Project Tags” UI in Phabricator. There's a screenshot of this UI at 
>> https://groups.google.com/g/firefox-dev/c/IlHNKOKknwU/m/zl6cOlT2AgAJ.
>> 
>> We’ve been piloting the policy for a few weeks with positive feedback from 
>> reviewers. Still, there may be some rough edges as we roll this out more 
>> widely. I’d like to hear about those, so please contact me directly or in 
>> the #testing-policy channel in Slack / Matrix if you have feedback or 
>> questions about how the policy should apply to a particular review.
>> 
>> We’re working on ways to make this more convenient in the UI and to prevent 
>> landing code without a tag in Lando. In the meantime if you'd like a 
>> reminder to add the tag while reviewing code, Nicolas Chevobbe has built a 
>> WebExtension that automatically opens up the Project Tags UI when 
>> appropriate at https://github.com/nchevobbe/phab-test-policy.
>> 
>> ## Why?
>> 
>> Automated tests in Firefox and Gecko reduce risk and allow us to quickly and 
>> confidently improve our products.
>> 
>> While there’s a general understanding that changes should have tests, this 
>> hasn’t been tracked or enforced consistently. We think defining an explicit 
>> policy for including automated tests with code changes will help to achieve 
>> those goals.
>> 
>> Also, we’ll be able to better understand exactly why and when tests aren’t 
>> being added. This can help to highlight components that need new testing 
>> capabilities or technical refactoring, and features that require increased 
>> manual testing.
>> 
>> There are of course trade-offs to enforcing a testing policy. Tests take 
>> time to write, maintain, and run which can slow down day-to-day development. 
>> And given the complexity of a modern web browser, some components are 
>> impractical to test today (for example, components that interact with 
>> external hardware and software).
>> 
>> The policy below hopes to mitigate those by using a lightweight enforcement 
>> mechanism and the ability to exempt changes at the discretion of the code 
>> reviewer.
>> 
>> ## Policy (This text is also located at 
>> 

Re: A new testing policy for code landing in mozilla-central

[Jeff Muizelaar]

Brian,

Now that we've been doing this for a while, do we have any aggregated
data on the testing tags? i.e. how often are we adding tests vs not.

-Jeff

On Tue, Sep 15, 2020 at 11:03 AM Brian Grinstead  wrote:
>
> (This is a crosspost from firefox-dev)
>
> Hi all,
>
> We’re rolling out a change to the review process to put more focus on 
> automated testing. This will affect you if you review code that lands in 
> mozilla-central.
>
> ## TLDR
>
> Reviewers will now need to add a testing Project Tag in Phabricator when 
> Accepting a revision. This can be done with the “Add Action” → “Change 
> Project Tags” UI in Phabricator. There's a screenshot of this UI at 
> https://groups.google.com/g/firefox-dev/c/IlHNKOKknwU/m/zl6cOlT2AgAJ.
>
> We’ve been piloting the policy for a few weeks with positive feedback from 
> reviewers. Still, there may be some rough edges as we roll this out more 
> widely. I’d like to hear about those, so please contact me directly or in the 
> #testing-policy channel in Slack / Matrix if you have feedback or questions 
> about how the policy should apply to a particular review.
>
> We’re working on ways to make this more convenient in the UI and to prevent 
> landing code without a tag in Lando. In the meantime if you'd like a reminder 
> to add the tag while reviewing code, Nicolas Chevobbe has built a 
> WebExtension that automatically opens up the Project Tags UI when appropriate 
> at https://github.com/nchevobbe/phab-test-policy.
>
> ## Why?
>
> Automated tests in Firefox and Gecko reduce risk and allow us to quickly and 
> confidently improve our products.
>
> While there’s a general understanding that changes should have tests, this 
> hasn’t been tracked or enforced consistently. We think defining an explicit 
> policy for including automated tests with code changes will help to achieve 
> those goals.
>
> Also, we’ll be able to better understand exactly why and when tests aren’t 
> being added. This can help to highlight components that need new testing 
> capabilities or technical refactoring, and features that require increased 
> manual testing.
>
> There are of course trade-offs to enforcing a testing policy. Tests take time 
> to write, maintain, and run which can slow down day-to-day development. And 
> given the complexity of a modern web browser, some components are impractical 
> to test today (for example, components that interact with external hardware 
> and software).
>
> The policy below hopes to mitigate those by using a lightweight enforcement 
> mechanism and the ability to exempt changes at the discretion of the code 
> reviewer.
>
> ## Policy (This text is also located at 
> https://firefox-source-docs.mozilla.org/testing/testing-policy/)
>
> Everything that lands in mozilla-central includes automated tests by default. 
> Every commit has tests that cover every major piece of functionality and 
> expected input conditions.
>
> One of the following Project Tags must be applied in Phabricator before 
> landing, at the discretion of the reviewer:
>
> * `testing-approved` if it has sufficient automated test coverage.
> * One of `testing-exception-*` if not. After speaking with many teams across 
> the project we’ve identified the most common exceptions, which are detailed 
> below.
>
> ### Exceptions
>
> * testing-exception-unchanged: Commits that don’t change behavior for end 
> users. For example:
>   * Refactors, mechanical changes, and deleting dead code as long as they 
> aren’t meaningfully changing or removing any existing tests. Authors should 
> consider checking for and adding missing test coverage in a separate commit 
> before a refactor.
>   * Code that doesn’t ship to users (for example: documentation, build 
> scripts and manifest files, mach commands). Effort should be made to test 
> these when regressions are likely to cause bustage or confusion for 
> developers, but it’s left to the discretion of the reviewer.
> * testing-exception-ui: Commits that change UI styling, images, or localized 
> strings. While we have end-to-end automated tests that ensure the frontend 
> isn’t totally broken, and screenshot-based tracking of changes over time, we 
> currently rely only on manual testing and bug reports to surface style 
> regressions.
> * testing-exception-elsewhere: Commits where tests exist but are somewhere 
> else. This requires a comment from the reviewer explaining where the tests 
> are. For example:
>   * In another commit in the Stack.
>   * In a followup bug.
>   * In an external repository for third party code.
>   * When following the [Security Bug Approval 
> Process](https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html)
>  tests are usually landed later, but should be written and reviewed at the 
> same time as the commit.
> * testing-exception-other: Commits where none of the defined exceptions above 
> apply but it should still be landed. This should be scrutinized by the 
> reviewer before using 

Intent to unship: Large-Allocation header

[Nika Layzell]

We intend to unship the Large-Allocation header. It was never implemented
by other browsers, nor was it standardized. It was primarily useful to get
a document in a new process on 32-bit systems so it would have sufficient
memory for certain WebAssembly or asm.js applications.


A partner we know to have used the header has indicated they no longer rely
on it.


Websites can adopt the Cross-Origin-Opener-Policy and
Cross-Origin-Embedder-Policy headers to achieve much the same effect
through the cross-origin isolated primitive.


Bug to remove: https://bugzilla.mozilla.org/show_bug.cgi?id=1598759
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform