Add notes regarding label usage, provided by i18n review #841
Conversation
A suggested by @xfq, add additional details about operator labels, clarifying that they are not intended to be natural language strings. And include an advisement that use of developer-provided labels is subject to spoofing, and implementations should sanitize them.
inexorabletash
force-pushed
the
i18n-label-notes
branch
from
3fe2425 to
be8515b
Compare
|
@xfq can you take a peek at the additions? I quoted your excellent suggested text directly. |
There was a problem hiding this comment.
The text in itself looks great to me. A suggestion on where to place this text:
Folks reading the Programming Model section may feel this section is too label heavy, so I suggest we place this text in https://www.w3.org/TR/webnn/#dom-mloperatoroptions-label instead.
Similarly, I'd propose to migrate the existing label related note to the same section.
(Per https://www.w3.org/TR/international-specs/#I18N_Considerations another option would be a dedicated Internationalization Considerations section but it seems inline in the body of the specification is preferred.)
Done in a3f8ab2 |
|
|
||
| Note: Implementations are encouraged to use the {{MLOperatorOptions/label}} provided by developers to enhance error messages and improve debuggability, including both synchronous errors during graph construction and for errors that occur during the asynchronous {{MLGraphBuilder/build()}} method. | ||
|
|
||
| Advisement: When displaying labels provided by developers via {{MLOperatorOptions/label}} in debugging tools, logs, or error messages, implementations should sanitize the output to prevent security risks, such as injection of malicious Unicode sequences (e.g., bidirectional control characters as described in Unicode Technical Report #36, Trojan Source attacks). For example, implementations should escape or filter control characters (e.g., U+202A to U+202E, U+2066 to U+2069) or use a safe rendering mechanism to neutralize potential spoofing. |
There was a problem hiding this comment.
A link to the relevant section of UTR#36 would be useful: https://www.unicode.org/reports/tr36/#Bidirectional_Text_Spoofing
There was a problem hiding this comment.
And maybe https://www.unicode.org/reports/tr55/
A suggested by @xfq, add additional details about operator labels, clarifying that they are not intended to be natural language strings. And include an advisement that use of developer-provided labels is subject to spoofing, and implementations should sanitize them.
Resolves #837
Preview | Diff