Meeting minutes
Anssi: welcome back to our telcons after the TPAC F2F
Anssi: first, I'd like to welcome our latest new participants:
… Masashi Hirano from Cybozu
… Sven Schultze, Nils-Lucas Schönfeld from Technical University of Darmstadt
… Paola Di Maio from Ronin Institute for Independent Scholarship
… Simon Wijckmans from Client side development Inc (CSide)
… Victor Huang, Emily Lauber from Microsoft
… Kasper Kulikowski, Reilly Grant, Isaac Ahouma, Johann Hofmann, Chi Yo Tsai, Chris Harrelson, Penelope McLachlan, Jingyun Liu, Daniel Rojas from Google
… Simon Farshid from assistant-ui
… Jeff Whelpley from GetHuman
… Kryspin Ziemski, Mariam H., James Garbutt, Ryuya Hasegawa, Iris Johnson as individual contributors
… to the WebML Community Group!
Anssi: Jeff Whelpley, co-founder of GetHuman, we use ML and AI for many things, Boston-based, excited to join
Anssi: Vasilii from Block, working with Anthropic on MCP and founded AAIF recently
WebMCP API
Repository: webmachinelearning/webmcp
Anssi: for WebMCP discussion today, we will follow up on TPAC 2025 topics
… in addition to that, we have one Proofreader API topic on the agenda
Communication with the TAG
Anssi: issue #35
<gb> Issue 35 Communication with the TAG (by xiaochengh)
Anssi: at TPAC 2025 we had a discussion with the TAG and resolved to continue development of WebMCP as the high-level API as per the TAG guidance and coordinate with the AI Agent Protocol CG on new protocols
https://
Anssi: no further feedback has been brought to my attention since our TPAC discussion on this matter
… any comments or updates from anyone?
Anssi: I have one related update to share
Anssi: at TPAC 2025 we heard that the TAG's "loudest concern is that MCP is not going to last"
… to help address this concern, Anthropic has decided to migrate the MCP development into a newly launched neutral forum, Agentic AI Foundation (AAIF), hosted as a Directed Fund under the Linux Foundation
… I'm working with Dom to formalize our group's coordination relationship with AAIF
… we're tracking this effort as a charter development issue
Agentic AI Foundation coordination
<gb> Issue 14 Agentic AI Foundation coordination (by anssiko)
<johannhof> Sorry what is the issue?
Vasilii: we're figuring out the intrastructure, big donations to the Agentic AI Foundation are MCP, goose, and AGENTS.md
Vasilii: I can take an action to help with the coordination
Anssi: thank you, that's great
Privacy & security considerations
Anssi: a follow up to the now closed meta-issue #45 and merged PR #55
<gb> MERGED Pull Request 55 add security and privacy considerations living document (by victorhuangwq)
<gb> CLOSED Issue 45 Privacy & security considerations for WebMCP (by victorhuangwq) [Agenda+]
https://
Anssi: Victor contributed an initial security and privacy considerations document, now landed, thank you!
… I'd like to discuss the remaining attack vectors that need to be considered to have a fuller picture of the threats
… and concretely open smaller issues for each topic similarly to issue #44 (discussed as a next topic)
<gb> Issue 44 Managing action specific permissions (by khushalsagar)
Anssi: Johan had a great breakout at TPAC, Agentic Browsing and the Web's Security Model
Anssi: have we integrated all related insights from Johann's breakout?
Johann: thank you, I appreciate the session, I haven't had time to dig into the S&P considerations yet, I do think from what I see, overall Victor did great work on these considerations
… some things specifically from my breakout, origin-boundness, how are we restricting agents to traverse origins, if no x-origin action we have an easier trust model
<Victor> No worries, I think Johann, with regards to the x-origin concern, there is one issue that I would like your thoughts on as well
<Victor> webmachinelearning/
<gb> Issue 52 Should we support cross-origin Agents across frame boundaries (by khushalsagar) [Agenda+]
<Victor> ^^ this
<Victor> haha gb got ahead of me
Johann: I will look at issue #52
<gb> Issue 52 Should we support cross-origin Agents across frame boundaries (by khushalsagar) [Agenda+]
Anssi: Victor shared additional thoughts on different attack vectors
… Prompt injection attack is the top-level consideration that was categorized into the following specific attacks:
… - Metadata / description attacks aka "tool poisoning"
… - Output injection attacks
… - Input injection attacks
webmachinelearning/
<gb> CLOSED Issue 45 Privacy & security considerations for WebMCP (by victorhuangwq) [Agenda+]
Anssi: it looks like the S+P Considerations document does not yet incorporate input injection attacks? Should we open a new issue for it?
Victor: I think for input injection, not sure if it is a concern yet, because the web sites themselves have an implementation that take some form of LLM at the other end, not sure if that is a situation where WebMCP is considered
… I opened a new PR recently to clarify this
… input injection i.e. where the input to the web tools are used for prompt injection to attack the site itself
Johann: I'd exclude this from the threat model, it could be helpful to have a spec note about this, however
<jeffwhelpley> Good for user land to be aware of it.
Jeff: agreed
Victor: I think my thought is we're 70-80% done identifying the threats, have thought of semantic hints, a possible new issue?
… x-origin agents would increase the scope of the security model significantly
… S&P considerations should not to go into hypothetical territory, wait and see how the adoption will be
<Victor> webmachinelearning/
<gb> Issue 53 Introduce semantic hints for side-effects of tools (by khushalsagar)
Johann: in the solution space, Chrome may have some mitigations on the server-side, should think how to describe that without being able to standardize on the exact model
Victor: wrt Johann's point, should we have things built into WebMCP API that provide guidance to users how to use this API
Johann: I will review everything as an action item, and will figure out possible mitigations
Managing action specific permissions
Anssi: issue #44
<gb> Issue 44 Managing action specific permissions (by khushalsagar)
Anssi: this issue is about mechanisms for specific permission for e.g. destructive actions that likely always require some type of user consent
… at TPAC 2025 we resolved that the WebMCP needs a threat model to evaluate the role of browser mediated consent for tool execution
… I see discussion on how to avoid double prompting, from both site and the agent
… also discussion on how the website controlled content showing up in a privileged UI can be used by malicious actors
James: is this more of a UX thing, agent technically writes a script and injects, similarly destructive as a tool could be
… we can do this today injecting arbitrary code today
Brandon: absolutely you can write a malicious agent that does things over CDP, attacks a site
… more of protecting users who are using regular browser, and preventing regular people who are doing hacky things with CDP
… for the vast majority of people, the browser could mediate, you can always write a CDP script to do hacky things but not many people would do that in mainstream usage
James: it is not necessarily a developer thing, using CDP, could be a community-built MCP server with a snippet of code that is not malicious, but can interact with WebMCP and could go into similar destructive actions
… concern is about that, not about developer injected thing
Johann: we built the agents to conform with the WebMCP spec, it needs to be expected in this case the agent asks for permission before taking an action
Brandon: this is a valid concern, two side to WebMCP: producer side and consumer side
… concern for the consumer side because there's always some sort of escape hatch, try to bypass the WebMCP security model, maybe the extension could avoid presenting concent checks
… browser agents care about user consents
Johann: we can put these as requirements in the spec, can say requires consent with MUSTs
Victor: my main through is, we're going to show a browser-level UI permission, based on a request from the website
… looks like a regular Permissions API, but the request can be more granular depending on how many and which tools are requested
… currently main way you can input the tool is dynamic, no way for tools to be checked
Johann: I agree with Victor we need to work on disruption aspects on the website
… I don't think we ever mandate specific UI for web specs
… should not give websites leverage points to abuse
<Victor> webmachinelearning/
<gb> Issue 44 Managing action specific permissions (by khushalsagar)
Declarative approach, new developer feedback and implementation experience
Anssi: PR #26
<gb> Pull Request 26 add explainer for the declarative api (by MiguelsPizza) [Agenda+]
Anssi: at TPAC our consensus was that reusing ARIA attribute for browsing agents would create a conflict of interest where the ARIA could be optimized for agents making the page less accessible to people using a11y tools
<vasilii> Exactly!
Anssi: to that end, after our TPAC F2F, I was exploring this space and got in touch with Sven Schultze & team from Technical University of Darmstadt who've done research in this space and invited their research team to join this group
… today, I'd like to discuss developer feedback and implementation experience gathered by Sven and the research group using a new declarative framework, VOIX, as a test vehicle
https://
Anssi: to quote the high-order bits from the paper:
… "VOIX, a web-native framework that enables websites to expose reliable, auditable, and privacy-preserving capabilities for AI agents through simple, declarative HTML elements"
… "VOIX introduces <tool> and <context> tags, allowing developers to explicitly
define available actions and relevant state, thereby creating a clear, machine-readable contract for agent behavior. "
Brandon: I commented initially that we should look at ARIA, I like how this paper makes tool and context first-class citizens
… context tag is particularly interesting
… the context tag makes it possible to give only the necessary control and is good for privacy
… interesting to see something like the VOIX model in the WebMCP proposal
Vasilii: agree ARIA is not the right thing for agentic usage, and agree with what Brandon said about VOIX
… good for privacy, good for web developer control
… ML agents should only access context field, or context field is additional information?
<johannhof> Gotta go, thanks all!
Proofreader API
Repository: webmachinelearning/proofreader-api
Support multiple labels
<gb> Pull Request 31 Support multiple labels (by QueenieZqq) [Agenda+]
<gb> Issue 30 Support Multiple Labels for Each Correction (by QueenieZqq) [Agenda+]
Reilly: Proofreader API is one of the build-in AI APIs in scope of this group being worked on by Queenie
Anssi: this API finds and corrects errors such as grammar, spelling, and punctuation given a text using a built-in model, labeling corrections as "spelling", "punctuation", "capitalization", "preposition", "missing-words", "grammar"
… this PR proposes to add support for multiple such labels per one correction
… a concrete example, correction can be both a "capitalization" and "spelling" correction
WebMCP API explainer-to-spec transition
Anssi: issue #56
<gb> Issue 56 not found
Repository: webmachinelearning/webmcp
Anssi: issue #56
<gb> Issue 56 Is this a proposal or a group of proposals? (by 43081j)
Anssi: some community participants have been asking good questions that I think could be resolved if we would transition from the WebMCP explainer stage to a Community Group spec draft stage where things are more explicitly specified and scoped
Khushal: I'm supportive of this transition to draft spec
<kush> +1
<brwalder> +1
<Victor> +1
RESOLUTION: The group will transition from the WebMCP explainer to a Community Group spec draft stage using the existing explainer, proposal and other supplementary documentation in the repo as the basis.
<anssik> s/interested to see/interested to see