VPN किंवा प्रॉक्सी कॉपीराइट असलेला मजकूर कॉपी करू शकते का? तीन कृती
पॅकेट पाठवणे, प्रतिसाद कॅशे करणे आणि पुन्हा प्रकाशित करणे या वेगवेगळ्या कॉपीराइट प्रश्नांना जन्म देतात. तुमची सेवा जी कृती करते ती तिचे नियमन करणाऱ्या नियमाशी जुळवा.
पॅकेट पाठवणे, कॅशिंग आणि पुनःप्रकाशन हे डॅशबोर्डवरून एकसारखे दिसतात, पण हक्काचा प्रश्न आला की ते पूर्णपणे वेगळे वागतात. वापरकर्ता आणि सर्व्हर यांच्यात बाइट हलवणारी सेवा एक कृती करते, तर प्रतिसाद ठेवून पुढच्या भेट देणाऱ्याला देणारी सेवा दुसरी कृती करते. दुसऱ्याचा मजकूर स्वतःच्या नावाने प्रकाशित करणे ही तिसरी कृती आहे, आणि सामान्य अर्थाने वितरण म्हणजे फक्त तिसरीच कृती.
तुमची प्रणाली या तीनपैकी नेमकी कोणती कृती करते हे ठरवा, मग तिला जुळणारा नियम जोडा. उत्पादनाची लेबले इथे काहीच ठरवत नाहीत, आणि वापरला जाणारा प्रोटोकॉलही निकष नाही.
प्रॉक्सी किंवा VPN करू शकते अशा तीन कृती
गेटवे TCP प्रवाह स्वीकारतो, पत्ते पुन्हा लिहितो आणि विभाग दोन्ही दिशांनी पुढे पाठवतो. जोडणी संपल्यावर डिस्कवर काहीही राहत नाही, आणि क्लायंटने मूळाशी नव्हे तर गेटवेशी TLS बोलणी केली नाही तर पेलोड गेटवेसाठी अपारदर्शकच राहतो.
कॅशिंग मध्यस्थ वेगळ्या पद्धतीने काम करतो: तो विनंतीचे विश्लेषण करतो, स्वतः मोजलेल्या किंवा हेडरमधून वाचलेल्या कालावधीसाठी प्रतिसाद साठवतो आणि नंतर तो साठवलेला घटक पुढील क्लायंटना पुन्हा देतो. आता तारेच्या बाहेर काहीतरी अस्तित्वात आहे, URL आणि वैधताकारकाने ओळखलेले, आणि त्याची साठवणूक ही दुष्परिणाम नसून संरचनेतील निवड आहे.
पुनःप्रकाशन एक पाऊल पुढे जाते. मजकूर तुम्ही नियंत्रित करता त्या पायाभूत सुविधेवर, तुम्ही निवडलेल्या प्रेक्षकांसाठी, बहुतेकदा संपादनानंतर ठेवलेला असतो. पहिल्या दोन कृती वाहतुकीचे वर्णन करतात, तिसरी वितरणाचे.
| कृती | नंतर काय राहते | निकाल ठरवणारा प्रश्न |
|---|---|---|
| प्रवाह वाहून नेणे | काही सेकंद टिकणारी भाषांतर स्थिती आणि बफर | क्षणिक प्रसारण कोणत्या मध्यस्थ तरतुदीत बसते? |
| प्रतिसाद साठवणे | घटक आणि ताजेपणा व वैधताकारक मेटाडेटा | साठवणूक आणि पुनर्प्रक्षेपणास परवानगी होती का, आणि कधीपर्यंत? |
| तुमच्या URL खाली कलाकृती देणे | नव्या प्रेक्षकांसाठी पाठवलेली प्रकाशित प्रत | त्या प्रेक्षकांसाठीच्या वितरणाला कोणती परवानगी लागू आहे? |
डिक्रिप्ट करणारी प्रॉक्सी वहनाचे प्रतिकरण कुठे करते
बहुतेक वाद ठरवणारा फरक हा आहे की यंत्र कधीही स्पष्ट मजकूर ठेवते का. शुद्ध बोगदा, तो WireGuard असो, OpenVPN tun उपकरण असो किंवा SSH -L फॉरवर्ड असो, टोकांमध्ये गुप्त मजकूर हलवतो आणि वाचता येईल असे काहीही मागे ठेवत नाही. TLS संपवणारी प्रॉक्सी उलटे काम करते: ती हस्तांदोलन पूर्ण करते, प्रतिसाद स्मृतीत बफर करते आणि नंतर प्रवाह क्लायंटकडे पुन्हा कूटबद्ध करते. त्या क्रियांमध्ये कलाकृती ऑपरेटर तपासू आणि ठेवू शकेल अशा रूपात असते.
17 USC 106 प्रतिकरण आणि वितरण यांचा समावेश एकमेव हक्कांत करते, आणि प्रत्येक त्याच संहितेत नमूद केलेल्या मर्यादांना अधीन आहे. मिलिसेकंदाचा बफर वाद न करता मर्यादेत बसू शकतो; साठवलेला, पुन्हा देता येणारा घटक तिथे बसवणे खूप कठीण. स्मृतीला स्पर्श झाला या वस्तुस्थितीपेक्षा कालावधी आणि हेतूला जास्त वजन असते.
यापैकी काहीही VPN ला परवाना बनवत नाही, आणि प्रत्येक प्रॉक्सीला उल्लंघनकारक बनवत नाही. वहन ही अनेक वस्तुस्थितींपैकी एक आहे, आणि मूल्यांकन करता येणारा प्रश्न तसाच राहतो: कोणती कृती, कोणाच्या मजकुरावर, कोणत्या परवानगीखाली.
कॅशे हेडर कायदेशीर परवानगी नव्हे, तर प्रोटोकॉल परवानगी सांगतात
HTTP कॅशे प्रतिसादाच्या मेटाडेटावरून काय साठवायचे हे ठरवतो, आणि RFC 9111 त्याने पाळावयाचे नियम ठरवते. Cache-Control: no-store प्रत्येक सुसंगत कॅशेला प्रतिसाद टाकून द्यायला सांगते, तर private पुनर्वापर एका वापरकर्त्यापुरता मर्यादित करते आणि लांब max-age सामायिक साठवणुकीचे निमंत्रण देते. एकच विनंती मूळाने कोणते धोरण निवडले हे सांगते. इतर कोणत्याही वादापूर्वी ती चालवा.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
लांब आयुष्य जाहीर करणारा प्रतिसाद कॅशेला सांगत असतो की प्रोटोकॉल पातळीवर पुनर्प्रक्षेपण स्वीकारार्ह आहे. ते विधान तोच घटक घेऊन पुन्हा होस्ट करून स्वतःच्या सेवेत जोडता येईल का याबद्दल काहीही सांगत नाही. दोन वेगळ्या परवानग्या दोन वेगळ्या यंत्रणांतून येतात, आणि एक पूर्ण केल्यावर दुसरी जिथे होती तिथेच राहते.
आरशातील प्रसंगही तसाच अपयशी ठरतो. टोकापासून टोकापर्यंत HTTPS पारदर्शक कॅशेला काहीही साठवू देत नाही, पण त्या निकालामुळे मजकूर वितरित करण्याचा हक्क निर्माण होत नाही, की तुमच्याकडे आधीच असलेला हक्क जात नाही. प्रोटोकॉलचे वर्तन यंत्र काय करू शकते हे स्पष्ट करते; ते कधीही अधिकार देत नाही.
सेवा सुरू होण्यापूर्वी काय लिहून ठेवावे
बाहेरचा माणूस तपासू शकेल अशा शब्दांत ती व्यवस्था वर्णन करा. मजकूर आणि त्याचा स्रोत नावाने सांगा, प्रणाली करते त्या कृतींची यादी करा आणि प्रत्येक साठवलेला घटक किती काळ जगतो ते सांगा.
ती वर्णने कोणाच्याही स्मरणात नव्हे, तर तैनातीसोबत ठेवा. तक्रार आल्यावर संरक्षण करता येणारी भूमिका आणि अंदाज यांतील अंतर बहुतेकदा महिन्यांपूर्वी लिहिलेला, साठवणुकीचा कालावधी आणि परवाना नावाने सांगणारा एक परिच्छेद असतो.
छोटी तपासणी यादी वारंवार येणाऱ्या त्रुटी झाकते:
- मजकुराचा स्रोत आणि त्याला जोडलेल्या अटी.
- केलेली प्रत्येक कृती: पाठवणे, साठवणे, संपादन, देणे.
- प्रत्येक घटक वर्गासाठी साठवणूक, तास किंवा दिवसांत.
- देण्याच्या टप्प्यासाठी आधार असलेली परवानगी किंवा मर्यादा.
- हक्कधारकांसाठी संपर्क आणि काढून टाकण्याचा मार्ग.
यादी स्थापत्य आराखड्यावर नव्हे, तर प्रत्यक्ष संरचनेवर चालवा. उत्तर नसलेली जागा हेच पुढचे काम: एकतर त्या कृतीसाठी परवानगी मिळवा, किंवा ती करणे थांबवा. व्यावसायिक सेवेसाठी, लिहिलेले वर्णन तुम्ही सेवा देता त्या क्षेत्राधिकाराशी वकिलाकडून तोंडून वाचून घ्या, कारण तेच वर्णन हा आढावा शक्य करते. लिखित स्वरूपात वर्णन करता येणार नाही ती अशी भूमिका आहे जिचे संरक्षण तुम्ही करू शकत नाही.