一般来说，运行一个别人写的脚本（或程序、软件），通常会担心它会不会向外发送本机的隐私，会不会读取我的个人文件，会不会删除我的文件……

但如果这是一个 deno 脚本（程序），就完全没有这些担心，deno 的安全性很高，很实用！

deno 默认不允许对硬盘进行读写，不允许网络访问。

只有在运行的时候明确指定权限，才有访问权限，而且，可以指定具体的域名，指定具体的文件夹目录！

简单来说，如果我运行一个 C/C++或 Go 等各种语言编写的程序，我要么相信它的来源是干净的，要么自己花大量时间精力去审查代码、自己编译，要么就要承受风险（比如它可能隐藏了勒索病毒、可能悄悄挖矿）。

但如果我运行一个 deno 程序，大多数情况下我都可以非常放心。
这是把防火墙的功能挪到程序里了，那么请问，有几个用户能这么折腾的

先用着 node，等 deno 生态圈完善了再入坑

让 deno 跑一个 subprocess,这种情况下 deno 也无能为力

chrome 浏览器内核的沙箱做得再好，还是有漏洞。
所以这个事有 deno 来做能做得有 chrome 的沙箱好吗？

这看起来很美好，但实际并不怎么样。
- 对于一个大的应用、脚本来说，你没有办法识别它要求的权限是否合理，这就像现在的安卓。
- 现在看来 `allow-run` 已经是特权了: 即便你只给一个 allow-run 然后用 Deno 启动一个子进程，在子进程中用 shell 去访问文件系统不受权限限制，也能访问网络。
- 如果你运行一个 deno 程序，大多数情况下你会安慰自己这很安全。...

这种 dssq 的事情从来就是，要不你就做得不够好，要么做的好了却没人用
不过起码 Deno 把问题提出来了
http://joeduffyblog.com/2015/11/10/objects-as-secure-capabilities

世界上有一部分人不想折腾，但同时也有一部分人注重安全和隐私，这个功能对于后者来说非常有用，实际使用起来也不麻烦。

嗯权限控制的很细，但敌不过流氓软件不给权限退出不让用

deno 这个权限管理有一个非常好的地方：可以指定具体的域名和文件夹！
比如访问外网，程序作者可以主动提供一个域名列表，使用者只要简单浏览一下这个列表就能放心了。
在访问本地文件夹方面，以后如果可以改进为指定“不可访问”的文件夹，就很方便保护系统和隐私了。

注意这个激动人心的特点：权限可以给，给的是非常具体的权限，具体到文件夹和域名。而不是一律允许联网或一律禁止联网。



不完美，至少开了个好头，后续如果 deno 发展得好，会有大厂或大牛贡献，会越来越完善的。总不能破罐子破摔的心态吧……

开容器跑不就行了，少见多怪

如果 A 程序引入了 B，C，D，E 模块，这些模块每个只需要一个权限，那么运行 A 就要同时给出 4 个权限，同时，B，C，D，E 每个模块也同时获得了额外的提权
这就是我担心的权限传染，即：既然 Deno 没有任何包管理机制，那么怎么精细管理 ECMAScript 里不存在的"权限"这一概念

模块不管权限的。
权限由执行程序的人来控制，执行 deno run 的时候用参数来设定权限。

能审查代码的项目，如果用户量够大，就不用怕，会有很多人来审查，出问题的可能性较小
当然大量公司的产品都不开源，还不得不用，这些程序才是个体需要警惕的
===============================================
个体公告号：o22Zhy8MzQYemARcftajENtfikjbhTNiqg

好像是这么回事儿

读写硬盘和访问网络是基本权利，如果这俩都没有，应用也基本没啥实际用处吧

我要哭了，我上面已经重复说了很多次…… 不仅可以赋予访问权限，而且可以精确到域名和文件夹。
比如，可以设定一个程序只能访问一个指定的 data 文件夹，同时设定它只能写入一个叫 temp 的文件夹。
有不少程序根本没必要访问网络，就可以彻底断掉它的联网权限。就算需要联网，在很多情况下域名范围都可以限定，这样也可以放心它不会连到奇怪的网址上去（比如不用担心被第三方植入偷取隐私的后门）

其实如果我要你的信息，我干嘛不用 Java go c++ C....... 来开发？
如果我不要你的信息，嗯... 为了让你放心，我用了个 deno 。
如果你爱用不用，嗯.... 我干嘛不用 Java go c++ C....... 来开发？

安全确实是 deno 的一个卖点，但离完善还有很长的路要走，且看发展吧

于是你就看到遍地都是
deno 怎么访问磁盘
deno 怎么访问网络
deno http 404

低级问题永远有人问，就算把工具做到超级简单易用，也防不住有人问低级问题。

你说这个倒是真的，最现实的一个例子就是，桌面网页版的网站不利于收集用户数据、打广告，于是现在都在把用户往 app 上赶。
这就是你说的，如果一种技术能保护用户，那我就用别的技术，把用户赶过去。

问下啊，前几天访问 deno 官网，读了篇介绍，末尾有个赞助，100 美元一件的衣服，我很少见官网上放赞助的，还是 100 美元，常见一些个人博客放些，赞助几块钱喝咖啡的。请问这是怎么个意思，如果入不敷出了，是不是后期就没人维护了

你们都搞错了吧，这个功能不是面向普通用户的，而是面向程序员的，为了防止 NPM package 里面被植入恶意代码之类（之前 NPM 有过盗取比特币的前例）的。

表面上看，deno 暂时是靠爱发电，没有工资没有收入，估计广告、赞助啥的也几乎等于零。至于背后有没有财主支持，那就不知道了。
长远来看，主要还是看能不能得到业界认可，有没有人去用。只要用的人多了，必然有人接手维护，大企业不差这个钱，只要是有热度的东西就有价值，总有企业去接手的。
如果撑一两年都没有发展，那就凉凉了，也许有人继续半死不活地维护等待复活，也许直接停滞，这种情况并不少见，很多以前曾经火过的语言、框架现在都沉寂了。

如果需要动态域名怎么办？比如请求一个白名单内的域名获取一个资源文件列表，但资源文件不确定在哪个域名下，这时候是不是白名单就没用了？

用户使用教程：
请打开 XXX 权限，XXX 权限，否则程序无法正常使用！
用户：
我叼，怎么这破程序无法正常使用！

在复杂的情况下，白名单确实没用。deno 的这个特性在很多情况下可以提高安全性，但不是一个完美、全能的方案。
瑕不掩瑜。

我是觉得权限限制会有用，但也仅限安全意识比较高的用户。
对于绝大多数用户来说，限制了网络权限，那么 --allow-net 参数就会成为标配，进而转变成在启动程序的时候，不管有没有网络需求都加上 --allow-net，甚至于 --allow-net 干啥用的都不知道，只知道不加这个参数可能会报错……
比如，对于很多程序员来说，sudo 就是各种命令的标准前缀了……都不知道 sudo 是支持详细配置权限控制的，直接默认配置就是给个 ALL……程序没起来，先不看错误提示，反手加一个 sudo 再试试，还是不行的话才将错误信息复制到 baidu 搜一下具体原因，然后可能由于 sudo 执行了一下产生了一个 root 用户所有的临时文件，导致后续所有解决问题的命令都加上了 sudo……

Deno 挺好的。启动很快，Node + TypeScript 平时用起来得搞一堆 transpile，启动慢成狗，本地开发和发布区别还很大，每次写都很麻烦。生态起来了就肯定有很多人用。
所以有事没事搬运一些 npm 包过去。既加速了生态建设，又赚了 Github 星星，何乐而不为呢？

楼上都多虑了，权限的问题，比如要网没网的时候启动 Deno 会提示。感觉跟 iOS，Android 之类 App 要权限差不多。
再说，即使用户搞不清 sudo 是干嘛的，也不应该把 sudo 这个功能删了吧……

据说他们还打算用 rust 来处理 typescript （未查证），到时还能更快。

deno 是个怪胎
很奇妙的将 go 的一些思路, rust 做扩展 typescript 做主要语言
给整在一起了

然后翻了一下，你要用的脚本 /库 /程序还没人用 deno 写。

deno 的包管理会是一个超级大坑

不让读写硬盘。。你用它作甚

https://github.com/swc-project/swc
rust 是有相关项目的，并且作者最后确实也谈了，希望 ts 的处理必须重写（ https://deno.land/v1）

希望那个词，删掉，打时脑抽了。。。

原来是真的，这个作者真的太有魄力了，到时重写后又是一个诱人的优点，typescript 算是真正成为服务器正规军的一员，希望微软能有所表示（按照最近微软对开源界的态度来看，可以乐观预测会有所支持）。

那不是挺好嘛…… Go 的 std，Rust 的底层，TypeScript 的表现力，把强项都捏在一起了。
不然想象一下 Rust 的 std，TypeScript 底层，Go 的表现力捏在一起是怎样一番景象……

不过 TSC 真的太难写了。现在 TypeScript 已经是小半个 Dependent type 语言了，现在 type operator 非常碎片化，而且每天都在加功能。主流语言除了 Scala，没有比它类型系统更复杂的了，这俩哪个更复杂还很难说……

这个确实，微软那帮人疯起来实在可怕，新特性疯狂地加，那么拼干嘛……

不看好

因为 type operator 这种东西是个潘多拉魔盒，一旦跨越了泛型，追求更高级的类型系统，就要加无数 type operator，加了一个就会发现你需要更多的 type operator，最后还是有 cover 不了的 case 。直到把 type system 变成一个真正的编程语言，或者跟本语言合体，签名和非签名代码可以互相混用。
TS 的类型系统不像普通的 Hindley-Milner，简单优雅地实现泛型，大部分情况都能推导就结束了。
首先要兼容 JS，type 已有语言用 Hindley-Miller 这种系统肯定就不行。历史包袱很多。
然后 type 一个没 type 过的语言，要 annotate 已有的库就非常困难，比如 JS 里完全就可以写出来如果入参是奇数，返回值就是 File，偶数返回值就是 Function 这些行为。所以要加 operator 尽量 cover 这些 case 。
这个趋势的终点就是语言和类型系统完全融合，成为一个完全的 dependent type 语言，效果就是能自己写一个 type safe 的 printf （ parse 第一个参数，字符串里面有几个%s%d 之类的来决定后面的参数类型，我理解主流语言还没有能做到的），或者一个 SQL 或者 GraphQL 查过去，不依赖 codegen 就能做到强类型（也不依赖 Ftype provider ）。
但是里这个距离应该还有很远，估计最后还是要有新语言或者重写来解决。不过让所有人能认识到这种需求是存在的是件好事，不要在泛型上继续内卷……就跟 Java 1.5 之前很多人认识不到泛型有用一样。
对这个话题感兴趣可以搜索一下 Lambda cube 这个概念。

权限的授权终端还是用户, 作为一个小白用户(比如我的父母)才不懂权限是什么, 只要不烦他就好了, 他们连看一下提示的想法都没有. 搞得这么麻烦实用性就差了, 说到底还是市场的选择

为啥大家老在纠结权限不会用问题，这玩意根本就不是给正常用户用的，面向的是程序员程序员！提什么父母不会用，不给权限就退出是想什么呢？？？好歹了解下这个东西是干嘛好不好。

看了入门教程，编译，自带 format 。。。有种 golang 的熟悉感

JavaScript 天下第一！ deno 天下第一！（，吹爆，高潮了

闭源怕怕求开源
开源怕怕求 deno
如果 deno 出现一个 0Day 漏洞就好玩了

1.0 版本都还没出吧，等等党永不为奴
这个权限管理是仿照安卓么，需要事先声明

权限这个事，这也算个事阿？
哪里下载的脚本，伤害不伤害本机，都随缘的
诶你别看 deno 脚本号称怎么样，好像不给权限了就没事了，这就是你运行来路不明的脚本的理由吗？哦 是
缘，妙不可言
各种来路不明的脚本，就说是 deno 写的，你就敢运行了是吧？
缘，妙不可言

swc 暂时还没法用，一些基础的转码都是错的

死在 deno 安装第一步，brew install deno 失败.....

deno 刚出来你用了多久就开始这么吹？`就完全没有这些担心，deno 的安全性很高，很实用！`，实践了吗，还是就看了个 demo 就激动睡不着了。JS 社区真能折腾，搞得人都想转后端

你怎么知道你 import 的 URL 没有被劫持呢

deno 的 import 语句是长这样子的：
import { serve } from "https://deno.land/[email&https 来防止劫持。

deno 凉了吧...

没有凉，但我的兴趣已经转移到 F