Intent to Ship: Trusted Types

[Daniel Vogelheim]

Contact emails: voge...@chromium.org, mk...@chromium.org

Explainer: https://github.com/w3c/webappsec-trusted-types/blob/master/explainer.md

Spec: https://w3c.github.io/webappsec-trusted-types/dist/spec/

Link to a tag review: https://github.com/w3ctag/design-reviews/issues/198

Summary

'Trusted Types' offers 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) string 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, and whose usage the browser will then enforce. "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

Intent to implement, experiment, and extend origin trial.

Link to Origin Trial feedback summary
(We have no formal summary document. Much of the feedback came from early implementors, mainly the ISE group at Google, but also others.)

The feedback from the Origin Trial & non-OT experiments falls mainly into two categories: 

- Bypasses (that is: incomplete coverage of TT)

- Deployment issues.

We treated the bypasses mostly as bugs and fixed them (along with regular bugs, of course). There is one issue left, and we'll delay shipping until that one is fixed, too.

The deployment-related feedback led to numerous changes in the API, namely:

- CSP "report-only" support,

- report-to support,

- better exception and reporting messages,

- changed error handling for "default" policies, which (now) cleanly delineates between regular and Trusted Types related errors,

- dropping of the "TrustedURL" type.

Is this feature supported on all six Blink platforms?
Yes.

Demo link
n/a.

If it helps, I can ask some of the early adopters to supply a demo. However, TT demos are exceedingly boring because - being a security feature to block cross-site scripting attacks - a TT-enabled demo site works & looks exactly like the non-TT enabled site. A working security feature is, (un)fortunately, invisible.

Debuggability

- Debugging: Trusted type violations throw exceptions (ContentSecurityPolicyViolation exceptions) and log console messages.

- Debugging at scale: Trusted Type observes CSP's report-to directive, so that a website can collect feedback from clients. In particular, a site can deploy as non-enforcing, report-only policy and collect reports; can then work down the list of problems encountered until the error reports indicate a clean deployment; and can then switch to enforcing mode.

Risks

Interoperability and Compatibility
Low risk.

Trusted Types is opt-in, meaning that developers need to explicitly enable it via a CSP header.

Also, any valid trusted type DOM assignment is also a valid non-TT assignment; it's only the invalid ones that get blocked. Consequently, it should be fairly easy to maintain apps compatible with both TT and non-TT browsers, and likewise it should be trivial to remove TT again (if that somehow becomes necessary).

During the Origin Trial, an over-eager deployment of TT led to user-observable bugs. We intend to address this with an FAQ, and/or supporting documentation on how to best deploy TT.

Edge: Current Edge builds pass most of the TT test suite in WPT. (Presumably inherited from Chromium.)

Firefox: Vague public support, plus more detailed, informal feedback. They have not yet started an implementation.
- https://github.com/mozilla/standards-positions/issues/20

- At TPAC: 

"Mozilla is evaluating it. Solves a problem we're interested in."

Safari: No signals.

W3C: The TT spec has been accepted by the W3C WebAppSec group.

Web / Framework developers: 

This is being tried out in several frameworks, e.g. Google-internal work, or public work (e.g. DOMPurify). To the best of my knowledge, none of these would have enabled TT by default yet. (Which is to be expected at this stage of development.)

(The template requests reporting of "both positive and negative" opinions. There's been near-zero negative opinions (unless one counts bug reports, and/or change requests for parts of the feature). I trust that developers uncomfortable with TT are simply ignoring it. Which - being strictly opt-in - they may continue to do post-launch.)


Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Likely CSP (Content Security Policy), and especially the reporting part of CSP.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

This seems unlikely.


Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Sort of. Utilizing the basic TT functionality looks to be rather easy.

A common feedback theme from developers was that base support for TT is easy. However, in most real-world apps there are some difficult code bits (oftentimes in legacy code or third-party dependencies) that need to be cleaned up in order to inject TT support into it as well. Ferreting out such dark corners of the code base appears to oftentimes be a majority of the work required. This is arguably both good and bad news: Good, because it is likely that such unmaintained bits of code harbour XSS potential, which this API means to inhibit. Bad, because in practice it means that TT deployment can be more work than we'd like it to be.

The main reaction to this have been deployment features like report-only and report-to support. This way, a developer can start testing a deployment in report-only, and can then over time work on the remaining issues until the stream of incoming reports is zero (or sufficiently low), and only then enable TT in enforcing mode.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Super totally yes.

- A polyfill is available here: https://github.com/w3c/webappsec-trusted-types/tree/master/dist

- We believe that libraries & frameworks will be the main deployment mechanism. There is active work to adapt several popular libraries/frameworks.

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

Yes: https://wpt.fyi/results/trusted-types

Entry on the feature dashboard:

https://www.chromestatus.com/features/5650088592408576

[Jun.K...@microsoft.com]

LGTM 0 :)

[Anne van Kesteren]

How can this ship when there are still many open issues, e.g.,
https://github.com/w3c/webappsec-trusted-types/issues/47? It's also
not entirely clear to me there is agreement across browsers that
modifying all these rather fundamental algorithms is the way to go.
That is, there have been no discussions with whatwg/dom and
whatwg/html about the rather invasive changes that I recall.

[Boris Zbarsky]

On 10/9/19 12:29 PM, Daniel Vogelheim wrote:
> *Firefox*: Vague public support, plus more detailed, informal feedback.

> They have not yet started an implementation.
> - https://github.com/mozilla/standards-positions/issues/20
> - At TPAC:
> "Mozilla is evaluating it. Solves a problem we're interested in."

> <https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-09-TPAC-minutes.md#trusted-types>

To be clear, Mozilla is interested in solving some of the problems
Trusted Types aim to solve, but last I checked our general feeling at
this time is that the specific Trusted Types proposal at hand may not be
the right solution, and has various known and unaddressed design-level
problems.

-Boris

[Joe Medley]

What version of Chrome are you trying to ship in?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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/CALG6KPP4Oe93pZgj9ux_vRNHF-1cS0mfJcQsSeJHCfr-Y-JL0Q%40mail.gmail.com.

[Daniel Vogelheim]

On Fri, Oct 11, 2019 at 8:19 PM Joe Medley <jme...@google.com> wrote:
> What version of Chrome are you trying to ship in?

Originally we were hoping for M80, provided we'd get all the
outstanding bugs fixed by that time. We're presently reconsidering,
based on the feedback in this thread. (We'll keep fixing any issues we
find, of course.)


On Thu, Oct 10, 2019 at 10:23 AM Anne van Kesteren <ann...@annevk.nl> wrote:
> How can this ship when there are still many open issues, [...]

On Thu, Oct 10, 2019 at 4:00 PM Boris Zbarsky <bzba...@mit.edu> wrote:
> To be clear, Mozilla is interested in solving some of the problems
> Trusted Types aim to solve, but last I checked our general feeling at
> this time is that the specific Trusted Types proposal at hand may not be
> the right solution, and has various known and unaddressed design-level
> problems.

The current API design has received reasonable feedback from web
developers that tried it out (e.g. during the origin trial). The API
has converged to its current shape over the two years since our
original Intent to Implement, due in large part to insightful feedback
from the web community, including folks at Mozilla and web developers
and library authors. We're interested in getting this API into the
hands of developers, and we're confident that we'll have
implementation bugs worked down to an acceptable level before shipping
it.

"Known and unaddressed design-level problems" is new feedback for us.
We're happy to pause this intent while we figure out those areas of
disagreement.

[Daniel Vogelheim]

Hi all,

I have been reminded that I left this thread on a cliffhanger. So for those following along: We've talked to folks who have raised concerns (on-list or off-list), and have identified several fairly concrete things we'll be working on before re-trying the intent-to-ship.

- DOM node manipulation and the <script> tag.

We'll implement an alternative that keeps current Trusted Types handling on the affected <script> attributes, but would store additional info on the <script> element (link) to determine whether the current script content is trusted, and then check this flag when preparing the script for execution. That way, the major DOM node manipulation APIs can remain unchanged. The trade-off - other than implementation effort - is developer ergonomics, in that this would create an error condition that isn't indicated by exceptions during regular JavaScript execution.

- Extensibility

During TT development, we deliberately reduced the scope to only cover the immediate needs of XSS protection against script execution, and dropped related (but potentially useful) things like similar protections for CSS stylesheets. There are some aspects of TT that might make it unnecessarily difficult to extend it to such uses in the future. We'll re-examine this, and will fix the problematic parts or provide some reasonable proposal for how future extensions of the API might be done. The point here is to keep the current scope, but to ensure we are not blocking future work.

- Developer support / Support by Frameworks

There are several trial-implementations of TT in public frameworks (plus in-house deployments). Here, the criticism is that merely offering a new API through a framework doesn't demonstrate the utility of that API. We'll try to be more specific about the benefits. (Generally, I'm not quite sure how much progress we can make here. Most frameworks & apps won't use a feature while it's still experimental. Hence, real-world benefit will only materialize once a feature will have shipped for a while.)


On timeline: We surely won't be done with this work within the original timeframe (M80), but I'm hopeful the overall delay will be modest. We'll update this thread when we're ready.

We'd like to thank everyone for their input.

tl;dr: intent still paused.

[Daniel Vogelheim]

Hello,

Thanks all for your patience. I would now like to pick this up again. I think we have a good understanding of the issues, and a plan to resolve them. The major changes are:

1, Improve extensibility, following the discussion here: Split the trusted types CSP directive in two, one to restrict the policies allowed, and one to activate the feature (require-trusted-types-for). The latter now enables/disables the feature, and is a CSP-idiomatic hook for potential future extensions.

2, Revise specification and implementation of the "default policy" feature, following the discussion here: This started out as a concern about the interaction of regular DOM manipulation and the <script> element, but morphed into a more general concern about how to handle the "default policy" callback.

This concern is centered around the observation that the "default policy" is an author supplied callback, which might modify the DOM while being called from within a DOM operation. This same general concept has caused problems - both bugs and interop issues - for the DOM Mutation Events, and we were encouraged to pretty please be careful of similar issues. We will address this by changing both the spec and the implementation, so that the time the callbacks are run will be clearly defined, and guarantees that the callbacks have finished before the underlying DOM operation starts.


We're presently targeting M82. (Modulo bugs or further feedback, of course, but M82 is our present best guess.)

[Yoav Weiss]

Has anything changed on the front of signals from other vendors? Do we have more concrete support (and hence, less of an interoperability risk) from Mozilla? Any word from Safari?

--

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/CALG6KPP%3DLpewQoYCCSpu-4PXRRjPTGU9MjB0-8R2g-NefdDFmQ%40mail.gmail.com.

[Daniel Vogelheim]

On Wed, Jan 22, 2020 at 9:44 AM Yoav Weiss <yo...@yoav.ws> wrote:

Has anything changed on the front of signals from other vendors? Do we have more concrete support (and hence, less of an interoperability risk) from Mozilla? Any word from Safari?

Mozilla documents their position here. As I read it, they currently fall "between worth prototyping and non-harmful". (comments Nov 18th, ff)

Also, some Moz folks have invested a good bit of time in helping us come to our conclusions. (E.g. on default policy.)

I'm unaware of any concrete statement from Safari on Trusted Types.

[Yoav Weiss]

Looking at the Mozilla thread, it seems like everyone agrees regarding the use-case, no one loves this particular solution, but there are no concrete proposals to make progress on anything else.

Given that, I think the right answer is probably to make progress on what we have and seeing if it sticks.

LGTM1

[Daniel Bratell]

We discussed this a bit during the Blink API owner meeting and I think there are still some parts that are unclear, or at least not obvious. It looks close to ready but I would like some things to be updated and clarified:

1. The TAG review is still in progress and it would be beneficial to let it complete.

2. You write that you have a fair understanding of how to resolve the remaining issues, but it's unclear to me if those solutions are complete or if there might be followup problem stemming from the implementation. 

Could you try to get consensus on those solutions, including the spec issue annevk referred to above? Alternatively if that or other remaining issues are not shipping showstoppers, let us know that it is so, and why.

/another Daniel

[Mike West]

Hey Daniel,

To address your questions in reverse order:

On Thu, Jan 30, 2020 at 9:46 PM Daniel Bratell <brat...@gmail.com> wrote:

We discussed this a bit during the Blink API owner meeting and I think there are still some parts that are unclear, or at least not obvious. It looks close to ready but I would like some things to be updated and clarified:

 

2. You write that you have a fair understanding of how to resolve the remaining issues, but it's unclear to me if those solutions are complete or if there might be followup problem stemming from the implementation. 

We've incorporated developer feedback from last year's OT, and we've talked with Mozilla quite a bit after they raised concerns on this thread a few months ago. I think the latter conversations were quite productive and helpful. I'm confident that we've dealt with the technical concerns they raised in a way that they accept. Two that stand out are those which Daniel (Vogelheim) noted upthread: we added a workable extensibility mechanism, and revamped our approach to executing a default policy. The former is specced and implemented. The latter has a PR outstanding against WebIDL. Anne suggested that the approach "makes sense". Boris more explicitly noted that he wants more buy-in before bringing it into the core specifications, but agreed that the general approach "makes sense". To be clear, I read both of these not as endorsements but as recognition that we've resolved the explicit objections noted earlier in the thread.

With the changes we've made based on the feedback described above, the current API is as complete as it needs to be to have some confidence in its ability to address the problems we'd like to mitigate. As with any new API, it may well be that we discover something unexpected as a result of implementation experience in the wild, at which point we'll need to address that feedback. At this point, though, I don't know of any issues which should prevent us from starting to obtain that implementation experience.

1. The TAG review is still in progress and it would be beneficial to let it complete.

The TAG review has been open in one form or another since 2017. The conversation stalled last August; after ~5 months without responding to our comments, they pinged the thread again two days before your post. We replied, and waited a bit before replying to y'all on this thread, but they haven't responded.

I value the TAG's opinion. At the same time, I'm not sure waiting for additional feedback is the right answer at this point. We have some feedback from developers, we've had a number of design discussions with Mozilla, and I think we've landed on something that's workable. There may well be additional information and context that the TAG could help us discover, but at some point I would prefer to ship what we have, learn from developers' usage, and iterate, rather than polishing in the absence of developer-facing experience.

As Daniel noted on the TAG thread two weeks ago, it feels unlikely that we're going to get additional feedback above and beyond the OT until this is a thing developers can rely on by default. That's also likely to unlock discussions with libraries, which are understandably reluctant to add support for an API before it ships. 

Earlier, Yoav asked:

Has anything changed on the front of signals from other vendors?

Yes, actually. In addition to the work we've done with Mozilla above, Apple weighed in briefly on Mozilla's standards positions thread yesterday. At a high level, they agree with the goal, but suggest that the API is overly complex, and claim that it wouldn't actually defend against common XSS vectors. We respectfully disagree with the latter assertion (indeed, Google's security team is quite interested in rolling this out at scale to reduce real attack surface). The former critique is harder to objectively judge. I'm certain that we could, given enough time and energy from all parties, devise a more perfect approach. At the same time, we've iterated on this quite a bit to solidify the API's current shape, both with Mozilla and developers, and we believe it solves real problems; in the eyes of this particular beholder, it's Good Enough.

Thanks!

-mike

[Boris Zbarsky]

On 2/14/20 12:42 AM, Mike West wrote:
> Boris more explicitly noted that he wants more buy-in before bringing it
> into the core specifications, but agreed that the general approach
> "makes sense

> <https://github.com/heycam/webidl/pull/841#issuecomment-586105065>". To

> be clear, I read both of these not as endorsements but as recognition
> that we've resolved the explicit objections noted earlier in the thread.

Just to be clear, my comment was purely on the mechanical level as IDL
spec editor: _if_ we posit that we want endorsement at IDL argument
conversion time, _then_ the proposed mechanism makes sense as a means of
accomplishing that goal. It's not 100% clear to me whether that
specific goal is the right thing here, fwiw, even after reading the docs
linked in the IDL pull request. Deciding on _that_ is out of the scope
of an IDL pull request, obviously.

I have not been following this specific proposal closely enough to
comment on the meat of it, and would like it to be clear that my "makes
sense" does not mean that I consider anything in particular "resolved".
Nor does it mean that I personally have any specific objections.

-Boris

[Boris Zbarsky]

On 2/14/20 1:38 AM, Boris Zbarsky wrote:
> Just to be clear, my comment was purely on the mechanical level as IDL
> spec editor: _if_ we posit that we want endorsement at IDL argument
> conversion time, _then_ the proposed mechanism makes sense as a means of
> accomplishing that goal.

And even more clearly, I said that the basic idea of doing it that way
makes sense, and explicitly said I had not read the specific steps in
the PR for sanity. Now that I have, they do not make sense, fwiw.

For what it's worth, in the future if you intend to use my feedback on a
PR as part of an intent decision, I would really appreciate it if you
told me that is the sort of feedback you are asking for, because that is
a very different thing than a general "I don't think we should merge
this, but ok, in theory something broadly like this might make sense".

Feeling played,
Boris

[Mike West]

Hey Boris,

This isn't the reaction I expected or wanted, and I apologize for misrepresenting your stance. I tried to make it clear that your words were not an endorsement; I obviously didn't go far enough with that disavowal. Likewise, I hoped it would be clear from context that this was the last issue we felt was blocking based on the feedback y'all gave in Q4. We could have made that more clear in the PR against IDL, and will do so next time.

At the same time, I hope that our engagement here and elsewhere shows that we're _really_ trying to take Mozilla's feedback into account generally, and that we're not "playing" you. The PR we're talking about here is the result of a number of productive conversations with Mozillians, and I feel like we're running in circles to some extent, with feedback from different folks leading in somewhat different directions.

How would you like us to engage with y'all on this?

-mike

[Boris Zbarsky]

On 2/14/20 3:33 AM, Mike West wrote:
> We could have made that more clear in the PR against IDL, and
> will do so next time.

Mike,

Thank you, that would help a lot.

Just to be clear, I try to very clearly separate my "IDL spec editor"
and "Mozilla representative" roles. I will likewise try to make it
clearer which hat I am wearing when, to avoid confusion.

> At the same time, I hope that our engagement here and elsewhere shows
> that we're _really_ trying to take Mozilla's feedback into account
> generally, and that we're not "playing" you.

Again, just to be clear, I do not feel that "Mozilla" was being "played"
here in any way, but "Boris" was, albeit accidentally. In particular I
ended up spending many more hours on this last night than I was planning
to, after being presented with the "oh, that comment means everything is
fine" bit, in an attempt to make sure things were clarified before too
much more time passed and ship decisions were final. If you look at the
timestamps, I ended up going to bed about 3 hours later than I was
planning to...

Maybe I could have pushed all that off to this morning. It's hard to
tell, with intents, how fast things will move.

> and I feel like we're running in circles to some extent,
> with feedback from different folks leading in somewhat different directions.

That is definitely not the intention, and I am sorry if that's how it's
ending up looking from your end.

> How would you like us to engage with y'all on this?

I think the general engagement has been fine. For the specific IDL PR,
it would have been nice if (1) it were clear that this was the final bit
before intent to ship and that therefore something more than a cursory
review is warranted and (2) if there were some slightly more concise
description of "why we chose this approach" than the very long issues
that were linked. I did read those, but the chance that I caught all
the details is pretty low... None of that would really be necessary if
I had been involved in all the trusted types stuff all along, but I
wasn't, so the context would have been helpful.

-Boris

[Yoav Weiss]

On Fri, Feb 14, 2020 at 6:25 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 2/14/20 3:33 AM, Mike West wrote:
> We could have made that more clear in the PR against IDL, and
> will do so next time.

Mike,

Thank you, that would help a lot.

Just to be clear, I try to very clearly separate my "IDL spec editor"
and "Mozilla representative" roles.  I will likewise try to make it
clearer which hat I am wearing when, to avoid confusion.

> At the same time, I hope that our engagement here and elsewhere shows
> that we're _really_ trying to take Mozilla's feedback into account
> generally, and that we're not "playing" you.

Again, just to be clear, I do not feel that "Mozilla" was being "played"
here in any way, but "Boris" was, albeit accidentally.  In particular I
ended up spending many more hours on this last night than I was planning
to, after being presented with the "oh, that comment means everything is
fine" bit, in an attempt to make sure things were clarified before too
much more time passed and ship decisions were final.  If you look at the
timestamps, I ended up going to bed about 3 hours later than I was
planning to...

Maybe I could have pushed all that off to this morning. It's hard to
tell, with intents, how fast things will move.

Just to clarify this particular point: even if this intent would have gotten 3 LGTMs in the last 10 hours, that doesn't mean that further feedback would've been ignored.

LGTMs can be made conditional on feedback being addressed, or even reversed if new evidence comes to light that indicates they should be.

So generally, things can wait till morning.

[Elliott Sprehn]

On Tue, Jan 21, 2020, 8:28 AM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Hello,

Thanks all for your patience. I would now like to pick this up again. I think we have a good understanding of the issues, and a plan to resolve them. The major changes are:

1, Improve extensibility, following the discussion here: Split the trusted types CSP directive in two, one to restrict the policies allowed, and one to activate the feature (require-trusted-types-for). The latter now enables/disables the feature, and is a CSP-idiomatic hook for potential future extensions.

2, Revise specification and implementation of the "default policy" feature, following the discussion here: This started out as a concern about the interaction of regular DOM manipulation and the <script> element, but morphed into a more general concern about how to handle the "default policy" callback.

This concern is centered around the observation that the "default policy" is an author supplied callback, which might modify the DOM while being called from within a DOM operation. This same general concept has caused problems - both bugs and interop issues - for the DOM Mutation Events, and we were encouraged to pretty please be careful of similar issues. We will address this by changing both the spec and the implementation, so that the time the callbacks are run will be clearly defined, and guarantees that the callbacks have finished before the underlying DOM operation starts.

Did the implementation require changing the ScriptForbiddenScope coverage? As someone who spent years fixing security and behavior bugs in the DOM I'd hope we can avoid future sync callbacks that are not either at CEReactions time or at microtask. Defining new timing is really hard.

--

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/CALG6KPP%3DLpewQoYCCSpu-4PXRRjPTGU9MjB0-8R2g-NefdDFmQ%40mail.gmail.com.

[Jochen Eisinger]

On Sun, Feb 16, 2020 at 6:14 AM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Jan 21, 2020, 8:28 AM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Hello,

Thanks all for your patience. I would now like to pick this up again. I think we have a good understanding of the issues, and a plan to resolve them. The major changes are:

1, Improve extensibility, following the discussion here: Split the trusted types CSP directive in two, one to restrict the policies allowed, and one to activate the feature (require-trusted-types-for). The latter now enables/disables the feature, and is a CSP-idiomatic hook for potential future extensions.

2, Revise specification and implementation of the "default policy" feature, following the discussion here: This started out as a concern about the interaction of regular DOM manipulation and the <script> element, but morphed into a more general concern about how to handle the "default policy" callback.

This concern is centered around the observation that the "default policy" is an author supplied callback, which might modify the DOM while being called from within a DOM operation. This same general concept has caused problems - both bugs and interop issues - for the DOM Mutation Events, and we were encouraged to pretty please be careful of similar issues. We will address this by changing both the spec and the implementation, so that the time the callbacks are run will be clearly defined, and guarantees that the callbacks have finished before the underlying DOM operation starts.

Did the implementation require changing the ScriptForbiddenScope coverage? As someone who spent years fixing security and behavior bugs in the DOM I'd hope we can avoid future sync callbacks that are not either at CEReactions time or at microtask. Defining new timing is really hard.

Unfortunately, the ScriptForbiddenScope implementation broke when Proxies where introduced in ECMAScript and was never fully fixed since then 

 

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

[Daniel Vogelheim]

On Sun, Feb 16, 2020 at 6:14 AM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Jan 21, 2020, 8:28 AM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

2, Revise specification and implementation of the "default policy" feature, following the discussion here: This started out as a concern about the interaction of regular DOM manipulation and the <script> element, but morphed into a more general concern about how to handle the "default policy" callback.

This concern is centered around the observation that the "default policy" is an author supplied callback, which might modify the DOM while being called from within a DOM operation. This same general concept has caused problems - both bugs and interop issues - for the DOM Mutation Events, and we were encouraged to pretty please be careful of similar issues. We will address this by changing both the spec and the implementation, so that the time the callbacks are run will be clearly defined, and guarantees that the callbacks have finished before the underlying DOM operation starts.

Did the implementation require changing the ScriptForbiddenScope coverage?

No.

The implementation stayed clear of any of these issues, by doing the checks before jumping into the actual DOM logic. (Which was fine for this particular aspect, but was still part of the overall problem because the spec actually asked for something slightly different.)

 

As someone who spent years fixing security and behavior bugs in the DOM I'd hope we can avoid future sync callbacks that are not either at CEReactions time or at microtask. Defining new timing is really hard.

Well yes. The current proposal wants to align both spec + implementation, and do so in a way that makes it easy to see that we'll be safe: The goal is to use the layering: 

    JS user code <-> bindings <-> DOM

If we can move (most of) the TT handling into the bindings and handle it effectively as a fancy argument conversion, then we have clear guidance for when & where the code is running, plus a convenient declaration mechanism.

Essentially, all TT checks would be equivalent to preceding all applicable DOM calls with an

  if (...trusted type check ..) { throw new TypeError(..) }

and then leaving the actual DOM call alone.

[Daniel Vogelheim]

Hello all,

What happened in the meantime:

The major outstanding issue is the WebIDL [StringContext=..] extended attribute: The specification discussion continues, with several proposals still on the table, and no joint commitment to any one. However, it seems they all differ in how & where exactly they are specified, but between them there don't seem to be any user-visible or script-visible behavioural differences. (At least, I'm not seeing any.)

(Which was one of the original concerns: That the spec was sufficiently vague about when Trusted Types processing would happen that conceivably several conforming implementations could exhibit different behaviour, e.g. if combined with DOM mutation observers. All current proposals would handle this outside of DOM and, for all I can see, all would cleanly solve this problem by enforcing TT processing before DOM.)

IMHO it'd be best to let the spec discussion proceed at its own pace and, given that the differences do not seem to be script-observable, proceed with the implementation.

The Chromium-side implementation is nearly done (following the current spec draft), and will be done in time for M82. (As a plus, the cleaner spec handling also translates into less code, mainly due to centralizing many call sites into the bindings layer. The complexity is arguably somewhat higher, though, in that this now involves the bindings compiler, rather than inline if-statements.)

Other things that happened:

- The W3C TAG review is progressing, here.

- We'll restrict Trusted Types to secure contexts.

  (There's been some arguments around this, in that arguably TT can be useful even in non-secure contexts. But it's been standing policy to restrict new security-ish features to secure contexts. And as it's vastly easier to expand applicability than to restrict it, we'll go with https:-only.)

- The <script> handling / "default policy" / attribute node resolution noted here still stands.

- Koto has been so kind to update the status of various outstanding spec issues.

Obviously, we'll continue to address any feedback we will receive, whether pre- or post-release. Also, we're committed to closely tracking the spec(s), so if future spec changes do require updates to the implementation after all, we intend to follow up promptly.

All in all, we feel we have addressed (and are addressing) the feedback received, and we still think it's important to get Trusted Types into the hands of developers. I'd like to ask API owner's for recommendations on how to proceed.

[Boris Zbarsky]

On 3/5/20 1:20 PM, 'Daniel Vogelheim' via blink-dev wrote:
> However, it
> seems they all differ in how & where exactly they are specified, but
> between them there don't seem to be any user-visible or script-visible
> behavioural differences. (At least, I'm not seeing any.)

Hmm. Can you summarize which proposals are still on the table at this
point in terms of Web IDL? There are definitely script-visible
differences between different proposals that I saw being discussed; I
just want to make sure we're on the same page in terms of what things
are still being considered here.

-Boris

P.S. There are also, I believe, open concerns at least from Apple on
the overall complexity of the setup, but I haven't been following that
thread closely.

[Daniel Vogelheim]

Hi,

On Fri, Mar 6, 2020 at 12:29 AM Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/5/20 1:20 PM, 'Daniel Vogelheim' via blink-dev wrote:
> However, it
> seems they all differ in how & where exactly they are specified, but
> between them there don't seem to be any user-visible or script-visible
> behavioural differences. (At least, I'm not seeing any.)

Hmm.  Can you summarize which proposals are still on the table at this
point in terms of Web IDL?  There are definitely script-visible
differences between different proposals that I saw being discussed; I
just want to make sure we're on the same page in terms of what things
are still being considered here.

I am referring to this discussion. I'm not seeing consensus there, although it seems the various positions aren't that far apart.

Options I see being discussed are: Merging spec vs "monkey patching" in TT, whether to spec an explicit union type (maybe with extended attributes) vs just a string with an extended attribute; whether [StringContext] needs to be specced in WebIDL or if it can be moved to other specs. 

I'm not seeing how this would affect script behaviour. It seems all of those would handle TT checking before DOM, and would end up doing the same argument checking/conversion. What am I missing?

P.S.  There are also, I believe, open concerns at least from Apple on
the overall complexity of the setup, but I haven't been following that
thread closely.

I think you're referring to this feedback. A proposal to address it is here. We ended up not making a change, because we didn't see the reduction in complexity that was sought for.

In the FAQ, the TrustedTypePolicyFactory is explained based on its major method, createPolicy. That indeed seems a bit daft, in that one could instead just instantiate policy objects directly. However, the TTPF supports additional functionality which we have to put somewhere. Also, the underlying implementation needs some sort of factory or repository to do e.g. duplicate name checking. So we could eliminate the factory method in favour of different syntax, but the object itself - then presumably under a different name - would still be around, and so overall complexity would be unaffected.

[Boris Zbarsky]

On 3/6/20 5:48 AM, 'Daniel Vogelheim' via blink-dev wrote:
> I am referring to this

> <https://github.com/heycam/webidl/pull/841> discussion. I'm not seeing
> consensus there

Right.

> Options I see being discussed are: Merging spec vs "monkey patching" in
> TT, whether to spec an explicit union type (maybe with extended
> attributes) vs just a string with an extended attribute; whether
> [StringContext] needs to be specced in WebIDL or if it can be moved to
> other specs.
>
> I'm not seeing how this would affect script behaviour. It seems all of
> those would handle TT checking before DOM

Yes, but would they handle it in the same order wrt validity checking on
other arguments and the side-effects of their conversions?

That is, given foo(arg1, arg2, arg3), will a TT check on arg2 happen
before processing of arg1, between processing of arg1 and arg2, or after
processing of arg3? That is one of the still-open questions, as far as
I can tell.

> I think you're referring to this

> <https://github.com/mozilla/standards-positions/issues/20#issuecomment-584793239> feedback.

That's correct.

> A proposal to address it is here

> <https://github.com/w3c/webappsec-trusted-types/issues/258>. We ended up

> not making a change, because we didn't see the reduction in complexity
> that was sought for.

Just to check, was Maciej involved in that discussion, and is he aware
of its resolution?

-Boris

[Mike West]

Hey folks!

Elsewhere, I was asked about the open GitHub issues. We've done another pass through them, and believe that https://github.com/w3c/webappsec-trusted-types/milestone/1 is the set of changes we need to make before shipping. https://github.com/w3c/webappsec-trusted-types/issues/259 is resolved (though not yet fixed in the spec), and https://github.com/w3c/webappsec-trusted-types/issues/252 is likely already taken care of in the spec, but we're waiting to wrap up the IDL discussion to verify that assertion.

https://github.com/w3c/webappsec-trusted-types/milestone/2 is a set of improvements that we're pondering for future iterations. These seem possible to change post-v1.

On Fri, Mar 6, 2020 at 10:02 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/6/20 5:48 AM, 'Daniel Vogelheim' via blink-dev wrote:
> I am referring to this
> <https://github.com/heycam/webidl/pull/841> discussion. I'm not seeing
> consensus there

Right.

> Options I see being discussed are: Merging spec vs "monkey patching" in
> TT, whether to spec an explicit union type (maybe with extended
> attributes) vs just a string with an extended attribute; whether
> [StringContext] needs to be specced in WebIDL or if it can be moved to
> other specs.
>
> I'm not seeing how this would affect script behaviour. It seems all of
> those would handle TT checking before DOM

Yes, but would they handle it in the same order wrt validity checking on
other arguments and the side-effects of their conversions?

That is, given foo(arg1, arg2, arg3), will a TT check on arg2 happen
before processing of arg1, between processing of arg1 and arg2, or after
processing of arg3?  That is one of the still-open questions, as far as
I can tell.

I agree that this kind of detail is worth hammering out, which is why I'm happy to see engagement on the WebIDL PR. It seems to me that the PR as written has a defined ordering. If I'm wrong about that, it seems quite reasonable to make changes to the PR to enforce such an ordering, and to lock it in with tests. I'm confident that's possible.

 

> I think you're referring to this
> <https://github.com/mozilla/standards-positions/issues/20#issuecomment-584793239> feedback.

That's correct.

> A proposal to address it is here
> <https://github.com/w3c/webappsec-trusted-types/issues/258>. We ended up
> not making a change, because we didn't see the reduction in complexity
> that was sought for.

Just to check, was Maciej involved in that discussion, and is he aware
of its resolution?

Maciej suggested he'd file issues against the GitHub repo a bit over three weeks ago. I pinged him about it again yesterday: he thanked me for the ping. I'll point him specifically to the conversation in case he has additional feedback.

More generally, I very much appreciate the value of working together. I'm happy to have had good conversations about this mechanism with folks at Mozilla, and we've been actively asking Apple for feedback on Trusted Types for quite some time, in various forums including in-person discussions at TPAC, WebAppSec meetings and calls (including the discussion around adopting Trusted Types as a WebAppSec deliverable), poking folks on Twitter, and TAG design review*. It would be nice to get feedback in those forums. I'm happy to see them engaging in Mozilla's standards positions discussion, I think we're responding to those comments in good faith, and we look forward to engaging with developers generally about improvements to the API as we gather deployment experience.

-mike

* The TAG review, incidentally, was closed on Thursday, with a note from David Baron suggesting that "I'm not sure that we've gone through everything in detail, but I also think we're reasonably comfortable with this approach at a high level even if we haven't dug into all of the details."

[Daniel Bratell]

LGTM2

Thanks for all the work making this ready for shipping! I agree that what remains to clarify won't have any impact on deployment and compatibility, and maybe not even implementation, and can be done in parallel with exposing the feature to the web.

/Daniel

--
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%3DfNoNy%3Dh1-yKfd8NgBra16dDGup4WTc9wBPGcPzJhJ0_w%40mail.gmail.com.

[Chris Harrelson]

LGTM3

I just ask that if there is additional actionable feedback from Maciej or others that comes in before final shipping time to the stable channel, please incorporate it and update this thread with the latest status.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/00575690-29b1-e4ba-71c3-b2981e0f6d39%40gmail.com.

[Daniel Vogelheim]

On Wed, Mar 11, 2020 at 11:43 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

I just ask that if there is additional actionable feedback from Maciej or others that comes in before final shipping time to the stable channel, please incorporate it and update this thread with the latest status.

Thanks. Will do. 

On Wed, Mar 11, 2020 at 2:20 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM2

Thanks for all the work making this ready for shipping! I agree that what remains to clarify won't have any impact on deployment and compatibility, and maybe not even implementation, and can be done in parallel with exposing the feature to the web.

Thanks. 

/Daniel

On 2020-03-07 08:33, Mike West wrote:

Hey folks!

Elsewhere, I was asked about the open GitHub issues. We've done another pass through them, and believe that https://github.com/w3c/webappsec-trusted-types/milestone/1 is the set of changes we need to make before shipping. https://github.com/w3c/webappsec-trusted-types/issues/259 is resolved (though not yet fixed in the spec), and https://github.com/w3c/webappsec-trusted-types/issues/252 is likely already taken care of in the spec, but we're waiting to wrap up the IDL discussion to verify that assertion.

https://github.com/w3c/webappsec-trusted-types/milestone/2 is a set of improvements that we're pondering for future iterations. These seem possible to change post-v1.

On Fri, Mar 6, 2020 at 10:02 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/6/20 5:48 AM, 'Daniel Vogelheim' via blink-dev wrote:
> I am referring to this
> <https://github.com/heycam/webidl/pull/841> discussion. I'm not seeing
> consensus there

Right.

> Options I see being discussed are: Merging spec vs "monkey patching" in
> TT, whether to spec an explicit union type (maybe with extended
> attributes) vs just a string with an extended attribute; whether
> [StringContext] needs to be specced in WebIDL or if it can be moved to
> other specs.
>
> I'm not seeing how this would affect script behaviour. It seems all of
> those would handle TT checking before DOM

Yes, but would they handle it in the same order wrt validity checking on
other arguments and the side-effects of their conversions?

That is, given foo(arg1, arg2, arg3), will a TT check on arg2 happen
before processing of arg1, between processing of arg1 and arg2, or after
processing of arg3?  That is one of the still-open questions, as far as
I can tell.

Thanks, this is a good point. I assume this has limited impact on Trusted Types in its current form since there are no operations with two or more [StringContext=] declarations.

WorkerGlobalScope.importScripts has a variadic final argument ([StringContext=ScriptURL] DOMString... urls). These are processed left to right. I'm not sure if this order follows from the spec. If it doesn't, an ordering certainly needs to be made explicit. (Of course we'll follow-up with our implementation if this will differ from what we have.)