Request for Position: Fetch Metadata
Hi everybody, I'd like a position on the Fetch Metadata[0] spec. It is a security feature that provides extra context to fetch requests so that servers can make informed decisions. It is currently implemented by both Firefox and Chromium. I have started a work-in-progress patch[1] on bug 204744 for this. It currently implements Sec-Fetch-Dest, Sec-Fetch-Mode, and part of Sec-Fetch-Site. However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers. So I'd appreciate input on if there is interest in this. Thanks, Patrick [0] https://www.w3.org/TR/fetch-metadata/ [1] https://bugs.webkit.org/show_bug.cgi?id=204744 [2] https://www.w3.org/TR/fetch-metadata/#directly-user-initiated
On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers.
Looking more into this Firefox takes a more heuristic approach to figuring this out (was there a referrer and what is the request type) and if that approach works out for WebKit it wouldn't require any port-specific changes. Chromium itself does just ask the `ui` layer what type of "transition" caused the request which is more in-line with the spec.
I’m interested in this work, and would be happy to review patches. I noticed that Chrome and Firefox both implement it and we don’t. Some of the implementation might be a little involved, so I’m happy to answer questions and point in the right direction when I can. I’m not thrilled that it adds more bytes to each request, especially when using HTTP 1.1 where headers are not compressed. The day may also come when we need to either omit the metadata or send incorrect metadata for privacy or security reasons, but I haven’t thought it through well enough yet and I’m not aware of cases where that would be necessary right now.
On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev <webkit-dev@lists.webkit.org> wrote:
On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers.
Looking more into this Firefox takes a more heuristic approach to figuring this out (was there a referrer and what is the request type) and if that approach works out for WebKit it wouldn't require any port-specific changes. Chromium itself does just ask the `ui` layer what type of "transition" caused the request which is more in-line with the spec. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
I also think this is worth prototyping. Destination and mode are valuable and are hopefully not controversial, I would start with those two. I would also hope WPT coverage is good in that area and would cover both regular network loads as well as cache loads. Not sure how this would play with memory cache. Le lun. 21 févr. 2022 à 22:07, Alex Christensen via webkit-dev < webkit-dev@lists.webkit.org> a écrit :
I’m interested in this work, and would be happy to review patches. I noticed that Chrome and Firefox both implement it and we don’t. Some of the implementation might be a little involved, so I’m happy to answer questions and point in the right direction when I can.
I’m not thrilled that it adds more bytes to each request, especially when using HTTP 1.1 where headers are not compressed. The day may also come when we need to either omit the metadata or send incorrect metadata for privacy or security reasons, but I haven’t thought it through well enough yet and I’m not aware of cases where that would be necessary right now.
On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev < webkit-dev@lists.webkit.org> wrote:
On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers.
Looking more into this Firefox takes a more heuristic approach to figuring this out (was there a referrer and what is the request type) and if that approach works out for WebKit it wouldn't require any port-specific changes. Chromium itself does just ask the `ui` layer what type of "transition" caused the request which is more in-line with the spec. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
participants (3)
-
Alex Christensen
-
Patrick Griffis
-
youenn fablet