Google memperbaiki lebih banyak bug Chrome pada Juni dengan AI dibanding dua tahun terakhir

 (blog.google)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Chrome mengotomatiskan seluruh proses mulai dari penemuan, klasifikasi, perbaikan, distribusi, hingga penerapan pembaruan kerentanan dengan agen berbasis Gemini, dan memperbaiki 1.072 bug keamanan di Chrome 149 dan 150, lebih banyak daripada gabungan 23 milestone sebelumnya
  • Sistem pendeteksian kerentanan bekerja dengan menggabungkan banyak model, basis pengetahuan riwayat CVE dan Git Chrome, SECURITY.md, serta agen kritik terpisah, dalam lingkungan yang sangat membatasi akses ke internet dan sistem lokal
  • Klasifikasi otomatis melakukan penghapusan spam dan duplikasi, pengumpulan reproduksi dan pelacakan stack, penambahan metadata seperti tingkat keparahan, serta penugasan penanggung jawab, dan diperkirakan menghemat ratusan jam kerja developer setiap bulan
  • Untuk mengurangi kesenjangan patch antara pengungkapan perbaikan dan eksploitasi, Google menguji rilis keamanan dua kali seminggu, serta mengembangkan patch dinamis yang mengganti proses anak tanpa restart dan restart otomatis di macOS
  • Tidak berhenti pada perbaikan bug individual, Chrome juga meningkatkan keamanan memori dengan MiraclePtr, std::span, dan Rust, serta mencegah masuknya kerentanan melalui pemeriksaan AI saat pengiriman dan pembaruan otomatis lebih dari 2.300 dependensi eksternal

Siklus hidup bug keamanan yang diubah oleh AI

  • LLM telah memperluas pendeteksian kerentanan otomatis melampaui skala yang bisa ditangani hanya dengan keahlian keamanan manusia, dan Chrome memanfaatkan AI untuk menemukan dan memperbaiki ratusan bug keamanan dengan lebih cepat
  • Jika bug fitur biasa dapat menyebabkan masalah seperti UI macet, bug keamanan dapat dimanfaatkan dalam eksploit yang memungkinkan penyerang membaca data pribadi atau mengendalikan komputer tanpa sepengetahuan pengguna
  • Bug keamanan ditangani melalui urutan penemuan, klasifikasi, perbaikan, distribusi Chrome yang memuat perbaikan, lalu restart browser dan penerapannya, dengan tujuan mempercepat semua tahap semaksimal mungkin

Perluasan pendeteksian kerentanan

  • Tim keamanan Chrome telah mengembangkan teknik pendeteksian berbasis LLM selama beberapa tahun
  • Harness agen Gemini yang dibangun pada awal 2026 meningkatkan efisiensi pendeteksian dan mengurangi false positive di codebase Chrome yang lebih luas
    • Bug sandbox escape yang ditemukan dapat membuat renderer yang telah dikompromikan menipu browser agar membaca file lokal, dan telah bertahan di kode selama lebih dari 13 tahun
  • Fitur berikut ditambahkan ke harness pendeteksian
    • Interoperabilitas model yang memanfaatkan kekuatan masing-masing model open-weight dan model proprietari
    • Basis pengetahuan yang mencakup seluruh CVE yang ada dan seluruh riwayat Git Chrome
    • Panduan penulisan SECURITY.md untuk menyampaikan batas kepercayaan dan model ancaman dengan jelas
    • Agen kritik yang membaca SECURITY.md dalam konteks terpisah
    • Pemindaian berulang pada codebase untuk mencerminkan sifat non-deterministik model dan peningkatannya dari waktu ke waktu
  • AI menganalisis hanya source code yang tersimpan pada perangkat terkunci yang tidak dapat mengakses internet umum
    • Semua permintaan jaringan dicegat untuk menerapkan allowlist berbasis aplikasi dan tujuan
    • Model tidak dijalankan dalam mode tanpa batas, dan perubahan sistem oleh sub-agen serta akses file di luar direktori source yang ditentukan dibatasi
  • Pendeteksian AI tidak menggantikan pengujian keamanan yang sudah ada
    • Fuzzing sangat efektif terutama untuk bug yang muncul dari interaksi jarak jauh antarbagian kode atau kombinasi beberapa operasi yang tampak tidak terkait
  • Peneliti eksternal tetap diberi imbalan untuk menemukan kerentanan yang sulit dan berdampak besar melalui Chrome Vulnerability Reward Program
    • Pada awal 2026, laporan dari semua jenis meningkat, dan pada Maret jumlah laporan bug yang diterima lebih banyak daripada sepanjang 2025
    • Karena itu Google mengubah VRP agar memberi nilai tambahan di atas hasil pendeteksian internal dan berfokus pada laporan yang mudah ditangani oleh pipeline otomatis

Klasifikasi otomatis dan perbaikan multi-agen

  • Dulu, mengklasifikasikan satu laporan keamanan memerlukan 5 menit hingga lebih dari 30 menit dan sangat bergantung pada keahlian manusia, tetapi kini sistem berbasis aturan digabungkan dengan AI untuk meningkatkan throughput dan akurasi
  • Klasifikasi otomatis berlangsung dalam empat tahap
    1. Menghapus spam dan duplikasi, lalu memeriksa apakah laporan memenuhi kriteria penerimaan dan memiliki penjelasan yang jelas tentang kerentanan keamanan Chrome
    2. Memverifikasi proof-of-concept dan reproduksibilitas, mengujinya pada sistem operasi dan versi browser terkait, lalu melampirkan informasi seperti stack trace
    3. Menambahkan waktu pertama kali bug masuk dan tingkat keparahan
      • Panduan tingkat keparahan diperjelas agar mudah diterapkan secara otomatis
      • Developer dapat mengubah tingkat keparahan yang salah dan melengkapi informasi batas keamanan melalui SECURITY.md
    4. Menugaskan masalah secara otomatis ke komponen dan penanggung jawab yang tepat
  • Pengukuran yang presisi memang sulit, tetapi klasifikasi otomatis diperkirakan menghemat ratusan jam kerja developer setiap bulan
  • Alur kerja multi-agen diterapkan untuk memperbaiki kerentanan
    • Agen perbaikan menerima konteks per masalah dan menghasilkan beberapa kandidat patch
    • Agen kritik mengevaluasi kandidat yang paling sesuai dan membuat artefak yang dibutuhkan untuk review developer
    • Kedua agen melakukan iterasi mirip code review untuk memeriksa perilaku fungsional, gaya Chromium dan Google, serta kepatuhan pada konvensi kode lokal
    • Agen penulisan test memverifikasi test di seluruh platform dan konfigurasi yang didukung Chrome sebelum review developer, sehingga dapat menghemat waktu hingga beberapa minggu
  • Saat ini LLM menghasilkan kandidat perbaikan untuk sebagian besar kerentanan
    • Di Chrome 149 dan 150, sebanyak 1.072 bug keamanan diperbaiki, melampaui total 23 milestone sebelumnya
  • Big Sleep dan CodeMender, hasil kolaborasi dengan DeepMind dan Project Zero, diintegrasikan ke CI untuk memeriksa semua CL setiap 24 jam
    • Selama bulan Mei saja, lebih dari 20 kerentanan termasuk masalah kritis S1+ berhasil diblokir sebelum mencapai produksi

Memperpendek kesenjangan patch dan menerapkan pembaruan

  • Serangan N-day adalah periode kesenjangan patch ketika penyerang dapat merekayasa balik dan mengeksploitasi kode perbaikan setelah masuk ke repositori open source publik tetapi sebelum sampai ke pengguna
  • Biasanya butuh beberapa minggu sampai perbaikan yang masuk ke main tree mencapai channel Stable yang dipakai mayoritas pengguna
    • Bergantung pada tingkat keparahan, perbaikan langsung di-merge ke branch rilis Stable saat ini dan terus dipantau untuk crash atau regresi baru
    • Sejak milestone utama Chrome beralih ke siklus dua minggu, pembaruan keamanan diberikan setiap minggu
    • Untuk merespons kecepatan serangan berbasis AI, Google juga sedang menguji rilis keamanan dua kali seminggu
  • Semua bug keamanan yang mencapai Stable didokumentasikan secara publik, terlepas dari apakah ditemukan secara internal atau eksternal
    • Untuk menghilangkan bottleneck manual dan mempersingkat waktu dari penemuan hingga pengungkapan, Google sedang mengerjakan pembuatan otomatis release note dan deskripsi CVE dari patch
  • Sejak 2008, Chrome menggunakan pembaruan otomatis yang mengunduh dan menyiapkan binary baru di latar belakang, lalu menerapkannya pada restart berikutnya
    • Klasifikasi, perbaikan, pengujian, dan distribusi memerlukan 1–2 hari, tetapi menunggu sampai pengguna melakukan restart juga dapat sangat berkontribusi pada risiko eksploitasi N-day
    • Restart mengganggu pekerjaan dan perlu dijadwalkan terpisah, sehingga mudah ditunda pengguna
  • Fitur sedang dikembangkan agar beban restart tidak dibebankan ke pengguna
    • Patch dinamis memanfaatkan arsitektur multi-proses Chrome untuk mengganti proses anak latar belakang seperti Renderer dan GPU secara bertahap dengan binary baru, dengan tujuan menghilangkan kebutuhan restart browser penuh dalam sebagian besar kasus
    • Cara untuk menyimpan lebih banyak state secara lokal sedang ditinjau agar sesi dapat dipulihkan bahkan dalam situasi yang kompleks
    • Restart dilakukan secara otomatis pada saat pemulihan sesi penuh dapat dijamin
    • Chrome 150 mendeteksi keadaan saat semua jendela di macOS telah ditutup tetapi aplikasi masih berjalan di latar belakang, dan jika ada pembaruan yang menunggu, aplikasi akan restart otomatis
  • Dalam jangka panjang, targetnya adalah browser yang selalu terbaru dengan menggabungkan patch dinamis berkelanjutan dan restart otomatis pada waktu yang minim gangguan
  • Rekomendasi untuk administrator IT perusahaan adalah sebagai berikut
    • Gunakan kebijakan RelaunchNotification untuk menerapkan tahapan dari notifikasi hingga restart paksa setelah periode tertentu
    • Gunakan Chrome Extended Stable Channel di lingkungan sensitif yang perlu memverifikasi perubahan
    • Lacak versi browser secara menyeluruh dan kelola pembaruan secara rinci dengan dashboard independen-OS Chrome Enterprise Core atau Premium

Pertahanan C++ dan transisi ke Rust

  • Chrome menggunakan strategi ganda: menetralkan kerentanan C++ yang sudah ada saat runtime sekaligus beralih ke bahasa yang memory-safe untuk jangka panjang
  • Karena sebagian besar kode Chromium ditulis dalam C++, toolchain dan mitigasi runtime menjadi garis pertahanan pertama yang langsung digunakan
    • Kerentanan Use-After-Free (UAF) telah dikurangi melalui pustaka template standar yang diperkuat dan teknologi keluarga MiraclePtr
  • Roadmap pertahanan C++ terdiri dari tiga sumbu
    • Perluasan MiraclePtr dan MiracleObject
      • MiraclePtr diperluas ke Skia, ANGLE, Dawn, iterator C++, dan kontainer std::
      • MiracleObject menukar performa runtime lokal dengan keamanan temporal, dengan target menetralkan hingga 90% kerentanan UAF pada thread utama GPU
    • Transisi ke std::span
      • Struktur lama yang menggunakan pointer dan ukuran bersama-sama diganti dengan std::span yang dapat diperiksa compiler untuk menghilangkan akses out-of-bounds (OOB)
      • Sebanyak 97% kode internal Chrome dapat dikompilasi tanpa masalah dengan peringatan unsafe-buffer yang ketat, dan persyaratan ini juga sedang diperluas ke Skia, ANGLE, dan Dawn
    • Penguatan struktur dan alokasi
      • Checked math diterapkan pada perhitungan alokasi memori untuk memblokir jalur integer overflow
      • Partisi heap tambahan yang memisahkan tipe berisi pointer dan non-pointer secara ketat membuat eksploitasi UAF semakin sulit
  • Chrome memperkirakan mitigasi runtime C++ akan memberikan manfaat marjinal yang semakin menurun dalam beberapa tahun ke depan
    • Pemeriksaan runtime lebih mahal daripada jaminan saat compile time, dan bahkan binary C++ yang telah dimitigasi kuat pun tetap memerlukan sandbox ketat yang membatasi performa untuk mematuhi Rule of Two
  • Dalam jangka panjang, transisi ke Rust terus didorong
    • Rust flywheel: membangun SDK terpusat yang menyediakan API dan tool berbasis Chromium langsung untuk Rust agar menjadi pilihan rutin pada komponen baru
    • Menghilangkan area padat bug: mengganti secara strategis kode yang secara historis memiliki kepadatan bug tinggi seperti parser data kompleks, image codec, dan stack font
    • Modularisasi berprivilege tinggi: menulis modul baru dalam Rust agar fitur kompleks dapat berjalan di area berprivilege tinggi seperti proses browser tanpa biaya performa sandbox
  • Opsi untuk mengimplementasikan UI tingkat atas browser dengan HTML, CSS, dan TypeScript juga sedang dipertimbangkan guna semakin mengurangi ketergantungan pada framework C++ lama

Memblokir kerentanan sebelum pengiriman kode

  • Memindai seluruh codebase secara berkala saja sulit mengikuti kecepatan pengembangan Chrome, sehingga pemeriksaan AI ditempatkan dekat waktu pengiriman kode
  • Model pertahanan di CI dan commit queue (CQ) memeriksa perubahan secara otomatis
    • Mengusulkan perbaikan transisi std::span
    • Menandai dangling pointer
    • Memaksa keamanan operasi numerik
  • Kode yang aman secara terpisah pun bisa menjadi masalah keamanan potensial yang serius bila digabung dengan perubahan logika kecil di lokasi lain
  • Analisis semantik LLM berkelanjutan di dalam CQ menemukan interaksi halus atau kompleks yang luput dari analisis statis tradisional, lalu memblokirnya sebelum kode masuk ke tree

Ekosistem open source dan dependensi eksternal

  • Keamanan web bergantung bukan hanya pada Chrome sendiri, tetapi juga pada proyek open source dan kemampuan maintainer untuk merespons
    • Google bersama peserta lain menyumbangkan 12,5 juta dolar ke proyek Alpha-Omega agar maintainer memiliki alat dan dukungan untuk merespons laporan kerentanan dengan cepat
    • Google juga menjadi anggota pendiri proyek Akrites, yang bertujuan mengurangi beban maintainer upstream dengan menyediakan kanal pelaporan kerentanan terpusat dan tim respons insiden keamanan
  • Chromium dan proyek terkait seperti V8, BoringSSL, Skia, ANGLE, dan Dawn memiliki lebih dari 2.300 dependensi eksternal
    • Dari jumlah itu, sekitar 1.700 didistribusikan ke pengguna melalui berbagai produk seperti perangkat Android, platform edge computing, dan stack perusahaan cloud berskala besar
  • Pipeline pemeriksaan kerentanan otomatis mengumpulkan data dari feed internal Google, NVD milik pemerintah AS, dan OSV yang berfokus pada open source
  • Karena monitoring setelah kejadian saja masih bisa menyisakan kesenjangan risiko, Google mulai beralih ke pipeline pembaruan otomatis yang secara proaktif memperbarui semua dependensi eksternal Chrome ke versi upstream terbaru
  • Dalam proses otomatisasi, sinyal keamanan dari proyek seperti GOSSIP digunakan untuk mencerminkan risiko lain di ekosistem open source eksternal

Browser yang terlindungi secara berkelanjutan

  • Bertambahnya jumlah bug yang ditemukan dan diperbaiki dengan LLM bukanlah kegagalan; setiap bug yang diperbaiki berarti satu pijakan bagi penyerang berkurang
  • Menemukan dan memperbaiki saja tidak cukup; perbaikan juga harus didistribusikan dan diterapkan ke lingkungan pengguna sebelum dapat dieksploitasi penyerang
  • Dengan menggabungkan rilis yang lebih cepat, patch dinamis, restart otomatis pada waktu yang minim gangguan, dan pertahanan struktural, Chrome menargetkan perlindungan berkelanjutan tanpa mengganggu pengguna

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Opini Hacker News

  • Belakangan, saat pekerjaan sedang sibuk, saya banyak mencoba AI untuk optimasi performa, tetapi hampir tidak berguna untuk menentukan arah tingkat tinggi. Ketika saya menunjukkan bagian yang mencurigakan dalam kueri SQL, perbedaan performa sebelum dan sesudahnya nyaris tidak ada; waktu saya habis untuk saran yang tidak berguna, dan saya juga harus menghadapi orang-orang lain yang melempar keluaran AI mentah seolah-olah itu kontribusi bermakna
    Namun, mengimplementasikan perubahan yang saya temukan sendiri atau memindahkan join ke CTE menjadi jauh lebih mudah

    • Saran panjang yang tidak berguna benar-benar melelahkan. Seorang rekan memakai Claude untuk semua komunikasi asinkron, termasuk Slack, Jira, code review, dan email, sehingga bahkan pertanyaan sederhana pun dijawab dengan tembok teks raksasa yang cakupannya terus melebar
      Meski berulang kali memberi tahu alat AI “singkat saja”, “jawab hanya pertanyaannya”, “jangan beri informasi yang tidak diminta”, keluarannya tetap lebih banyak dari yang diperlukan, dan terlihat seperti upaya halus untuk mengonsumsi lebih banyak token
    • AI bekerja sangat baik jika kita menyediakan semua alat untuk memverifikasi hipotesisnya sendiri dan membiarkannya menjalankan seluruh siklus hidup secara berulang
    • Jika diberi keluaran EXPLAIN ANALYZE bersama kuerinya, AI tidak terlalu kesulitan mengoptimalkannya, jadi penilaian bahwa AI tidak berguna untuk optimasi kueri cukup mengejutkan
    • Perlu juga disebutkan model apa yang digunakan. Perbedaan antar model terdepan pun sangat besar; dalam praktiknya, melebihi selisih di benchmark, Opus 5.0 berada di kelas yang sama sekali berbeda dari Cursor Grok 4.5, dan sulit dibandingkan dengan Sonnet atau Composer
    • Kesalahannya adalah hanya menunjukkan kode dan menyuruhnya mencari optimasi performa. Harus diberikan profil performa, rencana kueri, dan data telemetri, lalu mengukur sebelum dan sesudah perubahan
      Dari teks kode saja, ukuran cache, kapasitas database, dan latensi jaringan tidak bisa diketahui, jadi konteks seperti ini perlu diberikan agar hasilnya lebih baik

  • Fakta kunci adalah bahwa pada Pwn2Own Berlin Mei lalu, Firefox sama sekali tidak membayar hadiah. Sejak 2007, hadiah selalu dibayarkan di setiap acara, tetapi tidak adanya satu pun kerentanan yang terkonfirmasi terlihat sebagai tanda bahwa kerentanan yang mudah kini hampir habis, dan model seperti ini memang berguna sampai tingkat tertentu

  • Saya percaya AI bisa memperbaiki banyak bug, tetapi penasaran dengan proses sebenarnya. Ada kemungkinan Google menerbitkan blog dan, selama beberapa sprint, manajer mendorong perbaikan bug untuk menunjukkan hasil adopsi AI kepada atasan, sehingga tim bekerja jauh lebih banyak dari biasanya

    • Google sudah puluhan tahun mengotomatisasi segalanya, dan fuzzer serta Project Zero juga bagian dari arus itu. Menambahkan LLM di atasnya, lalu memperbaiki harness dan alat pengembangan agar deteksi, klasifikasi, perbaikan, dan verifikasi tersambung end-to-end adalah langkah berikutnya yang wajar
      Performa LLM bergantung pada struktur iterasi yang dijalankannya, dan struktur itu bergantung pada kualitas verifier, jadi hal ini cukup bisa dijelaskan tanpa perlu aksi pamer kinerja dari manajer
    • Setiap kali alat analisis baru seperti analisis statis atau fuzzing diperkenalkan, jumlah bug yang baru ditemukan kemungkinan melonjak pada awalnya, lalu setelah ditangani, frekuensi temuan kembali menurun
    • Jika pada awal 2026 laporan bug di semua kategori meningkat hingga pada Maret jumlahnya lebih banyak daripada sepanjang 2025, penggunaan AI mungkin juga sangat meningkatkan jumlah bug itu sendiri. Misalnya, pada 2025 mereka menemukan 50 dan memperbaiki 45, tetapi pada 2026 menemukan 500 dan memperbaiki 450
    • AI dapat menafsirkan kode dengan cepat sehingga tumpukan bug diproses lebih cepat, dan code review serta security review juga menjadi lebih cepat, sehingga lebih banyak masalah ditemukan. Fenomena serupa tampaknya terjadi juga di kernel Linux, Windows, dan Apple
    • Dalam organisasi engineering Chrome, selama sekitar 10 tahun terakhir mungkin ada budaya lesu yang tidak memperbaiki bug kecuali para petinggi Google mengakui nilai bisnisnya. Sekarang saya curiga ada motivasi bisnis untuk memperbaiki bug demi menjual AI lebih banyak, lalu mengatribusikan jasanya kepada AI

  • AI seharusnya dimanfaatkan sebagai alat akselerasi, bukan dibiarkan bekerja sembarangan, tetapi para pengkritik tampaknya mencampuradukkan hal itu. Ini seperti straw man argument dengan marah kepada Excel karena ROI buruk, jadi daripada terus berdebat, saya lebih ingin diam-diam berbagi cara memakainya dengan benar dan efisien bersama orang-orang yang mau

    • Masalahnya, tidak jelas bagaimana AI seharusnya digunakan. Satu pihak bilang beri semua konteks dan biarkan berjalan sesukanya, pihak lain bilang pandu dengan cermat dan tinjau semua hasilnya, dan keduanya mendapat dukungan
      Jika dibiarkan, hasilnya memburuk hanya dalam beberapa iterasi; jika dipandu teliti, nilainya muncul, tetapi usaha yang diperlukan—terutama untuk tugas berulang—mirip dengan menulis kode sendiri
    • Pada kenyataannya, AI adalah alat yang mempercepat developer, tetapi jajaran manajemen dan laboratorium terdepan mempromosikannya seolah sebentar lagi kita bahkan tidak perlu membaca kode dan programmer akan lenyap
    • Karena AI kini menjadi isu keamanan internasional dan politik, mungkin ada banyak propaganda di bidang ini, dan perdebatan saat ini mengambil bentuk yang mirip dengan perdebatan politik 10 tahun lalu
    • Saya teringat perdebatan ketika saya menjelaskan kegunaan Bitcoin yang menyelesaikan masalah saya, tetapi semua orang bilang itu mustahil. Bukan berarti AI sama dengan Bitcoin
    • Perbaikan bug, peningkatan kode, dan refactoring adalah tugas yang paling cocok untuk AI. Saya berharap software lama akhirnya bisa dirapikan, tetapi orang-orang yang terus dituntut mengembangkan fitur baru yang makin cepat akan bersorak atau bersikap sinis tergantung lingkungan tempat mereka ditempatkan

  • Tidak diketahui berapa banyak perbaikan otomatis yang dibatalkan, berapa banyak bug baru yang dibuat, atau berapa tingkat positif palsu dari agen deteksi. Postingan itu hanya memuat angka keberhasilan dan sama sekali tidak membahas bagian yang bisa salah

    • Dalam praktiknya, mereka mempromosikan bahwa berkat AI mereka menemukan dan memperbaiki banyak bug, tetapi kemungkinan besar indikator kinerja utamanya adalah memperbaiki sebanyak mungkin bug dengan AI, sehingga AI menemukan item backlog lama dan mudah lalu manusia yang memperbaikinya
    • Tidak dijelaskan apakah lonjakan tajam jumlah bug yang ditemukan setelah M146 disebabkan oleh pengujian yang lebih baik, atau karena sejak awal lebih banyak bug baru yang masuk
    • Di Amazon ada banyak ruang untuk berbagi kisah sukses AI, tetapi tidak ada tempat untuk berbagi kegagalan atau kekecewaan. Wajar saja jika manajemen hanya mendengar cerita sepihak dan mengambil keputusan keliru tentang AI
    • Saya juga penasaran berapa banyak dari bug itu yang justru baru dibuat oleh AI
    • Dalam keamanan browser, munculnya sedikit bug baru mungkin bukan masalah besar. Serangan Pinkie Pie pada 2012 pun harus merangkai 6 bug, dan setelah itu muncul pula serangan yang harus merangkai lebih dari 10 bug; jadi memperbaiki satu saja di antaranya bisa melumpuhkan seluruh serangan
      Kalaupun saat memperbaiki 10 bug muncul 2 bug baru, selama bukan bug serius yang bisa dieksploitasi secara mandiri, keuntungan bersihnya besar. Serangan browser makin lama menuntut rantai kerentanan yang lebih panjang, sehingga manfaat AI untuk menemukan bug potensial sulit diabaikan
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • Ada kekhawatiran bahwa ke depannya Google akan menilai Chromium tidak lagi membutuhkan perburuan bug kolektif secara publik lalu menghentikan pengembangan terbuka. Jika begitu, keluarga Chromium saat ini pada dasarnya akan menjadi fork dari versi publik terakhir, dan karena tidak punya sumber daya pemeliharaan sebesar Chrome yang dibantu Gemini, tingkat kesulitan pengelolaan tiap fork bisa berbeda-beda

    • Google sudah sangat mengendalikan arah Chrome dan Chromium, jadi jika mementingkan web terbuka, sebaiknya gunakan Firefox

  • Kritik terhadap AI sering berfokus pada kategori sempit bahwa menghasilkan kode secara membabi buta itu buruk, dan poin itu mudah diterima. Namun pengujian adversarial, memvalidasi asumsi developer, saran refactoring, alat pengembangan kecil, coding dengan panduan, serta pelacakan dependensi dan perilaku dalam codebase besar berada di sisi lain dan bisa sangat terbantu
    Kritik yang berlaku untuk pembuatan kode secara membabi buta terlalu mudah dicampuradukkan dengan seluruh pemanfaatan seperti ini

    • AI adalah alat yang harus digunakan dengan cara tertentu. Kita harus menentukan arah yang diinginkan, dan tidak boleh berharap ia menyelesaikan semua masalah secara ajaib
    • AI memiliki kemampuan yang tidak bisa dimiliki semua individu, tetapi bukan berarti ia lebih pintar daripada pengguna; jika pengguna tidak mengoreksinya, ia sering mengambil keputusan yang salah

  • Sejak awal, yang penting adalah berapa banyak dari bug ini yang muncul dari kode yang ditulis LLM. Membuat bug 100 kali lebih banyak lalu memperbaiki bug 100 kali lebih banyak bukanlah sesuatu yang patut dibanggakan

    • Chrome adalah proyek berusia lebih dari 20 tahun, LLM baru muncul belakangan, dan kemunculan generator kode LLM juga tidak membuat code review dan pengujian menjadi longgar. Karena isu berusia 13 tahun juga disebut, kemungkinan besar tidak banyak pengembangan baru di area yang terdampak
      Karena ini proyek open source, kita juga bisa memeriksa sendiri apakah bug tersebut benar-benar dibuat oleh LLM
    • Jika coding makin banyak diserahkan ke AI, kemampuan manusia untuk mengidentifikasi bug potensial juga bisa menurun. Jika fitur yang ditulis AI kemudian diperiksa lagi oleh AI sebelum commit, kita makin mendekati dunia di mana bahkan kode yang menjalankan infrastruktur pun tidak bisa dipahami manusia
    • Melihat statistik Git, jumlah baris kode yang diajukan tidak berubah secara dramatis. Tidak semua orang menggabungkan kode AI berkualitas rendah begitu saja, dan organisasi besar yang sudah mapan pada umumnya tidak menggabungkan hasil vibe coding yang tidak bertanggung jawab
    • Jika diasumsikan AI bisa membuat kode dengan lebih sedikit bug, maka peningkatan bug baru 100 kali berarti kecepatan pengembangan fitur baru meningkat lebih dari 100 kali. Jika model bisa menemukan bug fatal berusia 13 tahun, dengan kemampuan yang sama semestinya ia juga bisa menulis kode baru yang tidak mengandung bug semacam itu
    • Mengabaikan sejarah dan skala proyek, lalu tanpa dasar membuat angka bahwa bug meningkat 100 kali dan menyebutnya sebagai masalah inti, adalah tidak rasional. Dalam topik AI, sikap yang memaksakan konstruksi realitas seperti ini tampak sangat sering

  • Saya penasaran apakah Chrome juga memperbaiki bug pelacakan perilaku yang mencoba melacak pengguna di mana pun dan apa pun yang mereka lakukan