Google Chrome ने केवल *.google.com पर उपलब्ध API दिया

 (twitter.com/lcasdev)
2 पॉइंट द्वारा GN⁺ 2024-07-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Chrome *.google.com साइटों को ही ऐसे API देता है जो system/tab CPU usage, GPU usage, memory usage, विस्तृत processor जानकारी, और logging backchannel access की अनुमति देते हैं
  • यही API दूसरी साइटों पर उपलब्ध नहीं है, जिससे इस बात पर विवाद है कि क्या browser vendor अपनी ही वेबसाइटों को विशेष अधिकार दे सकते हैं
  • DMA इस विचार को क़ानूनी रूप देता है कि internet gatekeeper browser vendors को सभी को समान फीचर देने चाहिए, और व्याख्या के अनुसार केवल Google की properties को अतिरिक्त जानकारी देना DMA का उल्लंघन हो सकता है
  • Zoom को Google Meet जैसी CPU debugging features नहीं मिलतीं, जिससे वह प्रतिस्पर्धा में नुकसान की स्थिति में आ सकता है
  • यह फीचर एक built-in Chrome extension के रूप में लागू है जिसे disable नहीं किया जा सकता और जो extension panel में भी नहीं दिखता; Microsoft Edge और Brave में भी यही फीचर केवल *.google.com डोमेन पर उपलब्ध है

*.google.com-only API कौन-सी जानकारी उजागर करता है

  • Chrome केवल *.google.com साइटों को system status और debugging जैसी जानकारी देता है
    • system और tab का CPU usage
    • GPU usage
    • memory usage
    • विस्तृत processor जानकारी
    • logging backchannel
  • यही API दूसरी साइटों पर उपलब्ध नहीं है और केवल *.google.com डोमेन पर इस्तेमाल किया जा सकता है

implementation तरीका और Chromium-आधारित browsers का व्यवहार

  • यह फीचर एक built-in Chrome extension के रूप में लागू है जिसे disable नहीं किया जा सकता और जो extension panel में दिखाई भी नहीं देता
  • source code Chromium के hangout_services path में है
  • शुरू में यह स्पष्ट नहीं था कि यही extension दूसरे Chromium-आधारित browsers में भी शामिल है या नहीं, लेकिन बाद के update में यह व्यवहार पुष्टि हुआ
    • Microsoft Edge में भी यह फीचर केवल *.google.com डोमेन के लिए उपलब्ध है
    • Brave में भी एक preinstalled extension है जो Google को केवल *.google.com पर यह जानकारी लेने देता है, और इसका व्यवहार Chrome व Edge जैसा है

competition और regulatory मुद्दे

  • अगर browser केवल अपने कुछ खास domains को system जानकारी देता है, तो दूसरी web services के लिए उसी स्तर की diagnostic features बनाना कठिन हो जाता है
  • Zoom का उदाहरण दिया जाता है कि उसे Google Meet जैसी CPU debugging features नहीं मिलतीं, और इससे browser vendor द्वारा अपनी सेवाओं को प्राथमिकता देने का सवाल उठ सकता है
  • DMA के नज़रिये से मुख्य सवाल यही है कि क्या gatekeeper को फीचर access सबको समान रूप से देना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2024-07-10
Hacker News की राय

  • hangout_services नाम देखकर लगता है कि यह Google Hangouts के development को आसान बनाने के लिए बनाया गया कोई पुराना technical-debt वाला hack रहा होगा
    शायद इसका मकसद telemetry data सीधे Hangouts टीम तक पहुंचाना रहा होगा। Hangouts browser में video call लागू करने वाला पहला app था, और वही बाद में WebRTC बना। यह module CPU/GPU/RAM usage और hardware जानकारी expose करता है, जिसे app सामान्यतः नहीं देख सकता। Google शायद यह Twitter thread देखकर इसे बस हटा देगा। Hangouts अब dead product है, और अगर server-side code अभी भी इसका इस्तेमाल करता हो, तब भी WebRTC का usage अब कहीं ज्यादा व्यापक है, इसलिए Chrome टीम multi-site तरीके से performance को सीधे monitor कर रही होगी

    • नहीं, यह अभी Google Meet में इस्तेमाल हो रहा है। Chrome में meet.google.com का "Troubleshooting" panel खोलें तो पूरे system का CPU usage real time में दिखता है :)
    • privacy violation से अलग, मुझे लगता है यह साफ़ तौर पर antitrust issue नहीं है क्या? Google browser dominance का दुरुपयोग करके video conferencing market में अपने product को बढ़त दे रहा है
    • हो सकता है CPU/GPU usage वगैरह track करके यह fine-tune करने के लिए हो कि किस quality की video stream इस्तेमाल करनी है
      Non-standard तो है, लेकिन native app हो तो ऐसा काम बिल्कुल कर सकता है

  • इस हिस्से पर मैं थोड़ा समझा सकता हूं। संदर्भ के लिए, मैं पूर्व Google employee हूं
    एक समय Google के internal video conferencing platform GVC पर काम किया था। 2010–2011 के आसपास company के कई video conferencing devices Cisco Tandberg जैसे proprietary equipment थे, और महंगे होने के कारण इन्हें हजारों meeting rooms में deploy करना भी काफी costly था। लगभग उसी समय दूसरी टीम Hangouts develop कर रही थी, और मुझे ठीक से याद नहीं कि तब उसका नाम Google Meet था या बाद में ऐसा हुआ। लगता है Hangouts नाम तब अपनाया गया जब Google+ आने पर product में integrate किया गया। GVC configurations कई तरह की थीं, लेकिन सबसे common All-in-One(AIO) monitor/computer combo था, और वह पूरा Intel PC था। इसलिए GVC platform एक custom Linux distribution था, जिसे Google services से communicate करने और software updates deploy करने के लिए design किया गया था। Boot failure के लिए पुराना distribution भी रखा जाता था, और device naming जैसी कई समस्याएं थीं। Touch panel, बड़े PTZ camera, कई microphones जैसे अलग-अलग hardware support की भी जरूरत थी। आखिरकार Hangouts GVC का base stack बन गया और लगभग सारे Tandberg को replace करके काफी पैसा बचाया। यह system 2017 तक तो निश्चित रूप से इस्तेमाल में था, उसके बाद का नहीं पता। Monitoring भी इसका हिस्सा थी, इसलिए अगर *.google.com-only API दिख रही है तो इसे ठीक से देखना होगा। सिर्फ Tweet से यह पता नहीं चलता कि Google दुनिया भर के सभी Chrome instances को query कर सकता है या सिर्फ google.com पर ही संभव है। हालांकि hangouts_services नाम और domain restriction को देखते हुए यह GVC के लिए embedded Chrome monitoring support होने की संभावना ज्यादा लगती है। मैं गलत भी हो सकता हूं

    • मुझे नहीं लगता यह वही है। अभी Firefox में Meet call करके देखा, troubleshooting button दबाने पर CPU chart disabled है और text आता है, "CPU usage देखने के लिए Chrome इस्तेमाल करके देखें"
      Chrome में CPU usage दिखता है—यह Meet द्वारा इस्तेमाल CPU है या पूरा system, पता नहीं—लेकिन किसी भी तरह यह सामान्य API से संभव नहीं लगता। Background में yes jobs कुछ चलाकर check किया तो यह निश्चित रूप से पूरा system है। साथ में, naming confusion हमेशा होता है, लेकिन GVC सच में साफ़ और अच्छा नाम है
    • कहानी दिलचस्प है, लेकिन लगता नहीं कि इसका इस मामले से remotely भी कोई connection हो सकता है। Custom Linux distribution पर GCV platform चलाने वाले लोग machine stats report करने के तरीके के रूप में “चलो अपना custom extension दुनिया भर की हर Chrome installation में डाल दें” चुनते, ऐसा संभव नहीं लगता
      किसी भी *.google.com page पर खुद try कर सकते हैं:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • “Google दुनिया भर के सभी Chrome instances को query कर सकता है या सिर्फ google.com पर ही संभव है” वाली distinction मुझे ठीक से समझ नहीं आ रही
      API लगता है केवल *.google.com पर चल रहे content को expose होती है, लेकिन फिर भी यह लगभग “Google अपनी site पर आने वाले हर Chrome instance को query कर सकता है” के बराबर है। भले आप Google services इस्तेमाल न करें, Chrome default रूप से new tab page content Google से लाता है, इसलिए practically यह करीब-करीब 100% है। मुझे नहीं लगता कि इसे maliciously इस्तेमाल किया जा रहा है, लेकिन अगर Google इस तरह problems diagnose कर सकता है और उसी क्षेत्र के competitors नहीं कर सकते, तो फिर भी समस्या है। Zoom के पास ऐसी API नहीं है, है ना?
    • मैंने Google में काम नहीं किया है, लेकिन यह explanation ज्यादा convincing नहीं लगती
      क्या कह रहे हैं कि internal video conferencing platform के internal appliance में CPU usage observe करने के लिए आम users वाले Google Chrome में यह bundled plugin डाला गया?
    • दिलचस्प। शायद Google के ज्यादातर लोगों को भी अब तक पता नहीं था कि यह possible है
      अब दर्जनों product managers अपने product के tech lead के पास “ठीक है, पहले मेरी बात सुनो…” कहते हुए पहुंच रहे होंगे

  • यह feature अक्टूबर 2013 में जोड़ा गया लगता है: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    यह commit Chrome में Hangouts Services extension bundle करने का है। BUG=291271, review URL: https://codereview.chromium.org/35873003। संबंधित review URL https://codereview.chromium.org/35873003 है

  • मुझे ठीक-ठीक नहीं पता कि यह API क्या है और क्यों मौजूद है, लेकिन Firefox भी कुछ ऐसा ही करता है
    Mozilla और Firefox डोमेन पर ही इस्तेमाल हो सकने वाली खास APIs हैं, जैसे extension install या first-run experience में मदद के लिए। 12 महीने से भी कम समय पहले इससे जुड़ा एक ब्लॉग पोस्ट Hacker News पर आया था, लेकिन उसे ढूंढना मुश्किल है

    • यह लगभग वही बात नहीं है
      API सार्वजनिक और documented है, और domain allowlist UI और about:config में भी मौजूद है। Android Play Store version अपवाद है, क्योंकि उसमें सब कुछ छिपा दिया गया है—शायद ब्राउज़र को पूरी तरह कचरा बनाने के लिए। और अगर आप कोई अच्छा use case लेकर Bugzilla पर शालीनता से अनुरोध करें, तो लगता है developers default domains जोड़ने पर कम-से-कम विचार तो करेंगे
    • वह ब्राउज़र संचालन से सीधे जुड़े websites के लिए है। इसके विपरीत Chrome Google Meet जैसे अलग Google product में इस्तेमाल होने वाली API expose कर रहा है
      एक बाजार, यानी ब्राउज़र में monopoly का इस्तेमाल करके दूसरे बाजार, यानी video conferencing में फायदा लेना है, इसलिए यह antitrust law का उल्लंघन भी हो सकता है
    • मैंने बहुत पहले UITour वाले हिस्से पर लिखा था: https://www.mkelly.me/blog/content-uitourjs/
      ब्राउज़रों में यह काफी standard तरीका है। जोखिम का स्तर लगभग वैसा ही होना चाहिए जैसे कोई उस domain को spoof कर दे जहां से ब्राउज़र software updates डाउनलोड करता है, और अगर आपको सच में पसंद नहीं है तो preferences में इसे बंद कर सकते हैं
    • पिछले महीने WebKit के Quirks.cpp commit को share किया गया था [0]। शायद आप यही नहीं ढूंढ रहे थे, लेकिन इसका feel मिलता-जुलता है
      [0] https://news.ycombinator.com/item?id=40631439
    • वे APIs ब्राउज़र features और onboarding से जुड़ी हैं। उन्हें Mozilla के दूसरे products को दूसरी कंपनियों के मिलते-जुलते products से बेहतर स्थिति में रखने के लिए नहीं जोड़ा गया था

  • संदर्भ के लिए, मैं Google में काम करता हूं, लेकिन Chrome या इस API का जिम्मेदार नहीं हूं
    मुझे स्पष्टीकरण काफी सामान्य लगता है। उदाहरण के लिए, Google Meet खोलें और कोई खाली meeting, यानी “instant meeting”, शुरू करें, फिर “…” menu में “Troubleshooting & help” दबाएं, तो CPU usage समेत कई statistics graphs दिखते हैं। लगता है Meet call के दौरान machine पर load पड़ने पर यह tabs बंद करने का सुझाव भी विनम्रता से देता है। यह काफी उपयोगी है, इसलिए मैं कभी-कभी देख लेता हूं। दोबारा सोचने पर पक्का नहीं है कि tabs बंद करने का सुझाव सच में है या नहीं; मैंने असल में केवल statistics screen ही इस्तेमाल की है

    • “काफी सामान्य” वाले स्पष्टीकरण के उलट, यह बिल्कुल भी सामान्य नहीं है। यह अपने product को अनुचित प्रतिस्पर्धी बढ़त देने का एक perfect example है
      Meet users को बताया जाता है कि meeting ठीक से क्यों नहीं चल रही, लेकिन अगर Zoom, Teams, Slack वही काम नहीं कर सकते, तो Meet का user experience बेहतर होना तय है। यह भी अजीब नहीं कि बाकी सभी meeting services desktop app इस्तेमाल करने पर जोर देती हैं। Google Meet का desktop app आखिरकार Chrome ही है
    • बल्कि यही तो मुख्य बात है। दूसरे video conferencing tools ऐसे debugging options नहीं दे सकते, और जैसा आपने अभी कहा, वह feature उपयोगी है
    • competitor Zoom का browser version है। क्या performance problems diagnose करने के लिए यह API इस्तेमाल की जा सकती है? अगर नहीं, तो European regulators इसमें दिलचस्पी ले सकते हैं
      शायद यह भी एक कारण हो कि Meet browser में ठीक चलता है और Zoom नहीं, खासकर जब meeting attendees ज्यादा हों, इसलिए Zoom users अच्छी performance चाहते हैं तो native app इस्तेमाल करने लगते हैं
    • यह बहुत शानदार है कि Google ने एक anti-competitive browser बनाया है जो सिर्फ उनके लिए उपयोगी features देता है
      शुक्रिया कि Google employee ने खुद वह बात कह दी जिसे वे चुपचाप निकाल जाना चाहते
    • monopoly power transfer कोई सामान्य बात नहीं, बल्कि illegal है

  • लगता है submission title को original से बदलने की प्रक्रिया में थोड़ा गड़बड़ हो गया। मेरी समझ के मुताबिक यह ऐसा है
    Chrome में एक built-in extension है जो public Chrome API इस्तेमाल करता है, जिसे दूसरे Chrome extensions भी आसानी से इस्तेमाल कर सकते हैं। समस्या यह है कि जब यह extension Google के अपने domains से communicate करता है तो वह जानकारी share करता है, लेकिन दूसरी websites ऐसा नहीं कर सकतीं। कोई “खास hidden API” नहीं है

    • “खास” का मतलब है कि यह दूसरे extensions की तरह user द्वारा install किया हुआ नहीं, बल्कि Chrome में built-in है
      “hidden” का मतलब है कि chrome://extensions पर जाने पर भी यह list में नहीं दिखता। और जैसा पहले कहा, यह Chrome API भी है
    • Google site के Chrome DevTools console में इसे paste करके देखें तो यह special API जैसा दिखता है:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • “built-in extension” हो, तब भी अगर उसे disable नहीं किया जा सकता, तो वह अब भी browser का ही हिस्सा है
    • एक harmless और सरल explanation भी संभव है। कल्पना करें कि browser feature का कोई हिस्सा compiled/linked C++ के बजाय google.com signed webapp के रूप में implemented है
      अगर PWA के रूप में implemented browser code को system information access करने के लिए अलग permission मांगनी पड़े, तो यह अजीब होगा। क्योंकि वह browser feature का ही हिस्सा है। लंबे समय से मौजूद private API का एक और उपयोग Chrome Web Store जैसी core functionality देने वाली Google-only websites को Chrome browser से integrate करना है, ताकि webpage से extensions install और remove करने की अनुमति मिल सके
    • functionally तो यह वही काम है

  • यह "system.cpu" permission होने पर किसी भी extension द्वारा access किए जा सकने वाले chrome.system.cpu API का इस्तेमाल करता हुआ लगता है
    https://developer.chrome.com/docs/extensions/reference/api/s...
    यह extension जिन सभी permissions की request करता है, उन्हें यहां देखा जा सकता है:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • सही है, और यही तो समस्या है। Google ने browser के अपने कामकाज से असंबंधित extension को Chrome में bundle कर दिया है, जिससे उसके दूसरे product Hangouts को privileged access मिल रहा है
      दूसरे video conferencing apps को ऐसा access नहीं मिलता, जब तक user अलग से extension manually install करने जैसा बड़ा step न ले

  • ज़्यादा हैरानी की बात नहीं। यह बहुत Google-जैसा व्यवहार है। सवाल यह है कि क्या दूसरे Chromium browsers में भी यह है। Edge, Brave, Chromium, Ungoogled Chromium का क्या?

    • बाकी के बारे में नहीं पता, लेकिन ungoogled chromium शायद इसमें नहीं होगा, क्योंकि ऐसी चीज़ों से बचने के लिए वह code में "google" string आने वाली हर जगह को जानबूझकर उलट-पुलट कर देता है
    • Edge में यह enabled है। Edge में Google Meet troubleshooting खोलें तो system CPU देखा जा सकता है
      Firefox में ऐसा करने पर “CPU usage देखने के लिए Google Chrome इस्तेमाल करके देखें” दिखता है

  • Safari में भी Apple-only features हैं। उदाहरण के लिए, Apple account से दूसरी websites में login करते समय, यह passkey या password autocomplete से अलग तरह से काम करने वाला special dialog दिखा सकता है
    दूसरे browsers को redirect-based flow से गुजरना पड़ता है। मैं हमेशा सोचता था कि यह JavaScript में कैसे implement होता है। क्या यह किसी proprietary argument वाला WebAuthn जैसा है?

  • Google पहले भी ऐसा कर चुका है। details धुंधली हैं, लेकिन शायद Native Client को domain-level allowlist के जरिए सिर्फ Hangouts में काम करने के लिए set किया गया था, या कुछ ऐसा ही था