Mozilla का मानक रुख, Web Environment Integrity API का विरोध

 (github.com/mozilla)
1 पॉइंट द्वारा GN⁺ 2023-07-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mozilla standards-positions इश्यू में Web Environment Integrity API पर रुख मांगा गया, और Mozilla ने कहा कि यह प्रस्ताव वेब के openness सिद्धांत से टकराता है, इसलिए इसे position: negative के रूप में दर्ज किया गया
  • प्रस्ताव में Chromium prototype फिलहाल Google Play Integrity पर निर्भर है, लेकिन specification के अनुसार इसे vendor-neutral बताया गया है; हालांकि अनुरोधकर्ता ने चिंता जताई कि EME की तरह यह भी व्यवहार में कुछ गिने-चुने vendors के इर्द-गिर्द सिमट सकता है
  • Mozilla का मानना है कि यह API डिवाइस, operating system, और browser के चुनाव को सीमित करने वाला mechanism बन सकता है, इसलिए यह वेब ecosystem की openness के लिए हानिकारक है और उपयोगकर्ताओं के हित में नहीं है
  • प्रस्तावित use cases में “non-human traffic detection” जैसी चीज़ें assistive technology, automated testing, archiving, और search engine spiders जैसे मौजूदा वेब उपयोगों को रोक सकती हैं, जो इंसानों के लिए बने content को transform, validate, index, और summarize करते हैं
  • Mozilla ने कहा कि fraud और invalid traffic detection कठिन समस्याएं हैं और वह उनके समाधान में रुचि रखता है, लेकिन इस प्रस्ताव में यह स्पष्ट नहीं है कि यह वास्तविक use cases में क्या प्रगति लाएगा, और इसे अपनाने पर साफ़ नुकसान दिखते हैं

इश्यू का अनुरोध और प्रस्ताव का दायरा

  • GitHub इश्यू ने Mozilla से Web Environment Integrity API नाम की उभरती हुई web specification पर आधिकारिक रुख मांगा
  • अनुरोध में शामिल सामग्री:
  • Chromium का prototype फिलहाल Google Play Integrity पर निर्भर है, लेकिन अनुरोधकर्ता ने लिखा कि specification खुद vendor-neutral है

उठाई गई शुरुआती चिंताएं

  • अनुरोधकर्ता ने EME का उदाहरण दिया, जो सिद्धांततः vendor-neutral है, लेकिन व्यवहार में व्यापक रूप से स्वीकार किए गए vendors बहुत कम हैं
    • Google Widevine: अधिकतर platforms पर Firefox, Chrome, Android में उपयोग
    • Microsoft PlayReady: Microsoft Edge, Windows, और कुछ Android devices में Widevine के साथ उपयोग
    • Apple FairPlay: Safari और Apple ecosystem में उपयोग
  • चिंता यह थी कि यही स्थिति Web Environment Integrity API के साथ भी हो सकती है, और वास्तविक websites pre-approved browsers की मांग करने लगेंगी
  • एक टिप्पणी में कहा गया कि यह API end users को कुछ नहीं देती और केवल users को सीमित करने के लिए इस्तेमाल हो सकती है; साथ ही specification अस्पष्ट है और underlying mechanism भी साफ़ नहीं है

Mozilla के विरोध के कारण

  • Mozilla ने कहा कि यह प्रस्ताव Mozilla के web principles और vision के खिलाफ है
  • Mozilla के web vision के अनुसार, जो browsers, servers, और publishers common standards को implement करते हैं, उन्हें अपने-आप वेब का हिस्सा बन जाना चाहिए
  • standards को deployable hardware या software के बारे में धारणाएं बनाने से बचना चाहिए, और किसी खास पक्ष को यह तय नहीं करना चाहिए कि कौन-सा form factor, device, operating system, या browser वेब तक पहुंच सकता है
  • यही choice assistive technology, localization, form factors, और price के स्तर पर अलग-अलग लोगों को उसी वेब तक पहुंचने में सक्षम बनाती है
  • इसलिए choice को सीमित करने वाले mechanisms वेब ecosystem की openness के लिए हानिकारक हैं और उपयोगकर्ताओं के लिए अच्छे नहीं हैं

“non-human traffic detection” use case की समस्या

  • Mozilla का मानना है कि प्रस्तावित use cases “detect non-human traffic” क्षमता पर निर्भर करते हैं
  • यह तरीका मौजूदा वेब उपयोगों में बाधा डाल सकता है

    • assistive technology

      • automated testing
      • archiving
      • search engine spiders
      • ऐसे tools को इंसानों के लिए बने content को लेकर फिर इंसानों के लिए transform, test, index, और summarize करने में सक्षम होना चाहिए
      • प्रस्ताव में दिए गए safeguards, जैसे “holdback” या random तरीके से attestation generation को fail करना, प्रभावी होने की संभावना कम है और Mozilla की उठाई गई चिंताओं को दूर करने के लिए पर्याप्त नहीं माने गए

निष्कर्ष और इश्यू का निपटान

  • Mozilla ने कहा कि fraud और invalid traffic detection कठिन समस्याएं हैं, और वह उन्हें हल करने में रुचि रखता है
  • लेकिन Web Environment Integrity API प्रस्ताव यह नहीं समझा पाता कि सूचीबद्ध use cases में यह वास्तविक प्रगति कैसे लाएगा, और इसे अपनाने पर इसके स्पष्ट नुकसान हैं
  • Mozilla के एक सदस्य ने इस विश्लेषण के आधार पर इस प्रस्ताव पर negative लेबल लगाया
  • चूंकि यह प्रस्ताव एक व्यक्तिगत GitHub repository में रखा गया प्रस्ताव है, और standard-track work या public incubation group का काम नहीं है, इसलिए अलग dashboard entry की जरूरत नहीं मानी गई
  • 25 जुलाई 2023 को इस इश्यू पर position: negative लेबल लगाने के बाद इसे completed status के साथ बंद कर दिया गया

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

1 टिप्पणियां

 
GN⁺ 2023-07-26
Hacker News की रायें

  • हमले का तरीका मोटे तौर पर ऐसा है: हमलावर स्मार्टफोन जैसा कोई डिवाइस बनाता है, key pair जनरेट करता है और उसे डिवाइस के अंदर मौजूद HSM में, जिसे आम तौर पर trusted enclave कहा जाता है, स्टोर करता है, फिर public key को master key से sign करता है
    डिवाइस हमलावर का software चलाता है, और अगर यूज़र द्वारा चुना गया software ऊँचे privileges के साथ चलाया जाए, तो HSM को ऐसा डिज़ाइन किया जाता है कि वह reboot से पहले तक अपरिवर्तनीय तरीके से यह बात जान ले। HSM “यह डिवाइस हमलावर का software चला रहा है” वाले वाक्य और हमलावर का software जो content भेजना चाहता है, उस पर sign करता है, लेकिन अगर यूज़र द्वारा चुना गया software चल रहा हो तो sign नहीं करता। इसमें master key से sign की गई public key भी शामिल होती है, ताकि मिलीभगत करने वाला पक्ष यह पुष्टि कर सके कि डिवाइस यूज़र के नियंत्रण में नहीं, बल्कि यूज़र की स्वतंत्रता सीमित करने वाली इकाई के नियंत्रण में है
    वैकल्पिक रूप से, यह प्रमाण हमलावर के server से होकर anonymization या मनमानी condition checks के बाद किसी नए प्रमाण में बदला जा सकता है। आखिरकार कोई third party इस तरीके से यह भरोसा पा लेता है कि डिवाइस हमलावर का software चला रहा है, और यूज़र को अपना मनचाहा software चलाने से रोक सकता है या डिवाइस को हमलावर और उसके मिलीभगत करने वालों की इच्छित तरह इस्तेमाल करवाने पर मजबूर कर सकता है। यह हमला Android पर Google के SafetyNet और Play Integrity API के रूप में, और iOS पर Apple द्वारा पहले से चल रहा है; अब बस इसका web तक विस्तार हो रहा है

    • इसे हमला कहकर फ्रेम करना मुझे पसंद आया। Google और उसके दोस्तों को अब तक मैंने दिमाग में “middleman” की category में नहीं रखा था, लेकिन असल में ठीक वही हो रहा है
      यह Web Integrity API उन्हें वैकल्पिक middleman नहीं, बल्कि अनिवार्य middleman के रूप में पक्का करने का साधन है
    • इस framing से मीडिया, blogs वगैरह में मुद्दा उठाना उपयोगी रहेगा। दूसरी तरफ वाले पहले ही शब्दों के अर्थ जबरन खींच रहे हैं, और DRM को “open internet की रीढ़” बताना वाकई घिनौना था
    • इस scenario में हमलावर मेरा hardware बनाता है, जो बात समझ में नहीं आती। ऐसी स्थिति में तो वह वैसे भी जो चाहे कर सकता है, और यह “हमलावर के पास hardware का स्वामित्व है, इसलिए सचमुच कुछ भी संभव है” से व्यावहारिक रूप से अलग नहीं लगता
      और इस “हमलावर” को कुछ मिलता भी नहीं। यह हमलावर नहीं, बल्कि device manufacturer है। TPM को हमलावर कहकर remote attestation process समझाने जैसा है, इसलिए अजीब लगता है
    • आखिरकार तारों से बिजली भेजने की वास्तविकता के कारण कुछ side effects ऐसे भी हैं जिन्हें ठीक नहीं किया जा सकता: जो अतिरिक्त पक्ष hardware को पर्याप्त रूप से modify कर सकता है, वह अब भी हमलावर और उसके मिलीभगत करने वालों पर हमला कर सकता है
      इसलिए ऐसी व्यवस्था आम यूज़र पर लागत डालती है, जबकि फायदा सिर्फ उन लोगों को देती है जिनके पास ऐसी क्षमता है
    • smartphone इस्तेमाल करते हुए इस हमले से बचने का कोई तरीका है? मरता हुआ Ubuntu Phone याद आता है

  • यह अपेक्षित था, लेकिन अगर लोगों को Firefox की ओर भेजकर Chromium परिवार से दूर नहीं किया जा सका तो इसका कोई मतलब नहीं। web की safety और security, और व्यापक रूप से trust, में निवेश करने वालों पर कुछ हद तक ज़िम्मेदारी है
    Brave इसे support करेगा या नहीं, इस पर अभी कुछ नहीं देखा। हालांकि अगर मैंने सही समझा है, तो Chromium इस्तेमाल करने पर कोई विकल्प नहीं होगा, और उम्मीद है कि मैं गलत हूँ

    • इस मामले में Mozilla पर जो आलोचना होती है उसे देखते हुए, फिर भी उसका जो श्रेय बनता है वह मिलना चाहिए
      आखिरकार मुझे लगता है कि हमें IE bundling episode के बाद जैसी, कानून से समर्थित browser choice screen पर स्थायी रूप से लौटना होगा। वरना friction और incentives लगातार एक dominant player को और मजबूत करते रहेंगे
    • अंतिम नतीजा शायद यह होगा कि DRM sites और banking sites कहेंगी, “जारी रखने के लिए Chrome इस्तेमाल करें।” यूज़र Chrome की ओर जाते रहेंगे, और Mozilla को भी अंततः इसे implement करने के लिए मजबूर होना पड़ेगा
    • “safety और security” वाली अभिव्यक्ति कई लोगों के लिए घृणास्पद शब्द बन गई है, क्योंकि यह Google आदि द्वारा बनाई जा रही authoritarian dystopia की याद दिलाती है
      ज्यादा महत्वपूर्ण चीज़ freedom और interoperability है
    • SMBs के लिए काम करने वाले system admins या IT organizations के लिए एक तरीका यह भी है कि workstations पर Firefox पहले से install कर दें। यूज़र उस browser से परिचित हो जाएंगे और निजी तौर पर भी इस्तेमाल कर सकेंगे
      बोनस के तौर पर uBlock Origin भी पहले से install कर सकते हैं। हम ऐसा ही करते हैं
    • जब लोग अपने रोज़मर्रा के browser में पहले किए जाने वाले काम नहीं कर पाएंगे, तभी ऐसा migration होगा। मुझे लगा था कि Manifest V3 user scripts तोड़ेगा और ad blocking को झंझट बना देगा, लेकिन अभी तक ऐसा नहीं हुआ, इसलिए Chrome से हटने की खास वजह नहीं बनी
      अगर यह implement हो गया, तो किसी यूज़र की identity “अपर्याप्त” मानी जा सकती है और उसे कुछ websites या services तक access नहीं मिलेगा; तब इस feature के बिना किसी दूसरे browser पर जाने की motivation बन सकती है

  • जैसा मैंने दूसरी जगह भी कहा है, लोगों को Firefox इस्तेमाल करना चाहिए। अगर सभी रुक गए, तो Google की बकवास के सामने आवाज़ उठाने वाली कोई इकाई नहीं बचेगी। Google Chrome का मालिक है और जो चाहे कर सकता है
    बात यह नहीं कि Firefox perfect है या बेहतर है, बल्कि यह कि उसकी ज़रूरत है। हमें meaningful market share वाला ऐसा competing browser चाहिए जिसके पास ऐसा rendering engine हो जिसे Google ultimately control नहीं करता। वरना शिकायत करना बंद कर Google को अपनी मर्ज़ी करने देने के अलावा कोई रास्ता नहीं

    • क्या Mozilla की ज्यादातर revenue Google की default search engine paid placement से नहीं आती? नहीं पता कि पिछले कुछ वर्षों में बदला है या नहीं
      मोटे तौर पर खोजने पर दिखा कि 5–10 साल पहले revenue का 50% से ज्यादा Google से आता था, लेकिन इससे हालिया data नहीं मिला। अगर Google Mozilla का मुख्य revenue source, खासकर बहुमत, है, तो Google के पास Mozilla का सबसे बड़ा revenue source काटने की leverage है और वह असल में Mozilla को control करता है
      यह सवाल भी उठता है कि browser develop कौन-सी company या organization करे। हर कोई browser को free की तरह expect करता है, लेकिन development, operations और maintenance free नहीं हैं। Brave जैसी for-profit browser companies को browser को monetize करना ही पड़ता है, जैसे BAT crypto token या new tab ads के जरिए
    • अगर Firefox सच में मेरे लिए usable होता तो मैं इस्तेमाल करता, लेकिन ऐसा नहीं है, इसलिए नहीं कर सकता

  • क्या Mozilla भी पूरे इंटरनेट पर यूज़र्स को track करने वाले अपने IPA प्रस्ताव पर अपना रुख बता सकता है?
    अगर कोई user searchengine.example पर किसी product का ad देखता है, बाद में reviews.example पर उस product को देखता है और फिर shop.example पर खरीदता है, तो Mozilla browser ये सभी events एक या अधिक aggregation services को भेजेगा, ताकि shop.example कम-से-कम aggregate level पर समझ सके कि user searchengine.example पर ad के exposure में आया था और reviews.example पर भी फिर से exposure हुआ था। बेशक, इसमें यह मानकर चला जाता है कि aggregation services चलाने वाले cartel पर भरोसा किया जा सकता है।
    पहले ad-tech कंपनियां cookies बंद होने पर भी source IP address के आधार पर users को track कर सकती थीं, लेकिन IPA unique tracking identifiers के जरिए कई IP addresses के पार और cookie settings से स्वतंत्र होकर tracking संभव बनाता है। यह भी प्रस्तावित है कि operating system ऐसा unique tracking identifier दे, जिसे device के सभी apps और browsers इस्तेमाल कर सकें, जिससे एक ही IP के पीछे मौजूद कई devices को भी अलग-अलग पहचाना जा सके।
    https://github.com/patcg-individual-drafts/ipa/

    • Ads के काम करने के लिए attribution जरूरी है। अगर जिस platform पर ad खरीदा गया है उससे स्वतंत्र attribution न हो, तो वह ad platform fraud कर सकता है।
      यह user interest profile बनाने वाली ad tracking या पुराने visitors को target करके ads खरीदने वाली remarketing से अलग चीज है। ज्यादातर private attribution systems इस तरह design होते हैं कि ad operator यह गिन सके कि कितने लोगों ने ad पर click किया, लेकिन यह न जान सके कि किसने click किया या उसने और क्या किया। Safari के प्रस्ताव में प्रति domain चलाए जा सकने वाले campaigns की संख्या पर limit थी, ताकि हर user के लिए अलग “campaign” बनाकर एक ही बार में fingerprint tracking करने से रोका जा सके। Mozilla का प्रस्ताव कैसे अलग है, यह मुझे नहीं पता।
      User agent को ऐसी चीजों की परवाह करनी चाहिए या नहीं, यह अलग सवाल है।
      https://www.theregister.com/2023/06/29/google_trueview_skepticism/
      खास तौर पर remarketing ही modern advertising में वह “निगरानी में होने का एहसास” पैदा करती है, जहां आप कोई चीज search करते हैं और अगले पूरे हफ्ते उसी चीज के 10,000 ads आपका पीछा करते रहते हैं।
    • मूल पोस्ट देखने पर लगता है कि Mozilla का रुख https://github.com/mozilla/standards-positions पर GitHub issue खोलकर पूछा जा सकता है।
    • निष्पक्ष रूप से कहें तो “Web Integrity”, यानी remote attestation या “मेरे” hardware में डाला गया corporate surveillance agent, कहीं ज्यादा बुनियादी समस्या है। इसकी वजह यह है कि यह IPA जैसी जानबूझकर रखी गई security weaknesses हटाने वाले fork browser को चलाने से ही रोक सकता है।
      यह अफसोसजनक है कि Mozilla IPA जैसी बकवास के साथ तालमेल बिठा रहा है, लेकिन कम-से-कम अभी user के पास इसे disable, remove या fork करने की आजादी है। इसके उलट remote attestation user agent की अवधारणा के लिए practically game over है।
    • Mozilla का प्रस्ताव कितना भी खराब हो, यह मुद्दे को भटकाना है। आखिरकार यह Google के हितों की सेवा करता है और कहीं ज्यादा dystopian प्रस्ताव का बचाव करने लगता है।
    • “Mozilla browser ये सभी events एक या अधिक aggregation services को भेजता है” वाली बात user की अनुमति होने पर ही लागू होती है।

  • Browser detection, “environment” detection
    कुछ website operators विरोध के तरीके के रूप में ऐसी websites design कर सकते हैं जो Chrome से access न हो सकें। Google को इसे bypass करने की कोशिश करते देखना मजेदार होगा। खासकर अगर यह trend सिर्फ छोटी और non-commercial websites के बीच चले, तब और भी।

    • अच्छा idea है। इससे users को कई browsers नियमित रूप से इस्तेमाल करने की आदत डालने में मदद मिल सकती है। मेरे बच्चे भी Android devices पर YouTube ads block करने के लिए पहले से कई browsers इस्तेमाल करते हैं। पर्याप्त वजह हो तो लोग दूसरे browsers भी खुशी-खुशी इस्तेमाल करते हैं।
      हालांकि पूरी तरह block करने के बजाय मैं सिर्फ बेहद जरूरी functionality छोड़ूंगा, और लगातार बताऊंगा कि दूसरे browser पर switch करें या Tampermonkey जैसी चीज इस्तेमाल करें। क्या करना है, इसके लिए साफ instructions भी साथ देने चाहिए।
      इस feature support को detect करने का अच्छा तरीका क्या होगा? JavaScript API?
    • लंबे 6 सालों तक Chrome मेरी website access नहीं कर पाया। बाकी सभी browsers कर सकते थे, लेकिन server-side पर केवल non-HTTP/3 तरीका force-negotiate करने और ChaCha/Poly ही allow करने, AES/RSA को exclude करने वाली setting को Chrome respect नहीं कर पाता था। Microsoft Edge ने कुछ समय बाद इसे fix कर दिया।
      सौभाग्य से Google ने भी करीब 4 महीने पहले इसे fix कर दिया। कई free cross-browser testing tools में अब भी version test से वह breakage दिखाया जा सकता है।
    • संदर्भ के लिए उपयोगी हो सकता है: https://news.ycombinator.com/item?id=25240299

  • Mobile side का counterpart Play Integrity API गैरकानूनी घोषित किया जाना चाहिए और अदालत में challenge होना चाहिए। इसका core idea third-party ROMs को हटाना है, इसलिए मुझे लगता है कि यह EU के right-to-repair और e-waste कानूनों के भी खिलाफ हो सकता है।
    बहस का focus Google और उसके ads से पैदा हुई security problems की तरफ मोड़ना शुरू करना चाहिए।

    • Google trusted computing का दुरुपयोग कर रहा है। यह समझ में आता है कि कुछ banks चाहेंगे कि payment processing code locked-down devices पर चले, लेकिन अभी ऐसे Android devices में Google adware और spyware भी होता है, जिसकी payment के लिए trusted device में बिल्कुल जरूरत नहीं है।
      Google को तोड़ना चाहिए ताकि उसके हित Android और Chrome को दूषित न कर सकें।

  • मैं Mozilla को दान देना चाहता/चाहती हूं, लेकिन चिंता है कि मेरा पैसा C-level executives की जेब में चला जाएगा। क्या Firefox core team या MDN को खास तौर पर दान करने का कोई तरीका है?

    • Mozilla के नजरिए से इस तरह earmark करना समझ में नहीं आता। Firefox के लिए donation हो भी, लेकिन अगर office cleaning staff, rent, HR, accounting और legal लोगों को पैसा नहीं दे सकते, तो “Firefox core team और MDN” को hire करके चला नहीं सकते
      यहां तक कि बेहिसाब ज्यादा pay पाने वाला CEO भी कंपनी के लिए जरूरी होता है। मैं यह तर्क नहीं मानता कि अमेरिका में अच्छा CEO लाने के लिए बहुत ज्यादा pay करना ही पड़ेगा, लेकिन खराब CEO GE, Enron, Boeing, Twitter की तरह कंपनी को बर्बाद कर सकता है
      बजट के उपयोग पर restrictions कैसे fail होते हैं, इसका एक दिलचस्प उदाहरण Atlanta का MARTA है। पहले funding law की वजह से operating expenses और capital expenditure को 50/50 पर fix कर दिया गया था, तो नई trains तो थीं लेकिन बाकी सब ढह रहा था
    • क्या आप हर purchase पर यही analysis करते हैं? जिस sandwich shop से आपने lunch खरीदा, हो सकता है उसने उस पैसे से उस दिन काम भी न करने वाले owner और उसकी पत्नी के लिए pizza खरीदा हो। क्या इससे आपको गुस्सा आता है?
      Business में पैसा आता है, पैसा जाता है, और product बनता है। आपको पसंद के product के लिए पैसा देना है या नहीं, यह आपकी choice है। मिले हुए पैसे को कैसे खर्च करना है, यह उनका मामला है
    • आप Mozilla Foundation को restricted donation दे सकते हैं, और अगर वे उसे accept करते हैं, तो donor की सहमति के बिना वे उस restriction से बंधे रहते हैं
      लेकिन पैसा fungible होता है। अगर आप MDN support के लिए 500 डॉलर donate करते हैं, तो original revenue से MDN को जाने वाले 500 डॉलर की जगह यह ले सकता है, और दूसरे 500 डॉलर C-level pockets या Pocket वगैरह में जा सकते हैं। डॉलर खुद तो आपके बताए गए काम पर जाता है, लेकिन इससे वे दूसरे खर्च संभव हो सकते हैं जो आपको पसंद नहीं हैं
      उल्टा, अगर आप MDN support के लिए 50 billion डॉलर donate करें तो बात थोड़ी अलग होगी। existing MDN support budget जरूर मुक्त हो जाएगा, लेकिन MDN का खर्च 50 billion डॉलर तो नहीं होगा, इसलिए MDN की जरूरत से ऊपर का पैसा कहीं जा नहीं पाएगा
    • Mozilla कोई cooperative नहीं, बस एक non-profit corporation है। Developers भी दूसरी companies की तरह उस corporation के employees हैं। सच कहें तो कंपनी की revenue काफी है और वह donations पर बहुत ज्यादा निर्भर नहीं लगती
      Product इस्तेमाल करना और customer बनना शायद उनके और उनके manifesto के लिए ज्यादा valuable हो सकता है
    • अभी सबसे नजदीकी तरीका किसी एक product के लिए पैसा देना है। Pocket Premium, Firefox Relay, Mozilla VPN हैं

  • Mozilla विरोध कर सकता है, लेकिन अगर यह Chrome में आ गया और actively use होने लगा, तो आखिर में वे इसे CDM की तरह implement करेंगे
    आखिर user को बस यही दिखेगा कि कोई website Chrome में चलती है और Firefox में नहीं। जब potential market share loss की real cost सामने आएगी, तो Firefox समझेगा कि विरोध करने की वजह नहीं है

    • “Chrome नहीं, लेकिन लगभग Chrome” strategy ने market share पर कैसे काम किया, यह याद कर लें। ऐसे users को सीधे Chrome इस्तेमाल करने में कोई दिक्कत नहीं होती, इसलिए वह market असल में शायद इतना बड़ा न हो

  • WebKit का standards position भी देखने लायक है: https://webkit.org/standards-positions/
    यह मामला अभी reflect नहीं हुआ है, और शायद वे विरोध करेंगे

  • Classical sense वाले hackers का लंबा इतिहास रहा है कि उन्होंने computers से वे काम करवाए जो दूसरे लोग नहीं चाहते थे, और वे दूसरे लोग कुछ नहीं कर पाए या ज्यादा से ज्यादा arms race में लग गए। उनके लिए यह बुरा था, लेकिन society as a whole के लिए बहुत अच्छा था
    इसी से GNU, “IBM Compatible”, ad blockers, Firefox, BitTorrent, YouTube ReVanced/youtube-dl जैसी अनगिनत चीजें पैदा हुईं
    Consumer software के लिए device attestation का लक्ष्य इसी को खत्म करना है। Apple ने iOS में इसकी शुरुआत की और अब capitalism की ताकत से यह पूरी computing में फैल रहा है। Device attestation का मतलब है hackers की हार, और यह एक खराब अंत है
    एक और twin threat यह है कि software industry security को सच में ठीक कर रही है। पहले iOS jailbreak आम थे, लेकिन 1 साल से iOS jailbreak नहीं आया। Rust भी मदद नहीं करता
    हम ऐसी दुनिया की ओर तेजी से बढ़ रहे हैं जहां producers और intellectual property holders अपने बनाए content पर पूरा control रखते हैं, और cutting-edge cryptography व बेहद secure लेकिन consumer-hostile software से उस स्थिति को बनाए रखते हैं। यह इतिहास के सबसे खतरनाक developments में से एक है, और अगर reality बन गया तो इसे पलटा नहीं जा सकेगा। Stallman सही थे

    • अच्छी तरह summarize किया। सच में, इस तरह की attestation वाली सारी बकवास मुझे तो DRM ही लगती है। बेशक इसे “experience improve कर सकने वाले” optional feature की तरह market किया जा रहा है
      यह वैसा ही है जैसे कहा जाए कि बंदूक की नोक पर wallet दे देने से आपकी खुशी improve हो सकती है