आपकी वेबसाइट के लिए GDPR अनुपालन: गोपनीयता और विश्वास के लिए एक व्यावहारिक गाइड

एक दिन, आप एक बेफिक्र ब्लॉगर हैं। अगले दिन, आप अचानक GDPR नाम की इस बड़ी, डरावनी चीज से निपट रहे हैं। EU ने एक नया गोपनीयता-केंद्रित विनियमन, GDPR पेश किया है, और यह वेबसाइटों द्वारा व्यक्तिगत डेटा को संभालने के लिए महत्वपूर्ण गोपनीयता, सुरक्षा और डेटा पारदर्शिता आवश्यकताओं को निर्धारित करता है। आप खुद से पूछ रहे हैं, क्या यह मुझे प्रभावित करता है? और आप चिंतित हैं। आज, यह लेख आपको बेहतर ढंग से समझने में मदद करेगा कि कौन, क्या, कब और कैसे, और उम्मीद है कि आपको ज्ञान और उपकरण दोनों देगा ताकि आप एक बार फिर बेफिक्र ब्लॉगर बन सकें और आनंदपूर्वक अनुपालन कर सकें।

अब, वह एक अतिरिक्त प्रश्न जो आप शायद खुद से पूछ रहे हैं: यह गाइड केवल अब क्यों प्रकाशित हो रहा है, विनियमन के प्रभाव में आने के बाद? खैर, जवाब है, विश्वास करें या नहीं, अधिकांश टूल्स और सेवाओं ने केवल पिछले सप्ताह या उसके आसपास GDPR-अनुपालन अपडेट जारी किए, और इसने मुझे आखिरकार इस गाइड को एक साथ रखने की अनुमति दी। आइए देखते हैं कि क्या मामला है।

विषय सूची

1. अस्वीकरण
2. 60 सेकंड में GDPR
   1. यदि आप व्यक्तिगत डेटा प्रोसेस कर रहे हैं तो क्या?
   2. यह जुर्माने के बारे में भी नहीं है
3. डेटा फ्लो का पालन करें
   1. वेबसाइट से कनेक्शन
   2. पेज लोड हो रहा है
4. Google Analytics
   1. Google Analytics और व्यक्तिगत डेटा
   2. Google Analytics और लोकल स्टोरेज (कुकीज)
   3. IP एड्रेस अनामकरण
   4. यदि आप कुछ डेटा एकत्र करना चाहते हैं (या कुकीज का उपयोग करना चाहते हैं) तो क्या?
   5. अतिरिक्त Google Analytics पठन
5. Google Custom Search Engine
6. Google Adsense
7. ShareThis बटन
8. Matched Content
9. अन्य प्रकार के डेटा
   1. ई-कॉमर्स फॉर्म और बटन (PayPal)
   2. उपयोगकर्ता पंजीकरण
   3. टिप्पणियां
   4. ईमेल (और मेलिंग सूचियाँ)
   5. एम्बेडेड वीडियो (Youtube)
   6. एम्बेडेड स्क्रिप्ट्स
10. कंटेंट मैनेजमेंट सिस्टम (CMS): WordPress
    1. डेटा संग्रह = प्लगइन्स
    2. Google Analytics
    3. टिप्पणियां (Disqus)
       1. Disqus और WordPress डेटाबेस एकीकरण
    4. सामान्य स्क्रिप्ट नियंत्रण
       1. Wp_enqueue_script
       2. Wp_deregister_script
    5. सेशन कुकीज
    6. WordPress 4.9.6 - GDPR परिवर्तन
11. डेटा बैकअप
12. एन्क्रिप्शन टूल्स
13. दस्तावेज़ीकरण
14. निष्कर्ष
15. संसाधन

अस्वीकरण

आइए कुछ महत्वपूर्ण स्पष्टीकरण से शुरू करते हैं:

मैं वकील नहीं हूं, और आपको इस लेख को किसी भी तरह से कानूनी सलाह के रूप में नहीं समझना चाहिए।

मैं गलत या भ्रमित हो सकता हूं, इसलिए नीचे दी गई जानकारी पर आंख बंद करके भरोसा न करें।

यह लेख मुख्य रूप से वेबसाइटों और ब्लॉग चलाने वाले व्यक्तियों के लिए है, कंपनियों के लिए नहीं।

60 सेकंड में GDPR

यदि आपने पहले से GDPR के बारे में नहीं सुना या पढ़ा है, तो यहां इसका संक्षिप्ततम संस्करण है। General Data Protection Regulation (GDPR) डेटा सुरक्षा और गोपनीयता पर एक नया EU विनियमन है। यह 25 मई, 2018 को प्रभाव में आया। यह EU/EEA नागरिकों और निवासियों के व्यक्तिगत डेटा को संभालने के आसपास अतिरिक्त पारदर्शिता और विकल्प प्रदान करने के लिए डिज़ाइन किया गया है। विनियमन व्यवसायों को व्यक्तिगत डेटा को कैसे संभालते हैं, संग्रहीत करते हैं और उपयोग करते हैं, इस पर अतिरिक्त सुरक्षा उपाय और स्पष्टीकरण पेश करने की आवश्यकता है। जोर व्यक्तिगत पर है। व्यक्तिगत नहीं = समस्या नहीं।

GDPR किसी भी व्यक्ति पर लागू होता है जो व्यक्तिगत डेटा को संभालता, संग्रहीत करता है या उपयोग करता है। इसलिए यदि आप पूछने वाले हैं कि क्या विनियमन आप पर लागू होता है (आप, एक छोटे ब्लॉग वाले व्यक्ति जो खाना पकाने, यात्रा या IT मरम्मत पर है), तो जवाब निम्नलिखित प्रश्न में निहित है: क्या आप EU/EEA नागरिकों और निवासियों के व्यक्तिगत डेटा को संभालते, संग्रहीत करते हैं या उपयोग करते हैं?

उस प्रश्न का जवाब तुच्छ नहीं है।

यदि आप व्यक्तिगत डेटा प्रोसेस कर रहे हैं तो क्या?

इससे पहले कि हम हां या ना कह सकें, आइए एक त्वरित हां मान लें।

GDPR डेटा प्रोसेसिंग को नहीं रोकता - इसके लिए पारदर्शिता और अतिरिक्त सुरक्षा की आवश्यकता होती है। दूसरे शब्दों में, आपको व्यक्तिगत डेटा का उपयोग करने के अपने कारणों को उचित ठहराने में सक्षम होना चाहिए, यह समझाना चाहिए कि आप ऐसा क्यों और कैसे करते हैं, और डेटा की सुरक्षा के लिए तंत्र होने चाहिए। इन आवश्यकताओं को मोटे तौर पर इस प्रकार परिभाषित किया जा सकता है:

1. जानने की आवश्यकता - यदि आप डेटा संभाल रहे हैं, तो इसका एक कारण होना चाहिए।
2. गोपनीयता - यदि आप डेटा संभाल रहे हैं, तो इसे कम व्यक्तिगत बनाने का प्रयास करें।
3. सुरक्षा - यदि आप डेटा संभाल रहे हैं, तो इसे सुरक्षित होना चाहिए।

ऑनलाइन पढ़ते हुए, मैंने देखा है कि बहुत से लोग डेटा हैंडलिंग के बारे में वास्तव में परेशान हो जाते हैं। वे तुरंत मान लेते हैं कि डेटा हैंडलिंग गलत है और इससे बचा जाना चाहिए। सही दृष्टिकोण है - अत्यधिक और अनावश्यक डेटा हैंडलिंग से बचा जाना चाहिए।

यदि आपको व्यक्तिगत डेटा के कुछ टुकड़ों की आवश्यकता है, तो आपको उनकी आवश्यकता है। यह ठीक है। यदि आपके पास वैध व्यावसायिक हित हैं, तो आप उनका प्रयोग करते हैं। बात यह है कि GDPR अस्तित्व में आया क्योंकि बहुत सारे व्यवसाय वास्तव में एक सच्चे, वास्तविक, मुख्य व्यावसायिक आवश्यकता के बिना व्यक्तिगत डेटा के साथ खेल रहे थे - इसलिए उन सभी गोपनीयता घोटालों के बारे में जो आप पढ़ रहे हैं। मान लीजिए आपके पास एक प्लंबिंग व्यवसाय है। क्या आपको अपने ग्राहकों की उम्र या सामाजिक रुचियों को जानने की आवश्यकता है? नहीं। लेकिन फिर, यदि आप टी-शर्ट बेचते हैं, तो क्या आपको उनका लिंग और संभवतः उम्र और भौतिक पता जानने की आवश्यकता है ताकि माल भेजा जा सके? हां, आप करते हैं।

यदि आप डेटा संभालते हैं, तो सुनिश्चित करें कि आप इसके बारे में पारदर्शी हैं (जानने की आवश्यकता)। और फिर, इसकी रक्षा करें। इस लेख में, मैं अनामकरण (व्यक्तिगत सामान को गैर-व्यक्तिगत बनाना) और एन्क्रिप्शन (व्यक्तिगत डेटा को कम दृश्यमान/सुलभ बनाना) जैसी अवधारणाओं का उपयोग करूंगा।

यह जुर्माने के बारे में भी नहीं है

यह विनियमन का एक और गर्म तत्व है। भारी जुर्माने। संख्याएं डरावनी हैं। लेकिन उन पर ध्यान केंद्रित करना गलत दृष्टिकोण है। आप कानून और संबंधित सजा की जांच नहीं करते और फिर तय करते हैं कि आपको कुछ सही या गलत करना चाहिए। आप चोरी से इसलिए परहेज नहीं करते क्योंकि जेल की सजा लंबी हो सकती है। आप ऐसा नहीं करते, क्योंकि यह गलत है। यहां भी यही बात है। आपको GDPR का पालन इसलिए नहीं करना चाहिए क्योंकि इसके साथ जुर्माने आते हैं। इसे एक बेहतर, पारदर्शी ऑनलाइन उपस्थिति बनाने के अवसर के रूप में देखें।

यह प्रक्रिया दर्दनाक और महंगी हो सकती है, इसलिए यह सब हमारे मूल प्रश्न पर वापस जाता है - व्यक्तिगत डेटा। क्या आप इसे संभाल रहे हैं?

डेटा फ्लो का पालन करें

उपरोक्त प्रश्न का उत्तर देने के लिए कई स्तरों के स्पष्टीकरण की आवश्यकता है:

1. क्या व्यक्तिगत डेटा के रूप में वर्गीकृत होता है?
2. क्या आपकी वेबसाइट में ऐसे तंत्र हैं जो व्यक्तिगत डेटा एकत्र करते हैं?

पहले उप-प्रश्न का उत्तर भी तुच्छ नहीं है। व्यक्तिगत डेटा वह कुछ भी है जो किसी व्यक्ति की पहचान कर सकता है। अधिकांश कानूनी शब्दावली की तरह, परिभाषा अस्पष्ट है। सबसे अच्छा जवाब है, यदि आप निश्चित नहीं हैं, या यदि आपको संदेह है, तो यह मान लेना सबसे अच्छा है कि जानकारी का एक निश्चित "अस्पष्ट" टुकड़ा वास्तव में व्यक्तिगत डेटा के रूप में उपयोग किया जा सकता है।

एक अच्छा उदाहरण कंप्यूटर का IP एड्रेस है। तकनीकी शब्दों में, यह आपके फोन नंबर की तरह है। यह एक नंबर (पता) है जो कंप्यूटर को एक दूसरे के साथ संवाद करने की अनुमति देता है, और यह आपके डिवाइस को विशिष्ट रूप से पहचानता है। तो हां, कुछ परिस्थितियों में, किसी व्यक्ति की पहचान करने के लिए इसका उपयोग किया जा सकता है, उसी तरह जैसे आपके फोन नंबर को आपके अनुबंध या बिल या इसी तरह से ट्रेस किया जा सकता है।

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

यह हमें दूसरे उप-प्रश्न पर लाता है। कुछ (शायद अधिकांश) ब्लॉगर्स ने अपना बुनियादी ढांचा स्थापित नहीं किया होगा, और किसी और द्वारा बनाए गए प्लेटफॉर्म का उपयोग कर रहे होंगे - एक ब्लॉगिंग प्लेटफॉर्म, एक ठेकेदार द्वारा बनाई गई वेबसाइट, आदि। वे शायद यह भी नहीं जानते कि पृष्ठभूमि में क्या हो रहा है।

और इसीलिए हमें डेटा ट्रेल का पालन करना चाहिए।

यदि आप यह पता लगाना चाहते हैं कि GDPR आपकी साइट/ब्लॉग पर लागू होता है या नहीं - और यदि हां, तो यह सुनिश्चित करने के लिए आपको क्या करने की आवश्यकता है कि आप अनुपालन कर रहे हैं - तो आइए इंटरनेट ट्रैफिक की यात्रा का पालन करें - एक जिज्ञासु उपयोगकर्ता से आपकी साइट तक।

वेबसाइट से कनेक्शन

तकनीकी विवरण में जाए बिना, जब आप किसी वेबसाइट पर जाते हैं, मान लीजिए dedoimedo.com, तो होता क्या है, आपका ब्राउज़र इंटरनेट एड्रेस बुक (जिसे DNS कहा जाता है) का उपयोग करके यह पता लगाता है कि dedoimedo.com व्यापक इंटरनेट पर कहां पाया जा सकता है, और फिर इस पते से संपर्क करता है। यदि सब कुछ ठीक से कॉन्फ़िगर किया गया है, तो Web Server नामक सॉफ्टवेयर का एक टुकड़ा इस संपर्क अनुरोध को स्वीकार करेगा और वेब पेजों के रूप में जानकारी वापस करेगा, जैसे आप अभी पढ़ रहे हैं।

जब आप किसी Web Server से कनेक्शन शुरू करते हैं, तो आपका ब्राउज़र कुछ आवश्यक जानकारी भेजता है, जिसमें आपका IP एड्रेस, आपका ऑपरेटिंग सिस्टम, आपका ब्राउज़र वर्जन, और कुछ अतिरिक्त डेटा शामिल होता है। प्रत्येक ब्राउज़र का अपना तथाकथित हस्ताक्षर (यूजर एजेंट) होता है, जो Web Server को सर्वोत्तम सामग्री प्रदान करने में मदद करता है।

Web Server कनेक्शन को अपने डेटा लॉग में लॉग करते हैं। अक्सर, यह इसके लिए आवश्यक है: 1) सुरक्षा कारण, क्योंकि हैकिंग, धोखाधड़ी के मामले में आपको एक निशान की आवश्यकता होती है 2) तकनीकी समस्याएं 3) वेब ट्रैफिक संतुलन 4) अनुपालन और ऑडिटिंग।

हमने IP एड्रेस का उल्लेख किया। तो हम जानते हैं कि सर्वर के साथ व्यक्तिगत जानकारी का एक टुकड़ा पहले से ही लॉग किया जा रहा है, इसलिए GDPR चलन में आता है। लेकिन रुकिए। हमें पूरी तरह से समझने की जरूरत है कि क्या यह वास्तव में लागू होता है। इसलिए, निम्नलिखित प्रश्न:

• क्या आपके पास Web Server लॉग तक पहुंच है?
• यदि हां, तो क्या आपके पास इस बात पर कोई नियंत्रण है कि Web Server लॉग कैसे बनाए, संग्रहीत आदि किए जाते हैं?

इन प्रश्नों का कारण यह है कि लोगों के लिए मोटे तौर पर दो प्रकार की वेब सेवाएं उपलब्ध हैं। उनके अपने सर्वर हो सकते हैं या वे किसी और के सर्वर का उपयोग कर सकते हैं। बाद को होस्टिंग के रूप में जाना जाता है, और आप किसी होस्टिंग प्रोवाइडर को अपने Web Server को सेट अप और बनाए रखने के लिए भुगतान कर सकते हैं। बहुत बार, ये शेयर्ड सेवाएं होती हैं। आप GoDaddy, Digital Ocean, Media Temple, आदि के साथ होस्टिंग कर सकते हैं।

यदि आपकी अपनी वेबसाइट है, तो चीजें अधिक जटिल हैं। लेकिन इसका शायद यह भी मतलब है कि आप एक तकनीक-प्रेमी व्यक्ति हैं, क्योंकि Web Server स्थापित करना कोई तुच्छ बात नहीं है।

यदि आप किसी होस्टिंग कंपनी को अपने ब्लॉग को स्थापित करने के लिए बुनियादी ढांचा देने के लिए भुगतान कर रहे हैं, तो GDPR के लिए पूरी जिम्मेदारी केवल आपकी नहीं है। आपके होस्टिंग प्रोवाइडर की भी जिम्मेदारी है, क्योंकि उनका बुनियादी ढांचे पर नियंत्रण है।

यदि आपके पास सर्वर लॉग तक पहुंच नहीं है, तो यह आपकी चिंता नहीं है। यदि आपके पास पहुंच है - कुछ होस्टिंग प्रोवाइडर अपने उपयोगकर्ताओं को सीमित पहुंच की अनुमति देते हैं - क्या आपके पास कोई नियंत्रण है? काफी संभावना है, आप इन लॉग से किसी भी डेटा को हटाने या यह बदलने में सक्षम नहीं होंगे कि क्या और कैसे लॉग किया जाता है। फिर, यह मुख्य रूप से सुरक्षा कारणों से है, और यह ठीक है।

लेकिन फिर, क्या आप Web Server लॉग का उपयोग कर रहे हैं?

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

यदि आप ऐसा कर रहे हैं, तो आप व्यक्तिगत डेटा प्रोसेस कर रहे हैं - और इसलिए आपको GDPR अनुपालन करने की आवश्यकता है।

AWStats एक अच्छा उदाहरण है, क्योंकि यह एक लोकप्रिय टूल है। लेकिन यह अनुवर्ती प्रश्नों की एक पूरी श्रृंखला भी खोलता है। यदि आप व्यक्तिगत डेटा प्रोसेस कर रहे हैं, तो आपके पास डेटा सुरक्षा के आसपास क्या सुरक्षा उपाय हैं? क्या आप अपनी साइट के आंकड़े सार्वजनिक रूप से साझा करते हैं?

AWStats सरल और मैत्रीपूर्ण है - लेकिन यह डेटा को प्लेन टेक्स्ट के रूप में संग्रहीत करता है, उदाहरण के लिए। यह एक समस्या हो सकती है, क्योंकि GDPR उन्नत गोपनीयता और डेटा सुरक्षा तंत्र निर्धारित करता है। हमने अनामकरण और एन्क्रिप्शन का उल्लेख किया, और AWStats इन दोनों को संतुष्ट नहीं करता।

इसलिए यदि आप AWStats (या इसी तरह के) जैसे टूल का उपयोग कर रहे हैं, तो आपको यह देखने की आवश्यकता होगी कि क्या उनके पास कुछ प्रकार की जानकारी, जैसे IP एड्रेस, को डी-सेलेक्ट करने के लिए एक (अपेक्षाकृत आसानी से) कॉन्फ़िगर करने योग्य विकल्प है, और क्या पार्स किया गया डेटा एन्क्रिप्टेड फाइलों में रखा जा सकता है। यदि नहीं, तो आपको वेब सर्वर लॉग का विश्लेषण नहीं करना चाहिए, यदि आपके पास उन तक पहुंच है, क्योंकि आप तब GDPR जिम्मेदारी के हिस्से को पूरी तरह से अपने होस्टिंग प्रोवाइडर के हाथों से अपने हाथों में स्थानांतरित कर रहे हैं। मजेदार नहीं, लेकिन फिर हम थोड़ी देर बाद साइट आंकड़ों के अन्य प्रकारों के बारे में बात करेंगे।

पेज लोड हो रहा है

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

प्रत्येक प्रदर्शित वेब पेज का एक दृश्य भाग होता है (जो आप देखते हैं) और अदृश्य भाग - वेब भाषा निर्देश और घोषणाएं और विभिन्न स्क्रिप्ट्स। वेब पेज HTML/CSS भाषा में लिखे जाते हैं और वे अक्सर Javascript भाषा में लिखी गई स्क्रिप्ट्स लोड करते हैं।

आप आधुनिक ब्राउज़र में उन्नत डेवलपर टूल्स का उपयोग करके किसी भी पेज की लोडिंग का अनुसरण कर सकते हैं। उदाहरण के लिए, Firefox और Chrome दोनों ये टूल्स प्रदान करते हैं। राइट-क्लिक > Inspect। यह तकनीकी सामग्री से भरा एक अलग पेज खोलेगा, जिसमें एक कंसोल शामिल है जो लोड किए गए संसाधनों का क्रम दिखा सकता है। यह आपके पेजों का बैकएंड है, और यह दृश्य भाग से पूरी तरह से अलग है।

कृपया ध्यान दें: यदि आपने कभी भी ऐसा नहीं किया है, तो आपकी साइट के निष्पादन प्रवाह को समझने का कार्य आसान नहीं होने वाला है। यदि आप तकनीक-प्रेमी नहीं हैं, तो आप संघर्ष करेंगे। हालांकि, यदि आप GDPR-अनुपालन करना चाहते हैं, तो आपको यह जानना होगा कि आपकी साइट क्या कर रही है यह तय करने के लिए कि विनियमन आप पर लागू होता है या नहीं। यदि आप पहले से ही जानते हैं, तो यह बहुत अच्छा है, क्योंकि तब आप वास्तविक डेटा पर ध्यान केंद्रित करना चाहते हैं।

मैं आपको अपनी वेबसाइट का उदाहरण दूंगा। यह सबसे अच्छा या सबसे प्रतिनिधि उदाहरण नहीं है, क्योंकि dedoimedo.com मुख्य रूप से बिना किसी उपयोगकर्ता इंटरैक्शन के एक स्टेटिक साइट है। मेरा कोई पंजीकृत उपयोगकर्ता नहीं है, मैं टिप्पणियों का उपयोग नहीं करता, और डेटा एक्सचेंज भाग बहुत सीमित है। फिर भी, मुझे विश्वास है कि यह एक उपयोगी अभ्यास है, क्योंकि एक प्रतीत होता है निर्दोष साइट में कई डेटा-संग्रह वैक्टर हो सकते हैं जिन्हें ध्यान में रखने की आवश्यकता है।

मेरे पेज लोडिंग को देखते हुए, सामान्य रूप से, फ्लो (दृश्य और अदृश्य दोनों तत्व) कुछ इस तरह होगा (वर्तमान क्षण के लिए विशिष्ट विवरणों के बारे में चिंता न करें, हम प्रासंगिक लोगों के बारे में विस्तार से बात करेंगे):

• पेज हेडर (शीर्षक, विवरण, आदि)।
• Google Analytics (वेबसाइट ट्रैफिक विश्लेषण)।
• Google Custom Search Engine (लोगों को मेरी साइट पर सामग्री खोजने की अनुमति देता है)।
• मुख्य सामग्री (लेख पाठ और छवियां, जैसे आप अभी पढ़ रहे हैं)।
• Google Adsense (इनलाइन रखे गए विज्ञापन ब्लॉक)।
• अधिक मुख्य सामग्री (अधिक पाठ और प्यारी छवियां)।
• ShareThis बटन (शेयरिंग बटन जो लोगों को मेरी सामग्री को सोशल नेटवर्क पर साझा करने की अनुमति देते हैं)।
• Matched Content (मेरी साइट से संबंधित लेख और कुछ Google विज्ञापन दिखाने वाला Google कोड चलाता है)।
• Cookie Control स्क्रिप्ट (ओवरले एप्लेट जो उपयोगकर्ताओं को चुनने देता है कि कुकीज सेट करनी हैं या नहीं)।

Google Analytics

Web Server लॉग याद हैं? खैर, कुछ लोगों के पास पहुंच हो सकती है, कुछ के पास नहीं, कुछ के पास मैन्युअल विश्लेषण टूल्स स्थापित करने के लिए आवश्यक तकनीकी ज्ञान हो सकता है या नहीं। यहीं पर Google Analytics आता है। यह शायद सबसे लोकप्रिय साइट ट्रैफिक आंकड़ों का टूल है। कॉन्फ़िगरेशन सरल है - आप बस हर वेब पेज पर कोड का एक टुकड़ा जोड़ते हैं, और हो गया! आप जीतते हैं, और Google जीतता है, क्योंकि उन्हें डेटा पसंद है।

Google Analytics कई प्रकार के कोड प्रदान करता है। अतीत में, Google Analytics Urchin नामक टूल पर आधारित था, और आपके पेजों में जोड़े गए कोड स्निपेट ने इसे प्रतिबिंबित किया। फिर, कई साल पहले, Google ने Urchin को हटा दिया, हालांकि कार्यक्षमता (अभी के लिए) उन वेबसाइटों के लिए बैकवर्ड कम्पैटिबिलिटी के लिए सक्रिय रहती है जो अभी भी इसका उपयोग कर रही हैं। Urchin का उत्तराधिकारी Universal Analytics है। हाल ही में, Google ने Global Site Tag भी पेश किया, जो अतिरिक्त सुविधाएं और साइट माप क्षमताएं प्रदान करता है। फिर, कुछ अन्य विधियां भी हैं। कोड के तीन मुख्य टुकड़े इस प्रकार दिखते हैं।

Urchin (urchin.js):

<script src="https://www.google-analytics.com/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-xxxxxx";
urchinTracker();
</script>

Universal Analytics (analytics.js):

<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-xxxxxx', 'auto');
ga('send', 'pageview');
</script>

Global Site Tag (gtag.js):

<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());

gtag('config', 'UA-xxxxxx');
</script>

ये कोड के डिफ़ॉल्ट स्निपेट हैं, और इन्हें काम करने के लिए, आपको xxxxxx अक्षरों को अपने Google Analytics कोड से बदलने की आवश्यकता है। डिफ़ॉल्ट रूप से, Google Analytics कुकीज सेट करता है और कुछ जानकारी एकत्र करता है। इसलिए हमें यह समझने की आवश्यकता है: a) कुकीज क्या हैं? b) एकत्र की गई जानकारी व्यक्तिगत है या नहीं?

उस प्रश्न का उत्तर देने के लिए, हमें दो चीजों पर ध्यान केंद्रित करने की आवश्यकता है: वह कोड जो आप चलाते हैं और वह सामान जो Google Analytics के अंदर होता है। सरल जवाब है: डिफ़ॉल्ट रूप से, Google Analytics IP एड्रेस के अलावा व्यक्तिगत डेटा के किसी भी विश्लेषण के लिए कॉन्फ़िगर नहीं किया गया है। वास्तव में, Google ने अपने टूल्स को GDPR-अनुपालन बनाने के लिए बहुत काम किया है, और यह Google Analytics एडमिन डैशबोर्ड में उपलब्ध विकल्पों में परिलक्षित होता है। आइए उससे शुरू करें।

व्यक्तिगत डेटा संग्रह कई वैक्टर में आता है - और यदि आप इनका उपयोग करते हैं, तो आपको अपने EU उपयोगकर्ताओं को सूचित करना होगा और डेटा एकत्र करने के लिए उनकी अनुमति (सहमति) मांगनी होगी। इसका मतलब है कि एनालिटिक्स स्क्रिप्ट का निष्पादन उपयोगकर्ता की पसंद पर निर्भर है। दूसरे शब्दों में, यदि कोई अपना व्यक्तिगत डेटा एकत्र नहीं करना चाहता है, तो एनालिटिक्स स्क्रिप्ट नहीं चलेगी, और आपने उस विशेष उपयोगकर्ता पर कोई आंकड़े एकत्र नहीं किए होंगे।

तो आपके पास एक विकल्प है:

1. उपयोगकर्ता सहमति लंबित व्यक्तिगत डेटा एकत्र करें; संभवतः कम एकत्र करें (सैद्धांतिक रूप से EU से उतना ही जितना कुछ भी नहीं)।
2. व्यक्तिगत डेटा एकत्र न करें - जिस स्थिति में GDPR खंड लागू नहीं होते।

Google Analytics और व्यक्तिगत डेटा

आप Google Analytics को गैर-व्यक्तिगत साइट ट्रैफिक आंकड़ों के टूल के रूप में चला सकते हैं। इसका मतलब है कि आपके पास विजिट और पेज की संख्या, रीयल-टाइम ट्रैफिक और कुछ अन्य मेट्रिक्स पर जानकारी होगी, लेकिन आपके उपयोगकर्ताओं पर कुछ भी नहीं होगा। आइए देखें कि आपको Google Analytics डैशबोर्ड में ऑनलाइन क्या करने की आवश्यकता है। Google के पास एक बहुत विस्तृत FAQ है जो बताता है कि आप क्या कर सकते हैं और क्या नहीं - और क्या करना चाहिए।

Google Analytics आपको विज्ञापन और रीमार्केटिंग = व्यक्तिगत डेटा का उपयोग करने की अनुमति देता है। आप इन्हें बंद कर सकते हैं।

आपको एक रिटेंशन पॉलिसी सेट करने की आवश्यकता है (पुराना डेटा हटा दिया जाएगा)। इसका मतलब है कि आप सेट रिटेंशन अवधि से पहले पुराने ऐतिहासिक डेटा के आधार पर विश्लेषण नहीं कर पाएंगे, लेकिन फिर से, यह डेटा प्रोसेसिंग की मात्रा को कम करने में मदद करता है, जो हम चाहते हैं (वैसे भी प्रासंगिक नहीं यदि आप अगले चरण का पालन करते हैं)। फिर भी, सावधानी के पक्ष में गलती करना और गोपनीयता के प्रति जागरूक होना हमेशा सर्वोत्तम होता है।

फिर, User-ID चरण भी है। Google पहले से ही किसी भी डेटा का उपयोग करने से रोकता है जो लोगों की पहचान कर सकता है, लेकिन यदि आप इस फीचर का उपयोग करते हैं, तो आपको सहमति मांगनी होगी। इसलिए, इस फीचर को बंद पर सेट करने की आवश्यकता है।

आपको यह भी सुनिश्चित करना चाहिए कि आपके पास कोई कस्टम डायमेंशन और मेट्रिक्स नहीं हैं जो संभावित रूप से लोगों की पहचान कर सकते हैं। क्योंकि यदि आपके पास वे हैं, तो आप गैर-व्यक्तिगत स्थान से व्यक्तिगत स्थान में जा रहे हैं। फिर से, यदि आपके पास वे हैं तो यह ठीक है, लेकिन यह एक अलग विषय है। अभी के लिए, हम Google Analytics का उपयोग करके गुमनाम, गैर-व्यक्तिगत डेटा संग्रह पर ध्यान केंद्रित कर रहे हैं।

यह डैशबोर्ड में ऑनलाइन भाग को कवर करता है। लेकिन हमने अभी भी IP एड्रेस और कुकीज के बारे में बात नहीं की है। तो, पूर्व स्पष्ट है। अब, कुकीज ...

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

तकनीकी रूप से, कुकीज में संग्रहीत कुछ जानकारी संभावित रूप से लोगों की पहचान कर सकती है, जिसका अर्थ है, आपको कुकीज सेट करने के लिए उपयोगकर्ताओं से सहमति मांगने की आवश्यकता है। यदि वे सहमत नहीं हैं, तो कुकीज सेट नहीं की जानी चाहिए।

Google Analytics कई कुकीज सेट करता है। इसलिए आपको उपयोगकर्ता से अनुमति मांगने की आवश्यकता है। हालांकि, यह उससे थोड़ा अधिक जटिल है। यहां तक कि यदि आप प्रारंभिक कुकी सेट के लिए सहमति मांगते हैं, जब वेबसाइट पेज लोड होता है, यदि Google Analytics को चलाने की अनुमति दी जाती है, तो यह ब्राउज़िंग सत्र के दौरान कुकीज सेट करेगा, इसलिए आपको वास्तव में उपयोगकर्ताओं से न केवल कुकीज सेट करने बल्कि पहली जगह में Google Analytics चलाने के लिए सहमति मांगने की आवश्यकता है। यह साइट आंकड़ों पर वापस जाता है। यदि उपयोगकर्ता सहमति नहीं देते हैं, तो उनकी विजिट नहीं गिनी जाएंगी (यहां तक कि गैर-व्यक्तिगत भाग भी), और आप अपने आंकड़ों में कम (EU) ट्रैफिक गिना हुआ देखेंगे।

इसलिए यदि आप बिना किसी व्यक्तिगत डेटा संग्रह के Google Analytics चलाने में सक्षम होना चाहते हैं, तो आपको कुकीज अक्षम करने की आवश्यकता है, और हमें IP एड्रेस भाग को भी संभालने की आवश्यकता है - सभी ऑनलाइन कार्य के अलावा।

Google Analytics और लोकल स्टोरेज (कुकीज)

Google Analytics के लिए डेवलपर्स टूल्स सेक्शन में जानकारी का खजाना होता है, जिसमें लोकल स्टोरेज को अक्षम करने की सेटिंग्स शामिल हैं, जिसका अर्थ है कि कोई कुकीज बिल्कुल सेट नहीं की जाएंगी। वास्तव में, Universal Analytics के लिए, आपको निम्न लाइन बदलने की आवश्यकता है:

ga('create', 'UA-xxxxxx', 'auto');

इसे इसमें बदलें:

ga('create', 'UA-xxxxxx', { 'storage': 'none' });

और फिर, कोई कुकीज सेट नहीं की जाती हैं।

IP एड्रेस अनामकरण

Google Analytics IP एड्रेस कैप्चर करता है = व्यक्तिगत जानकारी। लेकिन आप IP एड्रेस को अनामित कर सकते हैं। ऐसा करके, IP एड्रेस, जो aaa.bbb.ccc.ddd जैसा दिखता है, aaa.bbb.ccc.0 बन जाएगा। तकनीकी विवरण में जाए बिना, यह अद्वितीय पहचानकर्ता (IP एड्रेस) को पते के अंतिम खंड (ऑक्टेट) के लिए उपलब्ध 254 पतों के समान बना देगा, जिससे Google Analytics द्वारा देखे गए उपयोगकर्ता की इंटरनेट उपस्थिति IP एड्रेस के माध्यम से गुमनाम हो जाएगी। यह Google Analytics इवेंट को सर्वर पर भेजे जाने से पहले एक लाइन जोड़कर किया जाता है। 'create' लाइन और 'send' लाइन (Universal Analytics) के बाद निम्न लाइन जोड़ें:

ga('set', 'anonymizeIp', true);

कुछ इस तरह:

ga('create', 'UA-xxxxxx', { 'storage': 'none' });
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');

और अब आपके पास Google Analytics के माध्यम से गुमनाम, गैर-व्यक्तिगत डेटा संग्रह है।

इस विधि का नकारात्मक पक्ष यह है कि आपके पास अपने उपयोगकर्ता वफादारी का कोई ज्ञान नहीं होगा। आपकी बाउंस दर (कितने लोग आपकी साइट पर केवल एक पेज के लिए आते हैं और फिर चले जाते हैं) 100% तक बढ़ जाएगी, और औसत सत्र अवधि (साइट पर बिताया गया समय) 0 सेकंड तक गिर जाएगी। लेकिन यह ठीक है, क्योंकि यही वास्तव में हम चाहते हैं। हम केवल समग्र, गैर-व्यक्तिगत ट्रैफिक डेटा चाहते हैं।

यदि आप कुछ डेटा एकत्र करना चाहते हैं (या कुकीज का उपयोग करना चाहते हैं) तो क्या?

उस स्थिति में, आपको Google Analytics स्क्रिप्ट की लोडिंग को स्पष्ट उपयोगकर्ता सहमति पर निर्भर करने की आवश्यकता है। और उस उद्देश्य के लिए, आपको किसी प्रकार के टूल (वास्तव में एक और स्क्रिप्ट) की आवश्यकता है जो Google Analytics के निष्पादन और कुकीज की सेटिंग को तब तक ब्लॉक करे जब तक (और यदि) उपयोगकर्ता ने सहमति नहीं दी है।

मैंने Civic Cookie Control लागू करने का निर्णय लिया, एक टूल जिसे विशेष रूप से GDPR आवश्यकताओं को पूरा करने वाले कुकी अनुपालन की पेशकश करने के लिए डिज़ाइन किया गया है। यह टूल, साथ ही कई अन्य Google Cookie Choices पर सूचीबद्ध हैं। उपलब्ध कुछ समाधानों का परीक्षण करने के बाद, मैंने फैसला किया कि यह मेरी जरूरतों के लिए सबसे पर्याप्त टूल था।

मुझे Cookie Control के बारे में क्या पसंद आया (स्पष्ट तकनीकी बिट्स के अलावा) वह यह है कि PRO वर्जन आपको गैर-EU देशों को फ़िल्टर करने की अनुमति देता है, इसलिए अप्लेट उन उपयोगकर्ताओं को नहीं दिखाया जाता जो GDPR से प्रभावित नहीं हैं। दूसरे शब्दों में, आप चुनिंदा रूप से अपने उपयोगकर्ताओं को कुकी सहमति अप्लेट दिखा सकते हैं। हालांकि एक फ्री वर्जन मौजूद है, यह अधिक सीमित है, और PRO वर्जन सस्ता नहीं है, जो वापस उस बात पर जाता है जो मैंने शुरुआत में उल्लेख किया था: GDPR अनुपालन में पैसा, समय लग सकता है और विशेषज्ञता की आवश्यकता हो सकती है जो अधिकांश व्यक्तिगत ब्लॉगर्स या साइट मालिकों के पास नहीं हो सकती।

मैंने अपनी साइट के हर पेज पर Cookie Control लागू किया - आप शब्दों, स्टाइलिंग को चुन सकते हैं, और आवश्यक श्रेणियां बना सकते हैं। सबसे महत्वपूर्ण बात, प्रत्येक श्रेणी के लिए, आपके पास दो फंक्शन हैं: onAccept और onRevoke। पूर्व केवल तभी कुछ कोड चलाएगा (और कुकीज सेट करेगा) यदि उपयोगकर्ता ने सहमति दी है। और बाद वाला कुकीज को डिलीट करेगा और संभवतः स्क्रिप्ट्स को रोक देगा यदि कोई सहमति नहीं है। इस विशेष टूल का सटीक कॉन्फ़िगरेशन इस लेख के दायरे से बाहर है।

इसलिए यदि आप हर पेज पर Google Analytics + कुकीज चलाना चाहते हैं, तो Cookie Control जैसे टूल के साथ, EU में, घोषणा कुछ इस तरह दिखेगी (Universal Analytics को हमारे उदाहरण के रूप में उपयोग करते हुए):

onAccept : function(){
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-xxxxxx', 'auto');
ga('send', 'pageview');
},
onRevoke: function(){
window['ga-disable-UA-xxxxxx'] = true;
}

यह भी दर्शाता है कि यदि हमें आवश्यकता हो तो कुकी नियंत्रण के अलावा स्क्रिप्ट्स को ब्लॉक करने का विकल्प हमारे पास है [sic]। हम इसे बाद में देखेंगे, जब हम WordPress जैसे Content Management Systems (CMS) पर चर्चा करेंगे।

Cookie Control स्क्रिप्ट मेरी साइट के हर पेज पर घोषित है - यह अन्य थर्ड-पार्टी सामग्री को नियंत्रित करती है, Google Analytics नहीं, क्योंकि मैंने अनामित, गैर-व्यक्तिगत मार्ग चुना है। प्रत्येक पेज पर जोड़ा गया कोड कुछ इस तरह दिखता है (मैंने कोड को एक ही लाइन में रखा है, क्योंकि इससे खोज और प्रतिस्थापन आसान हो जाता है यदि आवश्यक हो):

<script src="https://cc.cdn.civiccomputing.com/9/cookieControl-9.2.min.js"></script>
<script>var config = { apiKey: '3d26a534992cc77791b5baf9525828de5a1213b9', product: 'PRO_MULTISITE', text: { title: 'This site uses cookies.', intro: 'Dedoimedo.com has been designed for ...

BREVITY के लिए LINES REMOVED

... onRevoke: function(){}, thirdPartyCookies: [{"name": "ShareThis", "optOutLink": "https://www.sharethis.com/privacy/"}]}], initialState: "OPEN", position: 'RIGHT', theme: 'LIGHT'}; CookieControl.load( config );</script>

अतिरिक्त Google Analytics पठन

संसाधन अनुभाग में और भी बहुत कुछ है, लेकिन यहां कुछ अतिरिक्त चीजें हैं जिन पर आप विचार करना चाहेंगे। और विचार करने से मेरा मतलब है अपने उपयोगकर्ताओं को सूचित करना कि उनके पास अपनी ब्राउज़िंग को अधिक निजी बनाने और न केवल आपकी साइट पर, बल्कि सामान्य रूप से डेटा संग्रह से ऑप्ट-आउट करने का विकल्प है।

Google Analytics Opt-Out Browser Add-on

Google Custom Search Engine

Google Custom Search Engine (CSE) कोड का एक टुकड़ा है जिसे आप अपने पेजों पर जोड़ सकते हैं, जिससे लोग आपकी साइट पर और/या विश्व स्तर पर सामग्री खोज सकते हैं। नेत्रहीन, यह एक सर्च बॉक्स बनाएगा, और लोग इसे किसी अन्य Google सर्च की तरह उपयोग कर सकते हैं। यहां, हमें खुद से पूछने की जरूरत है: क्या इसमें कोई व्यक्तिगत डेटा संग्रह शामिल है?

<script>
(function() {
var cx = 'partner-pub-123456789:123456789';
var gcse = document.createElement('script');
gcse.type = 'text/javascript';
gcse.async = true;
gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(gcse, s);
})();
</script>
<div class="gcse-searchbox-only"></div>

अब, मुश्किल हिस्सा, Google CSE विज्ञापन भी प्रदर्शित कर सकता है - और यह Google Adsense से जुड़ा हुआ है, जिसके बारे में हमने अभी बात नहीं की है। लेकिन सामान्य तौर पर, Google CSE को एक विज्ञापन फीचर माना जा सकता है, क्योंकि यह वास्तव में Google Adsense डैशबोर्ड के माध्यम से उत्पन्न होता है। तो निश्चित रूप से एक व्यक्तिगत डेटा पहलू है - और कुकीज। हम जानते हैं कि कुकीज को कैसे संभालना है। हमें विज्ञापनों के बारे में बात करने की आवश्यकता है।

Google Adsense

Google Adsense शायद दुनिया का सबसे लोकप्रिय विज्ञापन नेटवर्क है। फिर से, अधिकांश अन्य Google टूल्स की तरह, इसका उपयोग करना बहुत सरल है। आप बस अपने पेजों पर कोड के स्निपेट्स जोड़ते हैं, और जब उपयोगकर्ता आते हैं और विजिट करते हैं, तो उन्हें विज्ञापन प्रदर्शित हो सकते हैं। फिर से, हमें पूछने की जरूरत है, क्या हम व्यक्तिगत डेटा संभाल रहे हैं?

दो प्रकार के विज्ञापन हैं - गैर-व्यक्तिगत (सिर्फ यादृच्छिक सामान) और व्यक्तिगत (उनके पिछले व्यवहार और एकत्रित मेट्रिक्स के आधार पर उपयोगकर्ता को विशेष रूप से लक्षित)। यदि आप अपनी साइट पर Google Adsense के माध्यम से व्यक्तिगत विज्ञापनों की अनुमति देते हैं, तो परोक्ष रूप से, आप व्यक्तिगत डेटा संभालते हैं। लेकिन Google Adsense स्क्रिप्ट्स चलाने के लिए सहमति देना Google Analytics की तुलना में बहुत अधिक कठिन है। एक, विज्ञापनों का प्लेसमेंट महत्वपूर्ण है, एनालिटिक्स के विपरीत, जहां आप बस कोड को कहीं भी रखते हैं, और कार्रवाई उपयोगकर्ता के लिए अदृश्य होती है। दो, यदि उपयोगकर्ता सहमति नहीं देता है, तो विज्ञापन नहीं चलते और दिखते नहीं हैं, और सहमति प्रभावी रूप से एक विज्ञापन अवरोधक बन जाती है, जिसका अर्थ है प्रकाशक के लिए कम राजस्व।

Google को इसका एहसास हुआ, इसलिए उन्होंने सोचा कि उन्हें एक केंद्रीय टूल प्रदान करने की आवश्यकता है जो उनके उपयोगकर्ताओं को यह कॉन्फ़िगर करने की अनुमति दे कि EU उपयोगकर्ताओं को विज्ञापन कैसे परोसे जाते हैं। वास्तव में, GDPR प्रवर्तन के लिए 25 मई की समय सीमा से कुछ समय पहले, Google ने Adsense डैशबोर्ड में एक अलग खंड पेश किया, जो केवल EU उपयोगकर्ताओं को गैर-व्यक्तिगत विज्ञापन परोसने की अनुमति देता है। यह आदर्श तरीका है कि प्रत्येक टूल और सेवा को इसे कैसे संभालना चाहिए, अफसोस यह हमेशा संभव नहीं है।

जैसा कि EU उपयोगकर्ता सहमति टैब बताता है, आपको अभी भी उपयोगकर्ताओं को कुकीज के लिए सहमति देने की आवश्यकता है। यह सर्च इंजन कार्यान्वयन को भी कवर करता है, क्योंकि कुछ कुकीज शेयर्ड हैं, चूंकि CSE विज्ञापन प्रदर्शित कर सकता है। तो हमारे प्रश्न पर वापस जा रहे हैं, हम EU में गैर-व्यक्तिगत विज्ञापनों का उपयोग करते हैं, और हम उपयोगकर्ताओं से कुकीज के लिए सहमति मांगते हैं, जो इस खंड को कवर करता है।

ShareThis बटन

जब मैंने 2018 की शुरुआत में अपनी वेबसाइट को नेत्रहीन रूप से पुनर्निर्मित किया, तो मैंने सामग्री के आसपास उपयोगकर्ता जुड़ाव बढ़ाने के तरीके के रूप में अपने पेजों पर ShareThese इंलाइन बटन स्क्रिप्ट जोड़ी। अनिवार्य रूप से, कार्यक्षमता दो टुकड़ों में आती है, एक HTML तत्व जो बटन दिखाता है और पृष्ठभूमि में चलने वाली स्क्रिप्ट:

<script src="//platform-api.sharethis.com/js/sharethis.js#property=
5a3a29849d192f001374331f&product=inline-share-buttons"></script>

दुर्भाग्य से - और हम इसे पूरे लेख में देखेंगे - ShareThis ने केवल 25 मई, 2018 को GDPR अनुपालन के लिए एक अपडेट जारी किया, और यह मेरे लिए बहुत देर हो चुकी थी। मैं तब तक इंतजार नहीं कर सकता था। मैंने Cookie Control का उपयोग करके सशर्त लोडिंग का उपयोग करके कार्यक्षमता को पहले ही लागू करने का निर्णय लिया, जैसा कि मेरे Google Analytics (कुकीज के साथ) उदाहरण में किया गया था। इसलिए यदि कोई उपयोगकर्ता सहमति देता है, तो बटन दिखाए जाएंगे और कुकीज सेट की जाएंगी, और यदि नहीं, तो वे नहीं होंगे। मैं इस तरह कुछ शेयरिंग/एंगेजमेंट ट्रैफिक खो देता हूं, लेकिन कार्यान्वयन अनुपालन है।

ऊपर दिए गए स्क्रिप्ट को onAccept फंक्शन में रखने से काम नहीं चलेगा। आपको जिस सिंटैक्स की आवश्यकता है वह थोड़ा अलग है, लेकिन यह वास्तव में किसी भी Javascript स्क्रिप्ट पर लागू होता है:

onAccept : function(){var file=document.createElement('script');
file.setAttribute("type","text/javascript");
file.setAttribute("src", "//platform-api.sharethis.com/js/sharethis.js#property=
5a3a29849d192f001374331f&product=inline-share-buttons");
document.getElementsByTagName("head")[0].appendChild(file);},

एक अधिक सार तरीके से:

function(){
    var file=document.createElement('script');
    file.setAttribute("type","text/javascript");
    file.setAttribute("src", "SCRIPT HERE");
    document.getElementsByTagName("head")[0].appendChild(file);
}

मैंने नई ShareThis कार्यक्षमता का भी परीक्षण किया। मैंने इसे आदर्श नहीं पाया, क्योंकि यह अपने स्वयं के ओवरले विंडो के साथ आता है (जो मेरे कुकी अप्लेट से टकराता है), और सहमति के लिए उपयोगकर्ता को दिए गए नियंत्रण की बारीकियां पर्याप्त नहीं हैं (मेरी राय में)। मैं अनुपालन के लिए शेयरिंग ट्रैफिक के नुकसान को स्वीकार करने को तैयार हूं। लेकिन यह एक और अच्छा उदाहरण है जहां नया विनियमन आपकी चल रही गतिविधियों में हस्तक्षेप कर सकता है, जैसे Google Analytics का उपयोग करते समय बाउंस दर और सत्र अवधि बिना कुकीज के।

Matched Content

यह CSE और Adsense के समान ही है। फिर से, Matched Content के लिए कोड Google Adsense डैशबोर्ड में उत्पन्न किया जा सकता है, इसलिए वही नियम लागू होते हैं। आपको EU में गैर-व्यक्तिगत विज्ञापनों का उपयोग करने और कुकीज के लिए उनकी सहमति मांगने की आवश्यकता है। हम यहां तैयार हैं।

अन्य प्रकार के डेटा

उपरोक्त उदाहरण केवल एम्बेडेड सामग्री और स्क्रिप्ट्स के संभावित प्रकारों की एक छोटी संख्या को दर्शाते हैं। वास्तव में, आपके पास एक शॉपिंग कार्ट भी हो सकती है। और यह अगला डेटा प्रकार है जिस पर मैं चर्चा करना चाहूंगा।

आप केवल उन्हें शब्द और छवियां दिखाने के अलावा अन्य तरीकों से अपने उपयोगकर्ताओं के साथ इंटरैक्ट कर सकते हैं। हमने अदृश्य स्क्रिप्ट्स देखी हैं (वे पृष्ठभूमि में चलती हैं), हमने कुकीज देखी हैं, हमने विजिबल थर्ड-पार्टी सामग्री जैसे सर्च और विज्ञापन और शेयरिंग बटन भी संभाले, हमने वास्तव में प्रति से कोई जानबूझकर व्यक्तिगत जानकारी प्रोसेस नहीं की।

ई-कॉमर्स फॉर्म और बटन (PayPal)

इस खंड में मेरा उदाहरण PayPal होगा। वास्तव में, PayPal सबसे लोकप्रिय ऑनलाइन भुगतान सेवाओं में से एक है। वेब पेजों के साथ एकीकरण मृत सरल है। आप अपने पेजों पर कोड कॉपी और पेस्ट करते हैं, और फिर उपयोगकर्ता Buy बटन या Donate बटन का उपयोग करके आपको पैसे भेज सकते हैं। वे अपने यूजरनेम और पासवर्ड से प्रमाणित करते हैं, और एक लेनदेन किया जाता है। पार्टियों के बीच डेटा और पैसा एक्सचेंज होता है।

GDPR शर्तों में, हमारे पास विचार करने के लिए बहुत सी चीजें हैं:

• क्या PayPal फॉर्म का लोडिंग अनुपालन है?
• क्या PayPal कुकीज सेट करता है? संकेत: हां। लेकिन फिर क्या आपको इनके साथ छेड़छाड़ करने की अनुमति है?
• यदि उपयोगकर्ता आपको भुगतान भेजते हैं, तो वे व्यक्तिगत जानकारी प्रदान करते हैं, तो आगे क्या होता है?

अनुपालन के लिहाज से, संक्षिप्त जवाब हां है। इसके अलावा, लोगों को PayPal के नियमों और शर्तों से सहमत होने की आवश्यकता है, जिसका अर्थ है कि यदि वे आपके पेजों पर भुगतान फॉर्म या बटन का उपयोग करते हैं, तो वे पहले ही PayPal को उनकी कुछ जानकारी तक पहुंच के लिए सहमत हो चुके हैं। आप इस डेटा में से किसी के भी विशेषाधिकार प्राप्त नहीं हैं जब तक कि लेनदेन नहीं किया जाता है, और फिर, इस डेटा का केवल एक छोटा सा हिस्सा आपके साथ साझा किया जाता है - जिसकी आपको स्पष्ट व्यावसायिक कारणों के लिए आवश्यकता होती है, जिसमें कर घोषणाएं शामिल हैं। आवश्यकता विवाद में नहीं है (किसी भी रसीद या चालान से अलग नहीं), लेकिन फिर हम डेटा हैंडलिंग पर कुछ और चर्चा करेंगे।

एक और बात जिसका उल्लेख करने की आवश्यकता है वह यह है कि PayPal एक वित्तीय संस्थान है, इसलिए सुरक्षा और धोखाधड़ी-रोकथाम कारणों से कुछ डेटा संग्रह अनिवार्य है। और भले ही आप उनकी सेवाओं (या किसी अन्य ई-कॉमर्स प्लेटफॉर्म) का उपयोग करते हैं, आपके पास वास्तव में इस मामले में ज्यादा कहने का अधिकार नहीं है।

एक बार फॉर्म या बटन लोड हो जाने पर, एक स्क्रिप्ट चलेगी - और यह स्क्रिप्ट संभवतः कुछ महत्वपूर्ण सुरक्षा-संबंधी जानकारी लॉग करेगी। फॉर्म एक कुकी भी सेट करेगा - आपके अपने डोमेन के लिए नहीं बल्कि paypal.com के लिए। और यहां, हमारे पास एक ऐसी स्थिति है जहां हमारे पास एक गैर-वैकल्पिक स्थिति है। अब तक, हम उपयोगकर्ता से सहमति मांग सकते थे या अपने स्क्रिप्ट्स को गैर-व्यक्तिगत तरीके से उपयोग कर सकते थे। लेकिन यहां, हम इसे नियंत्रित नहीं कर सकते। एक आवश्यक कुकी है जो फॉर्म को ठीक से काम करने के लिए आवश्यक है, और PayPal के लिए उनका काम करने के लिए। आपके केवल विकल्प हैं फॉर्म को लोड करने की अनुमति देना (बिना किसी छेड़छाड़ या बदलाव के) या इसे न रखना, लेकिन इसका मतलब सभी व्यवसाय खोना भी हो सकता है।

यह एक ऐसी स्थिति है जहां आवश्यक डेटा संग्रह किया जाता है - सुरक्षा कारणों से। कुकी नियंत्रण टूल्स भी PayPal ऑब्जेक्ट्स को डिलीट नहीं कर पाएंगे भले ही आप चाहें। ब्राउज़र जिस तरह से काम करते हैं, सुरक्षा कारणों से, डोमेन केवल अपने लिए कुकीज डिलीट कर सकते हैं और कुछ नहीं। इसलिए यदि आप एक साइट पेज खोलते हैं, तो यह अन्य साइटों से संबंधित कुकीज के साथ छेड़छाड़ नहीं कर सकता। समझ में आता है, क्योंकि आप नहीं चाहते कि कोई आपके सेशन लॉगिन डेटा को चुरा सके।

तो आप ऐसी स्थिति में क्या करते हैं? खैर, इसके बारे में पारदर्शी रहें। आप अभी भी एक सेवा का उपयोग करते हैं, लेकिन अपने उपयोगकर्ताओं को समझाएं कि आप ऐसा कैसे करते हैं, कौन सा डेटा एकत्र किया जाता है - और सबसे अच्छा, उन्हें संबंधित गोपनीयता नीति पर भेजें ताकि वे पढ़ सकें और समझ सकें कि क्या होता है।

हमने तीन में से दो प्रश्नों का उत्तर दिया। अंतिम है - आपके पास अब कुछ व्यक्तिगत डेटा है, जो सीधे आपकी साइट पर किए गए वित्तीय लेनदेन से संबंधित है। यह आवश्यक डेटा है (जैसे ई-कॉमर्स प्लेटफॉर्म द्वारा सेट की गई आवश्यक कुकीज), और आपको इस डेटा का उपयोग तब करना होगा जब आप कर रिपोर्ट आदि जमा करते हैं। दूसरे शब्दों में, आप इस डेटा को PayPal से, जिसकी अपनी सुरक्षा उपाय हैं डेटा की सुरक्षा के लिए, अपने स्वयं के मशीन पर स्थानांतरित करेंगे, शायद किसी प्रकार का डेस्कटॉप, लैपटॉप या फोन। अब क्या?

याद रखें हमने डेटा संग्रह से संबंधित दो प्रमुख पहलुओं के बारे में बात की थी: अनामकरण और एन्क्रिप्शन। पहला डेटा संग्रह को कम करने के आसपास है (इसे गैर-व्यक्तिगत बनाने की हद तक)। हमने ऊपर अधिकांश चरणों में ऐसा किया, लेकिन हम कोर व्यवसाय से संबंधित कुछ डेटा के साथ समाप्त होते हैं। हम इसे आगे अनामित नहीं कर सकते (यह शायद कर अधिकारियों के साथ एक झंडा उठाएगा, उदाहरण के लिए)। कोई समस्या नहीं। इसलिए हमें इस डेटा की रक्षा करने की आवश्यकता है।

एक बार जब आप PayPal (या किसी अन्य ई-कॉमर्स प्लेटफॉर्म) से फॉर्म या रिपोर्ट डाउनलोड करते हैं, तो आप इसके लिए जिम्मेदार हो जाते हैं। इसलिए आपको यह सुनिश्चित करना होगा कि डेटा हमेशा सुरक्षित रहे। इसका मतलब है, यदि आप गलती से इसे खो देते हैं, या यह चोरी हो जाता है, तो आपको व्यक्तिगत जानकारी की किसी भी पुनर्प्राप्ति को कठिन बनाना होगा। यहीं एन्क्रिप्शन चलन में आता है।

एन्क्रिप्शन एक गणितीय प्रक्रिया है जो मानव-पठनीय डेटा को टेक्स्ट के यादृच्छिक बिट्स में प्रस्तुत करती है जिनका कोई अर्थ नहीं होता और जिन्हें उचित एन्क्रिप्शन कुंजी के बिना समझा नहीं जा सकता। अच्छा एन्क्रिप्शन पारंपरिक कंप्यूटिंग विधियों के साथ तोड़ना लगभग असंभव है। इसके अलावा, चीजों को GDPR-अनुपालन बनाने के लिए, आपको एन्क्रिप्शन कुंजी का एकमात्र मालिक होना चाहिए ताकि केवल आप डेटा खोल सकें। दूसरे शब्दों में, यदि कोई और इस डेटा के कब्जे में आता है, तो यह बेकार होगा।

निचला रेखा: यदि आप डेटा की एक ऑफलाइन प्रति उसके मूल स्रोत (जैसे PayPal ऑनलाइन कंसोल) के बाहर रखते हैं, तो उस डेटा को एन्क्रिप्ट करें। इसे केवल आवश्यक आदान-प्रदान के उद्देश्य के लिए खोलें, जैसे एकाउंटेंट, कर अधिकारियों आदि के साथ। अंतिम चरण में कभी-कभी व्यक्तिगत डेटा को ईमेल या भौतिक मेल के माध्यम से भेजने की आवश्यकता होगी। फिर से, यह कानूनी उद्देश्यों के लिए आवश्यक है, और यह अपरिहार्य है। लेकिन यह ठीक है, क्योंकि व्यक्तिगत डेटा को संभालने वाले अन्य व्यवसाय और संस्थाएं भी GDPR अनुपालन पर अपना हिस्सा रखेंगी, और इसमें आपका ईमेल प्रोवाइडर, आपका एकाउंटेंट, आपकी सरकार शामिल है। विचार है ऐसी कार्रवाइयों को कम करना और उच्च सुरक्षा बनाए रखना (यह एक अस्पष्ट शब्द है, लेकिन हम इस पर नीचे विस्तार से चर्चा करेंगे)। एन्क्रिप्शन पर अनुभाग देखें।

उपयोगकर्ता पंजीकरण

आपकी साइट पर एक उपयोगकर्ता पंजीकरण फॉर्म हो सकता है। आमतौर पर, ऐसे फॉर्म में कम से कम नाम और ईमेल फील्ड होंगे। पंजीकरण फॉर्म में प्रदान किया गया डेटा तब किसी प्रकार के डेटाबेस में सहेजा जाएगा। यदि आपकी साइट पर यह कार्यक्षमता है, तो आपको खुद से निम्नलिखित प्रश्न पूछने की आवश्यकता है:

• क्या आपको वास्तव में पंजीकृत उपयोगकर्ताओं की आवश्यकता है? जवाब केवल हां हो सकता है।
• आपको अपने उपयोगकर्ताओं से कौन सी जानकारी चाहिए? क्या आपका पंजीकरण फॉर्म पर्याप्त 'स्लिम' है?
• क्या आप जानते हैं कि आपका डेटाबेस कहां स्थित है, इसे कैसे एक्सेस करें, संपादित करें और सुरक्षित करें?

हम वापस उसी पर जाते हैं जो हमने पहले चर्चा की थी - अनामकरण और एन्क्रिप्शन। यदि आप जो उपयोगकर्ता डेटा संभालते हैं उसे अपनी ब्लॉग/साइट गतिविधि को नुकसान पहुंचाए बिना कम व्यक्तिगत बना सकते हैं, तो करें। यदि आप इस डेटा को कहीं रखते हैं, तो इसे एन्क्रिप्ट करने का प्रयास करें। अधिकांश लोगों के लिए, शेयर्ड प्रोवाइडर के साथ होस्ट किए गए SQL डेटाबेस को एन्क्रिप्ट करने के बारे में कोई कैसे जाता है, इसका उत्तर बहुत जटिल है। लेकिन। आप इस खेल में अकेले नहीं हैं। आपके प्रोवाइडर की अपनी सेवाओं के संबंध में अपनी जिम्मेदारी है: उन्हें मजबूत और सुरक्षित होने की आवश्यकता है।

आपकी अतिरिक्त GDPR जिम्मेदारी तब चलन में आती है जब आप उपयोगकर्ता डेटा संभालते हैं। दूसरे शब्दों में:

• आपको यह जानने की आवश्यकता है कि उपयोगकर्ता डेटा कहां संग्रहीत है।
• आपको यह जानने की आवश्यकता है कि इस डेटा तक कैसे पहुंचें (और यदि आवश्यक हो तो इसे डिलीट करें)।
• यदि आप इस डेटा का बैकअप लेते हैं (अपने कंप्यूटर, क्लाउड, अन्य सर्वर पर), तो आपको बैकअप के लिए एन्क्रिप्शन की आवश्यकता है।

यदि आप इससे संघर्ष करते हैं, तो आपको इसे करने के लिए एक पेशेवर को नियुक्त करने की आवश्यकता होगी (पैसा, भरोसा, घोटालों से सावधान)। अन्यथा, आप GDPR अनुपालन के संबंध में सर्वोत्तम स्थिति में नहीं हो सकते हैं। यह कठोर और क्रूर लगता है, लेकिन इसके बारे में सोचें: यदि आप अपने उपयोगकर्ता डेटा हैंडलिंग तंत्र के काम करने के तरीके के बारे में अनजान हैं, तो क्या आप वास्तव में चाहेंगे कि लोग आपकी सेवाओं का उपयोग करें? या खुद को उनकी जगह रखें। क्या आप एक साइट पर भरोसा करेंगे जिसे कोई 'आइडिया' नहीं है कि वे उपयोगकर्ता डेटा के साथ क्या कर रहे हैं?

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

सक्रिय उपयोगकर्ता डेटा संग्रह का पहलू निश्चित रूप से केवल पृष्ठभूमि में आपके द्वारा सक्षम निष्क्रिय सेवाओं की तुलना में अधिक जटिल है। इसके लिए कहीं अधिक प्रयास की आवश्यकता होती है। हम Content Management Systems (CMS) पर चर्चा करते समय इस पर कुछ और बात करेंगे।

टिप्पणियां

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

ईमेल (और मेलिंग सूचियाँ)

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

ईमेल में बहुत सारा व्यक्तिगत डेटा भी होता है। एक सामान्य ईमेल में शामिल होगा:

• अंतिम मेल सर्वर का IP एड्रेस (प्रेषक से आपके तक मेल सर्वर की श्रृंखला में)।
• कुछ मामलों में, प्रेषक का IP एड्रेस।
• सिस्टम/मेल क्लाइंट हस्ताक्षर।
• उपयोगकर्ता का ईमेल एड्रेस (स्पष्ट)।
• नाम या उपनाम (वास्तविक या काल्पनिक)।
• वास्तविक सामग्री, जिसमें किसी भी तरीके का व्यक्तिगत डेटा हो सकता है।

इसके अलावा, ईमेल आमतौर पर एन्क्रिप्टेड नहीं होते हैं, इसलिए यदि आपके पास वास्तविक मेल संदेश है तो संदेश स्वयं पठनीय है। रुकिए। घबराएं नहीं। यह अशुभ लगता है, लेकिन ऐसा नहीं है। जबकि संदेश प्लेन टेक्स्ट में लिखे जाते हैं, अधिकांश मेल सिस्टम कनेक्शन स्थापित करने और डेटा भेजने के लिए अतिरिक्त एन्क्रिप्शन का उपयोग करते हैं। हम इसे थोड़ी देर में चर्चा करेंगे।

ठीक है, अब हम क्या करते हैं?

हमें दो मुख्य विषयों को संबोधित करने की आवश्यकता होगी: 1) ईमेल प्राप्त करना और भेजना 2) ईमेल जानकारी संग्रहीत करना।

पहला, आपके द्वारा ईमेल में प्राप्त कुछ डेटा पर आपका कोई नियंत्रण नहीं है। मेल प्रोटोकॉल कुछ बुनियादी फील्ड निर्धारित करते हैं (कार्यक्षमता और सुरक्षा के लिए)। इसके अलावा, यदि आपके पास सार्वजनिक रूप से उपलब्ध/सुलभ ईमेल एड्रेस है, तो आपके पास इस पर कोई नियंत्रण नहीं है कि कौन आपसे संपर्क करता है, या क्यों। यह उपयोगकर्ता की ओर से सहमति का गठन करता है।

GDPR अनुपालन तब चलन में आता है जब आप ईमेल के माध्यम से अन्य लोगों के साथ संपर्क शुरू करते हैं। आपको ऐसा करने के लिए अपने उपयोगकर्ताओं से सहमति की आवश्यकता है। यदि आपके पास उपयोगकर्ता पंजीकरण और टिप्पणियां हैं, तो आप अनिवार्य रूप से कई पंजीकृत उपयोगकर्ताओं के साथ समाप्त होंगे, और आपके पास उनके ईमेल एड्रेस तक पहुंच होगी।

इस डेटा के कब्जे से आपको अपने उपयोगकर्ताओं को जानकारी (अक्सर मार्केटिंग, विज्ञापन और प्रचार) भेजने का अधिकार नहीं मिलता जब तक कि वे स्वीकृति न दें। इसके बारे में सोचें। यदि कोई टिप्पणी लिखने के लिए साइन इन करता है, तो इसका मतलब यह नहीं है कि वे चाहते हैं कि आप उन्हें अपने न्यूज़लेटर से स्पैम करें। उन्हें न्यूज़लेटर के लिए अलग से सहमत होने की आवश्यकता है।

इसे सरल बनाने के लिए: आपको केवल इच्छित उद्देश्य के लिए ईमेल का उपयोग करने की आवश्यकता है:

• यदि कोई आपको लिखता है, तो आप वापस लिखते हैं; पूरी तरह से ठीक, संचार का आदान-प्रदान।
• यदि कोई पंजीकृत होता है, तो आप उनके ईमेल का उपयोग उपयोगकर्ता प्रबंधन उद्देश्यों के लिए कर सकते हैं - ईमेल सत्यापन, उनके खाते के आसपास अधिसूचना, टिप्पणियों पर अधिसूचना, पासवर्ड रीसेट, आदि।
• यदि आप अपने उपयोगकर्ताओं को अन्य जानकारी भेजना चाहते हैं, तो आपको उनसे सहमति मांगने की आवश्यकता है। कुकीज की तरह।

और यह ईमेल एक्सचेंज का काला जादू है। आप मेलिंग सूचियों का उपयोग कर सकते हैं। आप न्यूज़लेटर्स का उपयोग कर सकते हैं। आपको इन सूचियों को अपने उपयोगकर्ताओं की स्पष्ट स्वीकृति के साथ बनाना होगा। सरल।

दूसरा भाग है: डेटा हैंडलिंग। ईमेल डेटा किसी अन्य व्यक्तिगत डेटा की तरह है। आपको यह सुनिश्चित करने की आवश्यकता है कि आप इसे सुरक्षित रखते हैं। यह ई-कॉमर्स डेटा के समान है। आपको कानूनी और लेखांकन कारणों से ईमेल रखने की सबसे अधिक संभावना होगी। सुनिश्चित करें कि आप इसे सुरक्षित और ऑडिट करने योग्य तरीके से करते हैं:

• एक्सेस: आप मुख्य रूप से दो तरीकों से ईमेल एक्सेस करेंगे: 1) वेब ब्राउज़र के माध्यम से 2) Microsoft Outlook या Mozilla Thunderbird जैसे समर्पित मेल क्लाइंट का उपयोग करके, उदाहरण के लिए। दोनों मामलों में, सुनिश्चित करें कि आप एक सुरक्षित लेयर का उपयोग करके कनेक्ट करते हैं (ब्राउज़र में https:// और मेल क्लाइंट कॉन्फ़िगरेशन में सुरक्षित पोर्ट, जैसे पोर्ट 465 TLS/SSL)। कुछ मामलों में, आपके पास Two-Factor Authentication (2FA) का उपयोग करने का विकल्प भी होगा, जो आपके लॉगिन के खिलाफ हैकिंग प्रयासों को अधिक कठिन बनाता है।
• स्टोरेज: आपका इनबॉक्स सुरक्षित होना चाहिए। यदि आप ऑनलाइन प्रोवाइडर का उपयोग करते हैं (अपने होस्टिंग प्रोवाइडर सहित), तो डेटा की सुरक्षा के लिए उनका अपना उचित परिश्रम और जिम्मेदारी है। जब आप कर सकते हैं तो अपनी सुरक्षा जोड़ें, जैसे 2FA, यदि संभव हो। सबसे महत्वपूर्ण, यदि आप अपने इनबॉक्स की एक ऑफलाइन प्रति रखते हैं (कोई भी मेल क्लाइंट वास्तव में), तो आपको मेलबॉक्स को एन्क्रिप्टेड स्थान पर रखना चाहिए (स्वयं एन्क्रिप्शन कुंजी के एकमात्र मालिक के रूप में)। एन्क्रिप्शन पर बाद में और अधिक।

इसे सारांशित करने के लिए:

• ईमेल का उपयोग इच्छित उद्देश्य के लिए करें (उत्तर दें, खाता समर्थन, मेलिंग सूचियाँ - प्रत्येक की अपनी सहमति के साथ)।
• ईमेल की रक्षा करें (सुरक्षित कनेक्शन, एन्क्रिप्टेड लोकल स्टोरेज, जहां संभव हो अतिरिक्त ऑनलाइन सुरक्षा उपाय)।

एम्बेडेड वीडियो (Youtube)

यह एक दिलचस्प है। Youtube आपको अपने पेजों में वीडियो एम्बेड करने की अनुमति देता है। बुरा नहीं। लेकिन यहां बहुत सी चीजें चलन में आती हैं। Youtube वीडियो विभिन्न तत्वों को जोड़ते हैं: ट्रैकिंग का एक तत्व हो सकता है, जो Youtube को वीडियो सिफारिशें पेश करने की अनुमति देता है; उपयोगकर्ताओं को विज्ञापन दिखाए जा सकते हैं, फिर से विभिन्न प्राथमिकताओं के आधार पर; कुकीज हो सकती हैं; और बहुत कुछ।

यदि आप वीडियो एम्बेड करना चुनते हैं, तो आपको यह समझना होगा कि इन वीडियो का उपयोग इन वीडियो को देखने वाले उपयोगकर्ताओं को प्रोफाइल करने के लिए किस तरह से किया जा सकता है, और यदि व्यक्तिगत डेटा का एक तत्व शामिल है, तो आपको उपयोगकर्ताओं से सहमति मांगने की आवश्यकता है। इसके अलावा, मोटे तौर पर, एम्बेडेड वीडियो के दो प्रकार हैं - फ्लैश-आधारित क्लिप्स (पुराने) और नेटिव HTML5 वीडियो (नए)। यह भी एक बड़ा अंतर बनाता है।

एक फ्लैश-आधारित वीडियो कुछ इस तरह दिख सकता है:

<object width="680" height="412">
<param value="https://www.youtube.com/v/EWrJqUtYW7Y" name="movie" />
<param value="window" name="wmode" />
<param value="true" name="allowFullScreen" />
<embed width="680" height="412" wmode="window" allowfullscreen="true" type="application/x-shockwave-flash" src="https://www.youtube.com/v/EWrJqUtYW7Y"></embed>
</object>

एक HTML वर्जन कुछ इस तरह दिखेगा:

<iframe width="560" height="315" src="https://www.youtube.com/embed/KHG6fXEba0A" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

तो सवाल है - वीडियो को GDPR-अनुपालन कैसे बनाएं?

पहला, फ्लैश क्लिप्स (विशेष रूप से Adobe Flash Player) के संबंध में। सामान्य तौर पर, फ्लैश एक तकनीक के रूप में शायद आगे बढ़ने का सबसे अच्छा तरीका नहीं है, कम से कम जब ऑनलाइन वीडियो की बात आती है। एक दशक से अधिक समय से, यह तकनीक वेब पेजों में इंटरैक्टिव मल्टीमीडिया सामग्री एम्बेड करने के लिए पसंदीदा विधि के रूप में बेहद लोकप्रिय थी, लेकिन हाल के वर्षों में यह धीरे-धीरे चरणबद्ध हो रही है, फ्लैश प्लेयर से जुड़े सुरक्षा मुद्दों के कारण और क्योंकि सभी आधुनिक ब्राउज़र नेटिव HTML5 वीडियो का समर्थन करते हैं।

फ्लैश क्लिप्स कुकीज भी सेट कर सकते हैं - सिर्फ सामान्य कुकीज नहीं - फ्लैश कुकीज। वे प्रकृति में नियमित वेब कुकीज के समान हैं, लेकिन वे अलग से संग्रहीत होती हैं और विशेष रूप से Adobe Flash Player द्वारा उपयोग की जाती हैं। और आपके पास कुकी नियंत्रण टूल्स का उपयोग करके उन्हें नियंत्रित करने का सीधा तरीका नहीं हो सकता है। तो आपको क्या करना चाहिए:

• मौजूदा सभी क्लिप्स को पुराने फॉर्मेट में पुनः एम्बेड करें और इसे नए फॉर्मेट में बदलें।

फिर, यह हमें डेटा संग्रह और कुकीज के परिचित पहलुओं के साथ छोड़ देता है। सौभाग्य से, Youtube शेयरिंग के लिए एक उन्नत गोपनीयता फीचर प्रदान करता है। जब आप ऑनलाइन किसी भी वीडियो के लिए शेयर विकल्प पर क्लिक करते हैं, तो आपके पास वीडियो एम्बेड करने का विकल्प होता है। फिर, आपको उस बॉक्स को टिक करने की आवश्यकता है जिस पर Enable privacy-enhanced mode लिखा है। यह एक अलग एम्बेड कोड उत्पन्न करेगा, और यह कोई कुकीज सेट नहीं करेगा।

गोपनीयता-बढ़ाया कोड तब इस तरह दिखता है:

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/KHG6fXEba0A" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

और इस तरह - इस तथ्य को देखते हुए कि Youtube (Google) GDPR अनुपालन के हिस्से के रूप में थर्ड-पार्टी विज्ञापन परोसने और पिक्सेल ट्रैकिंग का उपयोग नहीं करता है, और हम बिना कुकीज के गोपनीयता-बढ़ाए मोड का उपयोग करते हैं, हमारे पास अब उपयोगकर्ता-अनुकूल एम्बेडेड वीडियो हैं। अन्यथा, आपको पहले की तरह सहमति मांगने की आवश्यकता है।

अंत में, आपके पेजों पर अन्य गैर-मानक, गैर-Youtube फ्लैश क्लिप्स भी हो सकते हैं। उदाहरण के लिए:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase=
"https://active.macromedia.com/flash5/cabs/swflash.cab#version=5,0,0,0" height="550" width="690">
<param name="movie" value="video.swf">
<param name="play" value="true">
<param name="loop" value="false">
<param name="quality" value="low">
<embed src="video.swf" quality="low" loop="false" type=
"application/x-shockwave-flash" pluginspage=
"https://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=
ShockwaveFlash" height="550" width="690">
</object>

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

एम्बेडेड स्क्रिप्ट्स

आप अपने पेजों पर वीडियो के अलावा अन्य सामग्री भी एम्बेड कर सकते हैं। उदाहरण के लिए, पोल, मैप्स, आदि। ये स्क्रिप्ट के किसी रूप में आएंगे, ज्यादातर अक्सर Javascript (something.js)। इन्हें संभालने का सबसे अच्छा तरीका, यदि आप उन्हें चाहते हैं या उनकी आवश्यकता है, तो उपयोगकर्ताओं से सहमति मांगना है, ठीक उसी तरह जैसे हमने ShareThis बटन के साथ किया था। आप जिस भी टूल का उपयोग करते हैं, onAccept फंक्शन में शामिल होगा:

function(){
    var file=document.createElement('script');
    file.setAttribute("type","text/javascript");
    file.setAttribute("src", "SCRIPT HERE");
    document.getElementsByTagName("head")[0].appendChild(file);
}

कंटेंट मैनेजमेंट सिस्टम (CMS): WordPress

यह खंड इस लेख को पढ़ने वाले अधिकांश लोगों के लिए सबसे अधिक रुचिकर होगा। WordPress दुनिया में सबसे लोकप्रिय वेबसाइट और ब्लॉगिंग मैनेजमेंट सिस्टम है। इसका उपयोग करना बहुत आसान है, कॉन्फ़िगर करना अपेक्षाकृत आसान है, और यह उपयोगी प्लगइन्स का खजाना प्रदान करता है। मैं वास्तव में WordPress के साथ प्रदर्शित करूंगा, लेकिन ध्यान दें कि अन्य CMS मौजूद हैं, जैसे Drupal, Joomla!, Magento, phpWiki, और बहुत कुछ।

WordPress ने अपना पहला GDPR-तैयार वर्जन, 4.9.6, 17 मई, 2018 को जारी किया। Wpbeginner.com ने 23 मई, 2018 को GDPR पर एक बहुत उपयोगी गाइड जारी किया, विनियमन के प्रभाव में आने से केवल दो दिन पहले। मेरे स्वयं के परीक्षण और अनुपालन के लिए आवश्यक परिवर्तनों के कार्यान्वयन से इस गाइड के कुछ अंतर दिखाई देते हैं, और इसलिए मैं विस्तार से उन परिवर्तनों और सेटिंग्स को साझा करना चाहूंगा जो मैंने अपनी पुस्तक-लेखन साइट, The Lost Words, को विनियमन के अनुरूप बनाने के लिए किए हैं।

The Lost Words एक काफी सरल WordPress साइट है - कोई उपयोगकर्ता पंजीकरण नहीं। मैंने Disqus प्लगइन का उपयोग करके टिप्पणियां सक्षम की थीं (ऑर्गेनिक टिप्पणियों के बजाय) और MonsterInsights प्लगइन द्वारा Google Analytics for WordPress का उपयोग करके डेटा एनालिटिक्स एकत्र किया (जिसका उल्लेख ऊपर दिए गए गाइड में भी किया गया है)। मैंने GDPR प्रवर्तन तिथि से पहले इन दोनों प्लगइन्स को अक्षम कर दिया था और अनुपालन के लिए वैकल्पिक तरीकों को लागू किया था, और मैं वास्तव में बताऊंगा कि क्या और कैसे।

तो, यात्रा वही है जो हमने पहले की थी - केवल अब हम इसे WordPress के साथ करेंगे। अपनी साइट से कनेक्शन स्थापित करें। डेटा फ्लो को समझने की कोशिश करें। डैशबोर्ड खोलें और अपने इंस्टॉल और सक्रिय प्लगइन्स की जांच करें।

डेटा संग्रह = प्लगइन्स

यदि आप एक या अधिक WordPress प्लगइन्स का उपयोग कर रहे हैं, तो यह काफी संभावना है कि आप डेटा एकत्र कर रहे हैं, संभवतः व्यक्तिगत डेटा। यह सत्यापित करने का सबसे सरल तरीका है कि क्या आपके प्लगइन्स डेटा एकत्र कर रहे हैं, उनकी गोपनीयता नीति पढ़ें, यदि कोई मौजूद है। फिर, आपको यह बेहतर समझने के लिए थोड़े तकनीकी ज्ञान की आवश्यकता हो सकती है कि क्या होता है। और याद रखें, तथ्य यह है कि कोर WordPress GDPR-अनुपालन है इसका मतलब यह नहीं है कि आपके प्लगइन्स - या आपकी गतिविधियाँ - हैं।

मेरे मामले में, मेरे कई प्लगइन्स इंस्टॉल हैं। इनमें से कुछ कोई व्यक्तिगत डेटा बिल्कुल एकत्र नहीं करते। ये ज्यादातर सुरक्षा हार्डनिंग टूल्स हैं, जो वेबसाइट को अधिक मजबूत बनाने के लिए डिज़ाइन किए गए हैं। कुछ प्लगइन्स में डेटा एकत्र करने का एक कॉन्फ़िगरेबल विकल्प होता है (यह वेब सर्वर लॉग के समान है जिन पर हमने चर्चा की थी और Google Analytics विकल्प)। कुछ निश्चित रूप से व्यक्तिगत डेटा एकत्र करते हैं। तो हमारे तीन समूह हैं:

• प्लगइन्स जो व्यक्तिगत डेटा एकत्र नहीं करते (चर्चा से बाहर)।
• प्लगइन्स जो डेटा एकत्र कर सकते हैं - हम उन्हें गैर-व्यक्तिगत उपयोग के लिए कॉन्फ़िगर कर सकते हैं, या व्यक्तिगत डेटा एकत्र कर सकते हैं लेकिन फिर उपयोगकर्ताओं को सूचित करें और उन्हें सहमति देने का विकल्प दें। कुछ स्थितियों में, डेटा आवश्यक हो सकता है। हम जल्द ही इसकी खोज करेंगे।
• प्लगइन्स जो डेटा एकत्र करते हैं - हमें उपयोगकर्ताओं से सहमति मांगनी होगी।

Google Analytics

Google Analytics के माध्यम से वेबसाइट ट्रैफिक आंकड़ों का संग्रह दूसरे समूह में आता है। हमने पहले ही देखा है कि Google Analytics का उपयोग गुमनाम, गैर-व्यक्तिगत डेटा संग्रह तरीके से कैसे किया जाता है। यहां, मैं आपको दिखाऊंगा कि कुकीज के साथ लेकिन बिना व्यक्तिगत डेटा के स्क्रिप्ट कैसे चलाई जाए। हम दोनों को मिलाएंगे।

मैंने Cookie Control के माध्यम से उपयोगकर्ता सहमति के आधार पर Google Analytics की सशर्त लोडिंग को लागू करने का निर्णय लिया, जैसा कि मैंने आपको पहले दिखाया था। मूल रूप से, हम उपयोगकर्ताओं से सहमति मांगते हैं, और यदि वे करते हैं, तो स्क्रिप्ट चलेगी और कुकीज सेट की जाएंगी। हम अभी भी IP एड्रेस अनामकरण का उपयोग करते हैं। Cookie Control, मेरी पसंद का टूल, वास्तव में इस उद्देश्य के लिए एक सहायक उदाहरण है, इसलिए इसे सेट करना आसान होना चाहिए। वास्तविक कॉपी और पेस्ट करने योग्य कोड स्निपेट के लिए पहले देखें।

MonsterInsights क्यों नहीं?

व्यावहारिकता और समयसीमा का एक सरल मामला। मूल रूप से, मेरे पास वास्तव में MonsterInsights द्वारा Google Analytics for WordPress प्लगइन कॉन्फ़िगर किया गया था जो उनके GDPR-तैयार अपडेट जारी करने से पहले भी गैर-व्यक्तिगत डेटा संग्रह (कुकीज को छोड़कर) के लिए था। वास्तव में, प्लगइन अब एक अलग EU Compliance टूल के साथ आता है जो इस संबंध में सब कुछ कॉन्फ़िगर करेगा (स्वचालित रूप से)। यह ऐडऑन पैसा खर्च करता है - और मैंने पहले से ही एक अलग कुकी नियंत्रण समाधान में पैसा लगाया है (जो स्क्रिप्ट्स को भी संभालता है)।

इस पर पढ़ते हुए कि यह क्या करता है, प्लगइन IP अनामकरण, UserID ट्रैकिंग अक्षम करता है और Author ट्रैकिंग अक्षम करता है, यह एक कस्टम डायमेंशन है। आप इनको मैन्युअली संभाल सकते हैं, लेकिन इस प्लगइन के माध्यम से करने का लाभ यह है कि ये परिवर्तन केवल आपके EU विजिटर्स पर लागू होंगे। यदि आप अपने Google Analytics अकाउंट्स के माध्यम से परिवर्तन करते हैं, तो वे वैश्विक होंगे। MonsterInsights by Google Analytics for WordPress कुकी प्लगइन्स के साथ भी एकीकृत होता है। मुझे नहीं पता कि क्या स्क्रिप्ट की कोई सशर्त लोडिंग है, हालांकि।

मेरे लिए, पेश किए गए परिवर्तन थोड़े देर से आए - अधिकांश GDPR टूल्स की तरह, वे प्रवर्तन तिथि से केवल एक छोटे सप्ताह पहले हुए, जो उचित परीक्षण के लिए मुश्किल से पर्याप्त है। इसके अलावा, चूंकि मुझे कुकीज के लिए उपयोगकर्ताओं से सहमति मांगनी थी (हालांकि मैं नो लोकल स्टोरेज विकल्प का उपयोग कर सकता था), तो मैं Google Analytics को Cookie Control के माध्यम से सशर्त रूप से भी लोड कर सकता था, और मैंने पहले से ही इसके लिए मल्टी-साइट लाइसेंस खरीदा था।

तो यह वास्तव में व्यावहारिकता का मामला है। आप MonsterInsights का उपयोग कर सकते हैं (कुछ अतिरिक्त लागत के साथ) और कई कुकी नियंत्रण प्लगइन्स के साथ एकीकृत कर सकते हैं। या आप एक अलग टूल (जैसे मैंने किया) में अपना पैसा निवेश कर सकते हैं, और इसे इस तरह से संभाल सकते हैं, इस लाभ के साथ कि आप Google Analytics की तरह विशेष रूप से नहीं, बल्कि अतिरिक्त स्क्रिप्ट्स और कुकीज को नियंत्रित कर सकते हैं, जैसे ShareThis बटन, जैसा कि हम पहले ही देख चुके हैं।

टिप्पणियां (Disqus)

मैं टिप्पणियों के लिए Disqus चलाता था। दुर्भाग्य से, Disqus ने केवल 25 मई, 2018 को एक अपडेट जारी किया, और यह मेरे लिए बहुत देर हो चुकी थी। इस बिंदु पर, मैंने ब्लॉग पर टिप्पणियों को अक्षम कर दिया था। मैंने फैसला किया कि मैं उन्हें बाद के चरण में फिर से पेश करूंगा, जब मैंने यह सुनिश्चित कर लिया कि WordPress टिप्पणियां या Disqus अनुपालन हैं।

Disqus के लिए GDPR अपडेट से पहले, मैंने Cookie Control और इसके onAccept और onRevoke फंक्शन का उपयोग करके Disqus को 'इंटरसेप्ट' करने की कोशिश की। यह एक मूल्यवान सबक था जिस पर हम शीघ्र ही चर्चा करेंगे। अब, Disqus ने आवश्यक GDPR उपाय पेश किए हैं। यदि आप लॉग इन करना चाहते हैं और टिप्पणी पोस्ट करना चाहते हैं, तो आपको पहले उनकी नई गोपनीयता नीति से सहमत होने की आवश्यकता है। यदि आप पहले से लॉग इन हैं, तो आप टिप्पणी फील्ड नहीं देखेंगे जब तक आप सहमत नहीं होते। और आपके पास ट्रैकिंग से ऑप्ट-आउट करने का विकल्प भी है। एक उपयोगकर्ता के रूप में (कोई Disqus का उपयोग कर रहा है), इस विकल्प का नकारात्मक पक्ष यह है कि आपके पास केवल अस्थायी सत्र लॉगिन होंगे, और आपको हर बार नए सिरे से लॉग इन करना होगा।

Disqus और WordPress डेटाबेस एकीकरण

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

सामान्य स्क्रिप्ट नियंत्रण

आपके WordPress साइट पर अतिरिक्त प्लगइन्स या स्क्रिप्ट्स हो सकती हैं, जिनके पास कोई GDPR सहायक उपकरण नहीं हो सकते हैं। यदि ये प्लगइन्स या स्क्रिप्ट्स व्यक्तिगत डेटा एकत्र करते हैं, तो आपको उनके निष्पादन को तब तक ब्लॉक करना होगा जब तक उपयोगकर्ता ने सहमति नहीं दी है। यह उसी के समान है जिसे मैंने पहले ShareThis बटन के साथ रेखांकित किया था। उस अंत तक, हमें दो WordPress फंक्शन्स - wp_enqueue_script() और wp_deregister_script() के बारे में बात करने की आवश्यकता है।

Wp_enqueue_script

यह फंक्शन आपको मांग पर स्क्रिप्ट चलाने की अनुमति देता है। उपयोग तुच्छ से दूर है, लेकिन यदि आप जानते हैं कि कौन सी स्क्रिप्ट चलाने की आवश्यकता है, तो आप इसे wp_enqueue_script में लपेट सकते हैं और फिर इसे अपने कुकी नियंत्रण टूल के onAccept सेक्शन में रख सकते हैं, जैसा कि हमने पहले किया था।

मुश्किल हिस्सा वास्तव में उस स्क्रिप्ट को ढूंढना है जिसे चलाने की आवश्यकता है। यह ब्राउज़र में वेब कंसोल की जांच करने और यह पता लगाने की कोशिश करने पर वापस जाता है कि आपकी साइट क्या कर रही है। इसके चारों ओर कोई आसान रास्ता नहीं है, खासकर यदि आपके पास प्लगइन्स हैं जो अजीब, अनिर्दिष्ट तरीके से व्यवहार करते हैं। Justin Tadlock ने 2009 में अपनी साइट पर इस पर चर्चा की थी, और यह सलाह का एक अत्यंत मूल्यवान टुकड़ा है। आपकी सशर्त स्क्रिप्ट कुछ इस तरह दिख सकती है:

wp_enqueue_script( 'contact-form-7', wpcf7_plugin_url( 'contact-form-7.js' ), array('jquery', 'jquery-form'), WPCF7_VERSION, $in_footer );

Wp_deregister_script

यह फंक्शन enqueue के विपरीत करता है; यह एक स्क्रिप्ट को हटाता/रोकता है। कुछ इस तरह:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );

function my_deregister_javascript() {
    wp_deregister_script( 'contact-form-7' );
}

सेशन कुकीज

WordPress (और आपके प्लगइन्स और थीम) सेशन कुकीज सेट कर सकते हैं। फिर से, हमें सहमति की आवश्यकता है, जैसे पहले।

WordPress 4.9.6 - GDPR परिवर्तन

उस बात को दोहराने का कोई मतलब नहीं जो पहले लाखों बार कही जा चुकी है। बहुत संक्षेप में, WordPress में अब अतिरिक्त टूल्स हैं जो आपको उपयोगकर्ता डेटा प्रबंधित करने में मदद कर सकते हैं। यदि आपके पास पंजीकृत उपयोगकर्ता हैं, तो आप उन्हें डिलीट कर पाएंगे, और गोपनीयता नीति के लिए एक टेम्पलेट भी है।

डेटा बैकअप

हमने पहले बैकअप के बारे में बात की थी - ईमेल और डेटाबेस के आसपास। सामान्य तौर पर, इस बात की काफी अच्छी संभावना है कि आप अपनी साइट डेटा का बैकअप लेंगे (और इसके साथ उपयोगकर्ता डेटा)। यह एक स्वस्थ, अनुशंसित अभ्यास है। आपके पास बैकअप होना चाहिए। हर तरह से। आपको यह सुनिश्चित करने की आवश्यकता है: अनामकरण और एन्क्रिप्शन।

आपने अनामकरण भाग को पहले ही कवर कर लिया होगा (डिजाइन द्वारा)। एन्क्रिप्शन अगला कदम है। आपके द्वारा किया गया कोई भी डेटा बैकअप जाना चाहिए:

• सुरक्षित, विश्वसनीय और दस्तावेज़ीकृत स्थान।
• किसी के लिए भी सुलभ न हो सिवाय आपके।

इसे प्राप्त करने का सबसे अच्छा तरीका एन्क्रिप्शन के साथ है - और मैं इस तथ्य के बारे में बात नहीं कर रहा हूं कि कुछ बैकअप प्रोवाइडर्स (ज्यादातर क्लाउड) एन्क्रिप्शन प्रदान करते हैं। उदाहरण: आप डेटा का बैकअप Dropbox पर ले रहे होंगे। सेवा सुरक्षित है, यह 2FA और एन्क्रिप्शन प्रदान करती है। इसलिए यदि कोई वास्तव में Dropbox सिस्टम में हैक करता है, तो वे उनके द्वारा चुराए गए किसी भी डेटा को पढ़ नहीं पाएंगे। लेकिन यह पर्याप्त नहीं है। क्योंकि आप एन्क्रिप्शन विधि को नियंत्रित नहीं करते हैं।

समाधान है अपने स्वयं के टूल और कुंजी (पासवर्ड यदि आप चाहें) के साथ बैकअप को एन्क्रिप्ट करना, और फिर, किसी भी कारण से, यदि किसी की इस डेटा तक पहुंच है, तो वे वास्तविक सामग्री तक पहुंच नहीं पाएंगे। और हम अंततः इस तकनीक पर चर्चा कर सकते हैं जिसे एन्क्रिप्शन कहा जाता है।

एन्क्रिप्शन टूल्स

खैर, हमने ऊपर एन्क्रिप्शन के बारे में बहुत बात की। आइए इसे कुछ अच्छे उपयोग में लाएं।

डेटा एन्क्रिप्ट करने के कई तरीके हैं। मैं अब कुछ संभावित टूल्स पर विस्तार से बताऊंगा। कृपया ध्यान दें कि एन्क्रिप्शन टूल्स की गुणवत्ता और सुरक्षा भिन्न हो सकती है। इसके अलावा, विभिन्न डेटा प्रकारों को विभिन्न प्रकार के एन्क्रिप्शन और मानकों की आवश्यकता हो सकती है। कुछ मामलों में, आपको अनुपालन के लिए विशिष्ट विधियों का उपयोग करना पड़ सकता है। सामान्य ब्लॉगर्स के लिए, अधिकांश टूल्स पर्याप्त होने चाहिए। कुछ स्तर के तकनीकी ज्ञान की आवश्यकता है।

सबसे बुनियादी एन्क्रिप्शन विधि पासवर्ड-सुरक्षित ZIP आर्काइव बनाना है। यह फूलप्रूफ नहीं है, लेकिन 7-Zip जैसे टूल अपने नेटिव 7z फॉर्मेट में (फाइलनाम एन्क्रिप्शन सहित) AES-256 विधि का उपयोग करके एन्क्रिप्टेड फाइलें बना सकते हैं, जिसे US सरकार द्वारा अपनाया गया एक एन्क्रिप्शन मानक है। Linux में, आप फाइलों के साथ-साथ ईमेल को एन्क्रिप्ट करने के लिए GPG (GnuPG), OpenPGP मानक का एक मुफ्त कार्यान्वयन, उपयोग कर सकते हैं। कई फ्रंटएंड टूल्स उपलब्ध हैं।

आप एन्क्रिप्टेड कंटेनर भी बना सकते हैं - बड़ी फाइलें जिन्हें आप तब कई अलग-अलग फाइलों को अंदर स्टोर करने के लिए वर्चुअल फोल्डर्स के रूप में उपयोग कर सकते हैं। एक आकस्मिक पर्यवेक्षक के लिए, एक एन्क्रिप्टेड कंटेनर एक रैंडम फाइल की तरह दिखता है, जैसे Documents.bin, 603 MB के आकार के साथ, उदाहरण के लिए। जब आप इसे माउंट करते हैं (इसे एक विशेष प्रोग्राम में खोलते हैं जो एन्क्रिप्टेड फॉर्मेट को पढ़ने और डिक्रिप्ट करने में सक्षम है), तो यह आपके फाइल मैनेजर में एक फोल्डर या एक अलग ड्राइव के रूप में दिखाया जाएगा, और आप इसके साथ किसी अन्य स्थान की तरह इंटरैक्ट कर सकते हैं।

एन्क्रिप्टेड कंटेनर बना सकने वाले फ्रेंडली GUI टूल्स में TrueCrypt और VeraCrypt शामिल हैं, बाद वाला TrueCrypt का एक फोर्क है, जिसे 2015 में बंद कर दिया गया था। जानकारी का यह अंतिम टुकड़ा आपको विराम दे सकता है, क्योंकि आप मान सकते हैं कि इसमें एक अंतर्निहित सुरक्षा जोखिम है। हालांकि, प्रोग्राम के एक स्वतंत्र ऑडिट में कोई महत्वपूर्ण सुरक्षा जोखिम नहीं मिला (अभी के लिए)। ये दोनों प्रोग्राम कई एन्क्रिप्शन मानकों का उपयोग करते हैं, जिनमें AES शामिल है।

एक और Linux टूल - Plasma-आधारित डिस्ट्रिब्यूशन जैसे KDE neon या Kubuntu में Vault, उदाहरण के लिए। यह प्रोग्राम डेस्कटॉप में एकीकृत है और आपको फ्लाई पर एन्क्रिप्टेड कंटेनर बनाने देता है। एन्क्रिप्शन बैकएंड CryFS है, जो AES-256 प्लस एक अन्य सिफर का भी उपयोग करता है।

दस्तावेज़ीकरण

अंतिम टुकड़ा, एक बार जब आप अपनी साइट को अनुपालन बना चुके हैं, तो चीजों को समेटना है। सब कुछ दस्तावेज़ करें, और इसका मतलब गोपनीयता नीति लिखना भी है। यह लंबा या फैंसी होना जरूरी नहीं है। वास्तव में, छोटा और मधुर आगे बढ़ने का सबसे अच्छा तरीका है। आप क्या करते हैं और क्यों, इसके बारे में पारदर्शी रहें, और परिवर्तनों की व्याख्या करें। यदि संदेह में, हमेशा सावधानी के पक्ष में गलती करें। अपने उपयोगकर्ता को विकल्प दें बजाय यह मान लेने के कि यह ठीक है। अंत में, यह आपके कार्यों की पारदर्शिता, उपयोगकर्ता डेटा का अनामकरण (यदि संभव हो) और सुरक्षित हैंडलिंग (एन्क्रिप्शन) के बारे में है।

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

निष्कर्ष

और यहां हम हैं, अंत में। मुझे विश्वास है कि यह लेख उपयोगी रहा है। सरल, स्पष्ट और व्यावहारिक। मैंने यथासंभव अधिक सामग्री को कवर करने की कोशिश की है, अस्पष्ट भाषा से बचा है, और अपने स्वयं के ब्लॉगिंग रोमांच से वास्तविक जीवन के, संबंधित उदाहरण प्रदान किए हैं। GDPR अनुपालन एक तुच्छ चीज नहीं है। इसके लिए मानसिक और तकनीकी प्रयास की आवश्यकता होगी, इसके लिए घंटों काम की आवश्यकता होगी, और यह आपको पैसे भी खर्च करवा सकता है, प्रत्यक्ष निवेश और पोस्ट-अनुपालन ट्रैफिक परिवर्तनों दोनों में। लेकिन आपके पास एक अच्छी, साफ-सुथरी साइट होगी जो आपके उपयोगकर्ताओं के लिए मैत्रीपूर्ण और मजेदार है।

कोई शॉर्टकट नहीं हैं। इस यात्रा में सबसे महत्वपूर्ण चीज शिक्षा है। अज्ञानता भय पैदा करती है। लेकिन यदि आप यह समझने के लिए समय लेते हैं कि आप क्या कर रहे हैं - और आपकी साइट क्या कर रही है - तो आप अपने काम और परिणाम दोनों का आनंद लेंगे। इसका मतलब है वहां मौजूद त्वरित वादों और सिल्वर-बुलेट समाधानों के आसपास सावधान रहना। जल्दबाजी न करें, अपना समय लें, अपनी साइट को अनुपालन बनाने के लिए सर्वोत्तम, सबसे सुंदर तरीका खोजने का प्रयास करें। अंत में, यदि इस विषय पर आपकी कोई प्रतिक्रिया, सुझाव या अनुरोध है, तो बेझिझक मुझसे संपर्क करें, और मैं इस गाइड को अपडेट करने का प्रयास करूंगा। ध्यान रखें, इंटरनेट के बच्चों।

संसाधन

उपस्थिति और प्रासंगिकता के क्रम में (पूरे दस्तावेज़ में अधिकांश लिंक भी):

GDPR विषय:

• EU GDPR Information Portal
• GDPR पर विकिपीडिया लेख

वेबसाइट आंकड़े और एनालिटिक्स टूल्स:

• AWStats
• Google Analytics
• वेब पेजों के लिए Google Analytics माप विकल्प
• Google Analytics विज्ञापन सुविधाओं के लिए नीति आवश्यकताएं
• Google Universal Analytics IP अनामकरण
• Google Analytics Opt-Out Browser Add-on

कुकी नियंत्रण टूल्स:

• Google Cookie Choices
• Civic Cookie Control
• Google द्वारा उपयोग की जाने वाली कुकीज के प्रकार
• वेबसाइट पर Google Analytics कुकी उपयोग
• Google Universal Analytics कुकीज और उपयोगकर्ता पहचान

Google Adsense, Custom Search Engine और Matched Content:

• Google Adsense
• Google CSE

शेयरिंग बटन:

• ShareThis ऑप्ट-आउट पेज

ई-कॉमर्स:

• PayPal गोपनीयता नीति

एम्बेडेड वीडियो और फ्लैश प्लेयर:

• Local Shared Objects (फ्लैश कुकीज) पर विकी पेज
• Adobe Flash Player सेटिंग्स मैनेजर
• Youtube एम्बेड वीडियो और प्लेलिस्ट

WordPress:

• WordPress होम पेज
• WordPress वर्जन 4.9.6
• WordPress और GDPR अनुपालन के लिए अंतिम गाइड
• MonsterInsights द्वारा Google Analytics for WordPress EU अनुपालन प्लगइन ऐड-ऑन
• Disqus ऑप्ट-आउट नीति
• WordPress स्क्रिप्ट्स और स्टाइल्स कैसे अक्षम करें
• WordPress डेवलपर्स टूल्स रेफरेंस: wp_enqueue_script
• WordPress डेवलपर्स टूल्स रेफरेंस: wp_deregister_script

एन्क्रिप्शन टूल्स:

• 7-Zip होमपेज
• The GNU Privacy Guard
• OpenPGP एन्क्रिप्शन मानक
• Advanced Encryption Standard (AES) पर विकी पेज
• TrueCrypt (GRC पेज)
• TrueCrypt ऑडिट रिपोर्ट
• VeraCrypt