Word दस्तावेज़ों के ज़रिए खुद फैलने वाला Copilot AI worm

• बाहरी Word दस्तावेज़ में छिपाया गया cross-domain prompt injection (XPIA) Copilot के लिखने और संपादन के परिणामों में हेरफेर कर सकता है और नए दस्तावेज़ों में कॉपी होकर, मूल हमलावर दस्तावेज़ के बिना भी सामान्य कार्यप्रवाह के साथ फैल सकता है
• सफेद रंग और छोटे फ़ॉन्ट में छिपाए गए निर्देशों को भी Copilot formatting हटाने के बाद पढ़ लेता है; परीक्षण में इसने वित्तीय आँकड़े बदल दिए और पूरे attack prompt को परिणाम दस्तावेज़ के नीचे छिपाकर उसे नया attack vector बना दिया
• हमलावर को पीड़ित के Microsoft 365 tenant तक पहुँच की ज़रूरत नहीं होती; SharePoint, Teams, Outlook के ज़रिए दस्तावेज़ साझा करने के बाद बस इतना काफ़ी है कि उपयोगकर्ता उसे attach करे या Work IQ उसे OneDrive की संबंधित सामग्री के रूप में चुन ले
• Microsoft ने कुछ payloads को block करने और model upgrade जारी करने के बावजूद, बदले हुए prompts के साथ GPT-5.6 पर भी पूरा attack chain फिर से दिखाया गया, और 144 दिनों के coordinated disclosure के बाद भी इस पूरी vulnerability class को रोका नहीं जा सका
• संक्रमित दस्तावेज़ सामान्य internal या partner सामग्री की तरह circulate हो सकते हैं, जिससे source tracking और detection मुश्किल हो जाती है; इसलिए बाहरी दस्तावेज़ों और Copilot के परिणामों की समीक्षा करें और मूल source व model edit history को metadata के रूप में सुरक्षित रखें

---

दस्तावेज़-आधारित AI worm कैसे काम करता है

• अगर किसी दस्तावेज़ में हमलावर-नियंत्रित निर्देश Copilot के generation या editing output में कॉपी हो जाएँ, तो परिणाम दस्तावेज़ वही हमला ले जाने वाला नया vector बन जाता है
  • अगर उस दस्तावेज़ को किसी और Copilot task के source material के रूप में इस्तेमाल किया जाए, तो निर्देश फिर चलेंगे और आगे के दस्तावेज़ों में कॉपी हो जाएँगे
  • इस तरह मूल malicious document या हमलावर की अतिरिक्त दखल के बिना भी प्रसार जारी रह सकता है
• पहले के Morris II ने generative AI email assistant ecosystem में self-replicating prompts का प्रदर्शन किया था
• यह मामला मुख्यधारा के commercial productivity product में सामान्य document workflow के दौरान document-based AI worm के self-propagation का सार्वजनिक प्रदर्शन है

सामान्य document workflow का इस्तेमाल करने वाला हमला

• एक कर्मचारी किसी compromise हुई भरोसेमंद website से छिपे निर्देशों वाला market analysis document डाउनलोड करता है और उसे Copilot से financial report बनवाने के source material के रूप में उपयोग करता है
  • Copilot internal financial numbers बदल देता है और attack instructions को नई report में कॉपी कर देता है
  • कर्मचारी सामान्य दिखने वाली report save करके अंदरूनी तौर पर share कर देता है
  • अगर कोई सहकर्मी इस report को अगली report के source material के रूप में इस्तेमाल करे, तो numbers में हेरफेर और instructions की कॉपी दोबारा होती है
• जैसे-जैसे report दोबारा इस्तेमाल होती है, अधिक दस्तावेज़ attack vectors में बदलते जाते हैं, और संक्रमित website व शुरुआती malicious document की अब ज़रूरत नहीं रहती

threat model और trust boundary

• हमलावर को पीड़ित के Microsoft 365 tenant access के बिना सिर्फ़ malicious document साझा करना होता है
  • delivery path में SharePoint, Teams, Outlook और दस्तावेज़ साझा करने के अन्य साधन शामिल हैं
• मुख्य security boundary attached source material और उस दस्तावेज़ के बीच है जिसे अभी लिखा जा रहा है
  • Copilot को उपयोगी जानकारी चुनने के लिए सभी attached documents पढ़ने पड़ते हैं
  • attached documents की जानकारी का इस्तेमाल होना चाहिए, लेकिन उनमें मौजूद निर्देशों को अधिकृत user instruction नहीं मानना चाहिए
• व्यवहार में, दस्तावेज़ में डाले गए निर्देश Copilot के व्यवहार को बदल देते हैं
  • यह user को बताए बिना financial report के numbers बदल देता है
  • पूरा XPIA बाद के दस्तावेज़ों में चिपका देता है ताकि आगे के tasks में भी वह फिर चल सके

Word में trust boundary कैसे पार होती है

• शुरुआती malicious document में JSON-format prompt डाला जाता है, जिसे सफेद background पर सफेद text और छोटे फ़ॉन्ट से user से छिपाया जा सकता है
• Copilot for Word text को base LLM तक भेजने से पहले रंग और font size जैसी formatting हटा देता है, इसलिए user को न दिखने वाली सामग्री भी model को पूरी तरह पढ़ाई जाती है
• attack instructions को task-संबंधित दिखने वाले सामान्य दस्तावेज़ में डालकर इसे और छिपाया जा सकता है
• malicious document को Copilot context में आने के लिए इनमें से एक शर्त चाहिए
  1. user सीधे दस्तावेज़ को Copilot for Word में attach या upload करे
  2. user Edit with Copilot का work/Work IQ mode इस्तेमाल करे, और Copilot OneDrive से उस दस्तावेज़ को संबंधित सामग्री मानकर चुन ले
• हमलावर को सामग्री ऐसी बनानी होती है कि दस्तावेज़ के सीधे चुने जाने या search result में आने की संभावना बढ़े
• यह vulnerability Word के magic pen और Edit with Copilot दोनों पर लागू होती है

चरण 1: दस्तावेज़ में हेरफेर और शुरुआती replication

• शुरुआती proof of concept (PoC) में सिर्फ़ सफेद text में malicious prompt वाला दस्तावेज़ इस्तेमाल किया गया, जिससे पुष्टि हुई कि source material task से असंबंधित हो तब भी context में आने पर हमला चल सकता है
• PoC prompt दो हिस्सों में बना था
  • पहला हिस्सा target document में subtle बदलाव करता था, जैसे summary के अर्थ को हल्का मोड़ना या financial document के numbers बदलना
    • मुख्य बात यह थी कि Copilot इसे task-संबंधित वैध request समझे
    • परीक्षण के दौरान अर्थपूर्ण बदलावों को आँख से पहचानना कठिन था, इसलिए बदले हुए हिस्से highlight करने का निर्देश अलग से जोड़ना पड़ा
    • वास्तविक हमले में बदलाव highlight करने की ज़रूरत नहीं होती; सार्वजनिक उदाहरण में तुरंत दिखने के लिए financial numbers बदले गए
  • दूसरा हिस्सा attack prompt को output document में कॉपी करने का निर्देश देता था
    • इसे बाद के दस्तावेज़ों की source tracking के काम जैसा दिखाया गया, और readability सुधारने के बहाने अपनी छिपाने की विधि भी बताई गई
• Tfosorcim Ltd. नाम की काल्पनिक कंपनी के market analysis document के अंत में सफेद text में हमला जोड़ने पर, Copilot ने Q1 financial report के सभी numbers आधे कर दिए
• इसके बाद उसने पूरा malicious prompt परिणाम दस्तावेज़ के नीचे सफेद 8-point text में कॉपी कर दिया, और user को न तो number बदलने की बात बताई न prompt insert होने की
• यहाँ तक कि जब user ने malicious document सीधे attach नहीं किया और सिर्फ़ Tfosorcim Q1 report बनाने को कहा, तब भी Copilot ने OneDrive खोजकर दूसरे folder में पड़े malicious market analysis document को ढूँढ लिया और हमला सफल हुआ
• इस PoC में उस समय का नवीनतम model GPT-5.6 इस्तेमाल किया गया

चरण 2: बाद के दस्तावेज़ों में self-propagation

• संक्रमित Q1 report स्वयं नया attack vector बन जाती है, इसलिए अगली writing session में शुरुआती malicious document की ज़रूरत नहीं रहती
• Q1 report attach करके Q2 report बनाने पर Copilot ने फिर सभी financial numbers आधे किए और पूरे prompt को सफेद text में कॉपी कर दिया
• नया vector वैध internal resource से बना दस्तावेज़ होता है, इसलिए उसे internal documents वाला trust भी मिल जाता है
  • अगर पीड़ित दस्तावेज़ सहकर्मी को share करे और वह या उसका सहकर्मी इसे Copilot के writing या editing source के रूप में उपयोग करे, तो हमला नए दस्तावेज़ों में फैलता जाता है
• रिपोर्ट किए गए सभी PoC में Copilot ने दस्तावेज़ बदले और छिपे निर्देश कॉपी किए; और जब संक्रमित दस्तावेज़ बाद के context में डाला गया, तो मूल स्रोत के बिना भी हमला फिर चला

संगठन और सहयोगी वातावरण पर प्रभाव

• शुरुआती entry point पार कर चुके संक्रमित दस्तावेज़ अंदर सामान्य रूप से बने material जैसे दिखते हैं, और approved Copilot edit history भी नहीं दिखती, इसलिए attack tracing बहुत मुश्किल हो जाती है
• अगर यह सामान्य document workflow के ज़रिए चुपचाप फैलता है, तो संगठन के decision-making में उपयोग होने वाली जानकारी की विश्वसनीयता कमजोर पड़ सकती है
• संक्रमण से अनजान संगठन shared SharePoint site या Teams collaboration के ज़रिए दूसरे संगठनों तक दस्तावेज़ भेज सकते हैं
  • किसी संगठन का शुरुआती attack document पहले से संक्रमित किसी भरोसेमंद partner से भी आ सकता है
  • partner documents पर भरोसे के कारण user के उन्हें Copilot context में डालने की संभावना भी बढ़ती है
• अगर Copilot को Microsoft Cowork या Microsoft Scout जैसे ऐसे systems में और गहराई से जोड़ा जाए जो documents, tools और collaboration flow को अपने-आप बनाते और चलाते हैं, तो यही mechanism machine speed पर कहीं बड़े attack surface को प्रभावित कर सकता है

Microsoft के mitigations और बची हुई कमजोरियाँ

• Microsoft ने शुरुआती जमा किए गए PoC prompt को block किया और disclosure coordination अवधि में कई fixes जारी किए
  • रिपोर्ट किया गया specific payload block कर दिया गया, इसलिए बाद की reproduction में वही पुराना wording नहीं बल्कि बदला हुआ payload चाहिए था
  • series के part 1 और part 2 में बताई गई memory और email body attack paths को mitigate कर दिया गया
• लेकिन मूल दस्तावेज़ के निर्देश Copilot output बदलते हैं और बाद के दस्तावेज़ों में खुद को कॉपी करते हैं — यह vulnerability class अब भी बनी हुई है
  • request task या wording बदलने पर भी मूल कमजोरी और propagation pattern नहीं बदलता
  • जारी किए गए सभी mitigations लागू होने के बाद भी बदले हुए payload के साथ पूरा attack chain दोहराया गया
• यह समस्या मौजूदा LLM-आधारित systems की संरचनात्मक कमजोरी है, और समान उत्पादों में इस class को पूरी तरह रोकने का कोई पक्का तरीका नहीं दिखा
• यह single patch से हल होने वाली समस्या नहीं बल्कि आगे और research चाहने वाला मुद्दा है, हालांकि Microsoft के fixes ने exposure को व्यावहारिक रूप से कम किया है

disclosure status और user response

• MSRC और Microsoft product team को reproduction steps, video, environment assumptions और सटीक PoC prompt देकर disclosure coordinate किया गया
• शुरुआती 90-दिन की coordination window को दो बार बढ़ाकर कुल 144 दिन तक प्रतिक्रिया का इंतज़ार किया गया, फिर भी disclosure के समय हमला दोहराया जा सकता था
• model upgrades सहित दो mitigations के बाद भी पूरी vulnerability class नहीं रुकी, इसलिए specific payload की जगह attack type और propagation mechanism के स्तर पर disclosure किया गया
• disclosure के समय ग्राहकों के पास समस्या को पूरी तरह हल करने का तरीका नहीं था, लेकिन exposure घटाने के लिए ये कदम सुझाए गए
  1. Copilot में उपयोग होने वाले external-source documents को untrusted material की तरह मानें
  2. Copilot generation या editing शुरू करने से पहले attached documents की समीक्षा करें
  3. Copilot द्वारा बनाए या संपादित दस्तावेज़ों को reuse, share या distribute करने से पहले बारीकी से जाँचें

disclosure timeline

• 6 मार्च 2026: reproduction steps, video, environment assumptions और PoC prompt के साथ शुरुआती रिपोर्ट MSRC को भेजी गई
• 9 मार्च: MSRC ने रिपोर्ट स्वीकार की और case खोला
• 31 मार्च: Microsoft ने व्यवहार की पुष्टि की और product team ने mitigation पर काम शुरू किया
• 3 अप्रैल: नए Edit with Copilot experience के ज़रिए पहला mitigation जारी किया गया
• 9 अप्रैल: पुराने attack prompt के block होने की पुष्टि हुई, लेकिन financial numbers में हेरफेर करने वाले नए XPIA task से हमला दोहराकर अलग case के रूप में रिपोर्ट किया गया
• 10 अप्रैल: MSRC ने नया case स्वीकार किया और product team ने mitigation पर काम शुरू किया
• 8 जून: Microsoft के अनुरोध पर disclosure date को 15 जुलाई तक टाला गया
• 14 जुलाई: base model को GPT-5.5 में upgrade करने वाला दूसरा mitigation जारी किया गया
• 15 जुलाई: उस समय के नवीनतम model GPT-5.6 पर worm propagation सहित हमला दोहराने में सफलता मिली
  • नए mitigation के लिए समय देने हेतु disclosure को फिर 28 जुलाई तक टाला गया, और Microsoft सहमत हुआ
• 28 जुलाई: हमला लगातार दोहराया जा सकने की स्थिति में coordinated disclosure जारी किया गया

information integrity और source tracking

• जैसे-जैसे LLM business operations में शामिल हो रहे हैं, information integrity एक बड़ा security issue बन रहा है
• हमलावर-नियंत्रित सामग्री न केवल individual output में हेरफेर कर सकती है या data leakage करा सकती है, बल्कि सामान्य user workflow के साथ कॉपी होकर खुद फैल भी सकती है
• generated content में शामिल malicious instructions कई दस्तावेज़ों में बनी रहती हैं, वैध users उन्हें दोबारा distribute करते हैं, और वे नए context में फिर प्रवेश कर जाती हैं
  • इसके बाद हमला शुरुआती entry point नहीं बल्कि system के अंदर information flow का हिस्सा बन जाता है
• सामान्य generation और editing प्रक्रिया से बनी सामग्री में बाद में manipulation की origin पहचानना कठिन होता है, जिससे detection और response जटिल हो जाते हैं
• prompt injection को block करने से अलग, generated documents में source material की origin और model द्वारा किए गए edits को metadata में सुरक्षित रखना चाहिए
  • यह नियंत्रण injection को स्वयं नहीं रोकता, लेकिन traceability बढ़ा सकता है

मौजूदा LLM architecture की मूल समस्या

• AI assistant को उपयोगी होने के लिए email, documents, web pages, memory और tool output जैसी हमलावर-नियंत्रित जानकारी भी process करनी पड़ती है
• बाहरी जानकारी system instructions, user requests और अन्य trusted information के साथ उसी context window में जाती है और उसी computation में भाग लेती है
• LLM को तय करना होता है कि बाहरी content का अर्थ क्या है, वह relevant है या attack है; लेकिन जाँच के उस समय तक हमलावर के tokens पहले ही उस computation को प्रभावित कर चुके होते हैं
  • यानी जिस content की जाँच होनी है, वही जाँच की क्रिया में भी हिस्सा लेता है
  • model से XPIA detection करवाना कुछ वैसा है जैसे किसी interpreter से untrusted program चलवाकर उसी से उसकी safety तय करने को कहना
• अगर malicious content target model तक पहुँचने से पहले detect या remove भी कर दिया जाए, तो भी वही समस्या सिर्फ़ pipeline में आगे खिसकती है
  • LLM बहुत अलग-अलग अभिव्यक्तियों से भी अर्थ पुनर्निर्मित कर सकते हैं, इसलिए detector में भी वैसी ही अर्थ-पुनर्निर्माण क्षमता चाहिए
  • target LLM से कमजोर detector केवल सीमित expression space संभालता है, इसलिए ऐसी malicious अभिव्यक्तियाँ बची रहेंगी जिन्हें target समझ ले लेकिन detector छोड़ दे
• समान semantic processing क्षमता देने वाली सामान्य तकनीक फिर एक और LLM ही होती है; इसलिए सामने एक model और जोड़ने से हर attack की सफलता दर घट सकती है, लेकिन फिर हर defense model को भी बचाना पड़ेगा — यही LLMs all the way down समस्या है
• लंबी अवधि में ऐसी system design चाहिए जिसमें goal और intent उस information से स्वतंत्र हों जिसे process किया जा रहा है
  • मौजूदा LLM architecture में intent और interpretation को स्थिर रूप से अलग रखने का कोई तंत्र नहीं है
  • हमलावर की जानकारी सिर्फ़ model output ही नहीं, बल्कि उस task को भी प्रभावित कर सकती है जिसे model यह मानता है कि उससे करने को कहा गया है
• भरोसेमंद workflows में LLM को जोड़ने वाले systems को यह मानकर चलना चाहिए कि जैसे ही हमलावर-नियंत्रित content context में प्रवेश करेगा, कुछ अनुपात में compromise होगा

[GN⁺]

Hacker News की राय

• “ज़्यादा व्यापक vulnerability categories के लिए कोई मज़बूत mitigation नहीं है” — अब यह साफ़ लगता है कि जब तक commands और data का mixing बंद नहीं होगा, तब तक ऐसी समस्याएँ ठीक नहीं होंगी

  • इन models में शुरू से security vulnerabilities थीं, लेकिन users ज़्यादातर उनके असर की परवाह नहीं करते दिखते। खासकर AI agents को बिना किसी सीमा के system का पूरा access देना बहुत गंभीर समस्या है
    लगता है AI industry को सचेत होने के लिए और data leaks होने पड़ेंगे, और अगर किसी ने खुद को Anthropic या OpenAI के हवाले किया है तो उसे पता होना चाहिए था कि वह कौन-सा जोखिम ले रहा है, इसलिए ज़्यादा सहानुभूति होना मुश्किल है
  • यह सबसे बुरे तरीके से von Neumann architecture में वापसी जैसा है
  • अगर training data में command privilege levels शामिल किए जाएँ तो शायद इसे अधूरे रूप में हल किया जा सकता है। model खुद probabilistic और अस्पष्ट है, इसलिए इससे ज़्यादा की उम्मीद करना मुश्किल है
  • शक है कि अनंत तरह के content को संभालने वाले general intelligence systems में commands और data को वास्तव में अलग किया जा सकता है या नहीं
  • यह बात सही लगती है कि LLM architecture में इसे ठीक नहीं किया जा सकता, और अभी बड़े पैमाने पर उपयोग के लिए कोई प्रतिस्पर्धी विकल्प भी खास नहीं है
    यह सिर्फ commands और data को मिलाने की समस्या नहीं है; LLM boundaries को deterministic तरीके से अलग नहीं कर सकता, इसलिए boundary setting ज़्यादा से ज़्यादा मानसिक तसल्ली है और कुछ attacks को बस थोड़ा कठिन बनाती है। इस architecture में fatal trinity एक स्थायी समस्या है

• स्थिति बेहतर होने से पहले बहुत अधिक खराब होगी, और agents को जरूरत से ज़्यादा access देना हास्यास्पद है
  कल्पना कीजिए कि किसी लोकप्रिय GitHub repository में बिना code के सिर्फ “bug reproduce करो” वाला comment पोस्ट हो। वह credit cards या Bitcoin wallets चुरा सकता है, और GitHub account के ज़रिए दूसरी repositories तक self-propagate भी कर सकता है

  • ChatGPT से पहले जब AI के existential risk और containment पर चर्चा सुनता था, तो मुझे लगता था कि AI जो तर्क दे, उसे सिद्धांततः नज़रअंदाज़ किया जा सकता है, इसलिए उसे box से बाहर निकालना आसान होगा
    लेकिन बहुत से लोग AI की डरावनी ताकत के बावजूद box नहीं खोलते, बल्कि उसी ताकत की वजह से output आने से पहले ही box फाड़कर खोल देते हैं। इसलिए बस यही उम्मीद है कि recursive self-improvement वैसे काम न करे जैसा doomers ने सोचा था
  • “AI agents” में security का ‘स’ तक नहीं है

• यह गंभीर है कि externally shared documents में छिपे malicious commands, Copilot को Word documents बदलने और attack को नए documents तक फैलाने पर मजबूर कर सकते हैं

  • commands और data का mixing हमेशा बुरा विचार रहा है, और मुझे लगा था यह बात सब समझ चुके हैं
  • कुछ models दूसरे models की तुलना में अधिक robust हैं। मैंने image में steganography से छिपे commands को Opus-5 से execute कराने की कोशिश की, लेकिन reliably काम करने वाला payload ढूँढना बहुत कठिन था
  • externally shared documents में मौजूद गलत जानकारी, Copilot सहित हर agent system, LLM और human intelligence को Word या दूसरे programs, यहाँ तक कि कागज़ पर भी documents बदलने और errors को नए documents में फैलाने पर मजबूर कर सकती है
    बहुत से लोग अब भी flat Earth, या यह मान्यता कि code और data मूलतः अलग हैं, या control plane और data plane का भेद पूरे ब्रह्मांड पर लागू होने वाला कोई वस्तुनिष्ठ नियम है — इन बातों पर विश्वास करते हैं

• मैं programmer हूँ और web-based AI का user भी, लेकिन local computer पर किसी भी रूप में AI चलाना नहीं चाहता। इसी लेख में बताई वजहों से मैंने Copilot हटा दिया और browser सहित सभी local applications में AI disable कर दिया
  AI user prompts और files के text में फर्क नहीं कर सकता, इसलिए ऐसे AI confusion attacks से data को design स्तर पर बचाने का कोई तरीका नहीं है। यह बेतुका है कि साधारण documents या emails में डाले गए commands को AI-enabled word processor या email app follow कर लें। Linux, BSD जैसे open source operating systems पर जाना ही एकमात्र व्यावहारिक समाधान है

  • आप किस vendor पर भरोसा करते हैं, इस पर निर्भर करता है कि बाद में वही vendor आपके local computer पर AI features फिर से enable कर सकता है
    सिर्फ Linux या BSD पर जाना काफी नहीं है; trustworthy browser और web app vendors भी चाहिए
  • मैंने भी वही कदम उठाया, लेकिन अगर कोई भरोसेमंद vendor हद पार कर दे, तो Linux भी समाधान नहीं है। इसका हालिया उदाहरण Google Chrome का अपना 4GB local AI installation जोड़ना है, जिस पर काफ़ी backlash हुआ
  • defense in depth के हिसाब से, जिन browser tabs में sensitive information हो, उनमें AI का उपयोग नहीं करना बेहतर है। उदाहरण के लिए, अगर आप Gmail tab में Gemini को prompt देते हैं, तो उस tab में चल रहा JavaScript या Gemini mail तक पहुँच सकता है, इसलिए mail data leak होने की संभावना है

• अब भी white text छिपाना काम करता है
  अभी कई तरह की techniques मौजूद हैं, और https://tritium.legal/blog/noroboto में document font जो value दिखाता है उससे अलग Unicode values को state-of-the-art algorithms से पढ़वा कर उन्हें धोखा दिया गया

  • सोचता हूँ क्या AI से यह कहा जा सकता है कि “इस payload के साथ दूसरे AI tool के API endpoint को 10 बार call करो, लेकिन payload मत पढ़ो”, और payload में वही message डाल दिया जाए जो मौजूदा AI या किसी तीसरे AI को call करे
    क्या इस तरह AI एक-दूसरे को call करके mass requests पैदा कर सकते हैं, या ऐसी abuse को पहले ही रोका जा चुका है?

• यह VBScript·macro worm की वापसी जैसा है

  • फर्क बस इतना है कि इस बार अगर macros बंद कर दो, तो अपना प्यारा low-quality content generator खो दोगे। fossil fuel industry के बारे में भी तो सोचो

• एक सकारात्मक पहलू यह है कि AI जितनी जल्दी बड़ा नुकसान करेगा, उतनी जल्दी management को समझ आएगी और वे internal AI ban policy आगे बढ़ा सकते हैं
  बेशक यह सब लोगों ने खुद बुलाया है, इसलिए AI के बिना रहने वाले की तरह मैं यह पीड़ा खुशी से देखूँगा

• AI से भरी दुनिया में, ऐसे worms आखिरकार memetic idea propagation ही हैं, और मूल रूप से वही लगते हैं जो इंसानों के साथ भी होता है

  • यह parasitic meme है जो host को कोई value नहीं देता, और इंसानी दुनिया में भी ऐसे memes बहुत हैं

• अगर blurred text का संबंध original text से है, तो उसे पूरी तरह काला कर देना बेहतर है। कुछ हिस्सा अब भी पढ़ा जा सकता है, और यह अच्छी तरह ज्ञात है कि अधिकांश blur algorithms जानकारी को सही मायने में नष्ट नहीं करते