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