Community managed software security model
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
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.
現在、ブラウザ環境でユーザースクリプトを実行する方法はありません。スクリプトをWebワーカーに投獄することは可能ですが、reactコンポーネントのようにDomを操作するものは何もできません。おそらく、賢い方法を見つけることができますが、それはパフォーマンスを欠き、ノードエコシステムの残りの部分から切断されます。その標準に合うように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.
ありがとうございました。では、VMは中央サーバーで実行されますか？私たちは、cdnからのカーネルコードを使用して、サーブレスアーキテクチャを設計しています。bcは、モジュールをスクリプトとして提供するデータベースです。クライアントシステムでVMを実行することをお勧めしますか？多分。おそらく、VMコードをキャッシュするために数分を費やす必要があります。
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.
「すでに多くのコード品質メトリクスがあり、そのコードは次の方法で簡単にフィルタリングできます：言語のバージョンのサポート、ドキュメントの存在、構文品質、テストカバレッジは言うまでもなく、パイプライン定義のテスト、スター、コラボレーションメトリクス、プルリクエスト、コミュニティアクティビティ、コードへのコメントなどは、それをすべて知っていて、セキュリティの脆弱性を意図的に導入するインテリジェントな悪意のあるアクターがいない限り、多くの問題を示している可能性があります。役に立つ。しかし、これは、有名なエンジニアによるより裁量的な主演と決定に従うことによって達成できると思います。たぶん、特別な種類のバッジが導入される可能性があります。これは、特定の実績のあるコミュニティメンバーのみが使用でき、レビューが提供された後にのみ使用できます。
同意します。私が想像しているのは、ブラウザを介して開発者以外の人がローコード方式でモジュールをスクリプト化できるローコードビルダーです。ほとんどはドラッグアンドドロップですが、いくつかの単純な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
私が仮想マシンと言うとき、私はプロセッサ命令セット仮想化である重量級のvirtualbox仮想マシンを意味しませんでした。
つまり、バイトコードを実行し、仮想マシンの仕様に従って操作を実行する単純な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.
P2PネットワークのすべてのノードでVM /インタープリターを実行します。この方法で信頼できないコードを実行できます。
あなたがそれを実行することを選択した場合のみ。
おそらく、あなたは人々の部屋とあなたが任意に通信できる部屋の人々を作成するUIを持っています。したがって、Webサイトでランダムなソケットを作成してデータを盗むことはできません。ファイルを開くこともできません。分散データベースにのみクエリを実行します。
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.
大多数の分散アプリが必要とするプリミティブを実行できる単純な仮想マシン言語と、他のマシンとの任意の通信を制限する単純で安全なランタイムを導入できます。
問題はビューレイヤーにあります。 vmはブラウザのDomにアクセスできません。 funcsの実行に使用できるWebワーカーAPIはすでに存在しますが、ユーザーが反応コンポーネントをスクリプト化できるようにしたいと考えています。 htmlを状態ロジックから分離し、そのロジックをWebワーカーまたはVMにジェイルする方法を確認できます。問題は、誰がそれらのコンポーネントを作成するための奇妙な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.
おそらくフロントエンドレイヤーは単純です-プログラマーは好きなReactコードを使用でき、ブラウザーはサンドボックス化を行います。
さまざまな分散アプリをホストする分散サーバーアプリケーションによって、ローカルホストでホストできます。サイトがHTTPリクエストを行う可能性があるため、安全性は低くなります。
分散ネットワークと通信してデータベースにクエリを実行するための単純なJSONAPIがあります。
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を持っています。したがって、Webサイトでランダムなソケットを作成してデータを盗むことはできません。ファイルを開くこともできません。分散データベースにのみクエリを実行します。
信頼できるユーザーへのアクセスを制限するテストネットのアイデアだと思います。コードは、レビューされるまでtestnetに投獄されます。 vmがDomを安全に操作できるようにする簡単でパフォーマンスの高い方法がわかりません。私はreactのようなよく知られた技術を使いたいです。すべての状態ロジックがfuncに分割され、vmまたはwebworkerで実行されている場合でも、純粋なhtml文字列でさえ安全ではありません。
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リクエストを行う可能性があるため、安全性は低くなります。
分散ネットワークと通信してデータベースにクエリを実行するための単純なJSONAPIがあります。
HTTPリクエストを禁止するコンテンツセキュリティポリシーを設定できます。
うーん。面白い。 localhostがサーバーのレンダリングを行い、htmlだけを提供するということですか？ htmlでさえ安全ではありません。考慮すべきこと。 mvpをコーディングしますが、今のところ概念実証であり、セキュリティ上の考慮事項が2つあります。しかし、私たちは解決策が必要です。個人的には、サンドボックススキームのどれも完全に信頼できるとは思いません。セキュリティに加えて、モジュールの品質を保証するためにも、レビュープロセスが必要です。どこかで人間が関わる必要があると思います。彼らの仕事をより簡単にすることは、議論する価値のある別の主題です
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：
現在のインターネットは、少なくともTCP / IPレベルを超えるすべてのプロトコルを許可するように設計されています。考えられるすべてのプロトコルのサブセットを取得し、それらのプロトコルで通信するが他のプロトコルでは通信しないノードのネットワークを構築することは、一種の孤立主義です。私はむしろ、プロトコル間で翻訳する方法を探しています。これにより、任意の言語で話すノードがお互いを理解できるようになります（[フォーマットの進化について]（https://book.mindey.com/metaformat/0001-metaform -philosophy / 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).
つまり、フロントエンドではサンドボックス化をまったく行わず、分散アプリを別のWebサイトとして扱うだけです。
分散ネットワークのセキュリティは、バックグラウンドで実行されている分散アプリランナーにあります。そのアプリは、アプリが何ができるかを決定します。フロントエンドが実行しているアクションを承認するために、コンソール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.
つまり、フロントエンドではサンドボックス化をまったく行わず、分散アプリを別のWebサイトとして扱うだけです。
分散ネットワークのセキュリティは、バックグラウンドで実行されている分散アプリランナーにあります。そのアプリは、アプリが何ができるかを決定します。フロントエンドが実行しているアクションを承認するために、コンソールUIが必要になる場合があります。
私はあなたの考えに本当に感謝していますが、私はフォローしていません。問題は、ブラウザのコンテキストで実行されている信頼できないスクリプトです。すべての種類は盗難を識別し、スパイは注意しないと可能です。アプリカーネルは、人々がネットに貢献しているものを監視することはできません。もう1つの制御メカニズムは許可システムですが、それも完全ではありません。誰が誰に権限を割り当てていますか？それは大いに役立つでしょうが、それはすべての悪い俳優を取り除くことはできません。
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.