जापान: Apple को दिसंबर तक browser engine प्रतिबंध हटाना होगा
(open-web-advocacy.org)- जापान सरकार ने हाल ही में स्मार्टफोन कानून पारित किया है, जो Apple के iOS में थर्ड-पार्टी browser engine पर प्रतिबंध को सीधे तौर पर प्रतिबंधित करता है
- अब तक WebKit engine की अनिवार्यता के कारण iOS पर browser competition लगभग अवरुद्ध था, और web apps की प्रतिस्पर्धात्मकता कम हुई थी
- नई guidelines स्पष्ट करती हैं कि Apple को तकनीकी या व्यावसायिक रूप से अव्यावहारिक बाधाएं पैदा करने की भी अनुमति नहीं होगी
- साथ ही browsers के लिए OS API access कार्यात्मक रूप से समान स्तर पर सुनिश्चित किया जाना चाहिए, और भेदभावपूर्ण performance degradation की अनुमति नहीं होगी
- जापानी कानून के लागू होने से EU और UK के साथ मिलकर browser competition की बहाली के लिए नियामकीय वातावरण बन रहा है, और 2026 एक turning point हो सकता है
जापान, Apple से browser engine प्रतिबंध हटाने की मांग
जापान ने हाल ही में आधिकारिक रूप से ‘स्मार्टफोन सॉफ्टवेयर प्रतिस्पर्धा प्रोत्साहन कानून’ पारित किया है, जिसके तहत Apple की iOS में थर्ड-पार्टी browser engines पर लंबे समय से लागू नीति को सीधे तौर पर प्रतिबंधित करने वाला प्रावधान लागू किया गया है
browser engine प्रतिबंध की वर्तमान स्थिति
- पहले Apple केवल WebKit engine के उपयोग की अनुमति देता था, जिससे Firefox, Chrome, Edge, Opera, Brave, Vivaldi जैसे सभी प्रमुख browser engines को iOS से प्रभावी रूप से बाहर रखा जाता था
- इसके परिणामस्वरूप browser competition व्यावहारिक रूप से अवरुद्ध हो गई, और web apps ऐसी APIs या performance का उपयोग नहीं कर पाती थीं जो native apps के बराबर प्रतिस्पर्धा के लिए आवश्यक हैं
जापान का कानून और guidelines
- यह कानून Digital Market Competition Headquarters की रिपोर्ट के आधार पर तैयार किया गया था, और इसमें Open Web Advocacy की सलाह भी शामिल की गई
- हाल ही में Mobile Software Competition Act (MSCA) guidelines प्रकाशित की गईं, जो कानून की वास्तविक व्याख्या और उसे लागू करने के तरीके को स्पष्ट रूप से बताती हैं
वैकल्पिक browser engines में बाधा डालने पर रोक
- guidelines थर्ड-पार्टी browser engines की शुरुआत को बाधित या कमजोर करने वाली सभी कार्रवाइयों पर स्पष्ट रूप से रोक लगाती हैं
- इसमें app providers पर अत्यधिक तकनीकी प्रतिबंध लगाना, उन पर लागत का बोझ डालना, या users को वैकल्पिक browsers से दूर करने वाले उपाय शामिल हैं
- बाधा की पहचान करते समय केवल स्पष्ट निषेध ही नहीं, बल्कि ऐसे मामले भी शामिल होंगे जहां वास्तविक रूप से अपनाने की संभावना उल्लेखनीय रूप से कम हो जाए
- इसका अर्थ है कि Apple नाममात्र की अनुमति देकर भी ऐसी स्थिति नहीं बना सकता, जिसमें उपयोग व्यावहारिक रूप से असंभव हो या व्यावसायिक रूप से अर्थहीन हो
OS API access की कार्यात्मक समानता
- MSCA यह निर्धारित करता है कि OS API access के लिए कार्यात्मक रूप से समान access सुनिश्चित किया जाए
- वैकल्पिक APIs की अनुमति दी जा सकती है, लेकिन यदि performance वास्तविक रूप से काफी कमजोर हो तो उसे कार्यात्मक समानता नहीं माना जाएगा
- यानी तकनीकी तरीका अलग हो सकता है, लेकिन Apple जैसे निर्दिष्ट providers को जो समान performance और accessibility मिलती है, वही थर्ड-पार्टी browsers को भी मिलनी चाहिए
browser choice screen की अनिवार्यता
- यह कानून browsers (और अन्य software) के लिए choice screen उपलब्ध कराना अनिवार्य बनाता है
- यह EU से भी अधिक सख्त निर्देश है, जिसके अनुसार "पहले activation के तुरंत बाद" choice screen दिखानी होगी
- smartphone की पहली setup प्रक्रिया के दौरान या संबंधित app के पहले launch पर, user को विशिष्ट software चुनने के लिए प्रेरित किया जाना चाहिए
आगे की दिशा
- Mobile Software Competition Act का दिसंबर 2025 से लागू होना निर्धारित है
- जापान EU और UK के साथ उन देशों में शामिल हो रहा है जहां Apple को थर्ड-पार्टी browser engines की अनुमति देनी होगी
- उम्मीद है कि जापान यूरोप और UK के नियामकीय अनुभवों को ध्यान में रखकर enforcement की तैयारी करेगा
- जैसा कि EU और UK के मामलों में देखा गया है, वास्तविक enforcement लंबी और जटिल प्रक्रिया हो सकती है
निष्कर्ष और संकेत
- जापान, EU और UK तीनों ही Apple पर थर्ड-पार्टी browser engine support अनिवार्य करके iOS पर वास्तविक browser competition बहाल करने की दिशा में आगे बढ़ रहे हैं
- 2026 browser market structure में बदलाव का turning point बन सकता है
- अंतिम सफलता इस बात पर निर्भर करेगी कि regulators enforcement के प्रति कितने प्रतिबद्ध हैं और Apple वास्तविक सुधार के लिए कितना प्रयास करता है
- browser और web app competition environment को बेहतर बनाने के लिए लंबे समय से काम कर रही जापानी सरकार और संबंधित संगठनों की भूमिका प्रमुख रूप से उभरती है
7 टिप्पणियां
हम्म... मेरी राय में यह थोड़ा अफ़सोस की बात है, क्योंकि अगर सभी browsing फीचर्स base library के ज़रिए चलते हों, तो सिस्टम किसी खास URL को block करने पर सभी ऐप्स की internal browsing फीचर्स में ऐसी अच्छी consistency मिलती है जिसे bypass नहीं किया जा सकता.
AI ब्राउज़र के उभार की उम्मीद है
डेवलपर के नज़रिए से देखें तो इसका मतलब होगा कि अब ध्यान में रखने वाले environments और भी बढ़ जाएंगे हाहा..
अब वेब standards के मुताबिक development करना चाहिए। जो features मौजूद नहीं हैं, उनका सक्रिय रूप से इस्तेमाल नहीं करना चाहिए।
संख्या ज़्यादा लगती है, लेकिन आखिर में क्या यह Firefox और Chromium engine ही नहीं हैं?
प्रतिबंध की मौजूदा स्थिति में जिन engines की सूची का ज़िक्र है, उसे देखकर ही चक्कर आने लगता है @_@
Hacker News राय
सब लोग Chrome की बात कर रहे हैं, लेकिन मैंने Android पर Chrome बंद करके Firefox इस्तेमाल किया हुआ है। मोबाइल Firefox में uBlock Origin के साथ अनुभव लगभग desktop web जैसा लगता है। सिर्फ ad blocking ही नहीं, बल्कि
:has-textजैसी RegEx rules से उन elements को भी तुरंत block कर सकता हूँ जिनकी मुझे परवाह नहीं। Chrome अब desktop पर भी ऐसा नहीं कर पाता। मैं तो यह तक सोच रहा हूँ कि Android को ही अपना main device बना लूँ। बस iMessage की वजह से MacBook से सीधे chat reply करने की सुविधा इतनी काम की है कि इसे आसानी से छोड़ नहीं पाता। उसे छोड़ दें तो Android कुल मिलाकर काफी बेहतर है। iOS keyboard या Siri की बात तो शुरू भी न करेंFF और uBO का combination ही वह killer app है जिसने मुझे Android पर बनाए रखा है। अगर Apple ने इसे allow किया होता, तो मैं कब का switch कर चुका होता। क्या आपने कभी messages.google.com पर विचार किया है? इसके लिए Google का Messages app चाहिए (Samsung Messages नहीं), और इससे desktop पर SMS और RCS इस्तेमाल कर सकते हैं, इसलिए यह iMessage का अच्छा विकल्प है
मोबाइल Firefox में consent-o-matic extension भी वाकई बहुत काम का है। यह लगभग सारे cookie banners को अपने-आप क्लिक करके आगे बढ़ा देता है, इसलिए मोबाइल पर हर बार खुद निपटना नहीं पड़ता और काफी सुविधा हो जाती है
मैं भी https://messages.google.com इस्तेमाल करके Android-based desktop iMessage जैसा setup बनाता हूँ। शायद यह आपके use case में भी फिट बैठे? मैं iMessage इस्तेमाल नहीं करता, इसलिए पूरी तरह कहना मुश्किल है
अगर iMessage के बिना सिर्फ SMS से काम चल सकता है, तो KDE Connect के जरिए Android से शानदार desktop messaging किया जा सकता है (Linux, Windows, MacOS पर इस्तेमाल हो सकता है, platform के हिसाब से features में फर्क है लेकिन SMS सब पर supported है)। https://kdeconnect.kde.org/
लगता है जापान ने EU में Apple की ‘शब्दों का खेल वाली compliance’ से सबक लिया है। अगर Apple फिर इसी तरह निकला, तो उम्मीद है कि जापान में उसे सचमुच असर करने वाला proper fine मिले। मुझे लगता है यह “if” नहीं बल्कि “when” का मामला है
मैं तो बिक्री और आयात पर रोक की कल्पना भी करता हूँ; तब देखना दिलचस्प होगा कि Apple Store कितने समय तक बंद रहने पर Apple घुटने टेकता है
मुझे ऐसा walled garden पसंद है जो मुझे खुद से गलती करने से बचाता है। Apple मेरी location यूँ ही इधर-उधर नहीं बाँट देता या कोई अजीब Monarch मेरा पीछा नहीं करता, इसलिए privacy leak की चिंता भी कम रहती है और इसके लिए मैं आभारी हूँ। (+4500 upvotes) Reddit पर anti-Apple headlines को +30k upvotes मिलते थे, लेकिन pro-Apple comments उनके मुकाबले बहुत कम दिखते थे, इसलिए मुझे हमेशा शक होता था। लगता था शायद marketing teams या troll farms reputation management कर रहे हों
अगर यह global legislative movement iOS पर एक ज्यादा खुला app ecosystem लाती है, तो उसका सच में स्वागत होना चाहिए। BrowserEngineKit बस XPC और iOS extension system पर एक पतला wrapper भर है। अगर XPC एक open API होता, और Apple की अनुमति के बिना isolated subprocesses में JIT की इजाज़त होती, तो development कहीं बेहतर होता। उदाहरण के लिए, messaging apps untrusted input handle करने के लिए अलग subprocess रख सकतीं (iMessage यह पहले से करता है), app के unstable components को isolate करके usability और crash recovery बेहतर की जा सकती, retro system emulators बहुत तेज हो सकते, iOS पर WASM का उपयोग संभव हो जाता, और browsers भी किसी special-purpose API के बिना XPC का इस्तेमाल कर सकते। समस्या यह है कि अगर यह सब संभव हो जाए, तो App Store review के बाद भी app के अंदर native speed पर चलने वाला code लोड करना आसान हो जाएगा, और जैसा कि हम सब जानते हैं, कहा यही जाता है कि ऐसी दुनिया आ गई तो मानो आपदा आ जाएगी
अगर वह ‘आपदा’ आती है, तो मैं MacRumors जैसी sites पर लोगों को घबराते देखना चाहूँगा। यह मानना मुश्किल है कि Apple अपने आर्थिक हित में internet narrative को push करने वाली sites को sponsor या प्रोत्साहित नहीं करता होगा। उदाहरण के लिए, यह बेहूदा राय कि लोगों को अपने phone का स्वतंत्र रूप से इस्तेमाल करने की आज़ादी देना सबकी security और privacy को खतरे में डालता है, practically बार-बार दोहराई जाती रही है
ऐसा करने पर system-level malware prevention का बहुत बड़ा बोझ app sandboxing पर आ जाएगा। दरअसल sandbox अभी भी notarization, permissions, app review जैसी कई defense layers में से सिर्फ एक layer रहा है। मैं भी इस बात के पक्ष में हूँ कि users जो app चाहें install कर सकें, लेकिन तब यह भी मानना होगा कि इससे सामान्य iPhone Android की तरह malware infection के लिए अधिक exposed हो जाएगा। Apple ऐसी policies सिर्फ monopoly की चाह में नहीं रखता; इसके पीछे वास्तविक security concerns भी हैं (भले ही मुख्य प्रेरक लाभ ही हो)
Browser खुद भी एक तरह का app store है, इसलिए हम वहाँ हर समय Apple की review के बिना apps चलाते ही रहते हैं। इस संदर्भ में मुझे कभी ठीक से समझ नहीं आया कि Apple और उसके fans App Store की security को इतना क्यों बढ़ा-चढ़ाकर बताते हैं
JIT की अनुमति मिल जाए तो बात सिर्फ fast emulation तक सीमित नहीं रहती; interpreter के चक्कर कम होने से efficiency भी बेहतर होती है, battery life management सुधर सकता है, और 2008 के games चलाते समय phone heating जैसी समस्या भी कम हो सकती है
(अर्थहीन राय छोड़ी गई)
अगर “blocking possibility” की व्याख्या व्यापक रूप से की जाए, तो उदाहरण के लिए “alternative browser engines को सिर्फ Japan Apple accounts पर रिलीज़ करने लायक region-lock लगा देना” भी मूलतः alternative browsers के वास्तविक अस्तित्व को रोकना माना जा सकता है। अगर ऐसा हुआ तो Mozilla के लिए target audience इतनी छोटी रह जाएगी कि iOS के लिए Firefox port करने का कोई मतलब नहीं बचेगा। इसकी संभावना कम है, लेकिन शायद यही global browser choice की दिशा में छोटा-सा शुरुआती कदम बन सकता है
Region-lock लगाकर सिर्फ कुछ accounts पर alternative browser engines की अनुमति देना, Apple EU में जो कर रहा है उनमें से एक है
मेरी जानकारी में Gecko (Firefox engine) पहले ही iOS पर port किया जा चुका है
market share पहले ही कम है, तो क्या उसे बढ़ाने के लिए सिर्फ मुट्ठीभर अतिरिक्त users के लिए port किया जाएगा, इस पर संदेह है
Mozilla वैसे भी कम market share का आदी संगठन है। यह स्थिति भी बहुत अलग नहीं होगी, बल्कि market खुलने से पहले users के जरिए QA version distribute करने का अवसर भी बन सकती है
EU और UK के बाद अब जापान भी iOS पर alternative browser engines पर लगी रोक को खत्म कर रहा है। तीनों ही बड़े markets हैं, इसलिए सोचता हूँ कि क्या इससे Chrome या Firefox को iOS के लिए अपने engine वाले versions (यानी Blink और Gecko based browsers) में निवेश करने की पर्याप्त motivation मिलेगी। लंबे समय से यह अफवाह थी कि इसी वजह से development अटका हुआ था
उसी site पर देखा कि Apple अब भी बड़े browser vendors को अपना engine ship करने से रोकने के लिए तरह-तरह की अड़चनें डाल रहा है संबंधित ब्लॉग
UK के मामले में, मेरी समझ है कि 2024 के Digital Markets Act जैसे संबंधित कानूनों को सरकार बहुत ढीले ढंग से लागू कर रही है
जापानी संस्कृति के हिसाब से इस बदलाव को लेकर बहुत ज्यादा हलचल शायद न हो। जापान में Linux adoption को देखें तो कुछ उत्साही power users चाहे जो हो जाए इस्तेमाल करते रहते हैं, लेकिन आम लोग बस वही इस्तेमाल करते हैं जो आसान और सुविधाजनक हो। वे systems या settings में बहुत छेड़छाड़ करना पसंद नहीं करते
एक नज़रिया यह भी है कि Apple ने browser developers के लिए हालात इतने मुश्किल बना दिए कि कोई भी उस barrier को पार नहीं कर पाया
सोचता हूँ कि क्या Firefox का Blink पर switch करके Google के साथ मिलकर iOS के लिए alternative engine बनाना ज्यादा practical और आसान विकल्प होगा
सोचता हूँ कि क्या यह बदलाव वास्तव में अच्छी चीज़ है। क्या इससे market में Chromium का share और नहीं बढ़ जाएगा?
Safari संरचनात्मक रूप से अच्छा browser नहीं है। Apple के हित इसी में हैं कि web platform को जानबूझकर कमजोर रखा जाए। अगर कोई browser users को मजबूर किए बिना चुना नहीं जा सकता, तो असली market competition वही है जिसमें लोग अपने-आप बेहतर browser चुनें
हाँ, यह सही है। आखिरकार iOS पर पूरे web को “All Chrome Everywhere” बनने से रोकने वाली आखिरी दीवार Safari ही था
सरकारें market monopoly का समाधान कर सकती हैं US Department of Justice vs Google मुकदमा wiki
सही, इसी वजह से दुविधा है। एक तरफ Apple को iOS और खुला बनाने के लिए मजबूर करना ज़रूरी है, लेकिन दूसरी तरफ इससे आखिरकार Chrome की monopoly और मजबूत हो सकती है
iOS पर एक proper Firefox चल पाने का फायदा बड़ा है। और यह सकारात्मक बदलाव है। इससे web standards पर Apple का वह अनुचित प्रभाव कम होगा जिसमें वह अपने हित के लिए standards को कमजोर करता है (जैसे WebGPU में SPIR-V support को रोकना)
(Narrator) एक साल बाद जापान में Chrome का share 100% तक पहुँच गया, और सारी websites सिर्फ इसी browser के लिए design की जाने लगीं
जापान का Apple के साथ एक अनोखा रिश्ता है। उदाहरण के लिए, Felica (जापानी NFC system) आधारित ticketing feature हर iPhone में built-in है, इसलिए दुनिया भर के iOS users भी जापान में कहीं ज्यादा सुविधा से रह सकते हैं। और सबसे दिलचस्प बात यह है कि असली tickets इस्तेमाल करने के लिए किसी app की भी जरूरत नहीं, सिर्फ Apple Pay काफी है। यह रुझान धीरे-धीरे native apps के फायदों की सीमा को छोटा कर रहा है (हालाँकि अभी भी native apps की अपनी अलग खूबियाँ हैं), लेकिन दूसरी ओर इस दलील का जवाब देना कठिन है कि Apple आखिरकार अपना ‘gatekeeper role’ बस दूसरे क्षेत्रों में शिफ्ट कर देता है
FeliCa network support का मुख्य कारण यह है कि जापान में mobile transit और payment technology iPhone से पहले ही स्थापित हो चुकी थी। वहाँ Mobile Suica और Osaifu-Keitai पहले से मौजूद थे, इसलिए Apple को competitive बने रहने के लिए सक्रिय रूप से साथ आना पड़ा। शुरुआत Japan-only SKU iPhone से हुई और बाद में यह globally फैली। यहाँ तक कि आज भी जापान में mobile payments market monopoly नहीं है। जब Apple पर competitive pressure पड़ता है, तो बदलाव आते हैं, जैसे Suica जैसी express transit support जोड़ना। और PayPay जैसी जापानी QR code payment apps वहाँ credit card payments से भी ज्यादा प्रचलित हैं
जापान में iOS का share अमेरिका (59%), UK (47%) या यूरोप (34%) से भी ज्यादा, 64% है statcounter स्रोत
FeliCa पेटेंट licensing का मामला है। लगता है Apple ने कहीं कोई फायदेमंद deal हासिल कर ली। Google Pixel में भी chip मौजूद होती है, लेकिन जापानी model न होने पर यह feature software से block रहता है (root करने पर खोला जा सकता है)
“कर सकने की ताकत” का असर साफ दिखता है। एक देश अगर कर दिखाए, तो दूसरे देश, जो 20 साल से कह रहे थे कि यह असंभव है, वे भी बदलने लगते हैं और सोचते हैं, ‘हम भी कर सकते हैं, पीछे नहीं रह सकते’
यह मानना पड़ता है कि Google लगातार इस तैयारी में रहा होगा कि iOS पर ‘real’ Chrome ला सके। शायद कानून बदलते ही तुरंत launch करने के लिए वह इसे बहुत पहले से बना रहा होगा?
Google Blink (iOS के लिए Chrome engine) को port कर रहा है और धीरे-धीरे प्रगति हो रही है। Chromium bug tracker में इसकी tracking मौजूद है tracking link। शायद Apple की regional lock (EU geofencing) policy और BrowserEngineKit की कई restrictions की वजह से अभी production deployment के लिए resources पूरी तरह नहीं लगाए गए हैं
फ़रवरी 2023: “Google ने iOS पर Apple WebKit के बजाय Blink engine के साथ Chrome चलाने पर काम शुरू किया” संबंधित लेख
(Blink, Chrome का web rendering engine है) iOS के लिए Chromium/Chrome build करने की official documentation में लिखा है कि ‘blink web platform’ experimental है और इसे सिर्फ analysis के लिए इस्तेमाल किया जाए। इसमें यह भी कहा गया है कि संबंधित targets के रूप में
content_shellऔरchromeउपयोगी हैं। official build docs