Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

516 views
Skip to first unread message

Sylvestre Ledru

unread,
Dec 20, 2017, 10:42:50 AM12/20/17
to dev-pl...@lists.mozilla.org, mobile-firefox-dev
Hello,

Earlier today, we announced on the enterprise ML several changes to ESR.

First, as Dave Camp mentioned during the Firefox All Hands, we are started some developments to improve
our support for enterprise users.
More information can be found on the wiki: https://wiki.mozilla.org/Firefox/EnterprisePolicies

Second, we will branch ESR from 60 instead of 59.
This will give us more time to work on the Enterprise policies.
Also, In parallel, this means that we will have more time to delete old/dead code before branching.
As a disguised advertisement, I am using this email to remind that Marco Castelluccio's tool
https://marco-c.github.io/code-coverage-reports/ is your best friend to find dead code [1].

Last but not least, we also warned our enterprise users that ESR52.9 (EOL August 28th) will be the last release supporting legacy add-ons.

The wiki and the ESR FAQ have been updated: https://wiki.mozilla.org/RapidRelease/Calendar
https://www.mozilla.org/en-US/firefox/organizations/faq/

Sylvestre

PS: Also, for people on these two MLs who are still using Windows XP, you'll get a few more weeks to update ;)

[1] meta bug https://bugzilla.mozilla.org/show_bug.cgi?id=1415819

-------- Forwarded Message --------
Subject: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine
Date: Wed, 20 Dec 2017 14:06:57 +0100
From: Sylvestre Ledru <sylv...@mozilla.com>
To: enter...@mozilla.org <enter...@mozilla.org>



The Firefox ESR (extended support release) is based on an official release of Firefox desktop for use by organizations including schools, universities, businesses and others who need extended support for mass deployments. Since Firefox 10, ESR has grown in popularity and many large organizations
rely on it to let their employees browse the Internet securely.

We want to make customization of Firefox deployments simpler for system administrators and we’re pleased to announce that our next ESR version, Firefox 60, will include a policy engine that increases customization possibilities and integration into existing management systems.

What is the policy engine?
The Policy Engine is a project to build a Firefox desktop configuration and customization feature for enterprise users. The policy engine will work with any tool that wants to set policies and we intend to bring Windows Group Policy support soon. We’ll be initially supporting a limited set of
policies but this will be evolving through user feedback.
More details on the policy engine can be found here. <https://wiki.mozilla.org/Firefox/EnterprisePolicies>
Bug reference <https://bugzilla.mozilla.org/show_bug.cgi?id=1419102>

What’s the plan?
In order to accommodate the group policy implementation, we are making Firefox 60 our next ESR version and will be following this plan:

* May 8th - ESR 60.0 released (we’d love feedback from early adopters at that point and will be sharing a feedback form through the enterprise mailing list)
* July 3rd - ESR 60.1 released
* August 28th - End of life for ESR 52 and release of ESR 60.2.0. No further updates will be offered for ESR52 and an update to ESR60.0.2 will be provided through the application update service


Also please keep in mind that Firefox 57, released last month, supports only add-ons built with theWebExtensions API <https://developer.mozilla.org/en-US/Add-ons/WebExtensions>. This means that Firefox 52 ESR is the last release that will support legacy add-ons.  If you developed an add-on that has
not been updated to the WebExtensions API, there is still time to do so.Documentation <https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_a_legacy_Firefox_add-on>is available, and you can ask questions by emailing dev-a...@mozilla.orgor joining the #webextensions channel
atirc.mozilla.org <http://irc.mozilla.org>.
If you are supporting users who use add-ons, now is a good time to encourage them tocheck if their add-on works <https://support.mozilla.org/en-US/kb/frequently-asked-questions-firefox-addon>with Firefox 57+.

Erin, Felipe, Jeff, Kev, Mike Kaply, Romain, Shell & Sylvestre

Frank-Rainer Grahl

unread,
Dec 20, 2017, 11:05:57 AM12/20/17
to
> Second, we will branch ESR from 60 instead of 59.
> This will give us more time to work on the Enterprise policies.
> Also, In parallel, this means that we will have more time to delete
old/dead code before branching.
> As a disguised advertisement, I am using this email to remind that Marco
Castelluccio's tool
> https://marco-c.github.io/code-coverage-reports/ is your best friend to
find dead code [1].

It would be nice if you can check comm-central usage before removing larger
bits or interfaces for ESR 60 e.g. web extensions support for mail is not ready.

Thanks
FRG

Sylvestre Ledru

unread,
Dec 20, 2017, 11:56:56 AM12/20/17
to Frank-Rainer Grahl, dev-pl...@lists.mozilla.org
On 20/12/2017 17:05, Frank-Rainer Grahl wrote:
> > Second, we will branch ESR from 60 instead of 59.
> > This will give us more time to work on the Enterprise policies.
> > Also, In parallel, this means that we will have more time to delete old/dead code before branching.
> > As a disguised advertisement, I am using this email to remind that Marco Castelluccio's tool
> > https://marco-c.github.io/code-coverage-reports/ is your best friend to find dead code [1].
>
> It would be nice if you can check comm-central usage before removing larger bits or interfaces for ESR 60 e.g. web extensions support for mail is not ready.
Could you please go throught that list and let us know so that we can tag them?

Thanks
Sylvestre

Luke Crouch

unread,
Dec 21, 2017, 11:03:42 AM12/21/17
to
On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru wrote:
> First, as Dave Camp mentioned during the Firefox All Hands, we are started some developments to improve
> our support for enterprise users.
> More information can be found on the wiki: https://wiki.mozilla.org/Firefox/EnterprisePolicies

The first example configuration.json I saw on the page only shows some custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from, etc.

Will the policy config allow admins to set other/any about:config prefs to custom values?

I'm thinking specifically it would be cool to let Enterprise+InfoSec admins set some security + privacy about:config prefs to more hardened defaults.

Mike Kaply

unread,
Dec 21, 2017, 11:09:31 AM12/21/17
to Luke Crouch, dev-platform
We currently do not plan to allow arbitrary preferences, but if certain
preferences are important, we can add policies for them.

We could also add policies that set groups of preferences for specific
purposes.

Mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Peter Saint-Andre

unread,
Dec 21, 2017, 12:45:46 PM12/21/17
to Mike Kaply, Luke Crouch, dev-platform
On 12/21/17 9:09 AM, Mike Kaply wrote:
> We currently do not plan to allow arbitrary preferences, but if certain
> preferences are important, we can add policies for them.
>
> We could also add policies that set groups of preferences for specific
> purposes.

Great idea. I like Luke's suggestion of privacy and security "bundles".
Another area of interest might be proxy server settings.

Peter

>
> Mike
>
> On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch <lcr...@mozilla.com> wrote:
>
signature.asc

Tom Ritter

unread,
Jan 4, 2018, 1:07:16 PM1/4/18
to Mike Kaply, dev-platform
I am curious what Enterprise users are asking for. I'd like to
think/hope that a primary concern of enterprise is "Security" (or the
separate topic of Privacy); but I'm not certain it is.

In particular, I am curious if enterprise users would be interested in
flipping preferences that would provide stronger security isolation at
the cost of more resources (like process/memory). This is basically
what Chrome is providing with command-line flags for site isolation. A
company can decide that domains of their choosing get allocated into
per-origin processes, at the potential cost of a bunch of additional
processes.

-tom

On Thu, Dec 21, 2017 at 10:09 AM, Mike Kaply <mka...@mozilla.com> wrote:
> We currently do not plan to allow arbitrary preferences, but if certain
> preferences are important, we can add policies for them.
>
> We could also add policies that set groups of preferences for specific
> purposes.
>
> Mike
>
> On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch <lcr...@mozilla.com> wrote:
>

Gijs Kruitbosch

unread,
Jan 5, 2018, 1:09:31 PM1/5/18
to
On 04/01/2018 18:06, Tom Ritter wrote:
> I am curious what Enterprise users are asking for. I'd like to
> think/hope that a primary concern of enterprise is "Security" (or the
> separate topic of Privacy); but I'm not certain it is.
>
> In particular, I am curious if enterprise users would be interested in
> flipping preferences that would provide stronger security isolation at
> the cost of more resources (like process/memory). This is basically
> what Chrome is providing with command-line flags for site isolation. A
> company can decide that domains of their choosing get allocated into
> per-origin processes, at the potential cost of a bunch of additional
> processes.

Yes, in fact this (process-per-site) has specifically already come up on
the enterprise list in the last few days.

~ Gijs

Romain Testard

unread,
Jan 10, 2018, 9:23:23 AM1/10/18
to Gijs Kruitbosch, dev-pl...@lists.mozilla.org
Some enterprises may indeed find that enabling site isolation is worth the
trade-offs (memory usage seems to be the main one on Chrome's
implemenation).
Our current goal is to make sure enterprise users retain the same feature
set with the next ESR and that we deliver a capability that allows easy
integration of new policies and third party management tools. We'll be
reaching out to enterprise users to collect feedback that should help
prioritize our next features, right now it's it's pretty hard to assess how
critical stronger security isolation is when compared to customization
features we're considering in the medium term like the ability to disable
printing.

On Fri, Jan 5, 2018 at 7:09 PM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:

Andrew McCreight

unread,
Jan 10, 2018, 11:16:41 AM1/10/18
to Romain Testard, dev-platform, Gijs Kruitbosch
On Wed, Jan 10, 2018 at 6:22 AM, Romain Testard <rom...@mozilla.com> wrote:

> Some enterprises may indeed find that enabling site isolation is worth the
> trade-offs (memory usage seems to be the main one on Chrome's
> implemenation).
>

Just to be clear here, we do not support the same kind of site isolation
that Chrome does. Firefox has only just shipped multiprocess at all, and
Chrome has been working on site isolation for around 5 years, so it will
likely be a lot of work to support in Firefox.

Our current goal is to make sure enterprise users retain the same feature
> set with the next ESR and that we deliver a capability that allows easy
> integration of new policies and third party management tools. We'll be
> reaching out to enterprise users to collect feedback that should help
> prioritize our next features, right now it's it's pretty hard to assess how
> critical stronger security isolation is when compared to customization
> features we're considering in the medium term like the ability to disable
> printing.
>
> On Fri, Jan 5, 2018 at 7:09 PM, Gijs Kruitbosch <gijskru...@gmail.com>
> wrote:
>
0 new messages