तुमच्या फाइल अपलोड होत नाहीत याची खात्री कशी करायची
प्रत्येक साइट आम्ही खासगी आहोत असंच सांगते. मग हे प्रत्यक्षात तपासायचं कसं?
सुरुवात योग्य गृहीतकापासून करा
मार्केटिंग पेजवरचा गोपनीयतेचा दावा हा पुरावा नाही. कुलपाचं चिन्ह, एखादा बॅज किंवा प्रायव्हसी पॉलिसीतलं वाक्यही पुरावा नाही — ते हेतू सांगतात, आणि तुम्हाला जाणून घ्यायचं असतं ते वर्तन. सुदैवाने वर्तन बघता येतं: पेज नेमकं काय पाठवतं हे दाखवणारी साधनं प्रत्येक ब्राउझरसोबतच येतात, आणि ती वाचायला तुम्ही डेव्हलपर असण्याची गरज नाही.
या तपासण्या याच साइटवर करून बघा. याआधी तुम्ही जी साइट वापरत होता तिच्यावरही करा. मुद्दा दुसऱ्या कोणत्या दाव्यावर विश्वास ठेवण्याचा नाही; मुद्दा हा की कोणत्याच दाव्यावर विश्वास ठेवण्याची गरज उरू नये.
तपासणी एक: नेटवर्क पॅनेलवर लक्ष ठेवा
- डेव्हलपर टूल्स उघडा. बहुतांश डेस्कटॉप ब्राउझरमध्ये त्यासाठी F12, किंवा Ctrl+Shift+I, किंवा Cmd+Option+I दाबावं लागतं.
- Network टॅब निवडा आणि रेकॉर्डिंग सुरू आहे याची खात्री करा.
- पेज रीलोड करा, मग यादी मोकळी करा, म्हणजे तुमची सुरुवात रिकाम्या लॉगपासून होईल.
- तुमची फाइल निवडा आणि ती प्रक्रिया चालवा.
- आकारानुसार क्रमवारी लावा, किंवा POST आणि PUT रिक्वेस्टसाठी Method स्तंभाकडे बघा.
तुम्ही शोधत आहात ती अशी कोणतीही रिक्वेस्ट, जिचा पेलोड तुमच्या फाइलच्या आकाराच्या घरातला आहे, आणि तुम्ही ज्या साइटवर आहात तिच्याखेरीज दुसऱ्या कोणत्याही होस्टकडे जाणारी कोणतीही रिक्वेस्ट. लोकल टूल स्वतःच्या कोडसाठीच्या रिक्वेस्ट दाखवेल — स्क्रिप्ट, स्टाइलशीट, WebAssembly मॉड्यूल, कदाचित एखादी मॉडेल फाइल — आणि मग काम चालू असताना काहीच नाही. अपलोड करणारं टूल मात्र तुम्ही बटण दाबताच अनेक मेगाबाइट वाहून नेणारी रिक्वेस्ट दाखवेल.
तपासणी दोन: नेटवर्कच काढून घ्या
ही सर्वात भक्कम तपासणी आहे, आणि यासाठी कोणत्याही तज्ज्ञतेची गरज नाही. पेज नेहमीप्रमाणे लोड करा, टूल एकदा वापरा म्हणजे त्याला लागणारं इंजिन कॅश होईल, आणि मग कनेक्शन तोडा: एअरप्लेन मोड सुरू करा, Wi-Fi बंद करा, किंवा डेव्हलपर टूल्समधलं ऑफलाइन टॉगल वापरा. आता एक फाइल प्रोसेस करा.
काम पूर्ण झालं, तर ती प्रक्रिया तुमच्या मशीनखेरीज दुसरीकडे कुठेही होणं शक्यच नाही. यात वादाला जागाच उरत नाही. ते फसलं किंवा अडकून बसलं, तर पाइपलाइनमधल्या कशाला तरी सर्व्हरची गरज होती — ती वैध असू शकते, उदाहरणार्थ अजून कॅश न झालेली मॉडेल फाइल, पण ती नेमकी कोणती हे विचारायचं आहे, हे आता तुम्हाला कळलं.
तपासणी तीन: content security policy वाचा
Content security policy म्हणजे साइट पाठवते आणि ब्राउझर अमलात आणतो असा एक हेडर. त्यातलं connect-src डिरेक्टिव्ह पेजला कोणकोणत्या ठिकाणी कनेक्शन उघडायची परवानगी आहे त्यांची यादी देतं. connect-src फक्त साइटच्या स्वतःच्या ओरिजिनपुरतं मर्यादित असेल, तर पेजचा कोड काहीही करू पाहत असला तरी दुसरीकडे काही पाठवण्याचा प्रयत्न ब्राउझर स्वतःच अडवेल.
ते वाचण्यासाठी Network टॅब उघडा, डॉक्युमेंट रिक्वेस्टवर — सहसा पहिल्याच ओळीवर — क्लिक करा, आणि रिस्पॉन्स हेडरमध्ये Content-Security-Policy बघा. बाहेरचा एकही होस्ट नसताना connect-src 'self' असलेलं धोरण म्हणजे ब्राउझरने अमलात आणलेलं अर्थपूर्ण बंधन असतं, नुसतं वचन नव्हे.
प्रत्येक तपासणी काय सिद्ध करते
| तपासणी | ती काय सिद्ध करते | ती कशाला स्पर्श करत नाही |
|---|---|---|
| नेटवर्क पॅनेल | या सत्रादरम्यान या पेजने काय पाठवलं | वेगळा कोड पाथ, साइटची पुढची आवृत्ती, किंवा तुम्ही बघणं थांबवल्यानंतर केलेली रिक्वेस्ट |
| ऑफलाइन चाचणी | प्रक्रिया स्वतः लोकल पातळीवरच चालते | काही रांगेत ठेवून तुम्ही पुन्हा कनेक्ट झाल्यावर पाठवलं जातं का |
| Content security policy | ब्राउझर मुळात कुठे कनेक्शनला परवानगी देईल | धोरणाने परवानगी दिलेलं काहीही, साइटच्या स्वतःच्या ओरिजिनसह |
| सोर्स कोड वाचणं | पाठवलेल्या कोडमध्ये काय आहे | मेहनत; आणि साइट बदलली की हे पुन्हा करावं लागतं |
एकत्रितपणे या तपासण्या भक्कम आहेत. स्वतंत्रपणे प्रत्येकीत एक फट आहे, आणि एकाच तपासणीने प्रश्न मिटतो असं सांगणारा माणूस गोष्ट फारच सोपी करून सांगतो आहे.
टूल लोकल नसल्याची लक्षणं
- तुमच्या डिव्हाइसशी काहीही संबंध नसलेल्या वेगाने सरकणारी प्रोग्रेस बार — वेगवान लॅपटॉपवर आणि जुन्या फोनवर सारखीच गुळगुळीत.
- निकाल तुमच्या ब्राउझरकडे आधीच असलेली फाइल म्हणून न मिळता, त्यांच्याच डोमेनवरच्या डाउनलोड URL ची लिंक म्हणून मिळणं.
- काही तासांनी फाइल त्यांच्या सर्व्हरवरून हटवल्या जातील असा संदेश. ते वाक्य म्हणजे फाइल तिथे होत्या याची कबुलीच आहे.
- रांग किंवा रेट लिमिट. तुमच्या स्वतःच्या प्रोसेसरची रांग इतर लोकांसोबत वाटलेली नसते.
- नेटवर्क बंद असताना टूल फक्त पहिल्या लहानशा फाइलपुरतं चालतं आणि मग थांबतं.
पडताळणीच्या मर्यादा
पडताळणी तुम्हाला साइटच्या ज्या आवृत्तीची, ज्या दिवशी चाचणी घेतली, तेवढ्यापुरतीच माहिती देते. साइट उद्या बदलू शकते. म्हणूनच सर्वात महत्त्वाच्या तपासण्या रचनात्मक असतात: कडक content security policy आणि यशस्वी ऑफलाइन चाचणी हे ॲप्लिकेशन कसं बांधलं आहे याचे गुणधर्म असतात, एखाद्या ठराविक रिलीझबद्दलची वचनं नव्हेत.
या यादीतल्या प्रत्येक तपासणीच्या बाहेर दोन गोष्टी राहतात. ब्राउझर एक्स्टेन्शन कोणत्याही पेजचा मजकूर वाचू शकतं — त्यात तुम्ही लोड केलेल्या फाइलचाही समावेश होतो — आणि हे कोणतीही साइट रोखू शकत नाही. तुम्ही उघडलेली प्रत्येक फाइल तुमची ऑपरेटिंग सिस्टिम पाहू शकते. एखादा दस्तऐवज इतका संवेदनशील असेल की या गोष्टी महत्त्वाच्या ठरतात, तर तो तुमच्या नियंत्रणातल्या मशीनवर ऑफलाइन सॉफ्टवेअरमध्ये हाताळा, आणि त्या कामासाठी कोणतीही वेबसाइट — ही साइटसुद्धा — चुकीचं साधन आहे असंच माना.
यासाठीची टूल्स
स्रोत
- W3C — Content Security Policy Level 3
- MDN — Content-Security-Policy connect-src
- Chrome DevTools — inspect network activity
- MDN — Firefox Network Monitor