- यात्रा कार्यक्रम, ठहरने की जानकारी और PDF दिखाने वाला Travelbound असल में वेब से मिला कंटेंट दिखा रहा था, लेकिन उसके साथ tracking और यात्रा विज्ञापन भी शामिल कर रहा था, इसलिए उसी जानकारी को देने वाला एक वेबपेज बनाकर उसे बदलने की कोशिश की गई
- Android virtual device को root करके और HTTP Toolkit से ट्रैफिक intercept करके यह पुष्टि की गई कि username और password को URL में जोड़ने वाली API ऐप का पूरा कंटेंट JSON के रूप में लौटाती है
- Ruby script और Cron से ताज़ा JSON को नियमित रूप से लाकर HTML बनाया गया, और ad data को हटाकर सिर्फ itinerary और PDF जैसी ज़रूरी फाइलें दिखाईं गईं
- वेब version में copy·print·save·bookmark·search संभव है, यह अधिक तरह के devices पर काम करता है, और मूल ऐप का tracking code व ads भी हटा देता है
- मूल ऐप 43MB से शुरू होकर कंटेंट डाउनलोड करने के बाद 124MB तक बढ़ जाता है, जबकि वेबपेज 0.05MB है और वैकल्पिक images भी सिर्फ 35MB हैं, इसलिए HTML और HTTP से डिलीवर होने वाले document-style content के लिए वेब ज्यादा उपयुक्त है
वेबपेज ही काफी था: Travelbound
- बच्चे के प्रदर्शन कला विद्यालय की Disneyland यात्रा का itinerary, transport और accommodation जानकारी देखने के लिए Travelbound ऐप इंस्टॉल करना पड़ता था
- ऐप का मुख्य कंटेंट वेब के जरिए डिलीवर होने वाला text·image·PDF link था
- वेबपेज से अलग इसकी दो ऐसी विशेषताएँ थीं जो उपयोगकर्ता के लिए नुकसानदेह थीं
- यह Google Account से जुड़ा tracking data developer को भेजता था
- यह उसी travel company के दूसरे यात्रा products को
inspirationsनाम से विज्ञापित करता था
- वेबपेज होने पर कंटेंट को copy·print·save·bookmark·search किया जा सकता है, लगभग हर device पर उपयोग किया जा सकता है, और संभावित रूप से accessibility भी बेहतर हो सकती है
Android app ट्रैफिक intercept करना
- Android Studio के Virtual Device Manager में नया virtual device बनाया गया और यह जाँचा गया कि
adb shellकाम कर रहा है - rootAVD का उपयोग करके Android 33 virtual device को root किया गया
./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img - root करना इसलिए ज़रूरी था ताकि Certificate Pinning इस्तेमाल करने वाले ऐप man-in-the-middle proxy के self-signed TLS certificate पर भरोसा कर सकें
- root के बिना Travelbound जैसे ऐप certificate को invalid मानकर communication ठुकरा देते थे
- cold boot के बाद Magisk चलाया गया और request करने वाले apps के लिए
suaccess अपने आप allow करने के लिए सेट किया गया- auto-allow न करने पर HTTP Toolkit user response का इंतज़ार किए बिना unprivileged mode में चल जाता था
- HTTP Toolkit से Android virtual device का ट्रैफिक intercept किया गया
- fake VPN provider इंस्टॉल करके device का ट्रैफिक proxy तक भेजा गया
- Android security restrictions की वजह से इंस्टॉल किया गया root CA certificate हाथ से जोड़ना पड़ा
- Play Store से Travelbound इंस्टॉल करने के बाद noise कम करने के लिए उसे इस तरह configure किया गया कि सिर्फ उसी ऐप का ट्रैफिक proxy हो
API call और data structure
- ऐप यात्रा समूह के username और password को जोड़कर इस format की API URL को call करता था
https://travelbound.api.vamoos.com/api/itineraries/…} - username और password पूरे travel group द्वारा साझा किए जाने वाले credentials थे
- API response JSON में ऐप द्वारा दिखाया जाने वाला पूरा कंटेंट मौजूद था
- यात्रा itinerary के हर section को रखने वाला array
inspirationsad array- image जैसी files रखने वाला cross-reference array, जिन्हें दूसरे sections refer करते थे
- डेटा में ऐप द्वारा दिखाया जाने वाला HTML code भी शामिल था, इसलिए कंटेंट डिलीवरी का तरीका खुद वेबपेज जैसा ही था
- S3 image URL की expiry अपेक्षाकृत कम थी, इसलिए कंटेंट न बदलने पर भी JSON को समय-समय पर फिर से लाना पड़ता था
- दूसरा तरीका images को local cache करना है, और मूल ऐप शायद यही तरीका इस्तेमाल कर रहा था
JSON को HTML में बदलना
- Ruby script लिखी गई और Cron schedule के अनुसार ताज़ा JSON लाकर HTML page बनाने के लिए configure किया गया
- generation process में data schema के
overlayRowsसे संबंधितinspirationsads को पूरी तरह हटा दिया गया - वेबपेज पर सिर्फ यह जानकारी दिखाई गई
- यात्रा itinerary items
- ads या itinerary में refer न की गई सभी files
- दूसरी सूची का उपयोग PDF download links को एक जगह इकट्ठा करने के आसान तरीके के रूप में किया गया
- generated page को उसी password से protect किया गया जो मौजूदा travel group को दिया गया था
- मूल JSON को
<details>element में रखा गया ताकि बाद में यह जाँचा जा सके कि क्या ऐसा schema data सामने आता है जिसे मौजूदा script नहीं समझ पाई
छोटा और अधिक लचीला वेब version
- वेबपेज मूल ऐप जितना आकर्षक नहीं है, लेकिन आकार में बहुत छोटा है और वेब की बुनियादी सुविधाएँ बिना अलग implementation के देता है
- कंटेंट को copy·print·save·bookmark·search किया जा सकता है और यह अधिक तरह के devices पर उपलब्ध है
- tracking code और ads हटाकर मूल ऐप की दो अनावश्यक विशेषताएँ भी खत्म कर दी गईं
- accessibility का औपचारिक audit नहीं किया गया, लेकिन मूल ऐप में ऐसे elements थे जो साधारण वेब version की तुलना में assistive technology के साथ उपयोग करना अधिक कठिन लगते थे
आकार और वितरण विधि की तुलना
- मूल Travelbound ऐप शुरू में 43MB का है और अतिरिक्त कंटेंट डाउनलोड करने के बाद 124MB तक बढ़ जाता है
- वैकल्पिक वेबपेज 0.05MB का है, और सभी images को वैकल्पिक रूप से डाउनलोड करने पर 35MB और जुड़ते हैं
- यात्रा समूह के साथ दोनों तरीके साझा किए गए ताकि उपयोगकर्ता ऐप और वेबपेज में से अपनी पसंद का तरीका चुन सकें
- कुछ कामों के लिए ऐप उपयुक्त हो सकता है, लेकिन जो Travelbound कंटेंट पहले से HTML में लिखा गया है और HTTP से डिलीवर होता है, उसके लिए ऐप आवश्यक नहीं है
- app store distribution लागत और development burden बढ़ाता है, और ऐसे document-style content को ऐप तक सीमित करने से सीधे वेब पर प्रकाशित करने की तुलना में उपयोगकर्ताओं और बुनियादी सुविधाओं दोनों की उपलब्धता घट जाती है
1 टिप्पणियां
Lobste.rs की राय
मैं इस बात से तंग आ चुका था कि जो सेवाएं मूल रूप से सिर्फ एक webpage हैं, वे app bloat में बदल जाती हैं; अच्छा लगा कि ऐसा सोचने वाला मैं अकेला नहीं हूं
Android पर webpage shortcut बनाना users को ज्यादा साफ तौर पर दिखता नहीं है, इसलिए समझ आता है कि कंपनियां apps को तरजीह देती हैं। लेकिन अगर कोई सेवा password को app link के साथ SMS में भेजती है, तो web app ही सबसे सही है। सीधे password page से link कर दें, बस
/e/OS app store में “web apps” section भी है, जिसमें Google Maps के web version जैसी entries रखी गई हैं। PWA खुद इस्तेमाल में आसान है, लेकिन default Chrome या manufacturer Android shortcut बनाने को कितनी सक्रियता से guide करते हैं और कितनी प्रमुखता से दिखाते हैं, यह मुझे नहीं पता
मौजूदा तरीका साफ तौर पर users के लिए नहीं है, और इसे कैसे बेहतर बनाया जाए इस पर सोचने की जरूरत है
आम users, खासकर जिन्हें computers की ज्यादा आदत नहीं है, उनके लिए app और webpage का फर्क असल में बस desktop या home screen shortcut जितना ही है
अगर webpage shortcut सीधे distribute किए जा सकें, तो यह बहुत सस्ते में app develop करने का तरीका होगा, और शायद ज्यादातर apps इसी तरह बनाए जा सकते थे
इस icon को tap करने पर नया browser tab नहीं, बल्कि सामान्य app की तरह standalone window खुलती है। मैंने App Store पर publish किए बिना इसी तरीके से अपना बनाया हुआ family expense tool distribute किया है
बहुत सारे “apps” के लिए सिर्फ webpage होना ही काफी है। बिना किसी खास वजह के मामूली feature इस्तेमाल करने के लिए पहले app install करना पड़ता है—ऐसी स्थितियां बहुत ज्यादा हैं और परेशान करती हैं
local device connection के लिए app इस्तेमाल करना समझ आता है, लेकिन कुछ systems में app को central server के जरिए local device से communicate कराया जाता है। तब app install करने का इकलौता औचित्य भी खत्म हो जाता है
शुरुआती iPhone ने webpages को app platform बनाने की कोशिश की थी, लेकिन आखिरकार आज जैसा बेतरतीब ecosystem बन गया