[LF3551]

Fixes #360.

Adds a mitigation under Security and Privacy Considerations → Mitigations for invisible characters in tool titles, descriptions, and schemas. Following @markafoltz's and @seunghan91's feedback, it now recommends rejecting registrations rather than silently stripping metadata.

The note covers:

• Default_Ignorable_Code_Point as the baseline for a precisely defined character set, with a shared Unicode version and explicitly defined exceptions across implementations;
• checking code points instead of UTF-16 code units, and rejecting lone surrogates in descriptions and parsed schema strings (while noting that title is already a USVString);
• recursively checking every object member name and string value in both serialized schemas, including enum, const, and default, after resolving JSON escapes and any toJSON() transformation, without rewriting the schema;
• the impact of blanket rejection on variation-selector and ZWJ emoji, flag tag sequences, and ZWNJ-dependent Persian and Indic spellings, with any exceptions defined by well-formed sequences and context;
• diagnostics identifying the offending code point or lone surrogate and its location, displayed as a visible escape;
• showing the user the same accepted text supplied to the model.

The section remains non-normative, as requested in #360. This PR does not add a rejection step to registerTool(); a normative check would need agreement on the Unicode version, exceptions, schema checks, and rejection behavior.

Validation: make lint and a full Bikeshed build with --die-on=warning --die-when=late both pass without warnings. Changes are confined to this mitigation section.

---

Preview | Diff

[markafoltz]

@jpagnucco I can't think of a downside to rejecting tool registrations with invisible characters in the title or description. WDYT about this?

[seunghan91]

+1 to rejecting at registration. From the host side it is also simpler than stripping: with stripping, the text the user reviews is no longer the text the developer wrote, and values the tool receives (enum, const, default, property names) can't be stripped without changing what the tool accepts. Rejection avoids both — the developer sees the error and fixes the string.

A few things that would make rejection consistent across implementations:

1. Define the set precisely. Default_Ignorable_Code_Point seems like the right baseline. It covers tag characters (U+E0000–E007F), zero-width characters (U+200B–200D, U+2060, U+FEFF), bidi controls (U+200E–200F, U+202A–202E, U+2066–2069) and the Hangul fillers. If each browser picks its own list, the same tool will register in one browser and fail in another.

2. Check code points, not UTF-16 code units. Tag characters are surrogate pairs, so a per-unit range check never matches them. That is exactly how they got past our filter while zero-width and bidi controls were caught. description is a DOMString, so lone surrogates should be rejected too.

3. Check the schemas, not only title and description. Strings in inputSchema (property names, descriptions, enum/const/default values) reach the model the same way.

4. Known cost. Some legitimate text will fail:

   • emoji with the variation selector U+FE0F (e.g. ❤️) or a ZWJ sequence (e.g. 👨‍👩‍👧);
   • the England, Scotland and Wales flags, which are tag sequences;
   • ZWNJ, which is needed in some Persian and Indic spellings.

   For tool metadata written by the site developer I think this is an acceptable trade. If the editors want to allow any of these, I'd suggest allowing them only inside a well-formed sequence (e.g. U+FE0F right after an emoji base) rather than as standalone code points, since even ZWJ/ZWNJ runs can carry hidden data.

A clear error message that names the offending code point and where it was found would help developers hit by (4).

[LF3551]

Thanks @markafoltz @seunghan91 — updated the note in a9d7580 to recommend rejecting registrations rather than stripping metadata. It now covers a shared Unicode character set/version, code-point checks and lone-surrogate rejection, recursive checks of both serialized schemas, emoji and language trade-offs with context-defined exceptions, and diagnostics identifying the offending character and location. The title/USVString distinction is also explicit.

I kept this non-normative as requested in #360; the registerTool() algorithm is unchanged. A normative check would still need agreement on the Unicode version, exceptions, schema checks, and rejection behavior. make lint and the full Bikeshed build both pass without warnings.