How can I get the top-level frame's origin in URLRequestHttpJob

347 views
Skip to first unread message

Steven Bingler

unread,
Aug 28, 2024, 6:02:37 PM8/28/24
to net...@chromium.org
Hello net-dev,

I'm trying to reliably get the top frame's origin within URLRequestHttpJob. I'm aware of `HttpRequestInfo::possibly_top_frame_origin()` and how it could sometimes be a site or nullopt instead of an origin. I already have one possible solution (see below) but I'm wondering if there's a better way.

For my use case I only care about requests that could result in an HSTS response header, `Strict-Transport-Security:`. Meaning that requests like DoH, browser internal stuff like the safebrowsing updates, etc aren't applicable.

After speaking with mmenke@ the current best idea is to check if cookies are allowed via `ShouldBlockAllCookies(request_info_.privacy_mode)`. Since only cookie-able requests should be capable of setting an HSTS header. Using `ShouldBlockAllCookies()` avoids checking the network delegate which could be blocking on a per-site basis.

Does anyone have any better ideas?

Thanks,
Steven


Adam Rice

unread,
Sep 3, 2024, 10:20:53 AM9/3/24
to Steven Bingler, net...@chromium.org
Is this for histograms? //net isn't supposed to know about things like frames (as much as possible), so I'm not keen to add more knowledge. Can it be implemented somewhere else?

--
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/CAKdrzHBnCJ-%3DqH5%2BLK7OsQcqB%3DQ59T9hC5k5ERr5Ku3SBSErgw%40mail.gmail.com.

Steven Bingler

unread,
Sep 3, 2024, 4:14:24 PM9/3/24
to Adam Rice, net...@chromium.org
It's for HSTS, net/http/http_security_headers.cc

In short, to implement tracking mitigates it's important to make sure that a HSTS response can only be set for the current hostname or the entire hostname.

Adam Rice

unread,
Sep 10, 2024, 11:46:31 AM9/10/24
to Steven Bingler, net...@chromium.org
Is there some reason why partitioning by NetworkAnonymizationKey or NetworkIsolationKey would be an insufficient solution?

Steven Bingler

unread,
Sep 10, 2024, 4:33:10 PM9/10/24
to Adam Rice, net...@chromium.org
Mostly because blocking third-party HSTS can be accomplished more simply for comparable security benefits. It also aligns matches with what other browsers (Firefox, Safari) are doing which is nice for consistency.

- Steven

Adam Rice

unread,
Sep 12, 2024, 10:23:05 AM9/12/24
to Steven Bingler, net...@chromium.org
In that case I would prefer to have a IGNORE_STS_HEADER load flag and let the web-platform-aware code in //network/services take care of setting it when needed.

Steven Bingler

unread,
Sep 20, 2024, 3:29:34 PM9/20/24
to Adam Rice, net...@chromium.org
Following up,

Thanks for the suggestion, but the design changed enough that getting this information isn't a requirement any longer.

- Steven
Reply all
Reply to author
Forward
0 new messages