• Explore the interest in developing a target privacy threat model for the Web.

We found broad consensus to build a target privacy threat model in PING, starting from https://jyasskin.github.io/privacy-threat-model/. We also got several concrete suggestions for things to ensure that document covers, which are recorded in the notes.

Video recording

• disseminate knowledge of JS Built-In modules to other hosts built on top of JavaScript (e.g. web browsers), and introduce the proposed governance model to potential stakeholders of additional JS Built-In Module namespaces (e.g. web:)

• Bring input to the MDN Product Advisory Board to see how MDN documentation can evolve to better meet the need from the W3C community
• Learn about the MDN Developer Survey and discuss what conclusions to draw from its results in terms of the W3C standardization agenda

• Make sure attendees are up-to-speed on how to participate in their Groups, get familiar with various documentations and tools used by W3C, including GitHub.

• The primary goal is to have a non-technical discussion about DIDs and prepare W3C members with the messaging they need to make the case publicly for this new type of identifier.

• To advance the DataCue API design between media experts and browser developers, and discuss how to improve synchronisation of media and associated content on the web

The group discussed how to expose timed events and timed metadata within media streams, e.g., ID3 tags or emsg events in CMAF. The discussion focused on whether the API should simply expose an ArrayBuffer, per the HTML5 specification, or expose structured data according to the scheme of the event. Next step is to continue the discussion in a session in the Media Working Group TPAC meeting.

The group also discussed the accuracy of firing of TextTrackCue events during media playback, when seeking, and when adjusting the timing of cues. The HTML spec does not specify a timing accuracy, and implementations vary. The conclusion was to report issues to improve particular implementations, and also add a note to the HTML specification on accuracy.

slides

• Get enough attraction of people to form community group and start working

• Introduce Telecom Authentication to the global web community, to help a better understanding of Telecom Authentication and how the Telecom Authentication is applied by telecom operators. From those teams who are interested in Telecom Authentication standardization, hope to share visions and experiences. Any advices is favourable.

• Raise awareness, exchange ideas, and encourage participation in the pronunciation task force

• The goal is to give users of JSON-LD 1.0 an update on features in the forthcoming JSON-LD 1.1 release, and what the impact on publishing and processing documents may be.

slides

We showed the updates to JSON-LD since the 1.0 release in 2014 and described our transition to CR expected in a couple of weeks.

There was discussion about reactivating the JSON-LD CG to serve as an advocacy point, and to solicit input on a new JSON-LD timeline for subsequent changes.

One area noted was the non-resolution of text direction in both JSON-LD and RDF, which will be discussed in another session. If a solution is found without modifying the RDF data model, potentially the WG could adapt some syntactic sugar to extend the JSON-LD value object to represent text direction more natively.

So far, three implementations (Ruby, JavaScript and Python) are targeted to be updated to 1.1, and we’d like to see more. One implementation area of specific interest is C++, and developers are sought.

• To inform that this is happening, and get more people interested in the issues of high-end Japanese typography and layout in the context of responsive modern digital media.

• Show what is done by the WoT WG/IG based on the WoT standards to all the TPAC attendees and encourage people to collaborate with the group (and join the group :). This time we'd like to show several different combinations of devices/applications and scenarios based on the WoT specifications

• Look at use cases and at how they can be implemented today
• assess possible performance gains if they were implemented with a more efficient mechanism
• refine scope for possible work on the topic
• review the Insertable Media Streams extension to WebRTC PeerConnections proposal + WebCodecs to allow inline media modification
• gauge interest among parties.

After a short introduction to set the context, the group reviewed current performance of media capture use cases and reflected on experience gained on similar topics in Web Audio and Firefox OS project.

The WebCodecs proposal, coupled with hooks to it in dedicated APIs as proposed in the Insertable Media Processing proposal, was hinted as a possible solution in that space, even though WebCodecs does not currently aim at solving raw media processing scenarios for now. More thoughts should be thrown into designing a generic architecture for media processing. There was interest to continue discussions, possibly in the Media & Entertainment Interest Group or in a Community Group.

• Help the global web community to better understand Bullet Chatting and the value of its standardization, and looking for teams interested in Bullet Chatting standardization, hoping to get some feedback and support, and get advice about what the W3C workflow.

• A discussion to understand the community's level of consensus on fundamental questions:
• Mission – W3C’s traditional mission statement is “lead the web to its full potential”. Does the community believe W3C’s basic value proposition need updating, perhaps to focus on some combination of documenting how the web actually works, certifying which products comply with the consensus standards, and focusing on the most pressing challenges to the original vision?
• Leadership – The founding Director is no longer involved with W3C’s day to day operations, but the “Director” has a key role in the process and governance. Would the community be more comfortable with finding another neutral person with considerable expertise who can commit the time to being Director, or delegating tasks such as adjudicating formal objections to some sort of elected council?
• Staffing – What role or roles should the Team prioritize and focus on? Mechanics of consensus building, or technical guidance on solutions?

• Trying to reach consensus on our proposed change to the spec (https://github.com/whatwg/html/pull/3851)

We talked about the current (broken) state of the Web and how Chromium recently changed its user activation model to address related problems. Then we addressed three specific comments our pull request received in the past: scope of the change, testability, and defining activation triggering events. By the end of the session, everyone was aligned with the proposal although there were some concerns about compatibility in edge cases. Chromium's rollout helps assuage some fears but not all. We decided to proceed with caution, and also laid out a longer term plan. See also a more detailed report.

• Discuss efforts underway in the foundation to recruit participation from our project communities into various W3C efforts.
• Discuss opportunities for cross-org collaboration. Highlight areas where OpenJSF projects would be additive to W3C.

• Introduce and provide motivation for new JSON, CSS, and HTML module types.
• Share status of the proposals and implementations.
• Discuss open design questions.

This session opened by introducing proposals for JSON, CSS, and HTML modules, in which the JavaScript module infrastructure is expanded to allow developers to 'import' content of those types in addition to JavaScript. The new modules would participate in the module graph and share all of its benefits: static resolution of dependencies, parallelized loading without extra work by the developer, clear definition of components/API surfaces, and assurance that duplicate dependencies are only processed a single time.

The following 3 open design questions were then introduced and discussed:

1. How should CSS module @imports be handled? Option 1 is to treat @import references in the normal way where each creates a distinct stylesheet reference. Option 2 is to treat @imports as CSS modules in their own right such that duplicate imports share the same CSSStyleSheet identity. The latter option has use cases for theme switching, where replacing the contents of an imported stylesheet will fan out to all locations where it is imported. Some developers have already rolled their own solutions for doing this sort of theme switching so it seems there are uses cases here.
2. Should HTML modules be limited to static content, or should they be allowed to contain <script> and <style> elements that are interpreted as its child modules? The latter option allows developers to build web components with HTML on top, sort of like small web pages. There was some interest from the room in this approach.
3. Using MIME type to determine module type poses security concerns because a compromised distributor could send JavaScript instead of JSON/CSS back to the importer, which would then execute in the importer's domain. CSP was proposed as a solution, but there were concerns about this being opt-in. Other solutions involve specifying the resource type as part of the import statement, though the best way to do this is not yet clear.

• Ensure everyone is up to date on the latest proposed API, implementation status, use cases and interest from developers
• Determine what are the next steps, and concerns if any
• Discuss advanced API topics or use cases.

• Introduce the W3C to the work of the Publishing Working Group, get more feedback on our efforts, raise awareness.

• Highlight new capabilities of wpt and wpt.fyi, gather feedback about top pain points for users.

• Determine interest level from implementers, discuss concerns.

• Introduce and provide motivation for new HTML attribute `aria-vistrualcontent`.
• Demonstrate what such capability enables.
• Share some early prototype feedback.
• Gather feedback and solicit implementer interest

• help the global web community to better understand Mini App and the value of its standardization, find proper way to move forward in W3C

• Figure out how to bring together the accessibility community to build capability, collaboration and community engagement in developing standards that address the challenges of making Virtual and Augmented Reality accessible.

An overview of WAIs current work in the XR space was given, such as in the Research Questions Task force and the APA, including introducing the draft XAUR User Requirements document. We discussed some the current accessibility challenges such as a lack of declarative semantics for accessible XR content, as well as issues with rendering environments and performance.

The Accessibility Object Model (AOM) was discussed, there was a sense that there are limitations with the current AOM, including a lack of implementation of the virtual DOM tree. Other options such as using having native support for glTF in the browser that can give 3D content a DOM for current accessibility APIs to function in XR space were mentioned, as well as how sensor enabled technology may contribute to accessible XR experiences. The need to better understand keyboard and switch requirements was also raised, as well as use of haptics.

• Discuss the open issue of fraud detection and what is required to ship this feature.

• Engage with browser engineers and media experts & gauge interest in pursuing this as new web API

• To identify parties most interested in the generic area of voice interaction and to narrow that down to a set of more specific areas of interest. E-commerce? Fact checking? Media streaming? APIs for Skills? More ...

Roughly 20 people gathered for this lively session that began with a short introductory set of slides, including a video from MIT's Auto-Id lab concerning the proposed Open Voice Network. After further introductory remarks, highlighting a variety of use cases and interests, there was an active discussion. The session was attended by staff from both Microsoft and Google who were close to, but not directly involved in, work on Cortana and Google Home.

The conclusions were:

1. It seems likely that there would be sufficient interest in extending SSML, version 1.1 of which became a Rec in 2010.
2. It further seems likely that there would be interest in defining additional hooks for Web pages to aid voice-driven navigation - things like 'add to basket' or other such common functions. These would almostcertainly be defined as schema.org terms.
3. The voice assistant platforms include a lot of proprietary technologies that are very unlikely to be standardised.
4. There was good agreement around the room that a W3C workshop would be well worth exploring. There were several offers to host such an event.

• We want to gather stories in order to tell a compelling story to the public. W3C Comm team may use this as part of an upcoming crowdfunding campaign.

We heard from the 16 participants how they were drawn to the Web, their hopes and fears for the future, what get us going, etc. Among ourselves were a few people who were born after the Web. We all come from all walks of life and not one of us had a similar journey leading us to the Web. But every single one of us was amazed by the Web and continues to be in awe of its potential. A majority of us expressed how they hold “making the Web a safer place for people” very dearly.

The W3C Communications team will get in touch with the participants as we may wish to use their stories, anonymously or not, to tell a compelling story to the public, possibly even as part of an upcoming crowdfunding campaign.

• motivate the need for a network-based WebAuthn transport
• discuss how this might look as part of the specification
• discuss phishing resistance and proximity

We discussed the feasibility of a network transport for WebAuthn, and found that version 2 of Google's caBLE proposal also solves many of the same problems. We got clarity on our understanding of the properties provided by authenticator proximity, and decided that we would attempt to extend caBLE to support a network transport once a cryptographic binding has been established.

• Rationalize existing proposals to ensure we're on the same page for primitives that should be exposed to the Web.

Discussed the Window Segments proposal and the foldables problem space. Attendees provided great feedback:

• It would be more useful to see the device targeted for these scenarios (help validate use cases)
• CSS/declarative solutions should be explored in more depth, with an eye towards prior art (circular display)
• Insight into how in-market devices work
• Relatively clear that multi-display for Desktop is a separate problem, but what’s the right way to express this in an API surface?

Next steps:

• Address feedback
• Get a draft into WICG and solicit issues there

• Raise awareness and start discussion about this problem and solution. Demonstrate a use of rendersubtree.

The talk covered the proposed rendersubtree attribute and how to use it to make large sections of DOM perform well without virtualization. The presentation (including videos for all demos) and IRC minutes are available. There were a lot of questions and clarifications on the details of rendersubtree.

Things not captured by the spec/explainer or the presentation included:

• performance vs accuracy is a tradeoff, e.g. scroll-bar size and tick-marks for CTRL-f cannot be perfect. When you defer style and layout all you have are estimated sizes
• selections's interaction with content is tricky and still in flux - should hidden content be included in selections (and automatically unhidden)? This may be use-case dependent
• should scrolling cause content hidden with rendersubtree to be revealed (outside of a virtual-scroller context)? Further discussion.
• rendersubtree is a proposed standard, virtual-scroller is not
• the 11MB single-page HTML standard can scroll and resize at 30FPS with the help of rendersubtree.

• Ensure everyone is up to date on the latest API, implementation status, and interaction with the IETF (https://mailarchive.ietf.org/arch/browse/webtransport/ https://tools.ietf.org/wg/dispatch/minutes)
• Determine when and how we should create a WG or CG
• Discuss advanced API topics such as how best to use WHATWG streams, how to handle congestion control, and stream prioritization

• Determine if certain Linked Data Security technologies are ready for standardization.

• The session strives to explain our sense of urgency for keeping the web an attractive application platform given fierce competition. The main objective is building an understanding of the arguments of multiple sides: those who argue the web can’t compete if it’s not equally capable, and those who argue this is not an option for reasons including, but not limited to, privacy or security.

Together with Anssi Kostiainen from Intel, John Jansen from Microsoft, and Thomas Steiner from Google, we jointly organized a breakout session for a more capable web under the umbrella of Project Fugu 🐡. You can see our slides online. In the session, we argued that to remain relevant with native, hybrid, or mini apps, web apps, too, need access to a comparable set of APIs. We briefly touched upon the APIs being worked on by the cross-company project partners, and then opened the floor for an open discussion on why we see the browser-accessible web in danger if we don't move it forward now, despite all fully acknowledged challenges around privacy, security, and compatibility. You can follow the discussion in the excellent(!) session minutes, courtesy of Anssi.

• The primary goal is to answer questions about DIDs and help W3C members understand the market interest in this new type of identifier.

• Determine interest level from implementers, discuss concerns.

• Get feedback from community and develop consensus on Process2020 proposals

• With the continuous improvement of WebRTC related standards and technologies, the combination of WebRTC technology and IMS will renew more vitality.

• Discuss use cases and implications, brainstorm the API

• Gauge developer interest in native 3D support in HTML (similar to image/audio/video tag) and looking forward to a wider collaboration with the community, as well as standardization in W3C.

• Get input from potential users of the API to see what use cases we need to make sure are well supported, as well as from experts of codecs.

• Introduce Editors to new features.

• Ensure everyone knows the state of the IETF discussion and the Chromium implementation
• Recruit collaborators
• Discover concerns and needed changes
• Get advice about what route through the W3C/WHATWG processes to follow

Jeffrey gave an overview of the Web Packaging proposals, implementation, and deployment, and answered questions from the attendees.

Slides

Bruce Lawson presented slides describing the problem statement and motivations for creating a standard.

Following this, Adrian Hope-Bailie walked through some slides describing the proposed API and the architectural decisions that are still being discussed ito how the feature should be deployed to browsers.

This was followed by discussion between the proposers and audience. All of the discussion has been captured as issues against the explainer.

• connect with people/groups that need Registries, to explore how they could work with the proposed formalization

• Help people understand the direction that WebGPU is going, and get feedback from the broader community

• Proposing a New Web that Runs Apps to the W3C

• identify opportunities for web APIs for Edge computing, capitalize on 5G features and look at challenges around security and privacy.

• Find additional use cases, and see if we could be using a better mechanism.

• Discuss the growing overlap between video formats and codecs, and image formats and codecs (e.g. AV1 AVIF, HEVC HEIF, MIAF) and the consequences for browsers, content providers and users.

• Share tools used.

• Bring awareness to current challenges of playing spherical video content and discuss options for standardizing.

• Introduce the W3C to opportunities for addressing Digital Transformation with graph data and rules, together with highly scalable graph algorithms and AI/ML

This session focused on digital transformation as the adoption by organisations of advanced digital technologies as a means to achieve increased efficiency, improved flexibility and greater speed at adapting to changes in business conditions. This emphasises the strategic importance of data and the need for enterprise-wide data management and governance. The business challenges for digital transformation include the need to capture knowledge about information and processes in a machine interpretable form, and to bring people along rather than to impose solutions from above.

From a technical perspective, the integration of information services across organisations is greatly eased with the use of graph models for concepts and relationships. The second part of breakout looked at ideas for simplifying the use of graphs for the average developer, and the increasing importance of machine learning to address scaling issues. Experimental work was presented for an approach based upon decades of progress in Cognitive Psychology that embraces both RDF and Property Graphs. This seeks to build upon the latest models of how the human brain works, and the analogies with Web architecture. Help is sought for gathering use cases and data sets as a basis for driving further progress.

Some links: https://www.w3.org/Data/events/tpac2019/digital-transformation.pdf https://www.w3.org/Data/demos/chunks/chunks.html

• Introduce a proposal for the UndoManager API, which allows web applications to modify and inspect the platform’s undo stack. This has implications for all types of web apps, with particular relevance to editing and productivity apps. We hope to establish context for the UndoManager API, demo a prototype of the API, and gain feedback for our proposal.

• Determine interest level from implementers, discuss concerns.

Bruce Lawson presented slides describing the problem statement and motivations for creating a standard.

Following this, Adrian Hope-Bailie walked through some slides describing the proposed API and the architectural decisions that are still being discussed ito how the feature should be deployed to browsers.

This was followed by discussion between the proposers and audience. All of the discussion has been captured as issues against the explainer.