ऑपरेटरों के लिए Lolly

एक डिफ़ेंस-इन-डेप्थ सुरक्षा और इंटेलिजेंस रणनीति - जो संयोग से एक क्रिएटिव प्रोडक्शन प्लैटफ़ॉर्म भी है

यह वह ज़ीरो-ट्रस्ट संगठनात्मक इम्यून सिस्टम है जो आपके पहले से चल रहे कामकाज के इर्द-गिर्द लिपट जाता है - ताकि आपकी टीमों को हर दिन जिस रूटीन क्रिएटिव काम की ज़रूरत होती है, वह आपकी परिधि से बाहर लीक होने के बजाय उसके भीतर ही हो।

इसमें आपके लिए क्या है। आप वह व्यक्ति बनते हैं जिसने किसी ऐसी चीज़ को हाँ कहा जो सुरक्षित भी है और लोकप्रिय भी। आप एक ही कदम में एक एक्सफ़िल्ट्रेशन छेद बंद करते हैं, क्षमता हासिल करते हैं, और एक रिक्वेस्ट कतार मिटा देते हैं - वह दुर्लभ सुरक्षा जीत जो आपको कम नहीं, ज़्यादा पसंद किया जाने वाला बनाती है। क़ानूनी टीम की रात 3 बजे कोई कॉल नहीं आती, क्योंकि एम्बार्गोड फ़ाइलें या ग्राहक डेटा किसी अनजान वेब टूल में जा पहुँचा; आपके ज़िम्मे कम SaaS वेंडर, कॉन्ट्रैक्ट और ऑडिट रहते हैं; और एक पूरी तरह पुनरुत्पादनीय ऑडिट ट्रेल रहता है जिसकी ओर आप इशारा कर सकते हैं जब कोई पूछे। आप बेहतर नींद लेते हैं, और साथ ही कुछ दिन रोशन भी करते हैं।

Lolly कोई सेकंड-क्लास क्रिएटिव टूल नहीं है: यह प्रोडक्शन-क्वालिटी आउटपुट हर किसी के हाथ में रख देता है, और ब्रैंड-गाइडेड क्रिएशन अनुभव में इसका कोई सानी नहीं। इसे इतने बड़े पैमाने पर बाँटना जिस वजह से सुरक्षित है, वह वजह आर्किटेक्चरल है: कुछ भी ऐसा अपलोड नहीं होता जो आपने खुद न डाला हो, हर नतीजा पुनरुत्पादनीय है, और हर एक्सपोर्ट क्रिप्टोग्राफ़िक रिकॉर्ड की कई इंडस्ट्री-लीडिंग परतें साथ ले जा सकता है। कोई दस्तावेज़ आपकी डेस्क तक चाहे जिस रास्ते पहुँचा हो, आप उसकी पूरी प्रोवेनेंस देख सकते हैं, यह भी कि उसमें छेड़छाड़ हुई है या नहीं, और यह भी कि क्या आप उसे पिक्सेल-परफ़ेक्ट दोबारा बना सकते हैं।

आज यह कहाँ खड़ा है। Lolly की सुरक्षा विशेषताएँ डिज़ाइन से ही मज़बूत हैं, और इसके क्रिप्टोग्राफ़ी तथा फ़ाइल-पार्सिंग इंजन SUSE की एंटरप्राइज़-ग्रेड इन्फ़्रास्ट्रक्चर हार्डनिंग से गुज़र रहे हैं। नीचे बताए गए सील, ऑन-डिवाइस साइनिंग और एन्क्रिप्शन अभी वास्तविक और बचाव-योग्य हैं, और स्वतंत्र प्रमाणन की दिशा में परिपक्व हो रहे हैं - इसलिए जहाँ किसी कॉन्ट्रैक्ट में प्रमाणित आश्वासन की माँग हो, वहाँ उस प्रक्रिया के पूरा होने तक इन्हें डिफ़ेंस-इन-डेप्थ के रूप में तैनात करें।

रणनीतिक बढ़त

रूटीन क्रिएटिव काम जिस आम तरीक़े से होता है वह एक दायित्व-सतह है: बाहरी डिज़ाइन कॉन्ट्रैक्टरों को ईमेल की गई फ़ाइलें, दर्जन भर SaaS एडिटरों पर अपलोड किए गए ब्रैंड एसेट, "बस एक झटपट ग्राफ़िक बनाने" के लिए किसी अजनबी के वेब टूल में पेस्ट किया गया ग्राहक डेटा। इनमें से हर एक आपके नियंत्रण से बाहर जाता हुआ डेटा है।

Lolly इसे उलट देता है। जिस काम ने उन लीक को जन्म दिया - कोट कार्ड, लोकलाइज़्ड बैनर, इवेंट बैज, रिडैक्ट किया गया स्क्रीनशॉट - वह अब एक ऐसे टूल पर होता है जो कर्मचारी के अपने डिवाइस पर, आपके ब्रैंड के अनुसार, बिना किसी सर्वर के चलता है। आपने किसी जोखिम भरे वर्कफ़्लो के ऊपर एक नियंत्रण नहीं जोड़ा; आपने जोखिम भरे वर्कफ़्लो की जगह ऐसा वर्कफ़्लो रख दिया जिसमें शुरू से ही कोई एक्सफ़िल्ट्रेशन रास्ता है ही नहीं।

• कॉन्फ़िगरेशन आपका है। इंजन और शेल ओपन सोर्स हैं (MPL-2.0)। ऊपर से अपना ऑथ, टेलीमेट्री या CA जोड़ें; इसे होस्ट करें या न करें; पूरा फ़ीचर और लागत नियंत्रण आपके हाथ में रहता है, git-ट्रैक्ड, किसी SaaS डेटाबेस में बंद नहीं।
• गवर्नेंस डेटा हो सकती है, डैशबोर्ड नहीं। जब आपको वह नियंत्रण चाहिए, तो टूल कैटलॉग को एक Git रिपॉज़िटरी के रूप में प्रबंधित करें - पुल-रिक्वेस्ट समीक्षा ही ब्रैंड अनुमोदन बन जाती है, आपके कार्यबल तक पहुँचने वाले हर टेम्पलेट के पूरे ऑडिट ट्रेल और तुरंत रोलबैक के साथ। यह एक विकल्प है, बाध्यता नहीं: जिन टीमों को बस चीज़ें बनानी हैं, वे Layout Studio में अपने टूल खुद बनाती हैं और अपनी फ़ाइलें कैटलॉग में इनजेस्ट करती हैं, पूरी तरह ऐप के भीतर, git को छुए बिना। देखें अडॉप्शन और गवर्नेंस।
• गार्ड-रेल संरचनात्मक हैं। ब्रैंड की पाबंदियाँ टेम्पलेट में हार्ड-कोड की गई हैं, ऐसे दिशानिर्देशों के रूप में प्रकाशित नहीं जिन्हें लोग नज़रअंदाज़ कर सकें। ग़लत आउटपुट को हतोत्साहित नहीं किया जाता - वह बन ही नहीं सकता।

कंटेंट को फैलाते हुए रिक्वेस्ट कतार को मिटाइए।

Lolly का एक लक्ष्य डिज़ाइन-रिक्वेस्ट डिफ़्लेक्शन है: ऐसी रूटीन रिक्वेस्ट जिन्हें कभी किसी डिज़ाइनर तक पहुँचने की ज़रूरत ही नहीं पड़ती, क्योंकि जिस व्यक्ति को एसेट चाहिए था उसने उसे खुद, सही ढंग से, मिनटों में बना लिया। हर डिफ़्लेक्ट हुआ टिकट एक प्रोडक्टिविटी जीत भी है और हाथ बदलने वाली एक फ़ाइल कम भी।

Lolly इस तरह बनाया गया है कि वह आपके संगठन के वास्तविक कामकाज के ढंग में फ़िट हो - इसे तैनात करने का कोई एक ही सही तरीक़ा नहीं है:

• डिप्लॉय करें, सर्व नहीं। अपने मौजूदा MDM (Intune, Jamf, Munki…) के ज़रिए Lolly को डिवाइसों तक पहुँचाएँ। यह डेस्कटॉप/मोबाइल ऐप या ऑफ़लाइन PWA के रूप में लोकली चलता है - किसी भी फ़ायरवॉल के पीछे, किसी भी एयर-गैप्ड परिवेश में काम करता है, न कोई सर्वर संभालना पड़ता है और अपडेट की रफ़्तार IT के नियंत्रण में रहती है।
• केवल सर्व करें। अपने नेटवर्क के भीतर (या किसी VPN के पीछे) एक इंस्टेंस चलाएँ; उपयोगकर्ता उस तक ब्राउज़र में पहुँचते हैं, कुछ भी इंस्टॉल नहीं। टूल एक बार प्रकाशित करें, वह तुरंत सबके पास होता है; एक्सेस नियंत्रण के लिए अपने IdP के साथ जोड़ें।
• हाइब्रिड। ऑफ़लाइन फ़ील्ड काम के लिए लोकल ऐप, उधार की मशीनों के लिए हमेशा-ताज़ा ब्राउज़र संस्करण - दोनों एक ही टूल लाइब्रेरी की ओर इशारा करते हुए।

पूरे डिप्लॉय मॉडल और प्रशासन की वॉकथ्रू डिप्लॉयमेंट और कॉन्फ़िगरेशन में हैं।

एंटी-एक्सफ़िल्ट्रेशन यूटिलिटी

Lolly टूल्स की एक श्रेणी - प्राइवेसी यूटिलिटी - फ़ाइलों को परिधि के भीतर रखने के लिए ख़ास तौर पर मौजूद है।

• छिपा डेटा हटाएँ

दस्तावेज़ों और मीडिया फ़ाइलों से लोकेशन और सारी छिपी पहचान बताने वाली जानकारी हटाएँ।

• टेक्स्ट हेल्पर

संरचित और असंरचित टेक्स्ट को एनोनिमाइज़, एनकोड, फ़ॉर्मैट और मैनिपुलेट करें।

• PDF कंप्रेस करें

किसी बड़े आकार की PDF को ऑन-डिवाइस छोटा करें, ताकि फ़ाइल ईमेल के लिए बहुत बड़ी होते ही कोई भी थर्ड-पार्टी "PDF कंप्रेस करो" वेबसाइट की ओर हाथ न बढ़ाए - जो ठीक वही जगह है जहाँ से डेटा खिड़की के बाहर फिसल जाता है।

ये सभी ऑन-डिवाइस ट्रांसफ़ॉर्म हैं: आपकी फ़ाइल या डेटा अंदर जाता है, साफ़ किए हुए बाइट बाहर आते हैं, और अपलोड करने के लिए कोई सर्वर है ही नहीं। ये उस आम "साफ़ करने के लिए अपनी फ़ाइल किसी अजनबी की वेबसाइट पर अपलोड करें" वाले टूल के जानबूझकर उलट हैं, जिसकी ओर एक नेकनीयत कर्मचारी वरना हाथ बढ़ाता है।

Text Helper फ़ाइलों की जगह टेक्स्ट के लिए वही सौदा है। यह वही टैब वाली वर्कबेंच है जिसे कोई कर्मचारी वरना किसी अजनबी की साइट पर ढूँढने जाता, और यह एक भी इनपुट घोषित नहीं करता, क्योंकि जिस चीज़ को यह छूता है वह कभी पेज से बाहर नहीं जाती।

Compress PDF इस सेट को पूरा करता है: बड़े आकार का अटैचमेंट आपकी चुनी हुई क्वालिटी सेटिंग के हिसाब से छोटा हो जाता है — उसी मशीन पर, जिसमें वह पहले से मौजूद है।

डिटरमिनिज़्म और पुनरुत्पादनीयता

हर टूल इनपुट URL पैरामीटर के रूप में व्यक्त किया जा सकता है, और एक जैसे इनपुट एक जैसी फ़ाइल बनाते हैं। इसके ऑपरेटर के लिए दो नतीजे हैं:

• URL ही आर्टिफ़ैक्ट है। लिंक को कमिट करें, ज़रूरत पड़ने पर एसेट दोबारा जनरेट करें - Git में कोई बाइनरी चेक-इन नहीं, चैट में "लेटेस्ट वर्ज़न" का पीछा नहीं। एसेट और टूल ID स्थायी अनुबंध हैं, इसलिए आज बना लिंक बाद में भी काम करता है।
• CLI वही रेंडर पथ है जो GUI का है, इसलिए बिल्ड पाइपलाइन और ऐप कभी अलग नहीं पड़ते। OG इमेज, सोशल कार्ड और डेटा विज़ुअल बिल्ड के समय, पुनरुत्पादनीय ढंग से जनरेट करें।

Prompt to Image डिटरमिनिज़्म का सबसे सादा रूप है: टेक्स्ट ही पूरा इनपुट है, टाइपसेट की गई इमेज ही पूरा आउटपुट, और एक ही टेक्स्ट हमेशा एक ही तरह टाइपसेट होता है।

प्रोवेनेंस और Content Credentials

एक्सपोर्ट Content Credentials साथ ले जा सकते हैं - फ़ाइल के बाइट के हैश से बँधा एक हस्ताक्षरित C2PA मैनिफ़ेस्ट। फ़ाइल में बाद में किया गया कोई भी बदलाव सील तोड़ देता है, इसलिए C2PA-समझने वाला वेरिफ़ायर छेड़छाड़ का पता क्रिप्टोग्राफ़िक ढंग से, ऑफ़लाइन लगाता है। यह क्रेडेंशियल टैम्पर-एविडेंट है: यह छेड़छाड़ को रोकने के बजाय उसे उजागर करता है, और ठीक यही बात पूरी तरह ऑफ़लाइन सत्यापन को संभव बनाती है।

• डिफ़ॉल्ट रूप से चालू, ऑन-डिवाइस। साइनिंग कुंजी डिवाइस पर ही जनरेट होती है, निकाली नहीं जा सकती (खुद Lolly भी उसे पढ़ नहीं सकता), और साइनिंग लोकली होती है - केवल वैकल्पिक पहचान एनरोलमेंट ही कभी नेटवर्क को छूता है।
• ट्रस्ट स्तर। बिना एनरोलमेंट वाला एक्सपोर्ट संरचनात्मक रूप से वैध होता है लेकिन अनाम रूप से हस्ताक्षरित (untrusted)। एक सत्यापित पहचान एनरोल करें (Lolly CA से मिला अल्पकालिक सर्टिफ़िकेट, एक ईमेल से जुड़ा) और Lolly रूट को पिन करने वाले वेरिफ़ायर trusted + हस्ताक्षरकर्ता का ईमेल रिपोर्ट करते हैं। एक विश्वसनीय टाइमस्टैम्प अथॉरिटी और थर्ड-पार्टी-वैलिडेटर ग्रीन (C2PA कन्फ़ॉर्मेंस) रोडमैप पर हैं। हर स्तर स्पष्ट है, और कोई फ़ाइल सिर्फ़ उतने ही भरोसे का दावा करती है जितना वह साबित कर सकती है।
• क्रेडेंशियल की अवधि साइनिंग के समय ऑपरेटर/उपयोगकर्ता का फ़ैसला है: 7 / 30 / 90 / 365 दिन, डिफ़ॉल्ट 30।
• Lolly Imprint. एक दूसरा, पूरक संकेत जो डिफ़ॉल्ट रूप से चालू है: रास्टर एक्सपोर्ट में पका हुआ एक अदृश्य पिक्सेल वॉटरमार्क (और PDF/PPTX के भीतर Lolly-रेंडर किए गए रास्टर में भी, कभी उपयोगकर्ता की अपनी एम्बेड की गई इमेज में नहीं)। जहाँ क्रेडेंशियल किसी भी कंटेनर बदलाव पर मर जाता है, वहाँ Imprint री-सेव या स्क्रीनशॉट के बाद भी बचा रहता है - एक टिकाऊ "ये पिक्सेल Lolly से होकर गुज़रे" संकेत, केवल उपस्थिति-सूचक, कोई व्यक्तिगत डेटा नहीं। यह सिक्योरिटी-थ्रू-ऑब्स्क्योरिटी है, कोई सख़्त बचाव नहीं, और यह क्रेडेंशियल की जगह लेने के बजाय उसे पूरक बनाता है। imprint=0 से इसे बंद किया जा सकता है।
• Durable Content Credentials (ऑप्ट-इन)। एक रास्टर एक्सपोर्ट अतिरिक्त रूप से एक अदृश्य durable मार्क साथ ले जा सकता है जो एक सॉफ़्ट-बाइंडिंग आइडेंटिफ़ायर एन्कोड करता है, ताकि सोशल अपलोड या री-सेव से फ़ाइल का मेटाडेटा हट जाने के बाद भी C2PA क्रेडेंशियल दोबारा हासिल किया जा सके - वह स्थिति जहाँ एक सामान्य क्रेडेंशियल खो जाता। यह केवल रास्टर के लिए है और इसकी क़ीमत एक न्यूरल-एनकोड पास है, इसलिए यह डिफ़ॉल्ट रूप से बंद रहता है (इसे चालू करने के लिए durable=1)। Lolly आज अपने ही durable मार्क को /verify पर ऑफ़लाइन पहचान लेता है; थर्ड-पार्टी टूल (जैसे Adobe) से रिकवरी इंडस्ट्री का सॉफ़्ट-बाइंडिंग रेज़ॉल्यूशन तय होते ही उपलब्ध होगी।
• सत्यापन ऑन-डिवाइस होता है। कोई भी फ़ाइल /verify पर डालें (या lolly validate <file> चलाएँ) और एक ऑफ़लाइन रिपोर्ट पाएँ कि क्या वह वाक़ई Lolly से बनी है और तब से अपरिवर्तित है। वेब Verify व्यू AI-जनरेटेड कंटेंट को भी फ़्लैग करता है, Lolly Imprint का पता लगाता है, SEAL हस्ताक्षरों को सत्यापित करता है (DNS में कुँजीबद्ध एक बाइट-स्तरीय हस्ताक्षर - जिसमें एकमात्र नेटवर्क स्पर्श एक DNS कुँजी लुकअप है, कभी फ़ाइल नहीं), वैकल्पिक रूप से थर्ड-पार्टी पिक्सेल वॉटरमार्क के लिए डीप-स्कैन करता है (एक बार का ऑन-डिवाइस मॉडल डाउनलोड), और छिपे डेटा को उजागर करता है - यह सब फ़ाइल अपलोड किए बिना। देखें Content Credentials पहचान।

इंटरऑपरेबिलिटी नोट। Lolly आज अपने क्रेडेंशियल और कई थर्ड-पार्टी क्रेडेंशियल ऑफ़लाइन सत्यापित करता है, जिसमें अन्य निर्माताओं के C2PA क्लेम v2 मैनिफ़ेस्ट पढ़ना भी शामिल है। एक इंटरऑप आइटम अभी प्रगति पर है: WebM - जिसके लिए अभी कोई मानकीकृत C2PA मैपिंग नहीं है, इसलिए Lolly मैनिफ़ेस्ट को एक Matroska हिस्से के रूप में जोड़ता है (थर्ड-पार्टी टूल Lolly की MP4 को सीधे बॉक्स से बाहर सत्यापित कर लेते हैं; मानक तय होते ही WebM भी इसके साथ आ जाएगा)।

एन्क्रिप्शन और पासवर्डिंग

जिन फ़ाइलों को लॉक होकर सफ़र करना है, उनके लिए सब कुछ ऑन-डिवाइस होता है:

• PDF ओपन-पासवर्ड - Standard एक 40-बिट RC4 निवारक है (कहीं भी खुलता है, लिंक में जा सकता है); Strong AES-256 है (PDF 2.0), जो एक्सपोर्ट के समय टाइप किया जाता है और कभी लिंक में नहीं रखा जाता।
• लॉक किए हुए डाउनलोड - कोई ZIP, कोई Projects फ़ोल्डर, या कोई बैच रन पूरा का पूरा लॉक किया जा सकता है: Standard ZipCrypto (कमज़ोर, सर्वव्यापी) या Strong AES-256 (WinZip AE-2)। डिफ़ेंस-इन-डेप्थ: Strong ज़िप के भीतर की हर PDF भी अलग से AES-256-लॉक होती है, इसलिए अनपैक होने के बाद भी वह लॉक रहती है।
• पासवर्ड-गेटेड शेयर लिंक - पूरा लिंक स्टेट PBKDF2-व्युत्पन्न कुंजी के तहत AES-256-एन्क्रिप्टेड होता है; केवल साइफ़रटेक्स्ट सफ़र करता है, पासवर्ड कभी लिंक में नहीं होता, और डिक्रिप्शन प्राप्तकर्ता के ब्राउज़र में होता है।

एयर-गैप के लिए तैयार

एयर-गैप एक फ़र्स्ट-क्लास डिप्लॉयमेंट है, कोई विशेष मोड नहीं - Lolly रेंडर के समय बिना किसी नेटवर्क के, आउट ऑफ़ द बॉक्स चलता है। वेब शेल एक ऑफ़लाइन-फ़र्स्ट PWA है (सर्विस वर्कर); फ़ॉन्ट और WASM ऑन-डिवाइस संग्रहीत रहते हैं; टूल स्टेट होस्ट ब्रिज के ज़रिए लोकली सहेजा जाता है, कभी localStorage में नहीं। जो भी टूल नेटवर्क तक पहुँचता है, वह केवल एक अनुमति-सूचीबद्ध host.net क्षमता के ज़रिए ऐसा करता है जिसे उसे अपने मैनिफ़ेस्ट में घोषित करना पड़ता है - जो शेल इसे पूरा नहीं कर सकता (या नहीं करना चाहता) वह उसे स्टब कर देता है। शेल को अपने MDM के ज़रिए डिवाइसों तक पहुँचाएँ, या अपने नेटवर्क के भीतर एक इंस्टेंस सर्व करें - और एक पूरी तरह एयर-गैप्ड इंस्टॉल रेंडर, एक्सपोर्ट, एन्क्रिप्ट और क्रेडेंशियल सत्यापन सब करता है, बिना किसी को फ़ोन-होम किए।

जानने लायक बातें

रोलआउट से पहले कुछ बातें साफ़ रखना ठीक रहेगा:

• हार्डनिंग प्रगति पर है। क्रिप्टोग्राफ़ी और पार्सर SUSE की एंटरप्राइज़-स्तरीय हार्डनिंग से गुज़र रहे हैं (ऊपर देखें) - आज डिज़ाइन से ही मज़बूत; जहाँ कॉन्ट्रैक्ट में प्रमाणित आश्वासन की माँग हो, वहाँ डिफ़ेंस-इन-डेप्थ के रूप में तैनात करें।
• *टूल हुक कोई सुरक्षा सैंडबॉक्स नहीं हैं। किसी टूल की वैकल्पिक hooks.js होस्ट ब्रिज इंजेक्ट होकर चलती है, लेकिन ब्राउज़र शेल में वह पेज के रेल्म में चलती है और window/document/fetch तक पहुँच सकती* है। टूल कोड के साथ वैसा ही बर्ताव करें जैसा आप किसी भी चलाए जाने वाले कोड के साथ करते हैं - उसकी समीक्षा करें। इसीलिए साझा कैटलॉग चलाने वाला संगठन उसे Git समीक्षा से गेट कर सकता है; दोनों ही सूरतों में, Worker आइसोलेशन आने तक केवल वही टूल चलाएँ जिनकी आपने समीक्षा की है।
• Content Credentials टैम्पर-एविडेंट हैं। वे छेड़छाड़ को रोकते नहीं, उसका पता लगाते हैं - ऊपर इंटरऑपरेबिलिटी नोट देखें।
• एन्क्रिप्शन के दो स्तर। Standard लॉक झटपट, सर्वव्यापी निवारक हैं; Strong (AES-256) पूरी सुरक्षा है - किसी भी संवेदनशील चीज़ के लिए Strong चुनें, यह ध्यान रखते हुए कि उसे आधुनिक रीडर चाहिए।

आगे कहाँ जाएँ

• अडॉप्शन और गवर्नेंस - पर्सोना, डिफ़्लेक्शन मीट्रिक, और गवर्नेंस-ऐज़-डेटा पूरे विस्तार से।
• डिप्लॉयमेंट - डिप्लॉय/सर्व/हाइब्रिड, MDM, और सेवाओं की सेल्फ़-होस्टिंग।
• कॉन्फ़िगरेशन - प्रोफ़ाइल, ब्रैंड पैक, क्षमता गेटिंग, और फ़ीचर फ़्लैग।
• प्राइवेसी नीति - औपचारिक "कुछ भी इकट्ठा नहीं करता, कुछ भी अपलोड नहीं करता" वक्तव्य।