undefined | Better HN

0 pointsdanenania3y ago0 comments

Why is that? I may be missing something, but they're already enforcing permissions at runtime, which seems like the hard part to me. It would 'just' need to be integrated with the call stack so you know which dependency(ies) want system/network access.

0 comments

zdragnar3y ago

IIRC there are all sorts of issues around monkey-patching prototypes, shared objects between modules, etc. which would readily allow escaping any sort of module / dependency level permissions system. You'd probably be better off pitching a typescript subset language with its own compiler / interpreter rather than trying to shoehorn it into V8.

danenaniaOP3y ago

These seem like solvable problems. Prototype modifications are rare these days and should probably be restricted in the same way that system/network access is. Shared objects between modules also seem like an edge case apart from callbacks? I posted an idea on how to handle callbacks upthread a bit: https://news.ycombinator.com/item?id=31326123#31332061

zdragnar3y ago

System and network access are all done via the runtime library functions, which are easy to control.

Changing prototype access almost certainly involves modifying V8 in unpleasant ways, and I'm not sure how you would get around the overhead of deno needing to the call stack on every function call- statically analyzing when a function is operating in one context or another is certainly not a trivial problem.

j / k navigate · click thread line to collapse

0 comments

zdragnar3y ago

danenaniaOP3y ago

zdragnar3y ago

System and network access are all done via the runtime library functions, which are easy to control.

j / k navigate · click thread line to collapse