Intent to Implement and Ship: Trusted Types fromLiteral

[Daniel Vogelheim]

Contact emails

voge...@chromium.org

Specification

https://w3c.github.io/trusted-types/dist/spec/#trusted-html

Summary

Add a function to each "Trusted Type" to create an instance from a JavaScript template literal (but not from a dynamically computed string). This makes it easy to mark literals in the JavaScript source text as "trusted". Example:

const html = TrustedHTML.fromLiteral`<p>Literal Text</p>`;

Blink component

Blink>SecurityFeature>TrustedTypes

TAG review

n/a

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal. (Gecko has not implemented Trusted Types.)

WebKit: No signal. (WebKit has not implemented Trusted Types.)

Web developers: Positive (https://github.com/w3c/trusted-types/issues/347)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No.

Debuggability

It's a new method. Its use can be readily debugged in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

TrustedTypesFromLiteral

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1271149

Estimated milestones

108

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6551852775112704

[Jun Kokatsu]

This is awesome! Thank you for working on this Daniel!

Jun

[Jakub Vrána]

From a practical standpoint, it would be better if the methods are named e.g. htmlLiteral, scriptLiteral and scriptUrlLiteral. Having the same methods in all three types makes it impossible to import just that method (or then it's not descriptive and collides if you import more). Writing TrustedScriptURL.fromLiteral`/` is quite mouthful.

Dne čtvrtek 29. září 2022 v 18:46:07 UTC+2 uživatel Jun Kokatsu napsal:

[Domenic Denicola]

You can import and rename at the same time using standard JavaScript syntax:

const htmlLiteral = TrustedHTML.fromLiteral;

htmlLiteral`...`

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/641cfa76-9c2d-4521-ad8a-1d61a272cca5n%40chromium.org.

[Rick Byers]

This seems like a pretty minor and uncontroversial extension to trusted types to me. But it also seems like a good time to just check-in on the state of discussion around TrustedTypes with other vendors.

I see Mozilla has a "neutral" status saying they're not sure about utility. Is this UseCounter accurate in saying that in Chrome >10% of page loads are on pages which have explicitly enabled the enforcement of trusted types? I don't think it needs to block this intent, but could you update the Mozilla standards position with current evidence we have on the value TrustedTypes is providing some major partners who have opted in? If it's accurate, the high usage alone seems to counter the "lack of utility" argument to me, but perhaps we can do even better now? Eg. are there any anecdotes of security issues being caught as a result? Are we aware of any cases where users were exposed to attack in browsers using other engines but protected on Chromium?

It looks like nobody ever replied to the request for position from WebKit. Maybe worth filing a request in their new tracker so we have a better record of it?

Also, can you please share the wpt.fyi link for the tests for this feature?

Thanks,

   Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_ZrvsEszkc8P0WVe%2BO_ffjQjjnBAssThM9OD1LL6ci8A%40mail.gmail.com.

[Rick Byers]

Oh, I should also add that I reviewed the TAG design review of trusted types. It sounds like TAG was only able to provide feedback on the high-level design, not API-by-API detail, so I suspect TAG wouldn't find value in spending time on this one minor addition. Others may disagree though.

Rick

[Yoav Weiss]

On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://w3c.github.io/trusted-types/dist/spec/#trusted-html

Summary

Add a function to each "Trusted Type" to create an instance from a JavaScript template literal (but not from a dynamically computed string). This makes it easy to mark literals in the JavaScript source text as "trusted". Example:

const html = TrustedHTML.fromLiteral`<p>Literal Text</p>`;

Blink component

Blink>SecurityFeature>TrustedTypes

TAG review

n/a

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal. (Gecko has not implemented Trusted Types.)

WebKit: No signal. (WebKit has not implemented Trusted Types.)

Web developers: Positive (https://github.com/w3c/trusted-types/issues/347)

Can you point out specific signals in that thread that should be counted as web developer ones?

 

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No.

Debuggability

It's a new method. Its use can be readily debugged in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

TrustedTypesFromLiteral

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1271149

Estimated milestones

108

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6551852775112704

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMW%2BtvbM8eAxv5HJC0JW192EWSX_VmE7Yugta5Z5G-nXg%40mail.gmail.com.

[Yoav Weiss]

Could you also update the explainer to also cover these new methods and how developers would use them?

[Daniel Vogelheim]

Hi Rick,

On Tue, Oct 4, 2022 at 5:40 PM Rick Byers <rby...@chromium.org> wrote:

This seems like a pretty minor and uncontroversial extension to trusted types to me. But it also seems like a good time to just check-in on the state of discussion around TrustedTypes with other vendors.

Our most recent check-ins are a March 2022 WebAppSec meeting, where Facebook, Microsoft, and Google reported about their Trusted Types deployments & result, and a mid-2021 Trusted Types "state of the union" report, also shared and discussed with the W3C WebAppSec community group. These also discuss results, e.g. the former: "[Number] of XSS [reported at Google] halved in 2020 and 2021. 0 DOM XSS in all TT applications".

I certainly think we should keep these discussions going, but I'm a bit afraid of over-doing it. Also, we don't really have new results since those meetings.

Also, can you please share the wpt.fyi link for the tests for this feature?

The change is a single CL, and I didn't want to land it before having lgtm for shipping. Thus the tests aren't in wpt.fyi yet. The tests in the CL are here (plus a few modifications to other tests.)

If it's important that the tests are in wpt.fyi for the API owners' review, I'll be happy to use a feature flag to land this default-off, wait for API owners' lgtm, and then enable it separately.

 

[Jun Kokatsu]

On Wednesday, October 5, 2022 at 2:52:59 AM UTC-7 yoav...@chromium.org wrote:

On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org

Specification

https://w3c.github.io/trusted-types/dist/spec/#trusted-html

Summary

Add a function to each "Trusted Type" to create an instance from a JavaScript template literal (but not from a dynamically computed string). This makes it easy to mark literals in the JavaScript source text as "trusted". Example:

const html = TrustedHTML.fromLiteral`<p>Literal Text</p>`;

Blink component

Blink>SecurityFeature>TrustedTypes

TAG review

n/a

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal. (Gecko has not implemented Trusted Types.)

WebKit: No signal. (WebKit has not implemented Trusted Types.)

Web developers: Positive (https://github.com/w3c/trusted-types/issues/347)

Can you point out specific signals in that thread that should be counted as web developer ones?

It's little hard to tell, but that issue was a feature request from a developer (i.e. me).

At the time, I was working in Microsoft where I worked with Bing team to deploy Trusted Types in some of their products, and that was a request that I made.

[Yoav Weiss]

Friendly ping on an explainer update :)

[Daniel Vogelheim]

Apologies this took a while, but the explainer bit has now landed here: https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals 

[Yoav Weiss]

Thanks!!

On Friday, October 21, 2022 at 11:30:22 AM UTC+2 Daniel Vogelheim wrote:

Apologies this took a while, but the explainer bit has now landed here: https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals 

I'm guessing that "const value = TrustedHTML.fromLiteral`<b>Hello there ${user_provided_name}</b>`;" will throw as well, right?

[Daniel Vogelheim]

On Tue, Oct 25, 2022 at 11:03 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks!!

On Friday, October 21, 2022 at 11:30:22 AM UTC+2 Daniel Vogelheim wrote:

Apologies this took a while, but the explainer bit has now landed here: https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals 

I'm guessing that "const value = TrustedHTML.fromLiteral`<b>Hello there ${user_provided_name}</b>`;" will throw as well, right?

Yes. (spec, §3.3 #2)

I proposed improved wording for the explainer, but kept it very brief to keep it within the spirit of an explainer.

[Daniel Vogelheim]

Update: I pushed the release target out to 109, so we'll have more time to sort this out.

[Yoav Weiss]

LGTM1

Thanks for explainer and extra explanations!!

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdeba401-3282-4ae6-a85f-689653eb4490n%40chromium.org.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9607f879-a78b-0d94-5ef2-81c0cf4ffc43%40gmail.com.