From ryanhaddad at apple.com Fri Jul 5 14:15:04 2024 From: ryanhaddad at apple.com (Ryan Haddad) Date: Fri, 05 Jul 2024 14:15:04 -0700 Subject: [webkit-dev] merge-queue / commit-queue downtime starting Friday July 5, 2024 @ 7:00 PM PDT Message-ID: Due to underlying infrastructure maintenance, merge-queue / commit-queue will be taken offline between Friday July 5, 2024 @ 7:00 PM through Saturday July 6, 2024 @ 12:00 PM PDT. EWS will remain operational during this time, and anything labeled for merge-queue will be processed as soon as the service comes back online. Thank you, Ryan From achristensen at apple.com Fri Jul 12 15:19:49 2024 From: achristensen at apple.com (Alex Christensen) Date: Fri, 12 Jul 2024 16:19:49 -0600 Subject: [webkit-dev] Deprecate webkit_web_page_get_main_frame? Message-ID: In https://github.com/WebKit/WebKit/pull/30763 I?m deprecating injected bundle frame access interfaces as part of the site isolation development. Would glib API maintainers be willing to deprecate webkit_web_page_get_main_frame to discourage its adoption and indicate plans to remove it at some point in the future? I?ve kept the functionality for now because we are still moving off it, but at some point that will be complete and it would be nice to remove bundle frame access together. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgarcia at igalia.com Mon Jul 22 03:31:55 2024 From: cgarcia at igalia.com (Carlos Garcia Campos) Date: Mon, 22 Jul 2024 12:31:55 +0200 Subject: [webkit-dev] Deprecate webkit_web_page_get_main_frame? In-Reply-To: References: Message-ID: Hi Alex, sorry for the delay to reply, I was on vacation last week.? So, we mainly use the frame object to get its javascript context, so what's the plan for that? I mean, it's only the api to get the main frame what's going to be deprecated or the frame object entirely? In most of the cases we get the frame from the script world on the window- object-cleared event, so we can probably deprecate get_main_frame(). I think it's only used in epiphany and evolution, but I would need to check how it's used there. El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev escribi?: > In?https://github.com/WebKit/WebKit/pull/30763?I?m deprecating > injected bundle frame access interfaces as part of the site isolation > development. ?Would glib API maintainers be willing to deprecate > webkit_web_page_get_main_frame to discourage its adoption and > indicate plans to remove it at some point in the future? ?I?ve kept > the functionality for now because we are still moving off it, but at > some point that will be complete and it would be nice to remove > bundle frame access together. > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From achristensen at apple.com Tue Jul 23 11:51:36 2024 From: achristensen at apple.com (Alex Christensen) Date: Tue, 23 Jul 2024 12:51:36 -0600 Subject: [webkit-dev] Deprecate webkit_web_page_get_main_frame? In-Reply-To: References: Message-ID: <8AE327A2-F97E-4405-BED9-633894E4F4F1@apple.com> We definitely have a lot of work to do, but the plan is to make UI process driven replacements for all uses of the injected bundle. It?s a large problem without a currently completely known solution, but we?re working on it and welcome collaboration from people working on webkit-based browsers on other platforms. I?m pushing to deprecate things to discourage further adoption of things we are planning to remove, even before we have a complete replacement plan. > On Jul 22, 2024, at 4:31?AM, Carlos Garcia Campos via webkit-dev wrote: > > Hi Alex, > > sorry for the delay to reply, I was on vacation last week. > > So, we mainly use the frame object to get its javascript context, so > what's the plan for that? I mean, it's only the api to get the main > frame what's going to be deprecated or the frame object entirely? In > most of the cases we get the frame from the script world on the window- > object-cleared event, so we can probably deprecate get_main_frame(). I > think it's only used in epiphany and evolution, but I would need to > check how it's used there. > > El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev > escribi?: >> In https://github.com/WebKit/WebKit/pull/30763 I?m deprecating >> injected bundle frame access interfaces as part of the site isolation >> development. Would glib API maintainers be willing to deprecate >> webkit_web_page_get_main_frame to discourage its adoption and >> indicate plans to remove it at some point in the future? I?ve kept >> the functionality for now because we are still moving off it, but at >> some point that will be complete and it would be nice to remove >> bundle frame access together. >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev at lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > Carlos Garcia Campos > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev From mcatanzaro at redhat.com Tue Jul 23 14:17:53 2024 From: mcatanzaro at redhat.com (Michael Catanzaro) Date: Tue, 23 Jul 2024 15:17:53 -0600 Subject: [webkit-dev] Deprecate webkit_web_page_get_main_frame? In-Reply-To: <8AE327A2-F97E-4405-BED9-633894E4F4F1@apple.com> References: <8AE327A2-F97E-4405-BED9-633894E4F4F1@apple.com> Message-ID: On Tue, Jul 23 2024 at 12:51:36 PM -06:00:00, Alex Christensen via webkit-dev wrote: > We definitely have a lot of work to do Yes, this seems tough. I wonder if we could introduce something like WebKitWebPageProxy and WebKitFrameProxy to replace WebKitWebPage and WebKitFrame.... From cgarcia at igalia.com Wed Jul 24 00:35:43 2024 From: cgarcia at igalia.com (Carlos Garcia Campos) Date: Wed, 24 Jul 2024 09:35:43 +0200 Subject: [webkit-dev] Deprecate webkit_web_page_get_main_frame? In-Reply-To: <8AE327A2-F97E-4405-BED9-633894E4F4F1@apple.com> References: <8AE327A2-F97E-4405-BED9-633894E4F4F1@apple.com> Message-ID: El mar, 23-07-2024 a las 12:51 -0600, Alex Christensen escribi?: > We definitely have a lot of work to do, but the plan is to make UI > process driven replacements for all uses of the injected bundle.? > It?s a large problem without a currently completely known solution, > but we?re working on it and welcome collaboration from people working > on webkit-based browsers on other platforms.? I?m pushing to > deprecate things to discourage further adoption of things we are > planning to remove, even before we have a complete replacement plan. > Ok, sounds good to me. We are of course happy to collaborate on this, so count on us for whatever we can do to help. > > On Jul 22, 2024, at 4:31?AM, Carlos Garcia Campos via webkit-dev > > wrote: > > > > Hi Alex, > > > > sorry for the delay to reply, I was on vacation last week. > > > > So, we mainly use the frame object to get its javascript context, > > so > > what's the plan for that? I mean, it's only the api to get the main > > frame what's going to be deprecated or the frame object entirely? > > In > > most of the cases we get the frame from the script world on the > > window- > > object-cleared event, so we can probably deprecate > > get_main_frame(). I > > think it's only used in epiphany and evolution, but I would need to > > check how it's used there. > > > > El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit- > > dev > > escribi?: > > > In https://github.com/WebKit/WebKit/pull/30763?I?m deprecating > > > injected bundle frame access interfaces as part of the site > > > isolation > > > development.? Would glib API maintainers be willing to deprecate > > > webkit_web_page_get_main_frame to discourage its adoption and > > > indicate plans to remove it at some point in the future?? I?ve > > > kept > > > the functionality for now because we are still moving off it, but > > > at > > > some point that will be complete and it would be nice to remove > > > bundle frame access together. > > > _______________________________________________ > > > webkit-dev mailing list > > > webkit-dev at lists.webkit.org > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > -- > > Carlos Garcia Campos > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev at lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- Carlos Garcia Campos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rniwa at apple.com Mon Jul 29 13:32:39 2024 From: rniwa at apple.com (Ryosuke Niwa) Date: Mon, 29 Jul 2024 13:32:39 -0700 Subject: [webkit-dev] Runtime guarding IPC receivers / messages by [EnabledBy=X] in messages.in Message-ID: <214A57EF-8984-404E-84D3-737FDC6398ED@apple.com> Hi all, I?ve recently added a mechanism to filter IPC messages based on which features are enabled at runtime. By adding `[EnabledBy=X]` either to a whole message receiver or on an individual IPC message, we can enable IPC messages only when feature X is enabled at runtime. Note that to use this feature, a new entry `sharedPreferenceForWebProcess: true` needs to be added to UnifiedWebPreferences.yaml. Why do we want to do that you may ask? It?s to protect UI, Network, and GPU processes from a compromised WebContent process. By restricting IPC messages/receivers at runtime, we dramatically reduce the attack surface available to the malicious code in WebContent process. So if you?re adding a new IPC message receiver or a new IPC message, please runtime guard each IPC receiver / message with `[EnabledBy=X]` when possible. - R. Niwa -------------- next part -------------- An HTML attachment was scrubbed... URL: