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.
„Bitcoin“ išsprendžia šią problemą sukurdama paprastą virtualią mašiną, kuri gali vykdyti ribotą nurodymų pogrupį ir negali sąveikauti su kitais kompiuteriais. „Ethereum“ ima mokesčius už dujas, kad galėtų paleisti kodą šioje virtualioje mašinoje - tam tikra „Ethereum“ operacijos dalis pašalinama arba išleidžiama vykdant kodą.
„Java“ virtualioji mašina turi baitinį kodą, kuris turi ribotą prieigą prie pagrindinio kompiuterio. Bet kokia prieiga prie mašinos turi vykti per API.
Galėtume pristatyti paprastą virtualios mašinos kalbą, galinčią vykdyti primityvius dalykus, kurių reikalauja didžioji dauguma platinamų programų, ir paprastą saugų veikimo laiką, kuris riboja savavališką bendravimą su kitomis mašinomis. Taigi saugumo sumetimais turite įmontuotą įeinančią ir išeinančią užkardą. Galite patvirtinti, su kuriomis mašinomis leidžiama kalbėtis su kodu. Tai slėptų lizdą arba HTTP programavimą iš programos. Apskritai daugumai platinamų programų reikia srautų ir paskirstytos duomenų bazės. Srautai skirti kalbėtis su kitais kompiuteriais, o duomenų bazė - duomenų užklausoms vykdyti.
Problema yra naudinga, nes jums reikia žemo lygio prieigos prie mašinos, tokios kaip mikrofonas ir garsiakalbių sąsajos. Naršyklė turėtų išspręsti šią problemą, tačiau mano patirtis rodo, kad API yra siaubingos.
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.
Šiuo metu nėra galimybės paleisti vartotojo scenarijų naršyklės aplinkoje. Galima įkalinti scenarijus žiniatinklio darbuotojams, bet ne viską, kas manipuliuoja „Dom“, pavyzdžiui, reagavimo komponentus. Galbūt galima rasti protingą būdą, tačiau tam trūktų našumo ir jis būtų atjungtas nuo likusios mazgo ekosistemos. Niekas nenorės perrašyti npm modulių, kad atitiktų tą standartą. Be to, niekada negarantuojate, kad nebus rasta galinių durų, įveikiančių visą kalėjimo schemą. Čia dabar yra naršyklės technologija. Galbūt tam tikru momentu atsiras vietinė naršyklės smėlio dėžė.
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.
// patikrinti bendruomenės moduliai //
Jau yra daug kodo kokybės metrikos, kurią galima tiesiog filtruoti: kalbos versijų palaikymas, dokumentacijos buvimas, sintaksės kokybė, jau nekalbant apie bandymų aprėptį, bandymo proceso apibrėžimai, žvaigždutės, bendradarbiavimo metrika, traukimo užklausos, bendruomenės veikla, komentarai apie kodą ir pan., kurie, mano manymu, gali parodyti daugybę problemų, nebent yra protingas kenkėjiškas veikėjas, kuris visa tai žino ir sąmoningai pristato saugumo pažeidimus, kuriems toks bendruomenės patikrinimas ir peržiūros būtų naudingi . Tačiau manau, kad tai būtų galima pasiekti pasirinkus žymesnių inžinierių vaidmenis ir vadovaujantis jų sprendimais. Galbūt būtų galima įvesti specialų ženklelį, kurį gali naudoti tik tam tikros patirties bendruomenės nariai ir tik po pateiktų atsiliepimų.
// 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.
Ačiū. Taigi, vm veiktų centriniame serveryje? Mes projektuojame tarnaujančią architektūrą, kurios branduolio kodas gaunamas iš cdn, bc yra duomenų bazė, tiekianti modulius kaip scenarijus. Ar siūlote paleisti vm kliento sistemoje? Gal būt. Galbūt jiems tektų praleisti kelias minutes, kad išgrynintų vm kodą.
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.
'' Jau yra daug kodo kokybės metrikos, kurią galima tiesiog filtruoti: kalbos versijų palaikymas, dokumentacijos buvimas, sintaksės kokybė, jau nekalbant apie bandymų aprėptį, bandymo proceso apibrėžimai, žvaigždės, bendradarbiavimo metrika, traukimas prašymai, bendruomenės veikla, kodo komentarai ir kt., kurie, mano manymu, gali parodyti daugybę problemų, nebent yra protingas kenkėjiškas veikėjas, kuris visa tai žino ir sąmoningai pristato saugumo pažeidimus, dėl kurių toks bendruomenės patikrinimas ir peržiūros būti naudingas. Tačiau manau, kad tai būtų galima pasiekti pasirinkus žymesnių inžinierių vaidmenis ir vadovaujantis jų sprendimais. Galbūt būtų galima įvesti specialų ženklelį, kurį gali naudoti tik tam tikros patirties bendruomenės nariai ir tik po pateiktų atsiliepimų.
Aš sutinku. Aš įsivaizduoju mažo kodo kūrimo priemonę, prieinamą ne kūrėjams per naršyklę, scenarijų moduliams žemo kodo būdu. Dauguma bus vilkti ir numesti, tačiau bus keletas paprastų „js“ funkcijų. Bandymų sistema gali būti įdiegta vėliau. Problema ta, kad žemas kodas atveria duris daug platesniam žmonių ratui ir turi daug daugiau blogų aktorių. Jei ratus padarysime per siaurus, mes pralaimėsime tikslą pasiekti tą platų žmonių ratą. Man labiausiai rūpi protingi blogi aktoriai, apgavikai, jūsų piniginės tipai. Deja, žemo kodo sistema sumažina tą intelekto slenkstį
''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
Kai sakau virtuali mašina, neturėjau omenyje sunkiosios virtualiosios virtualios mašinos, kuri yra procesoriaus instrukcijų rinkinio virtualizacija.
Turiu omenyje paprastą ciklo interpretatorių, kuris vykdo baitinį kodą ir atlieka operacijas pagal virtualios mašinos specifikaciją. „Python“ įdiegtas kaip baitų kodų vertėjas.
Norėčiau, kad V8 variklį būtų lengva importuoti ir naudoti kaip biblioteką, turintį galimybę pateikti virtualiosios mašinos kontekstą, kad būtų galima nurodyti, kokie simboliai galioja. Deja, tai taip sudėtinga, kaip įterpti „Nodejs“. Paprastas senas „JavaScript“ arba „Python“ yra saugus, kol negalite importuoti failų API arba pradėti procesų. Iš esmės, kol negalite importuoti jokios API, jūsų kodas yra izoliuotas.
Jei norite saugumo, turite iš naujo įdiegti daug naršyklės ar kalbų paketo, nes kalbos nėra saugiai įterpiamos.
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.
Aš paleisčiau VM/vertėją kiekviename P2P tinklo mazge. Tokiu būdu galite paleisti nepatikimą kodą.
Tik jei pasirinksite jį paleisti.
Galbūt turite vartotojo sąsają, kurioje sukuriate žmonių kambarį ir kambario žmones, su kuriais galite savavališkai bendrauti. Taigi jūs negalite sukurti atsitiktinių lizdų su svetainėmis ir pavogti duomenis. Taip pat negalite atidaryti failų. Užklausti tik paskirstytą duomenų bazę.
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.
Galėtume pristatyti paprastą virtualios mašinos kalbą, galinčią vykdyti primityvius dalykus, kurių reikalauja didžioji dauguma platinamų programų, ir paprastą saugų veikimo laiką, kuris apriboja savavališką bendravimą su kitomis mašinomis
Problema yra su vaizdo sluoksniu. Joks „vm“ neturės prieigos prie „Dom“ naršyklės. Jau yra žiniatinklio darbuotojo API, kuri gali būti naudojama funkcijoms vykdyti, tačiau norėtume suteikti vartotojams galimybę reaguoti į scenarijaus komponentus. Aš matau, kaip atskirti html nuo būsenos logikos ir įkalinti šią logiką žiniatinklio darbuotojui arba vm. Problema, kas išmoks kažkokių keistų API rašyti tuos komponentus ir kas perrašys visus komponentus, pasiekiamus 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.
Rekomenduoju pažvelgti į interneto kompiuterį, kurio tikslai yra panašūs.
https://dfinity.org/
Ji turi savo kalbą. Taigi vis tiek turite viską perrašyti.
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.
Galbūt priekinis sluoksnis yra tiesiog toks - programuotojas gali naudoti bet kokį norimą „React“ kodą, o naršyklė atlieka smėlio dėžę.
„Localhost“ gali būti priglobta paskirstytojo serverio programos, kurioje priglobiamos įvairios platinamos programos. Tai nebūtų labai saugu, nes svetainė gali pateikti HTTP užklausas.
Turėčiau paprastą JSON API, skirtą kalbėtis su paskirstytu tinklu ir užklausti duomenų bazę.
Galite uždrausti HTTP užklausas pagal turinio saugumo politiką.
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.
Galbūt turite vartotojo sąsają, kurioje sukuriate žmonių kambarį ir kambario žmones, su kuriais galite savavališkai bendrauti. Taigi jūs negalite sukurti atsitiktinių lizdų su svetainėmis ir pavogti duomenis. Taip pat negalite atidaryti failų. Užklausti tik paskirstytą duomenų bazę.
Manau, kad tai mano bandomojo tinklo idėja, kurioje apribojate prieigą tik patikimiems vartotojams. Jūsų kodas įkalinamas bandymų tinkle, kol bus peržiūrėtas. Nematau lengvo ir veiksmingo būdo leisti vm saugiai manipuliuoti Domu. Norėčiau naudoti gerai žinomas technologijas, tokias kaip reaguoti. Net gryna html eilutė nėra saugi, net jei visa būsenos logika yra atskirta į funkciją ir vykdoma „vm“ arba „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
Galbūt priekinis sluoksnis yra tiesiog toks - programuotojas gali naudoti bet kokį norimą „React“ kodą, o naršyklė atlieka smėlio dėžę.
„Localhost“ gali būti priglobta paskirstytojo serverio programos, kurioje priglobiamos įvairios platinamos programos. Tai nebūtų labai saugu, nes svetainė gali pateikti HTTP užklausas.
Turėčiau paprastą JSON API, skirtą kalbėtis su paskirstytu tinklu ir užklausti duomenų bazę.
Galite uždrausti HTTP užklausas pagal turinio saugumo politiką.
Hmmm. Įdomus. Turite omenyje, kad „localhost“ atliktų serverio atvaizdavimą ir teiktų tik html? Net html nėra saugus. Kažką apsvarstyti. Mes koduojame mvp, kol kas tik įrodome koncepciją, saugumo sumetimais. Bet mums reikia sprendimų. Asmeniškai nemanau, kad kuri nors smėlio dėžės schema yra visiškai patikima. Turi būti atliekamas peržiūros procesas, net siekiant užtikrinti modulių kokybę, be saugumo. Manau, kažkur žmonėms reikia įsitraukti. Palengvinti jų darbą yra dar viena tema, kurią verta aptarti
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
Pastaba: dfinity.org:
Dabartinis internetas sukurtas taip, kad būtų leidžiami bet kokie protokolai, bent jau viršijantys TCP/IP lygį. Imtis visų galimų protokolų pogrupio ir sukurti mazgų tinklą, kuris kalba tuose protokoluose, bet ne kituose, yra savotiškas izoliacionizmas. Verčiau ieškoti būdo, kaip išversti protokolus, kurie leistų bet kuria kalba kalbantiems mazgams suprasti vienas kitą (apie formatų raidą -philosophy/0001-metaform-filosofija.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).
Turiu omenyje, kad mes visiškai neužsiimame smėlio dėže ir tiesiog traktuojame platinamą programą kaip kitą svetainę.
Paskirstyto tinklo saugumas yra paskirstytame programų bėgiklyje, kuris veikia fone. Ši programa nusprendžia, ką programa gali padaryti. Galbūt reikia kokios nors konsolės vartotojo sąsajos, kad būtų patvirtinti operacinės sistemos atliekami veiksmai.
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.
Turiu omenyje, kad mes visiškai neužsiimame smėlio dėže ir tiesiog traktuojame platinamą programą kaip kitą svetainę.
Paskirstyto tinklo saugumas yra paskirstytame programų bėgiklyje, kuris veikia fone. Ši programa nusprendžia, ką programa gali padaryti. Galbūt reikia kokios nors konsolės vartotojo sąsajos, kad būtų patvirtinti operacinės sistemos atliekami veiksmai.
Labai vertinu tavo mintis, bet neseku. Problema yra nepatikimi scenarijai, veikiantys naršyklės kontekste. Galimos bet kokios vagystės ir šnipinėjimai, jei nesate atsargus. Programos branduolys negali kontroliuoti, ką žmonės prisideda prie tinklo. Kitas kontrolės mechanizmas yra leidimų sistema, tačiau tai taip pat nėra tobula. Kas ir kam suteikia leidimus? Tai būtų labai naudinga, tačiau ji negali pašalinti visų blogų veikėjų.
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.
Galite dezinfekuoti įvestis, kad uždraustumėte scenarijaus ir IMG žymas, kad išvengtumėte išfiltravimo. Problema ta, kad negalite apriboti platinamos programos „JavaScript“, kad anuliuotumėte dezinfekciją.
Jei pasitikime pačia platinama programa, galime pasitikėti jos pateiktais laukais, nes ji nebandys anuliuoti sanitarijos.
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.