Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A playground for thoughts #23

Open
WebReflection opened this issue May 16, 2019 · 2 comments
Open

A playground for thoughts #23

WebReflection opened this issue May 16, 2019 · 2 comments

Comments

@WebReflection
Copy link

WebReflection commented May 16, 2019

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.

import native from 'std:global/native';
// i.e.
const {apply} = native.Reflect;
const {toString} = native.Object;

Doing this way, which is what's possible already with the mentioned playground, it's also nicer to deal with accessors.

cont {innerHTML} = native.Element.prototype;

apply(innerHTML.set, node, ['<p>hello</p>'])

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.

@mikesamuel
Copy link

How much of of get-originals can't be done in early running user code?

@WebReflection
Copy link
Author

WebReflection commented May 16, 2019

edit I've read can be done

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants