Community managed software security model

+1  

A community driven, open source, low coding, distributed software model is, imo, next step. However, it inherently lacks security in a traditional sense. Here's one way to address that issue

YAML 想法

The traditional closed source software model introduces proprietary boundaries to assure code security. Unfortunately, those proprietors proved untrustworthy, as expected due to lack of transparency. The open source model solves the problem of transparency and creativity, allowing sharing and evolution of ideas. However, it introduces the problem of running untrusted code on your computer, potentially compromising personal private data. How can we address this issue? As an example, npm, node.js registry has this problem. There's been many packages containing malicious code. Granted, it's discovered over time, but is there a better model not to allow this to happen at all. The problem becomes much worse for a registry of low code software, created by non devs, by a wider community. The potential of such a system is revolutionary, but not if security issues are addressed at the very start. Here's my proposal. A system of peer review, where a pool of reviewers examines each published module. Suppose this registry exists on blockchain where each published module is traded, but not before it is approved. The reviewers are part of the economy, getting paid for their services, adding to the cost of usage. What if wait for a review is too long? There's a testnet, where you can use your own module, within the network of trusted collaborators and users. You will have access to all vetted community modules on mainnet but your module will not be available to others. You will be charged storage and usage fees but won't be able to generate any coins to compensate. Any new version of a module will be jailed to testnet till reviewed. What about quality of reviewers and their reviews? It's not perfect, as nothing ever is. However, the reviwer community is the solution. A reputation system and some entry barriers would be useful. An example is stack overflow. Simply, takes a community to help a community.



(别通知) (可选) 请,登录

您可以清理输入以禁止脚本标签和 IMG 标签以防止渗漏。问题是你不能限制分布式应用程序的 JavaScript 来撤消消毒。

如果我们信任分布式应用程序本身,我们就可以信任它呈现的字段,因为它不会尝试撤消消毒。

You can sanitise inputs to ban script tags and IMG tags to prevent exfiltration. The problem is you can't of restrict the JavaScript of the distributed app to undo the sanitisation.

If we trust the distributed app itself we can trust the fields it renders as it won't try undo the sanitisation.



    :  -- 
    : Mindey
    :  -- 
    

chronological,

我的意思是我们在前端根本不做任何沙盒,只是将分布式应用程序视为另一个网站。

分布式网络的安全性在后台运行的分布式应用程序运行器中。该应用程序决定了该应用程序可以做什么。也许需要一些控制台 UI 来批准前端正在执行的操作。

我真的很感激你的想法,但我没有跟随。问题是在浏览器上下文中运行的不受信任的脚本。所有有点识别盗窃和间谍活动都是可能的,但不小心。应用程序内核无法监管人们对网络的贡献。另一种控制机制是权限系统,但这也不是完美的。谁在分配权限,给谁?这在很大程度上是有帮助的,但它不能淘汰所有的坏演员。

I mean we don't do any sandboxing at all on the frontend and just treat the distributed app as another website.

The security to the distributed network is in the distributed app runner running in the background. That app decides what the app can do. Maybe need some console UI to approve actions that the frontend is doing.

I really appreciate your thoughts but im not following. The problem is untrusted scripts running in the browser context. All kinda identify theft and spying is possible a f not careful. The app kernel can not police what people contribute to the net. Another control mechanism is the permission system, but that's not perfect either. Who's assigning permissions and to whom? It would be helpful to large degree, but it can not weed out all bad actors.


我的意思是我们在前端根本不做任何沙盒,只是将分布式应用程序视为另一个网站。

分布式网络的安全性在后台运行的分布式应用程序运行器中。该应用程序决定了该应用程序可以做什么。也许需要一些控制台 UI 来批准前端正在执行的操作。

I mean we don't do any sandboxing at all on the frontend and just treat the distributed app as another website.

The security to the distributed network is in the distributed app runner running in the background. That app decides what the app can do. Maybe need some console UI to approve actions that the frontend is doing.


关于:dfinity.org 的注释:

当前的 Internet 被设计为允许任何协议,至少在 TCP/IP 级别之上。取所有可能协议的一个子集并构建一个节点网络,这些节点使用这些协议而不是其他协议,这是一种孤立主义。我宁愿寻找一种在协议之间进行转换的方法,这将使使用任何语言交谈的节点都能相互理解([关于格式的演变](https://book.mindey.com/metaformat/0001-metaform -哲学/0001-metaform-philosophy.html

A note on: dfinity.org :

The current Internet is designed to allow any protocols, at least above the TCP/IP level. Taking a subset of all possible protocols and building a network of nodes that talk in those protocols but not others, is a kind of isolationism. I'd rather look for a way to translate between protocols, that would enable to make nodes that talk in any language understand each others (on evolution of formats).


也许前端层很简单——程序员可以使用他们想要的任何 React 代码,浏览器进行沙盒处理。

可以由托管各种分布式应用程序的分布式服务器应用程序托管在本地主机上。不会很安全,因为该站点可以发出 HTTP 请求。

我将有一个简单的 JSON API 来与分布式网络通信并查询数据库。

您可以制定内容安全策略来禁止 HTTP 请求。

嗯。有趣的。你的意思是 localhost 会做服务器渲染并只提供 html 吗?即使 html 也不安全。需要考虑的事情。我们编写了一个 mvp,现在只是证明概念,我们有安全考虑。但我们肯定需要解决方案。就个人而言,我不认为任何沙盒方案是完全值得信赖的。除了安全之外,必须有一个审查过程,即使是为了确保模块的质量。我认为,人类需要参与的地方。让他们的工作更轻松是另一个话题,值得讨论

Perhaps the frontend layer is simply that - the programmer can use any React code they want and the browser does the sandboxing.

Could be hosted on localhost by the distributed server application which hosts the various distributed apps. Wouldn't be very secure because the site could make HTTP requests.

I would have a simple JSON API for talking to the distributed network and querying the database.

You could have a content security policy to ban HTTP requests.

Hmmm. Interesting. You mean localhost would do server rendering and serve just html? Even html is not safe. Something to consider. We coding an mvp, just prove of concept for now, wo security considerations. But we def need solutions. Personally, I don't think any of sandboxing schemes are totally trustworthy. There's gotta be a review process, even to assure quality of modules, besides security. I think, somewhere humans need to get involved. Making their job easier is another subject, worth discussing


也许你有一个 UI,你可以在其中创建一个房间,房间里的人可以随意交流。所以你不能用网站创建随机套接字并窃取数据。您也无法打开文件。只查询分布式数据库。

我认为这是我对测试网的想法,您可以在其中限制对受信任用户的访问。您的代码在经过审查之前会被监禁到测试网中。我没有看到允许 vm 安全操作 Dom 的简单且高效的方法。我想使用众所周知的技术,如反应。即使是纯html字符串也不安全,即使所有状态逻辑都分离成一个func并在vm或webworker中运行

Perhaps you have a UI where you create a room of people and the people in the room you can communicate arbitrarily with. So you can't create random sockets with websites and steal data. You can't open files either. Only query the distributed database.

I think it's my idea of a testnet, where you limit access to trusted users. Your code is jailed into testnet till it's reviewed. I don't see an easy and performant way to allow a vm to safely manipulate Dom. I'd like to use well known tech like react. Even pure html string is not safe, even if all state logic is separated into a func and is run in vm or webworker


也许前端层很简单——程序员可以使用他们想要的任何 React 代码,浏览器进行沙盒处理。

可以由托管各种分布式应用程序的分布式服务器应用程序托管在本地主机上。不会很安全,因为该站点可以发出 HTTP 请求。

我将有一个简单的 JSON API 来与分布式网络通信并查询数据库。

您可以制定内容安全策略来禁止 HTTP 请求。

Perhaps the frontend layer is simply that - the programmer can use any React code they want and the browser does the sandboxing.

Could be hosted on localhost by the distributed server application which hosts the various distributed apps. Wouldn't be very secure because the site could make HTTP requests.

I would have a simple JSON API for talking to the distributed network and querying the database.

You could have a content security policy to ban HTTP requests.


我建议看看具有类似目标的互联网计算机。

https://dfinity.org/

它有自己的语言。所以无论如何你都必须重写所有内容。

I recommend taking a look at the internet computer which has similar goals.

https://dfinity.org/

It has its own language. So you have to rewrite everything anyway.



    : Mindey
    :  -- 
    :  -- 
    

chronological,

我们可以引入一种简单的虚拟机语言,它可以执行绝大多数分布式应用程序所需的原语,以及一个简单的安全运行时,可以限制与其他机器的任意通信

问题在于视图层。任何虚拟机都无法访问浏览器 Dom。已经有一个 web worker api 可用于执行 funcs,但我们希望让用户能够编写 react 组件的脚本。我可以看到如何将 html 与状态逻辑分开,并将该逻辑囚禁到网络工作者或虚拟机。问题是,谁将学习一些奇怪的 api 来编写这些组件,以及谁将重写 npm 上可用的所有组件。

We could introduce a simple virtual machine language that can execute the primitives a vast majority of distributed apps require and a simple secure runtime that limits arbitrary communication with other machines

The problem is with view layer. No vm will have access to browser Dom. There's already a web worker api that can be used to execute funcs, but we'd like to give users ability to script react components. I can see how to separate html from state logic, and jail that logic to web worker, or a vm. The problem, who's gonna learn some weird api to write those components, and who's gonna rewrite all components available on npm.


我会在 P2P 网络中的每个节点上运行 VM/解释器。您可以通过这种方式运行不可信的代码。

仅当您选择运行它时。

也许你有一个 UI,你可以在其中创建一个房间,房间里的人可以随意交流。所以你不能用网站创建随机套接字并窃取数据。您也无法打开文件。只查询分布式数据库。

I would run the VM/interpreter on every node in the P2P network. You could run untrustworthy code this way.

Only if you choose to run it.

Perhaps you have a UI where you create a room of people and the people in the room you can communicate arbitrarily with. So you can't create random sockets with websites and steal data. You can't open files either. Only query the distributed database.


当我说虚拟机时,我指的不是重量级的虚拟机虚拟机,它是处理器指令集虚拟化。

我的意思是一个简单的 while 循环解释器,它执行字节码并根据虚拟机规范执行操作。 Python 是作为字节码解释器实现的。

我希望 V8 引擎易于导入和用作库,能够为虚拟机提供上下文以指定哪些符号是有效的。不幸的是,它与嵌入 Nodejs 一样复杂。只要您无法导入文件 API 或启动进程,普通的旧 JavaScript 或 Python 就是安全的。基本上只要您不能导入任何 API,您的代码就会被隔离。

如果您想要安全,您必须重新实现相当多的浏览器或语言堆栈,因为语言不能安全地嵌入。

When I say virtual machine I don't meant a heavyweight virtualbox virtual machine which is processor instruction set virtualization.

I mean a simple while loop interpreter that executes bytecode and performs operations according to a virtual machine specification. Python is implemented as a bytecode interpreter.

I wish V8 engine was easy to import and use as a library with the ability to provide a context to the virtual machine to specify what symbols are valid. Unfortunately it's as complicated as Nodejs is to embed. Plain old JavaScript or Python is safe as long as you cannot import file APIs or start processes. Essentially as long as you cannot import any API your code is isolated.

If you want safety you have to re implement quite a lot of the browser or language stack as languages aren't embeddable safely.



    :  -- 
    : Mindey
    :  -- 
    

chronological,

''已经有很多代码质量指标,这些代码可以简单地过滤:语言版本的支持、文档的存在、语法质量,更不用说测试覆盖率、测试管道定义、星级、协作指标、拉请求、社区活动、代码评论等,我认为,可以表明很多问题,除非有一个聪明的恶意行为者,知道这一切,并故意引入安全漏洞,这样的社区审查和审查将有用。但是,我认为,这可以通过由知名工程师更自由地主演和遵循决定来实现。也许可以引入一种特殊的徽章,只有具有一定业绩记录的社区成员才能使用,并且只有在提供评论后才能使用。

我同意。我设想的是一个低代码构建器,非开发人员可以通过浏览器使用,以低代码方式编写模块脚本。大多数将是拖放,但会有一些简单的 js 函数。稍后可以引入测试系统。问题是,低代码为更广泛的人打开了大门,有更多的坏演员。如果我们把圈子弄得太窄,我们就失去了接触广泛人群的目的。在你的钱包类型之后,我最关心的是聪明的坏演员,骗子。不幸的是,低代码系统降低了情报门槛

''There are already a lot of code quality metrics, that code can simply be filtered by: support of versions of language, presence of documentation, syntax quality, not to speak of test coverage, testing pipeline definitions, stars, collaboration metrics, pull requests, community activity, comments on code, etc., that I think, can indicate a lot of issues, unless there is an intelligent malicious actor, that knows all that, and intentionally introduces security vulnerabilities, for which such community vetting and reviews would be useful. However, I think, this could be achieved by a more discretionary starring and following decisions by the renowned engineers. Maybe a special kind of badge could be introduced, that is only usable by the community members of certain track record, and only after provided reviews.

I agree. What I envision is a low code builder available to non devs thru browser, to script modules in a low code way. Most will be drag and drop, but there will be some simple js funcs. A testing system can be introduced later. The problem is, the low code opens door for much wider range of people, with plenty more bad actors. If we make hoops too narrow, we defeat the purpose of accessing that wide range of people. I'm mostly concerned about intelligent bad actors, the cheaters, after your wallet types. A low code system lowes that intelligence threshold, unfortunately



    :  -- 
    : Mindey
    :  -- 
    

skihappy,

谢谢你。那么,虚拟机会在中央服务器上运行吗?我们正在设计一个无服务器架构,内核代码来自 cdn,bc 是提供模块作为脚本的数据库。您是否建议在客户端系统上运行虚拟机?也许。也许他们将不得不花几分钟来兑现虚拟机代码。

Thank you. So, a vm would run on a central server? We are designing a serveless architecture, with kernel code coming from cdn, bc is the database supplying modules as scripts. Do you suggest running a vm on client system? Maybe. Perhaps they would have to spend a few mins to cash vm code.



    :  -- 
    : Mindey
    :  -- 
    

skihappy,

// 经过审查的社区模块 //

已经有很多代码质量指标,这些代码可以简单地过滤:语言版本的支持、文档的存在、语法质量,更不用说测试覆盖率、测试管道定义、星级、协作指标、拉取请求,社区活动、代码评论等,我认为,可以表明很多问题,除非有一个聪明的恶意行为者,知道这一切,并故意引入安全漏洞,这样的社区审查和审查将是有用的.但是,我认为,这可以通过由知名工程师更自由地主演和遵循决定来实现。也许可以引入一种特殊的徽章,只有具有一定业绩记录的社区成员才能使用,并且只有在提供评论后才能使用。

// vetted community modules //

There are already a lot of code quality metrics, that code can simply be filtered by: support of versions of language, presence of documentation, syntax quality, not to speak of test coverage, testing pipeline definitions, stars, collaboration metrics, pull requests, community activity, comments on code, etc., that I think, can indicate a lot of issues, unless there is an intelligent malicious actor, that knows all that, and intentionally introduces security vulnerabilities, for which such community vetting and reviews would be useful. However, I think, this could be achieved by a more discretionary starring and following decisions by the renowned engineers. Maybe a special kind of badge could be introduced, that is only usable by the community members of certain track record, and only after provided reviews.


目前,无法在浏览器环境中运行用户脚本。可以将脚本囚禁到 Web Worker 中,但不能将任何操作 Dom 的内容(例如 react 组件)囚禁在其中。也许,可以找到一种聪明的方法,但它肯定会缺乏性能,并且会与节点生态系统的其余部分断开连接。没有人愿意重写 npm 模块以符合该标准。此外,永远无法保证不会找到后门来击败整个监狱计划。这就是浏览器技术现在所处的位置。也许,在某个时候会有一个原生浏览器沙箱。

Currently, there's no way to run user scripts in the browser environment. It's possible to jail scripts into web workers, but not anything that manipulates Dom, like react components. Perhaps, a clever way can be found, but it def would lack performance and would be disconnected from the rest of node ecosystem. No one will be willing to rewrite npm modules to fit that standard. Also, there's never gaurantee that a back door will not be found defeating the whole jail scheme. This is where browser tech is standing now. Perhaps, there will be a native browser sandbox at some point.


比特币通过产生一个简单的虚拟机来解决这个问题,该虚拟机可以执行有限的指令子集并且不能与其他计算机交互。以太坊收取汽油费以在此虚拟机中运行代码 - 以太坊交易的某些部分被删除或用于执行代码。

Java 虚拟机有一个字节码,它对主机的访问权限有限。任何机器访问都必须通过 API。

我们可以引入一种简单的虚拟机语言,它可以执行绝大多数分布式应用程序所需的原语,以及一个简单的安全运行时,可以限制与其他机器的任意通信。因此,您有一个内置的入站和出站防火墙以确保安全。您可以认可允许代码与哪些机器对话。它会隐藏应用程序中的套接字或 HTTP 编程。一般来说,大多数分布式应用程序需要流和分布式数据库。流用于与其他计算机交谈,数据库用于执行数据查询。

问题是有用,您需要对机器进行低级别访问,例如麦克风和扬声器接口。浏览器应该可以解决这个问题,但根据我的经验,API 很糟糕。

Bitcoin solves this problem by producing a simple virtual machine which can execute a limited subset of instructions and cannot interact with other computers. Ethereum charges gas money to run code in this virtual machine - some portion of an Ethereum transaction is removed or spent executing the code.

The Java virtual machine has a bytecode that has limited access to the host machine. Any machine access has to go through APIs.

We could introduce a simple virtual machine language that can execute the primitives a vast majority of distributed apps require and a simple secure runtime that limits arbitrary communication with other machines. So you have a built in inbound and outbound firewall for security. You could endorse which machines the code is allowed to talk to. It would hide socket or HTTP programming from the app. Generally speaking most distributed apps need streams and a distributed database. The streams are for talking to other computers and the database is for executing data queries.

The problem is to be useful you kind of need low level access to a machine such as microphone and speaker interfaces. The browser should be solving this problem but in my experience the APIs are dreadful.



    :  -- 
    : Mindey
    :  -- 
    

chronological,

语言