क्या macOS के permission popup पर भरोसा किया जा सकता है?

 (wts.dev)
2 पॉइंट द्वारा GN⁺ 2025-05-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS की TCC permission system में एक खामी के कारण यूज़र को भ्रामक permission request popup दिखाया जा सकता था
  • इस vulnerability को CVE-2025-31250 के रूप में दर्ज किया गया है, और समस्या यह है कि यूज़र की सहमति किसी दूसरे app पर लागू हो सकती है
  • एक malicious app, permission request window को किसी trusted app के नाम से दिखाकर यूज़र से सहमति लेने वाला spoofing attack कर सकता है
  • इसे Apple के macOS Sequoia 15.5 में patch किया गया है, लेकिन दूसरे versions में अभी भी patch नहीं हुआ है
  • permission grant history को देखना और revoke करना मुश्किल होने के साथ-साथ, आगे भी ऐसी vulnerabilities आने की संभावना है

महत्वपूर्ण सुधार

  • यह vulnerability macOS Sequoia 15.5 में patch की जा चुकी है, लेकिन macOS Ventura 13.7.6 और macOS Sonoma 14.7.6 में अभी patch नहीं हुई है
  • यह पुष्टि की गई कि Apple के security release notes में reporter का उल्लेख नहीं है
  • virtual machine पर सीधे macOS Sonoma 14.7.6 को test करके verify किया गया कि vulnerability अभी भी exploit की जा सकती है
  • अनुमान है कि Ventura 13.7.6 भी इसी स्थिति में है
  • Apple की आधिकारिक प्रतिक्रिया का इंतज़ार किया जा रहा है

परिचय

  • CVE-2025-31250 vulnerability apps को macOS पर fake permission request popup दिखाने की अनुमति देती है
  • अगर "Application A" popup दिखाए, तो popup में वह "Application B" के रूप में दिख सकता है, जबकि अंत में यूज़र की permission consent "Application C" पर लागू हो सकती है
  • सामान्य तौर पर ये तीनों applications एक ही होती हैं, लेकिन इस खामी के कारण इन्हें अलग-अलग set किया जा सकता था
  • इससे permission request window की reliability पर गंभीर सवाल उठते हैं
  • पहले भी HackTricks आदि में ऐसे ही "spoofing" तरीके दिखाए गए थे, लेकिन यह vulnerability उससे भी अधिक सरल है

TCC

  • TCC, Apple OS में built-in core permission management system है
  • permissions को "tccd" daemon को message भेजकर manage किया जाता है, और public API private TCC framework functions को call करती है
  • daemon, message communication के लिए Apple की XPC API का उपयोग करता है
  • इस vulnerability के patch होने से पहले, crafted messages भेजकर permission request popup दिखाने वाले app और वास्तव में permission पाने वाले app को अलग-अलग set किया जा सकता था
  • यह समझने के लिए कि ऐसी खामी क्यों आई, Apple Events को समझना ज़रूरी है

Apple Events

Apple Events क्या हैं

  • Apple Events, macOS apps के बीच process communication का तरीका हैं
  • यह protocol 1993 में प्रकाशित पुराने classic books के दौर से चला आ रहा है
  • macOS X आने के बाद भी इसे उसकी architecture के अनुरूप redesign करके इस्तेमाल किया गया
  • आज के समय में इसका उपयोग मुख्य रूप से automation के लिए होता है, और scripting AppleScript तथा JavaScript से की जाती है
  • यह Windows के Script Host जैसा है, और malware vector के रूप में भी इसका दुरुपयोग हुआ है

Apple Events और TCC

  • macOS Mojave 10.14 से Apple Events भेजने के लिए user consent अनिवार्य है
  • TCC के permission storage database (TCC.db) में requesting app, service, और consent response की जानकारी दर्ज होती है
  • Apple Events के लिए हर receiving app के हिसाब से permissions अलग manage करनी पड़ती हैं, इसलिए TCC.db का indirect object column इस्तेमाल होता है
  • TCC daemon का TCCAccessRequestIndirect function इस column का उपयोग करने वाले messages को process करता है
  • इसी function में एक logical bug था, जिसके कारण यूज़र को दिखने वाला app और वास्तव में permission पाने वाला app अलग-अलग set किया जा सकता था

अवधारणा प्रमाण (Proof-of-Concept)

  • Swift code example permission request message को इस तरह manipulate करता है
    • यूज़र consent popup में "spoofedBundle" path वाले app का नाम दिखाया जाता है
    • वास्तविक permission target के रूप में "actualBundle" का bundle ID set किया जाता है
  • नतीजतन यूज़र को लगता है कि कोई trusted app permission मांग रहा है, लेकिन असल permission malicious app को मिल जाती है
  • "indirect_object" value खाली छोड़ने पर भी कई TCC services को target किया जा सकता था
  • इससे user permission consent की reliability पूरी तरह टूट जाती है
  • attacker यूज़र को धोखा देकर किसी भी app को permission दिलवा सकता है

vulnerability का exploitation

सीमाएँ और विशेष बातें

  • केवल कुछ खास TCC services ही इस attack के प्रति vulnerable हैं, लेकिन Microphone, Camera जैसी महत्वपूर्ण services प्रभावित हैं
  • file/folder permissions जैसी चीज़ों में अतिरिक्त safeguards होने के कारण प्रभाव सीमित है
  • malicious app, वास्तव में permission चाहने वाले किसी दूसरे app की जगह यूज़र से consent दिलवाने के लिए social engineering के साथ इसका उपयोग कर सकता है

timing का महत्व

  • popup दिखाने का समय बहुत महत्वपूर्ण है
  • malicious app, चल रहे apps और current foreground app को detect करके सही समय पर popup दिखा सकता है ताकि यूज़र भ्रमित हो जाए
  • उदाहरण के लिए, FaceTime चलने के समय Camera permission popup दिखाया जाए, तो यूज़र उसे सामान्य request समझ सकता है
  • Voice Memos चलने के समय Microphone permission request को spoof करने वाला scenario भी संभव है
  • context के अनुरूप timing पर हमला किया जाए, तो सफलता की संभावना बढ़ जाती है

पुरानी vulnerabilities पर फिर नज़र

  • TCC.db का path user home folder के आधार पर तय होने का फायदा उठाने वाली vulnerabilities पहले भी रही हैं
  • 2020 तक सिर्फ HOME environment variable बदलकर fake TCC.db इस्तेमाल की जा सकती थी ($HOMERun)
  • patch के बाद भी root privileges और user consent की ज़रूरत होती है, लेकिन social engineering spoofing के साथ मिलकर permission bypass संभव हो सकता है
  • malicious app, यूज़र से consent लेने के बाद home folder बदलकर और registered database जोड़कर fake TCC.db के जरिए bypass कर सकता है
  • इस तरीके से test करके यह पुष्टि की गई कि TCC behavior पर असर डाला जा सकता था

timeline

1.

  • 2024-05-02 : Apple Product Security को प्रारंभिक रिपोर्ट और अतिरिक्त संदेश भेजा गया

2.

  • 2024-05-03 : Apple Product Security ने अतिरिक्त स्पष्टीकरण मांगा और उसका उत्तर दिया गया
  • उसी दिन, पूरे TCC bypass की संभावना मिलने पर Apple को फिर से रिपोर्ट किया गया

3.

  • 2024-05-04 : PoC testing जारी रही और अतिरिक्त update message छोड़ा गया

4.

  • 2024-05-06 : Apple Product Security ने जानकारी देने के लिए धन्यवाद दिया

5.

  • इसके बाद भी समय-समय पर patch status के बारे में पूछताछ और स्थिति की पुष्टि की जाती रही, और 2024-06 से 2025-02 तक Apple से लगातार संपर्क किया गया, लेकिन लंबे समय तक इसे ठीक नहीं किया गया

6.

  • 2025-05-12 : इस bug के लिए patch release किया गया

निष्कर्ष

अन्य बातें

  • TCC, System Settings app के Privacy & Security (पहले Security & Privacy) सेक्शन और उसके Automation section में दिखता है
  • लेकिन Apple Events से संबंधित consent history GUI में दिखाई नहीं देती, इसलिए यूज़र के लिए उसे सीधे revoke करना मुश्किल है
  • CLI tool tccutil से revoke किया जा सकता है, लेकिन इसके बारे में बहुत कम लोगों को पता है
  • हाल ही में Apple Endpoint Security framework में TCC database changes को monitor करने की सुविधा जोड़ी गई है
  • अगर यह सही तरह काम करे, तो यह यूज़र को बता सकता है कि वास्तव में किस app को permission मिली, और दुरुपयोग रोकने में मदद कर सकता है

Apple का patch

  • वास्तविक patch का implementation जटिल है, लेकिन अब बाहर से arbitrary indirect object set किए गए messages को tccd में चुपचाप ignore कर दिया जाता है
  • behavior verify करने पर पुष्टि हुई कि अब spoofing संभव नहीं रही
  • अगर patch अधूरा साबित होता है, तो आगे के updates में अतिरिक्त कदमों की ज़रूरत हो सकती है

अंतिम विचार

  • इस vulnerability को "TCC, Who?" नाम दिया गया है
  • security researcher के नज़रिए से permission system की reliability के महत्व पर फिर ज़ोर दिया गया है
  • यह संकेत दिया गया है कि भविष्य में भी ऐसी खामियाँ मिल सकती हैं
  • इससे यह बात सामने आती है कि यूज़र्स को macOS permission popup पर आँख मूंदकर भरोसा नहीं करना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-05-13
Hacker News की राय

  • Apple में कोई इस लेख को देखेगा, इस बहुत छोटी-सी संभावना पर फिर वही बात दोहराना चाहता हूँ जो मैं हमेशा कहना चाहता हूँ—काश Apple यह बंद कर दे कि कभी भी अचानक 'अभी (local admin) password डालें' वाला डायलॉग दिखा दे, सिर्फ इसलिए कि कंप्यूटर को update या कुछ install करने का मन हुआ। थोड़ी-सी भी तकनीकी समझ वाला कोई व्यक्ति वेब पर लगभग बिल्कुल वैसा दिखने वाला नकली popup आसानी से बना सकता है, और तकनीकी रूप से ऊपर के लगभग 20% लोगों को छोड़ दें तो ज़्यादातर users के मन में यह सवाल भी नहीं आएगा कि यह असली है या browser के अंदर बना हुआ नकली। इस समस्या को जड़ से रोकने के लिए users को यह आदत डालनी चाहिए कि सामान्य software अचानक बिना किसी चेतावनी के काम के बीच password dialog नहीं दिखाता, लेकिन अभी का macOS security UI इसका ठीक उलटा है। इसे बदलकर menu bar में कोई रंगीन, ध्यान खींचने वाला icon दिखाना चाहिए, या Windows की तरह थोड़ी देर के लिए secure screen दिखानी चाहिए। अभी का UI design सच में बहुत खराब है

    • इन popups में मुझे सबसे बुरी बात यह लगती है कि यह क्यों माँगा जा रहा है, मना करने पर क्या होगा, और बाद में यह setting बदलनी हो तो क्या करना होगा—कुछ भी पता नहीं चलता। जब app यह कहता है कि 'settings panel खोलिए और XXX permission दीजिए', तब साफ़ दिखता है कि कौन-सा app, कौन-सी permission और कौन-सा toggle है, लेकिन password popup ऐसा UX नहीं देता। इसी वजह से मुझे capabilities वाली अवधारणा खास पसंद नहीं आई, UX बहुत असुविधाजनक है और शायद यह लगभग टालना भी मुश्किल है। बात आखिरकार 'app को पूरी तरह इस्तेमाल करने के लिए <root my computer> allow करें' जैसी बन जाएगी, क्योंकि vendor को message तय करने देंगे तो वही होगा। बिल्कुल भी मददगार UX नहीं है

    • अगर macOS अब भी modal windows को window से जुड़ा हुआ दिखाता, तो शायद यह समस्या थोड़ी कम होती। पूरी तरह हल नहीं होती, लेकिन कुछ बेहतर ज़रूर होता। अभी toolbar के ऊपर modal तैरता हुआ आ जाता है, तो पहली नज़र में वही 'app के अंदर' जैसा लगता है। Steve Jobs ने Aqua demo के समय भी कहा था कि ऐसे अलग तैरते हुए modals usability खराब करते हैं, लेकिन अब लगता है Apple हर screen पर mobile UI इस्तेमाल करने की अजीब ज़िद में यहाँ पहुँच गया है

    • मेरे कम तकनीकी परिवार वाले local device password और iCloud/Apple ID password का फर्क भी नहीं समझ पाते, और आखिर में कुछ भी डालते रहते हैं जब तक कुछ काम न कर जाए (यह UI के अस्पष्ट और असंगत होने की वजह से है)। Apple पहले Vista के UAC का मज़ाक उड़ाता था, लेकिन अब उसने खुद भी अचानक आने वाली notifications और उलझे हुए UI की भरमार कर दी है

    • मैं हाल ही में Linux से Mac पर आया हूँ, और यूँ अचानक आने वाले root password popups ने मुझे सच में उलझा दिया। कौन-सा app या command root access माँग रहा है, और क्यों ज़रूरी है, इसकी कोई जानकारी नहीं थी, इसलिए कुछ बार allow करने के बाद मैंने सीधा deny करना शुरू कर दिया। उसके बाद से popup आना बंद हो गया। लेकिन अब भी मुझे नहीं पता कि वे किसलिए आ रहे थे, या अब क्यों नहीं आ रहे

    • एक बार फिर इस क्लासिक लेख की सिफारिश करना चाहूँगा: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/

    • Passkey popup का JavaScript popup से कोई साफ़ फर्क नहीं दिखता, इसलिए security के लिहाज़ से यह खास तौर पर गंभीर गलती है

    • ऐसी स्थिति में built-in fingerprint reader सच में बहुत काम आता है। मैं आम तौर पर laptop बंद रखकर सिर्फ external monitor से इस्तेमाल करता हूँ, लेकिन system authentication चाहिए हो तो जानबूझकर उसे खोलकर fingerprint से authenticate करता हूँ

    • ट्विस्ट: असल में ऐसा कोई dialog था ही नहीं! आप पहले ही फँस चुके थे

    • इस समय के सबसे लोकप्रिय comment में जोड़कर एक जानकारी देना चाहता हूँ—इस लेख पर एक महत्वपूर्ण update है: https://news.ycombinator.com/item?id=43969087

    • मैं यह जानना चाहता हूँ कि नकली popup पर click करने में threat model क्या है। अगर वह सच में system नहीं है, तो क्या यह बस बेकार की interaction नहीं है?

    • iCloud में sign in करते समय कंप्यूटर का local password माँगने वाला popup आता है, और अगर आप उसे दर्ज करते हैं, तो वह password iCloud server पर upload हो जाता है

  • मुझे हाल ही में पता चला कि Mac apps को system Applications की बजाय मेरे home directory के Applications (~/Applications) में install करना चाहिए, हालाँकि यह तभी मायने रखता है जब कंप्यूटर एक ही व्यक्ति इस्तेमाल करता हो। अगर मैं खुद को non-admin user बना लूँ और apps को home directory के Applications में install करूँ, तो update permission prompts परेशान नहीं करते। ज़्यादातर apps admin हुए बिना खुद update हो जाते हैं। अपवाद के तौर पर सिर्फ Tailscale जैसे apps, जिन्हें OS integration चाहिए, अलग permission माँगते हैं। जानकारी के लिए, यह तरीका Pareto Security नाम के app ने सुझाया था

    • अफ़सोस की बात है कि लगभग ज़्यादातर app developers को भी यह तरीका नहीं पता, और कई apps तो /Applications path पर ही install होने की ज़िद करते हैं, इसलिए दूसरी जगह पर काम भी नहीं करते

    • ~/Applications में app install करने से root के बिना auto-update संभव है, लेकिन उसी अनुपात में संदिग्ध code भी root के बिना आसानी से overwrite किया जा सकता है

    • मैं macOS 15.4.1 इस्तेमाल कर रहा हूँ, और ~/Applications folder खुद मौजूद नहीं है

    • यह दिलचस्प लगता है! मुझे रोज़मर्रा में admin account की ज़रूरत पड़ती है, इसलिए यह तरीका मेरे लिए मुश्किल है, लेकिन जिन पर लागू होता है उनके लिए वाकई उपयोगी है

  • इस लेख की बात में एक महत्वपूर्ण सुधार ज़रूरी है। पहले कहा गया था कि CVE को macOS Sequoia 15.5 में patch किया गया, लेकिन असल में उसी दिन जारी हुए macOS Ventura 13.7.6 और macOS Sonoma 14.7.6 में यह patch शामिल नहीं था। मैंने यह मानकर ऐसा लिखा था कि Apple ने स्वाभाविक रूप से सभी versions में patch दिया होगा, लेकिन security release notes में मेरा नाम बाकी दो versions में नहीं दिखा, इसलिए मैंने Apple से सीधे पूछा। अभी तक जवाब नहीं मिला। सीधे test करने के लिए मैंने virtual machine चलाई, macOS Sonoma 14.7.6 पर patch लगाया और अपना PoC चलाया, तो vulnerability अब भी काम कर रही थी। शायद Ventura 13.7.6 में भी यही स्थिति होगी। Apple ने patch क्यों नहीं दिया, यह मेरी समझ से बाहर है। और जानकारी मिलने पर मैं लेख फिर update करूँगा

  • macOS का TCC system एक मज़बूत privacy safeguard के रूप में जाना जाता है, लेकिन यह याद आते ही कड़वा लगता है कि इसे database की एक entry से आसानी से bypass किया जा सकता है। user consent popup की वास्तविक database manipulation के सामने बहुत कम अहमियत रह जाती है, खासकर SIP बंद वाले development environments में। आखिरकार यह भरोसे का सवाल है। क्या UX-स्तर की सहमति अभी भी कोई वास्तविक security boundary है, इस पर संदेह होता है। अब हम OS-level permission popups पर ज़्यादा निर्भर होते जा रहे हैं, लेकिन अगर वह boundary असल में भ्रम भर है (या सिर्फ staging), तो permission trust को 'दिखाने' के बजाय 'वास्तव में बनाए रखने' पर फिर से सोचने की ज़रूरत है

    • मैं सहमत हूँ कि अगर सच में कोई capabilities system लागू किया जाए तो बहुत बेहतर होगा। लेकिन अगर वह आखिरकार database ही होगा, तो दुविधा यह रहेगी कि उसे user space में रखें या kernel में। और ईमानदारी से कहूँ तो दोनों में से कोई विकल्प मुझे खास पसंद नहीं

  • मुझे याद है कि 'I'm a Mac and I'm a PC' विज्ञापनों में Vista की ऐसी चीज़ों का मज़ाक उड़ाया जाता था। लेकिन अब मेरा Mac Vista से भी बदतर लगता है। बहुत चिढ़ होती है

    • security और extensibility के बीच का tradeoff शायद अपरिहार्य है। फिर भी baseline पहले से बदली है, यह भी सच है। कम-से-कम macOS में पहले वाले Windows की तरह malicious processes की बाढ़ नहीं है। या शायद मैं बस भाग्यशाली हूँ और सावधान भी

    • बस जिज्ञासा से पूछ रहा हूँ, कौन-सी बातें आपको खास तौर पर इतनी परेशान करती थीं?

  • TCC system शुरू से ही बेहद कमजोर बनावट वाला था। यह सिर्फ वैध developers को परेशान करता है, users को permission popups से त्रस्त करता है, और malicious apps तो researchers के बार-बार दिखाने के अनुसार तरह-तरह से इस 'security show' को bypass कर लेते हैं। मैं security researcher नहीं हूँ, लेकिन Mac developer के रूप में मुझे भी bypass के कई तरीके मिले हैं। कभी-कभी तो शक होता है कि Apple engineers खुद अपनी इस्तेमाल की हुई technologies को समझते भी हैं या नहीं। सोचता हूँ, पारंपरिक Mac developers में से अब कितने बचे होंगे

    • जैसे-जैसे और बुनियादी system features TCC में जोड़े गए, Mac पर enterprise management software deploy करने में बहुत friction बढ़ गया है (खासकर education sector में)। अब तो इसके value proposition पर ही सवाल उठता है। मैं 2003 से macOS (Cocoa) developer के रूप में काम कर रहा हूँ

  • मैं कंपनी का Mac इस्तेमाल करता हूँ, और समय-समय पर 'Slack एक नया helper tool install करने की कोशिश कर रहा है' वाली सूचना आती रहती है। यह क्या है, क्यों आता है, कुछ पता नहीं। मैंने IT team से पूछा, उन्हें भी नहीं पता कि इसे कैसे verify करें। मुझे अक्सर लगता है कि इसका दुरुपयोग हो सकता है, क्योंकि यह बार-बार password माँगता है, और हर बार cancel करने पर भी फिर आ जाता है

    • यह dialog System Management framework से आता है। इसका मकसद यह है कि Slack कहीं भी install हो, और किसी भी user ने install किया हो, फिर भी वह खुद update कर सके, इसलिए वह ऊँचे privilege वाला helper tool install करता है

    • जब भी ऐसे popups आते हैं, मुझे यह तय करने के लिए कोई जानकारी ही नहीं मिलती कि allow करूँ या deny, इसलिए मैं हमेशा cancel ही दबाता हूँ

    • मैं Slack को web app की तरह इस्तेमाल करता हूँ (लेकिन browser के अंदर नहीं, अलग window में) https://support.apple.com/en-us/104996 Discord को भी इसी तरह इस्तेमाल किया जा सकता है। मेरे अनुभव में यह Electron app से कहीं अधिक smooth लगता है। ज़्यादातर Electron apps के लिए यह तरीका बेहतर है

    • मैंने खुद कभी 'helper tool' popup नहीं देखा, लेकिन Slack जैसे साधारण messaging app को ऐसी permission क्यों चाहिए, यह समझ नहीं आता। Slack support से पूछना अच्छा रहेगा (और उम्मीद है कि इस बार कोई सचमुच ठीक जवाब दे)

    • जिन apps को password चाहिए होता है (जैसे Linux में सिर्फ root के रूप में चलने वाले binaries), उनके मामले की तरह यहाँ abuse की संभावना साफ़ है। आखिरकार बात इस भरोसे की है कि developer और app सच में वही हैं जिन पर आप भरोसा कर सकते हैं। जिस दिन Apple बाहरी apps को root privileges देना पूरी तरह बंद कर देगा, उसी दिन Mac सच में एक walled garden बन जाएगा, और यहाँ (HN पर) शिकायतों की बाढ़ आ जाएगी। इसलिए निष्कर्ष यही है कि Slack जैसे उन apps पर, जिनके लिए इसकी ज़रूरत साफ़ नहीं है, root privileges न देने वाला 'स्वस्थ अविश्वास' रखना ज़रूरी है

    • यह ज़बरदस्ती input focus छीन लेता है, और message टाइप करते समय लिखा जा रहा text अचानक password input field में जाने लगता है। बेहद झुंझलाने वाला अनुभव है

    • popups समय के साथ जमा होते जाते हैं। वीकेंड के बाद कंप्यूटर चालू करो तो वे लगातार आते रहते हैं, और आखिर में मैं Slack बंद कर देता हूँ। एक साल से यही चल रहा है। मुझे नहीं पता Slack से यह permission कैसे वापस ली जाए, थोड़ा malicious-सा लगता है

    • इस तरह के 'security' blockers सच में बेवकूफी भरे हैं। उल्टा यह लोगों को और मूर्ख बनने की training देते हैं। आज भले असली हो, कल नहीं भी हो सकता। मुझे बैंक से 'identity protection' के नाम पर मेरी निजी जानकारी माँगने वाली calls आती रहती हैं, और ऐसे तंत्र लोगों को अनजान लोगों को अपनी निजी जानकारी दे देने की आदत सिखा देते हैं

    • मैं macOS developer नहीं हूँ, लेकिन हमेशा यह जिज्ञासा रही कि क्या कोई भी (malicious) app system popup window style की नकल करके user password चुरा सकता है

    • VSCode भी कंपनी के दिए हुए Mac पर यही popup दिखाता है। मैं कई सालों से इसे बस नज़रअंदाज़ कर रहा हूँ

    • कई Electron-based apps में, अगर आप OS user accounts एक से ज़्यादा इस्तेमाल करते हैं, तो ऐसे popups आते हैं

    • nordVPN में भी यही होता है

  • Apple को patch देने में पूरा 1 साल लग गया। यह काफ़ी लंबा लगता है। <i>2024-05-04 कई update messages छोड़े गए, PoC का test जारी है</i> <i>2025-05-12 patch release हुआ</i>

    • मैं भी मानता हूँ कि 1 साल बहुत लंबा समय है। मुझे लगता है कि या तो जिस behavior को मैंने ढूँढा, उसके पीछे कोई वैध (internal?) वजह रही होगी और malicious use case के साथ संतुलन बिठाने में समय लगा, या फिर इसकी priority कम रही होगी। जो भी हो, patch में 1 साल लगना चौंकाने वाला है

  • Adobe Creative Cloud OS settings में background execution को स्पष्ट रूप से बंद करने के बाद भी background में कई processes चलाता रहता है

  • मुझे इस व्यक्ति का research बहुत पसंद है, और presentation भी बहुत अच्छी लगती है

    • धन्यवाद! जानकारी के लिए बता दूँ, मैं पुरुष नहीं हूँ, बस एक व्यक्ति हूँ