PSA: private prefetch proxy proposal

394 views
Skip to first unread message

Kenji Baheux

unread,
Dec 7, 2020, 7:11:43 PM12/7/20
to blink-dev, Michael Buettner

bcc: chromium-dev


Hi,


We’ve just shared details about a new proposal that aims at speeding up navigations by downloading resources ahead of time, i.e. prefetching. 


The proposal defines the concept of a private prefetch proxy which consists of an end-to-end encrypted CONNECT proxy to hide potentially identifiable information (e.g. user’s IP address), as well as rules governing its usage, and additional measures to ensure that the prefetches can not be personalized to the user.


This proposal builds on previous work and is part of a long term effort designed to dramatically speed up navigations, across the whole web, through improved prefetching and pre-rendering techniques that are privacy and developer friendly. We are eager to work with the community on refining and generalizing the proposal for the benefit of the whole web.


While this barely scratches the surface, we have identified some challenges / open-questions for a viable web platform path. This ranges from tactical aspects to operational matters. For example:

  • Defining a way for pages to declare themselves capable of being prefetched/pre-rendered without credentials, and capable of updating the user experience upon gaining access to their storage on navigation (e.g. see the Alternate Loading Modes proposal). 

  • Who can run such a prefetch proxy? Who can specify which prefetch proxy to use for a given situation? What are the privacy properties and operational implications of the various possibilities (e.g. run and/or specified by the browser / referrer site / user / target site)?


If you are interested in the space, we’d love to hear your feedback and suggestions via this repo!



Sidebar

If you are familiar with Signed Exchange (SxG), you may also wonder what are the differences given that SxG can also be used for privacy preserving prefetch use cases. SxG has quite a few advantages, and unique use cases, over the prefetch proxy approach. Let’s mention a few:

  • Data costs saving for developers. SxG allows a third party to serve the content on your behalf with integrity and authenticity guarantees (i.e. your content can’t be modified and remain attributed to your origin). This provides opportunities for developers to minimize their data costs by offsetting a fraction of their traffic onto SxG caches.

  • Improved availability. Third parties can serve SxG to improve the availability of popular or critical content when the origin servers can’t keep up with the demand.

  • Precaching. SxG allows an application to fetch and cache content/apps ahead of time. This in turn enables experiences that are reliably fast, as opposed to on-demand prefetching/prerendering of most likely items which leads to user experiences with higher variance. This also enables experiences that are more resilient to a flakey connection. Some examples of applications that would benefit from this: news aggregation, discovery apps with instant mini-apps or games.


In other words, while Signed Exchange requires extra setup and work compared to the prefetch proxy approach, it’s nonetheless a viable, readily available (and sometimes trivial), option for privacy preserving prefetching with unique benefits and use cases that we hope will appeal to many developers.



Thanks!



--
Kenji BAHEUX
Product Manager - Chrome
Google Japan
Reply all
Reply to author
Forward
0 new messages