Re: [whatwg/webidl] Add `{{StringContext}}` extended attribute (PR #1392)

@annevk commented on this pull request.

I think this is mostly good now, but on closer inspection I think the "validate" aspect needs a bit more flushing out.

> @@ -10259,6 +10261,39 @@ that does specify [{{SecureContext}}].
     </pre>
 </div>
 
+<h4 id="StringContext" extended-attribute lt="StringContext">[StringContext]</h4>
+
+If the [{{StringContext}}] [=extended attribute=] appears on {{DOMString}} or {{USVString}}, it
+modifies how the value is converted to the IDL type, causing additional value validation to
+adhere to the context the string is used in.
+
+The [{{StringContext}}] extended attribute must [=takes an identifier|take an identifier=]. The [=identifier=]
+must be one of "<code>TrustedHTML</code>", "<code>TrustedScript</code>", and "<code>TrustedScriptURL</code>".

or?

> @@ -11056,6 +11091,21 @@ allowed.  The security check takes the following three inputs:
 
 Note: The HTML Standard defines how a security check is performed. [[!HTML]]
 
+Certain algorithms are defined to
+<dfn id="dfn-validate-the-string-in-context" export>validate the string in context</dfn> on a given
+value. This check is used to determine whether a given value
+is appropriate for its {{StringContext}}. This validation takes the following four inputs:
+
+1.  the [=platform object=] on
+    which the operation invocation or attribute access is being done,
+1.  the value to validate,
+1.  the {{StringContext}} [=identifier=], and
+1.  the [=identifier=] of the operation or attribute.
+
+The algorithm returns an ECMAScript value, or [=JavaScript/throws=] a <l spec=ecmascript>{{TypeError}}</l>.
+
+Note: The HTML Standard defines how the validation is performed. [[!HTML]]

I looked into this a bit more and this description appears insufficient.

1. It's not clear it always ends up throwing a TypeError. Doesn't this involve userland for some bits?
2. It seems this algorithm might also end up reporting violations per step 6.1 of https://w3c.github.io/trusted-types/dist/spec/#abstract-opdef-get-trusted-type-compliant-string.

I don't think "validate" is a sufficiently clear term given the implications. "Validate" makes me expect a side-effect-free-boolean-returning operation, not something that can result in network traffic (and events?).

---

Apart from the above, we'll need some test coverage to ensure that this is invoked at the correct time relative to other exceptions that can be thrown. This will be observable if this can throw non-TypeError exceptions, but even if this always throws a TypeError (and we ignore the message field) it's observable through network traffic.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1392#pullrequestreview-1976973675
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1392/review/1976973675@github.com>