Intent to Prototype: Supports-Loading-Mode opt-in

86 views
Skip to first unread message

Jeremy Roman

unread,
Oct 21, 2020, 2:42:14 PM10/21/20
to blink-dev

Contact emails

jbr...@chromium.org

Explainer

https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/opt-in.md

Specification

None

Summary

Allows documents to declare their support for new loading modes, such as upcoming enhanced privacy prefetching and prerendering. https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/opt-in.md


Blink component

Blink (at least for now; will likely move to Internals>Preload, Blink>Portals, or a new component)

Motivation

Because prerendering fetching modes intentionally obscure the user's identity, the response document cannot be personalized for the user. If it is used when the user navigates, the user will notice that they are not logged in (even if they should be), and other surprising behavior. Similarly, prerendering browsing contexts allow HTML parsing, subresource fetching, and script execution, but such actions are restricted to avoid identifying the user or causing user-visible annoyance. Pages designed with these restrictions in mind can "upgrade" themselves when they load, by personalizing based on data in unpartitioned storage and by fetching personalized content from the server. But existing web pages are unlikely to behave well with these restrictions today. (And, it is impractical for user agents to distinguish such pages.) As such, we propose a lightweight way for a page to declare that it is prepared for such prerendering, and will, if necessary, upgrade itself when it gains access to unpartitioned storage and other privileges.



Initial public proposal

https://github.com/WICG/proposals/issues/2

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal
WebKit: No signal
Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Contingent on dependent features such as prerendering and portals.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1141083

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5762115363143680

This intent message was generated by Chrome Platform Status.

Jeremy Roman

unread,
Oct 21, 2020, 3:51:46 PM10/21/20
to blink-dev
Implementation design doc is under review.

yo...@yoav.ws

unread,
Oct 22, 2020, 11:42:52 AM10/22/20
to blink-dev, Jeremy Roman
On Wednesday, October 21, 2020 at 9:51:46 PM UTC+2 Jeremy Roman wrote:
Implementation design doc is under review.

On Wed, Oct 21, 2020 at 2:41 PM Jeremy Roman <jbr...@chromium.org> wrote:

Contact emails

jbr...@chromium.org

Explainer

https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/opt-in.md

Specification

None

Summary

Allows documents to declare their support for new loading modes, such as upcoming enhanced privacy prefetching and prerendering. https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/opt-in.md


Blink component

Blink (at least for now; will likely move to Internals>Preload, Blink>Portals, or a new component)

Motivation

Because prerendering fetching modes intentionally obscure the user's identity, the response document cannot be personalized for the user. If it is used when the user navigates, the user will notice that they are not logged in (even if they should be), and other surprising behavior. Similarly, prerendering browsing contexts allow HTML parsing, subresource fetching, and script execution, but such actions are restricted to avoid identifying the user or causing user-visible annoyance. Pages designed with these restrictions in mind can "upgrade" themselves when they load, by personalizing based on data in unpartitioned storage and by fetching personalized content from the server. But existing web pages are unlikely to behave well with these restrictions today. (And, it is impractical for user agents to distinguish such pages.) As such, we propose a lightweight way for a page to declare that it is prepared for such prerendering, and will, if necessary, upgrade itself when it gains access to unpartitioned storage and other privileges.



Initial public proposal

https://github.com/WICG/proposals/issues/2

TAG review

None

It may make sense to kick off an early review.
Reply all
Reply to author
Forward
0 new messages