When to fallback redirect? #397
Comments
|
/cc @twifkak for consumer side feedback |
|
Thanks for opening the issue. Sorry for the delay; I've been sick and this slipped my radar. As a consumer & distributor, my product preference is to make as many things as possible a fallback. That said, I understand there may be reasons not to prefer that, and I would like to know more about them:
From your list above, I think there are some that I would feel safe removing fallback for today:
Essentially these are all the "outer exchange" things that are well-trodden and I feel confident we'll do correctly; also, they require that we generate the correct response rather than that we validate (but don't modify) a given response. I'm also okay with not falling back for Merkle integrity (this one was simple enough to check) or parse error (fallback seems dangerous). For a distributor with the privacy-preserving-prefetch use case, the downsides of having a network error page are:
The potential reasons that our cache may serve an invalid SXG include:
At this point, I'm mostly worried about the first two. But I'm mostly guessing. After #374 (and after we implement server-side monitoring of those reports), I'll be able to respond more usefully. |
|
(I'm presuming that the fallback for SXG version mismatch happens before the network error for MICE decode failure. Otherwise, future Chromium versions will need to continue supporting old MICE versions.) |
|
Thank you for collating all the error cases so we can just go through them. My suggestion is:
I basically want anything the distributor could catch to be an Error, while anything that clients might vary on (mostly time & crypto validity) should fall back. @sleevi, how do you feel about this list? |
At first glance, that sounds like a great principle and I think your analysis is reasonable and spot-on. Signature isn’t valid seems a reasonable error? |
|
@sleevi https://wicg.github.io/webpackage/loading.html#validating-signature includes the check against the client's clock (which I think should definitely fall back) and the check that it's a secp256r1 key (where I want to have clients fall back when they remove broken crypto, but maybe we should do that with a version increment instead). We should also make sure that the reporting API distinguishes between the cases that error vs fall back. Right now there are distinctions in the table above that aren't captured in the reporting API results. |
|
Yeah, the approach for changing crypto primitives was definitely seen as a version-bumpable thing. Perhaps it's worth splitting out "validate a signature" and "validate the timestamp" as two separate things, the former being an error, the latter being a fallback? |
|
Initial NEL analysis from AMP Cache is available to Googlers in http://b/126787670. Overall, error rate is relatively low, but I'd say not low enough to serve network errors in all cases. The two most prevalent errors are cert_fetch_error & mi_error. My understanding is that these can be due to a bad connection, which is beyond the control of the distributor (e.g. may be due to ISP issues or spotty cell coverage). I'm thinking that these cases should continue to fall back. Otherwise, spotty connnections would disproportionately affect SXG, because browsers are willing to render unsigned HTML that was truncated or had failed subresources. Are there downsides to falling back in these cases? |
|
Cert Fetch Errors are more similar to failures to fetch AIA (which causes
hardfail) or OCSP (for which behaviour varies between browsers), right?
As to whether it’s safe, the analysis would be:
- Identifying all the information an adversary could learn by observing the
fallback occurred
- Identifying whether and how that information might already be available
- Identifying how that information could be abused
- Identifying what the process would be if we “got it wrong” in the
analysis (in this case, what the implications would be if a browser had to
suddenly switch to block)
|
|
Reg. mi_error: From the implementation's POV, browser sends SXG's inner response header to the renderer as soon as the SXG header is validated. Merkle integrity error is detected after that, so it's too late to chagne the response to 303 redirect at that pont. |
|
cert_fetch_error: My instinct is that a failure to fetch the certificate from the same origin that's already transferring the signed exchange is similarly likely to a failure to fetch the signed exchange itself or the content from the publisher. Since we don't auto-reload on a network error, we shouldn't auto-redirect on one either. mi_error:
|
IIUC, currently both a
Chrome works in this way, although it's not guaranteed that response is loaded to the last validated chunk (internal buffer is discarded upon network error). |
I agree. |
|
Thanks for the clarifications; looks like I misunderstood what |
Add: * An invariant fallback URL, like signed exchanges have. * A version number, so we can easily know to fall back to a redirect. * Some infrastructure to identify what kind of error broke the parse, which can feed into both Network Error Logging and #397’s discussion of when to fall back. * The index maps URLs to a Variants value + a list of the responses for each possible Variant-Key, instead of using a set of request headers. * A new signatures section allows authorities to vouch for particular subsets of the bundle. This document doesn't describe how a user agent would decide to trust cross-origin resources based on which authority vouches for them.
In the current loading spec, redirect to the fallback URL happens only when the signed exchange version is not supported.
However, Chromium implementation performs fallback redirect in the following cases (corresponding to the error codes here):
X-Content-Type-Options: nosniffheader.Chromium doesn't fallbeck on the following errors:
We should clarify that which error should cause a fallback redirect, and spec them.
The text was updated successfully, but these errors were encountered: