Add security and privacy questionnaire

[victorhuangwq]

Addresses #193

cc: @bwalderman @johannhof @domfarolino

[domfarolino]

Suggested change

	No, the API itself does not expose PII.
	No, the API itself does not expose PII, but the tools that authors choose to implement _can_, depending on their nature.

[domfarolino]

Suggested change

	No. Tool `execute` callbacks are ordinary JavaScript invoked in the registering document's existing realm.
	No. Tool [`execute`](https://webmachinelearning.github.io/webmcp/#dom-modelcontexttool-execute) callbacks are ordinary JavaScript invoked in the registering document's existing realm.

If we keep this answer, I have the suggestion above. However, I think there's a chance we might want to say "Yes" to this question, since we're basically introducing a structured postMessage() v2, which allows a set of authorized origins to basically directly schedule callbacks in the tool provider's realm, which is kind of "new" on the platform. Since this is relevant to the TAG review we'll file, let me just ask @jyasskin directly: what do you think our answer should be for this question?

[bvandersloot-mozilla]

FWIW, I'd argue in favor of "yes" here.

[bvandersloot-mozilla]

FWIW, I'd argue in favor of "yes" here.

[bvandersloot-mozilla]

One question I anticipate from privacy review is what mitigations for this issue are possible for WebMCP. I agree with Dom: well said to make clear WebMCP isn't creating the problem. However, if there are any locations to tie the agent's hands a bit and make the privacy story better (even on the level of recommendations rather than requirements) that would be an improvement. Alternatively, you should make clear that nothing is actually being done to defend against that attack in the spec with something like ... but that risk is not WebMCP-specific and is therefore not defended against in the design of the API.

[victorhuangwq]

I think we can reference the https://webmachinelearning.github.io/webmcp/#mitigations section to begin with perhaps? We should also update the mitigations to include this #176, as discussed in the CG call.

Beyond that, there will just be things that will be left as recommendations for agent implementers, and thus non-normative in nature. But there should be areas where the API design can help with, and I don't want to close the doors on future mitigations by stating otherwise