Tarayıcı bir sandbox'tır

• Web platformu geliştiricisi Paul Kinlan, kodlama ajanları için güvenli bir çalışma ortamı olarak tarayıcının potansiyelini inceliyor
• Tarayıcının zaten güvenilmeyen kodu çalıştırmak için güçlü bir sandbox yapısına sahip olduğuna dikkat çekiyor
• Bunu doğrulamak için Co-do adlı bir demo hazırlayarak tarayıcı içinde dosya erişimi, ağ iletişimi ve kod çalıştırmayı test ediyor
• Co-do, File System Access API, CSP başlıkları ve <iframe sandbox>, Web Workers içinde WebAssembly kullanıyor
• Bu, tarayıcının yerel container'lar olmadan da bir AI ajanı çalışma ortamına dönüşebileceğini gösteren bir örnek

---

Tarayıcıya sandbox olarak bakış

• Google'dan Paul Kinlan, kodlama ajanlarını çalıştırmak için güçlü bir sandbox ortamı gerektiğini düşünüyor
  • Tarayıcının son 30 yılda kötü amaçlı yazılımları veya güvenilmeyen kodları güvenle çalıştırmak için gelişmiş bir platform olduğunu vurguluyor
  • Bu özellik, tarayıcının bir ajan çalışma ortamı olarak kullanılabilmesi için temel oluşturuyor

Tarayıcı tabanlı sandbox'ın üç temel unsuru

• Kinlan, sandbox'ın üç temel unsuru olarak dosya sistemi erişimi, ağ erişim kontrolü ve güvenli kod çalıştırmayı öne çıkarıyor
  • File System Access API, tarayıcıda yerel dosyalarla çalışma imkanı sunuyor ve şu anda yalnızca Chrome'a özel olarak biliniyor
  • CSP(Content Security Policy) başlıkları ve <iframe sandbox> niteliğiyle ağ erişimi kontrol edilebiliyor
  • WebAssembly ve Web Workers kullanılarak kod izole bir ortamda çalıştırılabiliyor

Co-do demosunun yapısı ve işlevleri

• Kinlan'ın fikrini doğrulamak için Co-do adlı bir demo uygulaması hazırlandı
  • Kullanıcı klasör seçiyor, ardından LLM sağlayıcısını ve API anahtarını ayarlıyor
  • Co-do, CSP tarafından izin verilen API çağrıları üzerinden LLM ile etkileşime giriyor ve dosyalarla konuşabilen bir sohbet arayüzü sunuyor
  • Bu yapı Claude Cowork'e benziyor, ancak büyük yerel container'lar olmadan yalnızca tarayıcıda çalışıyor

<iframe sandbox> ve güvenlik teknolojilerinin sınırları

• Ana sorunlardan biri, <iframe sandbox> için dokümantasyonun yetersiz olması
  • Tarayıcılar arasında uygulama farkları büyük ve ilgili kaynaklar sınırlı
  • Kinlan, double-iframe tekniğiyle iç çerçeveye ağ kuralları uygulama yöntemini gösteriyor

Ek keşifler ve deneyler

• <input type="file" webkitdirectory> niteliğinin Firefox, Safari ve Chrome üzerinde de çalıştığı doğrulandı
  • Bu sayede tarayıcı, tüm dizine salt okunur erişim sağlayabiliyor
  • Bunu denemek için bir webkitdirectory demosu hazırlandı ve gelecekteki projelerde de kullanılmasının planlandığı belirtiliyor

Sonuç

• Tarayıcı, güvenli izolasyon ve kod çalıştırma için yüksek olgunluğa ulaşmış bir platform haline gelmiş durumda
• Co-do örneği, tarayıcının AI kodlama ajanları için bir çalışma ortamı olarak genişleyebileceğini gösteren deneysel bir kanıt sunuyor

[GN⁺]

Hacker News yorumları

• Bu, bağlantı blogumda yayımladığım bir yazı. Bağlamın tamamını anlamak için mutlaka özgün metin olan The Browser is the Sandbox yazısını okumak gerekir

  • Bağlantı bloguna böyle bir yönlendirme notu eklemek iyi olabilir. Ben de bloguma yıl bilgisi ve abonelik notu ekledim; sonrasında aynı soruları içeren e-postalar ciddi biçimde azaldı. Bu sayede blog yazmaktan keyif almaya devam ediyorum
  • İstikrarın gerçekten etkileyici. HN'de adını görmediğim bir hafta neredeyse olmadı. Kişisel olarak LLM karşılaştırma yazıları bana çok hitap etmiyor ama süreklilik sonunda bir markaya dönüşmüş gibi görünüyor. Bundan sonrası için de desteğim seninle

• Google'ın NaCl'ı yapma nedeninin doğrudan WebAssembly'nin sandbox standardizasyonuna uzandığını düşünüyorum. DOM, JS ve CSS de birer render sandbox'ı gibi çalışıyor. Tarayıcı, işlevleri sınırlayarak birleşik bir kullanıcı deneyimi sunmalı.
  IE ve eski Edge'in başarısız olma sebebi de buydu. Flash, ActiveX, Java Applet ve Silverlight gibi harici sandbox'ların hepsi ortadan kayboldu; asm.js ve WebAssembly'nin oturmasıyla web çok daha temiz hale geldi. Bu arada Flash'ın ActionScript'i, ECMAScript ve TypeScript tasarımını da etkiledi

  • Ben ActionScript 3'ü gerçekten çok seviyordum. Zamanında AS3 ile chime.tv adlı bir video toplayıcısı yapmıştım (TechCrunch yazısı); geliştirme süreci gerçekten çok keyifliydi
  • Java'nın ActionScript ile ilgisi yok. LiveScript'in adı Sun/Netscape iş anlaşması nedeniyle JavaScript olarak değiştirildi, hepsi bu
  • Silverlight aslında oldukça iyiydi; sonlandırılmış olmasına üzülüyorum

• webkitdirectory niteliğini ilk gördüğümde ben de şaşırdım. Yıllardır web uygulamaları geliştiriyorum ama bunu kaçırmışım. Tarayıcı sandbox'ı, milyarlarca insanın şüpheli bağlantılara tıklayarak doğruladığı bir güvenlik modeli.
  Her seferinde yeni bir container ayağa kaldırmaktan çok daha olgun bir yaklaşım. Yine de tarayıcının sistem çağrıları, ikili dosya çalıştırma ve donanım erişimi gibi konularda kısıtları var. Yapay zeka ile kodlama için yeterli ama bazı işler için sınırları mevcut

  • Bence bu yaklaşım ajan tabanlı akışlar kurmak için çok uygun. Özgün dosyaları doğrudan değiştirmeden özetleme, soru-cevap ve yeni belge üretimi gibi yönlere genişletilebilir. Yerel LLM kullanırken bile araç çağrılarını güvenli biçimde sınırlamak mümkün
  • Aynı nedenle NPM geliştiricilerinin de NodeJS'in dengesiz API'lerine bağlı kalmak yerine tarayıcı sandbox'ında çalışabilen kaynak kodu işleyicileri üretmesinin daha iyi olacağını düşünüyorum

• systemd ya da Linux'un kullanıcı izin sistemi gibi şeylerin sandbox tartışmalarında neredeyse hiç anılmaması ilginç. Oysa bunlar da oldukça güçlü ve düşük maliyetli izolasyon sağlıyor

  • Unix izin modeli aslında başlangıçta sistemi kullanıcıdan korumak için tasarlanmıştı. Programlar kullanıcının izinleriyle çalıştığı için, programın kendisinin kötü niyetli olabileceği fikri yoktu. Günümüzde ise programlar arası koruma gerekiyor. Ben de bir dönem her uygulama için ayrı kullanıcı yaklaşımını denedim ama çok verimsizdi. Sonuçta gereken şey capabilities modeli. Bununla ilgili xkcd 1200 iyi açıklıyor
  • Çoğu kişi hâlâ sadece Dockerfile yazıp doğrudan deploy ettiği için bu tür tartışmalar pek yapılmıyor
  • Linux çekirdeğinde çok sayıda ayrıcalık yükseltme açığı var. Güvenilir yazılımları izole etmekte işe yarıyor ama kötü amaçlı yazılımlar karşısında etkisiz kalıyor
  • Yapay zeka ajanlarını MacOS'ta kısıtlı kullanıcı hesabıyla izole eden sandvault gibi yaklaşımlar var. Hafif ve genel amaçlı olduğu için oldukça iyi bir fikir gibi görünüyor
  • systemd ile tarayıcı içindeki JavaScript'in DNS ya da HTTP isteklerini engelleyemeyeceğiniz için, bu tür tartışmalara dahil etmek zor bence

• File System Access API, web'in gelişiminde büyük bir dönüm noktası. co-do.xyz üzerinde bir dizin seçip yapay zekanın içindeki dosyalarla güvenli biçimde çalışmasını sağlayabiliyorsunuz. Bu API sayesinde web uygulamaları gerçekten üretkenlik araçları haline geldi

  • Dağıtım maliyeti azalıyor ama durumu tarayıcıda yönetmek uzun vadede istikrarsızdı. Ben de bir yayımlama aracı geliştirirken sonunda yeniden LangGraph ve Celery'ye döndüm. Altyapı tasarrufundan daha önemli olan şey güvenilirlik kazanmak oldu
  • Yerel arayüzler hâlâ üstün olduğu sürece web uygulamalarının tam anlamıyla birinci sınıf üretkenlik uygulamaları olması zor
  • Safari ve Firefox'ta bu API'nin işlevleri hâlâ desteklenmiyor

• Tarayıcı tabanlı çalıştırma ilgi çekici ama çoğu gerçek iş uygulaması, bakım kolaylığı, güvenlik ve veri erişilebilirliği nedeniyle bulut merkezli yapıya geçti. Yerelde çalıştırma kişisel üretkenlik için iyi olabilir ama ana akım uygulamalar için sınırları var. Geçmişte AppleScript, COM ve DDE gibi masaüstü otomasyonu özelliklerinin ortadan kaybolmasının sebebi de bu

  • COM hâlâ Windows'un temel API aktarım mekanizmalarından biri olarak yaşıyor. Windows 3.x döneminde DDE ile uğraşılan günleri hatırlatıyor
  • Bootstrap ile kurulmuş GenAI uygulamalarında çıkarımı tarayıcıya offload etmek ekonomik bir zorunluluk. GPU maliyeti çok yüksek; bu yüzden kullanıcının donanımı fiilen eldeki tek ücretsiz kaynak

• Tarayıcıda mümkün olan iki şeyi daha tanıtmak istiyorum

  1. webcontainer ile NodeJS frontend ve backend'i tarayıcıda çalıştırmak mümkün (ör. bolt.diy projesi)
  2. jslinux ve x86 Linux örneğinde olduğu gibi, WebAssembly tabanlı tam bir Linux ortamını tarayıcıda çalıştırabilirsiniz
     Teoride yalnızca bir URL ile oldukça tam bir ajan sistemi kurulabilir
  • Şu anda v86 deneyi üzerinde çalışıyorum. Hedefim, LLM'in bunu bir dosya sistemi ve yürütme ortamı gibi kullanması. Ancak v86 daha çok etkileşimli kullanıcı arayüzüne odaklı olduğu için programatik kontrol kolay değil
  • webcontainers.io ticari ve kapalı bir çözüm olduğu için, ondan açık kaynak platformlarla aynı düzeyde söz etmenin uygun olmadığını düşünüyorum

• Eskiden Chrome'da File System Access API ile bir dizin için okuma/yazma izni istenebiliyordu ama sekme yenilenince izin kayboluyordu. Şimdi düzelip düzelmediğini merak ediyorum

  • Artık kalıcı izin verme mümkün. Chrome geliştirici blogu bunu ayrıntılı biçimde anlatıyor
  • Masaüstü Chrome'da (Ubuntu) izin korunuyor ama Android Chrome'da sayfa yenilenince dizin erişimi kayboluyor. MDN belgesi bakılabilir

• Bu yaklaşım yalnızca dosya sistemini sandbox içine alıyor. Oysa insanlar e-posta, takvim, sohbet, kaynak kodu ve finansal veriler gibi şeylere de bağlanmak istiyor. Dosya sistemi güvenliği sadece başlangıç; veri ekosisteminin tamamının güvenliği hâlâ çözülmesi gereken bir konu

• Bu yaklaşımın sınırlarını merak ediyorum. Tarayıcıda Gemini CLI'yi daha iyi bir UX ile uygulamak mümkün mü? Yerel araçlarla da entegre olabilir mi?

  • Bunun tamamen mümkün olduğunu kesin söylemek zor ama araçların çoğu JS tabanlı olduğu için tarayıcıda önemli bir kısmı uygulanabilir. Artık Node API'lerinde tarayıcıda çalıştırılamayan şey neredeyse kalmadı