You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The safer-env module, planned for other reasons than shimming this proposal, could probably be used to answer already few questions.
In my case, it answered a few already:
securing the env at runtime is super expensive
lazy loading namespaces is a no-go, 'casue these could be polluted before accessing
static class constants should likely be in since the namespase is used as generic reference for everything
Beside last point that looks like it's being discussed, I'd love to have a lazy loaded version of the secured namespace.
In that case, instead of going too fancy with import strings, all we need is import native from 'std:global/native' and have that native as secured Proxy for all namespaces.
I understand it's not a goal of the proposal to have improved human UX, but at the same time going this direction would make it possible to polyfill modern browsers, either through the playground, if security is truly needed, or through a no-op Proxy that lazy offers the namespace without securing, unless the browser supports the features.
Thanks for consideration.
Best Regards.
The text was updated successfully, but these errors were encountered:
@mikesamuel pretty much all of it, since it's possible to freeze objects, and a module is resolved only once anyway. However, the fact <script type=moule> works deferred, might result into already polluted environment (i.e. via earlier blocking scripts) so that early running user code must run synchronously on top, and somehow secure the result for future consuming.
I'm running already (not linking here but ...) safer-dom, safer-promise, safer-function, or safer-crypto without issues, but the loading order is indeed a concerning point.
The safer-env module, planned for other reasons than shimming this proposal, could probably be used to answer already few questions.
In my case, it answered a few already:
Beside last point that looks like it's being discussed, I'd love to have a lazy loaded version of the secured namespace.
In that case, instead of going too fancy with import strings, all we need is
import native from 'std:global/native'
and have thatnative
as secured Proxy for all namespaces.Doing this way, which is what's possible already with the mentioned playground, it's also nicer to deal with accessors.
I understand it's not a goal of the proposal to have improved human UX, but at the same time going this direction would make it possible to polyfill modern browsers, either through the playground, if security is truly needed, or through a no-op Proxy that lazy offers the namespace without securing, unless the browser supports the features.
Thanks for consideration.
Best Regards.
The text was updated successfully, but these errors were encountered: