विशिष्ट सहायक के रूप में hardware attestation

 (grapheneos.social)
2 पॉइंट द्वारा GN⁺ 10 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple और Google hardware-based attestation के उपयोग का विस्तार कर रहे हैं, अधिक सेवाओं में इसे अपनाने को बढ़ावा दे रहे हैं, और लंबे समय में बिना अनुमोदन वाले hardware और OS प्रतिस्पर्धा को बाहर करने वाली संरचना को मजबूत कर रहे हैं
  • Google Play Integrity API और Apple App Attest API समान तरीके से काम करते हैं, और Play Integrity strong integrity में hardware attestation की मांग करता है तथा device integrity में भी इसे चरणबद्ध तरीके से अनिवार्य करने की दिशा में बढ़ रहा है
  • Apple Privacy Pass, Google का रद्द किया गया Web Environment Integrity, और reCAPTCHA Mobile Verification attestation की मांग को web तक ले आते हैं, जिससे iOS या प्रमाणित Android device न होने पर web services तक पहुंच रोकी जा सकती है
  • Play Integrity API GrapheneOS को प्रतिबंधित करता है, भले ही वह अनुमत लक्ष्यों से अधिक सुरक्षित हो, जबकि 10 साल से बिना security patch वाले devices को अनुमति देता है; इससे सुरक्षा तर्क की तुलना में Google Mobile Services licensing और प्रतिस्पर्धा-बहिष्कार का उद्देश्य अधिक स्पष्ट दिखता है
  • जैसे-जैसे सरकार और banking services App Attest और Play Integrity के उपयोग को अधिक आवश्यक बना रही हैं, Apple devices या Google-प्रमाणित Android devices व्यवहारिक रूप से अनिवार्य हो सकते हैं, और इसका असर Windows·desktop Linux·FreeBSD जैसे वातावरणों की web access पर भी पड़ सकता है

web तक फैलती attestation की मांग

  • Apple का Privacy Pass अपने hardware पर CAPTCHA पार कराने में मदद के लिए hardware attestation को web तक लाता है
  • उस समय कई लोगों ने इसे हानिरहित माना, क्योंकि उनका सोचना था कि Apple hardware न इस्तेमाल करने वालों को रोकने वाली sites बहुत अधिक नहीं होंगी
  • Apple और Google, दोनों के अधिक व्यापक hardware attestation को web तक ले जाने की संभावना काफी है
  • बैंक और सरकारी सेवाएं mobile apps के उपयोग को लगातार अधिक अनिवार्य बना रही हैं, और app के भीतर attestation का उपयोग करके Apple या Google द्वारा अनुमोदित devices और OS को लागू कर सकती हैं
  • Apple का Privacy Pass, Google का रद्द किया गया Web Environment Integrity, और reCAPTCHA Mobile Verification इस प्रवृत्ति को web तक ला रहे हैं
  • reCAPTCHA Mobile Verification पर मौजूदा रिपोर्टिंग उसके प्रभाव और निहितार्थ को ठीक से नहीं समझा रही है
  • यह तरीका कुछ स्थितियों में reCAPTCHA पार करने के लिए प्रमाणित smartphone से QR scan करने की मांग करता है, जिससे Windows, desktop Linux, OpenBSD आदि पर भी hardware attestation की मांग आ जाती है
  • reCAPTCHA पर अपने नियंत्रण के कारण Google ऐसी स्थिति में है कि web के विशाल हिस्से के उपयोग के लिए iOS या प्रमाणित Android device को आवश्यक बना दे
  • Google Android certification की आवश्यकताएं तय करता है, जिनमें Google Chrome bundling को अनिवार्य करना जैसी शर्तें शामिल हैं
  • reCAPTCHA Mobile Verification अभी GrapheneOS के sandboxed Google Play के साथ काम करता है, लेकिन यह बिना hardware attestation वाले systems पर भी इसे लागू करना शुरू करने का साधन है
  • यदि यह मांग लागू होती है, तो iOS या Android device न रखने वाले लोगों को बिना किसी अतिरिक्त शर्त के भी रोका जा सकता है

Play Integrity और GrapheneOS का बहिष्कार

  • Google का Play Integrity API GrapheneOS के उपयोग को प्रतिबंधित करता है, भले ही GrapheneOS किसी भी अनुमत लक्ष्य से कहीं अधिक सुरक्षित हो
  • Play Integrity API अन्य विकल्पों को भी प्रतिबंधित करता है; यह केवल AOSP-आधारित OS तक सीमित समस्या नहीं है
  • FreeBSD-आधारित mobile OS इस्तेमाल करने पर भी इस समस्या से बचा नहीं जा सकता, बल्कि और अधिक बहिष्कार का सामना करना पड़ता है
  • Play Integrity API 10 साल से बिना security patch वाले devices को भी अनुमति देता है
  • device integrity स्तर को spoofing से bypass किया जा सकता है, लेकिन Google यदि इसका बड़े पैमाने पर उपयोग शुरू हो जाए तो इसे काफी प्रभावी ढंग से detect और block कर सकता है
  • strong integrity स्तर को bypass करने के लिए TEE या SE से लीक हुई key की जरूरत होती है
  • Play Integrity API बहुत सुरक्षित नहीं है और इसे अस्थायी रूप से bypass करना कोई खास मुश्किल काम नहीं है
  • software checks को spoof करने वाले frameworks मौजूद हैं, और hardware attestation bypass करने के लिए लीक keys भी खरीदी जा सकती हैं
  • हालांकि bypass करना लगातार कठिन होता जा रहा है, और उनकी वैधता अवधि भी लगातार कम हो रही है
  • Play Integrity कोई उपयोगी security feature नहीं देता, लेकिन प्रतिस्पर्धा को बाहर करने में बहुत प्रभावी है
  • जो services Apple App Attest या Google Play Integrity की मांग करती हैं, वे मुख्यतः Apple और Google को mobile devices पर duopoly बनाए रखने में मदद करती हैं
  • Play Integrity का अधिक महत्व इसलिए है क्योंकि AOSP open source है
  • GrapheneOS को hardware attestation के जरिए verify किया जा सकता है, और Google के Play Integrity में GrapheneOS पर प्रतिबंध का कारण यह है कि वह Google Mobile Services का license नहीं लेता और प्रतिस्पर्धा-विरोधी नियमों का पालन नहीं करता
  • ऐसे नियमों को कोरिया सहित कुछ स्थानों पर पहले ही अवैध माना जा चुका है
  • सेवाओं को मनमाने hardware और operating system के उपयोग पर प्रतिबंध नहीं लगाना चाहिए
  • जब Google 10 साल से बिना patch वाले devices को अनुमति देता है लेकिन उससे कहीं अधिक सुरक्षित OS को नहीं, तो सुरक्षा का तर्क टिकना कठिन है
  • यह GMS licensing के जरिए प्रभुत्व थोपने का तरीका है

सरकारी·banking सेवाएं और regulation की भूमिका

  • सरकारें न केवल अपनी सेवाओं में बल्कि commercial services में भी Apple App Attest और Google Play Integrity के उपयोग को बढ़ती हुई मात्रा में अनिवार्य कर रही हैं
  • EU digital payments, identity verification, age verification आदि में ऐसी आवश्यकताओं को लागू करने की प्रवृत्ति का नेतृत्व कर रहा है
  • कई EU government apps में ये आवश्यकताएं पहले से मौजूद हैं
  • Apple और Google के गंभीर anti-competitive आचरण को रोकने के बजाय, सरकारें अपनी सेवाओं के जरिए सीधे प्रतिस्पर्धा-बहिष्कार में भाग ले रही हैं
  • लोगों से Apple device या Google-प्रमाणित Android device की मांग करना सुरक्षा नहीं, बल्कि प्रतिस्पर्धा पर रोक है
  • banking·government services तक पहुंच या कुछ reCAPTCHA पार करने के लिए unmodified iOS या Google Mobile Services Android device की जरूरत पड़ना सिर्फ GrapheneOS की समस्या नहीं है
  • इसका वही असर Windows, desktop Linux, FreeBSD आदि पर भी पड़ता है
  • यह Pixel, Android devices, या AOSP-आधारित operating systems तक सीमित मुद्दा नहीं है, बल्कि desktop web access को भी प्रभावित कर सकता है

Android attestation API और Unified Attestation

  • Android verified boot key fingerprint की अनुमति देकर वैकल्पिक operating systems को समर्थन देने वाली एक मानक hardware attestation system प्रदान करता है
  • Android का hardware attestation मुख्यतः Google root of trust और remote key provisioning service का उपयोग करता है, लेकिन API स्वयं alternative roots of trust को support करता है
  • Android hardware attestation का उपयोग उन users को बाहर करने के लिए नहीं किया जाना चाहिए जो किसी खास hardware या OS का उपयोग नहीं करते
  • हालांकि मनमाने roots of trust और OS को अनुमति देने की क्षमता services को अधिक targets स्वीकार करने की गुंजाइश देती है
  • यदि Google का उद्देश्य सुरक्षा होता, तो वह इसी system का उपयोग करके Play Integrity में GrapheneOS को अनुमति दे सकता था
  • Unified Attestation कई European companies द्वारा आगे बढ़ाया जा रहा एक और anti-competitive system है, जो मनमाने hardware और software users को समान तरीके से बाहर करेगा
  • Unified Attestation कोई समाधान नहीं है, और Android के कहीं अधिक खुले hardware attestation API की तुलना में बहुत खराब है
  • Volla का Unified Attestation पूरी तरह Android के hardware attestation API पर बनाया गया है
  • Volla का Unified Attestation इसीलिए मौजूद है कि क्या अनुमति होगी, इस पर central authority और services का नियंत्रण स्थापित किया जा सके

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

2 टिप्पणियां

 
unsure4000 7 시간 전

मुझे Google इतना पसंद है कि काश इसके लगभग पाँच होते🥰
 
GN⁺ 10 시간 전
Hacker News की राय

  • EU Digital Identity Wallet(EUDI), Google या Apple के hardware attestation की मांग करता है, जिससे व्यवहार में EU की सारी digital identity अमेरिका की इन दो कंपनियों से बंध जाती है
    digital sovereignty की बात करते हुए ऐसा फैसला करना अजीब है, और ऐसा लगता है जैसे बच्चों की सुरक्षा को sovereignty से ऊपर रखा जा रहा है
    https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...

    • इसका मतलब है कि अगर अमेरिकी राष्ट्रपति सिर्फ एक स्विच पलट दे, तो EU का Digital Identity Wallet बंद हो सकता है
      समझ नहीं आता कि शुरू में ऐसा फैसला क्यों लिया गया
    • मैंने इस मुद्दे पर EU के जिम्मेदार अधिकारियों को मेल भेजा, लेकिन जवाब सिर्फ इसी तरह का उपदेशात्मक जवाब था कि app open source है, इसलिए सब ठीक है
      साफ लग रहा था कि जवाब तकनीकी जानकारी न रखने वाले आम उपयोगकर्ताओं के हिसाब से लिखा गया था
    • मैं भी लगभग यही सोचकर यहाँ आया था
      sovereignty और अमेरिका पर निर्भरता से बाहर निकलने की बात करने वाले बहुत लोग हैं, लेकिन फिर इतना बड़ा विरोध क्यों नहीं है, समझ नहीं आता; क्या इसे बस अज्ञानता ही मानना चाहिए
    • device-आधारित identifier की बड़ी समस्या यह है कि cloning के जोखिम के कारण उसे device से बहुत मजबूती से बाँधना पड़ता है
      खासकर privacy-संरक्षण वाले identifiers में यह और भी सच है, इसलिए device attestation महत्वपूर्ण हो जाती है
      अगर यह सत्यापित ही न किया जा सके कि hardware उपयोगकर्ता की key extraction को रोकता है, तो यह गारंटी नहीं दी जा सकती कि identity key वास्तव में device में locked है
      सबसे खराब बात यह है कि प्रेरित अपराधी आखिरकार उन keys को निकालकर fraud में इस्तेमाल करने का तरीका ढूंढ ही लेंगे, और नतीजा होगा open source और open computing का विनाश
    • अगर secure identity चाहिए, तो ISO7816 पहले से मौजूद है और Big Tech से पूरी तरह स्वतंत्र है
      किसे ID दिखाने की मांग की जानी चाहिए, यह अलग सवाल है, और केवल online स्थितियों के ज्यादातर मामलों में मेरा जवाब “नहीं” होगा; लेकिन जिस समाधान पर financial sector दशकों से भरोसा करता आया है, वह पहले से मौजूद है

  • approved silicon और software की मांग करना भी यहाँ की सबसे बड़ी समस्या नहीं है
    ये लोग zero-knowledge proofs या blind signatures का उपयोग नहीं करते
    इसलिए हर बार जब कोई device के जरिए proof देता है, तो वह एक ऐसा proof packet छोड़ता है जिसे उस कार्रवाई को उस device से जोड़ने में इस्तेमाल किया जा सकता है
    privacy की चिंता का दिखावा करने के लिए ये एक बीच का ढांचा रखते हैं, जहाँ intermediate server static device ID से one-time ID लेकर आता है, लेकिन उन intermediate servers पर क्या हो रहा है, यह पता नहीं, इसलिए मानकर चलना चाहिए कि सब log हो रहा है
    remote attestation path में ही यह हाल है, और DRM ID path तो इससे भी बदतर है। वहाँ कोई अर्थपूर्ण workaround नहीं है, इसलिए हर license server silicon में जड़ी static identity तक पहुँच सकता है। Google account path की तो बात ही अलग है
    remote attestation में blind signatures इस्तेमाल करने का प्रस्ताव वास्तव में दिया गया था, लेकिन अभी जहाँ तक दिखता है, इसका उपयोग नहीं हो रहा: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
    इसके कुछ संभावित कारण हैं। साफ कारण यह हो सकता है कि वे चाहें तो privacy का उल्लंघन कर सकें, या उन्हें ऐसी क्षमता रखना अनिवार्य किया गया हो
    दूसरा कारण यह हो सकता है कि अगर किसी proof को किसी खास device से जोड़ा ही नहीं जा सकता, तो abuse mitigation लगभग सिर्फ rate limiting तक सिमट जाती है, और उनके हिसाब से यह पर्याप्त नहीं हो सकता। कोई attacker device farm बनाकर हर device से malicious actor को remote attestation दिलवा सकता है और प्रति घंटा पैसा कमा सकता है

    • “किसी proof को किसी खास device से जोड़ नहीं सकते, इसलिए abuse mitigation सिर्फ rate limiting तक सीमित है” — यह बात अब भी समझ नहीं आ रही
      समझ नहीं आता कि कोई service anonymous रहते हुए भी rate limiting कैसे कर सकती है
      अगर एक service यह गिन सकती है कि दो requests एक ही entity से आई हैं, तो दो services भी खुद को एक ही service बताकर यह जान सकती हैं कि दोनों requests एक ही entity से आईं और उन्हें आपस में जोड़ सकती हैं
    • हमें online और devices पर निगरानी को सामान्य बनाना बंद करना चाहिए
      “समस्या hardware attestation नहीं, बल्कि zero-knowledge proofs का इस्तेमाल न करना है” जैसी बात कहना इस नए व्यवहार को सामान्य बनाना है
      ऐसा नहीं होना चाहिए। चाहे zero-knowledge proofs इस्तेमाल हों या नवीनतम security tech के साथ hardware attestation, समस्या hardware attestation ही है
      age verification में भी यही बात लागू होती है। समस्या यह नहीं कि age verification data leak के प्रति संवेदनशील है; समस्या खुद age verification है
    • मैं इस विषय पर कोई व्यवस्थित लेख पढ़ना चाहूँगा
      app की घोषणा के समय से ही मुझे लगभग यकीन था कि इसकी बनावट कुछ ऐसी ही होगी
      Graphene forums में भी मुझे याद है कि DRM ID सिर्फ preserved ही नहीं रहता, बल्कि profiles के बीच भी समान बना रहता है
    • सोच रहा हूँ कि क्या Privacy Pass उन्हीं तरह की समस्याओं को ठीक करने की कोशिश है जिनकी यहाँ बात हो रही है
      अगर हाँ, तो adoption को आगे बढ़ाने के लिए carrot या stick क्या बन सकता है

  • यह thread अच्छी तरह दिखाता है कि यह तकनीक क्यों “open” किसी भी चीज़ के लिए समस्या बनती जा रही है
    “हम अपना अलग web बना लेंगे” वाला तर्क तब तक ही ठीक है, जब तक हर service Google-approved या Apple-approved mobile device का मालिक होना अनिवार्य न कर दे

    • मुझे दोस्तों के साथ Pacific Northwest में Cascade Bicycle Club द्वारा आयोजित rides पर जाना बहुत पसंद था, लेकिन registration करने के लिए Google reCAPTCHA हल करना पड़ता है
      Google पहले ही उसे मेरे लिए पूरी तरह रोक चुका है
      माँगी गई चीज़ चुनने के लिए squares पर click करो तो वह अंतहीन loop में फँसा देता है, और audio version इस्तेमाल करने जाओ तो suspicious activity बताकर पूरी तरह block कर देता है
      इसलिए अब मैं अकेले ride करता हूँ, और इस साल membership भी renew नहीं की
      आखिरी बार ऐसा ही अनुभव तब हुआ था जब Facebook कुछ आयोजनों में शामिल होने का एकमात्र रास्ता बनने लगा था। तब भी मैंने बस यह मान लिया कि मुझे बाहर रखा जा रहा है, और अपना समय और पैसा कहीं और लगाया
    • ऐसी बेतुकी स्थिति बनाने के लिए किसी attestation की भी जरूरत नहीं थी
      पहले से ही कई businesses और social groups ऐसे थे जिन तक पहुँच सिर्फ Facebook, WhatsApp जैसी चीज़ों के पीछे से ही संभव थी
      यह सचमुच किसी अजीब cyberpunk dystopia जैसा लगता है। जैसे आप चिट्ठी और पार्सल सिर्फ उन्हीं लोगों को भेज सकें जो उसी निजी डाक सेवा के सदस्य हों, या आप सिर्फ उन्हीं सड़कों पर गाड़ी चला सकें जिनका आपकी car brand के साथ mutual licensing agreement हो
    • मुझे लगता है “उपयोगी security feature नहीं देता” वाला वाक्य हटा देना बेहतर होगा
      मान लो security feature हो भी, तब भी Google या Apple के अलावा दूसरे operating systems को दूसरे दर्जे का नागरिक बना देने वाला collateral damage बना रहेगा, और असली समस्या वही है
    • तो क्या फिर तर्क यह होगा कि उन services की अलग copies भी बना ली जाएँ
      bank या government interactions के लिए यह यथार्थवादी नहीं लगता, लेकिन बाकी कई services के लिए शायद संभव हो
      फिर भी किसी चीज़ को बनाना तो पड़ेगा ही, और लागत कम लोगों में बँटेगी; सिर्फ इस वजह से कि ad tech बनाने की जरूरत नहीं होगी और complexity कम होगी, शायद बात संतुलित न हो
      फिर भी यह शायद किसी तरह की अच्छी सामग्री वाली समस्या हो सकती है। hardware शायद और कठिन होगा
    • क्या हम संख्या में इतने हो सकते हैं कि अपना अलग देश जैसा कुछ चला सकें
      यह बेवकूफी भरा सवाल लग सकता है, लेकिन मैं गंभीरता से पूछ रहा हूँ

  • 1999 में जब Intel ने CPU में software द्वारा पढ़ा जा सकने वाला serial number डालने का फैसला किया था, तब उसका भारी विरोध हुआ था, और आखिरकार वह फैसला वापस लेना पड़ा
    उसके बाद भी “security” और trusted computing को आगे बढ़ाने वाले authoritarian लोग TPM और संबंधित तकनीकों को लगातार धक्का देते रहे, और mobile walled garden ecosystem के उभार में भी उनका योगदान रहा
    Windows 11 की TPM requirement भी उसी लक्ष्य की ओर एक और कदम थी। यहाँ और दूसरी जगहों पर इसे अच्छी चीज़ बताने वाला प्रचार कितना ज्यादा था, यह चौंकाने वाला था
    यह दिखाता है कि अगर “security” को बहाने के रूप में पेश किया जाए, तो काफी लोगों पर लगभग कुछ भी आसानी से थोपा जा सकता है। उम्मीद है ऐसे लोगों की संख्या घट रही होगी
    general-purpose computing के खिलाफ युद्ध जारी है, और हमें लड़ते रहना होगा
    Stallman हमेशा की तरह सही थे। उनका “Right to Read” फिर से पढ़ने का समय है। अगर अभी तक नहीं है, तो इस पर AI से बनी short film भी एक अच्छा विचार हो सकती है
    “जो लोग सुरक्षा के लिए स्वतंत्रता छोड़ देते हैं, वे दोनों के लायक नहीं रहते”

    • AI की बात आने तक मैं पूरी तरह सहमत था
      AI पूरी तरह centralized और monopolistic tool है
    • जो लोग Intel के खिलाफ थे, वही अब एक-दूसरे से कह रहे हैं कि सब बेकार है और कुछ नहीं हो सकता
      जैसा इस thread में भी दिखता है, इन मुद्दों पर momentum, गुस्सा, और self-organized response की जगह बस “किसी को परवाह नहीं”, “हम कुछ नहीं कर सकते” जैसी निराशा है
      हार मान लेना हारने का सबसे पक्का तरीका है

  • यहाँ की टिप्पणियाँ शायद इस तरह पढ़ी जा रही हैं कि attestation खुद में बुरी है, लेकिन असली तर्क शायद इसके ज्यादा करीब है कि Apple और Google के अलावा दूसरे providers को भी स्पष्ट रूप से शामिल करने का रास्ता होना चाहिए
    शीर्षक से ऐसा लगता है कि Apple और Google बुरे हैं और monopoly को स्थायी बनाने के लिए यह सब कर रहे हैं, और competitor GrapheneOS लोगों के लिए लड़ रहा है
    लेकिन आखिरी आपत्ति यह है कि इन्हें भी शामिल किया जाना चाहिए था, और ये Google के Play Integrity API द्वारा किसी अस्पष्ट कारण से reject किए जाने की शिकायत कर रहे हैं और उसे दुर्भावनापूर्ण बता रहे हैं; इससे लगता है कि ये भी इसके security value को मानते हैं
    महत्वपूर्ण identity data के लिए पूरी signature chain का proof सचमुच जरूरी है। क्योंकि AI की मदद से नकली identities आसानी से बनाई जा सकने वाली स्थिति से बचने का यही एकमात्र तरीका है

  • patent और copyright मूल रूप से monopoly के ही रूप थे
    software जब तक open source नहीं है, परिभाषा के अनुसार वह monopoly ही है

  • यह थोड़ी हैरानी की बात है कि HN पर GrapheneOS को sponsor करने वाले अमीर लोग और ज्यादा नहीं हैं
    जो संपन्न लोग और technologists इस मुद्दे की परवाह करते हैं, उनका Venn diagram काफी हद तक overlap करता होगा, और Graphene में कमियाँ होने के बावजूद यह इस क्षेत्र में बहुत बुनियादी काम कर रहा है

  • हमारी सभ्यता को आधुनिक microelectronics को manufacturing के बाद modify करने का कोई तरीका बहुत ज़रूरी है, और कम से कम अच्छी तरह सुसज्जित repair shops में तो यह संभव होना ही चाहिए
    इसकी जरूरत तो वास्तव में कल ही थी
    विकल्प के तौर पर, general-purpose computing devices को आम बिक्री के लिए भेजते समय CPU या SoC के mask ROM में किसी भी तरह का initial bootloader डालकर ship करना गैरकानूनी बना देना चाहिए
    यानी reset के बाद CPU जो पहली instruction चलाए, वह CPU package के बाहर भौतिक रूप से मौजूद storage से आनी चाहिए

    • या फिर DRM circumvention को illegal बनाने वाले कानून ही खत्म कर देने चाहिए
      संदर्भ: https://pluralistic.net/2026/01/01/39c3/
    • ऐसा होने की संभावना बहुत लंबे समय तक कम ही है
      अपेक्षाकृत सरल SoC भी undocumented boot ROM में काफी काम करते हैं, ताकि architectural reset vector तक पहुँचने से पहले reset process को संभाला जा सके
      low-level DFU routine को ऐसे boot ROM में रखना, जिसे गलती से मिटाया न जा सके, इसकी भी काफी उपयोगिता है
    • सिर्फ इससे मदद नहीं मिलेगी
      SoC silicon को इस तरह बदला जा सकता है कि वह power-on से लेकर secure boot handoff instruction तक चली हर instruction को record करे
      अगर उसमें state query, overflow flag, signature generation जैसी auxiliary instructions भी जोड़ दी जाएँ, तो OS अपना खुद का attestation बनाते समय pre-boot tampering की बात implicitly report करेगा
    • मूल लेख उन alternative operating systems के developers ने लिखा है जिन्हें Pixel 6 के बाद के सभी Google phones पर स्वतंत्र रूप से install किया जा सकता है
    • CPU या SoC के mask ROM में initial bootloader डालकर ship करना गैरकानूनी बनाने की जरूरत नहीं है
      bootloader में hardcoded key material डालना, और उसी key से load होने वाले code को verify करना गैरकानूनी बना देना काफी होगा

  • यह चौंकाने वाला है कि Google-Apple की जोड़ी को यह तय करने दिया जा रहा है कि पूरी तरह असंबंधित services तक किसकी पहुँच होगी और किसकी नहीं
    सोचिए, Google-विरोधी विचार रखने के कारण आपको Google services से block कर दिया जाए और फिर आप अपने bank account में भी login न कर सकें
    सच में Alphabet का breakup होना चाहिए

  • अगर विषय इतना गंभीर है, तो पढ़ने में कठिन ऐसे thread की जगह एक पेज में व्यवस्थित तार्किक वास्तविक लेख कहीं बेहतर होता