Intent to disable service workers and push in 52 ESR

[Ben Kelly]

Hi all,

I'd like to disable service workers in 52 ESR. This would also require
disabling push notifications.

A year ago we decided to disable service workers in 45 ESR because it was
very new and unstable:

https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ

While things have stabilized since then we are in process of making a major
architectural change in order to support multiple content processes
(multi-e10s). This will make it very difficult to uplift fixes. Once the
new architecture has stabilized we should be able to enable SW in the next
ESR.

Thoughts?

Thanks.

Ben

[Till Schneidereit]

That'll mean that Windows XP/Vista users won't have them.

Might be ok, but means the bar for a decision like this should be somewhat
higher than usual, I think.

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

[Dirkjan Ochtman]

On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly <bke...@mozilla.com> wrote:
> While things have stabilized since then we are in process of making a major
> architectural change in order to support multiple content processes
> (multi-e10s). This will make it very difficult to uplift fixes. Once the
> new architecture has stabilized we should be able to enable SW in the next
> ESR.
>
> Thoughts?

Maybe I'm missing context, but I find the notion of not-shipping
things on ESR that are available on the normal release channel pretty
strange. Maybe this is because I'm incorrectly assuming that the
majority of Firefox usage in the wild is not on ESR? Alternatively, is
Service Workers the only thing getting major architectural changes for
multi-e10s? (I would assume not.) If not, are we withholding all those
other things from the ESR channel, too?

Cheers,

Dirkjan

[Ben Kelly]

On Wed, Jan 18, 2017 at 10:58 AM, Dirkjan Ochtman <dir...@ochtman.nl>
wrote:

Last I checked we do this all the time for new and potentially unstable
things. For example, AFAIK we do not enable e10s on ESR. I have not heard
if that will change for 52 ESR. I would expect not, though, since we are
still rolling it out to the full population.

I just don't think we can commit to providing stable security uplifts to
ESR for a 9 months if our trunk version is completely different.

Ben

[Mike Conley]

> I would expect not, though, since we are
>> still rolling it out to the full population.

I do believe the plan is to enable e10s on 52 ESR, but with the Firefox
50 restrictions (e10s enabled by default, disabled if a11y APIs used,
disabled if non-WebExtension, non-mpc=true add-ons enabled).

That was my most recent reckoning of it, anyhow.

-Mike

[Ben Kelly]

On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit <
ti...@tillschneidereit.net> wrote:

> That'll mean that Windows XP/Vista users won't have them.
>
> Might be ok, but means the bar for a decision like this should be somewhat
> higher than usual, I think.
>

Understood, but that does not change the difficulty of trying to maintain
ESR for 9+ months when trunk code looks completely different. I think its
too risky from a security maintenance perspective.

Also, service workers are typically a progressive enhancement for most
sites. Users still have access to content on the web. They just lose
offline support and push notification alerts.

Ben

[Till Schneidereit]

On Wed, Jan 18, 2017 at 5:43 PM, Ben Kelly <bke...@mozilla.com> wrote:

> On Wed, Jan 18, 2017 at 10:58 AM, Till Schneidereit <
> ti...@tillschneidereit.net> wrote:
>
>> That'll mean that Windows XP/Vista users won't have them.
>>
>> Might be ok, but means the bar for a decision like this should be
>> somewhat higher than usual, I think.
>>
>
> Understood, but that does not change the difficulty of trying to maintain
> ESR for 9+ months when trunk code looks completely different. I think its
> too risky from a security maintenance perspective.
>

Dirkjan rightly points out that this'll likely be true for other things.
Backporting patches will be especially hard for 52 and perhaps the next ESR
because of all the Quantum work going on. However, that actually seems to
be an argument _for_ disabling Service Workers: as you say it's a huge
feature that's not yet really relied on by sites, at least not as a hard
requirement. So disabling it shouldn't have too much of a noticeable
negative effect, but will seriously lighten the burden of keeping the ESR
secure.

[Dirkjan Ochtman]

On Wed, Jan 18, 2017 at 5:38 PM, Ben Kelly <bke...@mozilla.com> wrote:
> Last I checked we do this all the time for new and potentially unstable
> things. For example, AFAIK we do not enable e10s on ESR. I have not heard
> if that will change for 52 ESR. I would expect not, though, since we are
> still rolling it out to the full population.
>
> I just don't think we can commit to providing stable security uplifts to ESR
> for a 9 months if our trunk version is completely different.

e10s is very different to me because it's not part of the web platform
API. On the other hand, sites like caniuse.com clearly advertise that
ServiceWorkers are available in Firefox (and Chrome), and then going
back and not exposing that in the ESR population seems to me that in a
sense, we break a kind of contract with web developers.

What's the rate of ServiceWorker security bugs? Do you expect that many of them?

Cheers,

Dirkjan

[Ben Kelly]

On Wed, Jan 18, 2017 at 1:35 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> API. On the other hand, sites like caniuse.com clearly advertise that
> ServiceWorkers are available in Firefox (and Chrome), and then going
> back and not exposing that in the ESR population seems to me that in a
> sense, we break a kind of contract with web developers.
>

This situation already exists with 45 ESR. Sites that hard code caniuse.com
with UA sniffing are already broken.

They are also broken in private browsing mode because we don't support
service workers there either.

Sites generally feature detect service workers because safari does not
implement them yet. The entire API has been designed to work well with
feature detection and progressive enhancement.

> What's the rate of ServiceWorker security bugs? Do you expect that many of
> them?
>

I don't have exact numbers. But there have been many uplifts for service
workers. In general it is helpful that we have been able to mark these as
45esr:disabled.

[Kit Cambridge]

This sounds like a good plan, Ben. IIUC, we're committing to support
all our ESRs for a year, so anything we can do to make uplifts easier
is sensible.

Till brings up a good point about folks on older platforms, but it's
likely they'll already have a degraded experience on many sites. I
expect future platform APIs to be built on service workers, too;
background sync is one current example. Even if we did enable service
workers and push in ESR 52, it won't be realistic to backport all new
APIs, so older releases still won't be able to take advantage of them.

Cheers,
- kit

On Wed, Jan 18, 2017 at 7:58 AM, Till Schneidereit

<ti...@tillschneidereit.net> wrote:
> That'll mean that Windows XP/Vista users won't have them.
>
> Might be ok, but means the bar for a decision like this should be somewhat
> higher than usual, I think.
>

> On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly <bke...@mozilla.com> wrote:
>
>> Hi all,
>>
>> I'd like to disable service workers in 52 ESR. This would also require
>> disabling push notifications.
>>
>> A year ago we decided to disable service workers in 45 ESR because it was
>> very new and unstable:
>>
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/
>> VWXOa8N9AgAJ
>>

>> While things have stabilized since then we are in process of making a major
>> architectural change in order to support multiple content processes
>> (multi-e10s). This will make it very difficult to uplift fixes. Once the
>> new architecture has stabilized we should be able to enable SW in the next
>> ESR.
>>
>> Thoughts?
>>

>> Thanks.

[Eric Shepherd]

Any time something is disabled or removed from ESR, please be sure the developer docs team knows about it, because that’s something that has to be reflected in our documentation. I’m not aware of many (if any) documentation that says something exists in version X but not in ESR version X; that’s an inaccuracy we need to avoid and to fix where already present.

[Lawrence Mandel]

We disabled some features (iirc Hello and Pocket) in ESR45. The preference
is to keep ESR inline with what's in the mainline release but we're also
supporting ESR on a best effort basis. I think the rationale in this thread
for disabling service workers and push in ESR52 makes sense if we're not
going to be able to maintain these features and they don't yet have broad
adoption that is going to see a significant risk of web compat issues.

Lawrence

On Mon, Jan 23, 2017 at 3:07 PM, Eric Shepherd <eshe...@mozilla.com>
wrote:

[Kohei Yoshino]

Do we already have a bug for this? Firefox 52 will be shipped just in 4 weeks.

[Ben Kelly]

I just filed:

https://bugzilla.mozilla.org/show_bug.cgi?id=1338144

On Thu, Feb 9, 2017 at 4:26 AM, Kohei Yoshino <kohei....@gmail.com>
wrote: