मैंने Honey का सोर्स कोड पढ़ा

वीडियो निर्माता Honey coupon Chrome extension के चल रहे घोटाले की जांच करने का इरादा व्यक्त करते हैं। चूंकि Honey एक Chrome extension है, इसका पूरा source code publicly accessible है जिससे YouTube videos में लगाए गए आरोपों को verify किया जा सकता है। विशेष रूप से, वे यह देखना चाहते हैं कि क्या Honey के software engineers ने समय के साथ इन गलत व्यवहारों को न केवल जारी रखा बल्कि उन्हें और बेहतर और मजबूत बनाया है। वे पुष्टि करते हैं कि हाँ, ऐसा हुआ है और वे दर्शकों को यह दिखाने वाले हैं कि यह कैसे हुआ। वीडियो का focus Honey के एक बहुत विशिष्ट operation पर है जिसे वे detail में discuss करेंगे।

यह section MegaLeg के Honey exposure video से तीन मिनट का अंश प्रस्तुत करता है जो stand down policy को समझाता है। Video में बताया गया है कि affiliate networks जानते हैं कि coupon extensions influencers और content creators से commission चुरा सकते हैं, इसलिए वे stand down policy लागू करते हैं। जब user किसी affiliate link पर क्लिक करता है, तो Honey को stand down करना चाहिए और cashback offer नहीं दिखाना चाहिए। MegaLeg का demonstration दिखाता है कि Honey दो अलग accounts पर अलग व्यवहार करता है - जिस account में zero cashback points हैं वह stand down हो जाता है, लेकिन जिस account में पहले से cashback points हैं वह stand down नहीं होता। यह selective enforcement दिखाता है कि Honey अपने rules को चुनिंदा तरीके से लागू कर रहा है।

वीडियो निर्माता अब actual code analysis शुरू करते हैं और बताते हैं कि उन्होंने Honey के कई versions को examine किया - February 2019 (version 1901) से लेकर वर्तमान version तक। वे AI की मदद से minified code को unprecedented speed से analyze कर पाए। मुख्य सवाल यह था कि क्या user points जैसी चीज stand down menu को control कर रही है, और क्या इसमें समय के साथ बदलाव हुए। बड़ी कंपनियों में काम करने के अनुभव से वे जानते हैं कि कभी-कभी code वैसे ही पड़ा रहता है बिना किसी बदलाव के। वे यह पता लगाना चाहते थे कि क्या Honey का code भी ऐसे ही stagnant था, या फिर महत्वपूर्ण intentional changes किए गए थे।

Copyright issues से बचने के लिए (क्योंकि PayPal के lawyers DMCA strikes भेज सकते हैं), वीडियो निर्माता blackboard पर code को recreate करते हैं। Version 11 (2019) में stand down logic मौजूद था जिसमें SSD stand down logics थी जो JSON file से match करती थी। Code में user points (UP), ad block last time used (ADB), और is account logged in जैसे fields थे। सबसे suspicious बात यह थी कि एक giant switch statement था जो check करता था कि email में 'test' शब्द है या नहीं - अगर है तो हमेशा stand down कर दो। यह link testing accounts को proper testing से रोकता था। इसके अलावा, code में hard-coded checks थे जो specific providers जैसे LinkShare के लिए specific rules apply करते थे। यह काफी hard-coded process थी जहाँ explicitly लिखा था 'if LinkShare, do this action'।

Version 11 से 14 के बीच (2019 से 2022 तक) code में बहुत कम बदलाव हुए। चीजें काफी हद तक stable रहीं और कोई major changes नहीं दिखे। थोड़े-बहुत edits हुए लेकिन कुछ खास demonstrate करने लायक नहीं था। यह period relative stagnation का था जहाँ stand down logic में कोई significant evolution नहीं हुआ। यह observation महत्वपूर्ण है क्योंकि यह दिखाता है कि अगले major changes intentional और deliberate थे, न कि gradual evolution का हिस्सा।

Version 16 (2024) में एक major refactor किया गया जिससे decisions को Honey के endpoint से dynamically control किया जा सके। अब endpoint एक object भेजता है जिसमें base value, provider-specific values, और store-specific values (X के अंतर्गत) होते हैं। पहले के hard-coded if statements की जगह अब sophisticated system है जो dot notation का उपयोग करता है - पहले base object लिया जाता है, फिर provider की values को spread किया जाता है, फिर store-specific values apply की जाती हैं। यह proper software engineering है जो configuration-driven approach follow करता है। उदाहरण के लिए, एक non-logged-in user को stand down नहीं होने के लिए 65,000 user points चाहिए, लेकिन अगर वे LinkShare से आए हैं तो यह requirement घटकर सिर्फ 5,001 हो जाती है। यह सब JSON configuration के through dynamically control होता है।

Code evolution को देखकर निर्माता conclude करते हैं कि समय के साथ Honey ने अपने system को deliberately बेहतर बनाने के लिए changes किए हैं। 2024 में engineers ने कहा कि हमें अधिक robust होने की जरूरत है और अधिक stores और providers के बारे में अधिक decisions लेने में सक्षम होना चाहिए, वह भी easily maintainable तरीके से। यह genuine software engineering था जो successfully implement किया गया। इन changes के पीछे clear intent दिखता है - वे जो भी system कर रहा है उसे maintain करना चाहते हैं, चाहे वह fraudulent हो या नहीं। यह साबित करता है कि यह behavior accidental या legacy code नहीं है बल्कि active development और improvement का subject रहा है।

Code analysis के दौरान निर्माता को बार-बार 'VIM' शब्द दिखा। Claude Code से पूछने पर पता चला कि यह VIM Instance Manager है जो Honey के अंदर है। जांच करने पर पता चला कि Honey plugin के अंदर एक पूरा JavaScript-in-JavaScript engine चल रहा है। Honey में Acorn (एक JavaScript parser) है जो valid JavaScript से AST बनाता है, इसे evaluate करता है, और फिर VIM engine में feed करता है। Code में cart_ops_retrieval_js और product_ops_retrieval_js जैसे references हैं जो कभी-कभी null नहीं बल्कि actual executable code होते हैं। हालांकि debugger में breakpoints set करने पर यह code execute होता नहीं दिखा, लेकिन infrastructure तो मौजूद है। यह Honey की तरफ से remote code execution की capability तैयार रखने का indication है।

यह पूरा JavaScript-in-JavaScript setup सबसे अजीब चीज है जो निर्माता ने कभी देखी। Chrome plugin development में normally कोई JavaScript में JavaScript नहीं चलाता। यह likely Google के Manifest V3 की requirements को bypass करने के लिए है जो JavaScript eval() का उपयोग prohibit करती है। Honey technically पुरानी Google service terms के खिलाफ नहीं है क्योंकि वे eval() नहीं कर रहे बल्कि operations को hard code कर रहे हैं जिन्हें वे दूसरे plugins से छुपाना चाहते हैं, और फिर उन्हें execute करने के लिए पूरा JavaScript engine include कर रहे हैं। Manifest V3 specifically कहता है कि remote source से fetch किए गए complex commands चलाने के लिए interpreter नहीं बनाना चाहिए। Honey इसे bypass करता है क्योंकि ये strings पहले से extension के भीतर हैं, remote नहीं हैं। यह extreme obfuscation है जिसका कोई legitimate reason समझ नहीं आता।

निर्माता conclude करते हैं कि यह सबसे असामान्य engineering है जो उन्होंने जीवनकाल में देखी है - 10,000+ lines की weird state machines से भी ज्यादा complex। Stand down stuff के लिए dynamic rules बेहद robust हैं और JSON के through per-store, per-provider, और per-user basis पर control किए जा सकते हैं। Purpose चाहे fraudulent हो या न हो, system को deliberately dynamic बनाया गया है। वे MegaLeg को special shoutout देते हैं जिन्होंने उनकी मदद की और recommend करते हैं कि सभी को उनके videos देखने चाहिए। अंत में वे viewers से feedback मांगते हैं कि क्या उन्हें यह नया format (stream पर code analysis करना और फिर report करना) पसंद आया। वीडियो Terminal.shop के coffee advertisement के साथ समाप्त होता है जो SSH के through coffee ordering का meme बनाता है।