Re: [w3ctag/design-reviews] Incubation: speculation rules `form_submission` field for prerendering (Issue #1192)

xiaochengh left a comment (w3ctag/design-reviews#1192)

Hi @robertlin-chromium, the TAG discussed this at a Breakout. Allowing search result pages to be prerendered looks like an important use case to us, and we'd like to see more work in this direction. We also have the following comments.

### Security and privacy

We found that this feature requires more security and privacy considerations than the existing speculation rules. Form data usually contains user input, and therefore, allowing form submission navigations to be prefetched/prerendered introduces a new way to expose user's sensitive information. The situation can be even worse if autofilled data is exposed. We'd like to see the privacy and security considerations section reworked.

### API design

1. It's unclear why the `form_submission` field is needed. The [alternatives considered](https://github.com/WICG/nav-speculation/blob/main/prerendering-form-submission.md#design-considerations-and-alternatives-considered) section gives two reasons: (1) to lift certain internal restrictions of Chrome, and (2) to avoid resource wasting. Neither requires spec changes as they can be fixed or optimized by the UA internally.

2. Backward compatibility design. When a UA that doesn't support this feature parses a rule with a `form_submission` field, how does it fall back? Does it ignore the field as treat it as a normal rule, or discard the rule completely? 

3. The [find matching links](https://html.spec.whatwg.org/multipage/speculative-loading.html#find-matching-links) algorithm currently only covers `<a>` and `<area>`, and we need to augment it to cover form submission URLs. This is not mentioned by the explainer.

### Eagerness

Unlike `<a>` and `<area>`, whose URLs are pretty much static, form submission URLs often include user input and are much more dynamic. The eagerness of such speculative loads must be carefully designed, otherwise the feature may either lead to huge resource waste or little effect.

For example, we don't want to prerender /search?q=f and /search?q=fo while the user is typing foo in the search field; but if we wait too long after the user finishes typing, they may have already hit the "Search" button and it's too late for us to start prerendering.

Since the eagerness strategy can be critical to the success of the feature, we'd like the spec to include more details instead of leaving everything as UA implementation internals.

### Minor comments regarding the explainer

1. The example, with duplicate `"prerender"` keys, is not a valid JSON as required by the [spec](https://html.spec.whatwg.org/multipage/speculative-loading.html#speculation-rules). We'd like to see a better example.
2. https://issues.chromium.org/issues/346555939 is filed by the Chrome team with only 2 stars. Is there a stronger reference for developer support?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1192#issuecomment-3962365845
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1192/3962365845@github.com>