Add security and privacy questionnaire#195
Conversation
|
|
||
| > 03. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either? | ||
|
|
||
| No, the API itself does not expose PII. |
There was a problem hiding this comment.
| 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. |
|
|
||
| > 10. Do features in this specification enable new script execution/loading mechanisms? | ||
|
|
||
| No. Tool `execute` callbacks are ordinary JavaScript invoked in the registering document's existing realm. |
There was a problem hiding this comment.
| 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?
There was a problem hiding this comment.
FWIW, I'd argue in favor of "yes" here.
|
|
||
| > 19. What happens when a document that uses your feature gets disconnected? | ||
|
|
||
| A disconnected document's tools are no longer discoverable or invokable by agents. Pending tool invocations associated with the document are abandoned. |
There was a problem hiding this comment.
This is not spec'd yet, so let's make a note that this will be the case, but the spec needs to catch up. And let's clarify that "abandoned" means that:
- In-page agents: the caller's Promise will be rejected
- Built-in agents: the agent will be notified that the tool call failed.
|
|
||
| > 10. Do features in this specification enable new script execution/loading mechanisms? | ||
|
|
||
| No. Tool `execute` callbacks are ordinary JavaScript invoked in the registering document's existing realm. |
There was a problem hiding this comment.
FWIW, I'd argue in favor of "yes" here.
|
|
||
| > 12. Do features in this specification allow an origin some measure of control over a user agent's native UI? | ||
|
|
||
| No direct control. There is discussion of `requestUserInput` in [Issue #165](https://github.com/webmachinelearning/webmcp/issues/165). |
There was a problem hiding this comment.
Shouldn't it be "yes"? Even the readOnlyHint offers indirect control over the browsing agent's native UI.
|
|
||
| > 04. How do the features in your specification deal with sensitive information? | ||
|
|
||
| WebMCP is not a source of sensitive information. Tools may wrap sensitive or high-privilege operations (e.g., purchases, account changes), but that risk is not WebMCP-specific. We discuss this risk in [Tool Implementation as Attack Targets](https://webmachinelearning.github.io/webmcp/#tool-implementation-targets). |
There was a problem hiding this comment.
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.
Co-authored-by: Dominic Farolino <domfarolino@gmail.com>
Co-authored-by: Dominic Farolino <domfarolino@gmail.com>
Co-authored-by: Dominic Farolino <domfarolino@gmail.com>
Co-authored-by: Dominic Farolino <domfarolino@gmail.com>
victorhuangwq
force-pushed
the
security-and-privacy-questionnaire
branch
from
3b63206 to
4e84b15
Compare
3 participants
Addresses #193
cc: @bwalderman @johannhof @domfarolino