- Google का Web Environment Integrity(WEI) प्रस्ताव Chrome को ऑपरेटिंग सिस्टम और सॉफ़्टवेयर की स्थिति के बारे में छेड़छाड़-प्रतिरोधी जानकारी वेबसाइटों को भेजने देगा, जिससे उपयोगकर्ता का अपने कंप्यूटर की ओर से क्या कहा जाए इस पर नियंत्रण कमजोर हो सकता है
- WEI, TPM या secure enclave के ज़रिये remote attestation का इस्तेमाल करता है, ताकि वेबसाइटें ब्राउज़र और डिवाइस कॉन्फ़िगरेशन को उपयोगकर्ता के कथन के बजाय क्रिप्टोग्राफ़िक प्रमाण से सत्यापित करें
- तर्क यह दिया जाता है कि इससे ad fraud, man-in-the-middle attacks, game cheating, bot accounts और fake reviews कम होंगे, लेकिन इसका वास्तविक लाभ मुख्यतः व्यावसायिक सेवा संचालकों को मिलने की संभावना है
- वेबसाइटें WEI का उपयोग करके उन ब्राउज़रों या ऑपरेटिंग सिस्टम को ब्लॉक कर सकती हैं जो उन्हें पसंद नहीं हैं, और Google का प्रस्तावित यह उपाय कि “Chrome के कुछ कम उपयोगकर्ताओं को WEI न भेजा जाए” भी इस बहिष्कार को रोकने के लिए पर्याप्त नहीं हो सकता
- remote attestation tools पर प्रतिबंध लगाने की ज़रूरत नहीं है, लेकिन इन्हें open web में नहीं जोड़ा जाना चाहिए, और उपयोगकर्ताओं को यह तय करने का अधिकार होना चाहिए कि वे अपने कंप्यूटर और सॉफ़्टवेयर के बारे में क्या कहें
Google WEI ब्राउज़र और वेबसाइट के रिश्ते को कैसे बदलना चाहता है
- Google, Chrome में ऐसा कोड जोड़ना चाहता है जो उपयोगकर्ता के ऑपरेटिंग सिस्टम और सॉफ़्टवेयर की स्थिति के बारे में छेड़छाड़-प्रतिरोधी जानकारी वेबसाइटों को भेजे
- ad fraud कम करने के दावे के बावजूद, यह फ़ीचर उपयोगकर्ता की अपने कंप्यूटर पर नियंत्रण रखने की क्षमता घटा सकता है
- जो उपयोगकर्ता स्वीकृत ऑपरेटिंग सिस्टम और ब्राउज़र का उपयोग नहीं करते, उन्हें कुछ वेबसाइटों पर ब्लॉक किया जा सकता है
- Google कर्मचारियों द्वारा लिखे गए अनौपचारिक विवरण दस्तावेज़ Web Environment Integrity(WEI) में माना गया है कि इससे नए ब्राउज़रों के लिए प्रवेश बाधा बढ़ सकती है
ब्राउज़र वेबसाइटों को कौन-सी जानकारी भेजता है
- वेब ब्राउज़र सर्वर से कनेक्ट होते समय डिवाइस और ब्राउज़र की जानकारी अपने-आप भेजता है
- उदाहरण: “Google Pixel 4 पर Chrome 116.0.5845.61 इस्तेमाल हो रहा है” जैसी जानकारी
- सर्वर इंस्टॉल किए गए fonts, screen size जैसी और भी विस्तृत जानकारी मांग सकता है
- इस जानकारी का उपयोग वेबसाइटें उपयोगकर्ता के डिवाइस के अनुरूप file format, resolution और layout देने के लिए करती हैं
- यही जानकारी browser fingerprinting में भी उपयोग होती है
- cookies या अन्य tracking को अस्वीकार करने वाले उपयोगकर्ताओं की पहचान ब्राउज़र विशेषताओं के संयोजन से की जा सकती है
- कुछ साइटें ब्राउज़र और डिवाइस जानकारी के आधार पर अलग-अलग कीमतें तय कर सकती हैं या खराब/भ्रामक ऑफ़र दिखा सकती हैं
उपयोगकर्ता को झूठी या यादृच्छिक जानकारी भेज सकने की ज़रूरत क्यों है
- अभी ब्राउज़र जो जानकारी वेबसाइटों को भेजता है, वह मूलतः स्वैच्छिक होती है
- उपयोगकर्ता plugins, privacy tools और advanced settings के ज़रिये अविश्वसनीय साइटों को अपनी पसंद की जानकारी भेज सकते हैं
- सिर्फ़ जानकारी न भेजना पर्याप्त नहीं हो सकता
- क्योंकि कोई सेवा डिवाइस जानकारी मांग सकती है और उसे न देने वाले उपयोगकर्ताओं को अस्वीकार कर सकती है
- privacy और anti-tracking tools इसके बजाय विश्वसनीय लगने वाली लेकिन गलत डिवाइस जानकारी भेज सकते हैं
- यह ऐसा तरीका है जिससे सेवाएँ उपयोगकर्ता के privacy विकल्पों के आधार पर भेदभाव नहीं कर पातीं
remote attestation और secure computing कैसे काम करते हैं
- अधिकांश आधुनिक कंप्यूटर, टैबलेट और मोबाइल फ़ोन में किसी न किसी रूप में secure computing सुविधा होती है
- शुरुआती secure computing में Trusted Platform Module(TPM) नाम का अलग प्रोसेसर इस्तेमाल होता था, और कई डिवाइस secure enclave नाम की मज़बूत subsystem का उपयोग करते हैं
- ये सिस्टम boot प्रक्रिया के हर चरण की निगरानी करके यह जाँच सकते हैं कि निर्माता द्वारा दिया गया अपरिवर्तित कोड ही चल रहा है या नहीं
- यही प्रक्रिया उपयोगकर्ता को जानबूझकर अलग कोड चलाने से रोकने में भी इस्तेमाल हो सकती है
- उदाहरण: free/open source operating systems
- उदाहरण: ऐसा सॉफ़्टवेयर जिसे surveillance features बंद करने या निर्माता के app store के बाहर का software इंस्टॉल करने की अनुमति देने के लिए बदला गया हो
- TPM और secure enclave में क्रिप्टोग्राफ़िक signing keys शामिल होती हैं
- वे OS version, extensions, software और bootloader जैसे low-level code की जानकारी इकट्ठा कर सकते हैं
- और इस जानकारी को क्रिप्टोग्राफ़िक रूप से signed attestation के रूप में दे सकते हैं
- remote server उपयोगकर्ता के ब्राउज़र के कथन पर भरोसा करने के बजाय डिवाइस का क्रिप्टोग्राफ़िक प्रमाण मांग सकता है
bypass और शोध से जुड़े क़ानूनी जोखिम
- यदि उपयोगकर्ता secure enclave या TPM की सुरक्षा को bypass नहीं कर सकते, तो attestation डिवाइस कॉन्फ़िगरेशन का बहुत विश्वसनीय संकेतक बन जाता है
- TPM या secure enclave में बदलाव करना क़ानूनी रूप से जोखिम भरा हो सकता है
- DMCA Section 1201, patents और copyright जैसी व्यवस्थाएँ इन तकनीकों का अध्ययन करने वाले इंजीनियरों के लिए civil और criminal जोखिम पैदा कर सकती हैं
- security features को disable या bypass करने के तरीक़े प्रकाशित करने से जोखिम और बढ़ जाता है
- bypass tools वितरित करने पर कई वर्षों की सज़ा सहित गंभीर आपराधिक और दीवानी जोखिम उठाने पड़ सकते हैं
WEI वेब के लिए किस तरह का remote attestation प्रस्तावित करता है
- WEI एक तकनीकी प्रस्ताव है जो सर्वर को डिवाइस से remote attestation मांगने की अनुमति देगा
- अनुरोध डिवाइस के secure enclave या TPM तक जाएगा, और डिवाइस क्रिप्टोग्राफ़िक रूप से signed, उच्च-विश्वसनीयता वाला डिवाइस विवरण लौटाएगा
- उपयोगकर्ता इस जानकारी को remote server को न भेजने का विकल्प चुन सकता है
- लेकिन जब उपयोगकर्ता को ज़रूरी लगे, तब डिवाइस और सॉफ़्टवेयर के बारे में बदली हुई या यादृच्छिक जानकारी भेजने की क्षमता वह खो देगा
Google द्वारा बताए गए उपयोग-केस और उनकी सीमाएँ
- Google के इंजीनियरों का मानना है कि WEI कई समस्याएँ कम कर सकता है
- यह अलग करने में कि कोई वास्तविक उपयोगकर्ता ब्राउज़र को manually चला रहा है या bot किसी सेवा को automatically चला रहा है
- ad fraud घटाकर publishers की आय बढ़ाने और उससे बेहतर content production होने की उम्मीद
- man-in-the-middle attacks को रोकना, जहाँ हमलावर two-factor authentication के one-time passwords तक intercept करके उन्हें वास्तविक सेवा login में इस्तेमाल करते हैं
- गेम में यह जाँचना कि प्रतिद्वंद्वी unmodified game चला रहा है और cheating नहीं कर रहा
- browser automation tools का पता लगाकर/block करके fake reviews या bot accounts की mass creation जैसी धोखाधड़ी रोकना
- इन उपयोग-केस में कुछ वैधता हो सकती है
- लेकिन security के मामलों में privacy का हनन और व्यक्तिगत autonomy की क्षति अक्सर वास्तविक समस्या के सिर्फ़ एक हिस्से को कम करती है
- अगर दुकान में आने वाले हर ग्राहक को हथकड़ी लगा दी जाए तो चोरी कम हो सकती है, लेकिन चोरी दुकान की समस्या है; इसकी क़ीमत हर ग्राहक को नहीं चुकानी चाहिए
WEI का उपयोग ब्राउज़र और ऑपरेटिंग सिस्टम को ब्लॉक करने के लिए हो सकता है
- Google दस्तावेज़ के एक section में माना गया है कि वेबसाइटें WEI का उपयोग उन ब्राउज़रों और ऑपरेटिंग सिस्टम को ब्लॉक करने के लिए कर सकती हैं जिन्हें वे पसंद नहीं करतीं
- Google एक उपाय के रूप में यह विचार कर रहा है कि Chrome में WEI लागू होने के बाद भी, जिन कंप्यूटरों से सामान्यतः WEI जानकारी भेजी जा सकती है, उनमें से “एक छोटे प्रतिशत” पर जानकारी न भेजी जाए
- सिद्धांततः, जो साइटें WEI के बिना ब्राउज़रों को ब्लॉक करेंगी, वे Chrome के इस छोटे समूह को भी ब्लॉक कर देंगी, और उपयोगकर्ताओं की शिकायतें उन्हें नीति बदलने पर मजबूर कर सकती हैं
- लेकिन कई वेबसाइटें यह तय करना चाह सकती हैं कि कौन-सा ब्राउज़र और ऑपरेटिंग सिस्टम इस्तेमाल किया जाए
- पहले भी “यह वेबसाइट Windows XP पर Internet Explorer 6.0 में सबसे अच्छा काम करती है” जैसी स्थितियाँ रही हैं
- कुछ वेबसाइटें उस “छोटे प्रतिशत” उपयोगकर्ता हानि की लागत स्वीकार कर सकती हैं
- वे उपयोगकर्ताओं को ब्राउज़र data reset करने और उस साइट पर WEI सक्रिय होने तक दोबारा प्रयास करने के लिए भी कह सकती हैं
Google का हितों का टकराव
- Google के पास “छोटे प्रतिशत” को कितना रखा जाए, इस सवाल पर हितों का टकराव है
- यदि यह प्रतिशत बहुत छोटा रखा जाए, तो अधिक ad clicks प्रमाणित किए जा सकेंगे, जो Google की ad fraud response टीम के लिए फ़ायदेमंद होगा
- authenticated ad clicks बढ़ने पर Google विज्ञापन अधिक ऊँची क़ीमत पर बेच सकता है
- यदि प्रतिशत बढ़ाया जाए, तो वेबसाइटों के लिए exclusionary behavior लागू करना कठिन होगा
- लेकिन ऊँचा प्रतिशत Google को सीधे लाभ नहीं देता और प्रतिस्पर्धी ब्राउज़र बनाना आसान करता है
- यह mitigation लागू होने पर भी Google का प्रोत्साहन खुले वेब की रक्षा के लिए बहुत छोटा प्रतिशत चुनने की ओर रहेगा
यह सिद्धांत कि उपयोगकर्ता अपने कंप्यूटर का मालिक है
- कंप्यूटर उपयोगकर्ता का होता है, और उसे उपयोगकर्ता के निर्देशानुसार काम करना चाहिए
- reverse engineering और कंप्यूटर reconfiguration को रोकने वाले क़ानून अपने-आप में भी समस्या हैं, लेकिन जब कुछ बड़ी वेबसाइटें इंटरनेट के chokepoints पर क़ब्ज़ा रखती हैं, तब जोखिम और बढ़ जाता है
- कुछ ही कंपनियाँ खरीदार और विक्रेता, कलाकार और दर्शक, श्रमिक और नियोक्ता, परिवार और समुदाय के बीच द्वारपाल बन जाती हैं
- यदि ऐसी कंपनियाँ लेन-देन से इनकार कर दें, तो उपयोगकर्ता का डिजिटल जीवन ठहर सकता है
- वेब इंटरनेट पर बचा हुआ अंतिम प्रमुख open platform है
- यह ऐसा प्लेटफ़ॉर्म है जहाँ कोई भी बिना अनुमति लिए या किसी और की specifications पूरी किए बिना ब्राउज़र या वेबसाइट बना सकता है और भाग ले सकता है
- भले ही वेबसाइटें “सिर्फ़ स्वीकृत तकनीक ही प्रवेश पाए” जैसी वर्चुअल चौकियाँ बना लें, उपयोगकर्ताओं के पास वह जवाब देने का अधिकार होना चाहिए जो वे चाहते हैं कि साइट सुने
WEI की मंशा और उसके अनुमानित दुरुपयोग
- WEI प्रस्तावक कहते हैं कि वे चाहते हैं कि WEI का उपयोग केवल सद्भावनापूर्ण उद्देश्यों के लिए हो
- वे ब्राउज़र ब्लॉकिंग या privacy बचाने वाले उपयोगकर्ताओं को बाहर करने के लिए WEI के उपयोग की स्पष्ट आलोचना भी करते हैं
- लेकिन computer scientists यह तय नहीं कर सकते कि किसी तकनीक का व्यवहार में उपयोग कैसे होगा
- वेब में attestation जोड़ देने से कंपनियों द्वारा उपयोगकर्ताओं के डिवाइस कॉन्फ़िगरेशन के अधिकार पर हमला करने का जोखिम पूरी तरह अनुमानित है
- यह जोखिम तब और बढ़ जाता है जब उपयोगकर्ता की ज़रूरतें tech कंपनियों की commercial priorities से टकराती हैं
- WEI को बनाया नहीं जाना चाहिए, और अगर बनाया भी जाए तो इसका इस्तेमाल नहीं होना चाहिए
remote attestation तकनीक के साथ कैसा व्यवहार होना चाहिए
- remote attestation पर अपने-आप में प्रतिबंध नहीं लगाया जाना चाहिए
- code is speech, और हर व्यक्ति को remote attestation tools का अध्ययन, समझ और निर्माण करने की स्वतंत्रता होनी चाहिए
- remote attestation tools का distributed systems में उपयोग हो सकता है
- मतदान मशीनों का निर्माता स्थल पर मौजूद डिवाइस कॉन्फ़िगरेशन की जाँच के लिए इसका उपयोग कर सकता है
- जोखिम में पड़ा कोई human rights activist किसी भरोसेमंद तकनीशियन को remote attestation भेजकर यह समझने में मदद ले सकता है कि डिवाइस state-sponsored malware से संक्रमित है या नहीं
- लेकिन ऐसे tools को वेब में नहीं जोड़ा जाना चाहिए
- open platform पर remote attestation उपयुक्त नहीं है
- उपयोगकर्ता के पास यह अंतिम निर्णय होना चाहिए कि वह अपने कंप्यूटर और सॉफ़्टवेयर के बारे में दूसरों से क्या कहे
कॉर्पोरेट समस्याओं से ऊपर है उपयोगकर्ता की स्वायत्तता
- उन कंपनियों की कठिनाइयाँ समझी जा सकती हैं जिनकी आय पर ad fraud असर डालता है, जो cheating से लड़ रही game companies हैं, या जो bot समस्याओं से जूझ रही services हैं
- लेकिन इन समस्याओं का समाधान tech users के अधिकारों से ऊपर नहीं रखा जा सकता
- उपयोगकर्ता को यह चुनने का अधिकार है कि उसका कंप्यूटर कैसे काम करे, और वह कंप्यूटर दूसरों से क्या कहे
- अपने डिवाइस पर नियंत्रण का अधिकार डिजिटल दुनिया के सभी नागरिक अधिकारों का मूल आधार है
- open web नुकसान से अधिक लाभ देता है
- यदि विशाल और एकाधिकारवादी कंपनियों को उपयोगकर्ता की तकनीकी पसंद पलटने दी जाए, तो शायद कॉर्पोरेट समस्या हल हो जाए, लेकिन उपयोगकर्ता की समस्या नहीं
1 टिप्पणियां
Hacker News की राय
सुरक्षा इंजीनियर के तौर पर काम करते हुए मिले व्यावहारिक अनुभव को देखें तो यह समझने में मदद मिल सकती है कि यह आखिर खराब दिशा में क्यों जाएगा
बैंक सुरक्षा को लेकर बेहद संवेदनशील संगठन होते हैं, क्योंकि हैकिंग की लागत खगोलीय हो सकती है और नियमन उनसे “जितना संभव हो उतना सुरक्षित” बनाने की मांग करता है
बैंक खुले वेब या Linux यूज़र्स से नफरत करते हैं इसलिए WEI अपनाने की कोशिश नहीं करेंगे, बल्कि इसलिए अपनाएंगे कि अगर नहीं अपनाया तो “सुरक्षा के लिए जो किया जा सकता था वह सब नहीं किया” जैसी जिम्मेदारी का मुद्दा उठेगा, जो मुकदमों, नियामकीय दंड और बीमा प्रीमियम बढ़ने तक ले जा सकता है
अभी WEI नहीं है, इसलिए यह requirement नहीं है, लेकिन एक बार आ गया तो इसके standard practice बनने की संभावना ज्यादा है, और इसका विरोध करने वाले लोग CCTV को privacy का उल्लंघन बताकर विरोध करने वालों की तरह अव्यावहारिक दिख सकते हैं
जल्द ही Cloudflare जैसे CDN इसे एक checkbox के रूप में देंगे, और site owner के लिए fiduciary responsibility के चलते उसे बंद रखना मुश्किल हो जाएगा
2 साल पहले तक IE7 इस्तेमाल होता था, काम का बड़ा हिस्सा अब भी Excel files को email से इधर-उधर भेजने के तरीके से चलता है, और मिले हुए email में Excel attached होना ही validity के सबूत जैसा माना जाता है
authentication के बिना SMTP relay भी चल रहा था, और असली सुरक्षा को नजरअंदाज करते हुए work laptops पर Windows अनिवार्य किया जाता है
वजह यह थी कि सिस्टम के सभी jar को recursively खोलकर log4shell खोजने वाली उनकी पसंदीदा RAT PowerShell script चलानी थी, और वे अब भी ऐसा कर रहे हैं
इन्हीं नियमों और practices को बनाने वाले लोग Denmark के केंद्रीय बैंक के payment clearing core system भी चलाते हैं
बैंक सुरक्षित होने से ज्यादा conservative और political होते हैं, security theater बनाए रखने के लिए लोगों को परेशान करते हैं, लेकिन असल में यह बाहरी खोल जैसा है
WEI वे निश्चित रूप से अपनाएंगे, लेकिन यह सुरक्षा नहीं लाएगा
हालांकि बैंक लोगों के पैसे की रक्षा करने में काफी अच्छा track record रखते हैं, और यह suspicious transactions को compliance officers द्वारा manually review करने वाली defense in depth की वजह से है
कई बड़े संस्थान अब भी सिर्फ SMS two-factor authentication support करते हैं, और वह भी अनिवार्य हुए ज्यादा समय नहीं हुआ
इसलिए यह तकनीक फैल भी जाए तो bank accounts पर इसे सबसे पहले नहीं, बल्कि लगभग सबसे अंत में enforce किए जाने की संभावना ज्यादा लगती है
credit cards का भयानक रूप से असुरक्षित होना भी इसी संदर्भ में है
ऐसा इसलिए नहीं कि उन्हें परवाह नहीं, बल्कि इसलिए कि वे technical measures को अपनी पूरी security strategy का छोटा हिस्सा मानते हैं, और online access को भी business का छोटा हिस्सा तथा मूल रूप से भरोसे लायक नहीं मानते
web का ज्यादातर हिस्सा authenticated users पर भरोसा करता है, लेकिन बैंक authenticated users पर भी आम तौर पर भरोसा नहीं करते और हर action को संभावित जोखिम मानते हैं, इसलिए authentication को ही मजबूत करने की priority तुलनात्मक रूप से कम रहती है
web interface हो तब भी login करने के लिए mobile app चाहिए
हालांकि विरोधियों के “अव्यावहारिक दिखने और उस जगह पर ज्यादा देर टिक न पाने” वाली बात पर मुझे यकीन नहीं है
universal surveillance का विरोध करने वाले लोग बहुसंख्यकों को अव्यावहारिक नहीं लगते, और वे अपना रुख भी नहीं बदलते
यह छोटा-सा paragraph कि कुछ कंपनियों ने खरीदारों और sellers, performers और audience, workers और employers, families और communities के बीच के bottleneck points पर कब्जा कर लिया है, और अगर वे लेनदेन से इनकार कर दें तो digital life रुक जाती है, उस अजीब स्थिति को अच्छी तरह समेटता है जिसमें हम बहते हुए आ गए हैं
जिन stakeholders पर नकारात्मक असर पड़ता है, वे असल में लगभग पूरा समाज हैं, और ऐसे gatekeepers के प्राकृतिक सहयोगी होते हैं—captured politicians या payroll पर मौजूद लोग, और externalities को नजरअंदाज करने वाले बाजार
फिर भी यह अजीब है कि लगभग असीमित financial, political और intellectual resources रखने वाले पूरे समाज को वे झुका सकते हैं
यह ऐसा लगने लगता है मानो system-scale mind control पहले से काम कर रहा हो
मेरे हिसाब से पूरा समाज धमकाया नहीं जा रहा, बल्कि ज्यादातर लोग बस परवाह नहीं करते
यह इतनी पागलपन भरी बात नहीं है, और यह mind control नहीं बल्कि पुरानी उदासीनता और अज्ञानता है
कुल मिलाकर सहमत हूं, लेकिन एक बात बता दूं: TPM का मतलब Technical Protection Module नहीं, बल्कि Trusted Platform Module है
FSF जितना ज्यादा नहीं, लेकिन वे commentary मिला देते हैं, और इस मामले में ऐसा लगता है जैसे किसी ने व्यंग्य करना चाहा हो
हालांकि TPM को लेकर गलती लगती है, या फिर दूसरे acronyms की तरह वैकल्पिक expansion पेश करने की कोशिश लगती है
शैतान के वकील की तरह देखें तो यह तकनीक पहले से मौजूद है, और सवाल यह है कि ब्राउज़र में client attestation किया जाए या यह दिखावा किया जाए कि remote attestation है ही नहीं
अगर इसे अस्वीकार किया गया, तो जिन सेवाओं को “trusted client” चाहिए, वे webapp छोड़कर iOS/Android apps पर निर्भर हो सकती हैं
मैं WEI का बचाव नहीं करना चाहता, लेकिन Google के Chrome में इसे implement न करने से यह समस्या जादू की तरह गायब नहीं होगी; बस कहीं और चली जाएगी
असली लड़ाई तो शुरुआत में TPM implement करते समय थी
यह कुछ-कुछ वैसा है जैसे Secure Boot keys पर सिर्फ Microsoft का अधिकार हो
mobile devices में पहले से ही secure enclave, security processors, और SIM card की cryptographic capabilities जैसी बहुत-सी attestation capabilities हैं
हमें ऐसी तकनीक की जरूरत नहीं है जिसका मनमाने नियमों के आधार पर tech-savvy लोगों को रोजमर्रा के internet से बाहर करने के लिए दुरुपयोग होना तय है
इसमें checks and balances नहीं हैं, और यह users पर थोपा जाने वाला अधिकारों का बहुत व्यापक bundle है
यह कोई प्रस्ताव या experiment नहीं, बल्कि forced push की कोशिश है
यह अच्छी तरह समझाता है कि web mobile/native apps से अलग क्यों है, और client attestation जैसी API mobile environment में संभव हो सकती है, लेकिन web platform में implement होने पर हानिकारक क्यों होती है
उदाहरण के लिए, WEI proposal “webpage पर जाना safe होना चाहिए” वाले सिद्धांत (https://www.w3.org/TR/design-principles/#safe-to-browse) का उल्लंघन करता है
नए features इस तरह design होने चाहिए कि webpage पर जाना आम तौर पर safe है—users की यह expectation बनी रहे
web को जीवंत बनाए रखने के लिए users यह उम्मीद कर सकें कि किसी link पर सिर्फ जाने भर से उनके computer security या privacy के मूल पहलुओं पर असर नहीं पड़ेगा
उदाहरण के लिए, कोई भी website assistive technology के इस्तेमाल का पता लगा सके ऐसी API, उस technology के users को अनजान pages पर जाना जोखिम भरा महसूस करा सकती है
अगर यह safety expectation वास्तविक हो, तो users web-based technologies और दूसरी technologies के बीच informed decision ले सकते हैं
native app install करना webpage पर जाने से ज्यादा जोखिम भरा है, इसलिए user app install करने के बजाय web-based food ordering page चुन सकता है
बहुत ज्यादा tech-savvy न होने के बावजूद सावधान users में से कई लोग सबसे भरोसेमंद source को छोड़कर किसी और का mobile app install करने से बिल्कुल इनकार करते हैं, और यह सिद्धांत यह समझने का अच्छा ढांचा देता है कि users अब भी web को क्यों पसंद करते हैं
पुराने Venmo में पूरा webapp था, लेकिन अब web पर पैसे भेजे या प्राप्त नहीं किए जा सकते
Chase के भी कई features सिर्फ phone के लिए हैं
और ऐसे बहुत-से apps, अगर detect कर पाएं, तो jailbroken iPhone या rooted Android को block कर देते हैं
अगर bank इसकी मांग करे, तो बस मेरी access block हो जाएगी
कोई attestation daemon नहीं है, और अगर हो भी, तो bank उस पर भरोसा नहीं करेगा
Firefox इसे जोड़ भी दे, तब भी यह मेरे computer पर वैसे ही काम नहीं करेगा
लोग सिर्फ browser की बात करते हैं, लेकिन मैं ऐसा operating system इस्तेमाल करते रहना चाहता हूं जिसमें adware और spyware built-in न हों
जिस computer का मालिक मैं हूं वह मेरे control में है, और remote attestation feature का मकसद उसी control को रोकना है
यही मूल समस्या है
अगर bank या brokerage firm इसे implement करें, तो मुझे dedicated नया computer खरीदना होगा, या phone या आमने-सामने ही banking करनी होगी
यह बहुत बड़ी बर्बादी है और security में भी मदद नहीं करता, लेकिन एक बार इसके मौजूद होने पर यह उन checklists में शामिल हो जाएगा जिनका banks पालन करेंगे
यहां लक्ष्य client attestation के उपयोग की जगह बढ़ाना नहीं, घटाना है
हर थोड़ी कमी भी जीत है; पहले इसे browsers से बाहर निकालें, फिर apps के native attestation से निपटें
“इसे अस्वीकार किया तो services native apps पर चली जाएंगी” वाली दलील EME के समय भी ठीक ऐसी ही दी गई थी
अब हम EME के प्रभावों पर पीछे मुड़कर देख सकते हैं: यह native apps की ओर move रोक नहीं पाया, Netflix जैसी कंपनियों ने EME implement करते हुए भी वे अधिकतर restrictions बनाए रखे जो वे वैसे भी लगाने वाली थीं, और इससे browser diversity को नुकसान हुआ
web पर “हम बस यह नहीं करेंगे” कहना डरावना लग सकता है, लेकिन हम पहले ही देख चुके हैं कि डराने-धमकाने के आगे झुकने से असर नहीं होता
जो sites native पर जाना चाहती हैं, वे जाएंगी, और WEI अकेला किसी business को web पर रहने या छोड़ने का justification नहीं बनेगा
जो native-only जाना चाहते हैं वे WEI आने से अचानक website नहीं बनाएंगे; वे वही करेंगे जो वे पहले से करना चाहते थे और user autonomy सीमित करने वाले toolbox में WEI जोड़ देंगे
client attestation पर निर्भर होना चाहने वाली कंपनियों को अपनी web presence छोड़ने के लिए मजबूर होना अच्छी बात है, और web की ताकत को कम आंका जा रहा है
WEI support न करने से web मर नहीं जाएगा
EFF का लेख recommend करना अच्छी बात है, लेकिन ऐसी campaigns में मदद करने के लिए सीधे donate भी किया जा सकता है
वे शानदार merchandise भी बनाते हैं: https://supporters.eff.org/donate/
[1] https://www.eff.org/press/releases/international-coalition-r...
[2] https://blog.cloudflare.com/kiwifarms-blocked/
मुझे समझ नहीं आता कि Google के ad fraud को घटाने और उसके advertising business की मदद करने की मुझे परवाह क्यों करनी चाहिए
यह Google की समस्या है, और Google को ज्यादा पैसा कमाने में मदद करने के लिए मेरे personal computer की जानकारी third parties तक पहुंचाने में मेरे शामिल होने की कोई वजह नहीं है
WEI कुछ-कुछ पुराने telephone network जैसा है, जहां individuals को अपना phone रखने और उसे network से connect करने नहीं दिया जाता था
आखिरकार सरकार ने उसे illegal घोषित कर दिया
इस विषय पर अब तक पढ़े गए लेखों में यह सबसे विस्तृत और संतुलित लेखों में से एक है
हालांकि दूसरे लेखों की तरह इसमें भी Web Environment Integrity के बारे में एक बेहद अहम बात छूट गई है
यह web का हिस्सा नहीं है
यह पूरी तरह Google Chrome feature के लिए Google का draft है, और भले ही Google W3C का member है, यह काम वह member के तौर पर नहीं कर रहा है
यह Google के हितों तक इतना सीमित है कि मुझे नहीं लगता ऐसा प्रस्ताव working group charter तक भी पहुंच पाएगा
web के लिए यह खतरा केवल इसलिए है क्योंकि Google की market dominance पहले से ही monopoly के करीब पहुंच रही है
मुझे चिंता है कि ऐसे document में “Web” शब्द का प्रमुखता से इस्तेमाल W3C की प्रतिष्ठा को खराब कर सकता है, जिसके पास web की openness को लंबे समय में नुकसान पहुंचाने वाले short-term interests से बचने के लिए मजबूत process[1] है
[1]: https://www.w3.org/Consortium/Process/
बहुत अच्छी तरह लिखा गया explanation है। काश इस तरह की explanations ज्यादा बार देखने को मिलें
लगता है लोग इसे ad-blocking check के रूप में समझ रहे थे, जबकि मूल proposal ने साफ कहा था कि browser extensions का WEI से कोई संबंध नहीं है
WEI मौजूदा operating system और TPM-based attestation API को call करता है, और उस attestation status को site को उपलब्ध कराता है
यह अब भी कुछ वैसा ही लगता है जैसे encryption के विरोधी “बच्चों के बारे में सोचिए” कहते हैं
WEI किस तरह magically website operators के व्यवहार को बदल देगा, इसका explanation अब तक नहीं दिखता
operators पहले से ही unwanted clients को block कर सकते हैं, लेकिन वे ऐसा इस हद तक नहीं कर रहे कि “open internet” में वास्तविक बाधा आए
अगर Apple इसे implement नहीं करता, तो WEI का कोई मतलब नहीं होगा, और मौजूदा debate का Apple पर एकमात्र असर शायद यही होगा कि वह इस choice को publicly कैसे frame करता है
अभी तक मेरा computer वही कहलवा सकता है जो मैं उससे कहलवाना चाहता हूं, इसलिए मैंने एक छोटा Firefox extension बनाया है जो तय करता है कि क्या कहना है
यह बचकाना और छोटी-सी चीज है, लेकिन कभी-कभी अपने rights exercise करने का अहसास अच्छा लगता है
[1] https://github.com/rogual/wei-gfy