Miért nem hash-ként tároljuk a kizárási listát

Egy weboldal építése közben az ember naponta hússzor megnyitja. Egy havonta negyven látogatót mérő számlálón így a statisztika fele maga a szerző. Ezért van egy beállítás: ne számolja a saját címemről érkező látogatásokat.

A szolgáltatásban mindenhol máshol a címekből titkos salttal és a dátummal képzett hash készül, maga a cím pedig soha nem kerül a tárolóba. Ezen az egy helyen viszont pontosan úgy tároljuk, ahogy beírták, nyílt szövegként. Ez tudatos döntés, és érdemes nyíltan kimondani, ahelyett hogy valakinek magának kelljen rájönnie.

Az elsőként kipróbált változat

Az első megvalósítás a cím ellenőrzőösszegét tárolta, összhangban minden mással. Működött, kevesebbet tárolt, és szinte semmit sem ért: a legtöbb otthoni internetkapcsolat minden nap új címet kap. A kizárás a beállítás pillanatában helyes volt, másnap reggelre pedig értéktelen.

A napi címváltást egy címtartomány éli túl — jellemzően a szolgáltató /24-es vagy /16-os tartománya, amely változatlan marad, miközben a cím utolsó része cserélődik. Egy tartományt viszont nem lehet ellenőrzőösszegként összehasonlítani. A hash szándékosan megsemmisíti a sorrendet, az pedig, hogy „benne van-e ez a cím ebben a tartományban”, a sorrendről szóló kérdés. Nincs rá ügyes kerülőút; a két követelmény ellentétes irányba mutat.

A tartományt ezért beírt formájában, normalizálva tároljuk, mellette a két határát egyenként tizenhat bájton, és egyetlen BETWEEN dönt. Az IPv4-címeket IPv6-alakjukban írjuk le, így a két címcsalád azonos szélességű, és egyetlen összehasonlítás mindkettőt lefedi.

Miért elfogadható itt ez a kompromisszum

Amit tárolunk, az az üzemeltető saját hálózata, amelyet ő maga írt be, neki jelenik meg, és bármikor törölheti. Nem egy látogató címe. Az adatvédelmi tájékoztató ugyanezt mondja, ugyanezekkel a szavakkal, mert a másik lehetőség — azt állítani, hogy a szolgáltatás mindent hash-el, és ezt csendben kivételként kezelni — olyan, nagy vonalakban igaz állítás volna, amely kevesebbet ér, mintha semmit sem állítanánk.

A korlát számlálónként tíz bejegyzés: elég az otthoni, a munkahelyi és a mobilkapcsolathoz, és elég kevés ahhoz, hogy a lista ne válhasson általános célú címtárolóvá.

A második fajta, a helyüket változtató forrásokhoz

Egyes forgalomnak stabil az identitása, de változó a címe: egy rendelkezésreállás-figyelő, egy csevegőprogram linkelőnézet-lekérője, egy ellenőrző szolgáltatás. Ezeket egyetlen tartomány sem fogja meg.

Ezeknél a kizárás ehelyett a böngészőazonosító egy részletére illeszkedik. A beírt uptimerobot részlet kiszűri a teljes karakterláncot, amelyet a szolgáltatás küld. A minimum négy karakter, mert egy kétbetűs részlet szinte minden azonosító karakterláncban előfordulna, és teljesen kikapcsolná a számlálót.

Az általános tanulság

Egy adatvédelmi koncepció kompromisszumok sorozata, és az érdekes részek azok, ahol egy szabálynak engednie kellett. Az olyan szabályok, amelyek soha nem engednek, többnyire azt jelentik, hogy még senki nem vetette össze őket egy valódi követelménnyel.

Amit kerülni kell, az a csendes engedmény. Egy hash-eltnek mondott mező, amely valójában nem az, de a dokumentáció úgy írja le, mintha az volna, rosszabb, mint egy egyszerű mező, amelyet egyszerűen írnak le — olyan bizalmat használ el, amelyet nem érdemelt ki, és előbb-utóbb rábukkan valaki, aki nem számított rá, hogy ezt ellenőriznie kell.