Apple ने पहले ही वेब डिवाइस attestation तैनात कर दिया था, और हमें लगभग पता भी नहीं चला
(httptoolkit.com)- Google के Web Environment Integrity प्रस्ताव पर विवाद चल रहा था, उसी बीच Apple ने macOS 13, iOS 16 और Safari में इसी तरह का वेब डिवाइस attestation सिस्टम, Private Access Tokens, पहले ही तैनात कर दिया
- Private Access Tokens में सर्वर HTTP 401 और
PrivateTokenchallenge भेजता है; फिर browser और OS डिवाइस की स्थिति को attester से सत्यापित कराते हैं और signed token के साथ दोबारा request भेजते हैं - Cloudflare और Fastly ने CAPTCHA कम करने के लिए इसे integrate किया है, लेकिन यही संरचना web server के लिए यह मांगने का आधार बनती है कि उपयोगकर्ता का डिवाइस वैध client साबित हो
- Safari की हिस्सेदारी करीब 20% है, इसलिए असर सीमित है; लेकिन Chromium-आधारित browsers 70% से ज्यादा हैं, इसलिए Google के प्रस्ताव के जुड़ने पर लगभग 90% web clients attestation के दायरे में आ सकते हैं
- Attestation नए browsers, OS, open source और user-modified devices को बाहर कर सकता है, और यह जोखिम है कि official support period या ad-blocking extension install होने जैसी शर्तों के आधार पर नियम और कड़े हो जाएं
Apple Private Access Tokens की तैनाती और उद्देश्य
- Google के लेखकों द्वारा विकसित और Chromium में prototype किए जा रहे दिखने वाले Web Environment Integrity प्रस्ताव को लेकर चिंताएं बढ़ रही हैं
- यह प्रस्ताव वेब पर attestation के बराबर है, जहां client को किसी trusted issuer ने approve किया है या नहीं, इसके आधार पर features या पूरे site access को सीमित किया जा सकता है
- वास्तविक trust issuers के Apple, Microsoft और Google होने की संभावना ज्यादा है
- Apple ने एक साल पहले ही बहुत मिलते-जुलते सिस्टम Private Access Tokens को विकसित कर तैनात कर दिया था, और यह फिलहाल macOS 13, iOS 16 और Safari में integrated है
- Apple Private Access Tokens को “पहचान जाहिर किए बिना यह साबित करने का शक्तिशाली tool कि HTTP request किसी वैध डिवाइस से आई है” के रूप में पेश करता है
- इस feature का मुख्य उद्देश्य CAPTCHA हटाना है, और Cloudflare तथा Fastly ने इसे वास्तविक clients को पहचानने के mechanism के तौर पर integrate किया है
- Cloudflare से जुड़ी व्याख्या: Eliminating CAPTCHAs on iPhones and Macs using new standard
- Fastly से जुड़ी व्याख्या: Private Access Tokens: Stepping into the privacy-respecting CAPTCHA-less
Private Access Tokens कैसे काम करते हैं
- Private Access Tokens HTTP के ऊपर होने वाला अपेक्षाकृत सरल exchange है, जिसे built-in browser API संभालता है और OS components के साथ मिलकर यह जांचता है कि browser और OS वैध हैं या नहीं
- यहां “वैध” का मानदंड attester, यानी Apple जैसी इकाई, तय करती है
- मूल flow इस तरह है
- Browser web server को HTTP request भेजता है
- Web server request को reject करता है और HTTP 401 response तथा
PrivateTokenchallenge लौटाता है - Browser challenge के एक हिस्से और OS द्वारा दी गई verified device information को attester को भेजता है
- Attester यह जांचने के बाद कि डिवाइस वास्तविक है और modified नहीं है, origin द्वारा trust किए गए और attester पर भरोसा करने वाले token issuer के साथ एक signed token लौटाता है
- Browser
Authorizationheader में signed token डालकर request फिर से भेजता है - Server इस तथ्य के आधार पर कि client को trusted provider ने verify किया है, उस client के साथ अलग व्यवहार कर सकता है
- यह प्रक्रिया Safari इस्तेमाल करने वाले Apple devices पर पहले से होती है, जब Fastly या Cloudflare जैसी इस feature का उपयोग करने वाली services किसी request की वैधता पर संदेह करती हैं
- Private Access Tokens privacy protection के लक्ष्य से origin, issuer और attester flow को अलग करते हैं, लेकिन वेब पर मिलने वाला व्यवहार इस पर निर्भर करता है कि Apple device, OS और browser configuration को स्वीकार्य मानता है या नहीं
Safari और Chromium की फैलने की क्षमता में अंतर
- सिर्फ Private Access Tokens भी वेब और पूरी industry पर बोझ डालते हैं, लेकिन Safari की market share के कारण यह Google के प्रस्ताव जितनी तेजी से फैलना मुश्किल है
- Safari की browser market share अभी करीब 20% है
- Mobile पर करीब 25%
- Desktop पर करीब 15%
- Chrome सभी क्षेत्रों में 60% से ऊपर है, और Brave, Edge, Opera, Samsung Internet आदि को शामिल करने पर पूरा Chromium उससे करीब 10 percentage points और ज्यादा है
- जब केवल Safari यह feature देता है, तब कुछ providers इसका उपयोग कर सकते हैं, लेकिन बिना attestation वाले clients को block करना या उनके साथ अलग व्यवहार करना मुश्किल होता है
- भले ही Safari पुराने OS versions या browsers को attest न करे, users पर बड़ा असर डालना मुश्किल है, और users को सांख्यिकीय रूप से ज्यादा CAPTCHA देखने पड़ सकते हैं
- जब Chromium इस्तेमाल करने वाले web clients 70% से ज्यादा हैं, तब Web Environment Integrity लागू होने पर यह वेब के बड़े हिस्से में तेजी से फैल सकता है
- Web Environment Integrity और Private Access Tokens साथ मौजूद हों, तो लगभग 90% web clients संभावित रूप से attestation के दायरे में होंगे, और “attestation नहीं है, इसलिए संदेहास्पद मानकर treat करें” वाला दबाव बढ़ सकता है
Attestation वेब के खुलेपन को कैसे हिलाता है
- Attestation सिर्फ approved clients को इस्तेमाल की अनुमति देता है, इसलिए यह competition और innovation के लिए नुकसानदेह है
- नया browser या OS बनाना कठिन हो जाता है
- Open source, community और छोटे indie प्रयास ऐसे mechanisms से लगातार बाहर रखे जा सकते हैं
- यह तुलना सामने आती है कि अगर IE6 के दौर में attestation होता, तो Firefox और Chrome के उभार में बड़ी बाधा आती
- यह संरचना design के लिहाज से users के लिए अपने devices पर नियंत्रण कठिन बनाती है
- Modified software इस्तेमाल करने वाले users का वैध client के तौर पर attest न होना इसके मुख्य लक्ष्यों में से एक है
- Rooted Android phone से वेब browse करने जैसे use cases बाहर किए जा सकते हैं
- पूरी तरह user-modifiable OS या hardware को ऐसे प्रस्तावों द्वारा चाही गई तरह attest करना कठिन है
- Approval providers बाद में नियम और सख्त बना सकते हैं
- “सिर्फ official support की 2 साल की अवधि के भीतर वाले devices का attestation”
- “Ad-blocking extension install वाले browser का attestation नहीं”
- Web Environment Integrity के समर्थक मानते हैं कि कुछ requests में attestation से इनकार करने वाले holdbacks attestation-based blocking को रोक सकते हैं
- लेकिन चिंता है कि business pressure के कारण holdbacks व्यवहार में काम करना मुश्किल होगा, और Google का मौजूदा Android Play Integrity attestation यह तरीका नहीं अपनाता
- वेब की सफलता काफी हद तक इस बात पर निर्भर रही कि विविध clients और servers को आजादी से इस्तेमाल किया जा सकता था, और attestation design के स्तर पर इस आधार को तोड़ देता है
Android में पहले ही दिख चुका जोखिम
- Android पर technically अपना OS बनाकर चलाया जा सकता है, और LineageOS जैसी Android distributions भी सामान्य रूप से काम करती हैं
- लेकिन attestation feature के कारण banking apps जैसी core apps द्वारा users को संदिग्ध मानकर block करने का जोखिम लगातार बना रहता है
- Android versions के बीच competition रोकना भी समस्या है, लेकिन वेब पर browser और OS दोनों तरफ competition रोकना कहीं ज्यादा गंभीर नतीजे ला सकता है
- Anti-Fraud Community Group में इसी श्रेणी के संभावित web features पर चर्चा करने वाले अन्य प्रस्ताव भी हैं
- वेब पर fraud और bots वास्तविक समस्याएं हैं और बचाव के तरीकों पर चर्चा मूल्यवान है, लेकिन competition को block करना, open source और open web को कमजोर करना, और user device control हटाना कोई उचित trade-off नहीं है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
कल Google के शुरुआती प्रस्ताव पर “कंपनी को तोड़ना अब काफी समझ में आने लगा है”, “दफा हो Google”, “गुस्सा और दुख है”, “जुड़े लोगों की प्रतिष्ठा पूरी तरह खत्म हो गई” जैसी प्रतिक्रियाएँ बहुत थीं
आज यह सामने आया कि Apple ने पिछले साल न सिर्फ यही फीचर प्रस्तावित किया था, बल्कि उसे सच में लागू कर के deploy भी कर दिया था, फिर भी टोन कुछ ऐसा है: “बहुत पहले खो चुके सपनों को फिर से शुरू करने का दिलचस्प मौका हो सकता है”, “दोनों पक्षों की बात कुछ हद तक समझ आती है”, “फिलहाल Safari में इसे चालू रखकर 1–2 साल देखूँगा”
कुल मिलाकर रुख अब भी नकारात्मक है, लेकिन Apple और Google को लेकर टोन का फर्क इतना साफ है कि reality distortion field अब भी सलामत लगती है
उनमें से एक ने Hacker News पर भी सीधे पोस्ट किया था, इसलिए नापसंद करने वालों को लगता है कि अगर वे संबंधित लोगों को काफी परेशान करेंगे तो वे हार मान लेंगे, और इससे harassment को बढ़ावा मिलता है
Apple ऐसी चीज़ों पर समय नहीं लगाता; वह review करता है, plan बनाता है और execute करता है। संबंधित व्यक्ति कौन हैं यह पता नहीं चलता, आम तौर पर feedback भी नहीं माँगा जाता, और वे अक्सर plan का justification तक नहीं देते। Web forums पर Apple पर गुस्सा करना ईंट की दीवार पर गुस्सा करने जितना बेकार है
चेहराविहीन कंपनी वाला cliché यूँ ही नहीं है; यह कर्मचारियों की रक्षा के लिए बनाई गई जानबूझकर policy है
लेकिन Apple में उल्टा है। third-party apps install करने की आज़ादी को खतरनाक कहा जाता है, browser में iMessage इस्तेमाल करने की आज़ादी को बेतुका कहा जाता है, और iOS पर third-party browser इस्तेमाल करने की आज़ादी में ज़्यादातर लोगों को रुचि नहीं दिखती
दूसरी कंपनियों का lock-in effect बुरा है, लेकिन Apple का lock-in effect उसके user base द्वारा सक्रिय रूप से प्रचारित किया जाता है—यह बात प्रभावशाली है
Apple का तरीका Apple devices पर मानव users और गैर-मानव users में फर्क करने के साधन के ज्यादा करीब है, और Google के proposal की तरह services को मनमाने ढंग से browser या operating system block करने नहीं देता
अगर आप पहले से Apple device इस्तेमाल कर रहे हैं, तो बस इतना है कि आपको “इंसान हैं या नहीं” वाला CAPTCHA नहीं करना पड़ेगा
संदर्भ: https://developer.apple.com/wwdc22/10077
इसके उलट Google शोर मचाने वाले Google-विरोधी छोटे समूह को अपनी reputation लगातार घटाने देता है, और narrative control करने के लिए PR लगभग नहीं करता
लगता है अब भी भरोसा है कि “don’t be evil” की एक गूँज 20 साल बाद भी सुनाई देती रहेगी
Microsoft ने Windows में IE bundle किया तो वह भयानक बात थी, लेकिन Apple का Safari bundle करना और competing browsers को रोकना ग्राहकों के हित में बताया जाता है
यह सचमुच वह बिंदु हो सकता है जहाँ internet बँट जाए। 90s से इसकी भविष्यवाणी होती रही है
एक तरफ “साफ” authority-approved corporate web होगा जहाँ सबकी जरूरत से ज्यादा identity verification होगी, और दूसरी तरफ porn और decentralized communities से भरी ज्यादा ढीली graynet galaxy बन सकती है
अगर सारे tinkerer corporate network से धकेल दिए जाएँ, तो यह बहुत पहले खो चुके सपनों को फिर से शुरू करने का दिलचस्प मौका भी हो सकता है
मैं कल्पना करता रहा हूँ कि internet के ऊपर “समाज” को दर्शाने वाली bubble जैसी social superstructure बन गई है। 90s से इसके छोटे versions थे, लेकिन Myspace, Facebook, Twitter जैसे social media के उभार के साथ यह सच में शुरू हुआ
“cancel culture” का तुरंत बाद आना भी मुझे संयोग नहीं लगता। जब virtualized public sphere बन जाता है, तो सवाल यह हो जाता है कि कौन और क्या उसके भीतर आता है, यह तय कौन करेगा
रवैया कुछ ऐसा है: “आखिरकार लोग मेरे उन skills को test कर पाएँगे जिनका वे लंबे समय से मज़ाक उड़ाते रहे हैं”
दोनों मामलों में समस्या यह है कि नई व्यवस्था के तहत पीड़ित होने वाले अधिकतर लोगों को नज़रअंदाज़ कर दिया जाता है। corporate walled garden से निकलकर free information highway पर जाने वाले लोग बहुत कम होंगे
corporate web की धुंधली echoes ही graynet के जरिए संरक्षित रहती हैं, और digital archaeologists corporate web में छिपे खोए हुए ज्ञान के “secrets” खोद निकालने की कोशिश करते हैं
शायद किसी ने पहले ही ऐसा लिखा होगा, लेकिन यह काफी फिट बैठता है
घर के ऐसे environment में भी कुछ हद तक चाहते हैं जहाँ public cloud और private use मिलते हैं, जैसे personal use के लिए Cloudflare Access tunnel और MS365 business tenant
लेकिन मैं बिल्कुल नहीं चाहता कि यह personal web browsing experience या personal browser environment तक पहुँचे
अभी ये इच्छाएँ वास्तव में एक-दूसरे से टकरा रही हैं, और यह ऐसी technology है जिसकी बिल्ली पहले ही थैले से बाहर आ चुकी है
90s का cyberpunk सपना अच्छा है, लेकिन “net” से जुड़ने के लिए हमेशा internet provider नाम की bottleneck से गुजरना पड़ता है—यह उस physical reality को नज़रअंदाज़ करता लगता है
आखिरकार internet कितना anti-establishment हो सकता है, इसकी एक ऐसी barrier है जिसे दूर नहीं किया जा सकता
मैं गलत भी हो सकता हूँ, लेकिन Web Attestation, Android या Chrome OS नहीं बल्कि Linux डिवाइसों के लिए वेब को बराबरी के क्लाइंट की तरह इस्तेमाल करने पर मौत की घंटी साबित हो सकता है
Linux इतना विविध और हैक किए जाने योग्य platform है कि remote attestation भरोसेमंद तरीके से काम नहीं कर पाएगा, इसलिए आखिरकार उसे पूरी तरह बाहर कर दिया जाएगा
कुछ “आशीर्वाद-प्राप्त” distributions ही अपवाद होंगी, लेकिन ऐसी distributions industry के नियंत्रण में होंगी और फिर Linux की spirit से बहुत दूर हो जाएँगी
आप लगभग हर website के spam-prevention classifiers में फँसेंगे, और protected जगहों तक पहुँचने के लिए 3–5 बार CAPTCHA हल करना पड़ेगा
Wikipedia भी editing रोकता है: https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re...
लगता है मेरे पास ऐसी sites छोड़ने की willpower नहीं है, तो शायद दूसरी तरफ से content loading रोक दिया जाना ही मेरे लिए ज़रूरी चीज़ हो
अब यहाँ कह दिया है, तो यह राज़ नहीं रहा
https://github.com/jwise/28c3-doctorow/blob/master/transcrip...
वे भी इतने विविध और hackable platforms हैं कि ऐसे भविष्य में, जहाँ किसी खास hardware के होने का प्रमाण देना पड़ेगा, वे अपर्याप्त लगेंगे
अक्सर सुनता हूँ कि कुछ “आशीर्वाद-प्राप्त” distributions industry control में आ जाएँगी और Linux की spirit खत्म हो जाएगी, लेकिन यह ठोस रूप से कैसे होगा, यह कम ही सुनने को मिलता है
industry द्वारा नियंत्रित UNIX की वजह से Linux बना था, और अगर Linux से वह spirit छीन ली गई तो वह किसी दूसरे community project में fork हो जाएगा
जब तक GPL license हटाया नहीं जाता, Linux पूरी तरह इस्तेमाल से बाहर होने तक “Linux spirit” बनाए रखेगा
मैं इस दलील से सहमत नहीं हूँ कि Safari dominant browser नहीं है, इसलिए यह Google के प्रस्ताव जितना खतरनाक नहीं है
असल में Apple करे या Google करे, दोनों ही उतने ही बुरे हैं, और Apple ने पूरी तरह निराशाजनक विकल्प चुना है
अगर Google इसे आगे बढ़ाता लेकिन Apple मना कर देता, तो इसे व्यावहारिक रूप से enforce करना मुश्किल होता। आँकड़े Chrome जितने बड़े नहीं हैं, लेकिन इतने बड़े ज़रूर हैं कि सभी iDevice users को काटा नहीं जा सकता
सच में मायने रखने वाली कंपनियाँ सिर्फ़ तीन हैं: Apple, Google, Microsoft
अफसोस है कि इस बार वह एक और आपदा रोक नहीं पाएगा
इसी वजह से Apple को sideloading खोलने के लिए मजबूर करने वाले कानूनों को लेकर भी चिंता होती है। लोगों के अपने systems पर control रखने का विचार मुझे पसंद है, लेकिन डर है कि व्यवहार में यह Google के लिए web को client end तक पूरी तरह control करने की आखिरी कील साबित न हो जाए
जब भी मैं बताता हूँ कि उन्होंने जो feature implement किया है वह कई browsers के साथ compatible नहीं है, वे हमेशा कहते हैं कि Firefox छोड़कर Chrome इस्तेमाल करो
किसी चीज़ को चलाने के लिए Safari पर switch करने को मुझे कभी नहीं कहा गया। यह अपने आप में बहुत कुछ बताता है
iOS पर यह feature बंद किया जा सकता है ऐसा लगता है
Settings में जाएँ, सबसे ऊपर वाला user account चुनें, “Password & Security” में जाएँ, फिर Advanced तक नीचे scroll करके “Automatic Verification” बंद कर दें
https://blog.cloudflare.com/how-to-enable-private-access-tok...
https://support.apple.com/en-us/HT213449
System Settings -> iCloud Settings(यूज़र नाम) -> Password & Security -> Automatic Verification
अगर Chrome WEI deploy करता है, तो कई Chromium forks भी इसे बंद करने देंगे, भले ही Chrome न दे, और Firefox भी इस्तेमाल किया जा सकता है
समस्या तब होगी जब बैंक, tax authorities और आपकी पसंदीदा streaming service इस feature की माँग शुरू कर देंगी
असली बात यह है कि सामान्य users के एक बड़े हिस्से के पास यह feature होना ही काफी है
मैंने वास्तव में इसे notice किया था और blog पर लिखने का भी सोचा था, लेकिन मेरे हिसाब से यह समस्या न लगने की एकमात्र वजह यह थी कि यह सिर्फ़ Apple platforms पर implemented था, इसलिए services के पास इसके आधार पर users को सचमुच restrict करने का तरीका नहीं था
यह बस एक अतिरिक्त factor था जिसे लोग एक और signal की तरह इस्तेमाल कर सकते थे
इसके उलट, Google का प्रस्ताव इसे स्पष्ट रूप से हमेशा चालू रहने वाले feature के रूप में push करने में दिलचस्पी रखता है
“deterministic platform integrity proof” जैसे use cases अभी client fingerprinting पर निर्भर हैं, यह व्याख्या असल में यह दावा है कि सीमित entropy वाला deterministic proof intrusive fingerprinting की जगह लेगा और long term में privacy के लिए ज़्यादा बेहतर practices का रास्ता खोलेगा
Apple ने इसे पहले implement किया, यह तथ्य बस इतना साबित करता है कि जो लोग उम्मीद करते हैं कि Apple हमें बचाएगा, वे भोले हैं
यह क्षेत्र वाकई दिलचस्प है और मतभेद पैदा करने लायक भी
वेब पर ऐसे use case बहुत ज़्यादा हैं जहाँ यह जानना ज़रूरी होता है कि आप “भरोसेमंद” hardware और software stack से बात कर रहे हैं या नहीं
कई सालों से हम यह मानकर design और build करते आए हैं कि stack पर भरोसा लगभग नहीं है; इससे complexity और लागत बहुत बढ़ जाती है, features सीमित हो जाते हैं, और सब कुछ उस स्थिति की तुलना में कहीं ज़्यादा मुश्किल हो जाता है जहाँ भरोसेमंद stack मानकर चला जा सके
साथ ही, जैसा अभी बड़े स्तर पर बताया जा रहा है, Big Tech monopolies के शामिल होने पर भरोसे की अवधारणा बहुत कठिन हो जाती है
एक तरफ, दुनिया में बहुत कम कंपनियाँ हैं जो लगातार threat actors से निपटने के लिए बड़ी tech teams चला सकती हैं, इसलिए अच्छा होगा अगर हम उनके security promises पर भरोसा कर सकें। अगर वे promises भरोसेमंद हों, तो वे किसी व्यक्ति द्वारा अपने software और platform के बारे में किए जा सकने वाले किसी भी promise से बेहतर हैं
दूसरी तरफ, hacker के प्लेटोनिक अर्थ में देखें तो “भरोसेमंद” का मतलब “monopoly द्वारा प्रमाणित” और “शायद स्थानीय सरकारी एजेंसी का backdoor मौजूद” पढ़ा जाता है; इससे control, innovation की कमी, और अंततः कुछ ही players के प्रभुत्व वाले फासीवादी tech future की ओर एक और कदम नीचे चला जाता है
आखिरकार, मुझे लगता है कि सफल हो सकने वाले समाधान में registry-based approach के बजाय भरोसेमंद open hardware certification technology शामिल होनी चाहिए। मजबूत local attestation बनाना और स्वतंत्र रूप से verify करना संभव होना चाहिए
silicon side पर इस समस्या से निपट रही कुछ tech companies को मैं जानता हूँ, लेकिन यह बहुत कठिन समस्या है, और यह भी पक्का नहीं कि अभी उनके जीवित रहने लायक demand है या नहीं
निजी तौर पर, फिलहाल मैं Safari में इसे enabled रखकर अगले 1–2 साल तक देखना चाहूँगा
DRM technology पर भी ऐसे ही शब्दों में चर्चा होती है, लेकिन लक्ष्य user को भरोसा देना नहीं, बल्कि developer या content owner को भरोसा देना होता है
साफ दिखता है कि यह सचमुच भरोसे से जुड़ा मुद्दा नहीं भी हो सकता
आपको चुनना होगा कि state system के फायदे लेने हैं या उसकी लागत उठाना सार्थक है
ऐसे अधिकांश systems की समस्या यह है कि वे exception cases को बिल्कुल handle नहीं कर पाते
आबादी के 99% लोगों के लिए यह ठीक चलता है, लेकिन बाकी 1% के लिए मानो “खुद देख लो” वाली स्थिति हो जाती है
यह वैसा है जैसे आप office hours के बाद ऑफिस में प्रवेश करना चाहते हैं, सिर्फ अपनी भूली हुई car keys लेने के लिए, लेकिन robot entry से मना कर देता है
system को सुरक्षित रूप से design किया गया है, इसलिए आप robot को बातों से मना नहीं सकते। अगर कोई इंसान होता, तो आम तौर पर बातचीत करके उसे मनाना और कोई workable solution निकालना कहीं आसान होता
तकनीक वाले लोग आखिरकार technology से ही हल निकालने लगते हैं। “अगर तुम्हें problem है तो मैं solve कर दूँगा, DJ के बजाते रहने तक मेरी technology देखो”
सिर्फ इसलिए bank accounts hack हो जाते हैं क्योंकि कोई अच्छी बातें कर सकता है और human gatekeeper को मनाने के लिए plausible कहानी बना सकता है
अगर यह “हाँ, यह व्यक्ति असली इंसान है” कहने का साधन है तो उपयोगी हो सकता है, लेकिन यह सिर्फ system attestation है, इसलिए यह जानने का तरीका नहीं कि क्या यह malicious actors को रोक पाएगा, और क्या CORS जैसे दूसरे systems की तरह इसे गलत समझा और misuse किया जाएगा
इस system का logical conclusion यह बनता है: “अगर आपके पास normal system है तो आप normal user हैं, और नहीं है तो नहीं”
दोनों पक्षों की बात कुछ हद तक समझ में आती है
अगर दूसरों की मंशा को अच्छे नज़रिए से देखें, तो पहचाने गए इंसानों और उनके अधिकृत एजेंटों से भरा वेब शायद हमारे सामने दिख सकने वाली सबसे “साफ़” आदर्श वेब स्पेस हो सकता है
नकली अकाउंट्स और लिंक फार्म से भरा वेब आदर्श नहीं है
इस प्रवाह का सबसे स्पष्ट अंतिम पड़ाव सरकार द्वारा जारी डिजिटल पहचान-पत्र है, जो पहचान साबित करता है और लॉगिन की भूमिका भी निभाता है
थोड़ा ध्यान से देखें तो यह उस दिशा में जाने वाली एक सीढ़ी जैसा लग सकता है
क्या यह 70 के दशक वाला आदर्शवाद सच हो गया? ऐसा नहीं है। लेकिन मुझे यह कुछ हद तक तर्कसंगत समझौता लगता है
अगर सरकार पर भरोसा नहीं किया जा सकता तो? वह समस्या शायद कोई भी इंटरनेट हल नहीं कर पाएगा। वह असली दुनिया की समस्या है
मुझे तो यह ज़्यादा sterilized web जैसा लगता है
इस बात को थोड़ी देर के लिए नज़रअंदाज़ कर दें कि इंसान आखिरकार उस सिस्टम को भी बायपास करने का तरीका खोज लेते हैं, और मान लें कि यह सबसे “साफ़” वेब स्पेस बन भी जाता है, तब भी यह मानकर चल रहा है कि उपभोक्ता यही चाहते हैं
native app की दुनिया में App Store, lockdown control और app identity पहले से हैं, फिर भी वेब अभी भी commerce पर हावी है, और Figma जैसे उदाहरणों से तो उलटे और मज़बूत होता लगता है
तो इस “शुद्ध” वेब की मांग की पुकार कहाँ है? कम से कम consumer side की मांग तो बिल्कुल ऐसी नहीं दिखती
इतनी बेहिसाब मज़बूत पहचान-प्रमाणीकरण की ज़रूरत क्यों है? अगर वाकई ज़रूरत थी, तो इंटरनेट अब तक कैसे चलता रहा?
लेकिन फिलहाल असल में कोई ऐसा प्रस्ताव दे भी नहीं रहा। Apple या Google का तरीका दोनों ही उसके करीब तक नहीं जाते। वे जो करना चाहते हैं वह platform की “integrity” की गारंटी है
ठीक कौन-सी integrity? उदाहरण में कहा गया है कि यह दिखाता है कि user एक सुरक्षित Android device पर web client चला रहा है
यानी यह न तो बताता है कि user कोई unique व्यक्ति है, न ही व्यक्ति के बारे में कोई काम का identifier देता है। इस उदाहरण और Apple के मामले में यह बस इतना बताता है कि device rooted या jailbroken नहीं है
असल में यह concept बड़े cat-and-mouse game के हिस्से के रूप में ही उपयोगी है। copyright protection की तरह remote attestation की सीमा भी उसी चीज़ से तय होती है जिसे वह वास्तव में साबित करता है
cinema hall में camcorder recording रोकना मुश्किल है, और आखिरकार फिल्म के photos की श्रृंखला और PCM sample frames होने की सच्चाई का फायदा उठाने वाले कई intermediate steps होते हैं; वैसे ही device महंगा हो तो भी कोई कई devices हासिल करके काम करे, इसे रोका नहीं जा सकता
system को धोखा देने के लिए Android devices के ढेर रखने वाले लोग पहले से ही बहुत हैं, और कुछ मामलों में एक device 50 डॉलर में मिल जाता है, इसलिए यह कोई meaningful barrier नहीं है
आखिर में इसका असर बस bot चलाने की लागत और complexity बढ़ाने तक सीमित है, और break-even point को काफी ऊपर कर दें तो theory में कहा जा सकता है कि जीत गए। लेकिन spam और fraud से मिलने वाला मुनाफा इतना बड़ा है कि ऐसा नहीं होगा
वर्षों की countermeasures के बाद भी हम अभी करीब तक नहीं पहुँचे, और ऐसे systems को चकमा देने वाली industry में बहने वाला पैसा उस cost को आसानी से उठा सकता है
सरकारी ID जोड़ देने से भी बात नहीं बदलती। लगभग हर spam operation के पीछे वास्तविक लोग होते हैं, इसलिए अगर किसी के नागरिक होने का blind proof मिल भी जाए, तो उस व्यक्ति के बारे में हमें लगभग कुछ पता नहीं चलता
मदद तभी होगी जब legitimate target होने के proof के बजाय वास्तव में हर व्यक्ति की unique ID मिलनी शुरू हो
और अगर यही इंटरनेट का अंतिम पड़ाव है, तो सच कहूँ तो यह पूरा प्रयोग किसी क़ीमत का नहीं था
fake mouse या keyboard लगाकर input सीधे feed भी किया जा सकता है
security hardware का कोई फायदा नज़र नहीं आता। एक निश्चित scale पर misinformation फैलाने वालों के लिए यह speed breaker तक नहीं बनेगा
यह सिर्फ बहुत अनाड़ी या हल्के malicious actors को थोड़ा असुविधाजनक बनाएगा, और browser बना सकने वाले लोगों तथा Linux users या Trusted Boot बंद करने वाले लोगों जैसे untrusted devices इस्तेमाल करने वालों को बहुत सीमित कर देगा
पता नहीं आपको AllAdvantage याद है या नहीं
सदी के मोड़ के आसपास यह एक service थी जो desktop पर ads दिखाने के बदले पैसे देती थी, लेकिन भुगतान केवल तभी करती थी जब PC वास्तव में इस्तेमाल हो रहा हो
लोगों ने mouse-moving devices से इसे चकमा दिया, और एक छोटी arms race शुरू हो गई
यह technology उनके लिए सपने जैसी चीज़ होती। वे जान सकते कि request असली browser से आई है या script से, और अगर untrusted driver से input simulate किया जाए या browser automated हो, तो attestation disable भी कर सकते
सचमुच बहुत अप्रिय technology है
यह बहुत popular security product category को browser में ही गहराई से integrate करने जैसा है
आज आप दार्शनिक रुख अपनाकर reCAPTCHA/hCAPTCHA इस्तेमाल करने वाली सभी websites को reject कर सकते हैं, और कल PAT इस्तेमाल करने वाली सभी websites को reject कर सकते हैं