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.
Биткойн решает эту проблему, создав простую виртуальную машину, которая может выполнять ограниченный набор инструкций и не может взаимодействовать с другими компьютерами. Ethereum взимает плату за газ за запуск кода на этой виртуальной машине - некоторая часть транзакции Ethereum удаляется или тратится на выполнение кода.
Виртуальная машина 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.
В настоящее время нет возможности запускать пользовательские сценарии в среде браузера. Можно заключить в тюрьму скрипты в веб-воркеры, но не все, что манипулирует 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.
Спасибо. Итак, виртуальная машина будет работать на центральном сервере? Мы разрабатываем бесперспективную архитектуру с кодом ядра, исходящим от 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.
'' Уже существует множество метрик качества кода, этот код можно просто отфильтровать по: поддержке версий языка, наличию документации, качеству синтаксиса, не говоря уже о покрытии тестированием, определениям конвейера тестирования, звездочкам, метрикам сотрудничества, вытягиванию запросы, активность сообщества, комментарии к коду и т. д., которые, как я думаю, могут указывать на множество проблем, если только не существует разумного злоумышленника, который знает все это и намеренно вводит уязвимости безопасности, для которых такая проверка и обзоры сообщества быть полезным. Тем не менее, я думаю, этого можно было бы достичь, если бы известные инженеры более осмотрительно играли главную роль и следовали решениям. Может быть, можно было бы ввести особый вид значка, который будет использоваться только членами сообщества с определенным послужным списком и только после предоставленных обзоров.
Я согласен. Я представляю себе конструктор с низким кодом, доступный не разработчикам через браузер, для сценариев модулей с низким уровнем кода. Большинство из них будет перетаскиванием, но будут и простые 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. Обычный старый JavaScript или Python безопасен до тех пор, пока вы не можете импортировать файловые API или запускать процессы. По сути, пока вы не можете импортировать какой-либо 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. Таким образом можно запустить ненадежный код.
Только если вы решите запустить его.
Возможно, у вас есть пользовательский интерфейс, в котором вы создаете комнату из людей и людей в комнате, с которыми вы можете общаться произвольно. Таким образом, вы не можете создавать случайные сокеты с веб-сайтами и красть данные. Вы также не можете открывать файлы. Запрашивать только распределенную базу данных.
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. Уже существует api веб-воркера, который можно использовать для выполнения функций, но мы хотели бы дать пользователям возможность создавать сценарии для компонентов реагирования. Я вижу, как отделить 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.
Возможно, уровень внешнего интерфейса - это просто: программист может использовать любой код 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.
Возможно, у вас есть пользовательский интерфейс, в котором вы создаете комнату из людей и людей в комнате, с которыми вы можете общаться произвольно. Таким образом, вы не можете создавать случайные сокеты с веб-сайтами и красть данные. Вы также не можете открывать файлы. Запрашивать только распределенную базу данных.
Думаю, это моя идея тестовой сети, в которой вы ограничиваете доступ для доверенных пользователей. Ваш код помещается в тестовую сеть до тех пор, пока он не будет рассмотрен. Я не вижу простого и эффективного способа позволить виртуальной машине безопасно манипулировать Dom. Я хотел бы использовать хорошо известные технологии, такие как React. Даже чистая строка html небезопасна, даже если вся логика состояния разделена на функцию и запускается в 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:
Нынешний Интернет предназначен для использования любых протоколов, по крайней мере, выше уровня TCP / IP. Взять подмножество всех возможных протоколов и построить сеть узлов, которые общаются на этих протоколах, но не на других, - это своего рода изоляционизм. Я бы предпочел поискать способ перевода между протоколами, который позволил бы узлам, говорящим на любом языке, понимать друг друга ([об эволюции форматов] (https://book.mindey.com/metaformat/0001-metaform -философия / 0001-метаформа-философия.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).
Я имею в виду, что мы вообще не делаем никакой песочницы во внешнем интерфейсе и просто рассматриваем распределенное приложение как еще один веб-сайт.
Безопасность распределенной сети обеспечивается исполняемым распределенным приложением, работающим в фоновом режиме. Это приложение решает, что приложение может делать. Возможно, понадобится консольный интерфейс для утверждения действий, выполняемых интерфейсом.
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 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.