EU Age Control: डिजिटल ID के लिए ट्रोजन हॉर्स
(juraj.bednar.io)- इसे केवल उम्र साबित करने वाले privacy-preserving authentication के रूप में प्रचारित किया जाता है, लेकिन वास्तविक डिप्लॉयमेंट संरचना हर देश के ऐप्स और वैकल्पिक रास्तों पर निर्भर करती है और यह एकल EU ऐप की तरह काम नहीं करती
- बड़े प्लेटफ़ॉर्म EU wallet की जगह पासपोर्ट स्कैन और liveness जांच करने वाले सामान्य KYC provider का इस्तेमाल कर सकते हैं, इसलिए privacy-preserving रास्ता अनिवार्य शर्त नहीं बल्कि एक विकल्प भर रह जाता है
- मौजूदा reference implementation का मुख्य रास्ता zero-knowledge proofs नहीं बल्कि ISO 18013-5 mdoc with ES256 का उपयोग करता है, और unlinkability भी मज़बूत गणितीय गारंटी के बजाय wallet के एक-बार-उपयोग credential rotation नियमों पर निर्भर है
- अगर ऐप इंटेग्रिटी वेरिफिकेशन में hardware attestation जुड़ जाए, तो अंतिम binary का Google या Apple द्वारा स्वीकृत कोड से मेल खाना ज़रूरी होगा, जिससे GrapheneOS या custom Linux phone जैसे डिवाइस बाहर रह सकते हैं
- relay attack को सभी signatures और attestation सही होने पर भी नहीं रोका जा सकता, और इसके साथ यह चिंता भी उठती है कि ऐसी संरचना उम्र सत्यापन से आगे बढ़कर revocable digital IDs की स्वीकृति तक ले जा सकती है
DSA बायपास रास्ते और KYC विकल्प
- कुछ प्रकार की सामग्री संभालने वाले बड़े प्लेटफ़ॉर्म के लिए age verification ज़रूरी है, लेकिन उन्हें अनिवार्य रूप से privacy-oriented EU wallet इस्तेमाल नहीं करना पड़ता
- प्लेटफ़ॉर्म EU wallet चुन सकते हैं
- साथ ही वे पूरे पासपोर्ट स्कैन और liveness जांच जैसी प्रक्रियाएँ करने वाले सामान्य KYC provider भी जोड़ सकते हैं
- privacy फीचर वैकल्पिक ही बने रहते हैं
- प्रचार privacy-preserving पहलू पर केंद्रित है, लेकिन नियमों के तहत कम निजी वैकल्पिक रास्ते भी अनुमत हैं
- हर देश की eID को सीधे जोड़ने का रास्ता व्यावहारिक रूप से कठिन बताया गया है
- 27 देशों की अलग-अलग national eID systems को एकीकृत करना जटिल है
- KYC कंपनियों के लिए भौतिक पहचान-पत्रों के दृश्य डेटा-बेस और फोटो-आधारित प्रक्रियाएँ बनाए रखना सस्ता और अधिक सार्वभौमिक रूप से काम करने वाला विकल्प है
- मौजूदा interoperability की तैयारी को भी कमज़ोर आंका गया है
- आधिकारिक trusted list में production apps की संख्या 0 है
- reference implementation को भी अभी अधूरा बताया गया है
- 2026 के अंत तक 27 देशों में साफ-सुथरी interoperability हो जाएगी, यह उम्मीद अवास्तविक मानी गई है
वास्तविक verification flow और device control
- मुख्य high-trust रास्ता NFC passport का उपयोग करता है
- फोटो पेज के नीचे की MRZ स्कैन करके NFC chip data पढ़ने और उसे decrypt करने की key प्राप्त की जाती है
- chip में signed data और धारक की JPEG photo होती है
- डिज़ाइन के अनुसार फोन पर real-time face photo लेकर उसे chip की फोटो से local matching किया जाता है
- यह local face matching इस बात को रोकने के लिए लिखा गया है कि बच्चा माता-पिता का पासपोर्ट स्कैन करके अपने लिए credential जारी न करवा ले
- ऐप open source होने पर भी, अगर वास्तविक राष्ट्रीय डिप्लॉयमेंट में hardware attestation लागू किया जाए तो मनमाना संशोधन रोका जा सकता है
- लेख के अनुसार फिलहाल reference code में server-side attestation verification अभी जुड़ी नहीं है
- लेकिन संरचना ऐसी है कि देश-विशेष डिप्लॉयमेंट्स को इसे जोड़ना होगा
- अंतिम binary का Google या Apple द्वारा signed उसी सटीक कोड से मेल खाना चाहिए
- यह security model कुछ डिवाइसों और operating systems को बाहर कर देता है
- GrapheneOS और custom Linux phone स्वीकार नहीं होंगे
- Huawei डिवाइस अपने hardware attestation के बावजूद Play Integrity पास नहीं कर पाते, ऐसा लिखा है
- उदाहरण के रूप में GrapheneOS attestation compatibility guide लिंक किया गया है
- एक सरल MRZ-only रास्ता भी है, लेकिन उसकी सीमाएँ बड़ी हैं
- यह NFC read या face matching के बिना केवल पहचान-पत्र की फोटो लेने वाला रास्ता है
- वास्तविक राष्ट्रीय ऐप्स इसे सपोर्ट करेंगे या नहीं, यह अस्पष्ट बताया गया है
- reference high-trust chip-based रास्ते की सिफारिश करता है
प्रचारित cryptography और वास्तविक तैनात cryptography के बीच अंतर
- बाहरी कथा zero-knowledge proofs पर केंद्रित है, लेकिन reference Android app के वास्तविक execution path में ZK crypto का उपयोग नहीं होता
- अभी काम करने वाला तरीका ISO 18013-5 mdoc with ES256 बताया गया है
- हर attribute पहले से signed होता है
- wallet केवल मांगे गए attributes ही प्रकट करता है, बाकी को salted-digest commitments से छिपाता है
- भले ही repository में ZK library शामिल हो, presentation path में उसे call नहीं किया जाता
- repository में मौजूद होने और वास्तव में switched on होने में अंतर बताया गया है
- देश-विशेष ऐप्स इसे बाद में सक्रिय करेंगे या नहीं, यह खुला प्रश्न छोड़ा गया है
- मौजूदा reference की unlinkability भी मज़बूत गणितीय गारंटी से अलग तरीके से समझाई गई है
- लेख इसे disposable-batch unlinkability कहता है
- यदि signed credentials को एक-एक बार ही इस्तेमाल किया जाए, तो केवल 18+ होने और issuer जैसी बातों का खुलासा हो सकता है, कोई unique identifier नहीं
privacy विशेषताएँ और सीमाएँ
- पूरा flow local-first के काफ़ी करीब है, लेकिन credential issuance server फिर भी आवश्यक है
- document scan और शुरुआती जांच फोन पर की जाती है
- attested app होने की शर्त पर issuance server कुछ हद तक भरोसा कर सकता है कि कौन-सा कोड चल रहा था
- server document signature verify करता है और signed credential जारी करता है
- verifier के नज़रिए से unlinkability केवल तब तक काम करती है जब wallet नियमों के अनुसार व्यवहार करे
- डिज़ाइन ऐसा नहीं है जिसमें दो proofs का गणितीय correlation analysis असंभव हो, बल्कि यह disposable credentials को एक बार उपयोग कर फिर नया लेने की व्यवस्था है
- अगर wallet इस नियम का पालन करे, तो अलग-अलग verifiers को अलग signatures दिखेंगे, जिससे उन्हें जोड़ना कठिन होगा
- अगर wallet धोखा दे या proof दोबारा उपयोग हो, तो वही signature bytes दिख सकते हैं और linking आसान हो जाती है
- आम धारणा वाला ZK = स्थायी unlinkability वाला कथन यहाँ लागू नहीं होता
- यह गुण इसलिए नहीं बना रहता कि cryptography reuse को ही निष्प्रभावी कर देती है, बल्कि इसलिए कि wallet rotation नियमों का पालन करे
- तुलना में BBS+ और CL signatures का उल्लेख है, जिनसे reuse होने पर भी unlinkable proofs बनाए जा सकते हैं
- issuer के नज़रिए से tracking का दायरा भी सीमित है
- जब उपयोगकर्ता ID प्रस्तुत करता है, तब issuer credential जारी करता है
- उसके बाद वह credential कहाँ और कितनी बार उपयोग हुआ, यह server नहीं जानता
- कल्पनीय rate limit भी issuance की संख्या तक सीमित है, वास्तविक उपयोग संख्या तक नहीं
- सामान्य wallet व्यवहार के तहत केवल इतना अनुमान लगाया जा सकता है कि उपयोगकर्ता किसी EU देश का नागरिक है, लेकिन कौन-कौन से accounts एक ही व्यक्ति के हैं या अलग साइटों की गतिविधियों को जोड़ना कठिन बताया गया है
Relay attack समस्या
- एक relay attack परिदृश्य प्रस्तुत किया गया है जिसका मानकों में संतोषजनक उत्तर नहीं मिलता
- जब कोई नाबालिग age-restricted साइट में प्रवेश करना चाहता है, तो वह proxy authentication service को QR code या link भेजता है
- वह service इसे एक वास्तविक वयस्क के साफ फोन तक पहुंचा देती है, जिसमें government wallet मौजूद है
- वयस्क के approve करते ही साइट को पूरी तरह वैध over-18 proof मिल जाता है और access दे दिया जाता है
- इस flow में कोई cryptographic verification विफल नहीं होती
- सभी signatures असली हैं, attestation भी असली है, और वयस्क सचमुच वयस्क है
- समस्या यह है कि protocol इस ब्राउज़र के सामने मौजूद इंसान से नहीं, बल्कि कहीं किसी wallet द्वारा approve किए जाने की घटना से bind होता है
- proximity check का अभाव इसकी मुख्य सीमा बताया गया है
- browser-side Digital Credentials API कुछ राहत केवल तब देता है जब उसी फोन पर browsing और authentication साथ हो रही हो
- डिवाइसों के बीच उपयोग होने वाले QR code और deep link अब भी खुले छेद बने रहते हैं
- Play Integrity भी इस समस्या को नहीं रोकता
- Play Integrity केवल यह attest करता है कि किस डिवाइस पर कौन-सा कोड चल रहा है
- यह नहीं बताता कि डिवाइस के सामने कौन है या वह डिवाइस कहाँ है
- proxy flow में relay करने वाली web service attestation का विषय नहीं होती, वह केवल bytes आगे बढ़ाती है
- वयस्क के register हो जाने के बाद resale model और आसान हो जाता है
- wallet में कम अवधि पर refresh होने वाले 30 disposable credentials होने की बात लिखी है
- issuer यह नहीं देख पाता कि वे credentials वास्तव में कैसे खर्च हो रहे हैं
- इसलिए proxy operator एक ही credential को अनेक नाबालिगों के लिए reuse कर सकता है और ऊपर की प्रणाली इसे पहचान नहीं पाएगी
- इसे implementation bug नहीं बल्कि protocol shape से उत्पन्न संरचनात्मक गुण कहा गया है
- इसलिए इसे 27 देशों के सभी मानक-अनुरूप ऐप्स में बने रहने वाली समस्या माना गया है
digital ID infrastructure तक विस्तार की चिंता
- age verification app को digital ID infrastructure की ओर जाने वाले entry point के रूप में देखा गया है
- शुरुआती तर्क बच्चों की सुरक्षा और हानिकारक सामग्री को रोकना है, लेकिन व्यवहार में इसे लोगों को अधिक सुविधाजनक attested wallet चुनने की दिशा में friction पैदा करने वाली संरचना कहा गया है
- इस संरचना में ऐप स्वयं भी attestation के दायरे में है, इसलिए क्या चल सकता है, इस पर Google या Apple का प्रभाव रहता है
- लिखा गया है कि credentials को issuer रद्द कर सकता है
- reference app के बारे में कहा गया है कि यह face photo केवल स्थानीय रूप से उजागर करता है
- साथ ही 27 देश अपने-अपने अलग versions बनाएँगे, इसलिए हर राष्ट्रीय implementation में अलग privacy bugs आने की आशंका जताई गई है
- बार-बार wallet invocation को Hawthorne effect पैदा करने वाला बताया गया है
- यदि विवादास्पद साइटों पर हर बार wallet निकालना पड़े, तो proof अनाम होने पर भी self-censorship बढ़ सकती है
- यह भी लिखा गया है कि सरकारों का ऐसे डेटा की सुरक्षा का रिकॉर्ड अच्छा नहीं रहा है
- आगे चलकर इसे Digital Euro जैसी अन्य प्रणालियों से जोड़ने की आशंका भी जताई गई है
- तब जीवन के बड़े हिस्से को दूर से बंद किया जा सकने की संभावना बताई गई है
- उदाहरण के तौर पर parking violation जुर्माना न भरने पर credential अस्थायी रूप से छीनने जैसी स्थिति की कल्पना की गई है
- निष्कर्ष में कहा गया है कि इंटरनेट access की कीमत के रूप में revocable digital IDs स्वीकार करने की आवश्यकता नहीं है
सार्वजनिक hacking मामलों के बारे में भेद
- रिपोर्ट की गई समस्याएँ दो श्रेणियों में बाँटी गई हैं
- mock-up bugs: file leak, बिना validation की MRZ scan, placeholder backend को hit करने वाला Chrome extension demo आदि
- structural properties: proximity binding का अभाव, client-side one-time-use, reuse पर टूटती unlinkability आदि
- पहली श्रेणी को राष्ट्रीय implementations में ठीक किए जा सकने वाले मुद्दों के रूप में वर्गीकृत किया गया है
- reference app का disk file leak ठीक कर दिया जाएगा, इसे मूलभूत समस्या नहीं माना गया है
- test credential हासिल करने के लिए धोखा देना संभव हो, तब भी लिखा गया है कि वास्तविक मुख्य रास्ता बिना-verify MRZ scanner mock-up नहीं बल्कि देश-विशेष eID systems होंगे
- दूसरी श्रेणी को bug नहीं बल्कि specification से सीधे निकलने वाले गुणों के रूप में देखा गया है
- इन्हें सभी मानक-अनुरूप राष्ट्रीय implementations में बने रहने वाली समस्या बताया गया है
- custom Chrome extension आधारित hacking को production environment में काम न करने वाला माना गया है
- attestation लागू होने पर ऐप verification में यह विफल हो जाएगा
- MRZ रास्ता भी वास्तविक EU common backend से जुड़ा नहीं है, और valid document registry हर देश के अधिकार क्षेत्र में बताई गई है
- mock-up को तोड़ देने जैसी demo को मूलतः library usage example पर हमला बताया गया है
- वास्तव में Slovak, Hungarian, German, Dutch, French आदि देश-विशेष apps अलग-अलग मौजूद होंगे
मांग और निष्कर्ष
- ऐसी प्रणाली की मांग मौजूद मानी गई है
- इंटरनेट को खतरनाक मानने वाले माता-पिता अपने बच्चों की सुरक्षा के साधन चाहते हैं
- बच्चे bypass कर पाएँगे या नहीं, इससे अलग, वास्तविक ग्राहक उन माता-पिता को बताया गया है जो बच्चे से अधिक स्वयं आश्वस्त होना चाहते हैं
- साथ में कुछ संदर्भ लिंक भी दिए गए हैं
- निष्कर्ष का आकलन चार बिंदुओं में संक्षेपित है
- EU fancy ZK apps की तैयारी धीमी है, इसलिए प्लेटफ़ॉर्म सामान्य KYC provider, AI face age estimator और अन्य साधनों का उपयोग कर सकते हैं
- specification के अनुसार लागू होने पर प्लेटफ़ॉर्म के लिए उपयोगकर्ता का असली नाम या accounts के बीच linking जानना कठिन रहता है, यानी सार्थक privacy गुण मौजूद हैं
- लेकिन यह गुण cryptographic enforcement से अधिक wallet behavior पर निर्भर है, और repository में मौजूद ZK mathematics फिलहाल सक्रिय नहीं है
- Google/Apple approved device न होने पर न चल पाने की बाधा और relay attack की संरचनात्मक सीमा साथ आती है
1 टिप्पणियां
Hacker News की राय
यह ट्रोजन हॉर्स नहीं है, बल्कि निर्णयों, बहसों और कानूनी दस्तावेज़ों में स्पष्ट रूप से लिखा गया लक्ष्य है
उम्र सत्यापन की आवश्यकताएँ इस बात को साबित करने का साधन हैं कि तकनीक व्यावहारिक है, और इसे पूर्ण digital ID की ओर जाने के सबसे सरल शुरुआती बिंदु के रूप में चुना गया है
EU में पहले से ही विभिन्न देशों की सरकारें smart card या government account आधारित OIDC-जैसी authentication services दे रही हैं, और digital wallet उसी का विस्तार है ताकि दूसरे EU देशों के नागरिकों की authentication आसान हो सके और पहचान पत्र को फोन में रखा जा सके
बच्चों को age verification token दे देने वाला परिदृश्य वास्तविक दुनिया में भी पहले से संभव है, और इस जोखिम को आम तौर पर स्वीकार करके, पकड़े जाने पर सज़ा देने के तरीके से संभाला गया है; बार मालिक पीछे-पीछे जाकर यह नहीं देखते कि वास्तव में कौन पी रहा है
वास्तविक भौतिक पहचान पत्र अक्सर सिर्फ़ बैंकिंग, दस्तावेज़ पर हस्ताक्षर, या सरकारी काम जैसे कम-बार होने वाले हालात में ही दिखाने पड़ते हैं, और शराब खरीदते समय भी यह शायद ही कभी माँगा जाता था
माँगा भी जाए तो सिर्फ़ दिखाना होता है, उसकी फोटो लेकर सहेजने की अनुमति नहीं दी जाती
लेकिन अगर हर किराना दुकान, फार्मेसी, पेट्रोल पंप, पार्किंग, रेस्तराँ और बार पहचान पत्र माँगे, उसकी फोटो लें और DB में सहेजें, तो इसे कोई भी खुशी से स्वीकार नहीं करेगा
मेरी भी लेखक की तरह Slovak ID है, और मैं जानना चाहता हूँ कि यह इंटरनेट सेवाओं तक पहुँच के लिए वास्तव में कब उपयोगी होगी
यहाँ जिस खामी की बात हो रही है, वह bypass को औद्योगिक स्तर पर संभव बनाती है, इसलिए यह वास्तविक दुनिया में कुछ बार किसी और से खरीदवा लेने जैसी बात से बहुत अलग है
BBS+ या CL signatures जैसी वास्तविक cryptographic unlinkability दोबारा उपयोग करने पर भी आपस में असंबद्ध proofs बनाती है, लेकिन यह सिस्टम वैसा नहीं है
जैसा Swiss eID बहस में भी सामने आया था, ZKP की जगह rotating signatures इस्तेमाल करने का कारण यह है कि अधिकतर फोन के secure hardware में BBS+ जैसे algorithms का support नहीं है
राज्य के लिए अपनी नई cryptographic storage व्यवस्था बनाने के बजाय, hardware module द्वारा पहले से बनाए गए signatures के सेट को घुमाकर इस्तेमाल करना कुल मिलाकर ज़्यादा व्यावहारिक और कम समस्याग्रस्त माना गया है
hardware module का फायदा यह है कि फोन खो जाने पर हमलावर के लिए असली private key निकालना बहुत कठिन हो जाता है
हर बार जब digital ID की बात आती है, डर बढ़ाने वाले लोग copy-paste की गई चिंताओं को दोहराते रहते हैं, लेकिन अगर आप असली EUDI spec पढ़ें, तो उनमें से काफ़ी बातें पहले से संबोधित हैं
https://eudi.dev/1.6.0/architecture-and-reference-framework-main/
Wikipedia पर अलग-अलग देशों के eID पन्ने देखने से बेहतर कोई शुरुआती बिंदु चाहिए
भेड़िया आया वाली घबराहट बार-बार दोहराया जाना सच में थकाऊ है
एक दूसरा नज़रिया भी हो सकता है
EU Age Control खुद ट्रोजन हॉर्स नहीं है, और ऐप वही काम करता है जिसका दावा करता है
कोई भी इसे इस्तेमाल करना नहीं चाहता
असली ट्रोजन हॉर्स है कॉरपोरेट mobile OS
यह मुफ्त तोहफ़े जैसा दिखता है, इसलिए लोग इसे खुशी से अपना लेते हैं, लेकिन वास्तव में इसका मूल business model Google, Apple और उनके advertising partners के पक्ष में privacy erosion करने वाला software है
लोगों को उसकी यह कार्यप्रणाली नहीं दिखती, उन्हें सिर्फ़ सुंदर मुफ्त तोहफ़ा दिखता है
इसलिए age verification ऐप भी सिर्फ़ कॉरपोरेट mobile OS पर चलता है
जैसा लेखक ने कहा, Google या Apple द्वारा स्वीकृत डिवाइस न हो तो Linux, GrapheneOS, Huawei, custom firmware सब बाहर हो जाते हैं, और कहा जाता है कि यह security model का हिस्सा है
ID की माँग का असली बहाना उम्र सत्यापन नहीं बल्कि security है, और इसी तर्क के कारण डिवाइस मालिक अपनी खुद की compile की हुई OS नहीं चला सकता
मेरी नज़र में digital ID भी digital currency की तरह अंततः लगभग अपरिहार्य हो सकती है
क्योंकि यह अधिक सुविधाजनक और अधिक कुशल है, इसलिए इसका जारी होना जारी रहेगा, और काग़ज़ आधारित पहचान प्रमाण समय के साथ कम होते जाएँगे
जुड़े हुए संसार में bank card या driving licence जैसे physical tokens न तो अनिवार्य हैं और न ही हमेशा सबसे अच्छा समाधान
इसलिए ध्यान इस बात को नियंत्रित करने पर होना चाहिए कि सरकार इसके साथ क्या नहीं कर सके
जैसे नागरिकता आसानी से नहीं छीनी जानी चाहिए, वैसे ही ID को deactivate या delete करना भी आसान नहीं होना चाहिए
Netherlands सरकार का tax filing आदि के लिए इस्तेमाल होने वाला digital ID भी है, और Ukraine सरकार द्वारा जारी X509 certificates और ऐप के ज़रिये भी कुछ ऐसा ही किया जा सकता है
इन्हें भी बुरा मानना मुझे ठीक से समझ नहीं आता
UK में यह राजनीतिक फैसले से भी हो सकता है, और bank account freeze जैसी दूसरी पाबंदियाँ भी लगाई जा सकती हैं, इसलिए मुझे संदेह है कि इसे प्रभावी ढंग से रोका जा सकेगा
physical token की समस्या भी मुझे खास समझ नहीं आती
वे सरल होते हैं, single point of failure नहीं बनाते, फोन खो जाए तब भी कार्ड और नकद बचे रहते हैं, और network या system failure में भी टिके रहते हैं
कुछ कार्ड साथ रखना क्या इतना बड़ा नुकसान है?
इसके अलावा काग़ज़ पर भी digitally encoded और cryptographically signed ID रखी जा सकती है, जो सुरक्षा और machine-readability के लिहाज़ से electronic रूप जैसा काफ़ी काम कर सकती है
electronic token की असली उपयोगिता खास तौर पर वहाँ चमकती है जहाँ किसी ID या किसी और चीज़ की एकमात्र भौतिक प्रति के कब्ज़े को साबित करना हो
EU पहले से कई वर्षों से इस दिशा में आगे बढ़ रहा है, यह कहकर कि सरकार क्या कर सकती है उसे नियंत्रित किया जाएगा
https://escapekey.substack.com/p/europe-goes-full-digital
social media के बढ़ने के बाद चुनाव कैसे बदले हैं, यह देखकर लगता है कि सरकारें पहले जैसा नियंत्रण वापस पाना चाहती हैं
child sexual abuse material, आतंकवाद, और अब AI-generated CP जैसे डर दिखाकर खुले इंटरनेट को लगातार कसते-कसते, अंत में शायद हमें पश्चिमी शैली की Great Firewall और social credit जैसी दूसरी श्रेणी की व्यवस्था मिल जाएगी
कुछ उदार लोकतांत्रिक देशों में इसकी जड़ें शायद पहले ही बोई जा चुकी हैं
कुछ बड़े influencer accounts चीन या रूस से जुड़े bots निकले हैं, और नफ़रत व विभाजन फैलाने की कोशिशें LLM की वजह से और बढ़ रही हैं
social accounts के पीछे असली इकाई को verify कर सकने वाला किसी तरह का digital ID शायद सार्वजनिक विमर्श को बचाने की आख़िरी उम्मीद हो सकता है
मेरी सरकार कुछ समय से कहती रही है कि social media हमें ज़्यादा मूर्ख, ज़्यादा उदास और ज़्यादा चिंतित बनाता है, और मुझे लगता है यह सच है
इसका असर चुनावों पर भी पड़ता है, यह मैं मानता हूँ, लेकिन ऐसा नहीं लगता कि चुनाव ही वह मुख्य बिंदु है जिसे वे ठीक करना चाहते हैं
अगर आप समस्या हल करेंगे, तो चुनावों पर असर पड़ना स्वाभाविक ही है
वास्तविक बच्चों पर आधारित सामग्री के मामले में भी, अगर कोई अरबपति खुलेआम generator access बेचे तो भी मानो कुछ नहीं होता
इसलिए यह मुझे अंततः डर पैदा करने वाली कठपुतली दलील जैसा ही ज़्यादा लगता है
चाहे demo app हो या नहीं, सही implementation ज़्यादा महत्वपूर्ण है
क्योंकि हर member state के सब कुछ सही तरीके से लागू करने की संभावना कम है
बच्चों की सुरक्षा का यह समाधान भी अंततः सीमित ही है
बच्चों को फोन या कंप्यूटर ही न देना एक सरल समाधान हो सकता है, और वैसे भी अवैध साइटें age verification का पालन नहीं करेंगी
अगर Pirate Bay जैसी साइटें कानून का ठीक से पालन करतीं, तो वे शुरू से मौजूद ही नहीं होतीं, इसलिए यह अंततः काफ़ी हद तक अप्रभावी समाधान जैसा है
खासकर देशों के बीच किस approval/control protocol का पालन होगा, यही महत्वपूर्ण है
single DB या बिना नियंत्रण वाले network की कल्पना काफ़ी डरावनी लगती है
आजकल कई स्कूलों में कंप्यूटर तक पहुँच होना ही आवश्यक है
हम बहुत पहले से eID इस्तेमाल करते आए हैं, और इसका ऑनलाइन अधिक व्यापक उपयोग होना ठीक है
उम्र सत्यापन के साथ भी यही बात है, लेकिन यह प्रक्रिया ऐसी होनी चाहिए जिसमें अमेरिकी कंपनियाँ या Palantir शामिल न हों
age verification जैसी चीज़ों में असली Zero Knowledge Proof व्यवस्था की अनुमति मिलने की संभावना कम लगती है
और remote attestation भी उस तरह काम नहीं करता
असली ZKP सिस्टम में अगर एक भी key leak या extract हो जाए, तो असीमित नकली proofs बनाए जा सकते हैं, और उनका पता लगाना कठिन हो जाता है
https://eudi.dev/2.5.0/discussion-topics/g-zero-knowledge-proof/
क्योंकि यह Oreo जैसे पुराने डिवाइसों तक को attest कर देता है, जबकि जिन डिवाइसों को vendor ने update देना बंद कर दिया है उनमें व्यावहारिक रूप से अनंत कमजोरियाँ बची रह सकती हैं, जिससे key extraction संभव हो जाती है
कई देश वर्षों से digital ID चला रहे हैं
समस्या digital ID खुद नहीं बल्कि निगरानी है
जब digital ID सिर्फ़ सरकार द्वारा जारी इकाई के साथ सीधे संवाद में उपयोग हो, तो वह ठीक है, बल्कि वांछनीय भी हो सकती है
लेकिन उम्र सत्यापन को आगे बढ़ाना उस जानकारी को private companies तक खोलने का माध्यम है, और मेरे हिसाब से वही असली ट्रोजन हॉर्स है
{"over_18": true}या{"over_16": true, "over_18": false}जैसी signed government assertion भर हैहाँ, Vatican ID जैसे कुछ असामान्य मामलों में दिक्कत हो सकती है, लेकिन वैसे भी वे इस सिस्टम में भाग नहीं लेते
इंटरनेट कभी cyberpunk शैली का पलायन मार्ग हुआ करता था, लेकिन अब लगता है कि किसी भी कीमत पर anonymity खत्म करने की दिशा में बढ़ा जा रहा है
face recognition से फोन unlock करना, और इंटरनेट इतिहास का government ID से 1:1 जुड़ जाना — यह सब बस उदास कर देता है