सुरक्षा आर्किटेक्चर

PDF Pro के गोपनीयता दावे वास्तव में कैसे काम करते हैं।

इस पेज पर सब कुछ आपके ब्राउज़र के DevTools में सत्यापन योग्य है। मुख्य नियम: हमें आपकी फ़ाइलें एक्सेस नहीं करनी चाहिए — भले ही हम चाहें। नीचे बताया गया है कि यह नियम क्रिप्टो, स्टोरेज और रिक्वेस्ट लेयर पर कैसे लागू होता है।

memoryक्लाइंट-साइड WebAssembly और JS lockAES-256-GCM verifiedECDSA P-256 cloud_offक्लाइंट-साइड एन्क्रिप्टेड स्टोरेज
lanएन्क्रिप्शन प्रवाह देखें थ्रेट मॉडल
इस पृष्ठ पर

चार आर्किटेक्चरल स्तंभ

चार तकनीकी विकल्प सुरक्षा स्थिति को परिभाषित करते हैं। इन्हें उस कोड द्वारा लागू किया जाता है जो आपके ब्राउज़र में चलता है — किसी नीति दस्तावेज़ द्वारा नहीं।

memory
1. लोकल-फर्स्ट प्रोसेसिंग
PDF देखना, एनोटेशन, फॉर्म भरना, संपीड़न, मर्जिंग, कन्वर्जन, और साइनिंग — सब कुछ WebAssembly और JavaScript के माध्यम से पूरी तरह से आपके ब्राउज़र में चलता है। इन टूल्स के लिए कोई भी फ़ाइल डेटा कभी आपके डिवाइस को नहीं छोड़ता — आपके Network टैब में सत्यापन योग्य।
key
2. क्लाइंट-साइड जेनरेट की गई कुंजियाँ
जब आपको कोई फ़ाइल शेयर करनी होती है, तो एन्क्रिप्शन कुंजी आपके टैब के अंदर Web Crypto API द्वारा जेनरेट होती है। यह मेमोरी में, URL फ्रैगमेंट में, या (पासफ्रेज़ मोड में) प्राप्तकर्ता के डिवाइस पर PBKDF2 के माध्यम से व्युत्पन्न होती है। सर्वर इसे कभी नहीं देखता।
cloud_off
3. क्लाइंट-साइड एन्क्रिप्टेड स्टोरेज
केवल AES-256-GCM साइफरटेक्स्ट और एक इनिशियलाइज़ेशन वेक्टर (और पासफ्रेज़ मोड में, एक PBKDF2 साल्ट) स्टोर किया जाता है। कुंजी के बिना, यह डेटा क्रिप्टोग्राफिक रूप से रैंडम बाइट्स से अप्रभेद्य है। रूट डेटाबेस एक्सेस भी इसे डिक्रिप्ट करने में हमारी मदद नहीं करेगा।
policy
4. ईमानदार AI सीमा
AI टूल (चैट, सारांश, अनुवाद) को काम करने के लिए पठनीय टेक्स्ट चाहिए। हम क्लाइंट-साइड टेक्स्ट निकालते हैं और केवल वही मॉडल प्रोवाइडर को भेजते हैं — PDF फ़ाइल कभी नहीं, इमेज कभी नहीं, एम्बेडेड अटैचमेंट कभी नहीं। पूर्ण विवरण के लिए नीचे AI अनुभाग देखें।

एन्क्रिप्शन प्रवाह (सुरक्षित ट्रांसफर)

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

प्रेषक — ब्राउज़र में
// 1. generate a fresh 256-bit key key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // 2. random 96-bit IV per file iv = crypto.getRandomValues(new Uint8Array(12)) // 3. encrypt the PDF bytes locally ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // 4. upload ciphertext + iv — nothing else id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}}) // 5. build the share link with the key in the URL fragment (#) link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
सर्वर — केवल साइफरटेक्स्ट स्टोर करता है
ciphertext = opaque bytes // cannot be decrypted without the key iv = 12-byte nonce expiry = 24 h (free) / 30 d (Pro) // the URL fragment (#...) is NEVER sent to the server by browsers
▼
प्राप्तकर्ता — ब्राउज़र में
// 1. browser loads the page; the "#..." fragment stays client-side rawKey = location.hash.slice(1) // 2. fetch the ciphertext ct = await fetch("/api/transfer/" + id) // 3. decrypt locally using Web Crypto pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // 4. file ends up in the recipient's Downloads folder

सुरक्षा गारंटी चरण 5 (प्रेषक) और चरण 1 (प्राप्तकर्ता) पर निर्भर है: # के बाद URL फ्रैगमेंट किसी भी अनुपालन करने वाले ब्राउज़र द्वारा सर्वर को प्रेषित नहीं किया जाता। यही बात लिंक को स्वयं डिक्रिप्शन क्रेडेंशियल बनाती है।

पासफ्रेज़ मोड चरण 1 (प्रेषक) को PBKDF2-SHA256(passphrase, salt, 310_000) से बदलता है। साल्ट सर्वर-साइड स्टोर किया जाता है; पासफ्रेज़ आउट-ऑफ-बैंड प्राप्तकर्ता के साथ साझा किया जाता है।

साइनिंग प्रवाह (ECDSA P-256)

PDF साइनिंग NIST P-256 कर्व पर ECDSA का उपयोग करती है। प्राइवेट कुंजी आपके ब्राउज़र में जेनरेट होती है; दस्तावेज़ कभी आपका डिवाइस नहीं छोड़ता।

key
प्राइवेट कुंजी जनरेशन
आपके ब्राउज़र में crypto.subtle.generateKey के माध्यम से एक ECDSA P-256 कीपेयर जेनरेट होती है। प्राइवेट कुंजी को एक पासवर्ड-रैप्ड JSON Web Key (JWK) में एक्सपोर्ट किया जाता है जिसे आप स्थानीय रूप से स्टोर कर सकते हैं।
fingerprint
SHA-256 हैश और साइन
PDF बाइट्स को क्लाइंट-साइड SHA-256 से हैश किया जाता है। उस हैश पर प्राइवेट कुंजी द्वारा हस्ताक्षर किया जाता है। हस्ताक्षर CMS कंटेनर (PAdES-B-B प्रोफाइल) में PDF में एम्बेड किया जाता है।
verified
ऑफलाइन-सत्यापन योग्य
पब्लिक कुंजी (दस्तावेज़ के साथ या फिंगरप्रिंट के रूप में वितरित) वाला कोई भी व्यक्ति ऑफलाइन हस्ताक्षर सत्यापित कर सकता है। कोई सर्वर राउंड-ट्रिप आवश्यक नहीं।
gavel
यह क्या नहीं है
हमारे हस्ताक्षर क्रिप्टोग्राफिक रूप से सत्यापन योग्य हैं लेकिन eIDAS के तहत योग्य इलेक्ट्रॉनिक हस्ताक्षर (QES) नहीं हैं। ये अखंडता के छेड़छाड़-स्पष्ट प्रमाण हैं, आंतरिक वर्कफ़्लो के लिए उपयुक्त, नियामक-ग्रेड कानूनी बाध्यता के लिए नहीं।

AI फीचर — जहाँ हम सीमा के बारे में ईमानदार हैं

AI Chat, AI Summary, और Translate को पठनीय टेक्स्ट चाहिए। यहाँ बिल्कुल स्पष्ट है कि आपके डिवाइस से क्या जाता है, और क्या नहीं।

description
ब्राउज़र में टेक्स्ट निकाला गया
PDF को pdf.js के माध्यम से स्थानीय रूप से पार्स किया जाता है। केवल निकाला गया टेक्स्ट (या स्कैन किए गए PDF के लिए OCR आउटपुट) मेमोरी में रखा जाता है — मूल फ़ाइल आपके डिवाइस पर रहती है।
outbound
प्रोवाइडर को केवल टेक्स्ट
हम वह टेक्स्ट स्ट्रिंग AI प्रोवाइडर (Anthropic / OpenAI) को भेजते हैं। PDF फ़ाइल, एम्बेडेड इमेज, फॉन्ट और फॉर्म डेटा किसी भी AI मॉडल पर अपलोड नहीं होते।
block
आपकी सामग्री पर कोई ट्रेनिंग नहीं
हमारे प्रोवाइडर अनुबंध ग्राहक सामग्री पर ट्रेनिंग को अक्षम करते हैं। अनुरोध स्टेटलेस हैं — प्रत्येक आपके सत्र तक सीमित है।
info
यह कब मायने रखता है
यदि आपके दस्तावेज़ में विनियमित सामग्री (PHI, वर्गीकृत, कानूनी-विशेषाधिकार प्राप्त) है जहाँ टेक्स्ट निष्कर्षण भी संवेदनशील है, तो AI फीचर छोड़ें और लोकल टूल (देखें, एनोटेट, साइन, संपीड़ित, कन्वर्ट) उपयोग करें — वे 100% ब्राउज़र में काम करते हैं।

थ्रेट मॉडल — हम क्या बचाव करते हैं, क्या नहीं

थ्रेट मॉडल के बारे में स्पष्ट होना मार्केटिंग से अधिक उपयोगी है। आर्किटेक्चर वास्तव में क्या रोकता है, और कहाँ रुकता है।

shieldआर्किटेक्चर किसके विरुद्ध बचाव करती है

  • PDF Pro स्टाफ का हमारे सर्वर पर आपकी फ़ाइलें पढ़ना (हमारे पास कभी कुंजी नहीं होती)।
  • ट्रांसफर स्टोर का डेटाबेस-स्तरीय उल्लंघन (हमलावर साइफरटेक्स्ट देखता है, फ़ाइलें नहीं)।
  • फ़ाइल सामग्री का न्यायालय-आदेशित प्रकटीकरण (हम साइफरटेक्स्ट सौंप सकते हैं — जो हमारे पास है बस वही)।
  • संवेदनशील अटैचमेंट का मेल-सर्वर रिटेंशन (कुछ भी कभी आपके मेल सर्वर तक नहीं पहुँचता)।
  • हस्ताक्षरित PDF के साथ छेड़छाड़ (ECDSA हस्ताक्षर सत्यापन किसी भी बाइट परिवर्तन को पकड़ता है)।

warningकोई भी ब्राउज़र-आधारित टूल किसके विरुद्ध बचाव नहीं कर सकता

  • एक समझौता किया गया एंडपॉइंट (आपके डिवाइस पर मैलवेयर) — कुंजियाँ ऐसे डिवाइस की मेमोरी में रहती हैं जो भरोसेमंद होना चाहिए।
  • कोई URL फ्रैगमेंट को कंधे से देख रहा हो — शेयर लिंक को फ़ाइल जैसा मानें।
  • पासफ्रेज़ मोड में कमज़ोर पासफ्रेज़ — PBKDF2 ब्रूट फोर्स को धीमा करता है लेकिन 6-अक्षर का पासफ्रेज़ सुरक्षित नहीं बनाता।
  • प्राप्तकर्ता का डिक्रिप्टेड फ़ाइल फॉरवर्ड करना — ट्रांसपोर्ट सुरक्षा तब समाप्त होती है जब प्राप्तकर्ता PDF सेव करता है।
  • ब्राउज़र का स्वयं समझौता होना या कोई दुर्भावनापूर्ण एक्सटेंशन पेज में इंजेक्ट करना।

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

संबंधित पठन

क्लाइंट-साइड एन्क्रिप्टेड PDF शेयरिंग, समझाया गया
AES-256-GCM, कुंजी हैंडलिंग, फ्रैगमेंट बनाम पासफ्रेज़ मोड पर गहरा विश्लेषण।
सुरक्षित PDF ट्रांसफर आर्किटेक्चर
ट्रांसफर सिस्टम कैसे वायर्ड है, इसकी एंड-टू-एंड व्याख्या।
व्हाइटपेपर
क्रिप्टोग्राफिक साइनिंग और एंड-टू-एंड एन्क्रिप्टेड ट्रांसफर तकनीकी पेपर।

अक्सर पूछे जाने वाले प्रश्न

क्या PDF Pro मेरी फ़ाइलें डिक्रिप्ट कर सकता है?
नहीं। एन्क्रिप्शन कुंजियाँ उपयोगकर्ता के ब्राउज़र में जेनरेट और रखी जाती हैं। सुरक्षित ट्रांसफर के लिए, सर्वर केवल AES-256-GCM साइफरटेक्स्ट और एक इनिशियलाइज़ेशन वेक्टर (और पासफ्रेज़ मोड में साल्ट) स्टोर करता है। कुंजी कभी हमारे इन्फ्रास्ट्रक्चर तक नहीं पहुँचती। पूर्ण डेटाबेस एक्सेस के साथ भी, हमारे ऑपरेटर आपकी फ़ाइल डिक्रिप्ट नहीं कर सकते।
वास्तव में क्या स्थानीय रूप से चलता है और क्या सर्वर पर?
देखना, एनोटेशन, फॉर्म भरना, संपीड़न, मर्जिंग, कन्वर्जन, और साइनिंग — सब कुछ 100% WebAssembly और JavaScript के माध्यम से आपके ब्राउज़र में चलता है — कोई फ़ाइल डेटा कभी आपके डिवाइस को नहीं छोड़ता। AI फीचर (चैट, सारांश, अनुवाद) स्थानीय रूप से टेक्स्ट निकालते हैं और केवल वह टेक्स्ट (PDF फ़ाइल कभी नहीं) मॉडल प्रोवाइडर को भेजते हैं।
PDF Pro किन एल्गोरिदम का उपयोग करता है?
सममित एन्क्रिप्शन के लिए AES-256-GCM (सुरक्षित ट्रांसफर), पासफ्रेज़-व्युत्पन्न कुंजियों के लिए 310,000 पुनरावृत्तियों के साथ PBKDF2-SHA256, डिजिटल हस्ताक्षर के लिए NIST P-256 पर ECDSA, और दस्तावेज़ हैशिंग के लिए SHA-256। ये सभी ब्राउज़र के नेटिव Web Crypto API के माध्यम से चलते हैं, जो ऑडिट किया गया, मानकीकृत है, और हमारे द्वारा लागू नहीं किया गया।
क्या यह कानूनी रूप से बाध्यकारी इलेक्ट्रॉनिक हस्ताक्षर है?
PDF Pro के हस्ताक्षर क्रिप्टोग्राफिक रूप से सत्यापन योग्य हैं (SHA-256 हैश पर ECDSA P-256, PAdES-B-B प्रोफाइल) लेकिन eIDAS या समकक्ष विनियमों के तहत योग्य इलेक्ट्रॉनिक हस्ताक्षर (QES) नहीं हैं। QES-ग्रेड कानूनी बाध्यता के लिए, एक प्रमाणित ट्रस्ट सेवा प्रदाता आवश्यक है।
यदि मैं पासफ्रेज़ भूल जाऊँ या शेयर लिंक खो दूँ तो क्या होगा?
फ़ाइल स्थायी रूप से अनुपलब्ध हो जाती है। यह एंड-टू-एंड एन्क्रिप्शन का ट्रेड-ऑफ है — कोई रिकवरी पथ नहीं है, क्योंकि हमारे पास पहले कभी कुंजी नहीं थी। पासफ्रेज़ को पासवर्ड मैनेजर में सेव करें और लिंक को किसी टिकाऊ जगह सेव करें।
क्या आप फ़ाइल गतिविधि के सर्वर-साइड लॉग रखते हैं?
हम ऑपरेशनल लॉग रखते हैं (रिक्वेस्ट टाइमिंग, एरर कोड, रेट लिमिटिंग के लिए IP पते) लेकिन कभी प्लेनटेक्स्ट फ़ाइल सामग्री या एन्क्रिप्शन कुंजियाँ नहीं। लॉग एक छोटे शेड्यूल पर बनाए रखे जाते हैं — वर्तमान रिटेंशन विंडो के लिए हमारी गोपनीयता नीति देखें।
क्या कोई न्यायालय आदेश आपको मेरी फ़ाइलें प्रकट करने के लिए बाध्य कर सकता है?
हम केवल वही सौंप सकते हैं जो हमारे पास है: साइफरटेक्स्ट। डिक्रिप्शन कुंजी के बिना — जो प्रेषक के डिवाइस पर या प्राप्तकर्ता के पास URL फ्रैगमेंट में रहती है — वह साइफरटेक्स्ट डिक्रिप्ट नहीं किया जा सकता। सम्मन पत्र पूर्वव्यापी रूप से वह कुंजी वापस नहीं ला सकता जो हमने कभी स्टोर नहीं की।
मैं क्रिप्टोग्राफिक दावों को स्वयं कहाँ सत्यापित कर सकता हूँ?
अपना ब्राउज़र DevTools खोलें → Network टैब और देखें कि सुरक्षित ट्रांसफर अपलोड के दौरान पेज से क्या जाता है। आप देखेंगे कि सर्वर को मूल PDF नहीं बल्कि साइफरटेक्स्ट PUT किया जा रहा है। एन्क्रिप्शन कोड Web Crypto API को कॉल करता है, जो आपके ब्राउज़र में बिल्ट-इन है — हमारा कोड नहीं — और कोई भी इसे निरीक्षण कर सकता है।

गोपनीयता — आर्किटेक्चर के रूप में, मार्केटिंग के रूप में नहीं।

एक सुरक्षित ट्रांसफर आज़माएँ और Network टैब को स्वयं जाँचें। कोई भी फ़ाइल कभी प्लेनटेक्स्ट में अपलोड नहीं होती।

lockसुरक्षित ट्रांसफर आज़माएँ