Google ने AI की मदद से जून में Chrome के पिछले दो सालों से भी ज़्यादा बग ठीक किए

 (blog.google)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chrome Gemini-आधारित एजेंटों के साथ vulnerability खोजने, वर्गीकृत करने, ठीक करने, deploy करने और update लागू करने तक की प्रक्रिया को automate कर रहा है, और Chrome 149 व 150 में पिछले 23 milestones के कुल योग से भी ज़्यादा 1,072 security bugs ठीक किए गए
  • vulnerability detection system कई models, Chrome के CVE और Git history knowledge base, SECURITY.md, और एक अलग critique agent को जोड़ता है, और यह इंटरनेट व local system access को सख्ती से सीमित करने वाले environment में चलता है
  • automated triage spam और duplicates हटाता है, reproduction और stack trace इकट्ठा करता है, severity जैसी metadata जोड़ता है, और ownership assign करता है; अनुमान है कि इससे हर महीने डेवलपर्स के सैकड़ों घंटे का काम बचता है
  • fixes public होने के बाद exploitation तक के patch gap को घटाने के लिए हफ्ते में दो बार security releases का परीक्षण किया जा रहा है, और restart के बिना child processes बदलने वाली dynamic patching तथा macOS auto-restart विकसित किए गए हैं
  • सिर्फ़ individual bug fixes तक सीमित न रहकर Chrome MiraclePtr, std::span और Rust के ज़रिए memory safety बढ़ा रहा है, और submit के समय AI checks व 2,300 से अधिक external dependencies के automatic updates से vulnerabilities के प्रवेश को रोक रहा है

AI ने security bug lifecycle कैसे बदल दिया

  • LLM ने automated vulnerability detection को उस स्तर तक बढ़ा दिया है जो केवल इंसानी security expertise से संभालना मुश्किल था, और Chrome AI का उपयोग करके सैकड़ों security bugs को और तेज़ी से खोज व ठीक कर रहा है
  • जहाँ सामान्य feature bugs UI freeze जैसी समस्याएँ पैदा कर सकते हैं, वहीं security bugs का उपयोग attackers exploit के लिए कर सकते हैं, जिससे वे personal data पढ़ सकें या यूज़र की जानकारी के बिना कंप्यूटर को नियंत्रित कर सकें
  • security bugs को खोज, classification, fix, fixed Chrome build की deployment, browser restart और application के क्रम में संभाला जाता है, और लक्ष्य हर चरण को जितना संभव हो उतना छोटा करना है

vulnerability detection का विस्तार

  • Chrome security team ने कई वर्षों में LLM-आधारित detection techniques विकसित की हैं
    • 2023 में security fuzzing की reach और performance बढ़ाने का तरीका विकसित किया गया
    • 2024 में Project Zero के साथ Naptime विकसित किया गया, जिसने LLM को vulnerability research के specialized tools दिए
    • 2025 में DeepMind और Project Zero के साथ Big Sleep विकसित किया गया, और इस agent ने V8 JavaScript engine व graphics stack में bugs खोजे
  • 2026 की शुरुआत में बनाया गया Gemini agent harness व्यापक Chrome codebase में detection efficiency बढ़ाता है और false positives घटाता है
    • खोजा गया sandbox escape bug एक compromised renderer को browser को धोखा देकर local files पढ़ने दे सकता था, और यह code में 13 साल से अधिक समय तक मौजूद था
  • detection harness में ये capabilities जोड़ी गईं
    • open-weight और proprietary models, दोनों की strengths का उपयोग करने वाली model interoperability
    • सभी मौजूदा CVE और Chrome की पूरी Git history शामिल करने वाला knowledge base
    • trust boundaries और threat model को स्पष्ट रूप से बताने वाले SECURITY.md authoring guidelines
    • अलग context में SECURITY.md पढ़ने वाला critique agent
    • model non-determinism और समय के साथ होने वाले improvements को ध्यान में रखने के लिए codebase की repeated inspection
  • AI सामान्य इंटरनेट तक पहुँच के बिना locked machines पर केवल stored source code का analysis करता है
    • सभी network requests को intercept करके application और destination-based allowlist लागू की जाती है
    • models को unrestricted mode में नहीं चलाया जाता, और sub-agents के system changes तथा निर्धारित source directories के बाहर file access को सीमित किया जाता है
  • AI detection मौजूदा security testing का replacement नहीं है
    • fuzzing खास तौर पर उन bugs के लिए प्रभावी है जो code के दूरस्थ हिस्सों के long-range interactions या कई seemingly unrelated operations के combinations से पैदा होते हैं
  • external researchers को Chrome Vulnerability Reward Program के ज़रिए कठिन और high-impact vulnerabilities खोजते रहने के लिए इनाम मिलता है
    • 2026 की शुरुआत में सभी प्रकार की reports बढ़ीं, और मार्च में 2025 के पूरे साल से ज़्यादा bug reports प्राप्त हुईं
    • इसके अनुसार VRP में बदलाव किया गया ताकि internal detection results के ऊपर अतिरिक्त मूल्य देने वाली reports पर ध्यान रहे और automated processing pipeline आसानी से जिन reports को ले सके उन पर फ़ोकस किया जा सके

automated triage और multi-agent fixing

  • पहले एक security report को triage करने में 5 मिनट से 30 मिनट या उससे अधिक लगते थे और यह मुख्यतः इंसानी expertise पर निर्भर था, लेकिन अब rule-based systems और AI को जोड़कर throughput और accuracy बढ़ाई जा रही है
  • automated triage चार चरणों में चलता है
    1. spam और duplicates हटाए जाते हैं, intake criteria पूरे होते हैं या नहीं यह देखा जाता है, और यह जाँचा जाता है कि Chrome security vulnerability का स्पष्ट विवरण मौजूद है या नहीं
    2. proof of concept और reproducibility की पुष्टि की जाती है, संबंधित OS और browser version पर परीक्षण किया जाता है, और stack trace जैसी जानकारी जोड़ी जाती है
    3. bug पहली बार कब आया और उसकी severity क्या है, यह जोड़ा जाता है
      • automatic application को आसान बनाने के लिए severity guidelines को स्पष्ट रूप से व्यवस्थित किया गया है
      • developers गलत severity rating बदल सकते हैं और SECURITY.md से security boundary जानकारी को पूरक बना सकते हैं
    4. issue को सही component और owner को automatically assign किया जाता है
  • सटीक मापना कठिन है, लेकिन अनुमान है कि automated triage से हर महीने सैकड़ों घंटे का developer work बचता है
  • vulnerability fixes में multi-agent workflow लागू किया गया है
    • fix agent issue-specific context लेकर कई candidate patches बनाता है
    • critique agent सबसे उपयुक्त candidate का मूल्यांकन करता है और developer review के लिए ज़रूरी artifacts तैयार करता है
    • दोनों agents code review जैसी iterative प्रक्रिया चलाकर functional behavior, Chromium और Google style, तथा local code conventions के पालन की जाँच करते हैं
    • test-writing agent developer review से पहले Chrome के supported platforms और configurations में tests verify करता है, जिससे कई हफ्तों तक का समय बच सकता है
  • अभी अधिकांश vulnerabilities के लिए LLM candidate fixes generate कर रहा है
    • Chrome 149 और 150 में 1,072 security bugs ठीक किए गए, जो पिछले 23 milestones के कुल योग से भी अधिक है
  • DeepMind और Project Zero के साथ बनाया गया Big Sleep और CodeMender CI में integrate हैं और हर 24 घंटे में सभी CL की जाँच करते हैं
    • मई महीने में ही critical S1+ issues सहित 20 से अधिक vulnerabilities production तक पहुँचने से पहले रोक दी गईं

patch gap को छोटा करना और updates लागू करना

  • fix code public open source repository में आने के बाद और users तक deploy होने से पहले attackers उसे reverse-engineer करके exploit कर सकते हैं; इस N-day attack अवधि को patch gap कहा जाता है
  • main tree में landed fixes को अधिकांश users द्वारा उपयोग किए जाने वाले Stable channel तक पहुँचने में आमतौर पर कई हफ्ते लगते हैं
    • severity के आधार पर fixes को मौजूदा Stable release branch में सीधे merge किया जाता है और नए crashes या regressions की लगातार निगरानी की जाती है
    • प्रमुख Chrome milestones को 2-सप्ताह cadence में बदलने के बाद हर हफ्ते security updates दिए जा रहे हैं
    • AI-आधारित attacks की गति के जवाब में हफ्ते में दो बार security releases का भी परीक्षण किया जा रहा है
  • Stable तक पहुँचे सभी security bugs को, चाहे वे internally मिले हों या externally, public documentation में दर्ज किया जाता है
    • manual bottlenecks हटाने और discovery से disclosure तक का समय घटाने के लिए patches से release notes और CVE descriptions automatically generate करने पर काम चल रहा है
  • Chrome 2008 से automatic updates का उपयोग कर रहा है, जिसमें नया binary background में डाउनलोड होकर तैयार रहता है और अगली restart पर लागू होता है
    • triage, fixing, testing और deployment में 1–2 दिन लग सकते हैं, लेकिन users के restart करने तक का इंतज़ार भी N-day exploitation risk में बड़ा योगदान दे सकता है
    • restart काम में रुकावट डालता है और अलग से समय निकालना पड़ता है, इसलिए users इसे टाल देते हैं
  • users पर restart का बोझ डाले बिना updates लागू करने के लिए features विकसित किए जा रहे हैं
    • dynamic patching Chrome की multi-process architecture का उपयोग करके Renderer और GPU जैसे background child processes को नए binaries से क्रमशः बदलता है, और लक्ष्य अधिकांश मामलों में पूरे browser restart की ज़रूरत खत्म करना है
    • जटिल स्थितियों में भी session restore हो सके, इसके लिए अधिक state को local रूप से store करने के तरीकों की समीक्षा की जा रही है
    • जब full session restoration सुनिश्चित हो सके, तब automatic restart किया जाता है
    • Chrome 150 macOS पर उस स्थिति को detect करता है जहाँ सभी windows बंद हो चुकी हों लेकिन app background में बना रहे, और pending update होने पर auto-restart करता है
  • लंबी अवधि में लगातार dynamic patching और कम बाधा वाले समय पर automatic restart को मिलाकर हमेशा up-to-date browser बनाना लक्ष्य है
  • enterprise IT admins के लिए सिफारिशें इस प्रकार हैं
    • RelaunchNotification policy का उपयोग करके notifications से लेकर तय समय के बाद forced restart तक चरणबद्ध रूप से लागू करें
    • उन sensitive environments में जहाँ changes को validate करना ज़रूरी हो, Chrome Extended Stable Channel का उपयोग करें
    • Chrome Enterprise Core या Premium के OS-independent dashboard से पूरे browser version fleet को track करें और updates को granular तरीके से manage करें

C++ defenses और Rust transition

  • Chrome एक दोहरी रणनीति अपनाता है: मौजूदा C++ vulnerabilities को runtime पर निष्प्रभावी करना और लंबी अवधि में memory-safe languages की ओर बढ़ना
  • क्योंकि Chromium code का अधिकांश हिस्सा C++ में है, इसलिए toolchain और runtime mitigations तत्काल पहली defense line हैं
    • hardened standard template library और MiraclePtr जैसे techniques से Use-After-Free (UAF) vulnerabilities कम की गई हैं
  • C++ defense roadmap तीन हिस्सों में बँटा है
    • MiraclePtr और MiracleObject का विस्तार
      • MiraclePtr को Skia, ANGLE, Dawn, C++ iterators और std:: containers तक विस्तारित किया जा रहा है
      • MiracleObject का लक्ष्य local runtime performance को temporal safety के साथ trade करके GPU main-thread UAF vulnerabilities के अधिकतम 90% तक को निष्प्रभावी करना है
    • std::span transition
      • pointers और size को साथ लेकर चलने वाली पुरानी structures को compiler-checked std::span से बदला जा रहा है ताकि out-of-bounds (OOB) access हट सके
      • Chrome के अपने code का 97% हिस्सा strict unsafe-buffer warnings के साथ बिना समस्या compile हो रहा है, और requirements को Skia, ANGLE और Dawn तक भी बढ़ाया जा रहा है
    • structure और allocation hardening
      • memory allocation calculations पर checked math लागू करके integer overflow paths रोके जा रहे हैं
      • pointer-containing और non-pointer types के बीच सख्त अलगाव करने वाली अतिरिक्त heap partitioning से UAF exploitation को कठिन बनाया जा रहा है
  • Chrome का मानना है कि आने वाले कुछ वर्षों में C++ runtime mitigations की marginal returns घटेंगी
    • runtime checks की लागत compile-time guarantees से अधिक होती है, और काफ़ी mitigated C++ binaries को भी Rule of Two का पालन करने के लिए performance-limiting सख्त sandboxing की आवश्यकता होती है
  • लंबी अवधि में Rust transition को आगे बढ़ाया जा रहा है
    • Rust flywheel: Chromium-based APIs और tools को सीधे Rust में उपलब्ध कराने वाला central SDK बनाया जा रहा है ताकि नए components में इसे नियमित विकल्प बनाया जा सके
    • bug-dense areas को हटाना: complex data parsers, image codecs और font stacks जैसे ऐतिहासिक रूप से bug-dense code को रणनीतिक रूप से replace किया जा रहा है
    • high-privilege modularization: नए modules को Rust में लिखकर browser process जैसे high-privilege क्षेत्रों में भी sandbox performance cost के बिना complex functionality चलाने का लक्ष्य है
  • browser की top-level UI को HTML, CSS और TypeScript में लागू करके मौजूदा C++ framework dependencies को और घटाने पर भी विचार किया जा रहा है

code submit होने से पहले vulnerabilities रोकना

  • पूरे codebase की periodic scanning अकेले Chrome की तेज़ development speed के साथ तालमेल नहीं रख पाती, इसलिए AI checks को code submit समय के काफ़ी करीब रखा जा रहा है
  • CI और commit queue (CQ) का defense model changes को automatically inspect करता है
    • std::span transition fixes सुझाता है
    • dangling pointers को mark करता है
    • numeric operation safety enforce करता है
  • जो code अपने आप में सुरक्षित दिखता है, वह किसी दूसरी जगह के छोटे logic change के साथ मिलकर गंभीर संभावित security issue बन सकता है
  • CQ के भीतर लगातार चलने वाला LLM semantic analysis उन subtle या complex interactions को पकड़ता है जिन्हें traditional static analysis छोड़ देता है, और code को tree में आने से पहले रोक देता है

open source ecosystem और external dependencies

  • web security सिर्फ़ Chrome पर नहीं, बल्कि open source projects और maintainers की response capacity पर भी निर्भर करती है
    • Google ने maintainers को vulnerability reports पर तेज़ी से प्रतिक्रिया देने के लिए tools और support उपलब्ध कराने हेतु Alpha-Omega project में अन्य प्रतिभागियों के साथ 12.5 million डॉलर दान किए
    • यह Akrites project का founding member भी है, जिसका लक्ष्य central vulnerability reporting desk और security incident response team देकर upstream maintainers का बोझ कम करना है
  • Chromium और V8, BoringSSL, Skia, ANGLE, Dawn जैसे संबंधित projects में 2,300 से अधिक external dependencies हैं
    • इनमें से लगभग 1,700 विभिन्न products के माध्यम से users तक पहुँचती हैं, जिनमें Android devices, edge computing platforms और बड़े cloud company stacks शामिल हैं
  • automated vulnerability scanning pipeline Google internal feeds, अमेरिकी सरकार के NVD और open source-केंद्रित OSV से data एकत्र करती है
  • केवल बाद की monitoring से risk gap बना रह सकता है, इसलिए सभी Chrome external dependencies को latest upstream versions में proactively refresh करने वाली automatic update pipeline की ओर बढ़ना शुरू किया गया है
  • automation प्रक्रिया में GOSSIP जैसे projects के safety signals का उपयोग करके बाहरी open source ecosystem के अन्य risks को भी शामिल किया जाता है

लगातार सुरक्षित रहने वाला browser

  • LLM से खोजे और ठीक किए जाने वाले bugs की संख्या बढ़ना विफलता नहीं है; हर fixed bug attackers के लिए एक संभावित foothold कम कर देता है
  • सिर्फ़ discovery और fixing काफ़ी नहीं हैं; attackers के exploit करने से पहले fixes को deploy करना और user environments में लागू करना भी ज़रूरी है
  • तेज़ releases, dynamic patching, कम बाधा वाले automatic restarts और structural defenses को मिलाकर, लक्ष्य ऐसा लगातार सुरक्षित Chrome बनाना है जो users को बाधित किए बिना उनकी रक्षा करे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • हाल में काम बहुत व्यस्त रहने के दौरान मैंने performance optimization के लिए AI का काफी इस्तेमाल किया, लेकिन उच्च-स्तरीय दिशा तय करने में यह लगभग बेकार रहा। SQL query में संदिग्ध हिस्से दिखाने पर भी पहले और बाद के performance में लगभग कोई फर्क नहीं था, बेकार सुझावों में समय बर्बाद हुआ, और दूसरों के बिना तराशे AI output को मानो कोई सार्थक योगदान हो, ऐसे झेलना भी पड़ा
    हालांकि, जिन बदलावों को मैंने खुद ढूंढा उन्हें लागू करना या joins को CTE में ले जाना काफी आसान हो गया

    • बेकार लंबे-चौड़े सुझाव सचमुच थका देने वाले हैं। एक सहकर्मी Slack, Jira, code review और email सहित हर asynchronous communication में Claude का इस्तेमाल करता है, इसलिए साधारण सवालों का भी जवाब लगातार फैलते हुए विशाल text wall की तरह आता है
      AI tool से बार-बार “संक्षेप में”, “सिर्फ सवाल का जवाब दो”, “अनुरोध न की गई जानकारी मत दो” कहने पर भी वह जरूरत से ज्यादा output देता है, और यह token ज्यादा खर्च कराने की सूक्ष्म कोशिश जैसा लगता है
    • अगर AI को अपनी hypothesis की जांच करने के लिए सारे tools दे दिए जाएं और पूरे lifecycle को बार-बार चलाने दिया जाए, तो यह हैरान कर देने वाली तरह से अच्छा काम करता है
    • query के साथ EXPLAIN ANALYZE output दे दिया जाए, तो AI को optimize करने में खास दिक्कत नहीं होती, इसलिए query optimization में बेकार होने वाली राय कुछ अप्रत्याशित लगती है
    • यह भी बताना चाहिए कि कौन-सा model इस्तेमाल किया गया। frontier models के बीच भी फर्क बहुत बड़ा है, और benchmark के अंतर से भी ज्यादा, व्यवहार में Opus 5.0, Cursor Grok 4.5 से बिल्कुल अलग स्तर का है, और Sonnet या Composer से भी तुलना करना मुश्किल है
    • सिर्फ code दिखाकर performance optimization ढूंढने को कहना ही गलत था। performance profile, query plan, telemetry data देना चाहिए और बदलाव से पहले व बाद का मापन करना चाहिए
      सिर्फ code text से cache size, database capacity या network latency का पता नहीं चलता, इसलिए बेहतर नतीजों के लिए यह context देना जरूरी है

  • पिछले मई बर्लिन के Pwn2Own में Firefox ने कोई prize money नहीं दी—यही मुख्य संदर्भ है। 2007 के बाद हर event में prize money दी जाती रही थी, इसलिए एक भी confirmed vulnerability न मिलना इस बात का संकेत लगता है कि अब आसान vulnerabilities लगभग खत्म हो चुकी हैं, और यह मॉडल कुछ हद तक उपयोगी है

  • मुझे यकीन है कि बहुत-से bugs ठीक किए जा सकते हैं, लेकिन असली प्रक्रिया जानने की जिज्ञासा है। संभव है कि Google ने blog post निकाली हो और managers को ऊपर AI adoption के नतीजे दिखाने के लिए कुछ sprints तक bug fixing बढ़ाने को कहा गया हो, जिससे टीम ने सामान्य से कहीं ज्यादा काम किया हो

    • Google दशकों से हर चीज़ को automate करता आया है, और fuzzers तथा Project Zero भी उसी धारा का हिस्सा हैं। उसके ऊपर LLM जोड़ना, harness और dev tools सुधारना, और detection·classification·fixing·verification को end-to-end जोड़ना अगला स्वाभाविक कदम है
      LLM की performance उस iteration structure पर निर्भर करती है जिसमें उसे चलाया जाता है, और वह structure verifier की quality पर निर्भर करता है, इसलिए manager की दिखावे वाली उपलब्धियों के बिना भी यह पूरी तरह समझाया जा सकता है
    • हर बार जब static analysis या fuzzing जैसे नए analysis tools लाए जाते हैं, शुरुआत में नए मिले bugs की संख्या तेजी से बढ़ती है, और उन्हें संभालने के बाद खोजे जाने की दर फिर से घट जाती है
    • अगर 2026 की शुरुआत में हर category में bug reports बढ़ जाएं और मार्च तक वे 2025 के पूरे साल से ज्यादा हो जाएं, तो AI ने bugs की कुल संख्या भी काफी बढ़ा दी हो सकती है। मसलन, 2025 में 50 मिले और 45 ठीक हुए, लेकिन 2026 में 500 मिले और 450 ठीक हुए—ऐसी तस्वीर हो सकती है
    • AI code को तेजी से समझकर bug backlog को जल्दी निपटा सकता है, और code तथा security review भी तेज कर सकता है, जिससे ज्यादा समस्याएं मिलती हैं। Linux kernel सहित Windows और Apple में भी कुछ ऐसा ही होता दिख रहा है
    • हो सकता है Chrome engineering organization में पिछले लगभग 10 साल से ऐसी निष्क्रिय संस्कृति रही हो जिसमें Google के वरिष्ठ लोग व्यावसायिक मूल्य न मानें तो bugs ठीक ही न किए जाएं। अब AI को और बेचने के लिए bugs ठीक करने और उसका श्रेय AI को देने की व्यावसायिक प्रेरणा पैदा हुई हो—ऐसा संदेह है

  • AI को बिना सोचे-समझे काम पर छोड़ने के बजाय acceleration tool की तरह इस्तेमाल करना चाहिए, लेकिन आलोचक शायद दोनों बातों को मिला देते हैं। यह कुछ वैसा strawman है जैसे ROI खराब होने पर Excel पर गुस्सा करना; इसलिए बहस करने से बेहतर है कि जो लोग इसे सच में कुशलता से इस्तेमाल करना चाहते हैं, उनके साथ चुपचाप इसके तरीके साझा किए जाएं

    • असल में AI को कैसे इस्तेमाल किया जाए, यही साफ नहीं है। एक पक्ष कहता है कि सारा context दो और इसे खुलकर चलने दो, दूसरा कहता है कि बारीकी से guide करो और हर result की review करो—और दोनों पक्षों को समर्थन मिलता है
      इसे यूं ही छोड़ दें तो कुछ iterations बाद नतीजे खराब हो जाते हैं; बारीकी से guide करें तो value मिलती है, लेकिन वह मेहनत, खासकर जब repetitive work हो, सीधे code लिखने जितनी ही लगती है
    • हकीकत में AI developers को तेज़ करने वाला tool है, लेकिन management और frontier labs ऐसे प्रचार कर रहे हैं मानो जल्द ही code पढ़ने की भी जरूरत नहीं रहेगी और programmers गायब हो जाएंगे
    • अब जब AI अंतरराष्ट्रीय सुरक्षा और राजनीति का भी मुद्दा बन चुका है, तो इस क्षेत्र में propaganda काफी हो सकता है, और मौजूदा बहस का रूप 10 साल पहले की राजनीतिक बहसों जैसा लगता है
    • इससे Bitcoin वाली बहस याद आती है, जहां मैं बताता था कि उसने मेरी समस्या कैसे हल की, और सब कहते थे कि यह असंभव है। इसका मतलब यह नहीं कि AI, Bitcoin जैसा ही है
    • bug fixing, code improvement, refactoring ऐसे काम हैं जिन पर AI सबसे ज्यादा फिट बैठता है। उम्मीद थी कि आखिरकार पुराने software को संवार सकेंगे, लेकिन जो लोग लगातार तेज़ होती नई feature development की मांगों में फंसे रहे, वे अपने तैनात environment के हिसाब से या तो खुश होंगे या निंदक

  • यह पता नहीं है कि ऑटोमैटिक fixes में से कितने वापस रोलबैक किए गए, कितने नए bugs बने, और detection agents की false positive rate कितनी है। पोस्ट में सिर्फ सफलता के आंकड़े हैं, और क्या गलत हो सकता है इस पर कुछ भी नहीं है

    • असल में वे यह प्रचार कर रहे हैं कि AI की वजह से बहुत सारे bugs मिले और ठीक हुए, लेकिन संभव है कि AI से जितने हो सकें उतने bugs fix करना ही मुख्य performance metric बन गया हो, और पुराने व आसान backlog items को AI से ढूंढ़कर इंसानों ने ठीक किया हो
    • यह नहीं बताया गया कि M146 के बाद bug discovery में तेज़ बढ़ोतरी बेहतर testing की वजह से है, या शुरू से ही ज़्यादा नए bugs शामिल किए गए थे
    • Amazon में AI success stories साझा करने की बहुत जगहें हैं, लेकिन failures या disappointments साझा करने की कोई जगह नहीं है। यह स्वाभाविक है कि management सिर्फ एकतरफा कहानी सुनकर AI के बारे में गलत फैसले ले
    • यह भी जानने की जिज्ञासा है कि उन bugs में से AI ने नए कितने बनाए
    • browser security में थोड़ा-बहुत नए bugs बनना शायद बहुत बड़ी समस्या न हो। 2012 के Pinkie Pie attack में भी 6 bugs को chain करना पड़ा था, और उसके बाद 10 से ज़्यादा bugs को जोड़ने वाले attacks भी आए, इसलिए उनमें से सिर्फ एक को ठीक कर देने पर पूरा attack निष्प्रभावी हो जाता है
      अगर 10 bugs ठीक करते हुए 2 नए बना भी दिए जाएँ, तो भी जब तक वे अपने-आप exploit हो सकने वाले गंभीर bugs न हों, कुल मिलाकर फायदा ही है। browser attacks समय के साथ और लंबी vulnerability chain मांग रहे हैं, इसलिए AI से संभावित bugs ढूंढ़ने के फायदे को नज़रअंदाज़ करना मुश्किल है
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • आगे चलकर यह चिंता है कि Google यह न मान ले कि Chromium में अब सार्वजनिक collective bug hunting की ज़रूरत नहीं है, और public development बंद कर दे। तब मौजूदा Chromium variants आख़िरी public version के लगभग forks बन जाएँगे, और Gemini की मदद पाने वाले Chrome जितने maintenance resources न होने के कारण हर fork की maintenance कठिनाई अलग हो सकती है

    • Google पहले से ही Chrome और Chromium की दिशा पर कड़ा नियंत्रण रखता है, इसलिए अगर open web महत्वपूर्ण है, तो Firefox इस्तेमाल करना चाहिए

  • AI की आलोचना अक्सर सिर्फ इस संकीर्ण बात पर केंद्रित रहती है कि कोड को अंधाधुंध generate करना बुरा है, और इस बात को मान लेना आसान है। लेकिन adversarial testing, developer assumptions की verification, refactoring suggestions, छोटे developer tools, guided coding, और बड़े codebase में dependencies व behavior tracing दूसरी तरफ़ हैं, जहाँ इससे बड़ी मदद मिल सकती है
    blind code generation पर लागू होने वाली आलोचना को इन सारे उपयोगों के साथ बहुत आसानी से मिला दिया जाता है

    • AI एक tool है, जिसे एक खास तरीके से इस्तेमाल करना होता है। इसे दिशा देनी पड़ती है; यह उम्मीद नहीं करनी चाहिए कि यह हर समस्या को जादू की तरह हल कर देगा
    • AI में ऐसी क्षमताएँ हैं जो हर व्यक्ति के पास नहीं हो सकतीं, लेकिन यह उपयोगकर्ता से ज़्यादा बुद्धिमान नहीं है, और अगर उपयोगकर्ता इसे ठीक न करे तो यह अक्सर गलत फैसले लेता है

  • मूल सवाल यह है कि आखिर इन bugs में से कितने LLM द्वारा लिखे गए code से पैदा हुए थे। 100 गुना ज़्यादा bugs बनाना और 100 गुना ज़्यादा bugs ठीक करना कोई शेखी की बात नहीं है

    • Chrome 20 साल से ज़्यादा पुराना project है, और LLM अभी हाल में आए हैं; सिर्फ LLM code generators आ गए, इससे code review और testing ढीले नहीं कर दिए गए। 13 साल पुराने issue का ज़िक्र भी हुआ है, इसलिए संभव है कि प्रभावित हिस्से में हाल का development बहुत ज़्यादा न रहा हो
      यह open source project है, इसलिए यह भी सीधे देखा जा सकता है कि bug वास्तव में LLM ने बनाया था या नहीं
    • अगर coding धीरे-धीरे AI को सौंपी जाती रही, तो इंसानों की potential bugs पहचानने की क्षमता भी घट सकती है। अगर AI द्वारा लिखी functionality को commit से पहले फिर AI से ही जँचवाया जाए, तो हम ऐसी दुनिया के क़रीब पहुँचेंगे जहाँ infrastructure चलाने वाला code भी इंसानों की समझ से बाहर हो जाएगा
    • Git stats देखने पर submitted code lines में कोई नाटकीय बदलाव नहीं दिखता। हर कोई low-quality AI code को जस का तस merge नहीं कर रहा, और मौजूदा बड़े organizations आम तौर पर गैर-जिम्मेदार vibe coding के नतीजों को merge नहीं करते
    • अगर मान लें कि AI कम bugs के साथ code लिख सकता है, तो नए bugs का 100 गुना बढ़ना यह दर्शाएगा कि new feature development speed 100 गुना से भी ज़्यादा तेज़ हो गई। अगर model 13 साल पुराना critical bug ढूंढ़ सकता है, तो उसी क्षमता से वह ऐसा नया code भी लिख सकता है जिसमें ऐसे bugs न हों
    • project के इतिहास और scale को नज़रअंदाज़ करके बिना आधार के bugs के 100 गुना बढ़ने का आंकड़ा बना देना और उसे मुख्य समस्या कहना तर्कसंगत नहीं है। AI के विषय में वास्तविकता को ज़बरदस्ती गढ़ने की प्रवृत्ति असामान्य रूप से ज़्यादा दिखती है

  • यह भी जानना है कि Chrome जहाँ-जहाँ, जो-जो करे, उपयोगकर्ताओं को track करने की कोशिश करने वाले behavior-tracking bugs भी ठीक किए गए या नहीं