This document answers the questions from the W3C TAG Self-Review Questionnaire: Security and Privacy for the proposed moderate_viewport_heuristics extension to Speculation Rules.
Chromium's "moderate" eagerness speculation rules on mobile use a viewport-based heuristic to pick at most one on-screen link to prefetch/prerender each time the user stops scrolling. The heuristic has three tunable parameters:
distance_from_pointer_down— a[low, high]band, as a fraction of screen height, gating how far a candidate link may be from the user's lastpointerdown.largest_anchor_threshold— how much larger (by visible area) the largest candidate must be than the runner-up before it is chosen.delay— milliseconds to wait after choosing a candidate before acting on it (so links flying past during a fling don't get speculated on).
The proposal lets a page carry a top-level moderate_viewport_heuristics object inside a <script type="speculationrules"> block, overriding these three parameters (within clamped ranges). This is intended to be temporary and experimental, to help developers and the browser find better default values.
This feature only configures an existing browser behavior. It does not introduce a new capability to fetch or observe cross-origin resources beyond what "eagerness": "moderate" speculation rules already do.
None to the web. The feature is a one-way channel from the page to the user agent: the page provides configuration values; the user agent does not surface any new information back to the page.
- First party, new info: None.
- Third party, new info: None.
- First party, mirrored info: None.
- Third party, mirrored info: None.
There is an indirect effect: because the heuristic determines which links (if any) are speculatively fetched, the timing and existence of subresource requests to same- and cross-origin targets can be influenced by the page. However, "eagerness": "moderate" already grants the page this power at coarse granularity; this feature only fine-tunes the parameters within clamped safe ranges. The origin authoring the rules is the same origin that can already, e.g., insert <link rel=prefetch> or <link rel=prerender> / speculation rules for arbitrary URLs.
Yes. The feature exposes zero information back to the page. It only accepts configuration.
The set of tunable parameters is deliberately limited to the three that drive the current Chromium heuristic. No additional state (e.g., last pointerdown position, viewport dimensions, computed link sizes, whether a candidate was chosen) is surfaced to the page.
2.3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. The feature exposes no information to origins. It does not touch PII.
The feature does not handle sensitive information. It only accepts three numeric configuration values.
2.5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
Not applicable. No data is exposed.
No. The configuration lives inside a <script type="speculationrules"> element in a single document and has the same lifetime as the document. It is not persisted by the user agent across sessions and does not add any new client-side storage surface.
2.7. Do the features in your specification expose information about the underlying platform to origins?
No. No hardware, sensor, configuration, or capability information is exposed. The feature does not vary its behavior based on device attributes in a way that is observable from script (beyond the fact that the heuristic itself is only engaged in the existing "moderate" eagerness context, which was already the case before this proposal).
Note that moderate_viewport_heuristics is currently only meaningful in Chromium mobile contexts where the viewport heuristic is active. User agents that do not implement the heuristic are expected to ignore the field. The presence or absence of any behavioral effect could, in principle, be a very weak signal about UA/platform — but this signal is already trivially exposed via the existing eagerness behavior and standard UA/platform disclosure.
Only in the sense that the numeric parameters are passed into the browser's speculation-rules machinery. The values are:
- Clamped by the user agent (e.g.,
delayto[0, 5000]ms; band endpoints to[-1, 1];largest_anchor_threshold >= 0). - Purely numeric; no strings, URLs, or free-form data are conveyed.
The URLs that end up being prefetched/prerendered are drawn from the existing speculation-rules mechanism (href_matches, etc.); this feature does not add any new sink for URLs or other data.
No. The underlying heuristic reacts to scroll position, pointerdown location, and layout-computed link geometry — all of which are already fully available to pages via existing DOM/event APIs. This proposal does not surface any of that data to origins; it only adjusts thresholds used internally by the UA.
No new mechanism. Speculation Rules with "eagerness": "moderate" already trigger prefetching/prerendering of URLs the page declares. This feature adjusts when the existing mechanism fires. It does not permit prefetching or prerendering of any URL the page couldn't already have listed in the rule set.
No.
2.12. Do features in this specification allow an origin some measure of control over a user agent's native UI?
No. The feature does not alter UA chrome, prompts, or visible UI. Prefetch/prerender activation may become slightly earlier or later, but this is a performance characteristic, not UI control.
None.
2.14. How does this specification distinguish between behavior in first-party and third-party contexts?
The feature inherits the same context rules as the enclosing Speculation Rules spec. Speculation rules that trigger prefetch/prerender are typically only meaningful when declared by the top-level document; third-party iframes gain no additional capability from moderate_viewport_heuristics beyond what they already have with "eagerness": "moderate".
Because the field only tunes heuristic parameters, and because those parameters are clamped, it does not open a new avenue for third-party abuse.
2.15. How do the features in this specification work in the context of a browser's Private Browsing or Incognito mode?
Identically to non-private mode. The feature stores no state and reveals no information to the page, so it cannot be used to detect Private Browsing, nor does it leak state between private and non-private sessions.
User agents may choose to disable speculation entirely in Private Browsing (as they do for other network prefetches); if they do, moderate_viewport_heuristics becomes a no-op along with the rest of the mechanism. This is consistent with existing Speculation Rules behavior.
2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
No. No specification for this, as this is an experiment-only feature.
No.
2.18. What happens when a document that uses your feature is kept alive in BFCache after navigation, and potentially gets reused on future navigations back to the document?
The configuration is a property of the parsed <script type="speculationrules"> in a document and has the same lifetime as that document. On BFCache restore, the previously parsed heuristic parameters remain in effect for the restored document — which is the expected and desired behavior, since the rest of the speculation rules from that document also remain in effect. No cross-navigation leakage of the configuration occurs.
The feature does not add any privacy-sensitive event stream that would need to be paused for non-fully-active documents.
When the document becomes non-fully-active (e.g., its containing iframe is disconnected), the speculation-rules engine stops considering its rules, and the heuristic parameters carried by that document become moot along with the rest of the rules. There is no separate cleanup required.
No new error surface. Malformed values (non-numeric, out-of-range, wrong array length, unknown field names) are handled the same way as other malformed speculation-rules entries: the offending field is ignored / clamped, and the surrounding rule set continues to be parsed. Nothing about the parse outcome is reported back to script.
This is intentional: the feature is not a probe. A page cannot use it to learn whether a particular parameter is supported or in-range, because the observable side of the feature (whether a given link gets prefetched) is already inherent to "eagerness": "moderate" and can only be observed via the same channels developers already have (e.g., their own server logs).
No. The feature does not surface any information about input modality or AT usage. It only accepts configuration input from the page.
There is a second-order consideration worth naming: the underlying heuristic is driven by scroll position and pointerdown location. Users who navigate primarily with assistive technology may not trigger pointerdown in the usual pattern, in which case the heuristic simply does not fire (and no candidate is chosen). This proposal does not change that behavior — it inherits it from the existing "moderate" heuristic — and it does not add any way for the page to observe whether the heuristic fired.
For a feature like this one — a small, developer-facing knob that tunes an existing UA-internal heuristic — the most relevant questions the questionnaire could add are:
- "Does your feature give the page more precise control over resource-scheduling behavior that could be used as a covert channel or side channel?" For
moderate_viewport_heuristics, the answer is no beyond what"eagerness": "moderate"already permits, but this is a class of concern that isn't cleanly captured by any current question.