W3C TPAC (Technical Plenary and Advisory Committee) is an annual event hosted by the World Wide Web Consortium (W3C), where members of various Working Groups (WG), Interest Groups (IG), and Community Groups (CG) gather to discuss the future of the web. It brings together a diverse group of people who share a common interest in understanding the web, identifying challenges, and working collaboratively toward defining requirements and addressing real-world use cases. Above all, we share a common core goal to ensure the web remains open and avoiding fragmentation into incompatible subsets.

Participating groups typically host their regular meetings to share progress, discuss what they have been working on, and explore future areas of focus. Additionally, some groups host breakout sessions for activities such as demonstrations and presentations, as well as to gather feedback from the broader community.

Attendees come from a wide range of fields and organizations, from small companies to large enterprises, including both implementers and technology providers. Some of the vendors who participated came from the “Big Tech” companies of Japan, China, US, and other countries.

This year, TPAC 2025 was held in Kobe, Japan, from November 10–14. This week-long event featured many groups covering topics that I found very interesting. I wasn’t able to participate in every session, as some sessions overlapped in the schedule. As a contributor to the Apache Cordova project, which heavily relies on WebViews, I primarily focused on topics related to WebViews and web-based applications. I also joined several other sessions that I found particularly interesting and that may affect or improve Cordova, as well as areas that I believe will be major focuses for many businesses.

While there were a variety of sessions to choose from—such as Documentation, Technical Architecture, Media, Internationalization, and Accessibility—the following sessions particularly piqued my interest and were the ones I chose to attend:

  • WebView
  • WebView Quirks & Testing
  • Web Payments & Web Authentication
  • Web Application Security
  • Updates on Servo
  • Modular Web Engines
  • MiniApps Ecosystem, MiniApps, High-Performance Baseline for Web Apps
  • Isolated Web Apps - Current State & Future Direction
  • Future of Open Web
  • Cookies
  • AI Agents

Of these sessions, I am part of the WebView Community Group (CG), which I helped co-chaired by taking notes. For all other sessions, I participated as an observer.

My Takeaway Points

Web Application Security

The Web Application Security Working Group covered many topics, but one of the proposals that was brought up really piqued my interest. This proposals was about a concept of Connection Allowlists. This proposal would allow servers to distribute a list of acceptable endpoints via response headers, enabling the user agent to allow or block a connection before it is established.

It was compared to the Content Security Policy (CSP) specification, as it addresses similar concerns. However, CSP is highly granular and has a complex syntax. My understanding is that Connection Allowlists would be much simpler, functioning as a straightforward check of whether a given endpoint is allowed. Unlike CSP, it would not require you to differentiate between specific allowed resource types, such as styles (style-src), images (img-src), scripts (script-src), etc.

While listening to the proposal, I was wondering whether this mechanism could be useful for WebView-based applications such as an application created with Apache Cordova.

Servo

Servo is a web browser engine currently under development and written in Rust. It was initially started by Mozilla Corporation and is open source and maintained under the Linux Foundation Europe. In this session, maintainers from the Servo project shared recent progress updates. They also demonstrated the WebDriver implementation, which recently expanded to include mobile support in addition to desktop support.

While Servo is a relatively new browser engine and still in development, it allows contributors to take a deep dive into WebDriver and other web specifications to ensure they are implemented correctly. Through this work, the team has identified bugs and ambiguities in existing specifications and test suites and has opened pull requests to address them.

What is interesting about Servo is it might be able to bridge gaps between browser engines across devices as well as taking a fresh perspective from ground up development. Looking from the Apache Cordova perspective, iOS and Android native WebViews, do not always share identical behavior or feature support. It would be interesting if Apache Cordova could create a Servo plugin that allows iOS and Android to use the Servo browser engine, as this could make WebView-based applications behave more consistently across platforms. This idea would be similar to the old Crosswalk plugin in Cordova.

However, Servo is still under development and not yet production-ready. Adoption would not be straightforward, especially given potential challenges and restrictions from mobile platform vendors that would present as hurdles to overcome. While it remains experimental, I see potential in its long-term direction.

WebView

The WebView Community Group hosted both a breakout session and a regular community meeting. During the breakout session, the CanIWebView website was presented, demonstrating how the community has been actively collecting and sharing data about WebView support across vendors. Currently, most of the data is derived from Browser Compatibility Data (BCD) for features that are easy to test automatically, while some entries are manually curated and focus on WebView behavioral characteristics.

These behavioral data points are not automated and test because they often involve WebView-specific APIs and configurations, and not all WebViews share the same mechanisms or terminology. Additionally, the CanIWebView mobile applications were demonstrated, showing that the community has built apps that can be installed on mobile devices to run, configure, and test WebView behavior directly.

While the morning breakout session did not have as many participants as hoped, there was strong participation during the community group’s regular meeting. The format remained open to the community, allowing participants to share information, feedback, and questions. We revisited several points from the breakout session, and attendees raised some questions and feedback that we would be able to turn into actionable items.

The main questions and action items that stood out to me were:

  • How to present data in a way that is useful and easy for developers to understand.
  • Developing an automated testing framework to run the CanIWebView app for testing WebView-specific APIs, potentially using Appium.
  • Finding a way to break down the data by WebView versions.
  • Improving clarity around the target audience (for example, whether this is intended for general web developers).
  • Defining what a “WebView Baseline” should look like.

From what I am hearing, WebViews have been becoming a hot topic again. While WebViews are not new, there appears to be increased momentum toward using them to address modern application needs. For example, while attending the Mini Apps session, I found many similarities that suggest WebViews could, and already do, play a role.

AI Agents

AI is a rapidly growing field, with many AI-based services emerging to help simplify tasks for individuals. During the AI Agents session, a presenter demonstrated how AI agents could assist with hotel reservations. The user would interact with the AI agent using natural language to specify their request and parameters but one major question was how could we define a protocol structure for a system that may have a vast number of undetermined parameters. There was also a major concern if too much privilege is given to the AI agents, for example handling of payments which everyone is against. This concern relates to who should have authorization and authentication for payment processing. Payments should only be processed through a trusted, signed merchant and should not be accessible, manipulated, or read by the AI agent.

In Summary

I really enjoyed participating in W3C TPAC. I learned a lot from like-minded people, and there is still much more for me to digest. I also had the opportunity to meet with Niklas Merz for the first time, another Apache Cordova PMC member I have worked and communicated with over the years. I hope I can continue to participate in future TPACs and other technical conferences, be more active, and contribute to the discussions.