Ephemeral navigation portals

[jeremyroman]

@jakearchibald has previously proposed in a few places that it be possible to load a portal which would have immediate access to its first-party storage in exchange for a UA-enforced guarantee that it will be activated within some fixed timeframe (say, five seconds). This could be hooked onto existing content-initiated navigations (e.g. links, form submissions) through a hypothetical navigate event, which would look something like:

partial interface NavigateEvent {
  HTMLPortalElement createPortal();
};

I suspect we'd need a few more features if we took such a direction, like telling the author what the deadline is and letting them observe the result of an implicit activation (esp. if it can be rejected).

dictionary EphemeralNavigationPortalInfo {
  HTMLPortalElement portalElement;
  DOMHighResTimeStamp deadline;
  Promise<void> activated;
};

// or a similar exposure on NavigateEvent, if we're willing to also commit to figuring out the implications of intercepting navigations (e.g. what happens to ones initiated from other frames)
partial interface Window {
  EphemeralNavigationPortalInfo createPortalForNavigation(RequestInfo navigationRequest);
};

Either way, I think there are some open questions, especially since we can't actually guarantee that the forced activation will actually be possible. For instance, the request could result in a 204 No Content response, a network or TLS error, abort (including via AbortController if we allow that to be configured on the request), etc. after a credentialed request has already been sent, and of course we could need to cancel due to a concurrent navigation being initiated.

If the conditions for doing this are similar to initiating a navigation that might result in a 204 response, then we may be okay but I think there are details that merit investigation if we want to pursue something along these lines.

[jakearchibald]

Ohhh I hadn't considered something like createPortalForNavigation. It removes (or decouples) the need for the navigate event. I still think we want a navigate event on the platform at some point, but I guess we can think about that later, or leave it to someone else 😄.

For instance, the request could result in a 204 No Content response,

I think the "risky time" for a portal like is, is when it can run script, and it isn't top level. So, createPortalForNavigation could return a promise that fulfills once we have a response we can work with. Is the result of a normal navigation would be a no-op (due to CSP, Content-Disposition, or 204 (do we no-op in that case?)), the promise could reject.

The promise would reject with an abort error if the navigation is stopped or cancelled somehow, like the user hitting the stop button, or another navigation taking priority.

EphemeralNavigationPortalInfo could also include an AbortSignal, which triggers if the navigation is aborted after the portal has been vended.

+1 to deadline.

I'm less sure about activated, since you wouldn't expect this page to be running script at that point anyway.

Need to think of how this would fit in with the restore callback and other activate options. Maybe they need to be given to createPortalForNavigation.

[jeremyroman]

If activation can fail in a way that keeps the page presented, I think activated is necessary to observe the reason for that. Even in the success case, you could later be pulled from bfcache, so even though you could add a once listener to pagehide/pageshow to observe that, it seems less ergonomic.

The idea of having the result not resolve until a document commits is interesting, though it is kinda equivalent to having the portal element have a promise that resolves when a document commits (which is similar to the contentPainted promise discussed on another issue).

[jakearchibald]

so even though you could add a once listener to pagehide/pageshow to observe that, it seems less ergonomic.

The restore callback would provide the ergonomic way to detect that, no?

The idea of having the result not resolve until a document commits is interesting, though it is kinda equivalent to having the portal element have a promise that resolves when a document commits

Yeah, a value on the portal is probably better. It's ok to add it to third party portals, because you can already access this timing with iframes. It's ok to add it to createPortalForNavigation first-party portals because you can already access this timing with pagehide on navigation.

[jyasskin]

This interacts with the mitigations identified in #208 as "Blocked by preventing fetches within portals from using credentials until they're activated". That needs at least one extra mitigation here:

• an attack based on a sequence of portal loads is possible if the page can repeatedly call createPortalForNavigation('gen204_bit0') and createPortalForNavigation('gen204_bit1'). Because this would never result in a navigation, it's not covered by the existing transfer-on-navigation in https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition even though it does require a modification to server processing. Is it feasible to say that a page can only call this function once in its lifetime?

• A response whose timing or status code depends on the user's ID is, I think, less powerful than the ability to encode a whole user ID in the path, called out in https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition. So this one probably doesn't need any mitigation.

[jakearchibald]

Is it feasible to say that a page can only call this function once in its lifetime?

Can we do whatever we do for repeated assignments to window.location.href?

[jeremyroman]

The mitigations that had previously been proposed were to require a user gesture and for the UA to activate such a portal if the document doesn't do so within some window (and it isn't cancelled by some other navigation -- I haven't given window.stop much thought).

Saying you can only do so once for a page's lifetime seems infeasible -- because it would preclude any further outgoing navigations after restoring from bfcache or similar.

What about, as @jakearchibald says, whatever mitigation is appropriate for the page navigating itself to URLs that serve 204 responses?

[jakearchibald]

Not just 204 responses, it could be a never-response, which the browser can't really distinguish from a slow response, except via timeouts.

[jyasskin]

It makes sense to plan to match whatever we wind up doing for assignments to window.location.href. I've asked the anti-tracking folks to come up with a plan for that, and I don't think it needs to block Portals.