uBlock Origin ने `ipaddress=` विकल्प को दर्शाने के लिए CNAME uncloaking कोड में बदलाव किया

 (github.com/gorhill)
1 पॉइंट द्वारा GN⁺ 2024-10-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • uBlock Origin कमिट में Firefox नेटवर्क प्रोसेसिंग में CNAME uncloaking फ्लो को दोबारा लिखा गया है और DNS lookup से मिले IP को details.ip में दर्शाने के लिए बदला गया है
  • मौजूदा cnames Map cache हटा दिया गया है और उसकी जगह dnsList, dnsDict, dnsWritePtr आधारित 256-एंट्री ring buffer और 60000ms TTL cache ने ले ली है
  • DNS lookup के लिए browser.dns.resolve(hn, [ 'canonical_name' ]) का उपयोग होता है, और परिणाम के canonicalName और addresses[0] को क्रमशः CNAME और IP के रूप में इस्तेमाल किया जाता है
  • CNAME exception handling में 1st-party, ignore list, root document शर्तें बरकरार हैं, और IPv4 address या [ से शुरू होने वाले hostname को दोबारा lookup से बाहर रखा जाता है
  • Chromium का minimum version 80.0 और Opera का minimum version 67.0 कर दिया गया है, जबकि hidden setting के cnameMaxTTL default value को हटा दिया गया है

Firefox DNS cache संरचना का पुनर्लेखन

  • platform/firefox/vapi-background-ext.js में CNAME uncloaking से जुड़ा कोड global Map-केंद्रित संरचना से बदलकर class के अंदर की DNS cache संरचना में ले जाया गया है
  • पहले के global state cnameUncloakEnabled और cnames Map की जगह अब cache को इन फ़ील्ड्स से मैनेज किया जाता है
    • dnsList: ring buffer
    • dnsWritePtr: अगला write position
    • dnsMaxCount: अधिकतम 256
    • dnsDict: hostname से ring buffer index की mapping
    • dnsEntryTTL: 60000ms
  • constructor में canUncloakCnames और cnameUncloakEnabled को true से initialize किया जाता है

request processing flow

  • onBeforeSuspendableRequest(details) request URL से hostname निकालने के बाद पहले dnsFromCache(hn) से cache जांचता है
  • अगर cached DNS entry में ip हो तो उसे details.ip में सेट किया जाता है
  • बेसिक super.onBeforeSuspendableRequest(details) कॉल का परिणाम अगर cancel या redirect जैसी स्थिति में खत्म हो जाए, तो वही परिणाम सीधे लौटाया जाता है
  • अगर cached DNS entry Promise नहीं है, तो onAfterDNSResolution(hn, details, dnsEntry) के जरिए आगे की processing जारी रहती है
  • अगर DNS re-lookup की शर्तें पूरी नहीं होतीं या details.proxyInfo?.proxyDNS मौजूद हो, तो अतिरिक्त DNS processing नहीं की जाती

DNS lookup और storage का तरीका

  • dnsShouldResolve(hn) खाली hostname, [ से शुरू होने वाले hostname, और IPv4 address फ़ॉर्म को DNS lookup target से बाहर रखता है
  • dnsResolve(hn, details) ring buffer की मौजूदा position पर hostname दर्ज करता है और dnsAPI.resolve(hn, [ 'canonical_name' ]) को कॉल करता है
  • lookup सफल होने पर dnsToCache(hn, rec, details) चलता है, और विफल होने पर dnsToCache(hn) के जरिए cache में खाली entry छोड़ दी जाती है
  • dnsToCache नई cache entry में hn और expiry timestamp को स्टोर करता है
    • अगर cnameFromRecord कोई मान लौटाता है, तो उसे dnsEntry.cname में स्टोर किया जाता है
    • अगर ipFromRecord कोई मान लौटाता है, तो उसे dnsEntry.ip में स्टोर किया जाता है
  • dnsFromCache में अगर cache entry Promise हो तो उसे वैसे ही लौटाया जाता है, और expired entry को dnsList और dnsDict से हटा दिया जाता है

CNAME और IP लागू होने की शर्तें

  • cnameFromRecord(hn, record, details) तब CNAME नहीं लौटाता जब record.canonicalName मौजूद न हो या मूल hostname के बराबर हो
  • अगर cnameIgnore1stParty चालू हो, तो CNAME और मूल hostname का domain समान होने पर उसे बाहर रखा जाता है
  • अगर cnameIgnoreList मौजूद हो, तो उस regex से match न होने वाले CNAME को बाहर रखा जाता है
  • अगर cnameIgnoreRootDocument चालू हो, तो request hostname details.documentUrl || details.url के hostname के समान होने पर उसे बाहर रखा जाता है
  • ipFromRecord(record) तब पहला address addresses[0] लौटाता है जब record.addresses array हो और खाली न हो

URL rewrite और आगे की filtering

  • onAfterDNSResolution में अगर DNS entry में CNAME हो और cnameUncloakEnabled चालू हो, तो uncloakURL के जरिए URL को rewrite किया जाता है
  • URL बदलते समय पुराना URL details.aliasURL में स्टोर किया जाता है और नया URL details.url में लागू किया जाता है
  • अगर DNS entry का IP मौजूद हो और वह मौजूदा details.ip से अलग हो, तो details.ip को update किया जाता है
  • बेस class के onBeforeSuspendableRequest(details) को दोबारा केवल तभी कॉल किया जाता है जब CNAME rewrite या IP change वास्तव में हुआ हो
  • uncloakURL URL के अंदर hostname की स्थिति ढूंढ़कर उसे CNAME से बदलता है, और cnameReplayFullURL मान के अनुसार या तो पूरा URL जोड़ा जाता है या सिर्फ path के शुरुआती हिस्से तक रखा जाता है

settings और manifest बदलाव

  • setOptions से cnameMaxTTL की processing हटा दी गई है
  • option change पर पुराने cnames Map को reset करने की जगह dnsList.fill(null) और dnsDict.clear() से DNS cache खाली किया जाता है
  • src/js/background.js की hidden setting defaults से cnameMaxTTL: 120 हटा दिया गया है
  • platform/chromium/manifest.json में minimum_chrome_version को 73.0 से बदलकर 80.0 किया गया है
  • platform/opera/manifest.json में minimum_opera_version को 60.0 से बदलकर 67.0 किया गया है

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

1 टिप्पणियां

 
GN⁺ 2024-10-08
Hacker News की राय

  • लगता है शीर्षक गलत है। uBlock Origin कई सालों से इस फीचर को सपोर्ट कर रहा था, बस यह सिर्फ Firefox पर संभव था
    यह मामला पूरी तरह नया फीचर नहीं, बल्कि उस code की refactoring जैसा लगता है

    • अभी भी सपोर्ट करता है, पहले भी करता था :P
    • यह सिर्फ refactoring से ज्यादा लगता है। अब असली request जाने से पहले IP के आधार पर blocking और पहले चरण में की जा सकती है
      हालांकि एक domain के कई IP होने पर browser कौन-सा IP चुनेगा, यह पता नहीं होता, इसलिए यह परफेक्ट नहीं है
    • शीर्षक को page title पर वापस कर दिया। submitted title था “uBlock Origin supports filtering CNAME cloaking sites on Firefox now”
      अगर कोई ज्यादा सटीक और neutral शीर्षक सुझाए, तो फिर बदल सकते हैं। हालांकि बिना अतिरिक्त context वाले GitHub commits आम तौर पर HN thread के लिए बहुत अच्छे नहीं होते

  • मुझे अभी तक सीधे नुकसान नहीं हुआ है, लेकिन अगर Chrome सच में uBO को खत्म कर देता है, तो switch कर सकूं इसलिए मैं अपने extensions को पहले से Firefox के लिए फिर से ठीक कर रहा हूं

    • यह “अगर” का नहीं, “कब” का सवाल है। 2020 से ही यह “कब” था, और अब सच में आ रहा है
      कुछ releases के भीतर आ जाएगा, इसलिए तैयार रहना चाहिए
    • मैं अपने परिवार को Brave पर shift कर रहा हूं। फर्क लगभग महसूस नहीं होता, और मुझे ज्यादा भरोसा है कि browser user-centric content filtering को support करता रहेगा
    • यह Canary release में पहले ही हटा दिया गया है
    • “extensions को Firefox के लिए फिर से लिखना” का क्या मतलब है, समझ नहीं आया। Firefox भी वही API इस्तेमाल करता है
      ज्यादा से ज्यादा background.service_worker को background.scripts में बदलना होगा, सचमुच बस key name बदलना है
    • जिन्हें नहीं पता, उनके लिए पूछ रहा हूं: uBO क्या है और ज्यादातर extensions पर इसका क्या असर है?

  • uBlock Origin Firefox को बेहतर बनाने वाली चीजों में से एक है, और Chrome वगैरह की जगह Firefox इस्तेमाल करने का बड़ा कारण भी है
    यह इंटरनेट को सच में browse करने लायक बनाता है

    • मैं कुछ साल पहले इस combination पर आया था, और छोड़ने की कोई वजह कभी नहीं दिखी। Android phone पर भी यही, यह मैंने देखा हुआ इकलौता काम का mobile web experience है
      10 साल से ज्यादा समय में कुछ sites पर display issues थे, लेकिन उन sites में Chrome पर भी issues थे
      निजी तौर पर मुझे ads आधुनिक समाज के cancer जैसे लगते हैं। white lies और दूसरी तरह के झूठ, manipulation सब मिला हुआ है, और उसमें इतना पैसा बहता है कि उसमें सम्मान करने लायक कुछ भी नहीं बचता
    • Mozilla advertising company बनती जा रही है, इसलिए यह बात बदल सकती है
    • मैंने Brave और Firefox दोनों इस्तेमाल किए हैं, और सच कहूं तो बड़ा फर्क महसूस नहीं हुआ। फिर भी philosophy और non-profit organization से आने की वजह से मैं Firefox को ज्यादा पसंद करता हूं
      Brave भी अच्छी quality का project है, इसलिए backup के तौर पर इस्तेमाल करता हूं, और कभी-कभी window tiling और कहीं बेहतर tab management के कारण Vivaldi भी साथ में इस्तेमाल करता हूं

  • CNAME cloaking का मतलब क्या यह है कि ad sites wildcard record की ओर इशारा करने वाले randomly generated subdomains इस्तेमाल करती हैं?

    • यह उसका एक हिस्सा है
      आम तौर पर जब आप contentsite.com visit करते हैं, तो ads adsite.com से serve होते हैं। ad blocking rules adsite.com को block कर दें तो ads नहीं दिखते
      CNAME cloaking में main site adsite.contentsite.com जैसे subdomain को adsite.com की ओर point कराती है। तब ad blocker के सामने लगभग असंभव काम आ जाता है: उसे ऐसे लाखों subdomains block करने पड़ते हैं जो normal site का हिस्सा लगते हैं
      legitimate site लगातार subdomains बदल सकती है, और ad blocker के पास यह जानने का कोई तरीका नहीं होता कि कौन-सा subdomain normal content है और कौन-सा ad। ऊपर से content उसी domain से serve होता है, इसलिए कुछ cookie policies bypass करके users को बेहतर track भी किया जा सकता है
      यह update resolved IP के आधार पर filtering rules set करने की सुविधा देता है
    • सही। ads और analytics providers ने third-party cookie protections bypass करने के लिए यह तरीका इस्तेमाल करना शुरू किया था

  • यह Manifest V3 क्यों खराब है इसका अच्छा उदाहरण है। definition के हिसाब से यह ऐसा काम कर ही नहीं सकता, और runtime code-based heuristics भी संभव नहीं हैं
    यह advertisers के साथ arms race है, और Google दोनों तरफ हथियार बेचने वाला dealer है। वह users को जीतने के लिए जरूरी चीजें नहीं देगा

    • declarative Manifest V3 API ऐसा feature क्यों नहीं दे सकती, इसकी कोई वजह नहीं है। अगर मैंने commit को सही पढ़ा है, तो असली server को कुछ भी भेजने से पहले request flow में बेहतर तरीके से integrate करके, असल में इस्तेमाल होने वाले IP address के आधार पर block करना बेहतर काम कर सकता है
      बेशक यह सब browser vendor, यानी Google, पर निर्भर है कि वह यह API add करना चाहता है या नहीं। अगर “runtime code” से imperative processing की जा सके, तो browser makers built-in support जोड़ने से पहले user space में innovation हो सकता है
    • technically Manifest V3 खुद browser द्वारा extensions को दिए जाने वाले API से अलग है। Firefox में Manifest V3 blocking web requests[1] के साथ supported है, जो “Manifest V3” से पहले वाली filtering API है
      इसलिए यह कहना गलत है कि कोई खास feature “definition के हिसाब से” असंभव है
      [1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
    • Chrome छोड़कर Firefox अपना लो

  • CNAME cloaking उदाहरण के लिए, मान लें कि SaaS provider A, company Q को एक शानदार ad tracking software देना चाहता है
    पुराने तरीके में A, company Q से कहता कि वह https://q-company.example पर मौजूद अपनी वेबसाइट में, जैसे https://A-ads-tracking.example की script डाल दे
    तब uBlock Origin द्वारा इस्तेमाल की जाने वाली block lists में “A-ads-tracking.example domain पर जाने वाली requests को रोकें” जैसा rule बन जाता, और ads block हो जाते
    CNAME cloaking में SaaS provider A अपना ad tracking service A-ads-tracking.example domain पर नहीं, बल्कि जैसे 29.1.2.3 जैसे किसी खास IP address पर रखता है। और अहम बात यह है कि SaaS A, company Q से कहता है कि वह q-company.example का एक subdomain बनाए और उसका CNAME record 23.1.2.3 की ओर point करे। इसे media.q-company.example जैसा plausible नाम दे दिया जाता है
    Company Q द्वारा वह CNAME set करने के बाद अगर वह वेबसाइट में media.q-company.example script tag जोड़ दे, तो SaaS A उस साइट के सभी users को track कर सकता है। इस तरह की bypass layer के कारण company Q के owner और public block lists के बीच असल में एक अनंत cat-and-mouse game बन जाता है
    इस समस्या से बचने के लिए uBlock Origin जैसे extension चलाने वाले software को browser request के target domain के साथ-साथ उस domain का actual IP address भी देख पाना चाहिए। यह commit उस behavior को सक्षम करने, या कम-से-कम उस code को बेहतर ढंग से काम कराने से जुड़ा लगता है

    • सही-सही कहें तो यह थोड़ा अलग है। नाम के मुताबिक इसमें CNAME इस्तेमाल होता है, यानी यह IP की ओर point करने वाला A record नहीं, बल्कि किसी दूसरे record की ओर point करने वाला record है
      उदाहरण के लिए media.q-company.example, q-company.ads-tracking.example की ओर point करने वाला CNAME हो सकता है, और फिर q-company.ads-tracking.example के पास IP देने वाला A record होता है
      Browser intermediate DNS name extensions को देता है या नहीं, यह मुझे नहीं पता। इसलिए uBlock जैसी चीज़ों को IP lists पर निर्भर रहना पड़ सकता है, लेकिन pihole जैसी DNS-based filtering ads-tracking.example के लिए rule से सीधे block कर सकती है
      जो भी हो, browser-based और DNS-based malicious blockers दोनों इस्तेमाल करना अच्छा है
    • इसी वजह से uBlock advanced mode में सारी JavaScript block करना, और site सही से काम करने लगे तब तक दिखने वाली scripts को धीरे-धीरे allowlist में डालना अच्छा तरीका है
      यह धीमा है और गलतियों की संभावना रहती है, लेकिन आदत पड़ जाए तो आसान हो जाता है, और इस तरह की बेकार चालबाजियों से पूरी तरह immune बना देता है

  • क्या Chrome uBO को block करने वाला है? मैं latest स्थिति हमेशा follow नहीं कर पाता
    मुझे पता है कि third-party cookies अब allow की जा रही हैं, तो शायद कुछ संभावना हो सकती है

    • वे uBO को सीधे block नहीं कर रहे, बल्कि नया plugin API, Manifest V3, लाते हुए वे browser features हटा रहे हैं जिनकी वजह से uBO काम कर पाता था
      uBO को यह पहचानने और फिर उसे load होने से रोकने के लिए जिन core APIs की ज़रूरत होती है, उन्हें हटाया जा रहा है
      Google का दावा है कि यह “performance” या “security” की वजह से है। बेशक, असल में जिस “performance” या “security” पर बड़ा असर पड़ता है, वह नुकसानदेह या ad-related downloads शुरू होने से पहले उन्हें पहचानने, intercept करने और रोकने की क्षमता है
    • Browser को update न करना भी risky है। Firefox पर switch करना, updates भी लेना और uBO का पूरा support भी पाना, कहीं बेहतर है
    • Browser monopoly को लेकर खराब public backlash एक साथ फूट पड़े, इससे बचने के लिए वे इसे लंबे समय में धीरे-धीरे phase out कर रहे हैं। लेकिन वह schedule जून से शुरू हो चुका है
      https://developer.chrome.com/docs/extensions/develop/migrate...
      https://www.bleepingcomputer.com/news/google/google-chrome-w...
    • फिलहाल Manifest V2 support करने वाले Chromium browsers के लिए Chrome Web Store पर uBlock Origin अभी भी मौजूद है
      अगर आप केवल Manifest V3 support करने वाला Chromium version इस्तेमाल करते हैं, तो यह छिपा दिया जाता है
    • सच कहें तो यह काफी हद तक इस पर निर्भर हो सकता है कि अमेरिका ऐसी administration बनाए रखता है या नहीं जो खुलेआम monopoly companies को court में ले जाने को तैयार हो

  • क्या कुछ DNS servers में ऐसा feature नहीं होता जो server द्वारा resolve किए गए CNAME जैसा काम करता है? यानी admin कोई ऐसा record डालता है जो किसी दूसरे DNS name की ओर point करता है, लेकिन client को बस A या AAAA record ही दिखता है

    • शायद आप ALIAS record की बात कर रहे हैं

  • uBO में यह feature काफी पहले से था। 1.34.0 से, और advanced settings में 1.25.0 से था
    https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...
    मुझे याद है यह लगभग 2021 के आसपास था

  • Brave, Edge, Opera में uBO की स्थिति क्या है?

    • बताए गए दो proprietary browsers में मेरी दिलचस्पी नहीं है, लेकिन Brave जहां तक संभव होगा Manifest V2 को आंशिक रूप से support करेगा और uBO compatibility बनाए रखेगा
      https://brave.com/blog/brave-shields-manifest-v3/
      हालांकि इसकी सख्त जरूरत नहीं है। Brave में अपना built-in ad blocker काफी powerful है, और आखिरी बार जब मैंने check किया था, वह native code में compile था, uBO से ज्यादा performant था, और वही ad lists भी पूरी तरह support करता था