Avoiding syncronous manifest requests in EPR

One thing that's come up in discussing EPR with the webappsec group is the
corner case requiring a synchronous request.  Specifically, nobody seems to
like synchronous requests.  :-)

The problematic scenario is involves mitigating XSS on the very first
request to a site, when no manifest exists in the EPR manifest cache.

(XSRF is already assumed to be impossible to mitigate, but less important
here because it requires the user to be auth'd, which won't generally be
the case until there is also an EPR manifest present.)

I believe there are a number of caveats that make the synchronous request
not so bad:

1)  The attack we're trying to mitigate (XSS) is only possible on a
navigation, not a resource request.

2)  It's essentially just a one-time thing per-domain.  Once a manifest is
cached there is no need to fetch the manifest synchronously until it
expires from the cache.

3)  It's only for sites that have opted-in to EPR via a header.  It would
not affect existing web sites.

Nevertheless, it sounds like a sync request may be a non-starter, so I'm
brainstorming some alternatives.

Consider this approach:

If X-EPR exists on the response
  AND it's a navigation (as opposed to a resource request)
  AND the navigation was initiated by a web site, not by the user typing in
the address bar or picking a bookmark
  AND no cached manifest exists
THEN enforce NO DATA.

NO DATA implies the request must not contain data in the querystring, hash,
or POST body.  Of course the request has already gone out, but the response
will be blocked (or redirected), not rendered in the browser.

With that in place we can do a lazy manifest download, no sync requests
necessary.

You could undoubtedly point to scenarios where there will be breakage with
this scheme.  Ultimately EPR is opt-in though.  I think if we walk through
various scenarios we'll still wind up better off with EPR, and it will also
be possible for sites to take action to avert any potential breakage.

Dave