प्लेटफ़ॉर्म टिल्ट

 (mozilla.github.io)
1 पॉइंट द्वारा GN⁺ 2024-01-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mozilla का Platform Tilt प्रमुख सॉफ़्टवेयर प्लेटफ़ॉर्म पर Firefox के अपनी ही 1st-party ब्राउज़र की तुलना में नुकसान में पड़ने वाली तकनीकी स्थितियों को ट्रैक करता है, और security, stability, performance और features के लिहाज़ से प्रतिस्पर्धी अंतर को उजागर करता है
  • Apple से जुड़े मुद्दे सबसे व्यापक हैं, जिनमें third-party browser engine पर प्रतिबंध, iOS में multi-process, JIT और accessibility API की सीमाएँ, default browser सेटिंग, extension और beta distribution, तथा home screen web app हैंडलिंग शामिल हैं
  • Google Android में मुख्य मुद्दे हैं browser data import API का अभाव, Google apps का default browser की बजाय Chrome खोलने वाला flow, और Firefox Android को low-quality search results page दिए जाने के उदाहरण
  • Microsoft Windows में third-party browsers के लिए default browser को programmatically सेट करना मुश्किल है, और Search, Copilot, Widgets जैसे flows Edge को प्राथमिकता देते हैं
  • सामान्य रूप से, उपयोगकर्ता का default browser चयन, browsers के बीच data migration, engine features, तथा distribution, testing और extension accessibility हर प्लेटफ़ॉर्म पर उसके अपने browser के पक्ष में काम करते हैं

Platform Tilt क्या ट्रैक करता है

  • Platform Tilt एक dashboard है जो प्रमुख सॉफ़्टवेयर प्लेटफ़ॉर्म पर Firefox के 1st-party browser की तुलना में नुकसान में पड़ने वाले तकनीकी मामलों को ट्रैक करता है
  • इसका दायरा security, stability, performance और features है, और यह अधिक समतल प्रतिस्पर्धी माहौल बनाने के लिए बदलावों का सुझाव देता है
  • real-time issue discussion platform-tilt issue tracker पर चलती है

Apple प्लेटफ़ॉर्म पर browser engine और iOS feature सीमाएँ

  • App Store forbids third-party browser engines: Apple App Store Review Guidelines का Rule 2.5.6 यह मांग करता है कि web browsing apps उचित WebKit framework और WebKit JavaScript का उपयोग करें
    • इस नीति के कारण Firefox को iOS पर Gecko के साथ वितरित नहीं किया जा सकता
    • यह macOS जैसे अन्य Apple प्लेटफ़ॉर्म पर भी App Store के माध्यम से Firefox distribution को प्रभावित करता है
    • App Store नीति को बदलकर web browsers में third-party browser engines की अनुमति देनी चाहिए
  • Support for third-party multi-process applications on iOS: आधुनिक web browsers multi-process architecture का उपयोग करते हैं, जिसमें site-specific processes और GPU जैसी संवेदनशील क्षमताओं के लिए dedicated processes शामिल होते हैं
    • Safari iOS पर multi-process structure का उपयोग करता है, लेकिन Safari के WebKit engine का उपयोग न करने वाले third-party apps को वही mechanism नहीं मिलता
    • iOS को isolated child processes बनाने और कुशल संचार के लिए mechanism प्रदान करना चाहिए
    • आवश्यकताओं में उपयोगकर्ता के browsing behavior के अनुसार child processes की संख्या और lifetime, restricted permission settings, messaging और shared memory, read/write या read-only shared memory regions, parent और child processes के independent entitlements, bundle के भीतर library loading, तथा Metal या OpenGL के जरिए IOSurface rendering और processes के बीच sharing शामिल हैं
    • Firefox कई operating systems में shared codebase का उपयोग करता है, इसलिए process management interface और behavior मोटे तौर पर macOS और Android जैसे अन्य प्लेटफ़ॉर्म के समान होने चाहिए
  • JIT Support on iOS: उच्च प्रदर्शन वाले JavaScript/WebAssembly engine को deploy करने के लिए browser process को ऐसे memory regions बनाने में सक्षम होना चाहिए जो writable भी हों और executable भी
    • iOS apps mmap(2) system call के जरिए ऐसे memory permissions नहीं बना सकते
    • Safari के WebKit rendering engine को अपवाद प्राप्त है, इसलिए वह writable-executable memory regions बना सकता है
    • macOS में Hardened Runtime entitlement com.apple.security.cs.allow-jit जैसा प्रावधान है, और iOS को भी non-WebKit browsers के लिए समकक्ष entitlement तथा pthread_jit_write_protect_np, sys_icache_invalidate API उपयोग की अनुमति देनी चाहिए
  • Accessibility APIs on iOS: iOS accessibility API documentation अधूरी है, और web browsers को accessibility web standards support करने के लिए जिन APIs की ज़रूरत है, उनमें से कई documented नहीं हैं
    • WebKit में runtime पर load होने वाला closed-source system bundle मौजूद प्रतीत होता है, जिससे इसके उपयोग के तरीके का अनुमान लगाना भी कठिन है
    • “visited”, “radio button” जैसे trait integer constants और “value changed” जैसे notification type integer constants में से कुछ सार्वजनिक नहीं हैं
    • WebKit द्वारा उपयोग किए जाने वाले सभी accessibility APIs documented और stable होने चाहिए, और आदर्श रूप से WebKit को भी इन्हें उसी तरह उपयोग करना चाहिए जैसे third-party browser engines करते हैं

Apple प्लेटफ़ॉर्म पर यूज़र अनुभव, वितरण और विस्तार क्षमता की खाई

  • Messages integration on iOS: iOS Safari होम पेज Messages app में हाल ही में मिले लिंक और भेजे गए contacts दिखाता है, लेकिन third-party browsers के पास Messages data की access permission नहीं होती, इसलिए वे वही सुविधा नहीं दे सकते

  • Importing browser data on iOS: iOS में browsing data जैसे history, bookmarks और cookies तक third-party browsers की पहुंच नहीं होती, और import API भी नहीं है

    • यह data संवेदनशील है, लेकिन प्रमुख desktop platforms पर इसी तरह की import सुविधा संभव है
    • iOS health·fitness data की तरह user consent के साथ संवेदनशील data access को नियंत्रित कर सकता है
    • data import संभव न होने पर Safari से दूसरे browser पर switch करते समय friction पैदा होता है

  • Setting and checking default browser on iOS: iOS third-party browsers को खुद को default browser के रूप में सेट करने के लिए system prompt दिखाने की सुविधा नहीं देता

    • Android browser role request के जरिए, और macOS LSSetDefaultHandlerForURLScheme तथा LSSetDefaultRoleHandlerForContentType के जरिए ऐसी ही सुविधा देता है
    • iOS browsers सिर्फ Settings UI के लिए deep link दे सकते हैं, और user को settings screen समझकर खुद बदलाव करना पड़ता है
    • iOS 17.2.1 में Settings search में “Default browser app” या “Default” टाइप करने पर भी default browser बदलने का विकल्प न दिखने के मामले हैं
    • third-party browsers यह भी detect नहीं कर सकते कि वे अभी default browser हैं या नहीं, इसलिए user intent के आधार पर browser को optimize करना या सही समय पर default browser बदलने का अनुरोध करना कठिन है

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: non-WebKit browsers को password autofill, one-time codes, passkeys, Apple Pay support करने के लिए web content origin-आधारित associated domain निर्दिष्ट करने में सक्षम होना चाहिए

    • WebKit-आधारित browsers browser app के associated domain को उस domain से override कर सकते हैं जिसे user ब्राउज़ कर रहा है
    • उदाहरण के लिए, example.com के password input field में browser को यह दिखाना चाहिए कि वह field example.com origin से संबंधित है, ताकि password manager को example.com scope में बुलाया जा सके
    • Apple Pay support के लिए Safari की तरह registered Apple Pay recipients के लिए payment स्वीकार करने हेतु अतिरिक्त बदलाव की ज़रूरत पड़ सकती है

  • Browser extension support on iOS: Safari iOS App Store के जरिए वितरित extensions को support करता है, लेकिन third-party browsers के लिए App Store Review Guidelines 2.5.2 की वजह से अपनी extension functionality देना मुश्किल है

    • browser extensions web ecosystem का एक मुख्य हिस्सा हैं, और ये developers को browser में features जोड़कर utility, usability और system apps के साथ interoperability बढ़ाने देते हैं
    • third-party browsers को अपना extension catalog इस्तेमाल करने देने के लिए App Store software requirements को ढीला किया जाना चाहिए

  • Beta testing on iOS: iOS में App Store पर beta version apps वितरित नहीं किए जा सकते और TestFlight का उपयोग करना पड़ता है

    • TestFlight में 10,000 users की सीमा है, जो बड़े browsers के beta user scale की तुलना में कम है
    • सीमा पूरी होने पर पुराने users को manually हटाना पड़ता है, जिससे maintenance burden बढ़ता है
    • users को TestFlight app install करना, access code के लिए request करना, waitlist में रहना और code दर्ज करने जैसी प्रक्रिया से गुजरना पड़ता है
    • Safari के नए versions iOS operating system beta में शामिल होते हैं, इसलिए उन पर यही सीमा लागू नहीं होती
    • समाधान के तौर पर browsers को App Store pre-release build distribution की अनुमति देना, या TestFlight user limit हटाकर public links की unlimited distribution की अनुमति देने का प्रस्ताव है

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: iOS और macOS के Search Web या Search with <Search Engine> context menu, और macOS menu bar के Services search entry points default browser की परवाह किए बिना Safari में search चलाते हैं

  • SFSafariViewController should respect the user’s default browser: SFSafariViewController एक high-level API है जो iOS apps को web content rendering यूज़र के browser पर छोड़ते हुए उसे app के अंदर embed करने देता है

    • यह API user के default browser की परवाह किए बिना हमेशा Safari version का उपयोग करता है
    • web content display experience असंगत हो जाता है, और traffic alternative browsers से बाहर चला जाता है

  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS: Apple का मौजूदा प्रस्ताव यह मांगता है कि अपना browser engine इस्तेमाल करने वाले browser vendors मौजूदा app को update करने के बजाय EU में अलग app वितरित करें

    • मौजूदा EU users को नए app पर migrate करना होगा, जो व्यावहारिक रूप से कठिन है और competition barrier बनाता है
    • Firefox की चिंताओं में WebKit Firefox से Gecko Firefox तक discovery और migration की कठिनाई, Gecko Firefox EU users का EU के बाहर 30 दिन से अधिक रहने पर access खो देना, और EU में स्थायी रूप से स्थानांतरित हुए non-EU WebKit Firefox users का update न होने वाले “orphaned” version पर रह जाना शामिल है
    • browser developers को पूरी तरह अलग दो apps develop, maintain और distribute करने पड़ते हैं, जिससे data migration complexity, user churn, कम acquisition, और EU iOS users के लिए दोहराए जाने वाले A/B rollout restrictions जैसी समस्याएं पैदा होती हैं
    • विकल्प के रूप में दुनिया भर में एक single binary और bundle में दोनों engines के webview शामिल करने, और app launch के समय OS द्वारा BrowserEngineKit eligibility की सूचना app को देने का प्रस्ताव है

  • Web developers should be able to test with alternative browser engines on iOS regardless of location: जब BrowserEngineKit पहली बार घोषित किया गया था, तब EU के बाहर के डिवाइसों पर अपने इंजन का परीक्षण रोकने वाली location restriction मौजूद थी

    • 18.2 beta में यह पाबंदी local development और testing के लिए हटा दी गई, लेकिन web developers के लिए यह अब भी बनी हुई है
    • EU के बाहर के web developers भी EU users को support कर सकते हैं, इसलिए location की परवाह किए बिना alternative browser engines पर sites को आसानी से test करने के लिए एक mechanism की ज़रूरत है

  • Browsers with alternative engines should be able to install and manage home screen web apps on iOS: alternative browser engines के लिए iOS home screen पर web apps जोड़ने का API मौजूद है, लेकिन वे apps Safari में खुलते हैं

    • install से पहले और बाद में engine-specific features, user state और preferences अलग हो जाते हैं, जिससे अनुभव बंट जाता है
    • Apple ने security का हवाला देते हुए non-WebKit engines को home screen web apps render करने की अनुमति देने का विरोध किया है
    • home screen web apps के बुनियादी security requirements वही हैं जो सामान्य web browsing में पहले से लागू cross-site sandboxing और isolation requirements हैं
    • Android कई वर्षों से web app rendering को third-party browser engines को सौंपता रहा है, और iOS में भी इसे सक्षम किया जाना चाहिए

Google Android में डेटा माइग्रेशन·डिफ़ॉल्ट ब्राउज़र·सर्च अनुभव

  • Importing browser data on Android: Android में browsing data जैसे history, bookmarks, cookies तक third-party browsers पहुंच नहीं सकते
    • डेटा web browser app की data directory में रखा जाता है, और third-party browsers इसे सीधे access नहीं कर सकते
    • import को संभव बनाने वाला कोई API या ContentProvider भी नहीं है
    • data import की कमी Chrome से दूसरे browser पर switch करने में बड़ा friction पैदा करती है
  • Some Android features launch Chrome instead of the user’s default browser: पहले से इंस्टॉल Google application की Google Search, Discover जैसी features उपयोगकर्ता की default browser पसंद को नज़रअंदाज़ करती हैं और external website links हमेशा Chrome में खोलती हैं
    • home screen search bar और app launcher जैसी built-in features में भी अतिरिक्त entry points हैं
    • हर बार जब link Chrome में खुलता है, उपयोगकर्ता default browser से बाहर हो जाता है
    • external links खोलने वाले सभी built-in apps और features को उपयोगकर्ता के default browser में खुलना चाहिए
  • Lower quality search result pages in third-party browser engines on Android: Android में web search अनुभव कई built-in features के साथ गहराई से integrated है, और ऐसे मामले रहे हैं जहां Firefox को Chrome की तुलना में कम गुणवत्ता वाले search results pages दिए गए
    • एक ही search query पर Firefox Android को Chrome से कम जानकारी वाला और design quality में कमजोर page मिला
    • सख्ती से देखें तो यह Google Search website का issue है, लेकिन Android में search की अहमियत और integration level के कारण यह ऐसा user experience gap बनता है जो third-party browsers चुनने से हतोत्साहित करता है
    • Firefox में उस page को काम न करने देने वाली कोई technical limitation नहीं है
    • इस issue की स्थिति closed है

Microsoft Windows में Edge-प्राथमिकता वाले flows

  • Setting default browser on Windows: Windows third-party browsers को खुद को default browser के रूप में सेट करने का programmatic request करने की सुविधा नहीं देता
    • browser install होने के बाद भी उपयोगकर्ता को operating system settings में जाकर खुद चयन करना पड़ता है, और यह Edge के उपयोग को जारी रखने वाला friction और inertia पैदा करता है
    • Android और macOS system prompt या संबंधित API के ज़रिए ऐसा pattern देते हैं जिसमें उपयोगकर्ता आसानी से approve या reject कर सकता है
    • Windows 10 में settings UI में कई बार click करना और double confirmation देना पड़ता है, और Windows 11 में Set default बटन है, लेकिन वह पर्याप्त नहीं है
  • Default browser is set to Edge by several Windows flows: Windows 10 और 11 लगातार यह संदेश दिखाते हैं कि Microsoft Edge Windows का “recommended” browser है, और default browser को Edge में बदलने वाला UI भी देते हैं
    • कुछ wording “recommended browser settings” लागू करने के लिए पूछती है, लेकिन default browser बदलने की बात साफ़ तौर पर नहीं बताती
    • उदाहरण Windows update जैसी अपने-आप दिखने वाली UI surfaces में जोड़े और हटाए जाते रहते हैं और लगातार बदलते रहते हैं
    • Windows components उपयोगकर्ता के default browser को सीधे बदल सकते हैं, लेकिन third-party browsers को ms-settings: protocol deep link इस्तेमाल करना पड़ता है
    • Windows को भी वही functionality और API इस्तेमाल करनी चाहिए जो third-party browsers को दी जाती है
  • Some Windows features launch Edge instead of the user’s default browser: Windows की कम-से-कम तीन प्रमुख features URLs को मौजूदा default browser के बजाय Microsoft Edge में खोलती हैं
    • Windows Search या Start Menu Search taskbar search box·search button, Start Menu input, WIN+S shortcut से दिखाई देता है, और search results व article links दोनों Edge में खुलते हैं
    • Windows Copilot Windows 11 में स्क्रीन के दाहिने तरफ dock की गई window के रूप में दिखता है, और response या rendering area के links को Edge में खोलता है
    • Widgets को Windows 10 में “news and interests” कहा जाता है, यह news·weather·stocks·sports scores जैसी जानकारी दिखाता है और web page links को Edge में खोलता है

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

1 टिप्पणियां

 
GN⁺ 2024-01-21
Hacker News की राय

  • कहा जाता है कि Android और Microsoft दोनों में ऐसे ऐप्स हैं जो यूज़र के चुने हुए ब्राउज़र में नहीं, बल्कि अपने तरीके से खोलते हैं, लेकिन बड़ा मुद्दा यह है कि ऐप के अंदर लिंक दबाने पर इनबिल्ट WebView को ब्राउज़र की तरह दिखाया जाता है
    उसके अंदर की जाने वाली वेब गतिविधि को ऐप मॉनिटर कर सकता है। मेरी इच्छा है कि Android Play Store और iOS App Store सभी थर्ड-पार्टी वेबसाइटों को यूज़र के ब्राउज़र में खोलना अनिवार्य कर दें
    ऐप्स को “वेब ब्राउज़र” और “वेब ब्राउज़र नहीं” में वर्गीकृत किया जा सकता है, और “वेब ब्राउज़र नहीं” ऐप्स से कहा जा सकता है कि वे केवल थोड़े से, लगभग 5–10, एक्सेस किए जा सकने वाले डोमेन रजिस्टर करें, बाकी को ऑपरेटिंग सिस्टम ब्लॉक कर दे
    Facebook, FB Messenger, Google Maps जैसे ऐप्स, जिनका मुख्य उपयोग वेब ब्राउज़िंग नहीं है, स्पष्ट रूप से “वेब ब्राउज़र नहीं” माने जा सकते हैं
    ऐसा करने से इनबिल्ट WebView की निगरानी वाली समस्या रुक सकती है, और ब्राउज़र प्रोफ़ाइल में सिंक किए गए पासवर्ड·पते·बुकमार्क·ब्राउज़िंग हिस्ट्री वैसे ही इस्तेमाल किए जा सकते हैं। अगर मैं दुनिया को अपनी मर्ज़ी से तय कर सकता, तो लिंक खोलने वाले ऐप्स में “प्राइवेट ब्राउज़र विंडो में खोलें” वाला context menu भी अनिवार्य करना चाहता

    • निजी तौर पर मैं भी यही सोचता हूँ, लेकिन हाल में पता चला कि ज़्यादातर यूज़र ऐसा नहीं सोचते। autotempest ऐप लॉन्च करते समय मैंने कई साइटों के वाहन detail pages पर सीधे जाने वाले सभी थर्ड-पार्टी लिंक यूज़र के default browser में खुलवाए थे, लेकिन यूज़र्स को यह पसंद नहीं आया और वे ज़ोर देकर चाहते थे कि वे ऐप के अंदर ही खुलें
      इसलिए ऐप के अंदर खोलना default बना दिया, लेकिन default browser इस्तेमाल करने का विकल्प छोड़ दिया
    • इन-ऐप ब्राउज़र समस्या को हल करना Open Web Advocacy की शीर्ष प्राथमिकताओं में से एक है। हालांकि Digital Markets Act के दायरे में क्या संभव है, इसकी वजह से मामला जटिल हो जाता है
      मैं सहमत हूँ कि यह सचमुच महत्वपूर्ण मुद्दा है, और अगर आप मदद करना चाहते हैं तो Open Web Advocacy से संपर्क करें
    • Google ने तो उलटे Android developers को ठीक विपरीत दिशा में धकेलने के लिए Custom Tabs फीचर बनाया है
      ऐप्स को प्रोत्साहित किया जाता है कि वे गैर-संबंधित पेज, जैसे यूज़र द्वारा दिया गया कोई लिंक खोलते समय भी default browser की बजाय “custom tab” में खोलें, और इसका घोषित उद्देश्य यह है कि यूज़र ऐप छोड़कर न जाए ताकि engagement बनी रहे
      स्वाभाविक है कि ऐसा कोई सिस्टम-वाइड setting नहीं है जिसे यूज़र बंद कर सके; हर ऐप में setting ढूँढनी पड़ती है, और फिर उम्मीद करनी पड़ती है कि ऐसी setting मौजूद हो
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • यह पहले से कुछ हद तक संभव है, इसलिए “ब्राउज़र में खोलें” दबाया जा सकता है। हालांकि यह Google के हित में है या नहीं, पता नहीं
      Android में कैमरा जैसी runtime permissions जोड़े हुए प्रमुख versions के हिसाब से 9 पीढ़ियाँ बीत चुकी हैं, लेकिन इंटरनेट access के लिए अब भी permission की ज़रूरत नहीं होती
    • मुझे लगता है कि 2–4 में कहा गया “WebView context को sandbox करना ताकि वह वास्तविक वेब ब्राउज़िंग गतिविधि या दूसरे ऐप्स के WebView से overlap न करे” क्या 1 में कही गई बात “ऐप अपना WebView नियंत्रित कर सकता है, इसलिए यह खतरनाक है” से टकराता नहीं है?
      “एक्सेस किए जा सकने वाले डोमेन” का असल मतलब भी अस्पष्ट है। अगर सिर्फ explicitly navigate किए गए URL के domain की जाँच की जाए तो यह बहुत ढीला होगा और bypass आसान होगा; अगर सभी request URLs की जाँच की जाए तो यह इतना सख्त होगा कि कई developers अपनी ही साइट सही से load नहीं करा पाएँगे

  • “App Store थर्ड-पार्टी browser engines पर रोक लगाता है” — इस बात पर Mozilla का सवाल उठाना वाजिब है, लेकिन पता नहीं वे इस धागे को खींचना चाहेंगे या नहीं
    iOS devices पर Safari monopoly होने की वजह से काफी developers non-Chrome support की परवाह करते हैं। अभी मजबूरी में करना पड़ता है
    अगर users तक “जो feature टूटा है, वह Chrome में नहीं टूटता” वाला message जाने लगे, तो यह monopoly की तरफ जाने वाला रास्ता है, और उसके बाद जब Google नए web standards बनाएगा तो उसे consensus की ज्यादा जरूरत नहीं रहेगी
    मौजूदा हालत भी गड़बड़ है, लेकिन और खराब भी हो सकती है। उम्मीद है मेरा यह अनुमान गलत निकले

    • iOS पर Apple द्वारा जबरन थोपे गए Safari monopoly को चुनौती देना स्वाभाविक रूप से Mozilla के हित में है। सिर्फ इसलिए कि Chrome भी iOS पर दबाया जाता है, Firefox का दबाया जाना Firefox के लिए फायदेमंद नहीं हो जाता
      अगर Apple की वे restrictions हट जाएं जो Firefox को Gecko और Gecko-based WebExtensions, खासकर ad blockers, implement करने से रोकती हैं, तो iOS पर Firefox का share बढ़ना तय है
      इस तरह बने iOS Firefox users desktop Firefox और ad-blocking वाले iOS Firefox को sync कर पाएंगे, इसलिए उन्हें desktop पर भी Firefox इस्तेमाल करने के लिए प्रेरित किया जा सकता है
    • मैं भी यही कहने आया था। iOS पर Safari को Chrome से replace नहीं किया जा सकता—यह अच्छा हो या बुरा—Chrome के पूर्ण वर्चस्व को रोकने वाला इकलौता mechanism है
    • अगर iOS पर free competition हो, तो मुझे लगता है बहुत से लोग Chrome install करेंगे। खासकर वे ज्यादातर PC users जिनके पास Apple device के नाम पर सिर्फ iPhone है
    • अपनी website को Firefox में चलाने की वजह यह नहीं है कि उसे Safari में भी चलाना पड़ता है
      Firefox आमतौर पर बस चल जाता है, और अगर न भी चले तो Safari नाम के उस neglected platform की वजह से, जिसे हमेशा extra काम चाहिए, मैं एक और technology stack की और चिंता नहीं करना चाहता
    • अगर Mozilla Apple को मुद्दा नहीं बनाता, तो दूसरी companies के खिलाफ शिकायतों को भी Safari का बहाना देकर ignore किया जा सकता है। Apple के तौर-तरीकों पर Mozilla सही बात कह रहा है, इसलिए Google/Microsoft की आलोचना करते हुए Apple को छोड़ देना पाखंड जैसा लगेगा
      मौजूदा हालत का बचाव करने वाली दलीलों से थक चुका हूं। status quo अच्छी दिशा में नहीं जा रहा, और bold action के बिना बदलेगा भी नहीं। Apple के status quo का समर्थन करने वालों के पास भी आगे हालात कैसे बेहतर होंगे, इसका कोई plan नहीं दिखता
      केवल Safari, Chrome dominance को रोकने के लिए पर्याप्त नहीं है, और EU के app store rules लागू होने के बाद browser engine opening को मजबूर किए जाने की संभावना भी छोटी नहीं है, इसलिए long term में status quo खुद भी guaranteed नहीं है
      अभी वह समय है जब tech companies के खिलाफ historically मजबूत antitrust enforcement की इच्छा दिखाने वाला अमेरिकी प्रशासन खत्म होने की ओर है। बहुत से लोगों ने यह पूरी तरह नहीं समझा कि Biden administration antitrust के लिए कितना favorable है
      यह administration 4 साल और चल भी सकता है और नहीं भी, लेकिन इस uncertainty को देखते हुए शुरुआती Windows antitrust case के बाद Google/Apple/Microsoft पर वास्तविक intervention मांगने के सबसे अच्छे मौकों में से एक है
      antitrust के लिए open administration, Big Tech को लेकर consumer sentiment में बदलाव, iOS को लेकर Apple पर दबाव, और जून में ad blockers को कमजोर करने की Google की चाल—इन सबके एक साथ आने से अभी status quo बदलने के लिए जोरदार push करने का अच्छा समय है
      जोखिम नहीं है ऐसा नहीं, लेकिन और इंतजार करने से स्थिति बेहतर नहीं होगी। जितना इंतजार करेंगे, Firefox की relevance उतनी घटेगी, administration बदलने की संभावना उतनी बढ़ेगी, और Mozilla के लिए public opinion का फायदा उठाना उतना मुश्किल होगा
      ऐसा कोई पल नहीं आएगा जब Mozilla यह argument 100% आसानी से जीत सके, और अगर अभी नहीं किया तो अंततः वह market से पूरी तरह बाहर धकेल दिया जाएगा
      Apple समेत सभी के खिलाफ पूरी ताकत से मुद्दा उठाने का समर्थन करता हूं। अगर iOS खुलने के बाद Chrome dominance की चिंता है, तो उस समस्या को Google को regulate करके संभालना चाहिए, और अभी वह argument रखने का सबसे अच्छा समय है

  • Android user के तौर पर Firefox न इस्तेमाल करने की मेरी मुख्य वजह anti-competitive behavior नहीं, बल्कि उसका धीमा महसूस होना है
    Firefox में home page load करते समय layout अक्सर हिलता-डुलता है, keyboard animation कभी-कभी झटका खाता है, और “छोड़कर select” menu option इस्तेमाल नहीं कर पाता

    • कई सालों से इस्तेमाल कर रहा हूं, लेकिन ऐसा फर्क कभी महसूस नहीं हुआ
    • “छोड़कर select” क्या है?
    • Firefox में external keyboard के default keyboard navigation shortcuts भी बिल्कुल काम नहीं करते

  • https://github.com/mozilla/platform-tilt/issues/3
    iOS में JIT support “EU iOS पर third-party rendering engines को मजबूर करेगा” वाली बहस में बहुत कम चर्चा किया गया factor है
    क्या Apple apps को JIT support allow करेगा? क्या browser developers को apply करना पड़े ऐसा कोई नया entitlement बनाएगा? दिलचस्प तो है, लेकिन ऐसा होगा नहीं लगता

    • Apple पहले से macOS पर कुछ entitlements को web browsers तक सीमित करने का तरीका इस्तेमाल करता है। Passkey entitlement इसका उदाहरण है
      com.apple.developer.web-browser.public-key-credential
      https://developer.apple.com/documentation/bundleresources/en...
    • LuaJit लिखता है कि वह iOS support करता है: https://luajit.org/status.html#ios
      क्या किसी को पता है यह सही है? पुराने versions में सही था लेकिन अब support नहीं है क्या?

  • संबंधित लेख: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    https://news.ycombinator.com/item?id=39059255 से आया हूं, लेकिन वहां comments नहीं हैं

  • macOS में selected area पर right-click करके web search चुनने पर, default browser कुछ और set करने के बावजूद हमेशा Safari खुलता है। शायद यह सिर्फ Mail.app में होता हो, लेकिन लगता है यह item छूट गया

  • Android के लिए Firefox में सबसे बड़ी शिकायत यह है कि कभी-कभी address bar में domain टाइप करके Enter दबाने पर भी कुछ भी नहीं होता
    यह व्यवहार अनियमित है और https://forum.syncthing.net जैसी कुछ ही websites को प्रभावित करता है
    टैब बंद करने या दूसरा टैब इस्तेमाल करने से भी हल नहीं होता; इसे ठीक करने के लिए app को force quit करना पड़ता है

    • Desktop पर भी वही समस्या है। लगता है उन्होंने address bar में लगभग कोई दिखने वाला बदलाव न करने वाला fix डाला था और blog post में उसका बखान किया था, लेकिन उसी प्रक्रिया में asynchronous race condition बना दी और कई सालों से उसे टूटा हुआ छोड़ रखा है
      शिकायतें हैं, फिर भी Google browser से बेहतर है
    • मेरे साथ भी हुआ है। बहुत चिढ़ाने वाला है। कभी-कभी random crash भी हो जाता है, जो हाल में करीब एक महीने पहले शुरू हुआ

  • ज़्यादातर बातें समझ आती हैं, लेकिन iOS के Messages integration वाला हिस्सा अच्छा नहीं लगता
    अगर यह उपयोगकर्ता द्वारा चुनी जाने वाली “हाल में भेजे गए links” API जैसा कुछ हो तो समस्या नहीं होगी, लेकिन पूरे message data तक access किसी third-party app को कभी नहीं देना चाहूंगा, भले ही developer Mozilla ही क्यों न हो
    iOS extensions के मामले में, Orion Chrome और Firefox extension galleries दोनों से extensions install कर सकता है, इसलिए लगता है कि या तो यह सचमुच समस्या नहीं है या App Review पास करने के बाद कई सालों से बना हुआ है

  • Google Colab में copy-paste Chrome में ठीक से काम करता है, लेकिन Firefox में नहीं

  • कहा गया है कि “browsing information जैसे history, bookmarked sites और cookies Android के third-party browsers के लिए accessible नहीं हैं”; user के नज़रिए से मैं क्यों चाहूंगा कि कोई third-party application मेरे browser की history, bookmarks और cookies तक access करे?
    यह साफ़ तौर पर privacy leak है। Firefox को सिर्फ वही data लेना चाहिए जो Firefox ने तब बनाया जब मैं Firefox इस्तेमाल कर रहा था; किसी दूसरे context का data नहीं

    • Leak तभी है जब access बिना अनुमति के हो। अगर user “बिल्कुल नहीं” कह सकता है, तो app का उस data तक access मांग पाना अपने-आप में समस्या नहीं है
    • जो user नए browser पर आसानी से switch करना चाहता है, वह चाहेगा कि नया browser पुराने browser के bookmarks वगैरह data तक access करके प्रक्रिया आसान बनाए
    • यह मुख्यतः दूसरे browsers से import/export करने के लिए है। Onboarding में यह बहुत आम काम है
    • History और cookies पर आपत्ति निश्चित रूप से समझ में आती है, लेकिन bookmarks export और फिर import करना तो अनिवार्य है
      फिर भी Android के लिए Firefox यह भी support नहीं करता :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • यह व्याख्या थोड़ी बेईमानी जैसी लगती है। Contacts या अन्य sensitive data भी पहले से “privacy leak” के बिना import किए जा सकते हैं
      संबंधित issue में भी बिना verification वाले import feature की मांग नहीं की गई है; वह कहता है कि Android user consent के साथ दूसरे sensitive data तक access को mediate कर सकता है