Meeting minutes
Anssi: first, please welcome:
… Fabio Bernardon from NVIDIA
… Yash Kumar Gupta from Adobe
… Alexandra Klepper and Mark Foltz from Google
… Davis Shaver and Stephen Erickson from The Washington Post
… Matthew Stewart as an individual contributor
… to the WebML Community Group!
Davis: I'm a staff SW engineer at The Washing Post, we're identifying new business models in the AI age
F2F Agenda brainstorming
Repository: webmachinelearning/meetings
Anssi: F2F Agenda issue #35
<gb> Issue 35 WebML WG/CG F2F Agenda - TPAC 2025 (Kobe, Japan) (by anssiko)
Anssi: I want to discuss, review and update draft WebML WG/CG F2F Agenda based on your feedback
… first, I will share the overall F2F plan for both WG and CG because many of you are participating both the groups due to synergies
… note on logistics:
… registration open until 3 November
… meeting dates are 10-11 November 2025 (start on 9/10 for remotes in Pacific timezone!)
… WG topics discussed on the first day
… CG topics discussed on the second day
… please export invites as .ics from:
10 November 2025 (Working Group)
11 November 2025 (Community Group)
Anssi: we have good F2F participation, currently 50 in-person participants including observers, excluding remote participants
… to set the expectations for the F2F meeting:
… F2F is an opportunity to get to know people, including folks outside the group and the wider community
… humans usually work better together when they know each other
… we will not do low-level specification PR reviews on a big screen at the F2F, an async GH-driven work mode is better for that
… rather we try to make resolutions and seek consensus on important issues, chart the path forward, and eat Japanese food in a great company
Anssi: I've put up a draft to solicit feedback via comments for both TBA topics and timing to avoid scheduling conflicts as best as we can
Nitin: I work for LinkedIn and have been following this group's work for long, previous worked on web performance, now looking at new explorations and working on LLM and memory optimizations
Anssi: 11 November 2025 is the Community Group F2F, here's the top-level view:
… - WebMCP
… we can fit 5-6 key issues for discussion
… possible other broader topics include: accessibility, security threat modeling, TAG design review, coordination with other groups e.g. AI Agent Protocol CG
… for the broader topics, we may pull in participants from other groups subject to their availability
Rafael: I might join the WebMCP discussion
webmachinelearning/
<gb> Issue 35 WebML WG/CG F2F Agenda - TPAC 2025 (Kobe, Japan) (by anssiko)
Anssi: - Built-in AI APIs:
… Prompt API
… Writing Assistance APIs
… Translator and Language Detector APIs
… Proofreader API
… all these APIs are backed by on-device ML models bundled with the OS or the browser
… we can cover ~2-3 key issues for each Built-in AI API
… I'd propose we use `Agenda+` label to triage issues for F2F across all the CG repos
… if you don't have triage permissions, please drop a comment in the F2F issue #35 and the triage team will take care of the rest
<gb> Issue 35 WebML WG/CG F2F Agenda - TPAC 2025 (Kobe, Japan) (by anssiko)
Anssi: we also very much welcome volunteers who'd like to pick up editor responsibilities for any of these APIs
… Domenic who edited these Built-in AI APIs left them in a good shape for the new editors to continue work
… please get in touch with me if you're interested in becoming an editor
… Domenic also shared his design principles for these Buit-in AI APIs that is useful context for all group participants interested in these APIs:
Designing the Built-in AI Web APIs by Domenic Denicola
Anssi: my recommendation would be to aim to have two editors per spec to allow for efficient peer review
… if you know someone who'd be a good fit or would like to step up yourself, please let me know via email
Anssi: - Proposals for new incubations
Anssi: in the last F2F session we will review proposed new incubations
… for example, I had some out-of-band discussion with Alex and Jason about MCP-UI, and filed a proposal issue for it to explore whether and how this intersects with the web platform
WebMCP API
Repository: webmachinelearning/webmcp
Elicitation
Anssi: issue #21
<gb> Issue 21 Elicitation (by bwalderman) [Agenda+]
Anssi: at our last teleconference, we made the following resolution for this issue:
"Tool execution should be able to start/stop yielding to the user throughout its lifecycle"
Anssi: since then, Brandon shared an example for an imperative API that does yielding:
webmachinelearning/
<gb> Issue 21 Elicitation (by bwalderman) [Agenda+]
Brandon: the idea is that during MCP tool function call, the tool function can tell the browser it needs user interaction, nested function runs with user having full control, user expected to return result, click a button or anything, once the user has provided their input
… nested function can be an async promise that returns to the assistant
… follow-up discussion on concerns, Khushal brought up
… the concern was a site that is abusing the API to grab user attention similar to popups
… can browser mitigate this by disallowing these tools for such abusive sites similar to popup blockers?
Brandon: interrupting too often, blocking the entire site would be possible, challenge is sites might get away at least once if we count the times it interrupts the user
Brandon: "the site requires your input, allow once etc."
Khushal: there's nothing we can change for the API for that case, we can just throw an error the user refuses to engage, if the site is abused
… the first time this happens we ask the user to intervene, similarly to what happens with popups, state persists for blocking a site that has been misbehaving
… overall happy with the API shape, any mitigations are implementation-dependant, do not require API change
Jason: is there already a request this will happen similarly microphone access?
Brandon: I think the point was about what is the permission prompt in the browser
… there's two points where the user may need to prompt for permission, whether to allow the site to use tools, and whether to allow those tools to pause and require user input, two separate prompt
Khushal: I was hoping we could resolve this with API shape, does it make sense to surface error to the user
… falling back to the previous behavior seems like the best path
Brandon: I think it is worth letting this API throw an error, that gives legitimate sites with tools to respond, and assistant take an appropriate action, stop or take an alternative path
… important to be able to throw an error, otherwise neither the site not the agent knows it is unable to complete the task
Khushal: the assistant would know, as it is built into the browser?
Brandon: good point, I guess throwing an error allows developers to customize the behaviour
… all the browser assistant knows is that the task can't continue
… if the web developer can catch the error, s/he can implement fallback behaviour
Khushal: no strong opinion on this design point
… first time the user indicates to the browser the site is abusive is the first time the error is thrown
Brandon: browser UI could provide different buttons, is "this site is abusive, I never want to interact with it" an option
Khushal: similar to popups, never allow this site to create popups
<kush> sgtm
<brwalder> +1
<AlexN> +1
RESOLUTION: requestUserInteraction API implementation should give user an option to block abusive sites permanently but throw an error to developers so legitimate sites can implement fallback behaviour.
Interleaving interaction
Anssi: issue #20 (related to elicitation #21)
<gb> Issue 20 Interleaving user and Agent interaction with the site (by khushalsagar) [Agenda+]
<gb> Issue 21 Elicitation (by bwalderman) [Agenda+]
Anssi: Khushal notes agents doing UI actuation would generally allow only one actor, user or agent, to interact with a site
… the question is, how to interleave user and agent interaction?
… elicitation seems to address part of this problem and it looks like we don't have a concrete use case for interleaving, Khushal?
… Khushal, do you think we should rescope this issue to the option 2 where the user "takes over" in the middle of the tool exection?
… or should we close this issue?
Khushal: I'm OK closing this, this came to my mind when elicitation was discussed, came up with option 2
<kush> The group did not identify a concrete use case for informing sites when users decide to take over in the middle of a tool execution. Eliciation issue #21 considers the case where the site explicitly passing over control to the user to interact.
RESOLUTION: The group did not identify a concrete use case for informing sites when users decide to take over in the middle of a tool execution. Elicitation issue #21 considers the case where the site explicitly passing over control to the user to interact.
Prompt injection
Anssi: issue #11
<gb> Issue 11 Prompt injection (by bwalderman) [Agenda+]
Anssi: I consider this a high priority issue due to security implications
… if you're aware of security experts in this domain willing to help, please loop them in
… Brandon, thanks for opening this issue to explore mitigations to the "lethal trifecta"
… this is well documented in the Simon Willison's blog post and talk:
The lethal trifecta for AI agents
Lethal Trifecta talk at the Bay Area AI Security Meetup
Anssi: Lethal Trifecta refers to combination of 3: private data, untrusted content, and external communication
Anssi: Jason shared another great reference, Brave's blog post about the Comet browser by Perplexity:
Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet
Anssi: the same threats and risks MCP is exposed to apply to WebMCP too in broad strokes, I believe
Anssi: I expect us to track developments in the broader agentic AI ecosystem and adapt emerging mitigations to our work
… talking of mitigations and solutions:
… Alex proposed an interesting clipboard feature as a mitigation that he also proposed to the official MCP spec, Brandon +1'd this approach
Spec Proposal: Give Clients a Clipboard
<gb> Discussion 960 Spec Proposal: Give Clients a Clipboard (by MiguelsPizza)
Alex: couple of versions of the Clipboard idea, a way to mitigate large pieces of context, sensitive things such as PII
… responses can be sent to client-managed clipboard that can be read from, when read, triggers elicitation event
… user has to explicitly say you can paste this information to another site
… lethal trifecta untrusted content is not fixed by this, but provides some level of mitigation, happy to talk about this more
… MCP community is iterating on mitigation prompt injection
Khushal: is there an issue on MCP spec that discusses this?
… it sounds like the API change would probably happen in MCP first and we'd embrace it then in WebMCP
… if you have thought how this information is presented to model, there's some identifier that tells you have access to user's name, for example
… "can you pass the user's name to this another cross-origin tool"
… I'm wondering if the tool output that comes from some origin, is able to have identifiers to sent to the model
Alex: there's discussions about this on MCP Discourse and elsewhere, I will put a summary in the WebMCP issue
… the identifier, in my implementation, is a key, key-value store is just a URL, sensitive value has time to live (TTL)
… all it sees is description and some metadata like "this is social security number coming from X"
Declarative API
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect)
<gb> Pull Request 26 add explainer for the declarative api (by MiguelsPizza)
Anssi: we discussed this a month ago in our meeting:
[18 September 2025] Declarative API
Anssi: since our last review, we've received feedback via both GH issue and PR, let's discuss both, first issue feedback, then PR review comments
… in issue #22 Tom and Brandon had an exchange how this fits in with MCP service discovery crawlers
… Brandon pointed out the Capability Discovery issue #8 is related, for which we made the following resolution:
<gb> Issue 8 Should tools be a means for capability discovery? (by bokand)
Anssi: then Brandon asks:
… "should crawlers rely on a site's toolset to understand its capabilities?"
… "Or, should sites have a high-level description of their capabilities (e.g. "This is a photo editing app") in the HTML or in a known location that crawlers can access?"
webmachinelearning/
<gb> Issue 22 Declarative API Equivalent (by EisenbergEffect)
Brandon: I was relating this issue to issue #8 by David, it sounds like Google has put more thought on this, not much to add right now
Anssi: in PR #26 Brandon asked was reusing ARIA attributes instead of introducing new tool-* attributes considered?
Khushal: I think what's proposed in the issue is different, which HTML content to expose to the agent, the fact the attributes map to an imperative API is a good design
… concern in the issue was to not ship imperative only API without declarative API
Built-in AI APIs
Anssi: as the last topic, I'd like to share an update on the Built-in AI APIs, future directions, editorship transitions
… these APIs are at different level of maturity, some are shipping while some are at their explainer stage
… here's the current spec and implementation status:
… - Prompt API has a spec and explainer, ships for Extensions only in Chrome 138, Dev Preview in Edge 138
… - Writing Assistance APIs has a spec and explainer, Origin Trial in Chrome 137-142, Dev Preview in Edge 138
… - Translator and Language Detector APIs has a spec and explainer, ships in Chrome 138
… - Proofreader API has an explainer
… please double-check the implementation status from the canonical sources:
https://
https://
https://