दोनों स्कोर कैसे बनते हैं

R07_silenceमौनthreshold4 फ़ील्ड पढ़ता है

जोखिम के अनुपात में मौन

केवल तब सक्रिय होता है जब P01 और P03 {none_known, unknown} में हों और P05 {none, unknown, fresh_no_numbers} में हो; risk = min(params.cap, params.per_year x years operating x weight), जिसमें weight exposure band के अनुसार params.weight से लिया जाता है। मूल्य वर्ष के आधार पर निर्धारित किया जाता है क्योंकि मौन जमा होता है: रिकॉर्ड में कुछ भी न होने के पंद्रह वर्ष, पाँच वर्षों वाले उसी दावे के समान नहीं हैं, और flat band ने ऐसा कहा था। जिस प्रदाता का launch year अज्ञात हो, उससे यहाँ कुछ नहीं लिया जाता, R08 के अनुसार

R08_unknown_pricing6 चैनलconstraintस्कीमा में प्रत्येक जोखिम और न्यूनतम-सीमा तालिका

अंकगणितीय नियम के रूप में निर्दोषता की धारणा

केवल प्रदाता के विरुद्ध findings पर लागू होता है, और ऐसे अज्ञात पर कभी लागू नहीं होता जिसे प्रकाशित channel prior के रूप में लिखा गया हो (C01 = prior_0.550), जो base rate है, finding नहीं। अन्यथा उस field के लिए risk(unknown) <= 0.50 x risk(worst confirmed value) और कभी उसके बराबर नहीं; caught lie हमेशा blank से ऊपर होता है; lie axis और हर event field पर risk(unknown) = 0.000 सीधे; blank की पूरी कीमत एक बार ignorance में चुकाई जाती है, जहाँ उसे ours के रूप में लेबल किया जाता है

R09_channel_combination8 चैनलnoisy_or8 फ़ील्ड पढ़ता है

आठ चैनल एक संख्या कैसे बनते हैं

स्कोर = 100 x आठ चैनलों पर product(1 - min(0.90, r_c)); कोई सर्वव्यापी न्यूनतम या अधिकतम सीमा नहीं; S18 नौवें चैनल के रूप में नहीं, बल्कि अखंडता के भीतर शामिल होता है

R10_disclosure_decayप्रकटीकरणdecaymax4 फ़ील्ड पढ़ता है

प्रतिकूल घटनाएँ भी पुरानी पड़ती हैं

प्रकटीकरण = P01, P02 और P03 में से उस फ़ील्ड के अपने मूल्य का decay के बाद अधिकतम — सबसे खराब स्थिति में लिया गया एक मार्ग, कभी संयुक्त नहीं, क्योंकि एक ही ज़ब्ती की तीन कोडिंग एक ही ज़ब्ती हैं; उसी प्रकरण की P12_case_history प्रविष्टि की तारीख पर decay(plateau=12, half_life=60, floor=0.35), जिसका मिलान प्रविष्टि में कही गई घटना के आधार पर हो — P01 का मिलान seizure से, P03 का court_order, subpoena या mandate_order से — और कभी उसके परिणाम के आधार पर नहीं, क्योंकि कुछ भी न देने वाला प्रकरण भी वही प्रकरण है जो निष्कर्ष की तारीख निर्धारित करता है; P02 का मिलान परिणाम पर होता है क्योंकि वहाँ परिणाम ही तथ्य है; ऐसी प्रविष्टि के बिना प्रतिकूल घटना अपना अवक्षय-रहित मूल्य बनाए रखती है; अभ्यास-साक्ष्य के लिए 0.15 की तुलना में यहाँ 0.35 का ऊँचा floor रखने वाली अभ्यास-वक्र आकृति, क्योंकि सिद्ध प्रकटीकरण रिकॉर्ड पर स्थायी रूप से बना रहता है

R11_evidence_voidingप्रतिधारणप्रकटीकरणअखंडताgate1 फ़ील्ड पढ़ता है

नियंत्रण में बदलाव से हस्तांतरित होने वाली चीज़ें फिर से निर्धारित होती हैं

M16 से पहले का साक्ष्य वर्तमान स्वामी से संबद्ध नहीं होता: ऑडिट श्रृंखला-बोनस खो देते हैं, प्रकटीकरण घटनाएँ R10 floor तक गिरती हैं, और सहोदर निष्कर्ष बिल्कुल स्थानांतरित नहीं होते

R12_report_plausibilityअखंडताअज्ञानताthreshold5 फ़ील्ड पढ़ता है

पारदर्शिता रिपोर्ट का मूल्य उसकी सामग्री के बराबर है

जब P09 = 0 हो, P08 params.min_requests से ऊपर हो और रिकॉर्ड यह स्थापित करता हो कि प्रति-व्यक्ति रिकॉर्ड प्रकटीकरण के लिए मौजूद है — अर्थात् प्रतिधारण की गंभीरता params.min_retention के बराबर या उससे अधिक हो — तब P06 = zero_implausible। केवल उपयोगकर्ता के पैमाने से इसका निर्णय करना उस उद्देश्य के विपरीत को दंडित करता था जिसके लिए यह बनाया गया था: जो प्रदाता अपने आँकड़े प्रकाशित करता है और कोई स्वीकृत अनुरोध नहीं होने की रिपोर्ट करता है, उसे झूठा कहा जाता था, जबकि जो कुछ भी प्रकाशित नहीं करता, वह कुछ भी नहीं चुकाता था। शून्य स्वीकृत अनुरोध केवल ऐसे प्रदाता के विरुद्ध अविश्वसनीय है जिसके अपने रिकॉर्ड में कुछ स्वीकृत करने योग्य वस्तु रखने की बात कही गई हो; स्थापित no-logs निष्कर्ष के विरुद्ध यह अपेक्षित उत्तर है, और मॉडल को एक चैनल में जिस बात का श्रेय दिया है, उसी पर दूसरे चैनल में अविश्वास नहीं करना चाहिए। जब यह सक्रिय होता है, P05 से स्थिति-राहत 0.00 पर निर्धारित होती है और अखंडता को params.route वाला मार्ग मिलता है

R13_derived_jurisdictionक्षेत्राधिकारnoisy_ormax6 फ़ील्ड पढ़ता है

अधिदेश फ़ील्ड निकाले जाते हैं, आंके नहीं जाते

MANDATE_COUNTRIES में C10 = M06; MANDATE_COUNTRIES में C11 = M11; जब M11 = M06 हो, तो दोनों एक ही परिस्थिति हैं और क्षेत्राधिकार max(C10, C11, P11) लेता है, noisy-OR कभी नहीं; फ़्लीट का जोखिम max(C09b, P04) के रूप में शामिल होता है, जो कंपनी वाले मार्ग से अलग मार्ग है; हाथ से लिखा गया override अपने स्रोत की मांग करता है और उसी रूप में प्रकाशित किया जाता है

R14_disclosure_rateप्रकटीकरणthreshold2 फ़ील्ड पढ़ता है

डेटा उत्पन्न करने वाले अनुरोधों का हिस्सा

P08 के params.min_requests तक पहुँचने के बाद rate = P09 / P08; risk = params.weight x rate; इसे rate के साथ प्रकाशित किया जाता है क्योंकि क्षेत्राधिकारों के बीच तुलनीयता कम है — एक देश में request का अर्थ court order है और दूसरे में पत्र

R15_free_tier_flagकोई चैनल नहींflag2 फ़ील्ड पढ़ता है

मुफ़्त स्तरों का भुगतान किसी न किसी तरह किया जाता है

S22 को flagged तब किया जाता है जब params में नामित प्रत्येक फ़ील्ड, उसके लिए params द्वारा सूचीबद्ध मानों में से कोई एक रखता हो; अन्यथा नहीं; इससे किसी भी अक्ष पर स्कोर नहीं बदलता — दोनों इनपुट पहले ही अपने उचित स्थान पर मूल्यांकित हैं, और उनके संयोजन का मूल्यांकन करना वही औसत निकालना होगा जिसे अस्वीकार करने के लिए दोनों अक्ष मौजूद हैं

R16_opaque_at_mass_scaleअखंडताthreshold2 फ़ील्ड पढ़ता है

जितने अधिक लोगों को अस्पष्टता ढकती है, वह उतनी ही बदतर होती है

X03 = अपारदर्शी और M08 = बड़े पैमाने पर -> अपारदर्शी के लिए X03 के अपने मूल्य के बजाय params.at_mass_scale

R17_location_noticeक्षेत्राधिकारderivation3 फ़ील्ड पढ़ता है

जहाँ अधिदेश वाले देश की पेशकश की जाती है, वहाँ वास्तव में क्या मौजूद है

C09 = MANDATE_COUNTRIES में आने वाले U02 देश, व्युत्पन्न और कभी हाथ से नहीं भरे जाते। C09 अकेले कुछ नहीं जोड़ता और पूर्णता के हर के अंश से बाहर रहता है: ऐसे देश में एग्ज़िट देना अपने-आप में कुछ नहीं कहता, और इसे पाठक द्वारा चुने गए स्थान के विरुद्ध प्रकाशित किया जाता है। जोड़ा जाने वाला C09b है, वह एकमात्र प्रश्न जिसे C09 के non-empty होने पर पूछना सार्थक है — क्या हार्डवेयर वास्तव में उस अधिदेश के अधीन स्थित है या स्थान वर्चुअल है और हार्डवेयर कहीं और है। C09 के empty होने पर C09b n/a है, और P04 के साथ max से जुड़ता है: अधिदेश के अधीन उपस्थिति एक ही परिस्थिति है, जिसे दो बार कोड किया गया है

R18_audit_gateप्रतिधारणgatemax2 फ़ील्ड पढ़ता है

ऑडिट प्रतिधारण की किस शाखा को अपनाता है

V11 प्रतिधारण बताता है -> params.credence_stated पर stated शाखा; V01 = yes_* और V11 मौन -> params.credence_silent x subject_factor पर silent शाखा (जहाँ subject स्थापित नहीं है वहाँ params.subject_default), और कोई शाखा params.credence_max से अधिक नहीं होती; अन्यथा कागज़ी साक्ष्य बिल्कुल नहीं; चुनी गई शाखा पर severity = max(C01_linkable_retention, V11_audit_findings), noisy-OR कभी नहीं — एक ही परिस्थिति को दो बार कोड किया गया है (R04 की तरह)

R19_audit_decayप्रतिधारणdecay1 फ़ील्ड पढ़ता है

कॉन्फ़िगरेशन में लगातार बदलाव होते रहते हैं

decay(params.decay) — महीनों में निरंतर, कोई नॉट नहीं

R20_practice_agesप्रतिधारणdecaymax1 फ़ील्ड पढ़ता है

हर दस्तावेज़ित घटना अपनी तारीख़ रखती है

P12 में outcome = nothing_produced वाली प्रत्येक घटना decay(practice, अपनी तारीख) का योगदान देती है; फ़ील्ड का practice मान उसकी घटनाओं पर max होता है, उनका योग कभी नहीं; P01 और P03 के एकल-तारीख वाले पठन को प्रतिस्थापित करता है, जिसमें कई ज़ब्तियों को एक में समेट दिया गया था

R21_circumvention_decayusabilitydecay1 फ़ील्ड पढ़ता है

ब्लॉकिंग साक्ष्य से तेज़ी से आगे बढ़ती है

U06 = जब फ़ील्ड की अपनी यथास्थिति तारीख 12 महीनों से अधिक पुरानी हो जाती है, तो दावा किए गए अनुसार स्थापित स्कोर; रिकॉर्ड में हर फ़ील्ड की तारीख पहले से है, इसलिए आयु वहीं से पढ़ी जाती है, मूल्य में लिखी नहीं जाती; decay वाला एकमात्र उपयोगिता फ़ील्ड, क्योंकि यही एक ऐसा फ़ील्ड है जिसकी सत्यता समाप्त हो जाती है

R22_completenessअज्ञानताconstraintहर फ़ील्ड का पूर्णता कॉलम

हर का हर भाजक क्या गिनता है

पूर्णता = हाँ वाले substantive फ़ील्ड; n/a हर से अंश को छोड़ देता है, अज्ञात उसमें बना रहता है; पहचान फ़ील्ड, model outputs, दोहराए गए labels और उपयोगिता फ़ील्ड सभी बाहर हैं — उपयोगिता कवरेज को S16 के रूप में अलग से रिपोर्ट किया जाता है

R23_credence_defaultsप्रतिधारणconstraintस्कीमा में प्रत्येक कारक तालिका

अपठित साक्ष्य का श्रेय नहीं दिया जाता

यह R08 का प्रतिबिंब है और जानबूझकर उसके साथ सममित नहीं है। उस फ़ील्ड में factor(unknown) <= वास्तविक साक्ष्य-स्तर की सबसे कमज़ोर श्रेणी, और प्रकटीकरण से इनकार को कूटबद्ध करने वाले किसी भी मान (V06 unnamed, V02 none) से सख्ती से ऊपर होना चाहिए। किसी ऐसे ऑडिट को, जिसे किसी ने पढ़ा तक नहीं, उसके अंकित मूल्य पर श्रेय देना ही खरीदी गई रिपोर्ट के स्कोर में धुलकर शामिल होने का तरीका है; अपनी अज्ञानता को ऐसे गिनना मानो वह प्रदाता का इनकार हो, इसका उलटा दोष है। अप्रमाणित साक्ष्य को श्रेय देने से इनकार आरोप नहीं है — प्रदाता पूर्व-आकलन, यानी बाज़ार की आधार-दर, पर लौटता है, किसी निष्कर्ष पर नहीं

R24_retention_compositionप्रतिधारणproductmax14 फ़ील्ड पढ़ता है

प्रतिधारण के उप-चैनल एक संख्या कैसे बनते हैं

चारों sub-channels का औसत नहीं लिया जाता। credence.paper = R18 द्वारा चुनी गई शाखा (stated: credence_stated; silent: credence_silent x subject_factor) x उस शाखा के अपने .conf का source_credence x audit_decay (R19) x publication_factor x engagement_factor (firm x standard x assurance strength) x stated शाखा पर scope_factor x series_bonus जब R11 series को कायम रखता है, और इसकी ऊपरी सीमा credence_max है। credence.practice = तारीख वाली nothing_produced घटनाओं पर practice_credence x practice_decay (R20) का max। credence = min(credence_max, max(paper, practice) + secondary_weight x min(paper, practice)) — दो प्रकार के साक्ष्य एक से बेहतर हैं, और साक्ष्य की कोई मात्रा निश्चितता तक नहीं पहुँचती। severity = R18 के अनुसार प्रति R18 max(C01, V11), या जब दोनों में से कोई भी स्थापित न हो तो prior। retention = credence x severity + (1 - credence) x max(severity, prior): बाज़ार की आधार-दर की ओर प्रतिगमन केवल ऊपर की दिशा में है, इसलिए अपने विरुद्ध दिया गया स्वीकारोक्ति अपना प्रत्यक्ष मूल्य बनाए रखती है। retention.floor = max(retention, C12 floor:) अंत में, क्योंकि tunnel तक सीमित ऑडिट app में किसी तथ्य को स्पष्ट नहीं कर सकता

R25_integrity_compositionअखंडताnoisy_or14 फ़ील्ड पढ़ता है

अखंडता के मार्ग एक संख्या कैसे बनते हैं

अखंडता = fire होने वाले रूटों पर product(1 - route) का 1 से अंतर: झूठ अक्ष (R04), स्वामी की पारदर्शिता (mass scale पर R16), स्वामी समूह का इतिहास, monetisation को समूह द्वारा बेची जाने वाली चीज़ों के साथ मिलाकर (R03), incident handling, absolute claims, lifetime push, खरीदी गई coverage (R01), implausible-report रूट (R12), store-declaration अंतराल (R28), disclosure_rate_weight x rate (R14) और cluster contagion (R02, S18)। रूट compound होते हैं क्योंकि वे अलग-अलग findings हैं; जोड़े जो एक ही परिस्थिति को दो बार coded करते थे, उन्हें उनके अपने rule में max से पहले ही collapse कर दिया गया था, इसलिए यहाँ फिर से कुछ collapse नहीं किया गया

R26_hygiene_compositionस्वच्छताcapped_sum12 फ़ील्ड पढ़ता है

स्वच्छता के फ़ील्ड एक संख्या कैसे बनते हैं

स्वच्छता = min(params.cap, यहाँ route किए गए प्रत्येक फ़ील्ड के risk: price का योग)। security axis पर एकमात्र additive channel: ये छोटे स्वतंत्र leaks हैं जो जमा होते हैं, न कि कोई एक finding outcome तय करती है, और cap यह सुनिश्चित करता है कि मामूली collection का ढेर disclosure जैसा न पढ़े। किसी list फ़ील्ड का मूल्य उसके सबसे सस्ते member जितना है — एक anonymous payment method पर्याप्त है — और जब किसी member का मूल्य निर्धारित नहीं हो, तो वह अपने अज्ञात मूल्य पर वापस जाता है। C13_weakest_protocol यहाँ एक derived summand है (R32): कोई live legacy transport अतिरिक्त रूप से collected होने वाली एक और चीज़ है, न कि outcome तय करने वाली finding

R27_report_concealmentअखंडताmax2 फ़ील्ड पढ़ता है

अनुरोधों की गारंटी देने वाले पैमाने पर प्रकटीकरण के बारे में मौन

mid या mass scale का प्रदाता निश्चित रूप से requests प्राप्त करता है, इसलिए संख्याओं की स्थापित अनुपस्थिति प्रदाता के बारे में एक तथ्य है, न कि हमारी research में अंतराल: P05 = none पर 0.150, fresh_no_numbers पर 0.100 — प्रकाशित report में उस एक महत्वपूर्ण number का छूट जाना इसका सबसे तीखा रूप है — और stale पर 0.050। यह केवल स्थापित value पर fire होता है; अज्ञात यहाँ कुछ charge नहीं करता और अज्ञानता में priced है, जहाँ हमारा स्वयं न देखना आता है। R12 का mirror: एक अविश्वसनीय number का मूल्यांकन करता है, यह किसी भी number की अनुपस्थिति का मूल्यांकन करता है

R28_store_declaration_gapअखंडताmax1 फ़ील्ड पढ़ता है

स्टोर की घोषणा उस नीति के विरुद्ध जो प्रदाता ने स्टोर को दी थी

अनिवार्य store form provider का अपने app के बारे में signed statement है, इसलिए form में घोषित कोई भी चीज़ उस policy में भी दिखाई देनी चाहिए जिसकी ओर provider स्वयं store को निर्देशित करता है। केवल एक दिशा में पढ़ें: app, service का subset है, इसलिए policy की तुलना में कम घोषित करने वाला form scope से समझाया जाता है और कुछ charge नहीं करता, जबकि form द्वारा घोषित और policy में कभी न उल्लिखित category के लिए ऐसा कोई बहाना नहीं है। मूल्यांकन उस undisclosed category से प्रकट होने वाली चीज़ के आधार पर है: identifier या diagnostic पर 0.150, behaviour — app activity, installed apps, location या कोई advertising purpose — पर 0.300, और no-logs claim द्वारा नकारी गई collection को ही घोषित करने पर 0.450 charge होता है। दोनों stores collection को अलग-अलग define करते हैं, इसलिए Apple form और Google form के बीच का अंतर अपने-आप में finding नहीं है। stores के बीच का सबसे बड़ा अंतर निर्णायक है

R29_session_stateप्रतिधारणconstraint2 फ़ील्ड पढ़ता है

कनेक्शन, कनेक्शन का रिकॉर्ड नहीं है

C01 यह मूल्यांकित करता है कि session समाप्त होने के बाद provider किसी व्यक्ति से क्या link कर सकता है। tunnel चालू रहने तक ही मौजूद state — source IP, account id और connection timestamp, जिन्हें server packets route करने और device limit लागू करने के लिए रखता है — connection स्वयं है, उसका record नहीं, और उसे retention के रूप में मूल्यांकित करना provider से VPN के काम करने का वर्णन करने के लिए charge करना है। इससे भी बुरा यह है कि इसमें कुछ न कहने से अधिक charge होता है: इस फ़ील्ड पर blank का market prior 0.550 है और source_ip का 0.750, इसलिए fifteen-minute buffer का ईमानदार वर्णन silence से अधिक महँगा था। यह carve-out संकीर्ण है, और ऐसा होना आवश्यक है, वरना यह वही sentence बन जाएगा जो हर provider लिखता है। यह केवल वहाँ लागू होता है जहाँ provider का अपना document session के अंत से जुड़ी deletion window बताता है और वह 24 घंटे से अधिक लंबी नहीं है — calendar की सबसे छोटी इकाई, service को आवश्यक किसी भी teardown से लंबी और किसी log द्वारा रखी जाने वाली किसी भी rotation से छोटी। Undeclared duration retention है। Calendar period — 7 दिन, 30 दिन, या rotation cycle — wording चाहे जैसी हो, retention है, क्योंकि design के अनुसार वह session से अधिक समय तक रहता है। window के बाद provider जो भी रखता है, वह अभी भी अपने tier के योग्य है, और carve-out केवल provider के claim को पढ़ता है: जहाँ audit ने data को मौजूद पाया, R18 finding को claim से ऊपर रखता है

R30_usability_foundationusabilitythresholdहर उपयोगिता फ़ील्ड का भार कॉलम

उपयोगिता स्कोर का कितना हिस्सा तालिका पर निर्भर है

usability sum उस weight से divide होता है जिसे वह पढ़ सका: कोई फ़ील्ड जिसे किसी ने स्थापित नहीं किया, denominator में रहता है, zero score नहीं बनता, क्योंकि coverage, quality नहीं है। इसकी लागत यह है कि score अपनी ही foundation नहीं देख सकता — जिस column का heaviest field unread हो, वह भरे हुए column जैसी ही number की shape देता है। S21 = weight read / weight live, जहाँ live हर weighted usability field है, सिवाय उन fields के जो n/a हैं। usability_foundation_floor से नीचे S20 = no_data: आधे से कम table पर आधारित number यह बताता है कि कौन से fields भरे गए थे, न कि product क्या करता है। floor security वाले से stricter है क्योंकि इस axis में ignorance channel नहीं है — security score के भीतर blank के लिए charge करता है और usability उसके लिए कहीं charge नहीं करता। score फिर भी no_data के अंतर्गत published है, ठीक वैसे ही जैसे security score है; रोकी गई number को check नहीं किया जा सकता

R32_protocol_floorस्वच्छताderivationmax1 फ़ील्ड पढ़ता है

अब भी पेश किया जाने वाला सबसे कमज़ोर परिवहन

C13_weakest_protocol, U07_protocols में C13 की अपनी table के risk order के अनुसार सबसे खराब protocol है, जिसे load time पर derive किया जाता है और कभी hand-filled नहीं किया जाता — R17 द्वारा U02 से C09 derive करने जैसी ही संरचना। यह R26_hygiene_composition में एक और summand के रूप में प्रवेश करता है और वहाँ के हर term की तरह hygiene channel cap से bound है। जिस fleet में केवल modern transports उपलब्ध हों, वहाँ field किसी name के बजाय not_applicable है: 0.000 से अधिक कोई protocol pricing न होने पर point out करने के लिए कोई weak चीज़ उपलब्ध नहीं है, और tie-break order से अच्छे विकल्पों में सबसे कम अच्छे को चुनने से ऐसी finding published होगी जो किसी ने बनाई ही नहीं। यह field उस cheap segment के लिए रखा गया है जहाँ PPTP और L2TP अभी live हैं। proprietary price किसी vendor के अपना protocol लिखने के लिए charge नहीं है — यह यह न बता पाने की कीमत है कि वह protocol weak है या नहीं, इसलिए vendor_open की कोई लागत नहीं है: जिस vendor transport का source published हो और independently reviewed हो, उसका assessment किया जा सकता है, और assessment में ऐसा कुछ नहीं कहा गया है कि वह weak है। फिर भी charge करना ऐसी ignorance का मूल्यांकन होगा जो resolved हो चुकी है, और source published करना उसे रोककर रखने से अधिक महँगा बना देगा

R33_exit_conductआर्किटेक्चरmax2 फ़ील्ड पढ़ता है

एग्ज़िट अपने द्वारा ले जाए जाने वाले ट्रैफ़िक के साथ क्या करता है

आर्किटेक्चर = max(C00_architecture की price, C14_traffic_modification की price)। exit कौन चलाता है और exit उसमें से गुजरने वाली चीज़ों के साथ क्या करता है, ये एक ही प्रश्न हैं — tunnel का far end आपके पक्ष में है या नहीं — और एक खराब उत्तर इसे तय कर देता है, इसलिए channel दोनों prices का sum नहीं बल्कि उनमें से खराबतर लेता है: strangers द्वारा चलाया गया exit, जो आपके headers को भी rewrite करता है, किसी एक से दोगुना खराब नहीं है, उतना ही खराब है। headers_injected (0.300) passing traffic में जोड़ा गया session identifier या कोई अन्य header है, जो हर destination को user का एक name देता है; content_injected (0.500) pages में रखे गए scripts, advertising या अन्य material हैं; tls_interception (0.750) exit द्वारा encrypted sessions खोलना है। none को ऐसा कहने वाले document से पढ़ना पड़ता है, जो बहुत कम documents करते हैं, इसलिए unknown C00 जैसा ही market prior रखता है और बाकी काम अज्ञानता channel करता है