Sync with asset references proposal

tc39 / proposal-dynamic-import-host-adjustment

TC39 proposal that affects doesn't stringify argument to import(...) early to enable interop with WICG/trusted-types

MIT License

18 stars 3 forks source link

Sync with asset references proposal #1

Closed mikesamuel closed 4 years ago

mikesamuel commented 5 years ago

+@bmeck +@sebmarkbage

Per feedback from the last in-person meeting:

BFS: I’d like to note this has an effect on AssetReferences. They’d also require a similar change for non-string types, since they encode information on where the asset reference is formed, they're not something which can be forged or done with a string identity.

this proposal may overlap with asset references.

Off the top of my head, points of overlap include:

Both may affect the HostImportModuleDynamically to FinishDynamicImport flow.
Asset references may benefit from the changes to dynamic import to not stringify early.
If github.com/wicg/trusted-types defines a TrustedModuleSpecifier type then new AssetReference(...) should not stringify the value assigned to its [AssetSpecifier] internal slot.

bmeck commented 5 years ago

@mikesamuel can you clarify

If github.com/wicg/trusted-types defines a TrustedModuleSpecifier type then new AssetReference(...) should not stringify the value assigned to its [AssetSpecifier] internal slot

If the value in the TrustedModuleSpecifier is downgraded to not be trusted (since it becomes a string), what is the problem? Are TrustedModuleSpecifiers not expected to have a URL based location on the web?

sebmarkbage commented 5 years ago

It seems to me that the specifier shouldn't necessarily be a TrustedModuleSpecifier. Instead, it is the whole AssetReference that is trusted. The tuple would be of a trusted type.

Although I'm not sure Asset References should necessarily automatically be trusted because they're static. A policy can prevent a particular url or path to be disallowed from a particular subgraph even if the path to it is statically specified. To avoid mistakes of taking on insecure dependencies.

For this to work the Asset References need some way to attain a policy that they produce trusted values from.

bmeck commented 5 years ago

@sebmarkbage if we are talking policies, there are a lot of other things a policy might wish to embed other than just if a specifier is allowed to be resolved (final path / integrity+MIME of resource body / etc.). It might be better to just say this is all host meta-data and leave it up to policy from the host to determine the right data to include.

mikesamuel commented 5 years ago

Sorry for taking so long to respond.

If the value in the TrustedModuleSpecifier is downgraded to not be trusted (since it becomes a string), what is the problem?

That fails safe w.r.t. integrity but not availability; if a properly made trust decision is not respected, then it's harder to convince teams to adopt measures that make trust decisions explicit and auditable.

It seems to me that the specifier shouldn't necessarily be a TrustedModuleSpecifier. Instead, it is the whole AssetReference that is trusted. The tuple would be of a trusted type.

Fair enough.

mikesamuel commented 4 years ago

I think issue #3 and issue #4 cover the main points.