Intent to Experiment: Foreign Fetch and Link rel=serviceworker

[Marijn Kruisselbrink]

Contact emails

m...@chromium.org, owe...@chromium.org, kenji...@chromium.org

Summary

Foreign Fetch is a proposal to enable service composition via third party service workers (see the Intent to Implement for sample use cases). Link rel=serviceworker will allow these service workers to bootstrap themselves using Link headers in HTTP responses, specifically without this header, a service would have to rely on being embedded in an iframe to install its foreign fetch service worker (this experiment also enable installation of service workers through the <link> element, although that part doesn't enable anything the service worker javascript API doesn't already support).

Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).

Explainer

https://github.com/slightlyoff/ServiceWorker/blob/master/foreign_fetch_explainer.md

Spec

Foreign fetch is defined in the Fetch and service worker specs. More precisely,  HTTP Fetch in the fetch spec calls out to Handle Foreign Fetch in the service worker spec. Also see the definition of the InstallEvent in the service worker spec for the API to register for foreign fetch.

Link rel=serviceworker:

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#link-type-serviceworker

The current implementation of foreign fetch in Chrome has a couple of temporary limitations:

• First of all any request for which CORS would send a preflight request isn't interceptable by foreign fetch.

• In addition to that Chrome won't fall back to the network either if a foreign fetch event is dispatched but not handled.

Both of these are caused by complications around the way CORS is implemented in Blink. Part of the goal of this experiment is to determine if it is worth the significant engineering effort to refactor the CORS code to lift these limitations.

Link to “Intent to Implement” blink-dev discussion

Foreign fetch: https://groups.google.com/a/chromium.org/d/msg/blink-dev/EecwKDQoNtk/i57bp1GrCAAJ

Link rel=serviceworker: https://groups.google.com/a/chromium.org/d/msg/blink-dev/HwDRVyP505Q/tgEJY5kYCwAJ

Goals for experimentation

First of all we'd like to figure out if this API is actually as useful as we imagine it could be, and to get a better idea how this API will be used. Part of this we hope to learn from feedback from websites using the trial, but we'll also collect metrics around how the API ends up being used (do websites intercept requests from all origins, or some limited subset of origins; how many sub-scopes does a service worker typically register for, maybe we can get rid of sub-scopes entirely, etc).

A second goal would be to determine if the current performance characteristics of the API are acceptable, and if not, what areas in particular need to be improved upon. To get some idea about this we'll be collecting various performance related measurements with regard to event dispatching, service worker overhead for foreign fetch, number of affected page loads, etc. This should help us decide what if any limitations that aren't already in place might need to be put in place to make this API more performant, while still addressing the use cases we care about.

Experimental timeline

Enabled:

• August 25th: Chrome 54 Branched to Dev.

• October 18th: Chrome 54 Stable*.

• November 17th: Chrome 56 Branch to Dev.

• 4 weeks of 54 stable channel feedback.

• December 6th: Chrome 55 Stable*.

• ~6 weeks after Chome 56: Chrome 57 Branch to Dev.

• 10 weeks of 54 stable channel feedback.

• 4 week of 55 stable channel feedback

• January 31st 2017: Chrome 56 Stable*.

Disabled:

• ~6 weeks after Chome 56: Chrome 57 Stable*. Initial experiment terminates.

* Stable dates are estimates: https://www.chromium.org/developers/calendar.

Any risks when the experiment finishes?

Even with foreign fetch there is no guarantee that any particular request will end up being intercepted by a third party's service worker. For example, under storage pressure we could evict the service worker and all storage for an origin using foreign fetch. Sites trying out this experiment should therefore be able to deal with things stopping working anyway.

Of course if foreign fetch is used to enable offline functionality, but the third party service worker doesn’t sync the data to a server then there is increased risk for the data to become unavailable after the experiment finishes, beyond the existing risk due to the storage pressure issue mentioned above.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All except Android WebView (Origin Trials aren't supported on Android WebView).

OWP launch tracking bug

Foreign fetch: https://code.google.com/p/chromium/issues/detail?id=540509

Link rel=serviceworker: https://bugs.chromium.org/p/chromium/issues/detail?id=582308

Link to entry on the feature dashboard

Foreign fetch: https://www.chromestatus.com/feature/5684130679357440

Link rel=serviceworker: https://www.chromestatus.com/features/5682681044008960

[rek...@gmail.com]

Perhaps worth noting that WHATWG pulled in Foreign Fetch a week ago: https://github.com/whatwg/fetch/commit/8510b2f52d576af6a6c683620878eb3e39e14954

Very excited that it's only two more weeks before I can start hacking on, trying out this capability! I came here to follow up on the Intent To Implement (10 month old thread!), was pleased to find this thread.

I started a discovery service using FF back in June ( https://github.com/rektide/0hub ), as it seemed like feature work for this was ramping down, and have been oh so eager to know when I might get to start testing/trying it. This discovery service proof of concept is in turn based around some ideas brought up early in the life of Foreign Fetches predecessor, navigator.connect, namely: https://github.com/mkruisselbrink/navigator-connect/issues/1

This is such a pivotal shift for the web; I'm overjoyed it's made it into the spec and that I now know when I'll be able to start building forward with it. A rich offline-capable interconnected set of sites is exactly the web I want. Regards all, thanks for the update!

[Peter Beverloo]

On Tue, Aug 9, 2016 at 9:59 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

Summary

Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).

The header is very useful without foreign fetch too. The discussions seem to have been closed; are there standing concerns that prevent us from just shipping it?

That said, Mozilla's implementation bug hasn't seen progress yet.

Thanks,

Peter

[Marijn Kruisselbrink]

On Wed, Aug 10, 2016 at 11:12 AM, Peter Beverloo <pe...@chromium.org> wrote:

On Tue, Aug 9, 2016 at 9:59 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

Summary

Even though these really are two independent features, it still seems sensible to combine them into one origin trial as the Link header makes foreign fetch a lot more powerful (and without foreign fetch there isn't that much benefit in using the Link header or element to install service workers rather than just using the existing JavaScript API).

The header is very useful without foreign fetch too. The discussions seem to have been closed; are there standing concerns that prevent us from just shipping it?

I'm not aware of any such concerns, no. That said, if we do go ahead and just ship the header I think it would make sense to limit the shipped version to main resource requests (documents/workers), and keeping support for the header on subresources as part of the foreign fetch experiment.

Marijn

[Chris Harrelson]

LGTM1 to experiment.

(Update coming soon about possible LGTM requirements for experiments, but for this one let's get 3 LGTMs to approve.)

--
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+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Darin Fisher]

LGTM3

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[rek...@gmail.com]

Hello,

According to the feature dashboard, this feature is supposed to be available in Origin Trial on m54.

According to the Origin Trials documentation, this means there should be a flag in about:flags that I can flip to enable foreign fetch for localhost and 127.0.0.1: https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md#how-can-i-experiment-with-the-new-feature-locally

Each feature that is available as an origin trial can alternatively be enabled on individual machines by flipping the corresponding flag in about:flags. The correct flag depends on the feature, and should be mentioned in the blog post about that specific feature.

There is no such flag (I've tried a chrome. I have filed for an Origin Trial token, but I would like to see adherence to the official Origin Trial guidelines. The option to have a flag is very important for enabling devs to experiment with upcoming features, and the official guide is supposed to afford devs a flag. Please fix this violation of Origin Trials policy. Please also provide some documentation, citiation, as per the guide, for what the flag is that develops can enable. If this flag is not available, please update the feature dashboard to reflect unavailability or partial availability of the feature.

I base these assertions on having tried Chrome 55.0.2873.0 from unstable and Chrome 54.0.2840.41 from beta, as well as numerous other m54 and beyond revisions. There have remained no relevant flag listed in about:flags nor is there anything pertinent on http://peter.sh/experiments/chromium-command-line-switches/ as an alternative to about:flags.

Thank you for your assistance in getting this fantastic feature underway,

rektide

On Tuesday, August 9, 2016 at 4:59:38 PM UTC-4, Marijn Kruisselbrink wrote:

Contact emails

[ed: snip]

[Anton Vayvod]

Judging from the definition here, the flag should be the usual --enable-experimental-web-platform-features.

This flag is mentioned here (not sure if that's the blog post that should mention the flag according to the guide).

I expect most of the experimental features will be enabled locally by this and not some other separate flag.

Enjoy experimenting!

[Ian Clelland]

No, it doesn't look like there is any flag in about:flags for ForeignFetch (mek, do you think it's worth adding one?)

As Anton said, --enable-experimental-web-platform-features should turn it on -- that turns on *all* experimental features, though, so it may be enabling more than you want.

If you want to turn on *just* foreign fetch, then I think that this command-line flag should work as well:

--enable-blink-features=ForeignFetch,LinkServiceWorker

(Both features are required in order for ForeignFetch to be useful; the origin trial enables both if the token is present.)

[rek...@gmail.com]

Foreign Fetch has been removed from WHATWG's Fetch spec[1] and is being removed from W3C's ServiceWorker spec[2]. A comment has been filed into the Chrome foreign fetch issue noting this[3], and discussing it's removal from Chrome.

[1] https://github.com/whatwg/fetch/pull/596

[2] https://github.com/w3c/ServiceWorker/issues/1188

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=540509#c36

This is extremely shocking and saddening news to me. The Offline Web, a redecentralized web needs the capability for origins to talk with one another and provide services, & foreign fetch was a brilliant natural understandable extension of ServiceWorkers to provide this necessary virtue. It fundamentally re-wove the web in an offline compatible way, and I loved it.

I did not expect this Trial to show a ton of activity. This is a very advanced capability, on top of technology we are only barely beginning to understand as practitioners - that we are, we must admit, still certainly infants at - ServiceWorkers.

Jake Archibald provided the one clear explanation I've seen of the technical double-keying issue that has beleaguered this effort[4]. Different invokers of the Foreign Fetch Service Worker would get different instances with their own isolated storage. This drastically reduces the usefulness and capabilities of the foreign fetch worker. So a fonts.google.com ff-sw wouldn't effectively be able to cache data effectively, since each different origin asking it for data would have a fresh uninitialized copy.

[4] https://github.com/w3c/ServiceWorker/issues/1188#issuecomment-323980484

This is earth shatteringly bad and awful news to me, and I don't see how the offline web can possibly survive this impact in any meaningful form. This is the saddest time for the web. Thank you for having put this experiment forward. I hope it can do more than fade, I hope that somehow we can create security policies that can bestow some elevated cookie status, say for domains people first-party visit. The offline web needs a chance and I see no other chance for it.

Sad regards,

rektide