Povestea uitată a lui Matt și lecțiile pe care le-am învățat prea târziu

Înainte de WordPress, înainte de Squarespace, când nimeni nu auzise de "no-code", exista un adolescent de liceu pe nume Matt Wright care a decis să împărtășească niște scripturi Perl pe care le scrisese.

Prin 1995, Wright a lansat Matt's Script Archive – o colecție modestă de utilitare web: formulare de contact, cărți de oaspeți, contorizări pentru site-uri și o creație virală numită WWWboard. În câteva luni, mii de website-uri rulau codul lui. Oameni obișnuiți – care habar nu aveau ce înseamnă "Perl" sau cum funcționează CGI – aveau dintr-o dată forumuri funcționale și funcții interactive.

Asta a fost prima gustare a internetului de instrumente democratizate. Și a venit cu toate consecințele haotice pe care această sintagmă le implică.

Distanța dintre constructori și utilizatori

Ce a făcut scripturile lui Matt atât de populare a fost exact ceea ce îi făcea pe programatori să scrâșnească din dinți: funcționau. Nu elegant. Nu sigur. Dar funcționau.

Wright a dat peste o adevăr fundamental legat de adoptarea software-ului: majoritatea oamenilor nu vor să înțeleagă instrumentele lor. Vor ca instrumentele să îi înțeleagă pe ei. Un mic proprietar de afaceri în 1996 nu se zbătea cu validarea input-ului sau prevenirea SQL injection. Îi păsa doar că vizitatorii puteau lăsa mesaje pe site-ul lor artizanal.

Între timp, dezvoltatorii experimentați se uitau la codul lui Wright și vedeau un coșmar. Parole stocate în directoare accesibile. Variabile de mediu expuse prin URL-uri. O vulnerabilitate deosebit de neplăcută în scriptul de contorizare a primit un scor CVSS perfect de 10.0 – practic o ușă din spate larg deschisă către server.

Comunitatea Perl a răspuns în cele din urmă cu nms (nongreedy's modifications), un proiect dedicat creării de înlocuitori care să nu expună utilizatorii la compromiterea de nivel root. Evaluarea lor a fost dură, dar corectă: "Scripturile sunt bine cunoscute în comunitatea Perl pentru că sunt prost scrise, pline de bug-uri și nesigure."

Paradoxul securității în popularitate

Și aici devine filosofic interesant.

Scripturile lui Matt nu erau unicate de groaznice pentru epoca lor. Mult cod web timpuriu avea găuri de securitate. Ceea ce făcea codul lui Wright periculos era răspândirea lui. Când mii de site-uri rulează același software vulnerabil, obții o suprafață de atac masivă. Dintr-o dată, o vulnerabilitate teoretică devine o epidemie reală.

Acest tipar s-a repetat nestingherit de atunci. Windows. WordPress. jQuery. Orice instrument suficient de popular devine o țintă nu pentru că e prost conceput, ci pentru că e peste tot. Munca comunității de securitate nu e doar să repare bug-uri – e să convingă oamenii că "destul de bun pentru acum" s-ar putea să nu fie destul de bun pentru mai târziu.

Dar iată tensiunea: uneori "destul de bun pentru acum" este exact ceea ce permite creșterea. O startup care folosește un instrument timpuriu nesigur ar putea construi următorul WordPress. Împiedicarea oamenilor să construiască cu instrumente imperfecte înseamnă împiedicarea lor de a construi deloc.

Salut, Vibe Coding

Saltă înainte treizeci de ani. Avem o nouă generație de instrumente "destul de bune": platforme de coding asistat de AI, aplicații vibe-coded, fragmente de cod generate de LLM-uri și trimise direct în producție.

Răspunsul comunității de securitate se desfășoară deja. Da, există îngrijorări legate de cod generat de AI cu vulnerabilități subtile. Da, există dezbateri aprinse despre dacă vibe coding-ul este responsabil. Și da, unii oameni deploy-uie absolut gunoi nesigur în producție.

Dar iată ce criticile nu înțeleg: vibe coding-ul face exact ce au făcut scripturile lui Matt. Permite oamenilor care nu sunt dezvoltatori profesioniști să livreze produse funcționale. Un solopreneur poate construi acum o aplicație web funcțională într-o după-amiază. Asta nu e nimic – asta e democratizarea creației în sine.

Întrebarea nu e dacă aplicațiile vibe-coded sunt sigure. Adesea nu sunt. Întrebarea e dacă beneficiile accesibilității depășesc compromisurile de securitate. Și istoria sugerează că răspunsul e complicat, dar generally pozitiv – cu mențiunea că avem nevoie de instrumente mai bune, default-uri mai bune și o educație mai bună.

Povestea domeniului

Există un postfață la această poveste care e deosebit de relevantă pentru oricine vede domeniile ca mai mult decât simple adrese.

Worldwidemart.com – domeniul care odată găzduia Matt's Script Archive – a expirat în cele din urmă. Pentru o vreme, a găzduit tipul de conținut plin de spam și pariuri care dă coșmaruri software-lui antivirus. Apoi, târziu anul trecut, cineva a cumpărat domeniul expirat специально pentru a păstra arhiva istoricului.

Cineva a ținut suficient de mult la istoria web pentru a salva o piesă din ea de la cybersquatteri. Asta merită menționat. Domeniile nu sunt doar active tehnice – sunt artefacte culturale. Uneori povestea pe care o spune un domeniu contează mai mult decât valoarea lui SEO.

Ce înseamnă asta pentru tine

Deci care e concluzia pentru dezvoltatorii moderni, fondatorii de startup-uri și antreprenorii tech?

În primul rând, "destul de bun" a condus întotdeauna adoptarea. Nu dismissa instrumentele doar pentru că experții le critică. Instrumentele pe care oamenii le folosesc efectiv contează mai mult decât cele pe care experții le aprobă.

În al doilea rând, datoria de securitate se acumulează. Dacă construiești pe fundații "destul de bune", înțelege ce moștenești. Planifică pentru datoria tehnică. Include audituri de securitate în roadmap-ul tău.

În al treilea rând, accesibilitatea și calitatea nu sunt dușmani, dar necesită echilibru. Scopul nu e să împiedici oamenii să construiască – e să faci construirea sigură mai ușoară decât cea nesigură. Asta ține de creatorii de instrumente. De platforme. De noi.

Matt Wright nu și-a propus să modeleze internetul. A făcut doar niște scripturi disponibile pentru oamenii care aveau nevoie de ele. Uneori asta e exact ce are nevoie lumea. Doar poate ține-ți dependențele actualizate.