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.



(別通知) (可選) 請,登錄

比特幣通過產生一個簡單的虛擬機來解決這個問題,該虛擬機可以執行有限的指令子集並且不能與其他計算機交互。以太坊收取汽油費以在此虛擬機中運行代碼 - 以太坊交易的某些部分被刪除或用於執行代碼。

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,

目前,無法在瀏覽器環境中運行用戶腳本。可以將腳本囚禁到 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.


// 經過審查的社區模塊 //

已經有很多代碼質量指標,這些代碼可以簡單地過濾:語言版本的支持、文檔的存在、語法質量,更不用說測試覆蓋率、測試管道定義、星級、協作指標、拉取請求,社區活動、代碼評論等,我認爲,可以表明很多問題,除非有一個聰明的惡意行爲者,知道這一切,並故意引入安全漏洞,這樣的社區審查和審查將是有用的.但是,我認爲,這可以通過由知名工程師更自由地主演和遵循決定來實現。也許可以引入一種特殊的徽章,只有具有一定業績記錄的社區成員才能使用,並且只有在提供評論後才能使用。

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


謝謝你。那麼,虛擬機會在中央服務器上運行嗎?我們正在設計一個無服務器架構,內核代碼來自 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,

''已經有很多代碼質量指標,這些代碼可以簡單地過濾:語言版本的支持、文檔的存在、語法質量,更不用說測試覆蓋率、測試管道定義、星級、協作指標、拉請求、社區活動、代碼評論等,我認爲,可以表明很多問題,除非有一個聰明的惡意行爲者,知道這一切,並故意引入安全漏洞,這樣的社區審查和審查將有用。但是,我認爲,這可以通過由知名工程師更自由地主演和遵循決定來實現。也許可以引入一種特殊的徽章,只有具有一定業績記錄的社區成員才能使用,並且只有在提供評論後才能使用。

我同意。我設想的是一個低代碼構建器,非開發人員可以通過瀏覽器使用,以低代碼方式編寫模塊腳本。大多數將是拖放,但會有一些簡單的 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,

當我說虛擬機時,我指的不是重量級的虛擬機虛擬機,它是處理器指令集虛擬化。

我的意思是一個簡單的 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,

我會在 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.


我們可以引入一種簡單的虛擬機語言,它可以執行絕大多數分佈式應用程序所需的原語,以及一個簡單的安全運行時,可以限制與其他機器的任意通信

問題在於視圖層。任何虛擬機都無法訪問瀏覽器 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.


我建議看看具有類似目標的互聯網計算機。

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,

也許前端層很簡單——程序員可以使用他們想要的任何 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.


也許你有一個 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 請求。

嗯。有趣的。你的意思是 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


關於: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).


我的意思是我們在前端根本不做任何沙盒,只是將分佈式應用程序視爲另一個網站。

分佈式網絡的安全性在後臺運行的分佈式應用程序運行器中。該應用程序決定了該應用程序可以做什麼。也許需要一些控制檯 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.


我的意思是我們在前端根本不做任何沙盒,只是將分佈式應用程序視爲另一個網站。

分佈式網絡的安全性在後臺運行的分佈式應用程序運行器中。該應用程序決定了該應用程序可以做什麼。也許需要一些控制檯 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.


您可以清理輸入以禁止腳本標籤和 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,

語言