Prefetch Cache - Cookie Keying

292 views
Skip to first unread message

Jeremy Roman

unread,
Feb 21, 2024, 11:05:42 AMFeb 21
to net-dev
I'm currently prototyping allowing the prefetch cache to take cookie values into account, and wanted to run it by some networking folks before I go too much further, in case there's a better approach. Mind taking a look at my lightweight doc?

https://docs.google.com/document/d/1QvOGdOfPvbGMAzwpdIdFO51tcFgWx6rXZ6oPe3TbsRU/edit

It's slim on details internal to the prefetching code because I don't expect it to be architecturally complex -- I'm mostly interested in the net/ and services/network/ bits right now.

Thanks!

Matt Menke

unread,
Feb 21, 2024, 11:32:13 AMFeb 21
to Jeremy Roman, net-dev
I don't think we can pass cookie headers to the renderer.  We deliberately hide cookies from the renderer so renderers can't access 3P cookies, and HTTP cookies, which are not accessible by the renderer, exist exactly to prevent third parties with scriptable access to the renderer from stealing a site's cookies.   I'm also skeptical we want to expose more information about third party network requests more generally to renderer code.  Totally not my area, but I think anything that allows sending request headers to the renderer is likely a non-starter.  Perhaps it could be allowed for "trusted" URLLoaderFactories only, though, which means browser-managed fetches only (like navigations).

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACuR13eaQr9niAO219kyyRQrgEmEVNZCtYLmFn7ypv%2BeH4RHDw%40mail.gmail.com.

Jeremy Roman

unread,
Feb 21, 2024, 12:20:34 PMFeb 21
to Matt Menke, net-dev
I'm not proposing to pass it to the renderer; this prefetch code runs in the browser process. If there are any additional measures required to prevent a renderer from getting its hands on it, I'd be interested in knowing.

Matt Menke

unread,
Feb 21, 2024, 2:49:40 PMFeb 21
to Jeremy Roman, net-dev
You're adding an option to URLLoaderFactory::CreateLoaderAndStart(), which is the API the renderer uses to load resources, so just adding the API directly will give renderers that capability.  I think a setting would have to be added to URLLoaderFactories to allow the new behavior (or just reuse the is_trusted bit to allow the new option - and ideally put it in ResourceRequest::TrustedParams, which will automatically make it so untrusted URLLoaderFactories don't have access).  I don't know if the URLLoaderFactories used by prefetch are already considered trusted, if not, have to change that, too.

Jeremy Roman

unread,
Feb 21, 2024, 4:47:17 PMFeb 21
to Matt Menke, net-dev
On Wed, Feb 21, 2024 at 2:49 PM Matt Menke <mme...@chromium.org> wrote:
You're adding an option to URLLoaderFactory::CreateLoaderAndStart(), which is the API the renderer uses to load resources, so just adding the API directly will give renderers that capability.  I think a setting would have to be added to URLLoaderFactories to allow the new behavior (or just reuse the is_trusted bit to allow the new option - and ideally put it in ResourceRequest::TrustedParams, which will automatically make it so untrusted URLLoaderFactories don't have access).

Latest patchset and updated doc send the bit through trusted_params instead.
 
I don't know if the URLLoaderFactories used by prefetch are already considered trusted, if not, have to change that, too.

Yes, they are.

Matt Menke

unread,
Feb 21, 2024, 5:32:49 PMFeb 21
to Jeremy Roman, net-dev
Great, I think that should completely address my concern!  I can't really comment usefully on the proposal in general.
Reply all
Reply to author
Forward
0 new messages