Sec-Fetch-Site shouldn't come from untrustworthy renderers |
||||
Issue descriptionSec-Fetch-Site currently comes from the following 3 places: 1. content/browser/worker_host/worker_script_fetch_initiator.cc - browser - good! 2. content/browser/frame_host/navigation_request.cc - browser - good! 3. third_party/blink/renderer/core/loader/base_fetch_context.cc - renderer - bad! We should move #3 to the NetworkService process (where it can be based on |request_initiator_site_lock|).
,
Today
(11 hours ago)
,
Today
(11 hours ago)
+mmenke@, +jam@ for NetworkService questions +toyoshim@ because OOR-CORS probably is/was in a similar situation Currently Sec-Fetch-Site is hidden behind blink::RuntimeEnabledFeatures::SecMetadataEnabled() (this is an "experimental" feature according to third_party/blink/renderer/platform/runtime_enabled_features.json5). How would one spell that "is Sec-Metadata feature enabled" check inside the NetworkService world? I guess we would need a new, separate base::Feature for that?
,
Today
(11 hours ago)
,
Today
(10 hours ago)
You'd need to pass it to net through a new API (Assuming it isn't constant for the lifetime of Chrome, in which case, it could be passed as a command line flag, I guess). Using base::Feature isn't really a great way to pass configuration data to the network service, unless it's something that's experimental but we're planning to always have on in the future. |
||||
►
Sign in to add a comment |
||||
Comment 1 by lukasza@chromium.org
, Today (11 hours ago)Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows