Bittenbak is IT lingo voor een database. De database in kwestie is die de telecom en internetproviders moeten aanleggen als gevolg van de dataretentiewet. U weet wel, die wet waardoor uw volledige bel- en internetgedrag een jaar moet worden opgeslagen.
Via via bereikte mij een datamodel voor die database. Waarschijnlijk niet de versie waarmee men nu werkelijk bezig is. Het sitebezoek ontbreekt namelijk nog.
Maar het geeft toch een aardige indruk van de gegevens die men van u aan het opslaan is.
Voor de niet-ITers onder u, de blokjes zijn tabellen (zeg maar een groot werkblad van excel) en de pijltjes zijn relaties (om bijvoorbeeld te verwijzen naar een uniek persoon met een nummer).
Geen flauw idee of het publiceren van dit document me een inval van de AIVD zal opleveren. Maar mocht het na dit postje plots stil worden, weet u waar het van komt.
Een grote anti-privacy bittenbak
Foto:
Reacties (39)
Hoax, of een hele slechte architect.
Ik vind het er wel doortimmerd uitzien, zo moeten we die terroristen toch wel te pakken kunnen krijgen?
Euh, kleine nuance: internetgedrag gaat ws. ‘slechts’ 6 maanden opgeslagen worden. En ik had begrepen dat sitebezoek niet wordt geregistreerd, alleen het opstarten van een IP-verbinding (ofzo)?
Heb het overzicht gekopieerd, voor als het door de AIVD wordt weggehaald. Sh*t, nu weten ze mij natuurlijk ook te vinden…
Wat leven we toch in een idiote politiestaat, en iedereen vind het maar OK. Je zou er moedeloos van worden.
Verschrikkelijk slecht. Hoax of beunhaas?
Geen idee of het reel is. Zo wat dingen die me opvallen:
-max straatnaamlengte is 43 tekens, volgens mij is de max toegestande lengte in de GBA langer.
-max naamlengte is 200 tekens. Die is volgens mij korter.
-Gebroken numeriek veld voor huisnummers? Vreemd.
-Als je dan toch de helft van je info uit de GBA raust, dan zou ik ook nationaliteit opnemen.
-ik vind ’t wel typisch dat ze overal ‘a-nummers’ gebruiken; die zijn inderdaad beter identificerend dan sofinummers, maar providers hebben dan weer geen toegang tot a-nummers maar alleen tot sofinummers (als ze die al hebben) of NAW-gegevens. En om aan de hand van door providers opgegeven NAW-gegevens sofinummers te gaan opzoeken — oboi, dat gaat een drama worden…
@1, @5, licht aan de digibeten eens toe wat er verschrikkelijk slecht aan is?
Gaap jongens, dit databasemodel komt uit 2006 en staat gewoon op internet. Tevens staat hier uitleg OVER het model:
http://www.eerstekamer.nl/behandeling/20081209/onderzoek_naar_de_nationale/f=y.pdf
Centraal in de bevragingsapplicatie wordt gelogd:
• Inhoud van de vraag
• Verkregen antwoord
• Toepasselijk wetsartikel
• Identiteit van de vraagsteller
• Identiteit van de goedkeurende OvJ/RC
• Tijdstip van vraag
• Tijdstip van goedkeuring
• Tijdstip van beantwoording
In de database van de intermediair wordt gelogd:
• Inhoud van de vraag
• Verstuurde antwoord
• Identiteit van de vraagsteller
• Tijdstip van vraag/beantwoording
Dat lijkt me dan wel weer mooi.
@Gaaaap: Thx voor het linkje. Hoewel in dat document alleen het globale ontwerp staat (zo snel ik kon zien). Maar het is inderdaad uit 2006.
Wat de details zo interessant maakt zijn dingen als MEI.
@Ronald: Dat is een voorstel voor de aanpassing van de wet. Nu is het nog 1 jaar.
Dat van dat sitebezoek heb ik dan even gemist. Moet ik nazoeken.
@7:
Het gebruik van a-nummer als koppelling. Omdat de verschillende telefoniesoorten niet zijn uitgenormaliseerd moet je in het slechtste geval drie tabellen, en bij uitbreiding meer, doorzoeken om bijbehorende details te vinden. Een tabel a-nummer/telefoniesoort ontbreekt dus op z’n minst.
Er is veel overlap in tabellen tussen de telefoniesoorten. Dat kan weer alleen worden aneengeregen door spagetticode.
Niet uitnormaliseren van adresgegevens.
x/y coordinaten bij mobiele telefonie, wtf?
etc..
Oh, en meneer/mevrouw Gaaaap, ik heb geen mailtje of artikel van u gezien om ons op de hoogte te brengen. Wat u weet, weet niet iedereen.
@7 zonder een formele beschrijving van het domein (“wat willen ze nou?”) is dat niet met zekerheid te zeggen, maar een aantal zaken komt een beetje vreemd over. Zo op het eerste oog lijkt het datamodel namelijk niet netjes genormaliseerd.
Wat dat betekent kan wikipedia veel beter uitleggen:
http://en.wikipedia.org/wiki/Database_normalization
Maar het komt erop neer dat er bepaalde altijd geldende regels zijn voor het ordenen van de pijltjes en de tabellen in zo’n schema. Als je je niet aan die regels houdt, kan het voorkomen dat in je data tegenstrijdigheden staan en kan er bijvoorbeeld redundante data in voorkomen.
Zo is het mogelijk om in dit datamodel de naam van een land 20x met een andere spelling in te voeren. In een net datamodel zou er een aparte tabel met landen zijn waar dan een pijltje naar zou staan en kunnen dergelijke fouten niet optreden. Bovendien kost een “pijltje” (typisch een nummertje) aanmerkelijk minder ruimte dan bij iedere -bv.- locatie de naam van een volledig land in te voeren.
Iets vergelijkbaars zie je bij de e-mailadressen. In plaats van een aparte tabel met e-mailadressen, worden ze hier iedere keer voluit geschreven. Vervolgens iets terugzoeken op e-mailadres is extreem duur en kost superveel tijd.
En het tegenovergestelde zie je ook: er ontbreken “constraints”, ook wel pijltjes. Kijk bijvoorbeeld eens naar de IP-sessie tabel. Daar staat een ID in van een eigenaar waarvan we mogen aannamen dat het naar een ID in een tabel met eigenaren wijst. Daar staat echter geen pijltje naar, ergo dat verband wordt niet gecontroleerd en je kunt erop wachten tot er een ID staat waarbij geen corresponderende eigenaar gevonden kan worden.
En databases zijn nou _juist_ bedoeld om dat soort fratsen te voorkomen.
Wordt hoog tijd om een random 24/7 IP Pinger te ontwikkelen.
@Steeph/10: in de (bijlage van de) gepubliceerde wet (pdf) gaat het alleen om telecom- en emailverkeer.
Wat ook wel weer mooi is dat zo’n “Gaaaap” anoniem reageert.
@13: constraints, foreign keys en alles superstrak normalizeren zijn *de* manier om ervoor te zorgen dat als je data uit je database wilt halen met een webapp je anderhalf uur onderweg bent… ( select from join join join join’). Werkt misschien goed voor kantoorsoftware, maar als je met gigabytes aan data werkt wordt dat ‘een probleem’.
D’r is niks op tegen om hier en daar kopieen van je data op te slaan. Maar iets als ‘nationaliteit’ zou ik platslaan tot een nummertje, ipv als tekst, en in de webapp zou dat nummertje omgevormd moeten worden tot een stukkie tekst.
Maar goed, ergens schrijven ze dat die hele opzoek-engine een half uur de tijd mag nemen. Zit je op die manier zo aan.
Oh, en @13: om hoeveel data ging ’t ook alweer? Als ’t inderdaad om *terabytes* per maand ofzo gaat, dan voorzie ik nog wel een boel problemen. Zolang serieuze automatiseerders nog voorstellen om grote overheidsregistraties in access te proppen, verwacht ik niet dat dat systeem ooit gaat werken.
(’t kan wel hoor. Hadoop is leuk speelgoed.)
@16 Beg to differ. Ik weet wel dat het anonieme reageren veel poep uit de bek loost, maar Gaap hoort daar niet bij.
En hoe weet mescaline dat?
@10; No problem, hier staat orgineel: http://www.eerstekamer.nl/behandeling/20081209/referentiegegevens/f=y.pdf
@13,@16: Breek me de bek niet open over dit model. Mits ze niet gekozen hebben voor een databasewarehouse is dit datamodel niet redundant. Wat mij vorig jaar opviel was de duplicated content in NAW. Een gezin van 6 mensen staat daar 6x in met zijn/haar adres. Dit model kan nooit gaan werken, zeker niet bij verhuizing van adres oid..
@18,@19: Ik ben anoniem, praat geen poep, reageer gewoon niet (overal) onder eigen naam.
Wat ik niet snap is hoe, door het geheel openbaar te maken, ze denken “terroristen” hier mee te kunnen vangen. Moment dat dit wordt ingevoerd gaan die toch gewoon op iets anders over, rooksignalen ofzo.
‘Intenties bespeuren’ is my middle name @gronk.
@18 Daarom denk ik dat het met gratis internetverkeer heel makkelijk wordt om de database heel snel veel te log te maken om er iets werkbaars van te krijgen
Dit model kan nooit gaan werken, zeker niet bij verhuizing van adres oid
Nu je ’t zegt, ik mis inderdaad nog wel een hele serie velden ‘begin/eind-geldigheid’. Zeker omdat dit model al uit 2006 komt vermoed ik dat ’t meer een ‘fluff’-model is wat in dat document zit puur voor de vorm, ‘omdat er iets moest zijn’, maar dat ’t eigenlijke model d’r ondertussen totaal anders uitziet omdat de automatiseerders die er mee aan de gang moesten gillend gek werden.
@gronk, #17: Nee dan heb je gewoon een kut-database;-) En als je data ongestructureerd wil opslaan, moet je geen database gebruiken.
Bovendien zijn dat soort joins juist sneller; wat zou nou sneller zijn, 4 miljard e-mailadressen karakter voor karakter vergelijken of zoeken in een lijst van 4 miljard nummertjes nadat je in de e-mailadressentabel het e-mailadres hebt opgezocht? Als je joins trager zijn dan een netjes genormaliseerd datamodel, doe je volgens mij iets fout.
Overigens lees ik dat het een expliciete requirement is om dingen juist niet terug te kunnen zoeken. Maar aangezien het datamodel klaarblijkelijk bedoeld is om uberhaupt te achterhalen om hoeveel data het gaat, is het juist stom dat men het niet heeft genormaliseerd. Het wekt de indruk dat men heeft geprobeerd zo hoog mogelijk uit te komen.
@Gaaap, #21: Verhuizen lijkt me nou juist toevallig geen probleem met dit model; men probeert juist de situatie op een bepaald tijdstip vast te leggen; die moet daarna dus juist niet meer veranderen. In zo’n beetje ieder ander model zou de NAW-tabel inderdaad model hebben kunnen staan voor allerlei verhuisperikelen “belt u maar terug als u verhuist bent!”;-)
Als je joins trager zijn dan een netjes genormaliseerd datamodel, doe je volgens mij iets fout.
Voor kantoorautomatisering heb je helemaal gelijk. Maar zodra je tabellen (veel) groter zijn dan ’t geheugen van je server *en* je een matige databaseserver onder je vingers hebt *kuch* sql server *kuch* kun je die joins wel vergeten.
@pr: als ik ’t goed heb wordt in dat model niet de gegevens vastgelegd van de sites die je bezoekt, maar van je modem. Oftewel, je kunt sites bezoeken wat je wil, zolang je niet iedere dag je modem in- en uitprikt heb je gewoon maar een record in die database, omdat je nog sessie nog steeds ‘open’ staat.
Re: joins. Hou je indexen maar eens bij in real time. Maar wie weet lukt het ‘snachts als je alle torrents blokkeert.
Kom er maar in Brein.
@28: Maar we hebben het hier toch niet over een webserver db?
@28: als ik dat pdf’je van gaaaaap zo snel zie dan wordt d’r wel met een webapp gequeried op die database.
@30: overheid kennende wordt d’r niet realtime data toegevoegd, maar batchgewijs, met alle data van afgelopen week of maand. Tenzij d’r in dat pdf’je andere specs staan.
@gronk, #28: Dat zeg ik: kut-database. Dat het voor sql server ophoudt waar het geheugen ophoudt, ligt aan sql server, niet aan het concept. Er is geen enkel fundamenteel verschil tussen “kantoorautomatisering” (whatever that may be) en dit systeem.
Los daarvan zou ik dit soort gegevens gewoon in een logfile proppen en vooral niet in een database die. Statische data heeft niks te zoeken in een database.
@32: Ik vraag mij af of het niet eerder is dat de ontwerper niet veel meer dan een webserver db heeft gemodeleerd.
@32 dat kan wel evt. als je heel veel data uitsplitst naar meerdere computers. Oracle-werk.
@29 maar wat is dan het nut? Men wil niet weten wat ik doe op internet, maar alleen waneer?
@36, mja de cun^H^Hontent is niet belangrijk, het gaat erom wanneer en hoe vaak je osama mailt, maar niet wat.
@36 er is geen nut, het moet van de EU.
@35: dat zeg ik. google maar eens op hadoop.