Re: [w3ctag/design-reviews] Trusted Types (#198)

Thanks for the review! Let me comment on the issues raised inline below:

> URLs as policy identifiers

In general, it's just strings I agree. We were trying to make them somewhat represent the policy author (e.g. which dependency creates it), but it so far is not very practical to use URLs to mandate that. We'll update our docs to clarify that.

> Trusted as a name

So far we were not able to find a more compelling name, "Validated" seems close, but it not that precise either. Full agreement that we should definitely explain the scope of the 'trustedness' we are aiming for in the spec.

> TT exposed in `Window` only

TT policies are meant to be created in the main window of the application. I'm not sure they would work in a service worker, given that we don't want them to be Transferable (to avoid other, e.g. cross-origin windows sending us the objects). The intention here is to create TT (locally, through policies) in a Window that will later use them with the related document. Service worker does not have the access to the document, so there would be no way for it to return the TT instance back. I agree that SW are compelling in that they might be allow us to centralize the policies implementation, but I don't see how that might work with our constraints, can you explain a bit what you had in mind, @cynthia? 

> server-side TT

I see that mechanism being useful to limit access to sensitive functions in other environments. I'm not sure TT in the current form would satisfy that, given that they are written to guard DOM sinks only (for practical reasons, we opted to solve the "narrow" problem of DOM XSS first). That said, this approach should in principle work for any DOM-like emulation in nodejs.

> expose not needed

Indeed :) The idea was to provide a global registry of (presumably safe for all inputs) policy implementations to facilitate automatic refactoring of the code:

```
a.innerHTML = foo + bar
```
to 
```
a.innerHTML = TrustedTypes.getExposedPolicy('sanitize-me-global', foo + bar);
```

but that's a fair point - we already have to rely on a configuration setting for this (the policy name), so may just as well fetch the policy from a global, configurable location instead. 

> use constructor pattern instead of `createXYZ`

@travisleithead, could you clarify this? Do you mean to use the constructor pattern for creating the policies, or the Trusted Type objects from them? We do not want the constructors for the latter to be callable. 

> Feature Policy

IIUC, Feature Policy aims to limit a window, together with all child frames, regardless of their origin. TT are expected to apply for the single window only, and definitely should not be propagated cross origin.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/198#issuecomment-461554872