Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Tool retrieval: wildcard or not

Abierto
  • ¿Algo no está bien?
#188 3 comentarios 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@domfarolino ya está trabajando en esto.

Desde el 27/5/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Chromium has implemented document.modelContext.getTools(), which I'm planning to spec, but we should discuss an important security implication before doing so.

As planned (and as currently implemented), getTools() resolves to a list of all tools that a Document has access to, controlled only by those that choose to register tool for the caller of getTools(). If in a frame tree, if both Evil.com and Victim.com have the tools permission, then Evil.com can "inject" tools into Victim.com's getTools() list, without Victim.com ever knowing about Evil.com or opting-in to see tools from that origin.

The onus is on Victim.com to manually check the tool's origin to see if it trusts the vendor of the tool, just like postMessage(): the onus is on the recipient of the message, to vet the sender's origin. Some of the web platform security folks we've been talking to believe it's best to force the caller of getTools() to supply a list of origins that it would like to see tools from, effectively making the resolved list the intersection of:

  • Tools that have been explicitly exposed to the getTools() caller's origin; and
  • Tools from the set of origins that the caller passes to getTools()

We were planing to add * wildcard as a supported value to the exposedTo array, so that the provider of a tool can send it to everyone. We should figure out how the proposal of locking down getTools() intersects with that. There are a few options:

  1. Same-origin default; opt-in wildcard
    • getTools() defaults to showing same-origin tools only
    • registerTool() defaults to exposing tools to same-origin, if exposedTo isn't included
    • Both support the * wildcard, so you can expose and receive tools from any origins, if you so dare to
  2. No wildcard; only explicit origin sharing/calling
    • Same defaults as above, but neither support wildcard. All tool sharing/invoking has to be via explicit origin
  3. Something in between
    • exposedTo doesn't support wildcard (this matches the spec today), but getTools() defaults to *, and the caller is responsible for vetting each tool's origin before running

(1) Is ultra usable, and supports the most use cases. (2) Is ultra secure, but requires explicit origin negotiation probably through postMessage(), and probably means JS agents/tool vendors will need to ship down static origin allowlists to approve/deny embedders and tools on the fly. This is tedious and might seriously hurt adoption, especially for third-party agents that are meant to be embedded on thousands of sites, and accept tools from thousands of origins. (3) This is a little—exposedTo is more secure that postMessage()'s targetOrigin since it doesn't allow *, but getTools() is just as secure as onmessageevent handlers, since the onus is on the tool retriever to vet the supplier of the tool. Probably this option is weird and no more secure than postMessage() today.

I personally would love to see us go with (1)—it's safe by default, but maximally useful/open when users of both sides of the tool ecosystem choose to be.

/cc @johannhof @camillelamy

Lenguaje dominante
Bikeshed
Estrellas
4.7k
Forks
328
Merge medio
2 d 15 h
PR fusionados (30 d)
16

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de webmachinelearning/webmcp

Todos los issues de webmachinelearning/webmcp

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.