Chrome के Prompt API पर Mozilla का विरोध

 (github.com/mozilla)
6 पॉइंट द्वारा GN⁺ 2026-05-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ब्राउज़र के भीतर के language model को web API के रूप में एक्सपोज़ करने वाला Prompt API सामान्य रूप में उपयोगी हो सकता है, लेकिन यह model-specific behavior के हिसाब से implementation को बढ़ावा देकर interoperability risk बढ़ाता है
  • अगर डेवलपर Edge के Phi-4-mini जैसी किसी खास implementation के लिए prompts और features को tune करते हैं, तो दूसरे browsers या models में quality degradation या site access block होने की स्थिति आ सकती है
  • Mozilla का मानना है कि इसे सीधे web API के रूप में ship करने के बजाय userland validation से और गुज़रना चाहिए, और वह trial web extension API तथा Web Machine Learning group के web extension proposal को शुरुआती feedback path के रूप में देखता है
  • अगर system prompts किसी खास model के quirk के हिसाब से फैलने लगें, तो नए models भी खराब दिख सकते हैं, और browsers पर Google model या quirk-compatible model शामिल करने का दबाव बन सकता है
  • Chrome पक्ष ने JSON schema·regex-आधारित response constraints, WebML CG discussion, और alternative model experiments जैसी mitigation पेश की हैं, लेकिन Mozilla की Prompt API स्थिति negative के रूप में दर्ज है

Prompt API पर Mozilla का नकारात्मक आकलन

  • Prompt API को Blink के intent-to-prototype के बाद Mozilla standards-positions में समीक्षा की गई, और explainer webmachinelearning/prompt-api README से लिंक है
  • Mozilla का feedback Writing Assistance APIs #1067 से लगभग समान है; सामान्य रूप वाला Prompt API उपयोगी हो सकता है, लेकिन यह model-specific behavior को बढ़ावा देकर interoperability risk बढ़ाता है
  • डेवलपर किसी खास model के लिए prompts और features को tune कर सकते हैं, और अगर वे Edge के Phi-4-mini जैसी implementation को target करें, तो दूसरे browsers या models में गुणवत्ता गिर सकती है या site access block हो सकता है
  • इसे सीधे web API के रूप में ship करने के बजाय userland में अधिक समय तक validate किया जाना चाहिए, और Mozilla का trial web extension API तथा Web Machine Learning group का web extension proposal शुरुआती feedback इकट्ठा करने के रास्ते हैं
  • संबंधित चर्चाओं और #1067 के आधार पर Prompt API की स्थिति negative के रूप में चिह्नित की गई है

Origin Trial की बजाय Web Extension को प्राथमिकता देने की वजह

  • model selection और standardization timing

    • model hub से सटीक model चुनने की क्षमता को अहम माना गया है, क्योंकि यह page-level functionality और browser द्वारा किसी खास model को न चुनने, दोनों से जुड़ी है
    • यह क्षमता तेजी से बदलते क्षेत्र की implementation details पर निर्भर करती है, इसलिए इसे अभी standardize करने के लिए तैयार नहीं माना गया
    • Extension, मौजूदा proposal scope से आगे बढ़कर वास्तविक usage patterns को जल्दी explore करने और तीनों engines के बीच अभी स्थिर न हुई semantics को मिलाकर ship करने की coordination cost के बिना cross-browser features को प्रयोग में लाने का कम-लागत तरीका देता है

  • उपयोगकर्ता को दिखने वाली boundary

    • Add-on install करना उपयोगकर्ता के लिए संकेत है कि वह सामान्य web functionality की सीमा से बाहर जा रहा है; यहां shared cross-origin storage इसका उदाहरण है
    • यह सोच दूसरे संदर्भ में WebMIDI Add-On Gated position addition #704 जैसी तर्क-रेखा से मिलती है
    • यह extension proposal page पर Prompt-जैसा API एक्सपोज़ करता है और local inference व developer-specified model का उपयोग करके shared model store और शुरुआती user feedback हासिल करने की संरचना देता है

एक ही model पर जम जाने का जोखिम

  • system prompts और model quirks

    • system prompts अक्सर इस्तेमाल हो रहे model के quirk के हिसाब से बार-बार tune किए जाते हैं
    • home automation निर्देश बनाने वाले एक system prompt में Gemini model शुरू में बहुत अमेरिकी शैली में जवाब दे रहा था, जो ब्रिटिश speaker voice के अनुरूप नहीं था
    • जब system prompt में जोड़ा गया कि वह ब्रिटिश voice में बोले, तो उसने “a'waight guv'nor apples and pears” जैसी अमेरिकी-शैली की ब्रिटिश नकल की, और उसे अधिक वास्तविक ब्रिटिश अंदाज़ के करीब लाने के लिए अतिरिक्त tuning करनी पड़ी
    • एक model के लिए किया गया correction दूसरे model में overcorrection बन सकता है, और branded voice या ऐसे output formats में समस्या बढ़ती है जिन्हें JSON schema या regex से व्यक्त नहीं किया जा सकता

  • नए models और browser updates का बोझ

    • अगर मौजूदा models के quirks के हिसाब से tuned system prompts व्यापक हो जाएं, तो बेहतर नए competing models भी डेवलपर्स और उपयोगकर्ताओं को खराब लग सकते हैं
    • Mozilla और Apple ऐसी स्थिति में आ सकते हैं जहां interoperability के लिए उन्हें Google model को license करना पड़े या Google model के quirks के साथ compatible model शामिल करना पड़े
    • इसी वजह से Chrome के लिए भी अपने model updates करना मुश्किल हो सकता है

  • model ID detection और browser branching

    • डेवलपर LanguageModel.create() से model बना सकते हैं और model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') जैसे prompt से model ID, नाम, version और origin company पूछ सकते हैं
    • एक उदाहरण response है 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • डेवलपर किसी खास model के लिए system prompt bundles बना सकते हैं, और unknown models को block कर सकते हैं या उपयोगकर्ता को बता सकते हैं कि output quality कम हो सकती है
    • इसे उस early-2000s code branching की वापसी के रूप में देखा गया है जिससे बचना चाहिए

Google policy और model neutrality की समस्या

  • Chrome docs के अनुसार Prompt API का उपयोग करने से पहले Google Generative AI Prohibited Uses Policy को acknowledge करना होता है
  • इस policy के कुछ हिस्से कानून से आगे के दायरे को कवर करते हैं, और “sexually explicit content को बढ़ावा देने वाले content की creation या distribution” तथा “government या democratic process से जुड़े misleading claims को बढ़ावा देना” निषिद्ध उपयोगों में शामिल हैं
  • web platform API का UA-specific usage rules की दिशा में जाना ठीक नहीं माना गया, क्योंकि यह भविष्य में और APIs पर UA-specific rules जुड़ने की मिसाल बन सकता है
  • अगर किसी user ने किसी वेबसाइट पर article comment के “summarize” पर क्लिक किया और नतीजे में Google policy violation हो गया, तो यह स्पष्ट नहीं है कि जिम्मेदार कौन है: बटन क्लिक करने वाला user, उल्लंघनकारी content लिखने वाला comment author, या उस comment को user के UA LLM तक भेजने की सुविधा बनाने वाला website owner
  • डेवलपर model terms का पालन करने और model owner की कानूनी कार्रवाई से बचने के लिए यह जानना चाह सकते हैं कि वे किस LLM से बात कर रहे हैं; unknown model का मतलब unknown terms हो सकता है, इसलिए usage block करना एक तर्कसंगत विकल्प बन जाता है
  • किसी खास browser के पास website developers पर ऐसे terms लागू करने का आधार नहीं है, और यह policy issue API proposal से अलग तरीके से संभाला जाना चाहिए—ऐसी राय भी सामने आई

Chrome पक्ष के updates और mitigation

  • Chrome Prompt API टीम ने blink-dev I2S और ChromeStatus पर interoperability and compatibility risks से संबंधित update साझा किए
  • वे WebML CG में भागीदारी और चर्चा जारी रखना चाहते हैं, और interoperable sampling parameters जैसे follow-up experiments भी साथ चल रहे हैं
  • Chrome पक्ष ने कहा कि उसका उद्देश्य web platform की long-term health और neutrality बनाए रखते हुए browser और OS द्वारा उपलब्ध कराए गए Language Model को web developers और users के लिए उपयोगी विकल्प बनाना है
  • Prompt API surface ने Google और Microsoft, दोनों models पर कुछ स्तर की compatibility दिखाई है, और known JSON schema या regex से मेल खाने वाले output के लिए objective response constraints लागू किए जा रहे हैं
  • इन constraints को unpredictable output से निपटने के लिए model-specific hacks की जरूरत घटाने वाली mitigation के रूप में इस्तेमाल किया जा रहा है
  • downstream Chromium projects alternative models और framework backends की खोज कर रहे हैं, जिनमें Microsoft का Android MLKit integration work और Apple foundational model integration की शुरुआती prototyping शामिल है
  • API trial phase में कई model versions को experimental रूप से deploy किया गया, और model updates व improvements की लगातार जरूरत बनी हुई है; साथ ही नए Gemma 4 open models support की भी पड़ताल हो रही है
  • अलग-अलग underlying architectures पर अधिक interoperable behavior tuning के लिए categorical sampling modes भी explore किए जा रहे हैं
  • Blink-dev के Interoperability and Compatibility wording के अनुसार, इस तकनीक का उपयोग करने वाले developers के लिए behavior और responses में variability एक अच्छी तरह समझी गई expectation है, और यह API browsers व models के बीच consistent web platform access के लिए interoperability framework को लक्ष्य बनाता है

web developer support के आधार और shipping की आलोचना

  • blink-dev intent to ship web developers की स्थिति को “Strongly positive” बताता है और आधार के रूप में explainer के stakeholder feedback को लिंक करता है
  • इस आधार को “Strongly positive” जैसी रेटिंग के साथ बहुत मेल खाता हुआ नहीं माना गया

  • सूचीबद्ध आधार

    • दो सकारात्मक जवाबों वाला GitHub thread
    • X पर एक single post
    • अब उपलब्ध नहीं रहने वाला blog post, Server Not Found स्थिति में
    • अब भी उपलब्ध blog post
    • survey से ऐसा लगता है कि डेवलपर्स से पूछा गया था कि क्या यह API extensions में मौजूद हो तो ठीक है; लेकिन survey numbers या target group स्पष्ट नहीं हैं
    • हट चुके blog post का archived version Wayback Machine link के रूप में साझा किया गया
    • दस्तावेज़ में “किस पर निर्भर न करें” और “किस पर निर्भर कर सकते हैं” को बहुत प्रमुखता से दिखाने पर भी, अगर उन सिफारिशों का पालन किया जाए तो API के संभव उपयोग इतने सीमित हो सकते हैं कि वास्तविक उपयोगिता बचती है या नहीं, यह स्पष्ट नहीं है
    • व्यवहार में, टेस्ट किए गए किसी specific model के behavior पर कुछ हद तक निर्भर रहा जा सकता है, और अगर वह model Chrome का model है तो साइट उपयोगकर्ताओं को latest Chrome इस्तेमाल करने का संदेश दिखा सकती है
    • Google का अधूरा क्षेत्र बहुत व्यापक रूप से पहचानना, लेकिन फिर भी सिर्फ मौजूदा mitigation के आधार पर shipping को पर्याप्त मानना, एक समस्या बना रहता है

comment discussion: alternatives, harm measurement, और post-hoc mitigation

  • browser automation और Lynx mode

    • Hermes Agent और Qwen3.6 से ज़्यादातर काम किए जा सके, और Prompt API की बजाय browser automation API तथा chat के लिए Lynx mode पर अधिक ध्यान देना चाहिए—ऐसी धारा भी रही
    • कुछ workflows में इंसान वेबसाइट में login करता है और AJAX extension से files को visible बनाता है, फिर agent chromedriver/webdriver के जरिए documents download, tagging, और summarization करता है
    • यह approach बाहरी POSIX shell के बिना browser के भीतर integrate हो सकती है
    • Lynx mode chat agents को जो दिख रहा है उसे जल्दी expose करता है, और सभी media assets को download या render किए बिना दोनों पक्षों के resources बचाता है
    • HTML-level के अधिक granular robots tags, Lynxmode shell और मौजूदा browser के बीच handoff, और agent-driven browser में old-school Google AdWord शैली के links को selectively दिखाने जैसे विचार भी चर्चा में आए

  • open web और FOMO

    • यह प्रतिवाद भी था कि open web, chat bot super apps जैसी चीज़ों से उसी तरीके से प्रतिस्पर्धा नहीं करता और न ही गायब होने वाला है
    • लगातार FOMO के बजाय पहले यह पूछने की ज़रूरत है कि आप किसका प्रतिनिधित्व करना चाहते हैं—ऐसी राय भी सामने आई
    • जैसे web mobile app paradigm को पूरी तरह support नहीं कर पाया, वैसे ही अगर वह agentic computing को तेज़ और प्रभावी ढंग से support न कर पाए तो commerce या journalism open web के बाहर जा सकते हैं—इस चिंता से भी कुछ लोग सहमत नहीं थे

  • Chromium shipping और harm measurement

    • Chromium के blink API owner approvers में से एक ने Mozilla की चिंताओं से सहमति जताई, लेकिन experiment, mistakes से सीखने और competition को बढ़ावा देने वाला रास्ता पसंद किया
    • आगे चलकर वास्तविक harm का मूल्यांकन करने के लिए concrete outcomes तय करने होंगे; EME जैसे विवादास्पद API shipping decisions को 5–10 साल बाद वास्तविक परिणामों से तुलना करना उपयोगी रहा है—ऐसा संदर्भ दिया गया
    • साइटों का Google-specific model पर lock-in, दूसरे browsers के ship करने पर आने वाले site compat bugs की संख्या और पैमाने, और Chrome के model update के समय आने वाले bugs की प्रकृति से मापा जा सकता है
    • bugs को “model को अधिक smart बनाना” बनाम “अजीब quirks को preserve करना” में अलग करना, और webcompat.com पर labels लगाकर इकट्ठा करना—ऐसी बात भी हुई
    • blink-dev I2S के अनुसार Edge भी इस API को अलग model के साथ ship कर रहा है, इसलिए initial data पहले से मौजूद है
    • TOS concerns के harm metric के रूप में यह देखा जा सकता है कि क्या violations की वजह से वास्तव में lawsuits या threats हुए; और ऐसे सबूत रिकॉर्ड के रूप में इकट्ठा किए जाने चाहिए

  • post-hoc mitigation और Chrome की प्रतिक्रिया

    • संभावित harm को वास्तविक रूप से verify करने वाला approach उचित हो सकता है, लेकिन वह तभी उपयोगी है जब harm होने के बाद meaningful mitigation उपलब्ध हो—ऐसा प्रतिवाद भी दिया गया
    • जब साइटें Google-specific model पर lock-in हो जाएं, तब feature unship करना, overfitted site prompts को तोड़ने वाले model changes, random model rotation, और on-device model weights का open standardization जैसे विकल्प सवाल के रूप में रखे गए
    • अगर यह सबूत मिले कि दूसरे browsers को Chrome model के अजीब quirks कॉपी करने पड़ रहे हैं, तो Chromium leadership की स्थिति से Chrome पर उन quirks को तोड़ने का दबाव डाला जाएगा—ऐसी राय रखी गई
    • उदाहरण के तौर पर, Mobile GMail buggy WebKit border image quirks पर निर्भर था और जब Firefox को उन्हें कॉपी करने की ज़रूरत महसूस हुई, तब Chrome को ठीक करके GMail तोड़ा गया; GMail ने जल्दी update कर लिया और users को इसका पता भी नहीं चला

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

1 टिप्पणियां

 
GN⁺ 2026-05-01
Hacker News की राय

  • विरोध का तर्क काफ़ी साफ़ दिखता है: प्रॉम्प्ट और मॉडल का मज़बूत coupling, और terms में model neutrality की समस्या
    https://github.com/mozilla/standards-positions/issues/1213 में दिए गए व्यक्तिगत उदाहरण की तरह, home automation notifications के लिए system prompt बनाते समय Gemini ने शुरुआत में बहुत अमेरिकी अंदाज़ में जवाब दिया, और जब उसे बताया गया कि वह British voice में बोले, तो इस बार उसने “a'waight guv'nor apples and pears” जैसी किसी अमेरिकी की भद्दी British नकल निकाल दी, इसलिए और tuning करनी पड़ी
    इस प्रक्रिया में system prompt किसी खास मॉडल के हिसाब से ढल जाता है, और दूसरे मॉडल्स के quirks अलग होते हैं, इसलिए एक मॉडल के लिए डाली गई correction दूसरे मॉडल पर overcorrection बन सकती है

    • नतीजा यह होता है कि adversarial mode में यह मज़ाक उड़ाने जैसा सुनाई देता है
    • अगर यह LLM functionality को support न करने की अच्छी वजह है, तो फिर निष्कर्ष यह होना चाहिए कि इसे किसी भी platform API में नहीं होना चाहिए। लेकिन इसे पहले ही कई platforms में जोड़ा जा चुका है
      मॉडल्स का एक-दूसरे से अलग होना इस तकनीक की मूल विशेषता है। यह कुछ वैसा ही है जैसे device या orientation के हिसाब से canvas size बदलता है, geolocation API की accuracy अलग होती है, या Speech Synthesis की voice हर device पर अलग होती है
      यह रचनात्मक आलोचना से ज़्यादा anti-AI भावना के करीब लगता है। अभी permission UI की ज़रूरत है, और आगे चलकर शायद low/medium/high जैसे IQ level भी जुड़ें, लेकिन जो developers सच में ध्यान देते हैं, वे वैसे भी 90% मामलों में किसी specific model पर निर्भर हो जाएंगे
      समय के साथ जब AI से नफ़रत कम होगी और लोग समझेंगे कि यह मददगार है, तब Firefox में इस feature का न होना व्यक्तिगत डेटा स्वायत्तता के लिहाज़ से नाकामी जैसा दिख सकता है। अगर Chrome का संबंधित TOU समस्या है, तो यह उल्टा Firefox के लिए साफ़ terms वाले मॉडल के साथ यह feature जोड़ने की वजह बनती है

  • पहले पता नहीं था कि यह विरोध किसने लिखा, लेकिन पता चला कि Chrome team में लंबे समय तक रहे Googler Jake Archibald Mozilla में जाकर Chrome API के खिलाफ़ लिख रहे थे। आलोचना इतनी व्यवस्थित होना हैरानी की बात नहीं, और शायद इस बार party line न माननी पड़े, यह उन्हें राहत जैसा लगा होगा

    • धन्यवाद, लेकिन मेरा मानना है कि Google में रहते हुए भी उन्होंने party line नहीं मानी थी। बस उसकी वजह से अंदर उनका काम धीरे-धीरे और मुश्किल होता गया, और आख़िरकार वे निकल गए
      टीम में अब भी मौजूद लोगों की बातें सुनकर लगता है कि उस मामले में हालात अब कई गुना बदतर हो चुके हैं
    • standards-positions repo से वे बहुत परिचित होंगे, और यह वैसा ही लगता है जैसा Google बिना पर्याप्त feedback लिए कुछ आगे बढ़ाता है तो बचाव में लिखा जाता है
      बदलाव का प्रस्ताव देने के बजाय पूरी चीज़ को ख़ारिज करने की कोशिश जैसी, मानो अगर यह गिर जाए तो Google Chrome team के नज़रिये से शुरू किए बिना इसे शुरुआत से collaborative तरीके से फिर लिखा जाएगा। लेकिन मैंने ऐसे मामलों में बहुत सफलता नहीं देखी, इसलिए सीधे ठोस संशोधन प्रस्ताव देना ज़्यादा बेहतर लगता है

  • मैं इसका विरोध करता हूँ

    1. यह नई fingerprinting जानकारी बनती है, और fingerprinting script को धोखा देना मुश्किल होने के कारण इसे “device verification” के लिए दुरुपयोग किया जा सकता है। Browser को “verify” किया जा सके, ऐसा नहीं होना चाहिए, और हर किसी को किसी भी browser को emulate कर पाना चाहिए
    2. LLM बहुत memory और CPU खाता है, और मौजूदा RAM कीमतों को देखते हुए upgrade भी महँगा है। अगर websites local model पर निर्भर होंगी, तो सस्ते devices पर वे धीमी चलेंगी
    3. API ऐसा लगता है जैसे OpenAI जैसे किसी खास LLM के लिए tuned है
    4. Browser market में उन competitors को बाहर धकेला जा सकता है जिनके पास अपना AI model नहीं है। अगर sites यह मानकर बनें कि Google Gemini model मिलेगा, तो दूसरे models या AI model के बिना चलने वाले country browsers में वे टूट सकते हैं, और “first-class” और “second-class” browsers नहीं होने चाहिए
      explainer कहता है कि data कहीं भेजे बिना local processing हो सकती है, लेकिन अगर ऐसा है तो फिर Google Gemini local model के लिए Prohibited Use Policy की ज़रूरत क्यों है, यह सवाल उठता है। Google उन prompts और responses की चिंता क्यों करे जिन्हें वह जान भी नहीं सकता
      offline LLM access अपने आप में अच्छा लगता है, लेकिन browser में LLM embed किए बिना भी websites WebGPU का उपयोग कर सकती हैं, या ML model processing के लिए WebGPU को बेहतर बनाया जा सकता है। या फिर सबको वही open source LLM इस्तेमाल करना चाहिए
    • Google किसी दूसरे bacteria की तरह बस उस दिशा में flagella हिलाता हुआ बढ़ता है जहाँ पैसा हो। समझ नहीं आता कि कोई क्यों सोचता है कि Google web या मानवता के लिए अच्छा काम करेगा
    • “browser को verify नहीं किया जा सके” इस बात से मैं सख़्ती से असहमत हूँ। AI industry ने pre-COVID वाले anti-scraping, anti-botting social contract को पूरी तरह फाड़ दिया है
      अब यह आम समझ बन चुकी है कि robots.txt कोई enforced requirement नहीं है और उसे पूरी तरह bypass किया जा सकता है, और इसने खुले web को लगभग dark forest बना दिया है
      Browser session में छेड़छाड़ नहीं हुई है या वह “trusted” है, इसे verify करने के तरीके आगे चलकर आएँगे ही। बहुत बुरा है, लेकिन इसमें काफ़ी हद तक हमारी अपनी भी गलती है
    • fingerprinting की चिंता पर मेरा मानना है कि Chrome में, और निश्चित ही Firefox में भी, “कभी कोई LLM download न करो और सारे LLM features बंद रखो” जैसा option होगा
      Sites छोटे LLM requests भेजकर model को fingerprint कर सकती हैं, यह रास्ता संभव है, लेकिन अगर इसे बंद किया जा सके तो यह बहुत बड़ी समस्या नहीं लगती
      बड़े स्तर पर यहाँ यह चिंता है कि “web platform को यह करने में सक्षम नहीं होना चाहिए।” इस नज़रिये से कोई कह सकता है कि user इसे बंद भी कर दे, तब भी “LLM नहीं है, इसलिए browser unsupported” जैसे sites आएँगे और web बदतर होगा
      लेकिन अंत में वह website operator का फ़ैसला है कि LLM न होने पर site बंद कर दे; यह feature बनाने वाले platform या maintainer की गलती नहीं है। यह वैसा ही है जैसे Firefox में सब ठीक काम करता हो, लेकिन test करने में आलस के कारण support बंद कर दी जाए
      Web, PDF से नहीं बल्कि SwiftUI से प्रतिस्पर्धा कर रहा दुनिया का सबसे सफल application platform है। “web को अभी जैसा static है वैसा ही रहने दो” कोई वास्तविक विकल्प नहीं, बल्कि भ्रम है। असली विकल्प यह है कि web को users की बदलती ज़रूरतों के हिसाब से adapt किया जाए, या फिर web असफल हो और उसकी जगह SwiftUI या WinUI ले लें। दूसरा विकल्प कहीं ज़्यादा बुरा है
    • इस thread के replies पढ़ते-पढ़ते मुझे समझ आया: वे यह करने ही वाले हैं, और जो लोग पहले से LLM पर निर्भर हैं या ठीक से निर्णय लेने की क्षमता नहीं रखते, वे इसकी तारीफ़ भी करेंगे
      https://news.ycombinator.com/item?id=47960596
      निष्कर्ष यह है कि अब आगे बढ़ने का समय है। हमें web browser से बेहतर online information exchange और media playback format के बारे में सोचना चाहिए। अगर हम ही product हैं, तो जिन tools का हम इस्तेमाल करते हैं उन्हें भी चुपचाप ad revenue किसी अविश्वसनीय शासक तक पहुँचाने वाले proxy की तरह behave नहीं करना चाहिए, बल्कि उस सच्चाई को सीधे प्रतिबिंबित करना चाहिए

  • जितना ज़्यादा सोचता हूँ, उतना इस बार Google की API design से ज़्यादा सहमत होता जाता हूँ
    प्रॉम्प्ट और मॉडल का मज़बूत coupling वास्तविक चिंता है और रोज़ की समस्या भी। लेकिन अगर समाधान ऐसा API है जो prompt को user के browser में मौजूद model के साथ और कसकर बाँध दे, तो जल्दी ही “हमने अपना prompt सिर्फ Gemini पर test किया है, इसलिए इस site के लिए Chrome चाहिए” जैसी स्थिति बन जाएगी
    इससे भी बुरा यह हो सकता है कि “कौन-सा AI model इस्तेमाल हो रहा है, यह पहचाना नहीं जा सकता।” अगर 2026 में बनी site 2030 तक update न हो, तो ऐसा पूरी तरह संभव है
    यह Mozilla engineer द्वारा पीछे कही गई terms वाली समस्या से भी जुड़ता है। अगर ऐसे browsers मौजूद रहने हैं जिनमें users को किसी specific AI model की terms मानने की ज़रूरत न पड़े, जैसे कि अच्छे open source model वाले browsers, तो Big Models को fingerprint न किया जा सके, यह अधिक फ़ायदेमंद है
    बेशक कई sites फिर भी isChrome() जैसी calls करेंगी। फिर भी browser fingerprinting के तरीक़े बढ़ाने वाले बदलावों का मैं आम तौर पर विरोध करता हूँ। model anonymity का फ़ायदा, Gemini और Qwen जैसे models के बीच छोटे फ़र्क़ से कभी-कभार निकलने वाले अजीब output के नुकसान से बड़ा है

  • समझ नहीं आता कि Google browser जो पहले से कर सकते हैं उनकी ढांचागत कमज़ोरियाँ ठीक करने पर भारी संसाधन क्यों नहीं लगाता, और उसके बजाय लगातार इधर-उधर की चीज़ें जोड़कर browser को Homermobile क्यों बनाना चाहता है
    static blogs से लेकर e-commerce और cutting-edge web apps तक, पूरे web platform की quality of life सुधारने वाली बुनियादी चीज़ों पर ध्यान क्यों नहीं
    https://simpsons.fandom.com/wiki/The_Homer

    • Google Chrome इसलिए नहीं बनाता कि वह बेहतर web बनाए। एक अच्छे browser को सिर्फ browser के लिए अच्छा बनाना goodwill पर अरबों डॉलर खर्च करना होगा, जबकि Chrome का लक्ष्य यह है कि user अपने device पर जो कुछ भी करे, उसके लिए वह user के OS की जगह लेने वाला platform बने
      वह Android और ChromeOS के ज़रिए इसे सीधे करने की कोशिश करता है, लेकिन Chrome Windows जैसे माहौल के औसत user को भी ज़्यादातर समय Google की दुनिया के अंदर बनाए रखता है
    • Google में promotion चाहिए तो prompt API launch करना होगा
    • prompt API implement न करने से क्या वाकई resources उन दूसरे कामों में लगेंगे जिन्हें पहले महत्वपूर्ण नहीं माना जाता था? यह मुझे false dichotomy जैसा लगता है

  • मेरा मज़बूत मानना है कि मौजूदा LLM और API harness इतने तकनीकी रूप से परिपक्व नहीं हैं कि इस तरह का API standard में जाए
    अगर फिर भी करना है, तो कम-से-कम यह per-site opt-in permission होना चाहिए, और यह पहचानने का तरीका होना चाहिए कि prompt किस model को भेजा जा रहा है। system prompt में छोटी-सी tuning भी उस पहचान का हिस्सा है
    user के तौर पर मुझे भरोसा चाहिए कि किसी मनमानी site पर जाने भर से मेरी अनुमति के बिना इस API से मेरा fingerprinting नहीं किया जाएगा
    developer के तौर पर मुझे यह जानना होगा कि users कौन-सा model चला रहे हैं, ताकि model-specific prompts बनाने का विकल्प रहे

  • “यह अपेक्षा बढ़ रही है कि browsers और operating systems language models तक पहुँच देंगे”? सच में?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • मुझे लगता है दिशा उलटी है। मैं नहीं चाहता कि OS या browser LLM तक पहुँचे, लेकिन मैं चाहता हूँ कि LLM browser या OS तक पहुँचे, और यह पहले से होने भी लगा है
      इसलिए default off रहे, और बस इतना हो कि user चाहे तो चालू कर सके, ऐसा LLM interface दिया जाए
      तब Apple द्वारा OS में डाले गए LLM में lock-in होने के बजाय यह चुनना भी संभव होगा कि कौन-सा LLM provider इस्तेमाल करना है। उदाहरण के लिए, जिन चीज़ों तक Apple Intelligence पहुँच सकता है, मैं चाहता हूँ कि Claude भी वहाँ पहुँच सके
    • वह वाक्य मैंने ही मूल रूप से लिखा था, और अंदाज़ा नहीं था कि उसका ऐसा गलत मतलब निकलेगा। मेरा मतलब users या developers की expectation नहीं था, बल्कि यह industry trend था कि OS और browser vendors LM ship कर रहे हैं या उसकी तैयारी कर रहे हैं
      अब शायद “will be expected to expose” की जगह “are being shipped with” लिखना बेहतर होगा। लगता है बहुत लोग भ्रमित हो रहे हैं, इसलिए अच्छा होगा कि project maintainers इसे अपडेट करें
    • macOS, iOS, Windows में third-party developers के लिए local model APIs हैं, और Chrome भी इसे test कर रहा है। Firefox model से alt-text बनाता है, लेकिन API नहीं देता
      सिद्धांत रूप में यह उपयोगी है। अगर developers local models पर निर्भर हो सकें, तो चीज़ें ज़्यादा private और decentralized होंगी, और AWS या Anthropic को पैसा भेजने की ज़रूरत भी कम होगी। local होने के कारण offline और free होना, low-stakes use cases में ही इसे वास्तव में अर्थपूर्ण बनाता है
      लेकिन व्यवहार में native apps में Apple Foundation Models का adoption मैंने लगभग नहीं देखा। अगर Mac/iOS developers के पास साझा करने लायक अनुभव हो तो जानना दिलचस्प होगा
    • AI उन लोगों को बहुत ताक़त देता है जो सिर्फ bikeshedding कर सकते हैं। AI खुद भी शायद एक bikeshed हो, लेकिन इसके कुछ legitimate use cases हैं, और यह बेकार ideas को विरोध से ज़्यादा देर तक बोल-बोलकर आगे धकेलने की ताक़त भी देता है
      अब हर चीज़ धीरे-धीरे bikeshed की उम्मीद करने लगी है। CVE इसका इंतज़ार कर रहा है
    • लगता है browser API surface अभी भी काफ़ी अश्लील रूप से चौड़ा नहीं हुआ है

  • open protocols की अच्छी बात यह है कि किसी खास implementation का समर्थन करना या उसे इस्तेमाल करना ज़रूरी नहीं होता, लेकिन फिर भी browser monopoly लगातार दुविधा बना हुआ है
    ungoogled chromium, Tor जैसे अच्छे projects हैं, लेकिन सबसे बड़ी समस्या यह है कि औसत लोगों की आवाज़ उठाने और आम जनता से जुड़ने वाले projects की कमी है
    बहुत से कम-जानकार users को cause या message delivery के तरीक़े से फ़र्क़ नहीं पड़ता, और वे freedom और control से ज़्यादा “fun” और कम friction पर प्रतिक्रिया देते हैं
    इसका हल क्या है? browser को हमारा, लोगों द्वारा, लोगों के लिए कैसे बनाया जाए? यह सोचते ही बस उदासी होती है

    • अगर आप browser खुद compile करें, तो स्थिति और खराब हो जाती है। Spotify या Netflix चाहिए तो attestation वाला Widevine चाहिए, और उसके लिए अंत में Google को भुगतान करना पड़ता है
      Browser Agent string अगर Chrome या Firefox न हो, तो अंतहीन Cloudflare CAPTCHA या 403 मिलते हैं
    • शुरुआत यह होनी चाहिए कि “native” applications में Chrome घुसाने के बजाय platform APIs सीखे जाएँ
      फिर web applications, Chrome जैसा करता है उसके आधार पर नहीं बल्कि web standards के आधार पर बनाए जाएँ, और Firefox या Safari साथ न दे पाएँ तो उसकी शिकायत न की जाए
    • आसान है। antitrust laws से सभी बड़ी tech companies को तोड़ दो। ये हमारे दौर के robber barons हैं
    • अफ़सोस की बात है, लेकिन जवाब लगभग हमेशा वास्तविक सार्वजनिक फंडिंग ही होता है
    • अच्छे browsers पहले से मौजूद हैं, और औसत लोग Chrome इस्तेमाल करते हैं। जिन्हें परवाह है, वे पहले वाले पर चले जाते हैं। फिर समस्या क्या सुलझानी है?
      आपने कहा कि औसत लोगों तक पहुँचने वाले projects चाहिए, और साथ ही यह भी कहा कि वे freedom और control से ज़्यादा कम friction चाहते हैं। इसमें विरोधाभास है। औसत लोग control से ज़्यादा less friction से जुड़ते हैं

  • मैं सोच रहा हूँ कि इस API का use case क्या है
    local LLM चलाने का मेरा अनुभव यह है कि llama-server चलाओ, ज़रूरत पड़े तो अलग machine पर चलाओ, और फिर दूसरी applications को यह configure कर दो कि वे OpenAI या किसी मिलती-जुलती service की जगह उसी OpenAI-compatible server को point करें
    मैं नहीं चाहता कि browser LLM instance बनाए या चलाए। हो सकता है उस machine में LLM instance चलाने की क्षमता या spare resources ही न हों

  • पता नहीं यह उन युवा पीढ़ियों और पुरानी पीढ़ियों का फ़र्क़ है जो LLM के बिना जी ही नहीं सकतीं, बनाम वे लोग जो privacy में दखल देने वाले web browser चलाने के लिए supercomputer की माँग नहीं चाहते
    मुझे तो यह उस बिंदु जैसा लगता है जहाँ लोग browser/web के विकल्प तलाशना और बनाना शुरू करेंगे

    • यह Mozilla द्वारा AI के खिलाफ़ बयान नहीं है
      यह सिर्फ़ साफ़ और तार्किक कारण बताता है कि अपने मौजूदा रूप में प्रस्तावित API web interoperability के लिए क्यों बुरा है
    • मुझे लगता है यहाँ विरोध का LLM को पसंद या नापसंद करने से कोई लेना-देना नहीं। सवाल यह है कि यह खास open web API proposal व्यवहार्य है या नहीं
      व्यक्तिगत रूप से मैं coding assistance और home automation में LLM इस्तेमाल करता हूँ, लेकिन मुझे नहीं लगता कि यह API web के लिए अच्छी है
    • मेरे अनुभव में युवा लोग आम तौर पर AI को नापसंद करते हैं
    • थोड़ा विषय से हटकर है, लेकिन मुझे लगता है कि फिर से काम browser interface से ज़्यादा operating system की अवधारणा पर होना चाहिए
      सही जवाब क्या है, यह नहीं जानता, लेकिन Niri/Wayland, GNOME, Windows, Mac इस्तेमाल करने के बाद मैं non-tiling desktop और non-keyboard-centric desktop window management workflow पर कभी वापस नहीं जाऊँगा
    • “supercomputer चाहिए और privacy में दखल देने वाला browser” वाली नाव तो 2008 में ही निकल चुकी थी