- कैलिफ़ोर्निया में सिक्योरिटी डिपॉज़िट को 21 दिनों के भीतर लौटाने और move-out से पहले inspection notice देने की बाध्यता का पालन नहीं होने से विवाद पैदा हुआ, और लीज़ एग्रीमेंट में मकान मालिक की जानकारी न होने के कारण पहले एजेंसी (International Executive Rentals) के साथ संवाद होने लगा
- एजेंसी ने दावा किया कि वह डिपॉज़िट अपने पास नहीं रखती, और कॉन्ट्रैक्ट की कॉपी भेजी; लेकिन उस दस्तावेज़ में "डिपॉज़िट IER trust account में रखा जाएगा" वाला मुख्य पाठ और अतिरिक्त धारा (Addendum) आपस में टकरा रहे थे, जिससे संदेह पैदा हुआ
- सिग्नेचर प्लेटफ़ॉर्म RightSignature द्वारा जोड़े गए authentication page का checksum एक जैसा था, लेकिन PDF metadata analysis में modification time·ID tag (ID0/ID1) के अंतर और timezone mismatch मिला, जिससे बाद में edit किए जाने के संकेत सामने आए
- PDF की internal structure को तोड़कर और compare करने पर, page 3 पर 'touchUp_TextEdit' tag और font naming rule में बदलाव, और signature insertion के समय इस्तेमाल किए गए Courier font के नाम में बदलाव मिला, जिससे signature के बाद editing का सबूत देने वाले संकेत मिले
- developer tools से base.pdf original और 'Original checksum' के match की पुष्टि करने पर अतिरिक्त धारा मौजूद नहीं थी, और screen sharing के दौरान भी upload date और Draft/Completed की दोहरी entries दिखीं, जो छेड़छाड़ की संभावना की ओर मजबूत संकेत देती हैं
घटना की पृष्ठभूमि और कानूनी संदर्भ
- अल्पकालिक किरायेदारी होने के बावजूद कैलिफ़ोर्निया के tenant protection rules लागू होते हैं, इसलिए डिपॉज़िट लौटाने की समयसीमा 21 दिन और move-out से पहले inspection notice देने की बाध्यता मौजूद है
- डिपॉज़िट रखने और लौटाने की ज़िम्मेदारी मकान मालिक की होती है; एजेंसी कानूनी रूप से ज़िम्मेदार पक्ष नहीं है
- कॉन्ट्रैक्ट में मकान मालिक का नाम और पता गायब होने से एजेंसी के ज़रिये notice serve करने की स्थिति बनी
- एजेंसी के प्रतिनिधि ने ईमेल में कहा, "डिपॉज़िट हम अपने पास नहीं रखते," लेकिन संलग्न कॉन्ट्रैक्ट में IER द्वारा रखे जाने वाला वाक्य और Addendum में 'मकान मालिक द्वारा रखे जाने' का उल्लेख साथ-साथ था, जो परस्पर विरोधी है
विवादित दस्तावेज़ और टकराती धाराएँ
- मुख्य धारा: "security (deposit)… IER Trust Account में रखा जाएगा" जैसी संस्था द्वारा रखे जाने की भाषा मौजूद है
- पेज के नीचे checkbox क्षेत्र: Addendum 1 में "डिपॉज़िट मकान मालिक रखेगा" वाला वाक्य checked दिखता है
- लेखक के पास मौजूद कॉपी में Addendum 1 खाली है, जबकि एजेंसी की कॉपी में यह checked और भरा हुआ है
फॉरेंसिक 1: PDF metadata की तुलना
- टूल: pdftk dump_data से CreationDate/ModDate और ID0/ID1 निकाले गए
- लेखक की कॉपी: creation और modification time एक जैसे, UTC, और ID0=ID1
- एजेंसी की कॉपी: creation time समान, लेकिन modification time हाल के सोमवार का, PDT के साथ, और ID0 समान लेकिन ID1 अलग
- व्याख्या: ID0 शुरुआती creation पर दिया जाता है और अपरिवर्तित रहता है, जबकि ID1 modification पर बदलने की प्रथा होती है; इससे एक ही original पर बाद में बदलाव किए जाने के संकेत मजबूत होते हैं
फॉरेंसिक 2: page-level structure की तुलना
- टूल: pdfalyzer से objects को तोड़कर diff किया गया
- अंतर केवल page 3 पर केंद्रित था, बाकी पेजों की संरचना समान थी
- page 3 पर "touchUp_TextEdit" tag मौजूद था, जिससे Acrobat edit trace की पहचान हुई
- संभावित आपत्ति: यह signature से पहले की editing, जैसे मकान मालिक का नाम जोड़ना, भी हो सकती थी; इसलिए और निर्णायक संकेत की ज़रूरत थी
फॉरेंसिक 3: font naming rule और signature timing का पता लगाना
- अधिकांश पेजों के fonts एक समान naming rule का पालन करते हैं, लेकिन विवादित page 3 को ही Acrobat शैली में rename किया गया था
- RightSignature ने signing complete होने पर जो Courier font डाला, उसका नाम पूरे दस्तावेज़ में एक जैसा है, लेकिन page 3 पर ही बदले हुए rule से दिखता है
- Courier केवल signature के बाद मौजूद होता है, इसलिए page 3 पर font renaming का मतलब signature के बाद editing है
फॉरेंसिक 4: signature से पहले की original file हासिल करना
- RightSignature viewer network tab (F12) में base.pdf को देखा और डाउनलोड किया गया
- उसका sha256sum authentication page के Original checksum से पूरी तरह मेल खाता था, और उसमें Addendum मौजूद नहीं था
- निर्णायक सबूत: authentication page की design सीधे verification की अनुमति न देने के बावजूद, platform के internal original और checksum match के आधार पर साबित हुआ कि additional clause original में नहीं थी
एजेंसी का दावा और अतिरिक्त परिस्थितियाँ
- एजेंसी: "RightSignature हर download पर फिर से seal करता है, इसलिए यह बदलाव जैसा दिखता है" — ऐसा दावा किया गया
- metadata में timezone·ID1 बदलाव, सिर्फ page 3 तक सीमित structural difference, और signature के बाद font naming change इस दावे से मेल नहीं खाते
- screen sharing के दौरान दिखा: "Uploaded: 09/22/25", Send for signature button, और Draft/Completed की दो entries
- Completed document में Addendum नहीं था, जबकि Draft document में Addendum शामिल होने के संकेत मिले
संभावित मंशा और जोखिम
- अनुमान: एजेंसी ने "IER द्वारा रखा गया" वाली भाषा से डिपॉज़िट लौटाने की ज़िम्मेदारी की संभावना समझने के बाद, बाद में Addendum जोड़ने की कोशिश की हो सकती है
- नतीजतन, सिविल स्तर पर छोटे संभावित दायित्व से बचने की कोशिश में document forgery जैसे हालात पैदा होने का जोखिम सामने आया
- भले ही अंतिम कानूनी ज़िम्मेदारी मकान मालिक की हो, दस्तावेज़ से छेड़छाड़ अपने आप में अलग कानूनी जोखिम पैदा कर सकती है
व्यावहारिक संकेत और response tips
- electronic signature platform इस्तेमाल करते समय, signing के तुरंत बाद original (base.pdf) और checksum को offline सुरक्षित रखना और भी महत्वपूर्ण हो जाता है
- PDF forensic points
- Creation/Modification timestamps के timezone और synchronization की जाँच
- ID0/ID1 की तुलना से modification history का अनुमान
- page-wise object diff, edit tags (touchUp_TextEdit), और font naming rule changes का पता लगाना
- "platform फिर से seal करता है" जैसे दावे का जवाब platform original और authentication checksum के cross-verification से दिया जा सकता है
- developer tools के network tab से signature से पहले का original हासिल करना निर्णायक साबित हो सकता है
1 टिप्पणियां
Hacker News टिप्पणियाँ
कैलिफ़ोर्निया के High Technology Theft Apprehension and Prosecution Program, FBI के Internet Crime Complaint Center, सैन फ्रांसिस्को के Financial Crimes Unit आदि से संपर्क करने की सलाह दी गई, RightSignature को Citrix ने अधिग्रहित किया था इसलिए Citrix को भी सूचित करने पर विचार किया जा सकता है, तथ्य स्पष्ट रूप से आपके पक्ष में हैं इसलिए वकील की फीस के बिना भी सफलता की संभावना काफ़ी अधिक है, हर्जाने का दावा भी संभव होगा (High Technology Theft Apprehension and Prosecution Program, Internet Crime Complaint Center, Financial Crimes Unit, Citrix अधिग्रहण संबंधी लेख, Citrix GC जानकारी)
इसकी आपराधिक मामला होने की संभावना अधिक है, राज्य सीधे दंड प्रक्रिया चलाएगा, और अतिरिक्त रूप से दीवानी मुकदमा भी किया जा सकता है, वकील रखने पर थोड़ा समय लग सकता है लेकिन अलग से खर्च किए बिना भी पर्याप्त उचित मुआवज़ा मिल सकता है, और सज़ा दिलाने के लिहाज़ से भी यह महत्वपूर्ण है
अगर यह एक व्यक्ति के साथ हुआ है, तो संभव है कि यह और भी बहुत लोगों के साथ हुआ हो, पर्याप्त जाँच होने पर class action भी संभव लगती है
इसलिए महत्वपूर्ण दस्तावेज़ तीन प्रतियों में होने चाहिए — हर पक्ष के लिए एक-एक, और notarization करने वाले के पास तीसरी कॉपी होनी चाहिए, document signing service यही भूमिका निभाती है, और बहुत दुर्लभ मामलों में यह गवाही देनी पड़ सकती है कि असली प्रति किसके पास है, मैं जब इसी तरह की एक कंपनी में काम करता था तब मैंने केवल 1 signature dispute का मामला सुना था, और उसमें सामग्री को लेकर विवाद नहीं था, hash कैसे काम करता है यह मुझे भले स्पष्ट हो, लेकिन जज तकनीकी बात न समझ पाए, इसलिए अंततः कंपनी को आधिकारिक रुख बताना ही होगा
तीन प्रतियों की यह परंपरा कम से कम 14वीं सदी के indenture contracts से चली आ रही है, “indenture” शब्द आरी-दाँत जैसी कटी हुई किनारी से आया है, दस्तावेज़ हाथ से तीन बार लिखा जाता था, फिर पूरी तरह हस्ताक्षर के बाद काटा जाता था, इससे नकल बनाना कठिन हो जाता था, और बीच में बड़े Latin अक्षर लिखे जाते थे ताकि जालसाज़ी और कठिन हो, अगर दो प्रतियाँ मेल न खाएँ तो कोई झूठ बोल रहा है, तीसरी प्रति को notarization office में रखा जाता था ताकि सच कौन बोल रहा है यह तय किया जा सके, indentured servant contracts भी इसी तरह होते थे
यही वजह है कि RightSignature कोई सस्ती self-hosted सेवा नहीं बल्कि महँगी SaaS service है, इसका मूल काम ऐसा third party उपलब्ध कराना है जो गवाही दे सके कि किसने किस version पर हस्ताक्षर किए
तीन प्रतियों की इस परंपरा के बारे में अब जाकर सुनकर मेरी जिज्ञासा शांत हुई, अब तक व्यस्तता में इसे खोज नहीं पाया था
मुझे Gwern की पुरानी पोस्ट याद आई जिसमें वह सोच रहा था कि लोग ऐसा ज़्यादा बार करने की कोशिश क्यों नहीं करते (Gwern ब्लॉग: PDF forgery पर विचार)
मुझे लगता है OP का यह मामला उसी सवाल का प्रमाण है, यह चौंकाने वाला है कि forgery authentication service के ज़रिए हुई, और इस स्थिति की ठीक से जाँच करके साबित करने के लिए software और forensics की गहरी समझ रखने वाले व्यक्ति को बहुत सारी verification प्रक्रियाओं से गुजरना पड़ता है, और अभी भी न तो settlement हुआ है न conviction, Craig Wright वाले मामले की तरह साधारण edits और backdating साबित करने के लिए भी भारी expert forensics चाहिए, जबकि मूल PDF को बदलना कोई शुरुआती व्यक्ति भी 5 मिनट में कर सकता है
लगता है Gwern का ध्यान public documents जैसे research paper PDFs की forgery पर था, उस मामले में तो एक बिल्कुल नया PDF बना देना और मूल से तुलना असंभव कर देना बेहतर हो सकता है, लेकिन कानूनी साक्ष्य के लिए आधिकारिक दस्तावेज़ों में जालसाज़ी करते समय उन्हें मूल जैसा ही रखना ज़रूरी होता है ताकि पकड़े न जाएँ, हालाँकि ऐसे दस्तावेज़ आम तौर पर इंटरनेट पर सार्वजनिक नहीं होते
"PDF के लिए Photoshop क्यों नहीं है" का एक जवाब Xournal++ है
मेरे साथ भी हाल ही में ऐसा ही कुछ हुआ, मैं पुर्तगाल में 1 साल रहा था और एक real estate agent ने बिजली और पानी के बिलों में हेरफेर करके नकली PDF दी, मैंने PDF metadata से जालसाज़ी पकड़ ली, लेकिन उससे आगे कुछ नहीं किया और सिर्फ़ पैसे वापस ले लिए, यह भी समझ आया कि metadata को आसानी से overwrite किया जा सकता है, मैं सोच रहा हूँ कि ऐसे मामलों में सुरक्षित रूप से खुद को कैसे बचाया जाए
digitally signed electronic invoices एक समाधान हैं, उदाहरण के लिए फ़्रांस का Factur-X (जर्मन नाम ZUGFeRD) signed XML data को PDF में embed करता है, इसलिए यह सत्यापित करना आसान होता है कि invoice वास्तव में किसने जारी किया, यूरोप के कई देश VAT processing के लिए इस प्रणाली को अपना रहे हैं, और मशीन द्वारा पढ़ा जा सकने वाला signed data कागज़ी दस्तावेज़ों की तुलना में कहीं अधिक भरोसेमंद है, दूसरा उपाय ऐसे मामलों की रिपोर्ट करना है ताकि संबंधित लोगों पर fraud के लिए कार्रवाई हो सके
वकीलों के पास इसका जवाब सैकड़ों साल पहले से था, हर दस्तावेज़ की कई प्रतियाँ बनती हैं और हस्ताक्षर के समय हर पक्ष के पास उसकी प्रति रहती है, मैं भी अनुबंध की दो प्रतियाँ लेता हूँ, दोनों पक्ष हस्ताक्षर करते हैं और फिर हर कोई एक प्रति अपने पास रखता है, संशोधन होने पर भी यही प्रक्रिया होती है, हर कोई अपनी कॉपी की ज़िम्मेदारी से रक्षा करता है, और यह प्रक्रिया डिजिटल दुनिया में भी लागू होनी चाहिए
ऐसे मामले में तो लगता है कि forged document का इस्तेमाल करके धोखाधड़ी करने पर मुकदमा होना चाहिए, भले यह आपके साथ कारगर न हुआ हो, लेकिन यही तरीका इस्तेमाल करके बहुत से और पीड़ित बने हो सकते हैं
अगर आप दूसरे tenants के लिए लड़ना नहीं चाहते, तो सिर्फ़ मुकदमे की "धमकी" देना भी ठीक हो सकता है, इससे real estate agent मकान मालिक की जानकारी देने या deposit लौटाने के लिए मजबूर हो सकता है
वापस मिलने वाला deposit, या wire-fraud (आपराधिक धोखाधड़ी) के कारण मिलने वाला दीवानी मुआवज़ा ही अंतिम लक्ष्य है
लगता है RightSignature साइट पर स्पष्ट सबूत मौजूद है, लेकिन अगर साइट गायब हो जाए तो दस्तावेज़ की प्रामाणिकता सत्यापित करने का कोई तरीका होना चाहिए, अभी जो verification page दिया जाता है वह साइट के बिना बेकार है
यह मुश्किल इसलिए लगता है क्योंकि verification page PDF के अंदर शामिल है, लेकिन उसमें अपने ही hash या signature को शामिल नहीं किया जा सकता, केवल hash से भी काम नहीं चलेगा क्योंकि फ़ाइल में छेड़छाड़ करते हुए hash भी बदला जा सकता है, किसी स्पष्ट रूप से signed payload को निकालने का तरीका चाहिए, लेकिन RightSignature का डिज़ाइन cryptography-आधारित नहीं है इसलिए उसे पूरी तरह नए सिरे से डिज़ाइन करना होगा
PDF स्वयं signature verification को support करता है, और Adobe Reader भी इसे पहचानता है, DocuSign यही तरीका इस्तेमाल करता है, और Reader में signed version सीधे देखा जा सकता है (Adobe signature document guide, signature preview उदाहरण: Adobe Reader उदाहरण)
मुझे बहुत जिज्ञासा है कि rental agency वाले मामले का आखिर क्या हुआ
मेरा मानना है कि sha256 collision जानबूझकर बनाना व्यावहारिक रूप से असंभव है, SHAttered में भी SHA-1 पर 110 साल की GPU क्षमता लगी थी, शायद RightSignature की तरफ़ से गलती से गलत दस्तावेज़ upload हो गया हो, जैसे गलत फ़ाइल चुन ली गई हो या गलती से कोई दूसरा version चढ़ गया हो और बाद में भ्रम हुआ हो
OP ने पोस्ट में स्पष्ट किया है कि वह draft बहुत बाद में upload हुआ था, इसलिए इसे साधारण भ्रम नहीं कहा जा सकता, अगर जानबूझकर नया version डाला गया था, तो पहले से signed lease agreement पूरा हो जाने के बाद संशोधित version दोबारा upload करने का कोई तर्कसंगत उद्देश्य समझ नहीं आता
वास्तव में signature में इस्तेमाल हुआ hash original document से मेल खाता है, यानी उस version से जिसमें tenant के हस्ताक्षर और धोखाधड़ी से जोड़ा गया अतिरिक्त clause नहीं है, बाकी किसी version से hash मेल नहीं खाता
इस चरण पर agency के पास दो विकल्प लगते हैं, (A) deposit तुरंत वापस कर दे, और अगर agent सिर्फ़ मध्यस्थ था तो बाद में landlord से वसूले, (B) landlord की पूरी जानकारी दे और landlord से कानूनी रूप से वापसी की स्पष्ट माँग करे, PDF forgery का मुद्दा और agency के साथ खींचतान दिलचस्प हो सकती है, लेकिन असली लक्ष्य deposit वापस पाना है
मैंने खोलने की कोशिश की तो 403 error मिला (web archive लिंक)