Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Tool retrieval: wildcard or not

Đang mở
  • Có gì không ổn?
#188 3 bình luận 1 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@domfarolino đang làm issue này rồi.

Từ ngày 27/5/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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

Ngôn ngữ chính
Bikeshed
Star
4.7k
Fork
328
Merge trung bình
2 ngày 9 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của webmachinelearning/webmcp

Tất cả issue của webmachinelearning/webmcp

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.