blogccasion

W3C TPAC 2023 Trip Report

Thomas Steiner headshot

By Thomas Steiner. Written on . Work

Background

The 2023 edition of the World Wide Web Consortium (W3C) Technical Plenary and Advisory Committee (TPAC) meeting took place from September 11 to 15 in the Meliã hotel in Seville, Spain. The hotel is located right next to the Plaza de España, a major Spanish tourist destination. The setup of the meeting was hybrid, and on site, strict Covid precautions were enforced, even though the pandemic was declared to be "over". Despite these methods, several people caught it. This is my personal report as a representative of the Chrome DevRel team at Google.

Panorama of Plaza de España.

View of the hotel pool with the Glorieta De La Ronda De Capitania in the background.

Monday, Tuesday

Web Applications Working Group

I attended the Web Applications Working Group meetings on Monday and Tuesday. After a quick rundown of all the APIs in scope for the working group, the first topic was the Screen Orientation API, which was mostly driven by questions and improvement proposals the WebKit folks had after implementing it.

Next, the group discussed the Badging API, which is only available after installation, and browsers differ on whether they make the API detectable when the app is running in a tab.

An interesting corner case was debated in the context of the joint meeting with the Devices and Sensors Working Group. Apple can't join the group due to its unwillingness to implement some of the APIs and the sheer volume of proposals the team would have to review. The workaround is shared deliverables, where the APIs that there is agreement on get cross-delivered by a working group Apple is part of.

Following this, we talked about whether the Screen Wake Lock API should use transient or sticky activation.

The group made no progress on François Beaufort's suggestion for a Screen Brightness API.

On the topic of DeviceOrientation API vs. Generic Sensor API, the soft-conclusion was that the new API provides not enough advantage over the existing API. There's still disagreement about whether using the API should require a permission, which is mostly used for fraud detection to determine if a real user is holding a device.

For the Geolocation API, most discussion circulated around limiting its precision by encouraging more coarse data. On the opposite side, there's also still the open question of floorLevel data, which Safari exposes, but which isn't standardized. The group briefly discussed a toJSON() method for geolocation results, but it probably would be a breaking change due to instanceof checks. The background geolocation discussion was taken over repeatedly by trolls, which made proper discussion partly impossible. It's a solve-worthy problem, albeit it's a heated space. Geolocation Sensor had promises but we're not sure it's worth bringing this over, since the callback can easily be wrapped.

There was a joint meeting with the Internationalization Working Group to discuss long-standing open questions regarding translations of the Web App Manifest were investigated, which resulted in a potential solution. I foresee challenges when looking at the "shortcuts" member.

Notes and resources

Web Platform Incubator Community Group

On Monday afternoon, I switched over to the Web Platform Incubator Community Group (WICG) meeting. The topics I was interested in were Low Level Device APIs and First Party Sets (now Related Website Sets).

In the first part, Vincent Scheib presented on low level device APIs. Firefox has rolled out Web MIDI access based on an ad-hoc extension, which didn't seem it would convince Apple people. Apple also had doubts whether a permission prompt would be enough for people to understand that devices can be abused to circumvent the same-origin model. Reilly Grant outlined that Chrome stopped tying WebUSB to websites in an attempt to keep devices usable, even if the original website disappears.

For First Party Sets, there are currently only a few entries in the First Party Sets list, following the Submission Guidelines. It's rolling out to Chrome slowly. Other browser vendors do not implement First Party Sets at the moment.

On Tuesday, the big topic was installable web apps where Dan Murphy presented our existing solutions around Launch Handling. Marcos from Apple and Olli from Mozilla questioned the queue model vs. an event model and suggested to replace LaunchParams with DataTransferItem. Apple noted that a launch handling feature is something that they would probably need.

Apple's questioning of Chrome's established solution caused me to raise a meta question: Chromium already asked for input years ago and got no meaningful feedback and then shipped a solution that was proven to be successful. Now other vendors are interested, but want to change the fundamental design (and perhaps together we can all agree on a better design). What is the process here? Are we as Chrome supposed to unship ours?

Sangwhan Moon provided the Technical Architecture Group (TAG) perspective that Chrome makes sure other vendors provide input before Chrome ships. Chrome can't wait until vendors have an active interest. The group agreed to discuss next steps.

Diego from Microsoft then presented the Install API proposal. There was general interest in a solution, but a lot of skepticism when it comes to cross-origin installations, which would be an important use case for app stores or search engines.

The group further discussed the standardization of [iOS' proprietary navigator.standalone](https://github.com/w3c/manifest/issues/1092).

After that, we looked at the update algorithm discussed at the last TPAC and confirmed an update token would be the way to go.

The group briefly touched upon isolation of installed apps from the running browser context and the challenges it introduces with OAuth etc.

Next was protocol handling which Apple mostly opposed, window controls overlay and tabbed application mode which Apple was neutral-ish to, and my app menu proposal which Apple committed to coming up with a proposal for. Mozilla notably was in the room, but had no opinion on almost all topics close to PWA.

Apple then dropped a proposal for declarative push notifications. I filed a number of questions to the proposal.

Notes and resources

Wednesday

Wednesday was the breakout session day. As always, there were some sessions that I wish I could have attended, but due to scheduling conflicts I couldn't. Below is the list of the sessions I attended.

Accelerating the Web performance by compiling Javascript code to WASM

This session introduced JWST, a JavaScript to WebAssembly static translator (compiler) co-developed by Huawei and a professor from a university in Beijing, after claiming the (somewhat [citation needed]) problem of slowness of JavaScript being a problem for web apps and the lack of DOM access of Wasm as a major challenge. The presented compiler in their example converted a ~1.6MB JavaScript app (which is already big) into a >20MB Wasm app that under certain conditions slightly outperformed the JavaScript solution in their benchmark. I asked for more details about the compiler, but there wasn't any and the Huawei representatives said they weren't entirely sure about open-sourcing it. As it stands, my current evaluation of the solution is that it's technology feasibility demonstration at best.

Notes and resources

Page Embedded Permission Control (Permission Element)

In this session, the Chrome team introduced our current thinking of a permission element. The reaction from both Apple and Mozilla was that they both "don't immediately hate it". Many questions remain to be answered, mainly around how this would deal with multiple permissions, whether it should allow blocking permissions, the spoofability of its UI and whether that poses a risk, the customizability of its UI, and how revoking permissions would look like with it.

Notes and resources

The Future of Powerful APIs on the Web Platform

This TAG-initiated session stated the problem of powerful APIs on the Web, leading to permission fatigue and browsers simply not implementing certain APIs as a consequence, and motivated something like an extended trust mode for the Web. Sangwhan Moon said that without all browser vendors agreeing, the situation would not improve. Mozilla sort of soft-excluded the browser from the effort by stating that they were not thinking of messing with the origin model and to not assume that all capabilities were on the table. They also said as a community, we shouldn't let envy of native capabilities drive this.

Notes and resources

Privacy Principles

This session introduced the privacy principles jointly developed by TAG and Privacy Interest Group (PING) and solicited feedback from the persons in the room. The document is currently in wide review and seeks to be both aspirational and practical. Each member of the author group outlined their favorite sections of the document, like data minimization, device owners and administrators, or execution context. I asked about a conscious opt-in for objectively hard to understand things like requestStorageAccess() to which the answer was to abstract as much as possible in the permission prompt.

Notes and resources

The cross-browser future of Installable Web Apps

This was a session I had organized together with Apple, Microsoft, and Intel. We discussed a number of approaches to installability taken by the various browsers, including new surfaces like sidebars and widgets—a currently proprietary approach based on Microsoft's Adaptive Card format. Of special interest was whether criteria should be required before a Web app can be installed. Chrome talked about the no longer required service worker. Apple insisted no requirements at all should be made, not even a title or icon. Apple's requirements for installable experiences are focused on ensuring consistent experiences. Users should know exactly where to go in their device settings to, for example, turn off Web push notifications, which require installation on iOS. We ended talking about extensions and whether they should be exposed in installed apps. Currently, Chrome and Edge expose extensions, Safari doesn't.

Notes and resources

Installing Web Apps

This was again a deep-dive in Microsoft's Web Install API proposal. Many points or arguments were already made in the WICG session on Tuesday (same notes document as for the breakout session). A noteworthy new point was the question if something like sidebar apps should be supported in a sense that a PWA would be able to express it would like to be installed to the sidebar. Apple said the baseline assumption of this API should not be that of an app store; the API should be useful in itself. If stores are involved, how would stores know if an app was already installed through another store or mechanism? Could getInstalledRelatedApps() be the solution for this? Another point raised was the trackability of installs, so stores could know if an installation was triggered by them, and apps what store an install came from. Finally, we discussed double prompting, first a bootstrap prompt whether a store may install apps in general, and then a concrete prompt to install a given app.

Notes and resources

Thursday

Devices and Sensors

I spent Thursday in the Devices and Sensors Working Group meeting. The first part of the day was occupied by a charter discussion between Philippe Le Hégaret from the W3C. The core question that was discussed was cross-deliverables between the Web Apps WG and the Devices and Sensors WG, since Apple can't commit to joining the Device and Sensors WG but is interested in some of the things the group is working on.

Next, we looked at the privacy principles and how they are applied by some of the specs. Marian Harbach briefly presented the permission element.

In suite, Intel talked about testability improvements they made around WebDriver.

Regarding Generic Sensors, we made a resolution to ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting, matching existing normative mitigations in the DeviceOrientation Events spec.

After that, we went through all the APIs in scope of the working group and looked at their status:

Next, Intel gave a device market overview followed by an implementation overview including compelling use case demonstrations for the Device Posture API. Fine-grained angle information was removed from the spec due to privacy concerns.

In the following, Intel continued on presenting on the Compute Pressure API, with a special focus on cross-site tracking mitigations through randomization that were proven to be effective in experiments, plus showing future extensions for the API like memory stalls and an "it's you" hint when the current process is responsible for CPU usage peaks.

The day ended with a look at the Geolocation API, which is mostly stable but could add improvements around encouraging more coarse location access.

As a meta remark, I feel like as a working group, we didn't achieve much new things compared to last year, mostly due to a lack of cross-implementer support for some of the APIs like the generic sensor APIs, and only a limited appetite to move on with things vendors at least partially agree on like screen brightness or ambient light sensor.

Notes and resources

Friday

WHAT Working Group

On Friday, I saw an interesting proposal for a headinglevelstart attribute that would allow authors to embed content with a heading structure into another context with an already existing heading structure, while overall correctly nesting both heading structures. This was mostly driven by GitHub, who embedREADME.md files into repository homepages and who wish to adjust heading levels accordingly.

Next, a focus navigation start point proposal was brought forward, which would allow to set the start point for the next focus point (which is not the same as the focus). Again this was driven by GitHub, who wanted to make the file tree fully keyboard-navigable.

Noteworthy was also a proposal for an Observable API presented by Dominic Farolino , which would allow for more convenient event handling scenarios and that was greeted with great interest.

Notes and resources

Web Platform Incubator Community Group

In the afternoon, I attended Web Incubator Community Group (WICG) sessions focused on the Accessibility Object Model (AOM), the Shape Detection API, and the File System.

Unfortunately the AOM session was a little confusing and it was not entirely clear what the status of the AOM was and which parts of it are cross-browser vs. abandoned. The AOM explainer contains many abandoned sections and the AOM spec is just a barebones skeleton, plus the demo doesn't work (anymore).

For the Shape Detection API, there's some interest from Apple to implement this. They raised questions about batch processing and synchronization challenges with video, which would likewise apply to blurring. I pointed at my demo that solves this with MediaStreamTrack Insertable Media Processing using Streams. Apple was also worried about the Chrome-specificity of the test suite and the future venue of the proposal, hinting it could be the WebML WG. As a final point, I noted that Apple's implementation works, but only on the main thread and not in workers. This is a known issue and "for reasons", according to Apple.

The File System Access session proposed by Austin Sullivan unluckily saw no attendance from Apple or Mozilla, so the meeting was adjourned since it would have been Googlers preaching to Googlers (and Google Developer Expert Christian Liebel).

Notes and resources

Web App Security Working Group

On the end of the day, I crashed the Web App Security WG meeting and saw Mike West's proposal for purposeful permissions. I made the point for aligning with other efforts in this area in an issue, namely the W3C MiniApp Manifest and Isolated Web Apps permissions.

Notes and resources

Meta observations

Covid measures

Covid measures were strictly enforced during the indoor sessions with a masking mandate and encouraged daily testing. All the breaks and lunches were outside or outside-ish (partially in a well-vented tent). After hours at dinners and drinks at the hotel bar, everyone partaking in those activities took their masks off. There were, I think, around 15 documented cases of infections.

In-person event

It was really, really great to be able to do in-person events again. While the group meetings worked pretty well with remote attendance (both from across the world, or from the conference hotel if you caught Covid), the famous hallway track and spending time with people at dinner or after-hours drinks is just not replaceable by video conferencing technology.

Food

Food was boxed lunches with the now infamous soggy potato chips and each day a variety of pre-packed industrial sandwiches. It felt wasteful, since there was a lot of food in a lot of packaging. Maybe a buffet-style lunch would have been better. There was typically an early dinner train, which ended up in one of the tourist trap-ish restaurants in old town that open early compared to local Spanish dinner times. My food quality indicator was always to check the bread: if it's plastic-sealed, the food will be fine; if it's fresh, it will be amazing.

Coffee was available in the breaks, and either horrible if you got the milk directly from the machine, or great if you got the milk separately from a waiter.

Google attendance

There were (again) a lot of people from Google in attendance. This year, we made a concerted effort to highlight more closely what team we represent, for example, Google Chrome, rather than all of Google. More than once, I saw other people mirror this, and introduce themselves as "from the X team at Y".