VPN:n tietosuojakäytäntö vastaan datan reitti: vertaileva läpikäynti

Ota yksi lause käytännöstä — se, joka sai sinut harkitsemaan palveluntarjoajaa — ja seuraa sitä järjestelmän läpi. Lupaus tunnelista ei automaattisesti kuvaa asiakastilin portaalia, selvittäjää, tuen postilaatikkoa tai maksunkäsittelijää. Useimmat huonot vertailut syntyvät siitä, että yhtä komponenttia koskeva väite luetaan ja sovelletaan toiseen. Alla oleva läpikäynti muuttaa tämän tavan lyhyeksi työpaperiksi.

Seuraa dataa, älä adjektiivia

Otsikko kuten ”ei toimintalokeja” on väite luokasta, ja hyödyllinen kysymys on, mikä komponentti ylipäätään voisi tuottaa kyseisen luokan. Tunnelipää näkee lähdeosoitteet ja aikaleimat; selvittäjä näkee kysytyt nimet; tilijärjestelmä näkee identiteetin ja maksuhistorian; tuki näkee kaiken, mitä liität tikettiin. Kaksi näistä voi olla saman yrityksen hallinnassa ja yksi voi olla alihankkija.

Siirron aikainen salaus ei kerro säilytyksestä mitään, koska päätepiste purkaa salauksen ennen edelleenvälitystä.

Rakenna ensin komponenttikartta

Kirjoita kuusi riviä: asiakasohjelma, tunnelin päätepisteen operaattori, DNS-selvittäjä, tili- ja laskutusjärjestelmä, tukikanava sekä diagnostiikan tai kaatumisraporttien vastaanottaja. Merkitse jokaiselle riville, kuka sitä hallinnoi ja onko se osapuoli sama yritys, josta luet. Valkoisen etiketin palvelut, ulkoistetut tukipöydät ja kolmannen osapuolen analytiikka tekevät vastauksesta useammin kiinnostavan kuin ei.

Luettele sitten, mihin kullakin komponentilla on teknisesti pääsy: lähdeosoite, tilin tunniste, kysytty nimi, yhteyden aika, siirretty määrä, laitetiedot, lähetetty raportti. Saatavuus ei ole säilytystä, mutta se osoittaa, minkä käytännön osan on vastattava mihinkin kysymykseen.

Vertaa luokkia, tarkoitusta, säilytystä ja jakamista

Väite, ettei selauskohteita tallenneta, ei kata istunnon aikaleimoja, eikä väite koostetusta tilastosta kuvaa raakarekistereitä, jotka sen ruokkivat. Etsi täsmällinen luokka, ilmoitettu tarkoitus, säilytysaika ja jakamisen muotoilu — tässä järjestyksessä. Kun käytäntö sanoo ”anonyymi”, tarkista, mitkä tunnisteet ja mikä aikaresoluutio on poistettu, sen sijaan että hyväksyisit sanan selityksenä.

Huomioi käytännön osat, jotka koskevat tuotelinjoittain. Saman brändin selainlaajennuksella, mobiiliasiakkaalla ja reitittimellä voi olla eri datareitit, ja käytäntö saattaa kattaa kaikki kolme yhdellä yleisluontoisella sivulla.

IETF:n yksityisyysnäkökohtia koskeva ohjeistus on tässä hyödyllinen rakenne, koska se pakottaa analysoimaan komponenteittain eikä markkinointilauseittain.

Hinnoittele hyväksymäsi todisteet

Avoimen lähdekoodin asiakaskoodi kuvaa, mitä asiakas tekee datallesi, ja kertoo vähän tunnelin päättävästä taustajärjestelmästä. Auditointi kattaa ilmoitetun järjestelmän ilmoitetulta ajanjaksolta, mikä on hyödyllistä ja kapeampaa kuin pysyvä tae. Väite lainkäyttövalta-alueesta on väite oikeudellisesta prosessista, ei teknisestä kirjaamisesta. Jokainen näistä on tietynlainen todiste, ja niiden sekoittaminen tuottaa itsevarmoja johtopäätöksiä, joita kukaan ei pysty puolustamaan vuoden kuluttua.

Lepotilan salaus suojaa tietueita, jotka ovat yhä olemassa, joten se vastaa eri kysymykseen kuin siihen, ovatko tietueet olemassa lainkaan.

Kirjaa, mikä jäi vaille vastausta

Kun komponentti puuttuu käytännöstä tai luokkaa ei käsitellä, kirjoita sen viereen ”selittämätön”. Se on rehellinen tulos, ja se on hyödyllisempi kuin muuttaa hiljaisuus takeeksi tai syytökseksi. Pidä käytännön versio ja päiväys muistiinpanojesi vieressä, sillä nämä asiakirjat muuttuvat hiljaa ja versioton vertailu vanhenee huonosti.

Lopuksi ole selvillä siitä, mitä oma testauksesi todisti. Toimiva ulostulo ja muuttunut julkinen osoite osoittavat reititystä. Ne eivät kerro mitään palvelinpuolen säilytyksestä, ja työpaperi on paikka, jossa tämä ero elää.