सभी browser API ‘web’ API नहीं होते

 (polypane.app)
17 पॉइंट द्वारा GN⁺ 2026-01-20 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • यह धारणा व्यापक है कि web platform standardized API पर एकसमान तरीके से काम करता है, लेकिन वास्तव में कई API browser vendor-विशिष्ट infrastructure पर निर्भर करते हैं
  • Geolocation, Speech, Push, Payments, Passkeys आदि सतह पर web standard जैसे दिखते हैं, लेकिन अंदरूनी तौर पर Google·Apple·Microsoft की services को कॉल करते हैं
  • एक ही API call होने पर भी accuracy, availability, region-wise incompatibility, privacy policy browser के अनुसार काफी बदल सकती है, और developer अक्सर इसे जाने बिना ही उस पर निर्भर हो जाता है
  • बड़े vendor-केंद्रित standardization structure छोटे browser और open source ecosystem के लिए प्रवेश बाधा बढ़ाता है और de facto lock-in effect को मजबूत करता है
  • Developers को ऐसे API को शुद्ध ‘web standard’ नहीं बल्कि vendor service abstraction layer के रूप में समझना चाहिए, और privacy disclosure, alternative design, browser-wise testing साथ में करना चाहिए

web platform के बारे में सामान्य धारणा और वास्तविक संरचना

  • web platform को standard spec-आधारित unified system माना जाता है, और समान engine-आधारित browser में समान व्यवहार की अपेक्षा की जाती है
  • लेकिन वास्तव में कई API browser-विशिष्ट implementation और third-party services, proprietary infrastructure, vendor internal systems पर निर्भर करते हैं
  • standardized interface के विपरीत implementation details browser vendor की पसंद के अनुसार काफी बदलती हैं

Geolocation API और location data का वास्तविक स्रोत

  • Geolocation API standardized interface देता है, लेकिन वास्तविक location data कई रास्तों से जुटाया जाता है
    • OS location service और GPS का उपयोग
    • Wi-Fi AP जानकारी के आधार पर location estimation
    • IP address-आधारित location database lookup
  • Chrome Google Location Services, Safari Apple server, और Firefox 2024 के बाद से Google service का उपयोग कर रहा है
  • location data का उपयोग करते समय user data किसी खास vendor server पर भेजा जा सकता है, लेकिन browser UI में यह स्पष्ट रूप से दिखाई नहीं देता
  • अगर किसी खास region में vendor service तक पहुंच blocked हो, तो feature के सामान्य रूप से काम न करने की संभावना रहती है

Speech Synthesis और voice processing infrastructure

  • Web Speech API का speech synthesis browser, OS और device environment के अनुसार अलग-अलग engine का उपयोग करता है
  • Speech Synthesis API standardized interface है, लेकिन voice data operating system TTS engine या cloud server पर process होता है
    • Chrome local और cloud दोनों का उपयोग करता है, Safari OS voice engine का उपयोग करता है
    • कुछ high-quality voices के लिए cloud-based processing हेतु online transmission की जरूरत होती है, इसलिए user data server पर भेजा जाता है
    • निजी message या sensitive information के अनजाने में external server पर भेजे जाने का जोखिम रहता है
  • साथ ही, test environment में चुनी गई voice user environment में मौजूद न भी हो सकती है

Speech Recognition और real-time voice transmission

  • Speech Recognition API ज्यादातर cloud recognition services पर निर्भर है
    • Chrome Google, Safari Apple, और Edge Azure-आधारित services का उपयोग करते हैं
    • Chrome 139 से processLocally option के साथ local processing संभव है, लेकिन यह default नहीं है, और यह भी केवल Chrome-विशिष्ट feature है
    • accuracy और language support में vendor के model quality के अनुसार अंतर आता है

Passkeys और WebAuthn का वास्तविक आधार: browser ecosystem dependency

  • WebAuthn API passwordless authentication का दावा करता है, लेकिन वास्तव में यह browser के password manager infrastructure पर निर्भर है
    • Chrome Google Password Manager, Safari iCloud Keychain, Edge Microsoft Account का उपयोग करते हैं
    • Polypane आदि Electron की सीमाओं के कारण Passkey unsupported हैं, इसलिए 1Password जैसे extension की जरूरत पड़ती है
  • credential storage, sync और recovery का तरीका पूरी तरह vendor-विशिष्ट implementation पर निर्भर करता है

Payment Request API और payment vendor dependency

  • Payment Request API standard जैसा दिखता है, लेकिन वास्तविक payment इस बात पर निर्भर करता है कि vendor partner के अनुसार यह काम करेगा या नहीं
  • Chrome Google Pay, Safari Apple Pay, Edge Microsoft integration का उपयोग करते हैं, जबकि Firefox unsupported है
  • region-wise support, UX, और अतिरिक्त user settings की जरूरत browser के अनुसार अलग-अलग है
  • नतीजतन, हर payment method के लिए अलग contract और handling logic की जरूरत पड़ती है

Push API और vendor-विशिष्ट notification network

  • Push API standard है, लेकिन वास्तविक notification delivery के लिए browser के अनुसार server infrastructure अलग होता है
  • Chrome/Edge FCM, Safari APNs, और Firefox Mozilla Push Service का उपयोग करते हैं
  • delivery limits, message size, offline handling, privacy policy service के अनुसार भिन्न हैं
  • vendor infrastructure में outage होने पर उस browser की push functionality पूरी तरह प्रभावित हो सकती है

Media API, codec, और DRM समस्याएं

  • Media Source Extensions(MSE) और Encrypted Media Extensions(EME) standard हैं, लेकिन codec और DRM license के अनुसार support बदलता है
  • Chrome·Edge·Firefox Widevine का उपयोग करते हैं, Safari FairPlay का उपयोग करता है; यानी पूरी तरह proprietary technology पर निर्भरता है
  • browser vendor के अनुसार पसंदीदा codec और strategy अलग हैं
  • DRM license cost और तकनीकी constraints के कारण छोटे browser के लिए support देना कठिन है

in-browser AI API का उभार: एक नई proprietary संरचना

  • Chrome Gemini Nano-आधारित AI API (summary, translation, proofreading आदि) का परीक्षण कर रहा है
  • local execution होने से data transmission नहीं होता, लेकिन model size (लगभग 4GB) और GPU requirement अधिक है, और यह Google का proprietary model है
  • दूसरे browsers को अपने model विकसित करने होंगे, और छोटे browser या open source project समान model हासिल या बनाए नहीं रख सकते, इसलिए प्रतिस्पर्धा करना मुश्किल है
  • यह AI-आधारित vendor dependency की नई संरचना है

यह क्यों महत्वपूर्ण है

  • portability problem: एक ही code होने पर भी browser, region, और environment के अनुसार behavior quality बदल सकती है
  • privacy risk: voice, location, और push data अनजाने में vendor server पर भेजा जा सकता है
  • standardization imbalance: बड़ी कंपनियां spec writing और implementation को lead करती हैं, और अपने infrastructure को de facto requirement बना देती हैं, जिससे छोटे browser बाहर हो जाते हैं
  • developer impact: feature उपयोगी हैं, लेकिन इन्हें standard नहीं बल्कि service dependency के रूप में समझना चाहिए

developers को क्या approach अपनानी चाहिए

  • API को vendor service abstraction layer के रूप में समझें, और testing, documentation, तथा alternative path तैयार रखें
  • graceful degradation design से feature mismatch के लिए तैयारी रखें
  • privacy transparency सुनिश्चित करें: data के third-party server पर भेजे जाने की संभावना स्पष्ट करें
  • vendor dependency management: service shutdown या policy change की स्थिति में response plan होना चाहिए
  • browser और region-wise testing से quality differences की जांच करें
  • strategic choice के जरिए vendor dependency को न्यूनतम करें

हम जिस web की कल्पना करते हैं बनाम वास्तविक web

  • standardized API call एक जैसी हो सकती है, लेकिन data flow, accuracy, regional support, privacy, cost structure browser के अनुसार अलग होते हैं
    • navigator.geolocation.getCurrentPosition() call वास्तव में Google या Apple location service को call करने जैसा है
  • standard spec केवल interface को define करती है, जबकि वास्तविक behavior vendor infrastructure और policy पर निर्भर होता है
    • API call करना यानी किसी विशेष vendor के server, policy, और business model का उपयोग करना
  • web platform शक्तिशाली है, लेकिन वास्तव में यह और अधिक fragmented और vendor-centric संरचना है
  • developers को standard और implementation की सीमा स्पष्ट रूप से समझकर design करना चाहिए

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.