Að byggja öruggan og árangursríkan sandkassa til að gera Codex kleift að virka á Windows

Þegar ég gekk til liðs við verkfræðiteymi Codex í september 2025 hafði Codex fyrir Windows enga útfærslu á sandkassa, sem þýddi að Windows-notendur neyddust til að velja á milli tveggja ófullnægjandi kosta þegar þeir notuðu kóðunarfulltrúa OpenAI:

1. Að samþykkja næstum hverja einustu skipun (jafnvel lestur) sem kóðunarfulltrúi vildi keyra sem er óhagkvæmt og hvimleitt. Einn helsti kosturinn við að nota Codex er að þú þarft ekki að vinna alla leiðinlegu vinnuna sjálf(ur).
2. Að virkja stillingu með fullum aðgangi: að leyfa Codex að keyra allar skipanir án samþykkis eða takmarkana, sem dregur úr núningi á kostnað eftirlits.

Codex⁠, kóðunarfulltrúinn okkar, keyrir á fartölvum forritara—hvort sem það er í gegnum CLI, IDE-viðbótina eða skjáborðsappið. Það stýrir samtali milli manneskju við lyklaborð og líkans sem keyrir í skýinu til að annast ályktunarvinnslu.

Codex keyrir sjálfgefið með heimildum raunverulegs notanda, sem þýðir að það getur gert allt sem notandinn getur gert. Þetta er öflugt og hugsanlega hættulegt. Kóðunarlíkanið getur sagt keyrsluumgjörðinni að keyra skipanir staðbundið, allt frá því að keyra prófanir til að lesa eða breyta skrá eða búa til Git-grein, þannig að sjálfgefin stilling Codex reynir að finna rétt jafnvægi milli árangurs og öryggis. Þessi sjálfgefna stilling leyfir Codex að lesa skrár nánast hvar sem er og skrifa skrár innan vinnusvæðisins þíns (þ.e. möppunnar þar sem þú keyrir Codex), án internetaðgangs nema þú takir það fram. Til að ná þessum sjálfvirku takmörkunum á skráarskrifum og netaðgangi innan öruggra marka þarf Codex-sandkassaumhverfi sem framfylgir þessum takmörkunum í raun.

Sandkassi er afmarkað keyrsluumhverfi. Þegar forritari notar Codex ræsir stýrikerfi tölvunnar hans skipun með skertum heimildum, og þær takmarkanir berast niður eftir ferlatrénu. Sérhver Codex-skipun er í sandkassa frá upphafi og sérhvert afsprengi hennar helst innan sömu marka.

Codex þarf einangrunareiginleika sem stýrikerfi tölvunnar framfylgir til að útfæra árangursríkan sandkassa. Sum stýrikerfi bjóða upp á nytjatól sem gera þetta vel (t.d. Seatbelt á MacOs, seccomp eða bubblewrap á Linux); hins vegar býður Windows ekki upp á slíka virkni beint úr kassanum eins og er.

Til að gera Codex jafn öruggt og ánægjulegt í notkun á Windows og það er nú þegar alls staðar annars staðar þurftum við að útfæra okkar eigin sandkassa.

Windows býður upp á nokkur verkfæri og frumeiningar fyrir einangrun. Þótt ekkert þeirra uppfyllti kröfur okkar að fullu skoðuðum við nokkrar mögulegar lausnir—nánar tiltekið AppContainer, Windows Sandbox og merkingar með Mandatory Integrity Control.

AppContainer

• Hvað: AppContainer er innbyggði sandkassi Windows, einangrunarlíkan sem byggir á getu og er hannað fyrir öpp sem vita fyrir fram nákvæmlega af hverju þau þurfa að hafa aðgang.
• Af hverju: Aðlaðandi vegna þess að það býður upp á raunveruleg mörk í stýrikerfinu í stað takmarkana sem aðeins eru besta viðleitni.
• Af hverju ekki: Codex er ekki eitt þröngt afmarkað app. Það knýr óafmörkuð verkflæði þróunaraðila: skeljar, Git, Python, pakkastjóra, byggingarverkfæri og hvaða aðrar keyrsluskrár sem fulltrúinn ákveður að hann þurfi. Í reynd gerði það að verkum að AppContainer var ekki rétt sniðið að vandamálinu. Þetta var öflug einangrun, en fyrir mun þrengri flokk vinnuálags en „að láta fulltrúa starfa eins og þróunaraðili“.

Windows Sandbox

• Hvað: Windows Sandbox er einföld, einnota sýndarvél frá Microsoft. Þú færð nýtt Windows-skjáborð með sterkum einangrunarmörkum, og allt sem þú gerir þar inni hverfur þegar lotunni lýkur.
• Af hverju: Áhugavert af augljósum ástæðum—mun samhæfðara handahófskenndum hugbúnaði en AppContainer og út frá öryggissjónarmiði er þetta miklu sterkari kassi.
• Af hverju ekki: Codex þarf að geta unnið beint á raunverulegri úttekt notandans, verkfærum og umhverfi, ekki inni á aðskildu, tímabundnu skjáborði sem þyrfti uppsetningu og tengingu milli hýsils og gests. Það var einnig með grundvallarvandamál sem vöru: Windows Sandbox er ekki einu sinni í boði í Windows Home SKU-útgáfum.

Merkingar með Mandatory Integrity Control (MIC)

• Hvað: Í Windows er til hugtak sem kallast „heilleikastig“, svo sem lágt, miðlungs og hátt, sem ákvarða hversu mikið kerfið treystir hlutum og ferlum. Grunnreglan er sú að ferli með lægra heilleikastig getur ekki skrifað í hlut með hærra heilleikastig, jafnvel þótt venjulegi ACL myndi að öðru leyti leyfa það. Til dæmis er ferli með lágt heilleikastig talið minna traust, þannig að Windows kemur í veg fyrir að það skrifi í hefðbundna hluti með miðlungs heilleikastig, nema þessir hlutir séu sérstaklega endurmerktir til að leyfa slíkan aðgang.
• Af hverju: MIC leit glæsilega út á pappír—keyrt Codex með litlum heilleika, endurmerkja skrifrætur sem lítinn heilleika og láta Windows framfylgja banni við skrifum alls staðar annars staðar. Það hefði gefið okkur leið án stjórnandaréttinda með raunverulega stýrikerfisvirkni að baki.
• Af hverju ekki: Líkt og ACL breyta heilleikamerkingar raunverulegu skráakerfi hýsilsins og í þessu tilviki er merkingarbreytingin sérstaklega víðtæk. Að merkja vinnusvæði með lágu heilleikastigi þýðir ekki bara „Codex getur skrifað hér.“ Það þýðir að ferli með lágt heilleikastig almennt séð geta skrifað þar. Á raunverulegri þróunarvél breytir þetta raunverulegu vinnuafriti notandans í lítinn heilleika-viðtaka fyrir hýsilinn, sem er mun áhættusamara en að veita einni sandkassahönnun vandlega afmarkaðar ACL. Jafnvel þótt þróunarverkfæri með miðlungs heilleikastigi haldi áfram að virka hefur undirliggjandi traustlíkan vinnusvæðisins breyst á þann hátt sem er erfitt að afmarka og enn erfiðara að réttlæta.

Eftir að hafa metið alla valkostina sem óraunhæfa fórum við að hanna okkar eigin lausn til að veita Windows-notendum góða Codex-upplifun.

Fyrsta virka frumgerðin okkar notaði sambland af Windows-hugtökum og -verkfærum til að útfæra þá einangrun sem við þurftum á að halda. Frá upphafi var eitt markmiðið að láta þetta virka án þess að krefjast hækkunar, sem þýðir að Codex þyrfti ekki að birta notandanum kvaðningu um stjórnandaréttindi bara til að setja upp eða keyra sandkassann. Það þýddi að komast að því hvernig hægt væri að setja skynsamleg takmörk á tvennt: ritun í skrár og netaðgang.

Ef við takmörkuðum ekki skrif á skrám yfirhöfuð, þá myndum við lenda í öryggisvandamálum. Ef við takmörkuðum skrif á skrám of mikið, myndi sandkassinn skerða framleiðni notenda og þurfa stöðugt að biðja um samþykki. Til að leysa þetta vandamál notuðum við tvær mikilvæga Windows-einingar: SID og rittakmarkaða tóka.

SID, eða öryggisauðkenni, er auðkennið sem Windows tengir við heimildir. Hver notandi er með SID, hópar eru með SID, og jafnvel ein innskráningarlota fær sitt eigið SID. Til dæmis gæti núverandi innskráð lota verið með SID á borð við S-1-5-5-X-Y. SID sem staðbundna stjórnendahópnum er úthlutað gæti verið S-1-5-32-544.

Windows gerir þér einnig kleift að búa til tilbúin SID sem samsvara ekki raunverulegum notanda en geta samt birst í ACL (aðgangsstýringarlistum), sem skilgreina hverjir geta lesið/skrifað/keyrt tilteknar skrár eða möppur. Þetta gerir SID að gagnlegri einingu fyrir sandkassann okkar: við getum búið til SID eingöngu fyrir Codex-sandkassann til notkunar, án þess að trufla neitt annað á vélinni.

Tókar eru öryggishlutir í Windows sem skilgreina auðkenni og réttindi fyrir keyrandi ferli. Þeir ákvarða hvaða aðgerðir ferli getur framkvæmt. Rittakmarkaður tóki er sérstök tegund vinnlutóka sem lætur Windows framkvæma viðbótar aðgangsathugun á skrifaðgerðum.

Til þess að skrifun takist þarf að standast tvær prófanir:

1. Venjulegt notandaaðkenni („eigandi“ tókans) verður að hafa heimild til þess
2. Að minnsta kosti eitt SID í lista tókans yfir takmarkað SID verður líka að hafa fenginn aðgang

Í reynd létu þessar athuganir okkur nota ACL til að skilgreina nákvæmlega hvar sandkassinn mætti breyta skráakerfinu sem veitti okkur þá nákvæmni sem við þurftum fyrir skrifaðgerðir.

Með SID og ritakmörkuðum tókum virkaði óupphækkaði sandkassinn okkar svona:

1. Uppsetning sandkassans bjó til tilbúið SID sem hét sandbox-write.
2. SID-auðkenninu sandbox-write var veittur skrif-, keyrslu- og eyðingaraðgangur að
   1. Núverandi vinnumöppu
   2. Öll frekari writable_roots sem eru skilgreind í config.toml.
3. Uppsetning sandkassans bannaði þessu sama SID sérstaklega skrifaðgang í „skrifvarið innan skrifanlegrar“ staðsetningar eins og:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ræsti skipanir undir rittakmörkuðum tóka þar sem listi yfir takmarkað SID innihélt Everyone, SID núverandi innskráningarlotu og tilbúna sandbox-write -SID.

Þetta flæði leysti í raun vandann við að takmarka skráarskrif og virtist lofa góðu. Nú þurftum við lausn til að takmarka netaðgang sandkassans.

Að takmarka netaðgang er mikilvægur hluti af sandkassanum; án þess gæti illgjarn kóði smyglað gögnum úr vélinni út á internetið. Þar sem við vildum forðast kröfu um upphækkun höfðum við takmarkaða valkosti til að útiloka netumferð af festu. Verkfærin sem við vildum nota, eins og Windows Firewall, var almennt ekki hægt að setja upp án stjórnandaheimilda.

Þar sem Windows Firewall var ekki valkostur takmörkuðum við það sem við gátum haft stjórn á. Við reyndum að stilla undirumhverfið þannig að það lokaði sjálfgefið á þær tegundir nettengdra verkfæra sem forritarar nota í raun, svo að Git-skipanir, pakkauppsetningarforrit o.s.frv. myndu mistakast í sandkassanum og notandinn þyrfti að samþykkja allar aðgerðir sem snúa að internetinu. Hugmyndin var að gera augljósu undankomuleiðirnar ónothæfar: senda umferð sem tekur tillit til proxy-stillinga á óvirkan endapunkt, láta HTTP(S)-flutningslag Git gera það sama og láta Git yfir SSH mistakast strax. Auk þess settum við litla denybin-möppu fremst í PATH og endurröðuðum PATHEXT þannig að staðgengilsskriftur fyrir SSH og SCP fyndust á undan raunverulegu keyrsluskránum.

Til dæmis eru hér nokkrar af þeim sértæku umhverfisyfirskrifum sem við notuðum til að takmarka netaðgang:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Þetta náði mikilli venjulegri verkfæraumferð, en það var samt bara ráðlegging. Ferli gæti hunsað umhverfið, farið fram hjá PATH eða bara opnað tengi beint - of áhættusamt.

Eins og með allar áhugaverðar hugbúnaðarinnleiðingar hafði fyrsta frumgerðin sína kosti og galla. Þó að það kláraði verkið með aðeins fáeinum stöðluðum Windows-eiginleikum, gerði kleift að skrifa mjög skýrt og ítarlega í skráarkerfi og keyrði án hækkunar – sem minnkaði þörfina fyrir notendur að samþykkja óhóflegar hækkunarbeiðnir eða vera stjórnendur á sinni eigin vél – hafði það nokkra raunverulega galla, sem sumir hverjir gerðu það óhæft til að verða lokahönnun okkar:

• Hraði uppsetningar: Það getur verið dýrt að nota ACL fyrir vinnusvæði, allt eftir því hvernig vinnusvæðismappan er í notkun.
• Fótspor: Við settum raunveruleg ACL á kerfi forritarans, þó að fótsporið sé ekki sérstaklega ífarandi þar sem allar notaðar aðgangsstýringarskrár tengjast sérsmíðuðu tilbúnu SID sem eingöngu er notað af sandkassanum.
• Merkingarfræði sem erfitt er að breyta: Þar sem stuðst er við ACL fyrir skráartengdar takmarkanir er kostnaðarsamt og flókið að breyta merkingarfræði sandkassans. Á macOS getum við aftur á móti breytt því á keyrslutíma hvernig við búum til .sbpl skrá sem er notuð til að stilla Seatbelt, Windows-sandkassinn gæti krafist hægrar og umfangsmikillar aðgerðar til að aðlaga ACL.
• Netvörnin er veik. Eins og áður hefur komið fram var þetta „ráðgefandi“, það yrði örugglega sniðgengið af sumum forritum sem útfærðu sinn eigin netkerfisstafla og var ekki hannað til að þola andstæðan kóða.

Fyrstu þrjú vandamálin eru eðlislæg í sérsniðinni sandkassaútfærslu sem er nógu sveigjanleg fyrir fulltrúaflæði. Sagan af netbælingunni var þó önnur.

Auk þess að illgjarn fulltrúi gæti auðveldlega sniðgengið umhverfisbundna netbælingu myndu mörg forrit/tvíundarskrár með góðan ásetning líka sniðganga hana einfaldlega ef þau virtu ekki proxy-breytur umhverfisins eða ef þau útfærðu eigin netkóða með sökklum. Okkur fannst þessi þáttur einn og sér nægja til að réttlæta fjárfestingu í betri sandkassastillingu.

Til að ná betri netbælingu vildum við nota Windows Firewall, sem gerir okkur kleift að blokka útleiðandi netumferð fyrir notendur eða forrit. Því miður gátum við ekki á skilvirkan hátt búið til nothæfa eldveggsreglu sem ætti aðeins við um skipanirnar sem Codex-keyrsluumgjörðin ræsti, af nokkrum ástæðum:

• Windows leyfir ekki að para eldveggsreglu við auðkenni takmarkaðs tóka sem er ekki aðal. Það þýðir að við gátum ekki beitt eldveggsreglu á „hvaða tóka sem er sem inniheldur tilbúna SID okkar í lista sínum yfir takmarkað SID.“
• Þótt við gætum búið til eldveggsreglu sem passar við tiltekna tvíundarskrá myndi það aðeins leyfa okkur að takmarka netnotkun fyrir codex.exe sjálfa. Það myndi ekki eiga við um ferlin sem fulltrúinn ræsir fyrir hönd notandans, svo sem Git- eða Python-ferli.
• Aðrar samsvörunarvíddir eldveggsins höfðu líka ranga lögun. Notandasértækar reglur samsvöruðu enn raunverulega Windows-notandanum í hönnuninni án aukinna réttinda, ekki bara takmarkaða undirferlinu. Reglur um forritsslóðir voru of grófar: þær gátu almennt lokað á codex.exe eða python.exe, en ekki þessa tilteknu keyrslu á python.exe í sandkassa. Reglur sem byggðust á gáttum eða vistföngum voru auk þess algerlega röng stefna. Til dæmis vildum við ekki loka á gátt 443; við vildum loka á ótilgreindan útleiðandi aðgang fyrir þetta tiltekna takmarkaða ferlatré.

Til að beita eldveggsreglu sérstaklega á sandkassaskipanir okkar þurftum við að keyra þær sem sérstakan aðal, ekki sem „alvöru“ notanda. Þessi aðferð leiddi okkur inn á nýja braut, braut þar sem við slökuðum á takmörkuninni „engin upphækkun“.

Næsta ítrun sandkassans, sem er núverandi innleiðing okkar, krefst aukinnar stjórnandaheimildar við uppsetningu. Ég kalla hann því „upphækkaðan sandkassa.“ Á skilunum þar sem Codex ræsir skipun á kerfinu lítur upphækkaði sandkassinn út eins og sá án upphækkunnar. Hann keyrir enn undirferli undir takmörkuðum tóka—á svipaðan hátt write_restricted -tókar með sama takmarkaða SID-, [Everyone, Logon, Synthetic]—en aðalauðkenni þessa tóka er ekki lengur hinn raunverulegi Windows-notandi, heldur annar af tveimur staðbundnum notendum sem Codex sjálft býr til:

• CodexSandboxOffline (það sem eldveggsreglur miða á)
• CodexSandboxOnline (það sem eldveggsreglur ná ekki til)

Þetta smávægilega smáatriði virðist kannski lítilsvert, en hefur í raun mikil áhrif á sandkassann, hverjir geta notað hann og hversu flókin uppsetning hans og keyrslutími eru.

Hann líkist sjónrænt óupphækkuðu frumgerðinni, með viðbót eldveggsreglna og sérstaks Windows-notanda sem keyrir skipanirnar í raun. (Innleiðing þessara nýju hugtaka þýðir þó að það þarf að vinna meiri uppsetningarvinnu áður en sandkassinn getur farið að keyra og verja skipanir.)

Hönnun óupphækkaða sandkassans hafði einfalt uppsetningarskref, en það var tiltölulega lítið:

• Búðu til tilbúið SID ef þess þarf
• Beittu ACL fyrir tilbúna sandbox-write SID

Upphækkaði sandkassinn hefur hins vegar meira að gera.

• Búa til tilbúið SID, ef það hefur ekki þegar verið búið til
• Búðu til sandkassanotendur á netinu og utan nets, ef þeir hafa ekki þegar verið búnir til
• Geymdu aðgangsupplýsingar nýstofnuðu notendanna staðbundið og dulkóðaðu þær með Windows Data Protection API (DPAPI) á stað sem sandkassanotendur geta í raun ekki lesið
• Búðu til eldveggsreglur sem útiloka allan útleiðandi netaðgang fyrir notandann CodexSandboxOffline eða, ef þær eru þegar til, sannreyna að þær séu réttar

Það er ein viðbótarflækja á uppsetningarstiginu. Gert er ráð fyrir að sandkassi Codex hafi lesaðgang sem samsvarar lesaðgangi raunverulega Windows-notandans. Í óupphækkaða sandkassanum, þar sem aðal-SID takmarkaða tókans var Windows-notandinn, náðist þetta. Hins vegar gerist það ekki af sjálfu sér þegar aðilinn verður nýr CodexSandbox-notandi. Margar viðeigandi möppur í Windows veita „Auðkenndum notendum“ lestrar- og keyrsluheimildir. Eitt athyglisvert dæmi er prófílmappa notandans. Sjálfgefið geta Windows-notendur ekki lesið prófílmöppur annarra Windows-notenda, þannig að jafnvel einfaldur lestur skráa myndi mistakast í mörgum tilvikum.

Til að bregðast við þessu bættum við við öðru lagi í uppsetningarferli sandkassans—lagi til að veita sandkassanotendum les-ACL þar sem slík ACL gætu ekki þegar verið til staðar. Til dæmis í nokkrar algengar Windows-möppur:

• C:\Users\<real-user>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Þar sem þessi listi yfir möppur er unninn með allra bestu fyrirhöfn og uppsetning ACL á hverja og eina getur verið nokkuð dýr, keyrum við þessa rökfræði ósamstillt svo að uppsetningarskrefið fyrir sandkassa, sem lokar fyrir notendur, þurfi ekki að bíða eftir að þeir klárist.

Við hjúpuðum uppsetningarrökfræðina í eigin keyrsluskrá, meðal annars til að fara aðeins yfir UAC-mörkin þegar þörf krefur. En dýpri ástæðan varðaði högunina: uppsetning sandkassans gegnir í grundvallaratriðum öðru hlutverki en codex.exe. Með því að halda uppsetningarrökfræði sandkassans í sérstakri tvíundarskrá gat codex.exe áfram verið venjuleg, óupphækkuð keyrsluumgjörð; komið í veg fyrir að Windows-sértæk uppsetningarvél blési út codex.exe á öðrum kerfum; aftengt lengri uppsetningarvinnu frá líftíma aðalferlisins; og gefið okkur einn stað til að meðhöndla mismunandi uppsetningarleiðir sem sandkassinn þurfti.

Vegna þess hvernig mörk innskráningar notenda og tóka virka í Windows gátum við ekki haldið áfram að búa til takmarkaðan tók og ræsa ferli undir honum á sama hátt og við gátum með óupphækkaða sandkassanum. Til að geta raunverulega ræst skipanir sem annar Windows-notandi var fyrsta hugmynd okkar eftirfarandi flæði:

• codex.exe keyrir sem raunverulegi Windows-notandinn. Síðan gerir Codex eftirfarandi í röð:
  • Kallar á LogonUserW(...) fyrir sandkassanotandann.
  • Kallar á CreateRestrictedToken(...) á þessum tóka sandkassanotanda.
  • Með þessum takmarkaða sandkassanotanda-tóka er kallað á CreateProcessAsUserW(...) til að ræsa síðasta undirferlið.

Í reynd virkaði þetta æskilega flæði ekki vegna réttindahindrunar við CreateProcessAsUserW(...). Þetta þýðir að codex.exe gat búið til takmarkaðan tóka fyrir sandkassanotandann, en gat ekki ræst undirferli á áreiðanlegan hátt með þeim tóka frá raunnotandahlið markanna. Við þurftum ferli sem keyrði nú þegar sem sandkassanotandi—þetta myndi gera takmörkunarskrefinu og lokastofnun ferlisins kleift að eiga sér stað sandkassanotandamegin við mörkin í stað raunnotandamegin.

Þessi krafa leiddi til codex-command-runner.exe, nýrrar keyrsluskrár sem hefur það eina hlutverk að búa til takmarkaðan tóka og ræsa umbeðna skipun. Í stað þess að biðja codex.exe um að sjá um allt flæðið sjálft (raunverulegur notandi → sandkassanotandi → takmarkaður tóki → undirferli) skiptum við flæðinu í tvennt:

Hluti 1

• codex.exe kallar á CreateProcessWithLogonW(...) til að ræsa codex-command-runner.exe sem sandkassanotandann, án þess að nota takmarkaðan tóka enn.

Hluti 2

• Inni í keyrslunni opnar OpenProcessToken(GetCurrentProcess(), ...) eigin tóka keyrslunnar, sem tilheyrir þegar sandkassanotandanum.
• Keyrslan kallar á GetTokenInformation(...) til að draga út útskráningar-SID sandkassans og síðan CreateRestrictedToken(...) til að búa til endanlega takmarkaða tóka.
• Enn inni í keyrslunni kallar hann á CreateProcessAsUserW(...) með þeim takmarkaða tóka til að ræsa raunverulega undirferlið.

Albert Einstein sagði: „Allt ætti að vera eins einfalt og mögulegt er, en ekki einfaldara.“ Í þeim anda leysti hönnun okkar öll vandamálin á fullnægjandi hátt. Lokahönnunin hefur þau fjögur lög sem við höfum áður fjallað um:

• codex.exe sjálft
• codex-windows-sandbox-setup.exe til að sinna allri upphækkaðri uppsetningarvinnu
• codex-command-runner.exe til að keyra skipanir með takmörkuðum tóka
• Undirferlið

Þegar ég byrjaði að takast á við þetta verkefni hafði ég ekki sterka hugmynd um hvert það myndi enda. Aðferð mín var að byrja á því að setja sandkassann á mörkin milli Codex og stýrikerfisins. Þessi aðferð líkist því hvernig sandkassinn í Codex er útfærður á MacO og Linux.

Þegar ég lærði meira um þau sérstöku verkfæri sem Windows býður upp á, og í gegnum fjölda ákvarðana sem vega og meta öryggi og auðvelda notkun, óx kerfið í núverandi mynd — margar tvíundaskrár, sérsniðnir notendur, eldveggsreglur, uppsetningarskref með upphækkuðun stillingum, ósamstilltir ferlar og fleira.

Þetta er ekki sérstaklega einfalt kerfi, en hverju flækjustigi var bætt við af nauðsyn, til að byggja upp sandkassa sem er bæði öruggur og, eins mikið og mögulegt er, ekki í vegi notandans.

Við leggjum okkur fram um að veita Codex-notendum góða notendaupplifun á Windows og markmið okkar var að búa til eitthvað öruggt sem myndi ekki skerða notagildi — allur tilgangurinn með því að nota Codex er að fulltrúar geti unnið verk sín án þess að þú hafir stöðuga athygli.

Einn helsti lærdómurinn af þessu verkefni var að Windows gaf okkur ekki eitt frumforrit sem tengist skýrt við „öruggt sjálfvirkt kóðunarforrit“. Við smíðuðum nokkur verkfæri og hugmyndir til að byggja upp eitthvað samhangandi. Sumar fyrstu hugmyndir voru blindgötur. Lokahönnunin var blanda af fyrri frumgerðum sem hver um sig leysti hluta af vandamálinu.

Hinn lærdómurinn var sá að öryggi fyrir forritara er allt annað mál en hefðbundið forritaöryggi. Codex verður að virka fyrir raunveruleg vinnuflæði forritara. Verkfræðivinnan snerist um að vega og meta samhæfni við forritaravinnu á móti raunverulegri framfylgd. Þessi spenna mótaði málamiðlanir í lokahönnuninni.

Viltu sjá Codex-sandkassann í verki? Prófaðu það⁠.