May 2025 - webkit-dev - lists.webkit.org

InjectedBundle deprecation
by Alex Christensen 01 Aug '25

01 Aug '25

Hello WebKit developers! We are ramping up to do some serious work on Site Isolation which includes putting cross-origin iframes in a different process than the parent frame. Similar efforts have been done in other browser engines and some related work has already been done in WebKit, but not enough. This will do strange things to the InjectedBundle APIs, which have fundamental assumptions that the whole DOM is in one process and that communication only happens with one process at a time. We have never exposed InjectedBundle APIs as public API, but some other distributors of WebKit have. As we make progress on this project, we anticipate that anything in Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation and removal. This will also allow us to tighten the sandbox on the web process, resolve security and performance issues, and have cleaner code. Would the maintainers of the GTK and WPE APIs be willing to assist in migrating from those APIs and designing replacements in the UI process? Alex Christensen

5 17

Site isolation
by Alex Christensen 01 Aug '25

01 Aug '25

The SiteIsolation feature is beginning to work in the simplest of cases, but I had to do some work in the Source/WebKit/Shared/RemoteLayerTree directory, which is platform-specific. Basically all the use of LayerHostingContextIdentifier in that directory needs an equivalent implementation for other graphics implementations, like in the CoordinatedGraphics directories. There is one layout test in LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently skipped on all non-Cocoa platforms. Is someone willing to collaborate to design and implement the feature in non-Cocoa ports? We are in the early stages of the project and have a long way to go, so I imagine things will continue to come up, like deciding how to implement event handling and other platform dependent features. Alex

3 6

Re: [webkit-dev] Interest in supporting cryptographically-generated domain names?
by Matthew Finkel 16 May '25

16 May '25

Hi Demi, Interesting idea! Comments in-line: > On May 4, 2025, at 5:52 PM, Demi Marie Obenour via webkit-dev <webkit-dev(a)lists.webkit.org> wrote: > > A major limitation of the Web PKI is that it cannot issue certificates > for devices that do not own a public domain name or IP address. To > solve this problem, I have created a proposal for incorporating a public > key in the domain name itself, allowing a server to be authenticated > without involving a third party. The proposal can be found at > <https://demimarie.github.io/cryptographically-generated-domains.html>. This idea of using the hash of a public has never gained widespread excitement, but maybe this time is different! The proposal seems to combine some previous ideas around self-authenticating addresses [0] and self-authenticating traditional addresses [1]. I recommend citing the prior work in the proposal for completeness. The Open Questions section mentions Tor’s onion services, and indeed a lot can be learned from them with regard to their addressing scheme. Primarily, cryptographic hashes are not user-friendly, in fact some would consider them user-hostile because they lack any inherent meaning and require byte-for-byte comparison that is tedious. However, the value of 1) uniqueness, 2) self-authentication, and 3) end-to-end security are important characteristics. > > Is an implementation of this something that Chromium would be interested > in? I do plan to propose this to the IETF, but first I want to check if > there is interest from browser vendors. I assume you forgot to replace Chromium with WebKit? :) But, with regard to Chromium, I believe they were exploring usability improvements in the area of supporting top-level HTTPS navigations to devices on a local network that don’t have globally valid TLS certificates. I can’t find the proposal at the moment, though. I also recommend citing RFC 7686 [3] and CAB ballot 201 [4]. I am interested in seeing if there is broader support of this idea, too. [0] https://spec.torproject.org/rend-spec/encoding-onion-addresses.html [1] https://www.researchgate.net/publication/337510353_Self-Authenticating_Trad… [3] https://www.rfc-editor.org/rfc/rfc7686.html [4] https://cabforum.org/2017/06/08/ballot-201-.onion-revisions/

2 1

Questions about concurrent <video> playback restrictions on Mobile Safari.
by Yury Yarashevich 15 May '25

15 May '25

Hi WebKit team, I’m curious about the original rationale behind the restriction that prevents concurrent playback of multiple <video> elements. Was it primarily introduced to save battery life? In practice, this behavior appears to have unintended side effects. There’s a reproducible issue where playback can be started with the video muted and then immediately unmuted, effectively bypassing the restriction. However, this often results in videos being randomly paused later—sometimes very frequently—leading to a “play/pause ping-pong” between Safari/WebKit and JavaScript restarting playback. This erratic behavior may actually *increase* battery consumption, despite appearing to work smoothly from the user’s perspective. Even if this workaround is eventually blocked, developers who rely on concurrent playback (e.g., outside of WebRTC contexts) will turn to more complex solutions, such as decoding video and audio using WebCodecs or/and WebAssembly, and rendering via <canvas> and AudioContext. While technically feasible, these approaches are likely to be significantly less power-efficient than simply allowing multiple <video> elements to play concurrently. Another similarly inefficient workaround would be to synthesize a MediaStream using the VideoTrackGenerator API and AudioContext.createMediaStreamDestination(). Lastly, another issue is that creating a MediaElementSource from a <video> element and routing its audio through a shared AudioContext also does not disable the playback restriction—whereas it *is* disabled when the <video> element itself is muted. This feels inconsistent and may point to a separate bug. Could you please clarify the motivation behind this restriction, and whether there are any plans to revisit or improve its behavior? Thank you!

3 5

Handling the list of files and functions in commit messages
by Anne van Kesteren 07 May '25

07 May '25

Keith Miller recently started various discussions about this, the latest in #dev on Slack: > Have we reconsidered the expectation/requirement to list of changed > files in the commit message? IMO, it makes it much harder to read > the git log output as most folks don't even put a file-by-file > comment in the message anyway. If I care about the history of one > file I would just git log Source/foo/bar so that doesn't seem like > a good trade off. Let me also quote Geoffrey Garen, who provided context for why we have this in the first place: > My memory is that Darin wrote the original PERL script, and the > intention was to provide a structure for per-file comments. If my > memory is right, probably nobody will defend the degenerate case > where you leave a list of files with no comments. It’s a > misunderstanding to explain that git can tell you the same list. > That was never the goal. > > For commits that explain everything per file, but occasionally > don’t explain a file because it’s trivial, probably the best thing > is to group the file with other files that get the same comment, > or, if the change is truly trivial, remove the file from the list > entirely. And Darin Adler: > [W]e never intended to have people just leave a massive list of > files and functions without comments. But few people seemed to > understand that; the point of making the list was to encourage you > to think about each change and possibly undo changes that don’t > make sense, explain each change. > > These are decisions we made a long time ago — I do find that my > changes are better when I carefully review them and try to explain > what I am doing. > > [...] If everyone is saying "I just write one comment above and > ignore the file and function list" than clearly we don’t need the > file and function list. The comments are supposed to say why we are > changing things, not what we are changing. [...] > > We should definitely delete the file and function list if there’s > no comments in there. Based on this, I have proposed a change that slightly tweaks the advice in the commit message template to make people consider removing lines of files and functions without corresponding comments: https://github.com/WebKit/WebKit/pull/44932. If there's no objections I'll merge that next week.

3 2

Re: [webkit-dev] Interest in supporting cryptographically-generated domain names?
by Demi Marie Obenour 05 May '25

05 May '25

On 5/5/25 10:13 AM, Matthew Finkel wrote: > Hi Demi, > > Interesting idea! Comments in-line: > >> On May 4, 2025, at 5:52 PM, Demi Marie Obenour via webkit-dev <webkit-dev(a)lists.webkit.org> wrote: >> >> A major limitation of the Web PKI is that it cannot issue certificates >> for devices that do not own a public domain name or IP address. To >> solve this problem, I have created a proposal for incorporating a public >> key in the domain name itself, allowing a server to be authenticated >> without involving a third party. The proposal can be found at >> <https://demimarie.github.io/cryptographically-generated-domains.html>. > > This idea of using the hash of a public has never gained widespread excitement, but maybe this time is different! The proposal seems to combine some previous ideas around self-authenticating addresses [0] and self-authenticating traditional addresses [1]. I recommend citing the prior work in the proposal for completeness. I was aware of Tor onion services, but not of self-authenticating traditional addresses. Thank you. > The Open Questions section mentions Tor’s onion services, and indeed a lot can be learned from them with regard to their addressing scheme. Primarily, cryptographic hashes are not user-friendly, in fact some would consider them user-hostile because they lack any inherent meaning and require byte-for-byte comparison that is tedious. However, the value of 1) uniqueness, 2) self-authentication, and 3) end-to-end security are important characteristics. Could the user experience problem be partially resolved by providing the URL as a QR code on the device itself and prompting the user to provide a human-memorable alias whenever they encounter a new CGDN in the URL bar? That avoids users ever having to interact with the ugly cryptographic hash, at least in common cases. [1] has some interesting ideas, but I'd rather leave them for later to keep the initial implementation simple. I also wonder how many users actually type in domain names they have memorized instead of relying on search. I do, but I would not be surprised if non-technical users often do not. >> Is an implementation of this something that Chromium would be interested >> in? I do plan to propose this to the IETF, but first I want to check if >> there is interest from browser vendors. > > I assume you forgot to replace Chromium with WebKit? :) But, with regard to Chromium, I believe they were exploring improvements in the area of supporting top-level HTTPS navigations to devices on a local network that don’t have globally valid TLS certificates. I can’t find the proposal at the moment, though. Yes, I did forget to make that replacement. I sent the same email to chromium-discuss(a)chromium.org and forgot that I had mentioned Chromium in the body by name. > I also recommend citing RFC 7686 [3] and CAB ballot 201 [4]. > > I am interested in seeing if there is broader support of this idea, too. > > [0] https://spec.torproject.org/rend-spec/encoding-onion-addresses.html > [1] https://www.researchgate.net/publication/337510353_Self-Authenticating_Trad… > [3] https://www.rfc-editor.org/rfc/rfc7686.html > [4] https://cabforum.org/2017/06/08/ballot-201-.onion-revisions/-- Sincerely, Demi Marie Obenour (she/her/hers)

1 0

Interest in supporting cryptographically-generated domain names?
by Demi Marie Obenour 04 May '25

04 May '25

A major limitation of the Web PKI is that it cannot issue certificates for devices that do not own a public domain name or IP address. To solve this problem, I have created a proposal for incorporating a public key in the domain name itself, allowing a server to be authenticated without involving a third party. The proposal can be found at <https://demimarie.github.io/cryptographically-generated-domains.html>. Is an implementation of this something that Chromium would be interested in? I do plan to propose this to the IETF, but first I want to check if there is interest from browser vendors. -- Sincerely, Demi Marie Obenour (she/her/hers)

1 0