Skip

Breakout schedule

Wednesday is the day for breakout sessions, when TPAC participants can organize discussions among the full W3C community about new or existing topics.

Times in America/Los_Angeles

Session 1 Session 2 Session 3 Session 4 Session 5 Session 6 Full schedule

If you make slides, consider using the TPAC 2024 template in HTML.

Skip

Session 1,

Breaking Silos: A Collaborative Discussion on Use Cases for Linked Web Storage

Proposer

Pierre-Antoine Champin, Aaron Coburn, Laurens Debackere, Eric Prud'hommeaux

Description

The mission of the newly created Linked Web Storage Working Group is to enable the development of web applications where data storage, entity authentication, access control, and application providers are all loosely coupled, as opposed to the web of today where these are typically all tightly coupled and changing one requires changing all, sometimes at the price of all past data.

A number of initiatives — such as IndieWeb, Unhosted, and Solid — have emerged to propose alternative models for web applications. They are largely based on existing open web standards, which they extend to give priority to individual and group autonomy.

The goal of the breakout session is to bring together current and potential participants of the Linked Web Storage Working Group, as well as members of other communities with shared interests (such as the ones cited above) to seed a set of use-cases that the working group can later adopt to guide its work.

Live minutes will be taken in https://docs.google.com/document/d/1sFZ0BozoLA3U7iROtu10tR7S05_OEOprS8Um9NZqZYw/edit

Goals

Gather use cases and experiences from a wide range of people to initiate the work of the Linked Web Storage WG.

Links
Room
4 Concourse Level - Redondo, ​–​

Browser API for Country Data

Tracks
UX
Proposer

Christian Indra, Westin Wrzesinski

Description

Millions of websites rely on country and address formatting data that needs to be unnecessarily downloaded on everyone of those websites. For example on a regular Shopify onlinestore this leads to 193kB uncompressed or 17.7kB compressed data being downloaded on every store. To allow developers build simpler and more performant websites we want to discuss our proposal for a browser API for country data.

Goals

Discuss proposal, get feedback, and discuss next steps

Links
Room
4 Concourse Level - San Clemente, ​–​

Canvas place element

Tracks
Web Apps
Proposer

Khushal Sagar, Fernando Serboncini

Description

A fundamental capability missing from the web is the ability to complement Canvas with HTML elements. Adding this capability enables Canvas surfaces to benefit from all of the styling, layout and behaviors of HTML, including interactive elements and built-in accessibility.

Goals

Present high level proposal and open questions, gather developer and implementor feedback

Agenda
  1. Use-cases targeted by this capability.

  2. Rendering model and basic syntax: 2d canvas, WebGL, WebGPU.

  3. Major open questions

Links
Room
2 Ballroom Level - California B, ​–​

Deprecation is Hard to Do, and We Can Do it Better

Tracks
Standards
Proposer

Benjamin VanderSloot

Description

Deprecating behavior on the web has to be done sparingly. Removing a behavior from the platform means that some websites that once worked will no longer do so. For some sites and behaviors that may be a good thing, e.g if it improves security or privacy protections provided to the user. However, this needs to be weighed against the impact on existing website deployments that don’t need or merit that protection and the impact on the web ecosystem of removing that behavior. Failing to sufficiently incorporate those website deployments' needs leaves the deprecation paternalistic at best.

One place this tension arises is in the similarity of authentication and tracking to the browser. Privacy protections that rely upon deprecating behavior, like third-party cookies, have had to work around this tension.

In this session we will discuss principles for deciding:

  • what behaviors are candidates for deprecation,

  • when a deprecation should proceed,

  • how to mitigate harm from those deprecations.

Participants are encouraged to bring their own examples that reveal challenges to provide concreteness. The chair will use third party cookie deprecation, storage access, FedCM, navigational tracking, OpenID Connect, and SAML as a starting point and example that they are familiar with

Goals

Improve consensus around deprecation of web platform behaviors

Agenda

5-10 minutes of stage setting, followed by discussion.

Links
Room
-1 Lower Level - Catalina 7, ​–​

Discover the Italian Digital Identity Wallet

Tracks
Wallets
Proposer

Giuseppe De Marco

Description

After more than two years of work and over a year of development, Italy has launched the first phase of the IT-Wallet pilot, a digital wallet solution that balances the experience gained from existing national digital identity systems with the requirements introduced by the new paradigm of digital wallets, as outlined by the EUDI Wallet regulation. In this presentation, we will summarize how the project began, how it continues to seek harmony with the EUDI Wallet, and the implementation choices that make the IT-Wallet an interesting platform for a critical analysis of Wallet Architectures.

Goals

The purpose of this session is to provide guidance on following the development of the IT-Wallet and to highlight some unique aspects of the Italian model. These include the trust infrastructure, revocation control mechanisms, and the integration model for Authentic Sources through the national interoperability platform.

Agenda

Agenda

Links
Room
-1 Lower Level - Catalina 5, ​–​

Expanding Verifiable Credentials: Future Standards and Innovations

Tracks
Identity
Proposer

Mandy Venables, Wesley Smith

Description

This breakout session for Verifiable Credentials will explore key areas for future development and standardization. It will cover the work on renderMethod and confidenceMethod, which provide flexibility for enhancing credential presentation and verifier trust. It will delve into the integration of the unlinkable ECDSA cryptosuite, an advancement for privacy-preserving credentials. It will cover the work on VC barcodes and the ongoing work on the VC API, supporting VC lifecycle management. The group will explore innovative methods for VC transmission over wireless technologies, including NFC and Bluetooth, to support in-person interactions. Finally, there will be discussion on vocabulary development for specific domains such as driver's licenses, electronic ID cards (EADs), citizenship documents, vehicle titles, and more, to ensure broad applicability and interoperability of Verifiable Credentials across various market verticals.

Goals

Inform members on upcoming Verifiable Credentials work as well as future rechartered work.

Agenda
  • RenderMethod

  • ConfidenceMethod

  • Unlinkable ECDSA Cryptosuite

  • VC Barcodes

  • VC API

  • VC over WirelessNFC

  • Vocabulary work

Links
Room
4 Concourse Level - Manhattan, ​–​

HTML Model Element Discussion

Proposer

Ada Rose Cannon, Marcos Caceres, Brandel Zachernuk

Description

Discussions about with some Wider Groups

Goals

Establish whether Model elements are Media Elements

Agenda

The HTML Model Element is an in progress proposal for a new HTML element which can display 3D models on a Web Site, with capabilities for displaying in Stereo on compatible display hardware such as VR and AR devices.

Is the element a Media Element?

The model element has many capabilities which overlap with Media elements, what does it mean to be a media element and is it appropriate here?

For example a model could have a duration for it's animation but it might not be animated at all. It could potentially have multiple independent tracks.

Should model's allowed to be transparent can they always be opaque are there any always opaque elements?

Can lead to uncomfortable visual conflicts if the 3D model punches through text/content which is behind it but visually in front.

General Q&A

Links
Room
4 Concourse Level - Laguna, ​–​

One year update: fenced frames with local unpartitioned data access

Proposer

Shivani Sharma, Andrew Verge, Josh Karlin, Zachary Cancio

Description

This breakout session will serve as a 1 year update to the "fenced frames with local unpartitioned data access" project. We will:

Notes: https://pad.w3.org/p/FencedFramesBreakoutNotes Slides: Presentation: https://docs.google.com/presentation/d/1xKwCrhN2pD_lxuPfurgjEDkfyAcf3wgxPS9njlG9tT0/edit?usp=sharing PDF: https://drive.google.com/file/d/1atW2LNCthu08-glzBXxcdY3dkoSC5ahv/view?usp=sharing

Goals

To present implementation and design updates, and welcome feedback on any use cases that may benefit from this.

Links
Room
4 Concourse Level - Palos Verdes, ​–​

One Year Update: Using LinkML in Web of Things Specifications

Proposer

Ege Korkan, Mahda Noura

Description

As kind of a follow-up of https://github.com/w3c/breakouts-day-2024/issues/15 and its predecessor https://github.com/w3c/tpac2023-breakouts/issues/8 , in this breakout, the Thing Description Task Force of the Web of Things WG would like to talk about their experience using LinkML to change how they generate various resources and specification text for their technical reports.

Goals

Experience Sharing, Discussion

Agenda
  • Wrap-up of Schemata Discussions from TPAC2023 and Breakout Day 2024

  • Presenting LinkML Usage in WoT Thing Description Specification Work

  • Feedback and Discussion

Links
Room
4 Concourse Level - Capistrano, ​–​

Sharing styles with Declarative Shadow DOM

Tracks
Web Components
Proposer

Kurt Catti-Schmidt

Description

Script-based Shadow DOM can share styles with AdoptedStylesheets, but Declarative Shadow DOM must either initiate network requests or use scripting to share styles. This session will discuss various proposals for sharing styles with Shadow DOM's declaratively. These include:

https://github.com/WICG/webcomponents/issues/909 https://github.com/w3c/csswg-drafts/issues/10176

Goals

Come to a consensus on which approach is preferred for sharing stylesheets in Declarative Shadow DOM.

Agenda
  1. Discuss requirements from developers a. Fully declarative (no network requests) b. Able to opt-in for specific shadow roots c. Able to export styles out of shadow roots

  2. Discuss various proposals a. https://github.com/WICG/webcomponents/issues/909 b. https://github.com/w3c/csswg-drafts/issues/10176

Links
Room
-1 Lower Level - Catalina 3, ​–​

Trust the Origin, Trust the Content - Originator Profile

Proposer

Michiko Kuriyama, Shigeya Suzuki

Description

This breakout session will introduce Originator Profile, which aims to tackle misinformation using verified originators' profiles. Discussions will also explore possible collaboration with similar projects, such as C2PA, that depend on the originator.

Goals

Provides an overview of Originator Profile Discuss potential standardization Find potential collaborators

Agenda

Introduction to Originator Profile (20m, includes short intro video) Demonstration (5 min) Discussions (30min) Wrap-up (5min)

Links
Room
-1 Lower Level - Catalina 2, ​–​

User Research on Permissions

Tracks
Permissions
Proposer

Marian Harbach

Description

This breakout provides an opportunity to share results from user research on permission prompts, discuss methods and findings, and ideate on additional research that could help the community.

Permissions are notoriously difficult to study, given that they happen in very brief moments while users try to accomplish a primary task. Yet, they are an important security and privacy mechanism that can have substantial positive or negative impact on users' experiences on the web. The Chrome team conducted two studies to (1) understand the general experience of permission prompts on the web as well as (2) how users perceive a mechanism to make prompts less interruptive. We will share a brief overview of results from the two studies and discuss implications.

Beyond that, this forum provides an opportunity to exchange ideas and experiences when conducting user research on security and privacy mechanisms in browsers as well as to identify new opportunities to better understand users' experiences.

Please leave comments and suggestions, for example if you also have user research in the permissions space that you would like to share or other ideas that would fit well into the scope of this breakout.

Slide deck Recording of conference talk for paper 1 Recording of conference talk for paper 2

Notes from Q&A:

Q: When accessing or requesting permission websites should explain why. Any testing and research whether the page has made an attempt to explain to the user why it is asking?
A: Permission rationale study. Tricky to draw firm conclusions, data is very noisy. Will follow up with a study replicating the main flows we observed.

Q: why do websites ask for permission on arrival? E.g. google.com asks like that without context.
A: It’s tricky to get hold of non-Google website owners that would provide rationale. Those that wanted to talk about it were likely to have thought about providing rationale anyway.

Q: if you require user interaction to trigger the prompt what would happen? Do we care if we break pages because of that?
A: This is more a business question than a research question. Browsers would need to answer that for themselves. Developers can actually query the permission state. So there’s a way for developers to check before prompting.

Q: Prompt fatigue: is that influencing behavior when dealing with the prompt?
A: At the median, individuals on Chrome see approx. 1 prompt per 2 weeks. People make fast decisions based on habituation. Fatigue comes through qualitatively though and we do try to avoid additional prompts.

Q: Cookie banners: users don’t differentiate between actual permission prompts and cookie banners. So they add to fatigue. Any research related to that?
A: No specific research on our end, but we see study participants confuse cookie banners for permission prompts.

Q: How many prompts users see is influenced by Chrome remembering the permission state, this is not the same behavior for Safari. So it feels like assumed user fatigue is more of a Chrome thing than generic across browsers.
A: Agreed. We are rolling out one time permissions which will change that, but no concrete data to be shared yet.

Comment: If we think about the people who commission websites, they want to know where the customers are and send them stuff. Not at all surprising that we have so much more notifications and location prompts.

Q: Is there a way for websites to know they’re getting into the quieting zone of Chrome’s intervention?
A: You can look in CrUX to see your rank, but there’s not a direct way to know beyond that.

Q: Safari requires user activation for Notifications. It’s great that Chrome and Firefox also do this. We should start doing something about geolocation as well.
A: Next session has more on notification spam and proposes some solutions.

Q: Is there a presentation issue around users being told that the prompt is quieted? Can we reframe it to sound more positive, e.g. this is a new way of doing prompting?
A: That sounds interesting and worth exploring. We did attempt to change the string in the chip to say “Get Notifications?” and that did not have substantial effects, though.

Q: Did website devs complain about Chrome changing behavior?
A: Some, but we tend to answer with “If you do the right thing you shouldn’t need to worry about it.” But yes, developers want predictability.

Goals

Share user research findings on permissions, discuss best practices and ideas

Links
Room
4 Concourse Level - Oceanside, ​–​

Web and Generative AI risks

Tracks
AI
Proposer

Qing An

Description

Generative Artificial Intelligence (AI) is a type of AI based on techniques and generative models that aim to generate new content, and its performance in knowledge learning, inductive summarization, content creation, perception and cognition is distinctly different from previous AI technologies. Now, Web is fraught with AI-generated information. There are several new features of generative AI, such as new contents generation, long context windows, etc,. At the same time, generative AI brings new risks, such as hallucination, privacy leakage, copyrights infringement. This session will introduce the new features and new risks brought by generative AI compared with traditional AI. And the session will have an open discussion about the risks related to Web and W3C can do on Web standards to address the risks.

Goals

Discuss the risks of Generative AI and what W3C can do to address the risks.

Agenda
  1. Introduction of generative AI and its potential risks

  2. Open discussion

Links
Room
2 Ballroom Level - California A, ​–​

Web Standards Beyond The Browser

Tracks
Feature lifecycle
Proposer

Niklas Merz

Description

This breakout session aims to bring together communities and working groups that focus on web standards beyond the traditional browser environment. While much of the web's development has centered around browsers, there are many other environments, such as WebViews, JavaScript runtimes, and EPUB readers, where web standards play a critical role. This session will explore how these different groups can collaborate to enhance user perception and promote their environments in broader web standards development.

Goals

Collaboration between groups to discuss challenges and identify areas where these environments can more effectively connect with web standards development efforts.

Agenda
  • Introduction & Admin (5 min)

  • Roll call: Who is here and what environments are we looking at? (15 min)

  • Open discussion on discussion points (30 min)

  • Close up with minutes, follow up items, results etc. (10 min)

Session Objectives:

  • Foster collaboration between groups working on standards for non-traditional web environments.

  • Discuss challenges and opportunities in promoting these environments to both users and developers.

  • Explore potential synergies and shared goals across different projects like WebViews, JavaScript runtimes, and EPUB.

  • Identify areas where these environments can more effectively align with mainstream web standards development efforts.

Discussion Points:

  • What unique challenges do environments like WebViews, JavaScript runtimes, and EPUB face in relation to web standards?

  • How can we better communicate the role of these environments in the web ecosystem to users and developers?

  • What areas of collaboration between these groups can enhance user experiences and drive further adoption of web technologies?

  • How can we promote these non-traditional environments within W3C and other standards bodies?

Links
Room
-1 Lower Level - Catalina 1, ​–​

Skip

Session 2,

Assistive Technology Interop through ARIA-AT

Proposer

Boaz Sender, Chris Cuellar

Description

We'll step through and demo the purpose built software we use to collect AT output, build consensus on verdicts, and run those verdicts through automated regression tests with real ATs.

Goals

Share our work, tools, and progress toward AT Interop

Agenda

Still working on this.

Links
Room
4 Concourse Level - Palos Verdes, ​–​

Community Group Program Enhancements

Proposer

Ian Jacobs, Dominique Hazaël-Massieux

Description

After 12 years of Community Group operations and many discussions about their role in Specification incubation, the Staff are working on greater alignment of the Community Group program with the W3C mission. We are planning enhancements to address a small number of situations of concern for those CGs that publish Specifications. (As a reminder, CG Specifications are the subset of CG Reports that are subject to the CLA and FSA.) CG Specifications that gain traction outside of the guarantees provided by standardization processes risk weakening the W3C mission; through these CG program enhancements we seek to reduce that risk.

During this breakout, we will discuss the situations of concern that are motivating this work, share initial ideas to address them, and recruit early testers and adopters of these enhancements.

After TPAC we will continue this work in the Community Council.

Goals

Raise awareness and generate interest in potential enhancements to the CG program.

Agenda
Links
Room
4 Concourse Level - Huntington, ​–​

Device Bound Session Credentials

Proposer

Benjamin Ackerman, Kristian Monsen, Arnar Birgisson, Aleksandr Tokarev, Sameera Gajjarapu

Description

Device Bound Session Credentials (DBSC) aims to enhance protection against web session theft by using a secure session that is bound to the device between the browser and web application. This session will provide a breakdown of the general attack vector of cookie theft that it is aiming to disrupt, an overview of the proposed DBSC web standard and host an open discussion about the web standard to gather any feedback or suggestions by the community. The session also covers an addition to the standard layered on DBSC, called the DBSC(E). DBSC(E) aims to provide session protection from malware for enterprise use cases against web session theft as an opt in.

Goals

Present the DBSC and DBSC(E) API and protocol proposed for standardization and have an open discussion about any of the various components that are of interest.

Links
Room
4 Concourse Level - Capistrano, ​–​

DID Method Standardization

Tracks
Identity
Proposer

Mandy Venables, Manu Sporny, Gabe Cohen, Kim Duffy

Description

Standardizing Decentralized Identifier (DID) Methods is important to progress W3C's foundational work on global identifiers that are not leased, but owned by individuals. This session will discuss a proposed W3C charter for web-based DID methods. We will also cover key categories of DID methods that have proven broadly useful, including self-resolvable, web-based, and decentralized methods. The goal is to standardize a few methods that are in production within these categories, ensuring they meet the needs of diverse use cases. To achieve this, the group will establish strong collaboration and liaison agreements among key organizations outside of W3C, minimizing barriers to participation and fostering a cooperative environment. Additionally, the effort will engage the broader community of DID builders, innovators, and adopters, inviting them to contribute to a detailed roadmap that guides the future of DID standardization.

Goals

Inform members on the new DID Methods Working Group charter.

Links
Room
4 Concourse Level - Manhattan, ​–​

Lessons learned by an independent implementation of the Digital Identity Wallet in Europe

Tracks
Wallets
Proposer

Denis Roio, Andrea D'Intino

Description

I'll introduce challenges and pitfalls emerging while implementing the digital identity wallet in Europe (EUDI ARF).

Our team has independently implemented the EUDI ARF specification and released all code free open-source, a beta demo is also available as an online application at didroom.

This was a journey through some shocking revelations and frustrations shared by other large-scale pilots in Europe, so I'll do my best to extract critical insights that can guide other digital identity initiatives and avoid similar setbacks in the future.

Goals

Share a critical perspective on EUDI ARF based on facts

Agenda
  • Quick overview of EUDI ARF

  • critical responses

  • wrong security assumptions

  • wrong privacy assumptions

  • viable alternatives we see

  • Q&A

Links
Room
-1 Lower Level - Catalina 5, ​–​

Page Embedded Permission Control (PEPC): Safely embedding permission entry points in web content

Tracks
Permissions
Proposer

Penelope McLachlan, Andy Paicu, Serena Chen, Marian Harbach, Balazs Engedy

Description

This breakout will continue past discussions of the Page Embedded Permission Control (PEPC). We will discuss safe, consistent mechanisms for web developers to link into browser UI surfaces, starting with permissions. Other examples of browser controls which could be embedded include content settings, a PWA install trigger, an installed app management surface, federated login, autofill or other browser settings. To date discussion has focused on the permissions use case, and while we would like to continue this discussion we believe the concept could be applicable to other use cases.

As web apps grow more sophisticated, rivaling native apps in capability and complexity, users can become confused as to how to access important settings that affect their ability to use apps. For example, in addition to origin scoped Permissions, PWAs can have application settings scoped to the application.

Websites can try to help users by providing guided instructions into browser UI surfaces but (1) this normalizes a safety anti-pattern and should not be encouraged even in legitimate sites as malicious websites are excellent at deceiving users into making unsafe changes to their settings, (2) instructions are inconvenient for the user, difficult to maintain for developers and frequently fail to help and (3) these types of instructions present extra challenges for accessibility.

This session will continue the dialog on providing in page access to permission settings, including implications for the underlying browser permission model, while expanding the discussion to include problem spaces beyond permissions. We will present preliminary usage data and developer feedback from the PEPC prototype for permissions as context for conversation.

Goals

Gather community feedback on the use cases and requirements for a general solution to providing safe entry points into browser UI surfaces from web content while laying out an incremental roadmap. Discuss whether (1) the problem space warrants solutions, (2) the requirements of a solution, (3) how the PEPC as prototyped stacks up against requirements, (4) alternative ways the requirements could be addressed.

Agenda

Agenda

Links
Room
4 Concourse Level - Oceanside, ​–​

RtpTransport

Tracks
Real-time Web
Proposer

Bernard Aboba, Peter Thatcher, Erik Språng

Description

While WebCodecs provides low-level access to the browser's native encoders and decoders, today there is no API to transport media peer-to-peer using the Real-time Transport Protocol (RTP), defined in RFC 3550.

The goal of the RtpTransport API is to enable applications to utilize peer-to-peer RTP transport, as well as to send and respond to feedback using the Real-time Control Protocol (RTCP).

The following use cases are being developed:

See:

Goals

To describe the goals of the RtpTransport API, and to solicit feedback on developer needs and use cases.

Agenda
  1. Introduction to the RtpTransport API.

  2. Use cases.

  3. Developer feedback.

Links
Room
-1 Lower Level - Catalina 2, ​–​

Scoped custom element registry

Tracks
Web Components
Proposer

Ryosuke Niwa

Description

Session to discuss scoped custom element registry

Goals

Come up with MVP for scoped custom element registry

Links
Room
-1 Lower Level - Catalina 3, ​–​

Sourcemaps, Security, devices, & more: What you may have missed from TC39 & Ecma

Proposer

Aki Braun

Description

Lots of people who are tuned into internet-relevant standards know about TC39, the technical committee within Ecma International that specifies ECMAScript® (JavaScript™). What you may not know is that TC39 is broken up into 5 Task Groups, only one of which is responsible for the core standard, ECMA-262. Ecma is also home to TC53, another technical committee focussed on ECMAScript® in embedded systems. Join me to hear about the rest of Ecma’s work on ECMAScript: Internationalization, Security, Sourcemaps, Experiments in programming language standardization, and ECMAScript® modules for embedded systems.

Goals

Spread knowledge of JavaScript outside of the Web APIs, identify areas where Ecma & W3C could be working together.

Agenda
Links
Room
4 Concourse Level - Laguna, ​–​

System Tray Icon Support for PWAs

Tracks
Web Apps
Proposer

Diego Gonzalez-Zuniga

Description

In this session we want to discuss the scope of having an installed PWA close to a system tray icon. What does this behavior mean in different platforms and what is the minimum functionality that needs to be supported to bridge the gap with platform-specific (Windows/macOS/Linux) counterparts.

Goals

To scope the feature based on feedback from participants.

Links
Room
4 Concourse Level - Redondo, ​–​

The Future of Popups!

Tracks
UX
Proposer

Ari Chivukula, Johann Hofmann

Description

Popups are a (mostly) desktop-only UI concept critical to many existing flows (e.g., payments and login). If popups had to be invented today, what would they look like? What privacy and security concerns could be addressed? What UI would exist on mobile? Consider this and other questions as we examine the Partitioned Popins proposal!

Goals

Consider the Partitioned Popins proposal, and re-think popups as well know them!

Agenda

Slides

Screenshot 2024-09-18 13 02 34

Links
Room
4 Concourse Level - San Clemente, ​–​

The Future of TAG Reviews & Other Output

Tracks
Standards
Proposer

Daniel Appelquist, Lea Verou

Description

Since 2013, the TAG has been systematically reviewing new web features as they are being designed and specified. We’ve called this process “Design Review”. Right now, the majority of the TAG’s time and effort is spent on design reviews, with the remainder of our time focusing on "other" outputs, such as updates to the Design Principles, Security & Privacy Self-Review Questionnaire, newer documents such as the Privacy Principles, and BF Cache Guide, as well as one-off "findings."

The design review issue queue is what drives most of our meeting agendas. Insights that come out of design reviews also inform and prioritize the work we do on these other documents that the TAG publishes. The TAG has a backlog of design reviews, and its feedback in those reviews has sometimes been too late to have an effect on the development of the reviewed spec. This has caused some frustration both on the part of the people filing these reviews and in the TAG. We need to find a way to focus and prioritize our work on the issues where it's most needed - where it can have the greatest benefit to the web. This session is intended to gather community ideas on the best ways to do that.

This session is to gather feedback from the W3C community. Is it clear how the TAG design review process works? Is it working for you? Have you filed TAG reviews and been frustrated with the results? Have you filed TAG reviews and been delighted with the results? Are we balancing correctly between design reviews and other output? We’d like to “check the temperature” to ensure what we’re doing is useful to the community and we’d also love your feedback about what we could be doing better? Help us help you.

Goals

Refine the plan in https://github.com/w3ctag/process/issues/36.

Agenda

The format will be a short overview of the Design Review process followed by open discussion. Please note, we don’t want to use this as a forum to discuss the technical details of currently open reviews.

Links
Room
-1 Lower Level - Catalina 7, ​–​

Web API for Hybrid AI

Tracks
AI
Proposer

Chunhui Mo, Martin Alvarez-Espinar

Description

Web apps are increasingly expected to gain access to a language model. We are proposing Web APIs that allow web developers to directly access both on-device and cloud-based language models, and securely share user data between multiple apps when using these models.

The following are the APIs goals:

  • Provide web developers with a connection strategy for accessing both on-device and cloud-based models. For example, if no on-device models are available, attempt to access cloud-based models. Conversely, if cloud-based models are unavailable, try accessing on-device models.

  • Provide web developers with a storage strategy for sharing user's private data. For example, one web app saves users' private data into a local vector database. Another web app, when accessing a on-device language model, can leverage this data through a local RAG system.

The following are not within our scope of concern:

  • Design a uniform JavaScript API for accessing browser-provided language models, known as the Prompt API, which is currently being explored by Chrome's built-in AI team.

  • Issues faced by hybrid AI, such as model management, elasticity through hybrid AI, and user experience, as this topic has already been discussed in Hybrid AI Presentations in the WebML IG, and will be covered in the sessions on AI Model Management.

This session will showcase how to use our proposed API for booking flights and hotels. It will also provide specific implementation details and references for these APIs. Example source code and implementation references can be found on GitHub web-hybrid-ai.

Goals

Explore the potential of our proposed Web API for accessing hybrid AI through use case demonstrations and API implementations. Additionally, discuss concrete steps for moving forward.

Agenda
  1. Introduce the goals of the Web APIs we propose for hybrid AI (2m)

  2. Introduce Connection API (5m)

  3. Introduce Storage API (4m)

  4. A Showcase of Hybrid AI App (3m)

  5. Considerations for Connection Strategy (2m)

  6. Considerations for Storage Strategy (2m)

  7. Considerations for Native OS APIs (2m)

  8. Discuss possible resolutions, followup actions and collaborations (20m)

Links

Links
Room
2 Ballroom Level - California A, ​–​

Web Features: Building an index for the web platform

Tracks
Feature lifecycle
Proposer

James Graham

Description

Web features is an initiative of the WebDX Community Group, to build a list of features on the web platform, organised in a way that's useful to developers. It is currently used for providing "baseline" statuses, indicating feature availability, to be presented on documentation sites such as MDN.

So far the work has mainly been focused on grouping the already-existing platform APIs into features that can be assigned a baseline status. However the purpose of this session is to understand the opportunities and requirements to use web-features earlier in the proposal lifecycle, as part of the ongoing standardisation process. For example, in a world where standards-positions and intent emails consistently use well-defined feature names, it may be possibly to build tooling that informs developers, and other interested parties, about which proposals are just waiting for implementation, or where there are more fundamental challenges at the standards level. This data could then be used to inform other projects such as Interop.

Goals

Understand the requirements / challenges of integrating web-features early into the standards development process

Links
Room
-1 Lower Level - Catalina 1, ​–​

🐞Ladybird: A new, independent browser engine — written from scratch

Proposer

Michael[tm] Smith (sideshowbarker), Andrew Kaster, Jelle Raaijmakers, Tim Ledbetter

Description

An intro+Q&A for the Ladybird browser engine: a completely new engine written from scratch (using no code from Blink/Chromium, WebKit/Safari, Gecko/Firefox, or any other browser), and backed by the non-profit Ladybird Browser Initiative — with a policy to never take funding from default search deals or any other forms of user monetization, ever.

Goals

The session goal it to give a detailed intro to Ladybird, and answer attendees’ questions about it.

Agenda

Some of the details planned to be covered include:

  1. What Ladybird is not (just to be clear):

  • Not a Blink/Chromium shell.

  • Not a WebKit port.

  • Not a Firefox fork.

  1. What makes Ladybird/Ladybird Browser Initiative different.

  • Fully independent: Written from scratch, using no code from any other browser engine.

  • Singular focus: Doing only one single thing: building a new browser engine and browser.

  • No monetization: Will never take funding from default search deals or any other forms of user monetization, ever.

  1. Very short history.

  1. Related early video/audio announcements and interviews (July–August 2024).

  1. Roadmap.

  • 2026: alpha release (daily driver for developers and early adopters) for Linux and macOS.

  • 2027: beta release; downloadable app for Linux and macOS.

  • 2028: stable release for general public. image

  1. Project goals and culture.

  • Eventually give everybody the choice of a whole new browser they can use for their daily browsing.

  • Prove it is in fact possible to build a completely new browser, by implementing from the WHATWG/W3C/etc. specs.

  • Have a lot of real fun together actually doing it.

  • Prove that developing an engine doesn’t take hundreds of engineers — and not anything close to even just a hundred.

  • Browser engineering: Further help de-mystify it and make it a standard thing to learn (hat tip: https://browser.engineering/).

  • Using project Discord server for communication discord.gg/nvfjVJ4Svh.

  • Using one GithHub repo for everything: issues (no bugzilla or other), patch/PR submission/review, CI/test automation.

  1. Project coding conventions and activity metrics.

  • Implement web-platform features exactly according to the actual steps in spec algorithms.

  • Abundant code comments with verbatim spec text copy/pasted in — showing exactly what’s being implemented.

  • Additional “AD-HOC:” comment convention to mark code that doesn’t map to any spec requirements.

  • Class/file names tend to closely match actual current spec terms; e.g., Navigable.h, Transferable.h.

  • “critically reading standards and reporting what is wrong”

  1. Project activity metrics.

  • Project activity data/graphs: https://git-pulse.github.io/snapshots/LadybirdBrowser-ladybird-2024-09-12-pulse.html

  • Project activity relative rankings: https://git-pulse.github.io/snapshots/?project=LadybirdBrowser_ladybird   | Engine | Committers per month | Commits per month | | ---------: | -----------: | -------------------: | | Ladybird | 53 | 564 | | Servo | 27 | 216 | | WebKit | 136 | 1262 | | Gecko | 417 | 3496 | | Chromium | 1297 | 13176 |

  1. How you can get the code and build it, and contribute new code/patches.

  • https://github.com/LadybirdBrowser/ladybird

  • https://github.com/LadybirdBrowser/ladybird/blob/master/Documentation/BuildInstructionsLadybird.md

  • https://github.com/LadybirdBrowser/ladybird/blob/master/CONTRIBUTING.md

  • https://github.com/LadybirdBrowser/ladybird/blob/master/Documentation/GettingStartedContributing.md

  • Linux, macOS, Windows (with WSL2), Android; build uses vcpkg to manage build dependencies.

  1. Code details and basic architecture.

  • C++ while selectively migrating parts to Swift and while keeping an eye on things like Sean Baxter’s Circle & Safe C++.

  • Some use of third-party libraries (e.g., Harfbuzz, Skia, simdutf, libcurl).

  • Performance optimizing is not yet a super-high priority (but performance-boosting changes are regularly getting made).

  • LadybirdBrowser/ladybird#features:

    • UI process, ImageDecoder process, RequestServer process, WebContent processes.

    • LibWeb: core web-rendering engine (HTML, CSS, Events, DOM, APIs).

    • LibJS: JavaScript engine written from scratch (currently JIT-less).

    • LibWasm: WebAssembly implementation written from scratch.

    • AK: Ladybird standard library/abstractions: asserts, smart pointers, strings, numbers (e.g., fast_float impl.), more…

  1. Current code size: cloc --vcs=git details/comparison (as of 2024-09-01): | Engine | C++ files | C++ lines of code | | ---------: | -----------: | -------------------: | | Ladybird | 1695 | 313947 | | WebKit | 17189 | 4586173 | | Gecko | 14187 | 5396911 | | Chromium | 63826 | 14902914 |

    | Engine | Rust files | Rust lines of code | | ---------: | -----------: | -------------------: | | Servo | 1010 | 268796 |

  2. Testing.

  • Has its own test harness/runner and some in-tree tests.

  • Currently passing ~79% of WPT (compared to major engines 95%–97%) — and that percentage is growing weekly.

  • CI/regression-testing: Can’t yet practically run all WPT tests on every PR (takes ~5.5 hours, many timeouts).

  • So, to have automated regression testing, we currently add some tests in-tree that may be redundant with WPT.

  • wpt.fyi/results?product=ladybird has current test results for all WPT tests.

  1. Financial support: Funded entirely through donations and sponsorships.

  • https://donorbox.org/ladybird – donations of any amount: $10, $50, $100, etc.

  • https://polar.sh/LadybirdBrowser – set bounties to directly fund specific features/tasks; e.g., $300 legacy-encoders bounty.

  • Sponsorship opportunities: Platinum $100,000 • Gold $50,000 • Silver $10,000 • Bronze $5,000 • Copper $1,000.

  • Ladybird Browser Initiative announced/seeded with 1 million dollar donation from defunkt and his family.

  1. Where Ladybird fits in at the W3C.

  • This means we have six engines in active development: Gecko, Servo, WebKit, Blink, Flow (88% WPT), and Ladybird.

  • Five open-source engines in active development — and six engines in total: both things we’ve never had before.

  • Imagine: Can the Ladybird project grow into a first-class citizen in the W3C community, along with other engines?

  • Enlightened self-interest: Helping a new engine project helps improve our specs, get new editors on board, etc.

  • You can bring your specific W3C/professional experience to help refine/align Ladybird code in key W3C focus areas:

    • Accessibility: ARIA, AOM, testing with AT, more…

    • Internationalization: CJK handling, layout, many other opportunities…

    • Security: CSP implementation, standards related to Spectre mitigation, security-related error messages, more…

    • Privacy: Lots of opportunities for implementing particular specs, for privacy-related browser/UI features, more…

  1. Resources.

  • FAQ: Independent? • When is it coming? • How many people? • Hiring plan? • Windows? • Mobile? • C++? • Swift?

  • Ladybird YouTube channel: monthly Ladybird project updates from Andreas.

  • Andreas’ YouTube channel: 1000+ videos from 6+ years; incl. “car talk” + OS/browser “hacking” (live-coding) videos.

  1. Tangentially-related background.

Links
Room
2 Ballroom Level - California B, ​–​

Skip

Session 3,

Content Authenticity and the Web

Proposer

Daniel Appelquist

Description

Goal of the session: Understand user needs around provenance and authenticity of content on the Web and their intersections with W3C work, towards a possible W3C Workshop in 2025.

One of the major threats the Web is facing is its use as a large-scale vector or mis- and disinformation, made even more prominent by the rise of generative AI which allows the production of synthetic superficially-credible content.

To understand what role W3C might play in mitigating that threat, discussions around a possible Authentic Web workshop sometime in 2025 have emerged in the community.

This breakout offers to discuss how we can better allow end users to determine the authenticity of the information they see when they use the web, as a first step towards identifying a relevant scope for such a workshop.

The Ethical Web Principles state: “The web makes it possible to verify information”. There are technologies being developed such as C2PA or OP (Originator Profile) which allow for stronger binding of metadata to content of various kinds. What can the web do better to surface this kind of metadata to end users and ensure that this metadata is maintained across various methods of content transfer?

The breakout will focus on the user needs - specifically thinking of web users (both as content creators and consumers), informed by current best practice thinking in the relevant industries (for example, journalism, fact checking).

Goals

Refine plan for a 2025 workshop on web authenticity.

Agenda

Format: Short presentations followed by discussion

Links
Room
4 Concourse Level - Redondo, ​–​

Cookie Layering

Proposer

Johann Hofmann, Anne van Kesteren

Description

We will share and discuss progress on the Cookie Layering effort, our new Cookies Internet Draft and how we can proceed to specify and standardize new Privacy features on the web such as third-party cookie blocking, cookie partitioning, and the Storage Access API in WHATWG and IETF.

Goals

Progress updates and planning next steps

Links
Room
4 Concourse Level - Capistrano, ​–​

Curating the web platform's data and documentation

Tracks
Feature lifecycle
Proposer

Florian Scholz, Will Bamberg, Estelle Weyl, Vinyl Da.i'gyu-Kazotetsu

Description

Open Web Docs is a nonprofit open collective that curates web platform documentation and data for the benefit of web developers and the ecosystem's tooling. In this session we want to talk about how we work and how you (as a spec editor or implementer) can collaborate with us.

We want to talk about how specs and web platform features go through a "pipeline" of repositories and why that is important for us as documentation and data curators.

  1. A new spec gets authored and picked up by: https://github.com/w3c/browser-specs

  2. Spec definitions and in particular IDL definitions get parsed by reffy and https://github.com/w3c/webref

  3. Web platform features get identified from webref and continuously tested by https://github.com/openwebdocs/mdn-bcd-collector

  4. If a browser ships an identified feature, https://github.com/openwebdocs/mdn-bcd-collector signals that to https://github.com/mdn/browser-compat-data

  5. https://github.com/mdn/browser-compat-data gets released and spreads the information to MDN, caniuse, caniwebview, linters, specs, other tooling and reporting.

  6. At this stage, the feature is also marked in need of technical documentation via https://openwebdocs.github.io/web-docs-backlog/

  7. https://github.com/web-platform-dx/web-features defines a feature id for the new feature and calculates a "baseline" status allowing it to be talked about in a consistent way in even more places.

  8. Web developers start using the feature more broadly and adapt it as the feature hopefully transitions to "baseline high" over the course of the next few months.

  9. (if the feature gets deprecated and we take steps to signal to users to move off of it again)

There is probably more to it but this should give you an idea of our "pipeline". The above is sort of the "golden path". Of course, things can go sideways in several ways and, in the worst case, that will lead to non-existing docs and compat data:

  • Specs don't make it into the browser-specs repo or don't have standing: good

  • Browsers implement things without a spec and we have to maintain custom IDL files and document features as non-standard

  • Features are specced but never see implementation (we shy away from curating these, "spec fiction").

  • Features sit behind a flag for a long time (and change drastically, so we don't curate docs and data until we have been promised with some stability)

  • Bugs in any of the above repositories

  • Shortage of maintainers, technical writers, developers, curators, in any of the repositories.

Goals

Discussing curation of documentation, compatibility data. Exchanging feedback among repo maintainers

Agenda
  1. Short presentation about OWD's web platform data and documentation curation pipeline

  2. Discussion

Links
Room
-1 Lower Level - Catalina 1, ​–​

Data and Account Portability on the Social Web

Proposer

Dmitri Zagidulin

Description

One of the major pain points (and most requested feature) is painless and automated migration, export and import of social web profiles and data. Join us for a discussion of the LOLA specification (Live Online Account portability), the Data Portability report and related specifications. We'll also discuss how Data Portability intersects with authentication (OAuth 2 and more), decentralized identity, signatures, and so on.

Goals

Community Discussion of Data Portability issues

Links
Room
4 Concourse Level - Palos Verdes, ​–​

Defining views

Tracks
UX
Proposer

Jan Jaap de Groot

Description

Defining what constitutes a view has been tried over the years. In this session, we will re-open the discussion.

Web page in WCAG 2.2

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

Views in WCAG 3

Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, a view could be considered a “screen” in a mobile app or a layer of web content – such as a modal.

Interpretation of Web Terminology in a Non-web Context

A small number of success criteria are written to apply to “a set of web pages” or “multiple web pages” and depend upon all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 2 is a single web page, the task force agreed that the equivalent unit of conformance for non-web documents is a single document. It follows that an equivalent unit of evaluation for a “set of web pages” would be a “set of documents”. Since it isn't possible to unambiguously carve up non-web software into discrete pieces, a single “web page” was equated to a “software program” and a “set of web pages” was equated to a “set of software programs”.

Goals

Getting closer to the definition of views

Agenda
  1. Web page definition (WCAG 2.2)

  2. View definition (WCAG 3)

  3. Web page mapping (WCAG2ICT)

  4. Defining view

Links
Room
4 Concourse Level - San Clemente, ​–​

Demonstration of AI Powered Accessibility Auditing

Tracks
AI
Proposer

David Fazio

Description

This session will demonstrate how Artificial Intelligence can be used for a number of accessibility analysis tasks in natural language processing, image understanding and design evaluation.

Goals

Demonstrate the power of AI-driven rule engines to enhance accessibility auditing capabilities and reduce the need for manual auditing efforts.

Additional session chairs (Optional)

@nehamjadhav

Agenda

Share & Discuss Current Implementation:

  • Abbreviations

  • Idioms and Phrases

  • Text from Images

  • Localization

  • Language and Context Analysis (Link Titles)

Future Implementation

  • Screen Recording Analysis

  • Video/Audio File Analysis

  • Image Analysis

  • Pattern and Relationship Recognition

  • Dynamic Content Analysis

Links
Room
2 Ballroom Level - California A, ​–​

Electronic Transferable Records: Implemented Using Transferable Verifiable Credentials

Tracks
Wallets
Proposer

Rachel Yager

Description

The presentation will share how Verifiable Credentials can be coupled with other decentralised technologies to implement the transferability feature of Electronic Transferable Records (ETRs). ETRs represent a digital evolution of traditional paper-based records, enabling instant, secure and easily verifiable electronic transactions. By leveraging transferable verifiable credentials, ETRs ensure the authenticity, integrity, and traceability of information throughout its lifecycle. Attendees will learn how TradeTrust (a freely available digital public good) uses these technologies to achieve trusted interoperability, with examples of use cases and the impact on various industries.

Goals

We aim to achieve:

  1. Awareness: To raise awareness among W3C members about the benefits of digitalising transferable instruments and applicability of ETRs;

  2. Alignment: To share latest information on related discussions happening at other international forum as the global trade community marshals around a freely-available and neutral standardized framework for ETRs. This would help ensure interoperability across different systems and platforms, making it easier for organisations to advance to digital trade practices.;

  3. Collaboration: To foster collaboration and discussions among industry experts and organizations, leading to collective efforts in spearheading innovation efforts.

  4. Feedback: To gather feedback from the W3C community on the importance of the transferability feature to them.

Links
Room
-1 Lower Level - Catalina 5, ​–​

Evolved Video Encoding with WebCodecs

Tracks
Real-time Web
Proposer

Erik Språng, Eugene Zemtsov

Description

WebCodecs provides a low-level API to do encoding and decoding of video with control over settings on a per-frame basis. As a relatively young API it currently lacks some more advanced features, such as temporal/spatial scalability that are important for real-time use cases like video conferencing.

This session is intended to discuss a number of potential next steps, to find which features are highest priority, and what benefits or problems we face with each of those.

Some of the topics for discussion:

Explicit reference frame control

By allowing the user to specify which reference buffers to reference and which to update on a per-frame basis, it is possible to implement a number of important reference structures and coding features including temporal/spatial/quality layers, long-term references, low-latency 2-pass rate control, etc.

In short, any of the scalability modes listed in Scalable Video Coding (SVC) Extension for WebRTC, any many more can be implemented with a small set of tools. If done right, this could even be done in a manner that is codec and implementation agnostic.

This way of modeling an encoder does also present some issues. The user needs to be able to determine how many reference buffers are available, how many can be referenced per frame and know which references are allowed or disallowed based on various circumstances. How do we expose such data in a way that is both user friendly, compatible with the current API, and avoids unnecessary finger printing surfaces?

There are also tradeoffs when it comes to integrating with existing encoder implementations, a small subset of which may not fit well into this model.

Spatial/Quality Scalability

Spatial scalability can be achieved by changing the encode call to take a sequence of encoding options, instead of a single option, per input frame. Each option would then represent a different layer and would include a desired encoded resolution. With reference frame scaling, a user may reference a buffer containing a different resolution.

Again, this comes with some challenges. Different codec types might have different bounds on the scaling factors, and even certain implementations have limitations in this regard - if it is supported at all. Some codecs allow only reference frame scaling within the same temporal unit, while other support any reference at any time. How do we handle encoders with special optimized mode such as "multi-res" or "S-mode aware" encoding?

Rate Control

When dealing with layered encoding, rate control becomes much more involved. The easiest way is to just support CQP, putting all of the rate control control with the user. If CBR is desired, the encoder needs to understand the bitrate target and expected frame rate for each spatio-temporal layer, this means it suddenly needs to be SVC aware even if the user is doing all of the reference frame control.

Auxiliary

There are many other knobs that could potentially be added. Speed/Quality control, segmentation/ROI-mapping, etc What's on the wish-list of the community?

Other Sessions of Interest

Note that there will also be a first-step proposal discussed at the joint Media/WebRTC WG Meeting on the 26th.

Further, there is a proposed breakout session on RtpTransport, an API that allows users to send custom-encoded frames over the RTP channel of a PeerConnection and is intended to go hand-in-hand with WebCodecs.

Goals

Find the highest priority features in the community, and what aspects needs more consideration

Agenda

The agenda is to discuss the proposal to add reference frame control to WebCodecs, and gather feedback and comments on the path forward. The session consist of a few parts:

  • General goals

  • Our initial proposal, a minimum viable useful implementation of reference control

  • How to query what the encoders are capable of

  • Spatial Scalability (SVC, Simulcast)

  • Rate Control

  • Miscellaneous

See also WebCodecs spec and github issue for the reference control.

Links
Room
-1 Lower Level - Catalina 2, ​–​

FedCM in practice

Tracks
Identity
Proposer

Yoav Weiss

Description

Smooth sign-up experiences on the web are essential for our users’ experience, and the fastest account creation experience is one where the user doesn’t have to create an account at all!!

While such experiences were powered by federated identity protocols using low level primitives in yesteryear’s web (e.g. third-party cookies, iframes and redirects), today’s privacy requirements lead to a new standard proposal to provide them with a more deliberate, safer and private binding - Federated Credential Management (or FedCM for short).

In this session we will briefly cover FedCM and how it does its magic, how it interacts with other efforts in the identity space, such as WebAuthn, and demonstrate real-life UX improvements that FedCM provides over the alternatives and discuss what can be improved in this space.

Co-hosts: @samuelgoto @gioele-antoci

Goals

Clarify the role of FedCM in the identity ecosystem, demonstrate its advantages and gather feedback on the feature and its future direction.

Links
Room
4 Concourse Level - Manhattan, ​–​

Mitigate Threats for Digital Credentials API

Proposer

Simone Onofri

Description

This is an interactive session to understand how to mitigate a number of specific threats identified during the Federated Identity Working Group's recharter review for the addition of the Digital Credentials API: a. Perpetuates sharing of personal data by making it more available via a browser API b. Increased centralization through subtle tradeoffs c. Content will be moved from the deep web to the “attributed deep web” d. Exchanges user agency for greater compliance and convenience

This breakout is intended to be a collaborative, working session. The focus will be on gaining consensus on the mitigations.

Goals

This breakout is intended to be a collaborative, working session. The focus will be on gaining consensus on the mitigations.

Agenda

Agenda

Links
Room
4 Concourse Level - Laguna, ​–​

New Features for the ServiceWorker Performance

Tracks
Web Apps
Proposer

Shunya Shishido, Keita Suzuki

Description

The session is going to be a presentation part and discussion part.

In the TPAC 2023 breakout, the Google Chrome browser team shared recent efforts on ServiceWorker and discussed potential opportunities for making ServiceWorker even faster. This year, we’d like to present a couple of updates from last year, including a newly shipped feature called Static Routing API, the new proposal extending Resource Timing API for the Static Routing API, and some of future ideas like or ServiceWorkerAutoPreload.

For the first half of the session, we’re going to present performance problems around ServiceWorker and introduce new APIs and how it works. For the second half, we’d like to spend time on the discussion.

Goals

This session aims to discuss ServiceWorkers performance issues, and how we can mitigate them. For the static routing API (now it’s part of the ServiceWorker spec), we’d like to hear browser vender status. For the other APIs that we’re proposing, we’d like to discuss and gather feedback from the community to make the standardization process forward.

Links
Room
2 Ballroom Level - California B, ​–​

Purposeful Permissions - Adding data use information to permission prompts

Tracks
Permissions
Proposer

Alexandra Reimers, Nick Doty, Serge Egelman

Description

Today’s web users often encounter permission prompts that lack context about why a website needs specific permissions and how the data will be used. While developers strive to provide context, the current approach lacks structure and consistency across websites. This session will explore options to add purpose declarations or other trustworthy, explainable contextual information to a permission request to bridge this gap and bring users greater transparency on how their data is used.

The discussion will focus on:

  • Use cases that might benefit or provide particular requirements for declarative contextual information, including access to information from government-issued credentials.

  • The potential roles of different stakeholders, including browser vendors, developers, and standardization bodies, in driving such an initiative forward.

  • Possible declaration options with various granularity levels spanning from links to the privacy policy to a fully fledged label system for data types and purposes of use.

  • Key challenges and opportunities in implementing purpose declarations for permission-gated capabilities.

Goals
  • Foster discussion and gather insights from various stakeholders on the development and implementation of permission purpose declarations.

  • Describe promising methods to provide purpose declarations and context for permission requests and identify volunteers who want to explore them, for future incubation and research, in credentials and other APIs.

Links
Room
4 Concourse Level - Oceanside, ​–​

Responsible Integration and New Use Cases of DNS Domain Names

Proposer

Swapneel Sheth

Description

Domain names have long been used as identifiers in applications. In the early days of the Domain Name System (DNS), domain names were associated with Teletype Network hosts, File Transfer Protocol servers, and email services. Later, they were adopted for web browsing.

Over the last several years, many novel use cases have emerged that utilize domain names. One such use case is allowing a user to verify control of a domain name, e.g., to show a verified badge on a profile as is seen with GitHub organizations. Another use case is as a social media handle, e.g., as performed in Bluesky. Blockchains and other decentralized applications are yet another use case, e.g., where a domain name may serve as a reference to a digital wallet address as seen in the Ethereum Name Service (ENS) or in various proposed Decentralized Identifiers (DID) methods.

We propose naming the process of integrating and maintaining a domain name into an application a DNS integration. These integrations have benefits, such as allowing users to keep a consistent identifier across their website, email, and new application use cases. Another benefit is portability, as users can opt into or out of integrations, e.g., by changing what DNS records are associated with their domain name.

This session will raise awareness of DNS integrations, the challenges they face, and facilitate discussions around how such challenges may be addressed. We will also highlight our IETF draft for DNS integrations and seek feedback from the community on additional topics to consider in this or future standards related work.

Goals

Raise awareness of DNS integrations and seek feedback for active standards work on providing guidance to applications that want to provide a DNS integration

Agenda

The agenda will be two parts. Part one will be a presentation to provide background context that:

  • Walks through examples of DNS integrations and their use cases (social, digital wallets, identity, etc.)

  • Explores why applications have chosen to provide DNS integrations

  • Provides measurement results showing challenges that select DNS integrations face

  • Promotes awareness of our IETF draft for DNS integrations and the topics it currently covers

Part two will be a discussion among participants about DNS integrations and what additional topics or concepts should be covered in the current IETF draft or future standards work, including at the W3C.

Links
Room
4 Concourse Level - Huntington, ​–​

Simplifying the Updatable REC Process

Tracks
Standards
Proposer

Marcos Caceres

Description

Join us at the W3C TPAC 2024 Tech Plenary to address the challenges and potential solutions for the updatable REC process. We'll focus on the issues outlined in issue #866 and collaborate on making the process more efficient.

Goals

Improve process and tooling

Links
Room
-1 Lower Level - Catalina 7, ​–​

Web Components & ARIA

Tracks
Web Components
Proposer

Ryosuke Niwa

Description

Session to discuss ARIA and web components: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md

Goals

Concrete proposal for ARIA across shadow trees

Links
Room
-1 Lower Level - Catalina 3, ​–​

Skip

Session 4,

AI Model Management

Tracks
AI
Proposer

Michael McCool

Description

AI models can be executed on the client web platform and can add significant functionality to web applications. However, they can also be quite large, requiring significant resources to download and store. Download and compilation latencies can potentially impact the user experience.

This breakout will discuss ways in which these issues can be mitigated. Possible topics include the following.

  • Background model download and compilation.

  • Caching strategies, including potential cross-site caching mechanisms with privacy-preserving mitigations

  • Model naming and versioning, allowing for model substitution when useful

  • Access to both downloadable and pre-installed models with a common interface

  • Storage deduplication

  • Model representation independence

  • API independence (e.g. sharing models between WebNN and WebGPU implementations)

  • Offline usage, including interaction with PWAs.

  • Common models are lower privacy risks

Note: this is both an AI topic and a Storage topic. Input from both communities would be useful and is encouraged!

There were some related presentations on this topic in the WebML IG.

See:

  • Repo - Please direct followup there, and to the WebML WG

Goals

Prioritize issues, discuss highest priority issues, define follow-up actions if possible.

Agenda
  1. Review list of issues and add or refine any if necessary (5m)

  2. Prioritize issues, identify shortlist for discussion (10m)

  3. Discuss potential solutions to high-priority issues (approx 15m each)

    • Expand explanation of each issue, identify stakeholders

    • Discuss possible resolutions

    • Define followup actions and collaborations

Links
Room
2 Ballroom Level - California A, ​–​

An Individual Differential Privacy Framework for Rigorous and High-Utility Privacy Accounting in Web Measurement

Proposer

Roxana Geambasu, Benjamin Case

Description

@bmcase and I, along with several differential privacy researchers, have developed a compelling privacy framework where each device tracks and controls the privacy loss incurred by the user’s participation in various measurements, such as advertising, engagement, or mobility analytics. Currently, these measurements require collecting sensitive user activity traces (e.g., visited sites, purchases), which raises privacy concerns. Our framework proposes a privacy-preserving alternative: the device tracks activity locally and generates encrypted reports, which can be aggregated by a trusted execution engine (TEE) or secure multi-party computation system.

We formalize our framework using individual differential privacy, allowing each device to account for and constrain their own user’s privacy loss toward each measurement party. This approach offers significant privacy-utility benefits over traditional models and improves transparency by letting users monitor their privacy on each device. However, it also introduces potential biases in measurement results, which we are working to address, but for whose design we require the community’s input.

At the breakout, we thus plan to:

  1. Present our privacy framework, which we developed initially for advertising measurement use cases.

  2. Seek community feedback on applying the framework to other domains, as we believe our framework is much more general.

  3. Discuss strategies to mitigate bias introduced by individual privacy tracking.

An academic paper describing our privacy framework can be found here.

Goals

To present our individual differential privacy framework for web measurements, gather community feedback on extending its application beyond advertising, and explore strategies for addressing challenges like bias in measurement results.

Agenda

Outline:

  • Background on ad measurements and emerging APIs

  • Our privacy framework: Cookie Monster

  • Discussion on broader applications and bias mitigation

Links
Room
4 Concourse Level - Huntington, ​–​

Camera Effects Coordination

Proposer

Mark Foltz

Description

Real-time effects applied to camera input such as background blur, face framing, and lighting correction are becoming more available to users through their operating systems, browsers, and other software components. These effects manipulate camera input before it reaches Web applications via getUserMedia().

Web applications that want to use camera input (and possibly apply their own effects) need know when effects are applied and respond accordingly.

Background:

Goals

Review current work, community discussion to gather feedback

Agenda

This a WIP and will be updated before the session begins.

  • How should we coordinate behaviors between applications that consume camera input and platforms that want to enhance camera input through effects?

  • Review how camera effects are currently exposed to script

  • Suggest possible improvements

  • (If time) Applicability to browser and OS audio effects

  • Questions and discussion

Links
Room
4 Concourse Level - Oceanside, ​–​

Compression: Brotli Support

Proposer

Brandon Stewart

Description

The session is on discussing open issues with adding Brotli to the Compression spec.

Goals

Aim to discuss open issues with Brotli support in the Compression spec.

Links
Room
4 Concourse Level - Capistrano, ​–​

Digital Wallet Project in Taiwan

Tracks
Wallets
Proposer

Denken Chen

Description

The Ministry of Digital Affairs (moda) from Taiwan government, has initiated a four-year (2024-2027) project, aiming to build a permissionless infrastructure that secures digital identity.

The digital wallet project will build digital civic infrastructure of issuer, wallet, and verifier based on the standards of W3C Decentralized Identifiers (DID) and Verifiable Credentials (VC). It features:

  1. Public Money, Public Code: The software parts will be licensed as open source software to the public.

  2. Open Ecosystem: To expand use cases, we welcome everyone to become an issuer, wallet, or verifier provider to meet any market needs.

  3. Sandbox Environment: we aim to maintain a testing playground for various needs starting in 2025. If you’re interested in joining, please send an email to our contacts.

We will also hold a bi-monthly Technical Advisory Meeting for discussing related technical issues, trusted registry and its trust model.

Goals

For anyone contributing in the W3C DID and VC ecosystem, we welcome any cooperation opportunities ranging from software interoperability, DID/VC use cases, and international standards development and collaboration initiatives.

Agenda

The Ministry of Digital Affairs (moda) from Taiwan government, has started building a permissionless infrastructure that secures digital identity.

  1. Project Overview

  2. Collaboration Opportunities

Links
Room
-1 Lower Level - Catalina 5, ​–​

Discuss: How to build a new feature for the web platform — and make it a success with developers

Tracks
Feature lifecycle
Proposer

Michael[tm] Smith (sideshowbarker)

Description

The goal of this session is to explore and discuss how to best get new features for the platform successfully created, implemented, tested, documented, and adopted — likely with active participation in the session from some people who’ve had experience in each of those areas and who can offer particular “lessons learned” insights and tips. Also:

  • documenting the process/advice (brainstorming, with the goal of writing something up from the session notes)

  • discussing ways in which the existing process might be improved

  • answering questions about parts of the process that may be especially mysterious to most people

Goals

The session goal is to discuss and help each other understand how to successfully get new features into the platform.

Agenda

This session aims to a very interactive discussion session, along the “How to facilitate a breakout discussion” guidelines.

So when you come to the session, please be prepared to discuss — with the discussion we all have together being guided by the following “How to build a new feature for the web platform” outline:

11-step process (zero-indexed, in hex):

  1. Describing the problem: What specific problem are you trying to solve. Who are you trying to solve it for?

  2. Proposing a solution; writing a good explainer with a problem description + proposed solution (optional/TODO step)

  3. Initiating and leading a focused discussion in a spec issue tracker about the problem and possible solutions.

  4. Putting together a spec or spec PR for a problem solution (and learning spec-publishing tools and their quirks).

  5. Writing good WPTs and getting attention for them from reviewers.

  6. Using browser-project bug/issue trackers to raise compelling implementation requests.

  7. Contributing an implementation patch to a browser project (and learning the project’s patch-contribution process).

  8. Getting documentation written for your feature in MDN (working with MDN writers/editors and technical reviewers).

  9. Driving web-developer adoption through outreach in places where web-developers pay attention.

  10. Monitoring web-developer experience/success and identifying web-developer pain points/frustrations.

   A. Iterating over each step as needed (including, going back to step #0 and repeating the whole cycle)

* Common off-by-one error many folks make: starting at step #1 (proposing solutions without first describing problems).

Resources






  • https://github.com/tc39/ecma402/blob/main/CONTRIBUTING.md

  • https://tc39.es/process-document/


  • https://web-platform-tests.org/writing-tests/

  • https://github.com/tc39/test262/blob/main/CONTRIBUTING.md


  • https://webkit.org/contributing-code/

  • https://firefox-source-docs.mozilla.org/

  • https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/contributing.md


  • https://github.com/mdn/content/blob/main/CONTRIBUTING.md


Links
Room
-1 Lower Level - Catalina 1, ​–​

Harmonizing Identity-Related Web Platform APIs

Tracks
Identity
Proposer

Tim Cappalli, Sam Goto, Marcos Caceres, Matthew Miller

Description

There are currently three active work streams for identity-related Web Platform APIs in the W3C: the Digital Credentials API (DC API), Federated Credential Management (FedCM), and the Web Authentication API (WebAuthn).

In each of these work streams, there have been some common discussion items including flexible but privacy preserving error codes, selector experience and query syntax, conditionally mediated flows, credential and user account identifiers, along with discussion around how these APIs should interact in the future (ex: requesting a VDC -or- an OIDC ID Token in one call). NOTE: Payments will be out of scope for this discussion.

This breakout is intended to be a collaborative, working session. The focus will be on gaining consensus on the more tactical items like errors codes and selectors, with some time at the end reserved for forward looking ideas.

Goals

This breakout is intended to be a collaborative, working session. The focus will be on gaining consensus on the more tactical items like errors codes and selectors, with some time at the end reserved for forward looking ideas.

Agenda

https://docs.google.com/document/d/15IiQS0yPzWML3zRHGQ_JQ5xAO5bIgrcJE3sNdwrgSHk/

Links
Room
4 Concourse Level - Manhattan, ​–​

HTTPS for Local Networks

Proposer

Carlos IbarraLopez

Description

It is not possible to get a publicly trusted CA to sign a certificate for a local domain (i.e. a non-publicly resolvable domain name such as router.local, printer.home, 192.168.1.1, etc), so currently router configuration pages, IoT devices, media servers, etc. have to either: not use TLS, rely on complicated workarounds, or use self-signed certificates and ask users to click through security warnings.

This session's goal is to explore potential solutions to this problem, such as PAKE (Password-authenticated key exchange) and TOFU (trust on first use).

There was previously a Community Group dedicated to this problem, but discussions seem to have stalled, and the group was closed in 2023.

Goals

Discuss potential ways HTTPS can be supported in local networks

Links
Room
-1 Lower Level - Catalina 7, ​–​

Next actions for digital manga and comics

Proposer

Shinya Takami, Hadrien Gardeur

Description

Over 10 years passed after EPUB based digital manga and comics have been delivered, there are some issues for them.

This session aims to discuss and collect issues, such as the current situation for EPUB based file format, accessibility for manga contents, format for scrolled comics and so on.

Goals

Sharing the current situation and gathering issues

Agenda
  • Situation and issues for Manga and Comics [25m]

    • in Japan

    • in Europe

    • in North America

  • State of the art and next steps [30m]

    • Spread and Page

    • Bitmap vs HTML/SVG

    • Accessibility

    • Scrolled Comics

  • Other topics for Manga and Comics [5m]

Links
Room
4 Concourse Level - Laguna, ​–​

Open styleable shadow tree and theming

Tracks
Web Components
Proposer

Ryosuke Niwa

Description

Session to discuss open styleable shadow tree and theming https://github.com/WICG/webcomponents/issues/909

Goals

Come up with a concrete proposal for open styleable shadow tree and theming

Links
Room
-1 Lower Level - Catalina 3, ​–​

Sync on Web, now and next of realtime media services on web

Tracks
Real-time Web
Proposer

Kensaku KOMATSU

Description

Real time Web is improving, in this moment we have an ability to build realtime media services on web w/ WebRTC, WebCodecs, Web Audio ... etc.

IMO, one interesting movement for this would be synchronization, which means "time alignment". General case for "time alignment" would be lip-sync, but with Media over QUIC, mainly leveraging to WebCodes and WebTransport, we can develop more synchronization use cases with media streaming and arbitrary time-related data. Examples would be synchronization of realtime text, haptics, midi events in co-watching or stream-media play-out.

With this feature, we believe that the potential of web would be improving more and more, since we can build Real/Virtual orchestrated services. Use cases would be meta verse, live viewing with MIDI data, remote robot operation etc.

For these realtime use cases, clock accuracy and frequency is quite important. And we have several questions for this. For example, requestAnimationFrame() is enough or not for the future use cases? In this breakout session, we will discuss about these topic according to clock and sync on Web.

Goals

figure out gap for sync on Web.

Agenda
  1. Presentations and demo

  2. Discussion

  3. Wrap-up

Links
Room
-1 Lower Level - Catalina 2, ​–​

View transitions: a taste of the future

Tracks
UX
Proposer

Noam Rosenthal, Khushal Sagar

Description

This is an opportunity to share the status of two future-looking enhancements that are in the long term pipeline for view transitions, and are in their early design phase:

  1. gesture-based view transitions: using a preemptive navigation gesture (swipe) to trigger a view-transition

  2. cross-origin view transitions: finding a secure way to allow a subset of what's possible with view transitions to a navigation between two origins that don't necessarily trust each other.

Goals

Introduce the thinking behind the two future enhancement, and gather early stage feedback, pushback, and hopefully enthusiasm!

Since these features touch on UX, navigations, performance and security, they could be of interest to people outside the CSS working group.

Links
Room
4 Concourse Level - San Clemente, ​–​

W3C Sustainability meeting

Proposer

Tantek Çelik

Description

The Sustainability Community Group (CG) identified a number of projects and work areas in its first meeting. Since then, two things key things have happened: First, the Sustainable Web Design CG has been forked off to its own in-progress Interest Group charter (on w3c-ac-members member only link) to focus on the Web Sustainability Guidelines. Thus this Sustainability meeting will focus on other areas listed. Second, the Ethical Web Principles (EWP) has been voted on by the W3C Advisory Committee, and there were no objections to the section on environmental sustainability, which provides an excellent forward-looking focus for a Sustainability CG meeting.

Goals

The goal of this session is to discuss and pick a few of the Sustainability CG work areas that are most directly and actionably aligned with the EWP encouragement to “endeavor not to do further harm to the environment when we introduce new technologies to the web”, and identify goals and next steps towards those goals. For example, expanding on the Principles identified by the EWP, and how to do a sustainability (s12y) assessment of new and proposed technologies towards establishing a practice of Sustainability Horizontal Reviews to build on W3C’s existing accessibility (a11y), internationalization (i18n), security, and privacy horizontal reviews.

Agenda

To be added to https://www.w3.org/wiki/Sustainability if this session is approved.

(Originally published at: https://tantek.com/2024/260/b1/w3c-sustainability-meeting)

Links
Room
4 Concourse Level - Palos Verdes, ​–​

What security guidance should we give web developers?

Proposer

Will Bamberg, Daniel Appelquist

Description

There are a lot of web platform features that relate to security, and they generally have pretty comprehensive documentation on MDN. But there's not a lot of normative guidance: which features should people use (and which should they avoid), why should they use them, and how should they use them?

In the Security Web Application Guidelines Community Group (SWAG CG) we've been trying to understand these questions, partly so we can update MDN with this sort of normative guidance for developers with deadlines. So this very open-ended session is proposed to gather input on security documentation requirements.

Goals

Security documentation requirements.

Agenda

https://wbamberg.github.io/web-security-w3c-breakouts-september-2024/Templates/Overview.html

Links
Room
4 Concourse Level - Redondo, ​–​

Why is it like this? Installed Web Apps - how they are built, function, and struggle today.

Tracks
Web Apps
Proposer

Daniel Murphy, Reilly Grant

Description

Installing web applications has been around for a while now, and common patterns, requirements, and problems have emerged. This presentation will go over these things with some case studies, and hopes to inform future development of web platform functionality to provide a stable, non-flaky, and functional platform for developers to create competitive and rich user experiences.

Goals

Understanding web app functionality, structures, problems, and common gotchas today.

Agenda

Presentation link: https://bit.ly/installed-web-app-state-struggles-2024-presentation Minutes: https://www.w3.org/2024/09/25-web-apps-struggle-minutes.html

Links
Room
2 Ballroom Level - California B, ​–​

Skip

Session 5,

Capture Prevention For Privacy Protection

Proposer

Xiaohan Wang

Description

Capturing of the screen, window, tab and even web elements has made it very convenient for users to share information on the web. There have also been efforts to prevent or restrict capturing to reduce data exfiltration, e.g. in an enterprise environment, or for content protection. We'd like to review capture prevention use cases, and discuss new perspectives like user privacy, e.g. to avoid accidental information leak.

Goals

Community discussion to gather interests, ideas and feedback

Links
Room
-1 Lower Level - Catalina 1, ​–​

Cloud Edge Client Coordination

Proposer

Dapeng(Max) Liu, Michael McCool

Description

Enabling workload orchestration among central cloud, edge cloud, and clients has many useful use cases, such as accelerating AI applications, streaming services, and cloud gaming.

However, there is no standardized mechanism for workload coordination and orchestration between central cloud, edge cloud, and clients, which may hinder the interoperability of the workload user, cloud provider, client-side OS, and applications.

This session will discuss the emerging new use cases and standard gaps of cloud, edge, client coordination.

Goals

Get feedback and discuss gaps in standards today to realise the emerging use-cases.

Agenda
  1. Discuss emerging use cases (AI model use case, Home AI/IoT use case, Cloud gaming use case; 10m)

  2. DEMO (EdgeRoutine; 5m)

  3. Discuss and identify standards gaps

    • list of standard gaps (25m)

    • prioritize identified standard gap (10m)

    • followup actions (10m)

Links
Room
-1 Lower Level - Catalina 2, ​–​

CSS Modules

Tracks
Web Components
Proposer

Ryosuke Niwa

Description

Session to discuss CSS modules and how they work with declarative shadow DOM: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Goals

Concrete proposal for CSS Module MVP

Links
Room
-1 Lower Level - Catalina 3, ​–​

Enabling carousel design patterns in CSS

Proposer

Robert Flack

Description

Carousels are an often used design pattern on the web. They are used in a variety of contexts, from product listing pages to slideshow like content. OpenUI has explored a range of carousel designs, showing that the specific layout and appearance can vary dramatically. They are also provided by many frameworks as components, however implementing a carousel correctly is complicated and often results in inconsistent and sometimes inaccessible implementations on the web today.

There are a set of problems being solved by carousels, which we believe could be provided by a set of simple incremental CSS features, allowing developers to combine these CSS features to create the various designs in a completely customizable fashion. CSS-only component libraries could be built to further simplify this process with an eventual built-in style similar to customizable select.

Prior discussions:

  • Carousel APIs generally: https://github.com/w3c/csswg-drafts/issues/9745

Goals

Share planned feature set and demos. Discuss gaps and plan how the related features should work.

Agenda
  1. Introduction / update https://github.com/w3c/csswg-drafts/issues/9745

  2. Scroll markers https://github.com/w3c/csswg-drafts/issues/10720

  3. Inert https://github.com/w3c/csswg-drafts/issues/10711

  4. Limited fragmentainer styling (e.g. columns) https://github.com/w3c/csswg-drafts/issues/10715

  5. Scroll buttons https://github.com/w3c/csswg-drafts/issues/10722

  6. Focus order of the generated controls https://github.com/w3c/csswg-drafts/issues/10912

  7. Active marker calculation https://github.com/w3c/csswg-drafts/issues/10917

Links
Room
4 Concourse Level - Redondo, ​–​

End-to-End Encryption (E2EE) on the Social Web

Proposer

Dmitri Zagidulin

Description

E2EE is useful in several key aspects of the Social Web (such as private Direct Messages), as well as for backend storage in general. Join us for a discussion of the Social Web E2EE roadmap and related specifications.

Goals

Community Discussion of E2EE Issues in the context of the Social Web

Links
Room
4 Concourse Level - Laguna, ​–​

Integrating UI components is too damn hard!

Tracks
Web Components
Proposer

Lea Verou, Keith Cirkel

Description

The vision of authors being able to drop components and UI libraries into their pages and have things Just Work™ and look right (at least to a first order approximation) is still largely unrealized. Integrating any UI component is incredibly laborious, as it requires manually communicating fine grained design tokens to every single component.

This Web Awesome tutorial illustrates the problem perfectly:

https://youtu.be/JhfYeXLfWdI?si=vF3xRai2QrjabVFv&t=277

image

And this is just for assigning a certain hue as the primary color of a whole page — the effort is duplicated for every third-party UI component that uses colors, fonts, measurements, font sizes, etc. Same-party components can use the same naming convention to reduce effort, but that doesn't work for components from different entities.

To reduce integration effort, we need to reduce the amount of information the host page needs to communicate about its design to each individual component. Some avenues are:

  1. standardized ways to set design tokens (e.g. the page’s primary color or serif font) in a way that can be read by other components

  2. ways to derive tokens from core tokens (e.g. a light tint from a primary color, or the next smaller font size in a scale) to minimize how many tokens need to be communicated.

  3. Ways for components to adopt and repurpose page styles of existing (standard) elements

  4. ???

Goals

Flesh out ideas for potential directions, see which are most viable in terms of I/E

Agenda
  1. Discuss requirements and potential directions

  2. Discuss relevant proposals:

    • https://github.com/w3c/csswg-drafts/issues/9992

    • https://github.com/w3c/csswg-drafts/issues/9999

    • https://github.com/w3c/csswg-drafts/issues/10452

    • https://github.com/w3c/csswg-drafts/issues/9660

    • https://github.com/w3c/csswg-drafts/issues/10222

    • https://github.com/w3c/csswg-drafts/issues/5900

Links
Room
-1 Lower Level - Catalina 7, ​–​

Let’s actually fix web notifications

Tracks
Permissions
Proposer

Serena Chen, Balazs Engedy

Description

Web Notifications are often used as a channel for unwanted spam. Even when the notifications are initially wanted, it can be difficult for people to work out how to unsubscribe to their notification subscriptions. The notifications permission grants never expire. It is also a common observed pattern from some websites that they socially engineer people into accepting the notification permission, for example by withholding site content or functionality until the permission is granted. In this session we would like to propose and discuss potential alternatives for structurally solving the aforementioned issues. These include:

1: Make notifications not-promptable

Instead of showing an interruptive pop-up when websites request notification permission, browsers could silently add a settings row available to the user in secondary browser UI, like so:

Group 2

Then, if the user wishes to subscribe to notifications from a website, they can proactively navigate to the browser UI to turn this toggle on. The benefit of this solution is (even if websites socially engineer users to grant them notifications permission), through the act of navigating to browser UI to turn on notifications, people inherently learn where to go to turn it off.

The drawbacks here are centered on discoverability, i.e., whether users will be able to find how to grant notifications when they actually want them. However, given the current prevalence of unwanted notification prompts, this might be a tradeoff worth making.

2: Make default notifications behaviour require an open and active tab

Most other permission types existing today require the website to be in an open and active browser tab for the capability to work. Notifications notably differs: it allows websites to message people even if they close all tabs from that website. In some ways, this is the point of the Web Push API.

Making the default notification behaviour tied to whether tabs from that origin are open gives people an intuitive way to sample notifications from a site while it’s still open, and to silence these notifications if they are unwanted. For sites that the user trusts highly, they can “upgrade” the permission to include the ability to notify them even when tabs from that site are closed. For installed web-apps, the "upgraded" behaviour could be the default.

3: Expire stale notification permissions

Current decisions on notification permission prompts are permanent. The browser does not do any automatic clean-up of stale notification subscriptions, even if they are from a site that the user has not interacted with for many years.

Clarifying the purpose of the Web Push and Web Notification APIs on a philosophical level – amongst browser vendors as well as web developers – would allow user agents to enable helpful notifications while curbing unwanted notifications. For example, if we can agree that the purpose of notifications is to inform users about content being changed on a site, and in response, users are expected to actually visit the sender origin within a reasonable time window (such as within a few months), user agents could expire permission grants outside that reasonable time window. It is an open question if there are legitimate in-the-wild use cases for notifications that users only read, never interact with, nor do they ever visit the sending website again.

Goals

Share and discuss solutions to curb spammy and abusive notifications on the web, and to help users exert better control over their notifications. Identify points of consensus and points of contention. Identify open questions to be answered to sort out points of contention. Identify practical next steps to improve Web Notifications.

Agenda
  1. Intro: Web Push Notifications problem space

  2. Potential solutions + discussion i. Make notifications not-promptable ii. Notifications to require open tab iii. Expiry for notification grants iv. Any other potential solutions from the group

  3. Identify points of consensus and points of contention i. What are the open questions to answer to sort out the points of contention?

  4. Next steps

Links
Room
4 Concourse Level - Oceanside, ​–​

One Year Update: Partitioning :visited links history

Proposer

Kyra Seevers, Artur Janc, Mike Taylor

Description

This breakout session will serve as a 1 year update to the partitioning :visited links project. We will:

  • Briefly recap the Partitioning :visited links history explainer.

  • Go over implementation progress in Chrome and highlight solutions that may be valuable to other developers.

  • Discuss public experiment results and key takeaways from our launch.

  • Discuss how to spec this proposal and how standardization choices now may affect future privacy improvements to CSS

  • Determine what work remains towards removing the 2010 privacy mitigations.

Goals

To present implementation and experimentation updates, and discuss concrete steps towards CSS standardization.

Links
Room
4 Concourse Level - Capistrano, ​–​

Real World Identity and the Web... Continued

Tracks
Wallets
Proposer

Tim Cappalli, Heather Flanagan

Description

At TPAC 2023, we introduced the topic of digital identity wallets and their use on the web, and asked the community for use cases, concerns, and asked browser engine maintainers to express interest in this work.

This evolved into a work item in the WICG, the Digital Credentials API, where folks from multiple communities involved in the digitally verifiable credentials space (including other W3C CGs and WGs, the OpenID Foundation, national standards organizations, privacy experts, issuers, verifiers, wallet makers, and more) have been working together to provide a safe, secure, privacy preserving method of sharing digital credentials on the web.

This session will provide an update on the work, the threat models being evaluated, upcoming work items, and open discussion.

Goals

Provide an update on the work stream to the wider community, hear new issues or concerns, receive feedback on core work items

Agenda
Links
Room
-1 Lower Level - Catalina 5, ​–​

Registries for W3C Specifications

Proposer

Ege Korkan

Description

In the related session of the breakout day of 2024, it was found out that the wide W3C community needs a place to discuss registry mechanism related topics such as best practices, experiences, and tooling. With the Web of Things WG advancing in defining their registry, we want to use this session to present the analysis that was done so far, collect opinions from others.

Goals

Experience Sharing, Discussion

Agenda
  • Wrap up of Breakout Day 2024, Registry Session

  • Experience from the development of the WoT Binding Registry

  • Feedback and Discussion

Links
Room
2 Ballroom Level - California A, ​–​

Threat Modeling @ W3C

Proposer

Simone Onofri

Description

When a standard is written, it's required to write Security and Privacy Considerations and, if the technology is particularly disruptive, to sample the human rights impact. One of the processes that can be used to get these considerations in a practical and structured way is to use Threat Modeling, a repeatable process with several techniques to understand best what we're doing, what can't go wrong, and what we can do about it. In this session, we will explore how to initiate Threat Modeling from the early stages of a specification, using practical examples. This approach ensures that everything is secure, respects privacy, and is properly documented.

Goals

Secure the standards

Agenda

Agenda

Links
Room
4 Concourse Level - Manhattan, ​–​

W3C Vision — Getting To Statement

Proposer

Tantek Çelik, Chris Wilson

Description

The Advisory Board (AB) published the W3C Vision as a Note earlier this year. The Vision Task Force (VisionTF) has processed most issues and a small number of Statement Blockers remain. This breakout session is an open session for working through the remaining Statement Blocker issues.

Goals

The goal of this session is reach consensus resolutions on the remaining Statement Blocker issues for the W3C Vision, so the Vision Task Force can prepare an updated W3C Vision Note for publication as a proposed Statement for an Advisory Committee vote.

Agenda

w3.org/wiki/AB/VisionTF/2024-09-25

(Originally published at: https://tantek.com/2024/257/b1/w3c-vision-getting-to-statement)

Links
Room
4 Concourse Level - Huntington, ​–​

Web Install API

Tracks
Web Apps
Proposer

Diego Gonzalez-Zuniga, Amanda Baker

Description

This breakout will serve as an update to the broader community about the Web Install API. We will be discussing the shape of the API, decisions behind it, and show the progress around the API.

As the platform continues to evolve with richer and more powerful capabilities, more developers lean on PWAs to reach their customers. Distribution is still tied to native app stores or proprietary protocol workarounds, with one big gap related toa application distribution.

Goals

Showcase the Web Install API and give an update on development. We want to gather community feedback on the API.

Agenda

Meeting minutes: https://docs.google.com/document/d/1ItMpSpuV1Cszg_64o4D2MJMT7KlWKBTz8jhWg3y3A5E/edit?usp=sharing

and presentation as a pdf: https://drive.google.com/file/d/1-pO4Ar5EpznGuNX-0AWp25ctIlsOCMcH/view?usp=sharing

Links
Room
2 Ballroom Level - California B, ​–​

Web on the Moon

Proposer

Jay Kishigami

Description

The Artemis plan calls for human habitation of the Moon from 2028, currently under international consideration from the perspectives of habitation, mineral resource collection, food and medicine, and is considered the first step towards sending humans to Mars in the future. Communication with family and others is essential when people are away from Earth for long periods. Astronauts on the ISS are already guaranteed a private conversation with their families on the ground at least once a day, and can even watch football games using web and remote conferencing technology, but the ISS is 400 km from the ground, and its latency is less than that of a geostationary orbit satellite (located 35,786 km above the ground) is said to be 500 ms. The distance to the Moon is 380,000 km, which theoretically translates into a latency of 2,600 ms.

Under these conditions, it is expected to be difficult for people living on the Moon to explore the Web, hold remote meetings with their families or watch football games, as they do on Earth, due to time-outs and other problems with current technology.

In this breakout session, we would like to discuss the possibility of using web technology on the Moon in the same way as on Earth, although the speed of light cannot be exceeded.

Goals

Participants will decide on the direction of future discussions.

Agenda
  1. overview of ISS, Artemis, DTN (RFC4838), etc.

  2. open discussion

Links
Room
4 Concourse Level - Palos Verdes, ​–​

Web Speech API Improvements

Proposer

Evan Liu

Description

Chrome is proposing new improvements to the Web Speech API, including:

Offline speech recognition: Allow speech recognition without an internet connection. [1] MediaStreamTrack support: Enable seamless integration of speech recognition with audio and video streams. [2] Spoken punctuation parameter: Add a new parameter to the speech recognition API that allows developers to control how spoken punctuation marks are handled in the transcription. [3]

Related Github issues: [1] Offline/on-device speech recognition #108 [2] Support SpeechRecognition on an audio MediaStreamTrack #66 [3] Speech recognition parameter for spoken punctuation #114

Goals

Discuss and reach a consensus on the proposed changes to the Web Speech API

Links
Room
4 Concourse Level - San Clemente, ​–​

Skip

Session 6,

Blending Realities: Building An Open Web Wide World

Proposer

Harry Wang, Rocman Zhao

Description

Building blocks for constructing a tangible virtual world has begun to take shape. Technologies from various fields are becoming increasingly mature, such as gaming, social platforms, digital twins, and virtual reality. This session aims to trigger the discussion on how each stakeholder may collaborate to co-create a tangible virtual world that is interconnected, mutually beneficial, supportive and belongs to all. We need a set of standards that enable the integration of individual efforts to build an open platform on web, fostering prosperity through cooperation rather than competition. This session will delve into our recent endeavors in crafting virtual world experiences on Tencent products. We will share insights from our development process, highlight the innovative solutions we implemented, and discuss the hurdles we encountered along the way.

The following aspects will be addressed:

  1. Types and Corresponding Roles: Sites as Service Integrators and Programs as Service Providers

  2. Scoping: Defining the Origins of Assets and Elements

  3. Asset Deployments: Planning Asset URIs and Deploying according to Scoping

  4. Site Hierarchy: Inter-Site Integration through Contracts and Administration according to Scoping

  5. Site-Program Integration: Cooperating between Programs and Sites through Contracts

  6. Permission Controls: Managing Authorization for Assets and Elements across Sites/Programs

  7. Version Management: Independent Releases by Sites/Programs with Unified Synchronization across the Virtual World

  8. Multi-user Interaction: Distributed across Sites and Seamlessly Integrated through On-Demand Pub/Sub for Users

web-wide-world-basics
Goals

1)Call for participation: co-create one tangible virtual world that is globally shared, co-constructed, and interconnected on web. 2)Share ideas on user experience, economic models, technological challenges. 3)DIscuss standard needs for asset, logic, user interaction, UI and business integrations.

Agenda
  1. Introduction on Web Wide World

  2. Live demo

  3. Open discussion Slides are available online

Links
Room
2 Ballroom Level - California B, ​–​

Bringing more UI utilities to specs

Proposer

Marcos Caceres

Description

When used in Editor's drafts, Respec and Bikeshed provide very powerful/useful JS controls that provide a lot o value to the community. For example, both Respec and Bikeshed allow clicking on variables in algorithms, which get highlighted to show where they are used. ReSpec adds a copy button to WebIDL, letting readers copy WebIDL with a single click, etc.

Other useful things are the definition boxes, MDN annotations, etc.

Unfortunately, these are inconsistently presented across specs/tools providing different experiences and capabilities.. as a community, we should look to align on the design of the above things, and expose these JS tools to all specs that need then.

It would be great to have a session where we look the great feature both Bikeshed and Respec provide, and see where we have overlapping features, and start looking at how we can harmonize the JS libraries into a single codebase.

It would be great if we could find a UI designer to help us make these tools even better... and, as a bonus, it would be cool if we could start using popup and other modern web features to achieve these things.

Hi @tabatkins, @sideshowbarker, @sidvishnoi, @fantasai, @dontcallmedom, @tidoust, @deniak 👋

Goals

Shared JS libraries for spec goodies

Agenda
  • Demo what Bikeshed has

  • Demo what Respec has

  • Compare differences

  • Talk about convergence

  • Talk about other neat things we could develop that would help users

  • Talk about what we can bring to TR and maybe let TR/ design handle

Links
Room
4 Concourse Level - Oceanside, ​–​

CBOR-LD, YAML-LD & the JSON-LD Recharter

Proposer

Mandy Venables, Benjamin Young

Description

The upcoming JSON-LD recharter includes two new compatible formats based on the JSON-LD data model: CBOR-LD and YAML-LD. CBOR-LD provides a highly compressed format keeping data small enough to be represented in QR codes, distributed over short-lived, low bandwidth scenarios, or enabling smaller device use cases when coupled with W3C Web of Thing descriptions. YAML-LD aims to provide simpler human-friendly formatting while staying fully compatible with the JSON-LD data model allowing for easy round-tripping between the two formats. The WG is also exploring a handful of other documents related to internationalization and enhanced processing modes.

Goals

Inform members on the upcoming JSON-LD recharter.

Links
Room
-1 Lower Level - Catalina 5, ​–​

Discussion for Proposal: asynchronous event listeners

Proposer

Michal Mocny, Dominic Farolino

Description

There is a proposal for async event listeners: https://github.com/whatwg/dom/issues/1308

Several use cases identified as related (https://github.com/whatwg/dom/issues/1308#issuecomment-2312993127):

  • "passive" event dispatch. Observe, but don't block, event dispatch. Don't need preventDefault.

  • lazy loading "controllers", aka progressive hydration.

  • Tracking long running "async effects" which follow the sync event dispatch.

  • "document still loading" use cases

  • "document started unloading" use cases

Goals

Discussion and sharing early feedback.

Links
Room
2 Ballroom Level - California A, ​–​

DOM Parts

Tracks
Web Components
Proposer

Ryosuke Niwa

Description

Session to discuss DOM parts proposal: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Imperative.md https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Declarative-Template.md

Goals

Come up with a concrete MVP for DOM parts

Links
Room
-1 Lower Level - Catalina 3, ​–​

Horizontal reviews at W3C and beyond

Tracks
Standards
Proposer

Philippe Le Hegaret

Description

This session is meant to touch base on how horizontal reviews are conducted at W3C and for the Web

In scope:

  • Scope of horizontal reviews: W3C Technical Reports, W3C Community Group reports, Web specifications from other organizations (WHATWG, IETF, ECMA, etc.)

  • How to get horizontal review

  • Horizontal review questionnaires

  • GitHub Issue review requests and trackers

  • Tooling improvements and needs

Goals

Evolve horizontal reviews of Web specifications

Agenda
  1. Slides

  2. Discussion

Links
Room
4 Concourse Level - Huntington, ​–​

Prompt spam and reputation attacks associated with requestStorageAccessFor

Proposer

Aaron Selya, Chris Fredrickson

Description

Discussion on how to expand the requestStorageAccessFor API to reduce the potential for it to be used as a vector for reputation attacks and prompt spam.

These are issues because embedded sites can not control who embeds them. Which means that the top level site can prompt on behalf of the embedded site. This could potentially damage the embedder’s reputation and/or spam the user with the generation of a large number of prompts.

Goals

gather input from the community and gain consensus on how to address the problems

Agenda

Introduce the problem Review how the browsers have addressed it so far Discuss more potential solutions

Links
Room
4 Concourse Level - Redondo, ​–​

Reconciling UIEvents and the DOM spec

Proposer

Gary Kacmarcik

Description

Identify where definitions exist in the DOM spec that can be used by UIEvents, with the goal of removing all duplication and to enable a proper algorithmic description of all UIEvents.

Goals

Identify where UIEVents needs to hook into the DOM spec

Agenda

_No response_he

Links
Room
4 Concourse Level - Palos Verdes, ​–​

Social Web and Fediverse Year in Review

Proposer

Dmitri Zagidulin

Description

Join us as we discuss the SocialWeb CG activities and developments in the areas of Social Web, Fediverse, distributed social software, over this past year.

Goals

Appraise the SocialWeb developer community of relevant specs and developments

Links
Room
-1 Lower Level - Catalina 7, ​–​

Styling form controls

Proposer

Tim Nguyen

Description

Discussing proposals around styling form controls.

Goals

Brainstorming and refining ideas

Agenda
  • appearance: base

  • general design principles

  • pseudo-elements

  • layout

  • ??

Links
Room
4 Concourse Level - Manhattan, ​–​

Web-based Digital Twins for Smart Cities

Proposer

Kazuyuki Ashimura, Michael Koster

Description

Based on the discussion during the W3C workshop on Smart Cities in 2021 and then two follow-up breakout sessions with invited key stakeholders from related SDOs (one during TPAC 2022 and another during TPAC 2023), we identified the stakeholders around Smart City standardization and reasonable applications for Smart City technologies. In addition, we got thoughtful input on how to improve the draft Charter Charter of the proposed Web-based Digital Twins for Smart Cities Interest Group for further discussions.

Some of the key input included:

  • "Digital Twins" should be the key concept for Smart Cities standardization.

  • Web standards, e.g., Web of Things (WoT), Decentralized Identifiers (DID) and Verifiable Credentials (VC), should be considered as possible key modules for the possible Web-based Digital Twins framework.

  • Standard vocabulary for semantic interoperability is also required for the platform.

  • Collaboration by related SDOs is necessary for further discussion, and W3C should become the central hub for the discussion given Web standards play very important roles.

Now the Web-based Digital Twins for Smart Cities Interest Group has been launched, and we'd like to start actual discussion about with the key stakeholders from related SDOs, industries and coutries/cities to work on the following deliverables of the Interest Group:

  • Survey on the existing technologies and standards for Smart Cities, e.g., possible building blocks of Digital Twin Framework and standardized Vocabularies for Smart Cities

  • Best Practices on what kind of technologies to be applied to what kind of Smart Cities applications, e.g., WoT, Automotive, Geospatial, VR/AR, Speech and Semantic Web to be applied to improved accessibility, visitor guidance and energy management

  • Use cases and requirements for Smart Cities

Goals

Following the breakout discussion during TPAC 2023, we'll summarize the discussion around Smart Cities within W3C so far, share the Charter of the Web-based Digital Twins for Smart Cities IG, and ask the key steakholders to join the discussion of the IG to kick-start the group's activity.

Agenda
  1. Review the discussion so far (Workshop and follow-up meetings)

  2. Review the IG Charter

  3. Discuss next steps: high-priority issues, clarify which existing work to be considered, how to proceed the discussion (monthly calls?)

Links
Room
-1 Lower Level - Catalina 1, ​–​

What can W3C do for members?

Proposer

Tzviya Siegman, Naomi Yoshizawa

Description

W3C wants to know how to improve member engagement and member retention. What would you like to see W3C do for you and your organization? Are you interested in regional meetups? Information about charters and recommendations that are relevant to your organization? Creating relationships with other standards organizations? Tell us what you would like to see W3C do for you. This session will have a short introduction and then be an open conversation.

Goals

Brainstorming for Member engagement

Agenda
  • Intro to W3C Member Engagement

  • Discussion

Links
Room
4 Concourse Level - San Clemente, ​–​

WinterCG

Proposer

Andreu Botella

Description

Web platform APIs are typically specified having web browsers as their main target. However, there is a large set of JavaScript runtimes that benefit from having a common API surface with the web platform.

WinterCG is a W3C Community Group focused on the needs of such runtimes, particularly in the server side. The main focus of this CG has been to work on a minimum subset of web platform APIs that all such runtimes would support (the WinterCG Minimum Common API), but we also work on identifying areas where such runtimes would benefit from changes in the web platform specs.

Goals

Exploring the collaboration between the web platform and server-side runtimes.

Agenda

Agenda

Links
Room
4 Concourse Level - Capistrano, ​–​

Skip

QR code for
              www.w3.org/2023/09/TPAC/schedule.html#friday W3C TPAC 2023
Breakout
Full schedule

Times in America/Los_Angeles – meetings ordered by meeting name

-1 Lower Level - Catalina 1 -1 Lower Level - Catalina 2 -1 Lower Level - Catalina 3 -1 Lower Level - Catalina 5 -1 Lower Level - Catalina 7 2 Ballroom Level - California A 2 Ballroom Level - California B 2 Ballroom level - California C 4 Concourse Level - Capistrano 4 Concourse Level - Huntington 4 Concourse Level - Laguna 4 Concourse Level - Manhattan 4 Concourse Level - Oceanside 4 Concourse Level - Palos Verdes 4 Concourse Level - Redondo 4 Concourse Level - San Clemente online & Hilton Anaheim: California Ballroom C, Ballroom Level, Second Floor (Talks), Lanai Deck, Fifth Floor (Gala)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               Breaking Silos: A Collaborative Discussion on Use Cases for Linked Web Storage, 4 Concourse Level - Redondo, ​–​
Browser API for Country Data, 4 Concourse Level - San Clemente, ​–​
Canvas place element, 2 Ballroom Level - California B, ​–​
Deprecation is Hard to Do, & We Can Do it Better, -1 Lower Level - Catalina 7, ​–​
Discover the Italian Digital Identity Wallet, -1 Lower Level - Catalina 5, ​–​
Expanding Verifiable Credentials: Future Standards & Innovations, 4 Concourse Level - Manhattan, ​–​
HTML Model Element Discussion, 4 Concourse Level - Laguna, ​–​
One year update: fenced frames with local unpartitioned data access, 4 Concourse Level - Palos Verdes, ​–​
One Year Update: Using LinkML in Web of Things Specifications, 4 Concourse Level - Capistrano, ​–​
Sharing styles with Declarative Shadow DOM, -1 Lower Level - Catalina 3, ​–​
Trust the Origin, Trust the Content - Originator Profile, -1 Lower Level - Catalina 2, ​–​
User Research on Permissions, 4 Concourse Level - Oceanside, ​–​
Web & Generative AI risks, 2 Ballroom Level - California A, ​–​
Web Standards Beyond The Browser, -1 Lower Level - Catalina 1, ​–​
Assistive Technology Interop through ARIA-AT, 4 Concourse Level - Palos Verdes, ​–​
Community Group Program Enhancements, 4 Concourse Level - Huntington, ​–​
Device Bound Session Credentials, 4 Concourse Level - Capistrano, ​–​
DID Method Standardization, 4 Concourse Level - Manhattan, ​–​
Lessons learned by an independent implementation of the Digital Identity Wallet in Europe, -1 Lower Level - Catalina 5, ​–​
Page Embedded Permission Control (PEPC): Safely embedding permission entry points in web content, 4 Concourse Level - Oceanside, ​–​
RtpTransport, -1 Lower Level - Catalina 2, ​–​
Scoped custom element registry, -1 Lower Level - Catalina 3, ​–​
Sourcemaps, Security, devices, & more: What you may have missed from TC39 & Ecma, 4 Concourse Level - Laguna, ​–​
System Tray Icon Support for PWAs, 4 Concourse Level - Redondo, ​–​
The Future of Popups!, 4 Concourse Level - San Clemente, ​–​
The Future of TAG Reviews & Other Output, -1 Lower Level - Catalina 7, ​–​
Web API for Hybrid AI, 2 Ballroom Level - California A, ​–​
Web Features: Building an index for the web platform, -1 Lower Level - Catalina 1, ​–​
🐞Ladybird: A new, independent browser engine — written from scratch, 2 Ballroom Level - California B, ​–​
Content Authenticity & the Web, 4 Concourse Level - Redondo, ​–​
Cookie Layering, 4 Concourse Level - Capistrano, ​–​
Curating the web platform's data & documentation, -1 Lower Level - Catalina 1, ​–​
Data & Account Portability on the Social Web, 4 Concourse Level - Palos Verdes, ​–​
Defining views, 4 Concourse Level - San Clemente, ​–​
Demonstration of AI Powered Accessibility Auditing, 2 Ballroom Level - California A, ​–​
Electronic Transferable Records: Implemented Using Transferable Verifiable Credentials, -1 Lower Level - Catalina 5, ​–​
Evolved Video Encoding with WebCodecs, -1 Lower Level - Catalina 2, ​–​
FedCM in practice, 4 Concourse Level - Manhattan, ​–​
Mitigate Threats for Digital Credentials API, 4 Concourse Level - Laguna, ​–​
New Features for the ServiceWorker Performance, 2 Ballroom Level - California B, ​–​
Purposeful Permissions - Adding data use information to permission prompts, 4 Concourse Level - Oceanside, ​–​
Responsible Integration & New Use Cases of DNS Domain Names, 4 Concourse Level - Huntington, ​–​
Simplifying the Updatable REC Process, -1 Lower Level - Catalina 7, ​–​
Web Components & ARIA, -1 Lower Level - Catalina 3, ​–​
AI Model Management, 2 Ballroom Level - California A, ​–​
An Individual Differential Privacy Framework for Rigorous & High-Utility Privacy Accounting in Web Measurement, 4 Concourse Level - Huntington, ​–​
Camera Effects Coordination, 4 Concourse Level - Oceanside, ​–​
Compression: Brotli Support, 4 Concourse Level - Capistrano, ​–​
Digital Wallet Project in Taiwan, -1 Lower Level - Catalina 5, ​–​
Discuss: How to build a new feature for the web platform — & make it a success with developers, -1 Lower Level - Catalina 1, ​–​
Harmonizing Identity-Related Web Platform APIs, 4 Concourse Level - Manhattan, ​–​
HTTPS for Local Networks, -1 Lower Level - Catalina 7, ​–​
Next actions for digital manga & comics, 4 Concourse Level - Laguna, ​–​
Open styleable shadow tree & theming, -1 Lower Level - Catalina 3, ​–​
Sync on Web, now & next of realtime media services on web, -1 Lower Level - Catalina 2, ​–​
View transitions: a taste of the future, 4 Concourse Level - San Clemente, ​–​
W3C Sustainability meeting, 4 Concourse Level - Palos Verdes, ​–​
What security guidance should we give web developers?, 4 Concourse Level - Redondo, ​–​
Why is it like this? Installed Web Apps - how they are built, function, & struggle today., 2 Ballroom Level - California B, ​–​
Capture Prevention For Privacy Protection, -1 Lower Level - Catalina 1, ​–​
Cloud Edge Client Coordination, -1 Lower Level - Catalina 2, ​–​
CSS Modules, -1 Lower Level - Catalina 3, ​–​
Enabling carousel design patterns in CSS, 4 Concourse Level - Redondo, ​–​
End-to-End Encryption (E2EE) on the Social Web, 4 Concourse Level - Laguna, ​–​
Integrating UI components is too damn hard!, -1 Lower Level - Catalina 7, ​–​
Let’s actually fix web notifications, 4 Concourse Level - Oceanside, ​–​
One Year Update: Partitioning :visited links history, 4 Concourse Level - Capistrano, ​–​
Real World Identity & the Web... Continued, -1 Lower Level - Catalina 5, ​–​
Registries for W3C Specifications, 2 Ballroom Level - California A, ​–​
Threat Modeling @ W3C, 4 Concourse Level - Manhattan, ​–​
W3C Vision — Getting To Statement, 4 Concourse Level - Huntington, ​–​
Web Install API, 2 Ballroom Level - California B, ​–​
Web on the Moon, 4 Concourse Level - Palos Verdes, ​–​
Web Speech API Improvements, 4 Concourse Level - San Clemente, ​–​
Blending Realities: Building An Open Web Wide World, 2 Ballroom Level - California B, ​–​
Bringing more UI utilities to specs, 4 Concourse Level - Oceanside, ​–​
CBOR-LD, YAML-LD & the JSON-LD Recharter, -1 Lower Level - Catalina 5, ​–​
Discussion for Proposal: asynchronous event listeners, 2 Ballroom Level - California A, ​–​
DOM Parts, -1 Lower Level - Catalina 3, ​–​
Horizontal reviews at W3C & beyond, 4 Concourse Level - Huntington, ​–​
Prompt spam & reputation attacks associated with requestStorageAccessFor, 4 Concourse Level - Redondo, ​–​
Reconciling UIEvents & the DOM spec, 4 Concourse Level - Palos Verdes, ​–​
Social Web & Fediverse Year in Review, -1 Lower Level - Catalina 7, ​–​
Styling form controls, 4 Concourse Level - Manhattan, ​–​
Web-based Digital Twins for Smart Cities, -1 Lower Level - Catalina 1, ​–​
What can W3C do for members?, 4 Concourse Level - San Clemente, ​–​
WinterCG, 4 Concourse Level - Capistrano, ​–​
W3C Plenary, 2 Ballroom level - California C, ​–​
W3C@30, online & Hilton Anaheim: California Ballroom C, Ballroom Level, Second Floor (Talks), Lanai Deck, Fifth Floor (Gala) , ​–​

Legend: Feature lifecycle, Permissions, UX, Identity, Real-time Web, AI, Web Components, Wallets, Standards, Web Apps. A time like ‘02:00+1’ means 2 a.m. the next day.

Skip

Sponsors

Support TPAC 2024 and get great benefits from our Sponsorship packages.
For further details, contact [email protected]

Who are our sponsors?

Gold sponsor

AWS

Silver sponsor

Google

Bronze sponsor

Igalia