Primary eng (and PM) emails
pwn...@chromium.org and natt...@chromium.org
Summary
We would like to immediately add a DevTools warning for pages that have a manifest attribute on the html element, or that access the ApplicationCache API. We hope to get the usage to drop significantly by migrating a large internal customer, and intend to follow up with an Intent to Remove afterwards.
Removing AppCache from insecure origins was previously approved and has landed in M70. This intent addresses deprecating AppCache in secure origins.
Motivation
AppCache is documented as deprecated and under removal in MDN and in the WHATWG standard, and marked as obsolete in W3Câs HTML 5.1.
The modern replacement for AppCache, service workers, is a very different type of API -- the former is declarative while the latter is imperative. As a consequence, switching a Web application from AppCache to service workers has a non-trivial technical cost. For this reason, we consider that the benefit of helping developers avoid using AppCache in new applications is worth the DevTools noise caused by the proposed deprecation warning.
Furthermore, Firefox and Safari have already deprecated AppCache (see below). We think we need to follow suit so developers donât incorrectly infer that we support keeping the feature in the Web platform.
The upcoming removal intent hits most of the bullet points in the removal guidelines:
Code health - Our AppCache implementation has been on life support for the past couple of years, in anticipation of the Webâs migration to service workers. Maintenance has been limited to fixing critical bugs, and weâve accumulated a fair amount of minor bugs. Furthermore, the AppCache implementation currently has tendrils in //net and the network service, and removing it would reduce complexity throughout our network stack.
Interoperability - Two other major browsers have already deprecated the feature.
Known bad practice - The AppCache API is difficult to use correctly. Lighthouse considers it a bad practice.
Interoperability and Compatibility Risk
Edge: Supported, deprecation TBD
Firefox: Supported, already deprecated
Safari: Supported, already deprecated
Alternative implementation suggestion for web developers
Modern applications should use service workers, which are supported across all major browsers.
Usage information from UseCounter
The ApplicationCache API usage looks as follows:
On secure origins - ApplicationCacheAPISecureOrigin: 1.57%
On insecure origins - ApplicationCacheAPIInsecureOrigin: 1.65%
The (non-empty) manifest attribute usage is:
On secure origins - ApplicationCacheManifestSelectSecureOrigin: 0.33%
On insecure origins - ApplicationCacheManifestSelectInsecureOrigin: 0.02%
Insecure usage will go to zero in M70, per the removal mentioned above.
Entry on the feature dashboard
https://www.chromestatus.com/feature/6192449487634432
Requesting approval to remove too?
No.
We are currently working to transition large internal customers off of AppCache. We expect that the usage will drop significantly after the transition, and would like to come back with a removal proposal at that time. While we donât have a timeline, the Chrome Storage team is committed to removing our AppCache implementation.
Primary eng (and PM) emails
pwn...@chromium.org and natt...@chromium.org
Summary
We would like to immediately add a DevTools warning for pages that have a manifest attribute on the html element, or that access the ApplicationCache API. We hope to get the usage to drop significantly by migrating a large internal customer, and intend to follow up with an Intent to Remove afterwards.
Removing AppCache from insecure origins was previously approved and has landed in M70. This intent addresses deprecating AppCache in secure origins.
Motivation
AppCache is documented as deprecated and under removal in MDN and in the WHATWG standard, and marked as obsolete in W3Câs HTML 5.1.
The modern replacement for AppCache, service workers, is a very different type of API -- the former is declarative while the latter is imperative. As a consequence, switching a Web application from AppCache to service workers has a non-trivial technical cost. For this reason, we consider that the benefit of helping developers avoid using AppCache in new applications is worth the DevTools noise caused by the proposed deprecation warning.
Furthermore, Firefox and Safari have already deprecated AppCache (see below). We think we need to follow suit so developers donât incorrectly infer that we support keeping the feature in the Web platform.
The upcoming removal intent hits most of the bullet points in the removal guidelines:
Code health - Our AppCache implementation has been on life support for the past couple of years, in anticipation of the Webâs migration to service workers. Maintenance has been limited to fixing critical bugs, and weâve accumulated a fair amount of minor bugs. Furthermore, the AppCache implementation currently has tendrils in //net and the network service, and removing it would reduce complexity throughout our network stack.
Interoperability - Two other major browsers have already deprecated the feature.
Known bad practice - The AppCache API is difficult to use correctly. Lighthouse considers it a bad practice.
Interoperability and Compatibility Risk
Edge: Supported, deprecation TBD
Firefox: Supported, already deprecated
Safari: Supported, already deprecated
Alternative implementation suggestion for web developers
Modern applications should use service workers, which are supported across all major browsers.
Usage information from UseCounter
The ApplicationCache API usage looks as follows:
On secure origins - ApplicationCacheAPISecureOrigin: 1.57%
On insecure origins - ApplicationCacheAPIInsecureOrigin: 1.65%
The (non-empty) manifest attribute usage is:
On secure origins - ApplicationCacheManifestSelectSecureOrigin: 0.33%
On insecure origins - ApplicationCacheManifestSelectInsecureOrigin: 0.02%
Insecure usage will go to zero in M70, per the removal mentioned above.
Entry on the feature dashboard
https://www.chromestatus.com/feature/6192449487634432
Requesting approval to remove too?
No.
We are currently working to transition large internal customers off of AppCache. We expect that the usage will drop significantly after the transition, and would like to come back with a removal proposal at that time. While we donât have a timeline, the Chrome Storage team is committed to removing our AppCache implementation.
We acknowledge that deprecation without a strict removal date is discouraged. In this case, we believe that not posting a deprecation warning would significantly hurt Web developers who may commit new applications to AppCache. The deep architectural differences between AppCache and its replacement (service workers) lead to non-trivial switching costs.Â
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP_mGKrHWvavNK%3DiLWzHWAMoATVXRUh_6onM8ATEZQgwqrG6oA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh1kYkQDND--XzAs_-7SDLdk5jMZvhsJyTb7eqcP5QV%3DA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20fc41a8-fff4-43d0-8290-eb664cdf6232%40chromium.org.
There's workbox (https://developers.google.com/web/tools/workbox/) which helps generate a service worker for you.As for an Appcache polyfill, we're currently lacking good support for https://w3c.github.io/ServiceWorker/#fetch-event-resultingclientid, which we'd need to associate a page to a given cache for its lifespan. Once we've got that, building a polyfill is possible.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20fc41a8-fff4-43d0-8290-eb664cdf6232%40chromium.org.
I would also like to see a polyfill that works as much as possible like a safe drop-in replacement before we force everyone off AppCache.I have tried several times to move projects from AppCache to service workers by following whatever recipes looked most-recommended at the time, but I've always ended up with something that was a flakier user experience â especially when the connection isn't great.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANCvrdRaupMehM89mkRyUvomXFbsL%2BcqNyS_yb2XtA%2B4PdN7Lg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMq%3Dbeh02OKD4iQMi_w4rTCQWTfEtMY5RPXNRE8g_buNDFBtbQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9CweUXUOnBA17Yvbzam7C_Bbeq%2B19gNp6D8-b6qpLREw%40mail.gmail.com.
We (me, Alex, Chris, Daniel) discussed this briefly again today. Have you looked into adding UKM metrics for this?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdRVcGO%3D-dk1sMgpKXV4-7W7jEZjphQ12FFegFuqpW3Bw%40mail.gmail.com.
Contact emails
Design docs/spec
Specification: https://html.spec.whatwg.org/multipage/offline.html#offline
Summary
AppCache was standardized in the Offline Web applications section of the HTML specification. The standard is formally referred to as application caches.
AppCache support was removed from insecure origins in M70. This intent addresses AppCache usage in secure origins.
Motivation
First and foremost, AppCache is a deprecated standard with serious architectural concerns. Second, Chrome's AppCache implementation is a security and stability liability.
AppCache is documented as deprecated and under removal in MDN and in the HTML standard. The AppCache API is difficult to use correctly. Lighthouse considers AppCache usage to be a bad practice. AppCache is incompatible with CORS, making it unfriendly for usage with CDNs.
From a security perspective, AppCache has recently become the 2nd most troublesome client-side storage API in the Web Platform. In 2018-2019, AppCache has required 14 merges to Beta, and 3 merges to Stable. In 2019, AppCache has also received 14 critical fixes, addressing Web Platform security issues and/or crashes. Details at https://docs.google.com/document/d/1sQoB_6bySEn3wbGtTokKqf6jp-fwaYDOd_rkYOf35-s/. Overall, AppCache was changed in over 400 Chromium CLs in 2018-2019. It has imposed a tax on all of Chromeâs significant architectural efforts: Mojofication, Onion Souping, and the Network Service.
Interoperability and Compatibility Risk
Edge: Supported, neutral to removal
Edge on Chromium intends to follow Chrome's deprecation and removal schedule.
Firefox: Deprecated, positive to removal
Intent to remove in two stages. Firefox 72 will expose the API but not populate or use caches. Firefox 74 will remove the API.
Safari: Deprecated, positive to removal
Deprecated in 2018/01, logs a deprecation warning in DevTools. No timeline indicated for removal.
Alternative implementation suggestion for web developers
New Web applications should be built around Service Workers. Existing applications that use AppCache should migrate to Service Workers.
Migrating from AppCache to Service Worker requires fundamental architectural changes. To facilitate the migration, the Chrome team has published a polyfill that implements AppCache on top Service Worker at https://github.com/GoogleChromeLabs/sw-appcache-behavior
Applications with a modern Service Worker-based architecture can use the Workbox library published at https://developers.google.com/web/tools/workbox/
Usage information from UseCounter
The ApplicationCache API usage is tracked by ApplicationCacheAPISecureOrigin: 2.70%
The (non-empty) manifest attribute usage is tracked by ApplicationCacheManifestSelectSecureOrigin: 0.28%
AppCache has very high usage for a removal. However, when the user is online, the lack of AppCache will at most result in degraded performance. Site functionality will only be compromised for offline users.
Is this feature fully tested by web-platform-tests?
No
AppCache has some WPT coverage at html/browsers/offline/
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6192449487634432
Requesting approval to remove too?
Yes. Asking for approval to deprecate immediately (in M79), with warning messages targeting removal in M82.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3878c222-dee2-420f-a572-13f5bbcecb94%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Df18-whyP6bD4%2BG2kYoujZ%3D9g_c4fsOEzgp-aY%2B69S-1A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_yVa5evqCU%2B8gd3CTLmbhruX%2BiCYsvp_9kwy%3DqKOEGdg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/153cc94b-8b25-4c80-8b52-76f1025954bc%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMiuCXwwJwWkJQcnuUy_3Lo7KOw6KXGeEivdFGKiPfiGQw%40mail.gmail.com.