<p dir="auto">I think it would be possible for Deno to support ARM as rust can be compiled for ARM architecture devices</p>
<p dir="auto">I was originally excited about the security-consciousness of deno, but I am now struggling to see the benefit.</p>
<p dir="auto">It strikes me that the security is too broad-grained in two ways:</p>
<ol dir="auto">
<li>It tries to make do with <a href="https://deno.land/manual.html#flags" rel="nofollow">± five flags</a> something that other approaches need a much more elaborate vocabulary to pull off (e.g. <a href="https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW1" rel="nofollow">Apple's sandboxing</a> or <a href="http://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-selinux.html" rel="nofollow">SELinux</a>). And with the current flags it seems there has already been discovered some uncomfortable overlap between e.g. "file" access vs. all other access under many OSes.</li>
<li>It is process-level. I guess it's handy to not trust someone else's executable as much, but honestly how much "other people's code" we use these days <em>doesn't</em> semi-legitimately need <code class="notranslate">--allow-write</code> and <code class="notranslate">--allow-net</code> access? That's usually been the point of most tools we have to use, <code class="notranslate">git</code> and <code class="notranslate">heroku</code> and <code class="notranslate">kubectl</code> and <code class="notranslate">certbot</code> not to mention <code class="notranslate">webpack</code> with <code class="notranslate">@babel/preset-env</code>…</li>
</ol>
<p dir="auto">Putting the two together… isn't it the operating system's job to privilege processes? With some googling and platform-specific shell-fu, couldn't I already prevent pretty much anything I launch from gaining net access if I cared to?</p>
<p dir="auto">What would seem a lot more useful problem to solve, if deno could, is per-import privileges. My process as a whole needs a lot of access. But the helper libraries it imports often don't. (<code class="notranslate">left-pad</code>, <code class="notranslate">event-stream</code>… the current --allow flags actually seem more appropriate at that level… my server needs everything but some parser it uses needs nothing.)</p>