Note that this whole feature is already marked deprecated.
Firefox is moving ahead with restricting this feature to secure contexts in Nightly/Beta and release with Firefox 62: https://www.fxsitecompat.com/en-CA/docs/2018/support-for-application-cache-on-insecure-sites-has-been-deprecated/. (Should have shipped by September 2018.)
Reportedly other browsers have similar plans.
Therefore, it might make sense to reflect this restriction in the standard (while still keeping the feature marked deprecated).
See also #151.
cc @whatwg/security @jonathanKingston
Note, we are removing window.applicationCache when its disabled. An alternative that has been thrown around is leaving it there, but making it simply do nothing. I think we want to avoid that if we can, but I guess it depends on how breaking things are in practice.
Also note, we never exposed an ApplicationCache interface on the global. So if there are sites doing "ApplicationCache" in self for their feature detection then we were already getting false on firefox.
I've started a Blink-side conversation in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ANnafFBhReY. The usage numbers Chrome users were reporting seem a bit higher than what Firefox's users showed, but based on some analysis of HTTP Archive, I'm hopeful that we'll be able to justify any potential breakage.
If we're able to follow Firefox's good example, I'd suggest that marking window.applicationCache, ApplicationCache and ApplicationCacheErrorEvent interfaces as [SecureContext] would be reasonable, as well as changing the language around the manifest attribute to impose a similar restriction. I think that's more or less the behavior Firefox has landed on as well.
more or less the behavior Firefox has landed on as well.
This sounds about right. These change are still behind the pref because of the phased roll-out but essentially the plan is to:
manifest= in the HTML parser but ignore it's usage in insecure contextsWebKit issue: https://bugs.webkit.org/show_bug.cgi?id=182442
FWIW, it seems in Firefox ApplicationCache is more akin to [NoInterfaceObject] as we simply never expose it. Other user agents might want to do that as well in order to make it easier to remove it down the line.
Should we move forward with spec changes on this, or wait until browsers see success, or...?
I think we should wait until September at least, until someone else manages to ship in release before then. It would also be useful to know if [NoInterfaceObject] is reasonable for other browsers.
We've marked this as secure context only in appropriate places, e.g. https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
Most helpful comment
WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=182442