Re: Intent to unship AppCache

2020-04-13 Thread Valentin Gosu
Hi everyone,

Jonathan is unfortunately not with the company anymore so I wanted to
follow-up and clarify our current timeline for disabling appcache.

It is my intention to land bug 1619673 [1] in Firefox 77 and let it ride
the trains.
We would keep the pref off in 78 because that's an ESR release, in case
there's a critical use case for it (we could add an enterprise policy for
it, or re-enable it if needed) but that's unlikely to happen.
Starting with 79 we can start removing the code that backs appcache, such
as the old and slow .
The intention for now is to leave the dom property window.applicationCache
and the “OfflineResourceList” interface in place for the foreseeable future
in order to avoid websites breaking.

Note that appcache use is still very low [2].
Assuming Chrome keeps to their plan [3][4] they should also be disabling
this around the end of June.
As stated in the previous email, appcache is a progressive enhancement, so
removing it doesn't break the web.

Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673
[2]
https://georgf.github.io/usecounters/index.html#kind=page&group=OFFLINERESOURCELIST&channel=beta&version=75
[3] https://www.chromestatus.com/features/6192449487634432
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=582750#c47

On Fri, 30 Aug 2019 at 00:30, Jonathan Kingston  wrote:

> I spoke to some folks who work on Chrome and they suggested because of
> their larger usage numbers there wasn't a concrete timeline that they were
> working towards, however they think there is an active plan to exchange
> appcache for service worker on some Google products they have which will
> aid in it's removal in the browser.
>
> Due to the code freeze we should increase all those version numbers by one
> in my original email, however I believe we should continue with this plan:
> - As our usage numbers are much lower.
> - Appcache is unique feature in that it's largely a progressive
> enhancement, so removing it doesn't break the web as a whole.
> - Removing this code is a bigger benefit to Firefox users from a
> performance and security standpoint.
>
> Thanks
>
> On Thu, Aug 22, 2019 at 2:45 PM Andrew Overholt 
> wrote:
>
> > It's been a long time coming :) Do you know if Chrome plans to drop
> > support, too?
> >
> > On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston 
> wrote:
> >
> >> The design of AppCache brings many problems to the web platform from a
> >> performance and security perspective. Service workers have long solved
> the
> >> same use cases as AppCache.
> >>
> >> Removal of this code would bring a large reduction of code and
> complexity
> >> that is largely unmaintained.
> >>
> >> History
> >>
> >> Four years ago, in Firefox 44, we marked the API as deprecated[1].
> >>
> >> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> >> followed suit[2].
> >>
> >> Safari 11.1 added support for Service Workers, which are a replacement
> >> technology [3].
> >>
> >> Metrics
> >>
> >> Chrome measures a few different metrics here which suggest 2.3%[4] of
> >> secure page loads attempt to use the document visible API whilst only
> >> 0.27%[5] actually use the offline cache.
> >>
> >> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> >> however we don’t have a distinct metric for the API usage.
> >>
> >> The last blocker for a removal was usage of AppCache by some Microsoft
> >> online products.  I’m enquiring into if this is still applicable and
> also
> >> want to ensure with this rollout plan that we don’t break these when the
> >> user has an online connection.
> >>
> >> Implementation
> >>
> >> Bug where the code will be implemented[7].
> >>
> >> Plan
> >>
> >>-
> >>
> >>In Firefox 70, Remove the previous preference
> >>“browser.cache.offline.insecure.enable” and related code, forcing all
> >> of
> >>the APIs to only ever be available over Secure Contexts despite user
> >>choice. Due to the insecure nature of insecure context AppCache it
> is a
> >>good time now to remove this fully.
> >>
> >>
> >>-
> >>
> >>Create a new preference that disables only the storage and use of
> >>AppCache data whilst permitting access to the dom property
> >>window.applicationCache and the “OfflineResourceList” interface.
> >>-
> >>
> >>   Disable access in Nighty and beta for 70 for two releases before
> >>   disabling for all other releases in 72.
> >>   -
> >>
> >>   Once storage is disabled in all releases:
> >>   -
> >>
> >>  Disable the API access in Nightly and beta via the existing
> >>  preference (browser.cache.offline.enable) in version 72.
> >>  -
> >>
> >>  Wait two releases and then disable in all releases in Firefox
> 74.
> >>
> >>
> >> This staged removal of AppCache is to reduce the risk of web
> compatibility
> >> issues of the API being accessible to page scripts. Despite the API
> >> presence it won’t have any ability to use 

Re: Intent to unship AppCache

2019-08-29 Thread Jonathan Kingston
I spoke to some folks who work on Chrome and they suggested because of
their larger usage numbers there wasn't a concrete timeline that they were
working towards, however they think there is an active plan to exchange
appcache for service worker on some Google products they have which will
aid in it's removal in the browser.

Due to the code freeze we should increase all those version numbers by one
in my original email, however I believe we should continue with this plan:
- As our usage numbers are much lower.
- Appcache is unique feature in that it's largely a progressive
enhancement, so removing it doesn't break the web as a whole.
- Removing this code is a bigger benefit to Firefox users from a
performance and security standpoint.

Thanks

On Thu, Aug 22, 2019 at 2:45 PM Andrew Overholt 
wrote:

> It's been a long time coming :) Do you know if Chrome plans to drop
> support, too?
>
> On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston  wrote:
>
>> The design of AppCache brings many problems to the web platform from a
>> performance and security perspective. Service workers have long solved the
>> same use cases as AppCache.
>>
>> Removal of this code would bring a large reduction of code and complexity
>> that is largely unmaintained.
>>
>> History
>>
>> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>>
>> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
>> followed suit[2].
>>
>> Safari 11.1 added support for Service Workers, which are a replacement
>> technology [3].
>>
>> Metrics
>>
>> Chrome measures a few different metrics here which suggest 2.3%[4] of
>> secure page loads attempt to use the document visible API whilst only
>> 0.27%[5] actually use the offline cache.
>>
>> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
>> however we don’t have a distinct metric for the API usage.
>>
>> The last blocker for a removal was usage of AppCache by some Microsoft
>> online products.  I’m enquiring into if this is still applicable and also
>> want to ensure with this rollout plan that we don’t break these when the
>> user has an online connection.
>>
>> Implementation
>>
>> Bug where the code will be implemented[7].
>>
>> Plan
>>
>>-
>>
>>In Firefox 70, Remove the previous preference
>>“browser.cache.offline.insecure.enable” and related code, forcing all
>> of
>>the APIs to only ever be available over Secure Contexts despite user
>>choice. Due to the insecure nature of insecure context AppCache it is a
>>good time now to remove this fully.
>>
>>
>>-
>>
>>Create a new preference that disables only the storage and use of
>>AppCache data whilst permitting access to the dom property
>>window.applicationCache and the “OfflineResourceList” interface.
>>-
>>
>>   Disable access in Nighty and beta for 70 for two releases before
>>   disabling for all other releases in 72.
>>   -
>>
>>   Once storage is disabled in all releases:
>>   -
>>
>>  Disable the API access in Nightly and beta via the existing
>>  preference (browser.cache.offline.enable) in version 72.
>>  -
>>
>>  Wait two releases and then disable in all releases in Firefox 74.
>>
>>
>> This staged removal of AppCache is to reduce the risk of web compatibility
>> issues of the API being accessible to page scripts. Despite the API
>> presence it won’t have any ability to use the cache. We may look into
>> shimming these APIs depending on how the rollout plan goes.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>>
>> [2]
>>
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>>
>> [3]
>>
>> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>>
>>
>> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>>
>> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>>
>> [6] https://mzl.la/2TKRbvA
>> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
>> ___
>> 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: Intent to unship AppCache

2019-08-22 Thread Andrew Overholt
It's been a long time coming :) Do you know if Chrome plans to drop
support, too?

On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston  wrote:

> The design of AppCache brings many problems to the web platform from a
> performance and security perspective. Service workers have long solved the
> same use cases as AppCache.
>
> Removal of this code would bring a large reduction of code and complexity
> that is largely unmaintained.
>
> History
>
> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>
> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> followed suit[2].
>
> Safari 11.1 added support for Service Workers, which are a replacement
> technology [3].
>
> Metrics
>
> Chrome measures a few different metrics here which suggest 2.3%[4] of
> secure page loads attempt to use the document visible API whilst only
> 0.27%[5] actually use the offline cache.
>
> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> however we don’t have a distinct metric for the API usage.
>
> The last blocker for a removal was usage of AppCache by some Microsoft
> online products.  I’m enquiring into if this is still applicable and also
> want to ensure with this rollout plan that we don’t break these when the
> user has an online connection.
>
> Implementation
>
> Bug where the code will be implemented[7].
>
> Plan
>
>-
>
>In Firefox 70, Remove the previous preference
>“browser.cache.offline.insecure.enable” and related code, forcing all of
>the APIs to only ever be available over Secure Contexts despite user
>choice. Due to the insecure nature of insecure context AppCache it is a
>good time now to remove this fully.
>
>
>-
>
>Create a new preference that disables only the storage and use of
>AppCache data whilst permitting access to the dom property
>window.applicationCache and the “OfflineResourceList” interface.
>-
>
>   Disable access in Nighty and beta for 70 for two releases before
>   disabling for all other releases in 72.
>   -
>
>   Once storage is disabled in all releases:
>   -
>
>  Disable the API access in Nightly and beta via the existing
>  preference (browser.cache.offline.enable) in version 72.
>  -
>
>  Wait two releases and then disable in all releases in Firefox 74.
>
>
> This staged removal of AppCache is to reduce the risk of web compatibility
> issues of the API being accessible to page scripts. Despite the API
> presence it won’t have any ability to use the cache. We may look into
> shimming these APIs depending on how the rollout plan goes.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>
> [3]
>
> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>
>
> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>
> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>
> [6] https://mzl.la/2TKRbvA
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
> ___
> 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