New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefetch vs Service Workers #78

Open
jyasskin opened this Issue Apr 4, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@jyasskin
Copy link

jyasskin commented Apr 4, 2018

In a recent discussion, it was pointed out that if page A includes <link rel=prefetch href=B> and <link rel=prefetch href=C>, both B and C are requested through A's Service Worker. It would be possible to force either to go through its own SW using an as=document attribute, but that's unimplemented and likely being removed (#66).

If the user winds up clicking a link to B, which uses C as a subresource, the real subresource request for C goes through B's SW, which A's <link rel=prefetch href=C> can't achieve either with or without the as attribute.

I can imagine several options:

  1. Give <link rel=prefetch> a new attribute explicitly saying which SW to send the request through. However, I could imagine some SWs breaking if any attacker could send them a fetch their site would never actually send.
  2. Assume all prefetches are for the top-level resource of a navigation, and send them through the href's service worker.
  3. Say that <link rel=prefetch> is only for pre-populating the HTTP and preload caches and should always skip the SW layer. Then a site with an <a href=D> might have to <link rel=prefetch> something other than D if D's Service Worker is going to build its response for D from several non-D subresources.

I don't see the current behavior of going through the referrer's SW as a sensible option now that we've thought about it, but maybe I've just missed something, and I could imagine that we're stuck here now.

What do folks think?

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 17, 2018

Triggering a cross-origin service worker based on a element seems a bit like foreign fetch to me in terms of enabling tracking cookies. If it was limited to something like "as=document", then the browser could treat them like iframes and respect the user's configured 3rd party iframe policies.

@jyasskin

This comment has been minimized.

Copy link

jyasskin commented Apr 18, 2018

Ah, trackers, ruining things for everyone. Thanks for pointing out that angle.

For browsers with third-party cookies turned off, I think the mitigation for (2) and (1) is the same: either block the prefetch or fall back to (3). It's possible we could come up with a declarative or Worklet-based system to let the third-party SW map request URLs to the set of resources needed to serve them, without being able to record anything as a result, but that's more complex than I'd want to design without some more concrete use cases.

@yoavweiss

This comment has been minimized.

Copy link
Contributor

yoavweiss commented Apr 27, 2018

If there's a concrete use-case for as=document, it can be easily implemented and remain in the spec.
It makes sense for navigation prefetches to go through the destination SW.

However, I'm wondering if we should define a "prefetch cache" below the SW, where prefetch requests would bypass the current SW entirely, and will go through SW only once the resource is used (by the future Document).

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Apr 27, 2018

If there's a concrete use-case for as=document, it can be easily implemented and remain in the spec.
It makes sense for navigation prefetches to go through the destination SW.

Keep in mind that for privacy reasons this would have to be treated as a non-top level navigation. So things like 3rd party storage blocking and such would have to be applied. Webkit would probably want to partition any service worker interception a prefetch like this as if it was a 3rd party frame.

If the developer is using the document prefetch to prime possible navigations beyond the current page, is this really useful?

However, I'm wondering if we should define a "prefetch cache" below the SW, where prefetch requests would bypass the current SW entirely, and will go through SW only once the resource is used (by the future Document).

Where does it say to consult the prefetch cache? If it was tied to the request's internal client value then in theory we could allow passthrough evt.respondWith(fetch(evt.request)) consult the prefetch cache.

Of course implementation would have to deal with the client and service worker threads living in different processes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment