Intent to Experiment: Trusted Types

[Daniel Vogelheim]

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

- Explainer: https://github.com/WICG/trusted-types

- A proper spec (more formal, more complete, and more up to date) is coming shortly.

Summary

Start an Origin Trial for 'trusted types'.

'Trusted types' offer an (optional) mechanism for web sites to protect themselves against XSS (cross-site scripting) attacks. Those type of attacks stem from implementation oversights, that allow user-controlled (and therefore attacker-controlled) data to slip through into parts of the DOM where they are interpreted as JavaScript (or script-equivalent). Or, in other words, the developers forgot to sanitize user inputs in some part of their app. "Trusted types" solves this by limiting the attack surface from potentially the entire code base to a handful of "policies" that a developer can implement and install. "Trusted types" then ensure that all risk-ful parts of the DOM can only be used by data that has gone through such a developer-supplied policy. 

(The Explainer above has a more fleshed out description.)

Link to “Intent to Implement” blink-dev discussion

link

Goals for experimentation

Since DOM manipulation is these days mostly handled by frameworks (rather than being re-developed for each web app), our hope is that the "trusted type" functionality can also be utilized at the framework level, requiring little to no additional effort by app authors. If that ambition works out, this would potentially allows trusted types to be deployed across a substantial portion of the web in (comparatively) little time.

Several framework implementors have expressed interest in experimenting with this. This origin trial is meant to allow them to do so. We are specifically looking for feedback on feature completeness and deployability.

Experimental timeline

M73 - M76 (until ~June '19)

Any risks when the experiment finishes?

Minor.

(Being a security feature, the primary function of "trusted types" is to block certain functionality that's usually enabled. When "trusted types" are disabled again, everything that works with it should also work without. Conceivable issues would be if e.g. TT APIs are called unconditionally, even with the experiment disabled, since those calls would then throw exceptions.)

Ongoing technical constraints

None.

Debuggability

When "Trusted Types" blocks DOM access, it throws exceptions whose message explains that this was a trusted type thing.

We're considering to support the 'Reporting API' to also allow error monitoring at scale, but that has not been implemented yet.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

link

[Mike West]

I'm abstaining from this, since my name is on the thing, but it LGTM without my owners hat on. I'm looking forward to seeing what developers make of this approach to XSS mitigation. It's different in kind than what we've tried in the past with things like CSP, and I think it has legs. +Krzysztof Kotowicz has been doing a lot of outreach work to various libraries and developers inside and outside Google, and I think the origin trial will give us some valuable feedback about the shape of the API.

Relatedly, I've asked the TAG to reopen their review, which we closed out while we were revamping the API earlier this year: comments on https://github.com/w3ctag/design-reviews/issues/198 would be appreciated

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMOjukuf203A53Qz09daqwJYL3a4ZNKvg4TZ-K3QvuRQg%40mail.gmail.com.

[Yoav Weiss]

LGTM to experiment!

On Fri, Jan 11, 2019 at 8:31 PM Mike West <mk...@chromium.org> wrote:

I'm abstaining from this, since my name is on the thing, but it LGTM without my owners hat on. I'm looking forward to seeing what developers make of this approach to XSS mitigation. It's different in kind than what we've tried in the past with things like CSP, and I think it has legs. +Krzysztof Kotowicz has been doing a lot of outreach work to various libraries and developers inside and outside Google, and I think the origin trial will give us some valuable feedback about the shape of the API.

Relatedly, I've asked the TAG to reopen their review, which we closed out while we were revamping the API earlier this year: comments on https://github.com/w3ctag/design-reviews/issues/198 would be appreciated

Would it be possible to also use this opportunity to reach out to other vendors for their opinion? (e.g. reach out to Mozilla on their standards positions repo)

Similarly to the TAG, they may also need time to properly review. 

-mike

On Fri, Jan 11, 2019 at 1:41 PM Daniel Vogelheim <voge...@chromium.org> wrote:

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

- Explainer: https://github.com/WICG/trusted-types

- A proper spec (more formal, more complete, and more up to date) is coming shortly.

Summary

Start an Origin Trial for 'trusted types'.

'Trusted types' offer an (optional) mechanism for web sites to protect themselves against XSS (cross-site scripting) attacks. Those type of attacks stem from implementation oversights, that allow user-controlled (and therefore attacker-controlled) data to slip through into parts of the DOM where they are interpreted as JavaScript (or script-equivalent). Or, in other words, the developers forgot to sanitize user inputs in some part of their app. "Trusted types" solves this by limiting the attack surface from potentially the entire code base to a handful of "policies" that a developer can implement and install. "Trusted types" then ensure that all risk-ful parts of the DOM can only be used by data that has gone through such a developer-supplied policy. 

(The Explainer above has a more fleshed out description.)

Link to “Intent to Implement” blink-dev discussion

link

Goals for experimentation

Since DOM manipulation is these days mostly handled by frameworks (rather than being re-developed for each web app), our hope is that the "trusted type" functionality can also be utilized at the framework level, requiring little to no additional effort by app authors. If that ambition works out, this would potentially allows trusted types to be deployed across a substantial portion of the web in (comparatively) little time.

Several framework implementors have expressed interest in experimenting with this. This origin trial is meant to allow them to do so. We are specifically looking for feedback on feature completeness and deployability.

Experimental timeline

M73 - M76 (until ~June '19)

Any risks when the experiment finishes?

Minor.

(Being a security feature, the primary function of "trusted types" is to block certain functionality that's usually enabled. When "trusted types" are disabled again, everything that works with it should also work without. Conceivable issues would be if e.g. TT APIs are called unconditionally, even with the experiment disabled, since those calls would then throw exceptions.)

Can you call that out specifically in the explainer and code examples and make sure the latter integrate feature detection before using the API?

Ongoing technical constraints

None.

Debuggability

When "Trusted Types" blocks DOM access, it throws exceptions whose message explains that this was a trusted type thing.

We're considering to support the 'Reporting API' to also allow error monitoring at scale, but that has not been implemented yet.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

link

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMOjukuf203A53Qz09daqwJYL3a4ZNKvg4TZ-K3QvuRQg%40mail.gmail.com.

--
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/CAKXHy%3DfvVaqcWsFQg-9j8x4JonxJXTBnGzri74rUSdUH2tg8dg%40mail.gmail.com.

[Krzysztof Kotowicz]

On Tue, Jan 15, 2019 at 5:29 PM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM to experiment!

On Fri, Jan 11, 2019 at 8:31 PM Mike West <mk...@chromium.org> wrote:

I'm abstaining from this, since my name is on the thing, but it LGTM without my owners hat on. I'm looking forward to seeing what developers make of this approach to XSS mitigation. It's different in kind than what we've tried in the past with things like CSP, and I think it has legs. +Krzysztof Kotowicz has been doing a lot of outreach work to various libraries and developers inside and outside Google, and I think the origin trial will give us some valuable feedback about the shape of the API.

Relatedly, I've asked the TAG to reopen their review, which we closed out while we were revamping the API earlier this year: comments on https://github.com/w3ctag/design-reviews/issues/198 would be appreciated

Would it be possible to also use this opportunity to reach out to other vendors for their opinion? (e.g. reach out to Mozilla on their standards positions repo)

Similarly to the TAG, they may also need time to properly review. 

There already is an issue opened there for trusted types, the decision from late last year was 'defer': https://github.com/mozilla/standards-positions/issues/20 

--

koto@ / Krzysztof Kotowicz / Google