स्क्रीनशॉट, ईमेल और फ़ाइल तारीख़ें: आपका सामान्य प्रमाण क्यों विफल होता है

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

स्क्रीनशॉट

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

ईमेल

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

फ़ाइल की अपनी तारीख़

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

मूल फ़ाइल का होना भी इसे हल नहीं करता

एक आम प्रवृत्ति यह मान लेना है कि स्वामित्व मामला सुलझा देता है: फ़ाइल अब भी मेरे पास है, तो मैंने ही बनाई होगी। स्वामित्व यह साबित करता है कि आज आपके पास एक प्रति है। यह इस बारे में कुछ नहीं कहता कि वह प्रति, या उसका कोई पहले का संस्करण, पहली बार कब अस्तित्व में आया, क्योंकि आपकी अपनी ड्राइव पर मौजूद फ़ाइल अपने इतिहास का कोई स्वतंत्र रिकॉर्ड साथ नहीं रखती। फ़ाइल और उसकी उम्र का दावा दोनों एक ही स्रोत से आते हैं, और यही वह कमज़ोरी है जिसे कोई विवाद उजागर करता है।

चारों के पीछे का पैटर्न

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

योग्य टाइमस्टैम्प अलग क्या करता है

योग्य इलेक्ट्रॉनिक टाइमस्टैम्प किसी फ़ाइल का वर्णन नहीं करता। यह क्रिप्टोग्राफ़िक रूप से किसी फ़ाइल से बंधा होता है। फ़ाइल के ठीक-ठीक बाइट्स से एक हैश निकाला जाता है, और कोई योग्य ट्रस्ट सेवा प्रदाता उस हैश पर टाइमस्टैम्प जारी करता है, न कि किसी फ़ाइल नाम, फ़ोल्डर पथ या लिखित विवरण पर। दस्तावेज़ में एक अक्षर बदलिए और हैश मेल खाना बंद कर देता है, इसलिए बाद में इस पर कोई अस्पष्टता नहीं रहती कि कौन-सा संस्करण सील किया गया था।

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

यह अंतर्निहित अधिकार नहीं बनाता, और यहां सटीक होना ज़रूरी है। बर्न कन्वेंशन के तहत, कॉपीराइट किसी कृति के निर्माण के क्षण ही स्वतः उत्पन्न हो जाता है, 180 से अधिक देशों में, बिना किसी पंजीकरण या औपचारिकता के। टाइमस्टैम्प वह सुरक्षा प्रदान नहीं करता, और उसे करने की ज़रूरत भी नहीं। यह जो देता है वह इस बात का प्रमाण है कि किसी ख़ास फ़ाइल का कोई ख़ास संस्करण कब मौजूद था, और यही वह ठीक सवाल है जिसका जवाब कोई स्क्रीनशॉट, कोई ईमेल, या किसी फ़ाइल की अपनी तारीख़ नहीं दे सकती जैसे ही कोई व्यक्ति जो कमरे में नहीं था, सीधे यह सवाल पूछता है।

असली सवाल के सामने क्या टिकता है

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

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

अदालत के कमरे से परे

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

अभिलेख के बजाय आदत बनाना

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