VPN ડિરેક્ટરી તેની પાછળના નોડની જામીનગીરી કેમ ન આપી શકે
એક નોંધ જોડાણ અને તેને પ્રકાશિત કરનાર ડિરેક્ટરીનું વર્ણન કરે છે. સંગ્રહ અને જાળવણી ઓપરેટરની છે, જે બીજું પક્ષ હોઈ શકે છે.
ડિરેક્ટરીની જે નોંધો હોસ્ટનામ, દેશ અને પ્રોટોકોલનો સમૂહ ની યાદી આપે છે, તે કનેક્ટિવિટી વિશે પુરાવા છે, બીજી બાજુનું યંત્ર શું રેકોર્ડ કરે છે તે વિશે નહીં. અહીં મહત્ત્વનો નિર્ણય એ નથી કે સામાન્ય રીતે યાદીઓ પર ભરોસો કરવો જોઈએ કે નહીં. તે એ છે કે કયો પક્ષ તમે ખરેખર પૂછો છો તે પ્રશ્નનો જવાબ આપવાની સ્થિતિમાં છે.
એક નોંધ પાછળ ચાર પક્ષો
કોઈપણ વચન વાંચતા પહેલાં ભૂમિકાઓ અલગ કરો. ડિરેક્ટરી નોંધ પ્રકાશિત કરે છે, સોફ્ટવેર પ્રોજેક્ટ પ્રોટોકોલનું અમલીકરણ પૂરું પાડે છે, હોસ્ટિંગ પ્રદાતા યંત્ર અને નેટવર્ક પૂરું પાડે છે, અને નોડ ઓપરેટર સેવાનું રૂપરેખાંકન કરે છે. ચારમાંથી કોઈપણ એક અલગ સંસ્થા હોઈ શકે છે, અને દરેક માત્ર પોતાના ભાગ માટે જ બોલી શકે છે.
આ વિભાજન સમજાવે છે કે કેમ એક વિધાન સાચું હોવા છતાં નકામું હોઈ શકે. જે વિકાસકર્તા દસ્તાવેજીકરણ કરે છે કે પ્રોટોકોલ પેલોડનું લોગ કરતું નથી, તે રિલે પર વિગતવાર જોડાણ લોગ સક્રિય કરનારા ઓપરેટર વિશે કંઈ કહેતો નથી. બંને વિધાનો વિરોધાભાસ વિના સાથે રહી શકે છે. એટલે જ પ્રશ્ન નામવાળા પક્ષને પૂછવો પડે છે.
કેટલીક સેવાઓ પોતાના અંતિમ બિંદુઓ જાતે ચલાવે છે, અને ત્યારે નોંધ અને નીતિ એક જ પક્ષ તરફથી આવે છે. તે વધુ મજબૂત સ્થિતિ છે, પણ પાનાના સ્વરૂપ પરથી અનુમાન કરવાને બદલે તે સ્થાપિત કરવી પડે છે. નિવેદન માગો, અને ચકાસો કે તે એ સેવાનું નામ આપે છે જે તરફ નોંધ ઈશારો કરે છે.
દાવા સાથે મેળ ખાતો દસ્તાવેજ માગો
સંગ્રહ વિશેના દાવાને એવો દસ્તાવેજ જોઈએ જે સિસ્ટમ, માહિતી શ્રેણી અને સમયગાળાનું નામ આપે. જાળવણી વિશેના દાવાને સંખ્યા અને વ્યાપ જોઈએ. સ્વતંત્રતા વિશેના દાવાને વર્ણન જોઈએ કે કોણ શું ધરાવે છે, વિશેષણ નહીં.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
સ્વયંસેવી પ્રોજેક્ટ ઘણી વાર સૌથી સ્પષ્ટ ઉદાહરણ હોય છે, કારણ કે કેટલાક પોતે સ્વીકારતા નોડ માટે સ્પષ્ટ લોગિંગ જરૂરિયાતો પ્રકાશિત કરે છે. તે દસ્તાવેજ પ્રોજેક્ટના નિયમો વિશે પ્રાથમિક પુરાવો છે, અને તે હજી પણ તે નિયમો અવગણનારા વ્યક્તિગત ઓપરેટર વિશે પુરાવો નથી.
ઓડિટ અલગ માપમાં એ જ તર્ક અનુસરે છે. જે અહેવાલ ચોક્કસ તૈનાતીને ચોક્કસ સમયગાળામાં તપાસે છે તે તે સીમાની અંદર ઉપયોગી છે. એ જ સોફ્ટવેરની દરેક સ્વતંત્ર નકલ પર લંબાવવામાં આવે તો તે એવી બાંયધરી બની જાય છે જે કોઈએ આપી નથી. તારણ વાંચતા પહેલાં વ્યાપનો ફકરો વાંચો.
જ્યારે વિક્રેતાનું ગોપનીયતા નિવેદન તેમની પોતાની સેવાને આવરે છે, ત્યારે તેને તે વિક્રેતાનું પોતાની સિસ્ટમ વિશેનું નિવેદન ગણીને વાંચો. તૃતીય પક્ષના રિલેનું વર્ણન કરવા તેનો ફરી ઉપયોગ કરવો શ્રેણીગત ભૂલ છે, પ્રોટોકોલ એકસરખો હોય તો પણ.
દરેક વિકલ્પ સાથે તમે શું ખરીદો છો તે નક્કી કરો
જાહેર નોડ જવાબદારીની કિંમતે પહોંચ અને વૈવિધ્ય ખરીદે છે. જે ઓપરેટર તમારો કોઈ દેવું ધરાવતો નથી તે ગાયબ થઈ શકે, રૂપરેખાંકન બદલી શકે અથવા સૂચના વિના રેકોર્ડ રાખી શકે, અને તમારો ઉપાય ફક્ત આટલો સીમિત છે: અંતિમ બિંદુઓ બદલવા. આ બદલો કેટલાક કાર્યો માટે સ્વીકાર્ય છે અને બીજા માટે નહીં.
ચૂકવેલી સેવા પ્રકાશિત નીતિ ધરાવતા અને ગુમાવવા જેવું કંઈક ધરાવતા પ્રતિપક્ષને ખરીદે છે. તે તકનીકી બાંયધરી ખરીદતી નથી અને નીતિ વાંચવાની જરૂર દૂર કરતી નથી, પણ જાળવણી નિવેદન સાથેની નામવાળી સંસ્થાનું મૂલ્યાંકન અનામી રિલે કરતાં સહેલું છે.
બંને કિસ્સામાં ટકી રહેતો નિર્ણયનો નિયમ એ છે કે પુરાવાને જોખમ સાથે મેળવવો. જો કાર્ય ફરતું અંતિમ બિંદુ સહન કરે, તો ડિરેક્ટરી કાર્યક્ષમ સાધન છે. જો તે માહિતી સંભાળ અંગેના ચોક્કસ વચન પર આધારિત હોય, તો ફક્ત તે જ પક્ષ સંબંધિત છે જે તે વચન આપી શકે, અને ડિરેક્ટરી બાંયધરી નહીં પણ માર્ગદર્શનની સુવિધા છે.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'
ઉપરનો એક આદેશ ચલાવવા લાયક છે, કારણ કે તે બે પ્રશ્નોને સ્વચ્છ રીતે અલગ કરે છે. તે દર્શાવે છે કે તમારો ટ્રાફિક ખરેખર કયું સરનામું વાપર્યું, જે કનેક્ટિવિટીની હકીકત છે, અને તે સરનામાના ઓપરેટરે જોડાણના મેટાડેટા સાથે શું કર્યું તે વિશે કંઈ કહેતું નથી.
ક્લાયન્ટ બાજુના પ્રશ્નો અલગ રાખો
ઓપરેટરની નીતિ એક સ્તર છે, અને ટનલમાંથી તમે જે કરો છો તેની સુરક્ષા બીજું છે. લક્ષ્ય પર HTTPS, બ્રાઉઝરમાં સત્ર સંચાલન અને તમે જે ખાતામાં પ્રવેશ્યા તેની મજબૂતાઈ તમારા નિયંત્રણો રહે છે, અને છૂટછાટવાળું રિલે તેમને નબળા પાડતું નથી જેમ ઉત્તમ રિલે તેમને મજબૂત બનાવતું નથી.
આ વિભાજન બે સામાન્ય ભૂલો અટકાવે છે. કડક ઓપરેટર નીતિને HTTPS છોડવાનું કારણ માનવું એ એક છે, અને કાર્યરત HTTPS જોડાણને રિલે કોણ ચલાવે છે તે અવગણવાનું કારણ માનવું એ બીજું છે. બંને ભૂલો બે સ્તરને એકમાં ભેળવી દે છે અને પછી ખોટા સ્તર વિશે દલીલ કરે છે.
ટૂંકું લેખિત મૂલ્યાંકન બંને સંભાળે છે. દરેક વચન આપનાર પક્ષનું નામ લો, તેને ટેકો આપતો દસ્તાવેજ જોડો, અને તારીખ નોંધો. પછી નક્કી કરો કે કાર્યને વધુ મજબૂત દાવો જોઈએ છે કે ફક્ત કાર્યરત માર્ગ.
નોંધે તેનું કામ ત્યારે કર્યું જ્યારે તેણે કહ્યું કે તમે ક્યાં જોડાઈ શકો છો. પ્રશ્નનો બાકીનો ભાગ તે અંતિમ બિંદુ ચલાવનારનો છે, અને પ્રામાણિક જવાબ ઘણી વાર એ હોય છે કે તમે જાણી શકતા નથી અને તે મુજબ પસંદગી કરવી જોઈએ.