के 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 ले पारदर्शी क्यासलाई केही भण्डारण गर्न दिँदैन, तर त्यो परिणामले सामग्री वितरण गर्ने अधिकार सिर्जना गर्दैन, तपाईंसँग पहिले नै भएको अधिकार पनि हटाउँदैन। प्रोटोकल व्यवहारले यन्त्र के गर्न सक्छ भन्ने व्याख्या गर्छ; यसले कहिल्यै अधिकार दिँदैन।
सेवा सुरु हुनुअघि के लेखेर राख्ने
बाहिरको मानिसले जाँच्न सक्ने शब्दमा त्यो व्यवस्था वर्णन गर्नुहोस्। सामग्री र त्यसको स्रोत नामकरण गर्नुहोस्, प्रणालीले गर्ने कार्यहरू सूचीबद्ध गर्नुहोस्, र भण्डारित हरेक वस्तु कति लामो बाँच्छ भनी बताउनुहोस्।
त्यो विवरण कसैको सम्झनामा होइन, तैनाथीसँगै राख्नुहोस्। उजुरी आउँदा रक्षायोग्य अडान र अनुमानबीचको दूरी प्रायः महिनौं अघि लेखिएको, भण्डारण अवधि र इजाजतपत्र नाम दिने एक अनुच्छेद हुन्छ।
छोटो समीक्षा सूचीले दोहोरिने खाडलहरू समेट्छ:
- सामग्रीको स्रोत र त्यसमा जोडिएका सर्तहरू।
- गरिने हरेक कार्य: अगाडि बढाउने, भण्डारण, सम्पादन, प्रस्तुत।
- हरेक वस्तु वर्गको भण्डारण, घण्टा वा दिनमा।
- प्रस्तुत गर्ने चरणका लागि आधार लिइएको अनुमति वा सीमा।
- अधिकारधारकका लागि सम्पर्क र हटाउने बाटो।
सूचीलाई स्थापत्य चित्रमा होइन, जीवित कन्फिगरेसनमा चलाउनुहोस्। उत्तर नभएको ठाउँ त्यही खाडल अर्को काम हो: या त त्यो कार्यका लागि अनुमति लिनुहोस्, या गर्न छोड्नुहोस्। व्यावसायिक सेवाका लागि, लेखिएको विवरण तपाईंले सेवा दिने क्षेत्राधिकारसँग वकिलबाट पढाउनुहोस्, किनकि त्यही विवरणले त्यो समीक्षा सम्भव बनाउँछ। लिखित रूपमा वर्णन गर्न नसकिने कुरा त्यो अडान हो जसको रक्षा तपाईं गर्न सक्नुहुन्न।