कार्यप्रणाली

दावा

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

आप स्वयं इसकी जाँच कैसे कर सकते हैं

1. अपने ब्राउज़र के डेवलपर टूल खोलें और Network टैब पर जाएँ।
2. कोई टूल पेज लोड करें और उसे पूरी तरह लोड होने दें। आपको HTML, CSS, JavaScript और कुछ टूल के लिए किसी WebAssembly मॉड्यूल या AI मॉडल के अनुरोध दिखाई देंगे। ये सभी इसी डोमेन से आते हैं।
3. नेटवर्क लॉग साफ़ करें।
4. कोई फ़ाइल चुनें और टूल चलाएँ।
5. लॉग देखते रहें। फ़ाइल के प्रोसेस होने के दौरान कोई भी अनुरोध नहीं भेजा जाता।

पेज लोड हो जाने के बाद अपना नेटवर्क कनेक्शन बंद कर देना इसी परीक्षण का सीधा-सादा रूप है: टूल काम करते रहते हैं।

बिल्ड इसे कैसे लागू करता है

चार स्वतंत्र तंत्र, जिनमें से हर एक चेतावनी देने के बजाय बिल्ड को फ़ेल कर देता है:

• सोर्स स्कैन। आपके बाइट को छू सकने वाली हर फ़ाइल को इनके लिए स्कैन किया जाता है: fetch, XMLHttpRequest, WebSocket, EventSource, WebTransport, sendBeacon और FormData। बिना एनोटेशन वाली एक भी उपस्थिति बिल्ड को रोक देती है। एकमात्र अनुमत अपवाद वही समान-मूल इंजन या मॉडल डाउनलोड है जो प्रोसेसिंग शुरू होने से पहले होता है, और उनमें से हर एक के साथ सोर्स में लिखित औचित्य दर्ज है।
• सेल्फ़-होस्टिंग ऑडिट। पूरे सोर्स ट्री और बिल्ड किए गए आउटपुट को तीसरे पक्ष के होस्ट के लिए स्कैन किया जाता है। कोई भी लाइब्रेरी, फ़ॉन्ट, मॉडल या WebAssembly बाइनरी किसी CDN से लोड नहीं होती, इसलिए अनुरोध के रास्ते में शुरू से ही कोई तीसरा पक्ष है ही नहीं।
• Content Security Policy. डिप्लॉय किया गया Content-Security-Policy हेडर यह सेट करता है: connect-src 'self'। भले ही कोई कोड बाहरी अनुरोध करने का प्रयास करे, ब्राउज़र उसे अस्वीकार कर देगा।
• रनटाइम लॉक। जब कोई प्रोसेसिंग कार्य चल रहा होता है, तब पेज के अपने नेटवर्क प्रिमिटिव बीच में ही रोक दिए जाते हैं और अनुरोध अस्वीकार कर देते हैं। स्वचालित ब्राउज़र टेस्ट इसी व्यवहार की पुष्टि करता है।

हम जानबूझकर किन बातों का वादा नहीं करते

• हम यह वादा नहीं करते कि कोई फ़ाइल किसी सटीक आकार तक पहुँच जाएगी। कम्प्रेशन सामग्री पर निर्भर करता है। जब गुणवत्ता की न्यूनतम सीमा पार किए बिना लक्ष्य तक नहीं पहुँचा जा सकता, तो FileSlimmer यह बता देता है और उसे जो सबसे अच्छा परिणाम मिला वही लौटाता है।
• हम यह वादा नहीं करते कि हर फ़ाइल हर डिवाइस पर प्रोसेस हो जाएगी। ब्राउज़र की मेमोरी सीमित है, और फ़ोन पर कोई बड़ी फ़ाइल टैब को क्रैश कर पाने से पहले ही अस्वीकार की जा सकती है। डिवाइस की सीमाएँ आपकी फ़ाइल पढ़े जाने के बाद नहीं, बल्कि उससे पहले लागू की जाती हैं।
• हम किसी परफ़ॉर्मेंस स्कोर का वादा नहीं करते। Lighthouse और Core Web Vitals डिवाइस और नेटवर्क पर निर्भर करते हैं।
• हम आपके एक्सटेंशन, आपके ऑपरेटिंग सिस्टम या आपके नेटवर्क के बारे में कुछ भी वादा नहीं करते। देखें: गोपनीयता कथन.

जानकारी नष्ट करने वाले ऑपरेशन चिह्नित किए जाते हैं

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

ओपन सोर्स

FileSlimmer ओपन-सोर्स कंपोनेंट पर बना है। उनके लाइसेंस और सोर्स रिपॉज़िटरी यहाँ सूचीबद्ध हैं: ओपन-सोर्स सूचनाएँ पेज— इसमें LGPL कंपोनेंट के लिए री-लिंकिंग की पेशकश भी शामिल है।