Protecting tools from 3P scripts in the top-level context

[yoavweiss]

There are scenarios where an iframe may have access to information that the top-level document is not privy to.
Assuming that #57 would allow that iframe to register tools, these tools could provide such information to the agent.

But #51 can allow any 3P script on the top-level to access these tools and extract that private information.

It'd be good to find a way for the tool to restrict access to the information to the browser's agent and/or to certain origins.

[domfarolino]

As discussed a couple of weeks ago, this is a tricky part of the threat model. It kind of assumes that some script on the top-level is more trusted than other script, which philosophically makes sense, but that's not really the security model of the web. All script running on your page is treated the same and you have to own it from a security perspective.

The main protection I can imagine here is not a platform primitive that lets you express what data from the iframe can get out and what data can get in—that's kind of impossible, since you can shape your data however you want. The real opportunity here I think is letting the tool implementer choose which origins can execute the tool, and further letting the tool implementation itself know which origin/agent/frame is causing the current implementation. This is modeling the same safety that postMessage() provides:

• You get to choose which origin receives the postMessage() so you don't accidentally send a message to the wrong frame
• The consumer of the message can check MessageEvent#origin to verify the sender of the message.

We probably need some safety primitives like these when it comes to invoking cross-document tools. Agreed?

[yoavweiss]

It kind of assumes that some script on the top-level is more trusted than other script

I don't think it does. In the scenario I'm thinking of, the iframe would probably want to exclude any script from the top-level.

We probably need some safety primitives like these when it comes to invoking cross-document tools. Agreed?

I agree that a postMessage() like model can probably work here, allowing the tools to know who invoked them and respond accordingly.

[domfarolino]

I don't think it does. In the scenario I'm thinking of, the iframe would probably want to exclude any script from the top-level.

I see, so in this scenario what frame is the iframe comfortable exposing the tools to? Just the built-in agent? Would it satisfy you ruse case if the iframe could spell out the origins that are allowed to use its tool?

[yoavweiss]

I see, so in this scenario what frame is the iframe comfortable exposing the tools to? Just the built-in agent? Would it satisfy you ruse case if the iframe could spell out the origins that are allowed to use its tool?

I believe so. I'm imagining tools.platform.com wanting to exclude anything on merchant.com (or publisher.com), but happy to accommodate tool calls from agent.platform.com, the browser's agent or extension-based agents.

[johannhof]

Yeah, I agree it seems like a security table stakes feature to make it impossible for embedders to call their iframes tools (bypassing the agent). In fact, I think it should be the default, exposing tools to the user via iframe should not expose them to the embedding site automatically. That matches the way that iframes are currently isolated from their embedders but usable by the user (agent).

[anssiko]

RESOLUTION: Spec a registration-time origin exposure via registerTool() exposedTo with Permission Policy.

@domfarolino to share the slides about iframe design presented on today's call. Also tag other issues relevant to this resolution.