Ik zou zeggen defineer "...na het gesprek..."....... Ik
bedoel, ik heb twee jaar geleden een gesprek gevoerd en het
moment 'nu' is ook na dat ene gesprek. Moeten ze dat ook
opslaan?

Of gaat het om de enkele seconden na het gesprek? Weer erg
vaag in elk geval.

In elk geval heb ik nog ca. 1,5 jaar om mijn huidige
telefoon te gebruiken, daarna zoeken ze het maar uit, dan is
mijn mobiele telefoongebruik helemaal over. Nee, ik heb
niets te verbergen onder de huidige definities van
'terroristen' van wie dan ook. Maar zodra men iedereen een
terrorist noemt die niet wenst mee te werken aan whatever de
regering ook maar wil, dan ga ik daar zeker een keer onder
vallen.

Jajajaja, ze kunnen nu ook al van alles volgen enz. Maar nu
is de staat nog niet totalitair zoals het Amerika begint te
worden....

- Unomi -

Ok.. Tijd om m'n e-mail te gaan encrypten... Niet omdat ik
wat te verbergen heb maar het gaat ze gewoon geen zak aan
wat ik schrijf....

Cool... Waar had ik die wardialer ook alweer gelaten? Op een
psion ofzo knallen, pre-paid (2e hands) mobieltje d'r naast
en op verschillende treinstations in een kluis.. Regelmatig
een ander station kiezen.. Zal ze leren..

ff klein vraagje aan sirdice: wat is een wardailer?
En hoe willen ze mijn mobiele prepaid nummer gaan controleren die ik
nergers gergistreerd heb staan onder mijn naam???

Ok.. Tijd om m'n e-mail te gaan encrypten... Niet omdat ik
wat te verbergen heb maar het gaat ze gewoon geen zak aan
wat ik schrijf....
[/quote]Het gaat om de verkeersgegevens, dus from, to, datum, ip etc. Niet de
inhoud van de e-mails wordt opgeslagen. Gelukkig maar voor jou, want als
je je mail wilt encrypten moet je zorgen dat je van iedereen die je een e-mail
wilt sturen een publieke key hebt. Ik weet niet hoe dat bij jou is, maar dat zijn
er maar bar weinig in mijn lijstje...

Tja, het wordt duidelijk hoog tijd om te communiceren via
wegen die niet gangbaar zijn, of in elk geval niet
toegankelijk voor het grote publiek..

Gaat ze idd geen zak aan..waar eindigt die ellende?

Een kind ziet de solution nog...en die terroristen niet?

Het gaat om zeer abstracte gegevens, die reeds door
teleco's worden bijgehouden.
Er veranderd dus niets, behalve dat het verplicht zal worden.

Een wardialer is een programma wat een reeks (of constant
dezelfde) telefoonnummers belt. Vroeger, toen er nog geen
Internet was (en tegenwoordig kan dat overigens nog steeds),
bedoelt om inbelpunten te vinden of te overbelasten om zo
een bedrijf binnen te komen. Erg old-school...

http://nl.wikipedia.org/wiki/War_dialing
http://en.wikipedia.org/wiki/Wardialing

Ehhmmm... Telco gegevens klopt ja... Alleen jammer dat daar
nu ook je Internet verkeer bij komt..

Oh? In dat geval gaat alles over meedere proxies heen.. Dan zien ze alleen maar die connecties.. Daar hebben ze ook geen moer aan.. En als ze, na een maand of tig, eindelijk toestemming hebben om die proxylogs door te spitten komen ze er achter dat m'n verkeer naar een volgende proxy gestuurd wordt (proxy-chaining)..

Maar heb jij meer informatie over WAT er nu precies onder "verkeersgegevens" verstaan wordt? Ik kan hier nergens iets over vinden en iedereen roept maar wat maar volgens mij weet niemand het..

Omdat niemand de noodzaak van encrypten nog in ziet.. Dat gaat nu dus veranderen... En anders e-mail ik ze gewoon niet meer...

Ik denk dat ik maar na 1 januari een 'underground' netwerk
op zetten. Zeg maar een combinatie van p2p, bbs en tls/ssl
vpn's. Geen hond die meer kan achterhalen wat waar en hoe.
Een aangezien ik geen ISP ben heb ik geen verplichting ook
maar iets te loggen. Veilig MP3, video, source codes en mail
uitwisselen zonder dat er ook maar een prutser van de
overheid erbij kan.

Een droom van vele komt uit............ (overheden en criminelen)

Is er ook bekend wat men doet indien deze DB word gelezen door onbevoegden...?

We kunnen natuurlijk ook allemaal een emailadres (afzender) invullen van onze ministers.......... laat ze dan maar eens uitzoeken wat wel en wat niet is verzonden door [cencuur!] en partners. (daarbij maakt IP of mac niets uit, we sturen allemaal wel eens een emailbericht vanaf een andere locatie dan thuis.)

Schuldig tenzij het tegendeel bewezen is, is nu werkelijkheid geworden.

TIP!

Handel in log bestanden van email-hosting en internetproviders,
"uw onschuld is in onze handen."

Lees dit artikel eens.
http://www.burojansen.nl/afluisteren/Hfst5.htm
Door naiviteit is het nog eenvoudiger geworden om ons te
............... (denk zelf over de mogelijkheden)

Kijk voor de gein eens in /var/log
Logs bestaan sinds mensenheugenis, noodzakelijk voor het
beheer en bevat precies de eerder omschreven informatie. Het
enige dat veranderd is dat er nu een minimum en maximum in
bewaartijd gesteld zal worden.

En als op een gegeven moment verkeersgegevens op straat
belanden (bijv. een afgedankte PC langs de straat of
floppies in een leasebak) zal ook die
verantwoordelijke minister verklaren dat het niet om
inhoudelijke gegevens gaat.

Erik van Straten

Als jij daar verkeersgegevens hebt staan... ik niet iig..
dice@maelcum:~>ls -l /var/log
total 704
-rw-r--r-- 1 root wheel 11418 Jun 8 2005 Xorg.0.log
-rw-r--r-- 1 root wheel 11418 Jun 8 2005 Xorg.0.log.old
-rw------- 1 root wheel 102702 Dec 15 11:08 auth.log
-rw------- 1 root wheel 11267 Dec 12 19:00 auth.log.0.bz2
-rw------- 1 root wheel 9892 Dec 9 12:00 auth.log.1.bz2
-rw------- 1 root wheel 12333 Dec 7 04:00 auth.log.2.bz2
-rw------- 1 root wheel 18491 Dec 6 14:00 auth.log.3.bz2
-rw------- 1 root wheel 10624 Dec 6 12:00 auth.log.4.bz2
-rw------- 1 root wheel 6236 Dec 5 13:00 auth.log.5.bz2
-rw------- 1 root wheel 14775 Dec 5 03:00 auth.log.6.bz2
-rw------- 1 root wheel 10901 Dec 4 13:00 auth.log.7.bz2
-rw------- 1 root wheel 32534 Dec 15 11:20 cron
-rw------- 1 root wheel 5681 Dec 14 15:00 cron.0.bz2
-rw------- 1 root wheel 5739 Dec 12 00:00 cron.1.bz2
-rw------- 1 root wheel 5739 Dec 9 08:00 cron.2.bz2
-rw------- 1 root wheel 5764 Dec 6 17:00 cron.3.bz2
-rw------- 1 root wheel 86440 Dec 15 11:15 debug.log
-rw------- 1 root wheel 6331 Dec 3 08:00 debug.log.0.bz2
-rw------- 1 root wheel 5263 Nov 20 19:00 debug.log.1.bz2
-rw------- 1 root wheel 31186 Dec 12 03:01 dmesg.today
-rw------- 1 root wheel 31124 Dec 10 03:02 dmesg.yesterday
-rw------- 1 root wheel 543 Sep 20 03:01 ipf.today
-rw------- 1 root wheel 542 Sep 19 03:01 ipf.yesterday
-rw-r--r-- 1 root wheel 28056 Dec 15 10:55 lastlog
-rw-r--r-- 1 root wheel 3976 Aug 31 22:48 lpd-errs
-rw-r----- 1 root wheel 1772 Dec 15 03:01 maillog
-rw-r----- 1 root wheel 575 Dec 15 00:00 maillog.0.bz2
-rw-r----- 1 root wheel 563 Dec 14 00:00 maillog.1.bz2
-rw-r----- 1 root wheel 561 Dec 13 00:00 maillog.2.bz2
-rw-r----- 1 root wheel 713 Dec 12 00:00 maillog.3.bz2
-rw-r----- 1 root wheel 762 Dec 11 00:00 maillog.4.bz2
-rw-r----- 1 root wheel 563 Dec 10 00:00 maillog.5.bz2
-rw-r----- 1 root wheel 562 Dec 9 00:00 maillog.6.bz2
-rw-r----- 1 root wheel 562 Dec 8 00:00 maillog.7.bz2
-rw-r--r-- 1 root wheel 89397 Dec 15 11:15 messages
-rw-r--r-- 1 root wheel 6706 Dec 3 19:00 messages.0.bz2
-rw-r--r-- 1 root wheel 8406 Nov 21 14:00 messages.1.bz2
-rw-r--r-- 1 root wheel 2952 Nov 16 19:00 messages.2.bz2
-rw-r--r-- 1 root wheel 2966 Nov 16 18:00 messages.3.bz2
-rw-r--r-- 1 root wheel 2967 Nov 16 17:00 messages.4.bz2
-rw-r--r-- 1 root wheel 7289 Nov 16 16:00 messages.5.bz2
-rw------- 1 root wheel 133 Sep 21 03:01 mount.today
-rw------- 1 root wheel 172 Sep 2 03:01 mount.yesterday
-rw------- 1 root wheel 0 Mar 25 2005 pf.today
-rw------- 1 root wheel 24 Sep 20 22:35 pflog
-rw-r----- 1 root network 15315 Sep 26 20:50 ppp.log
-rw------- 1 root wheel 0 Nov 5 2004 security
-rw-r----- 1 root wheel 728 Dec 15 03:01 sendmail.st
-rw-r----- 1 root wheel 728 Dec 9 03:01 sendmail.st.0
-rw-r----- 1 root wheel 728 Dec 3 03:01 sendmail.st.1
-rw-r----- 1 root wheel 728 Oct 8 04:15 sendmail.st.10
-rw-r----- 1 root wheel 728 Nov 26 04:15 sendmail.st.2
-rw-r----- 1 root wheel 728 Nov 20 03:01 sendmail.st.3
-rw-r----- 1 root wheel 728 Nov 14 03:01 sendmail.st.4
-rw-r----- 1 root wheel 728 Nov 8 03:01 sendmail.st.5
-rw-r----- 1 root wheel 728 Nov 2 03:01 sendmail.st.6
-rw-r----- 1 root wheel 728 Oct 27 03:01 sendmail.st.7
-rw-r----- 1 root wheel 728 Oct 21 03:01 sendmail.st.8
-rw-r----- 1 root wheel 728 Oct 15 03:02 sendmail.st.9
-rw------- 1 root wheel 3669 Dec 12 03:01 setuid.today
-rw------- 1 root wheel 3669 Nov 17 03:01
setuid.yesterday
-rw-r----- 1 root network 0 Nov 5 2004 slip.log
-rw------- 1 root wheel 209 Dec 13 2004 userlog
-rw-r--r-- 1 root wheel 1980 Dec 15 10:55 wtmp
-rw-r--r-- 1 root wheel 5632 Nov 29 18:11 wtmp.0
-rw-r--r-- 1 root wheel 2200 Oct 31 18:03 wtmp.1
-rw-r--r-- 1 root wheel 2288 Sep 30 15:00 wtmp.2
-rw-r--r-- 1 root wheel 792 Sep 1 00:41 wtmp.3
-rw------- 1 root wheel 0 Nov 5 2004 xferlog

Nu zien we het voordeel van spam, de AIVD zal zich door
bergen viagro moeten wroeten om de juiste gegevens te vinden.

Bijvoorbeeld cat /var/log/maillog
er staan er genoeg met verkeersgegevens.

http://www.security.nl/article/12515/1/83%
25_inkomend_netwerkverkeer_is_%22Dark_Traffic%22.html


WAHAHAHA

Gaan we daar dan ook voor betalen...?

Bedoel wie bepaalt dan wat er dark traffic is ...dan moet je als consument
toch korting krijgen?

Die war dialer ..hij is prachtig ;) Als we dat met zn allen doen lopen al die
disken vol met waardeloze shit...das toch humor ;)

Die's nogal beperkt tot e-mail..

Maar waar niemand schijnbaar een antwoord op heeft: Wat wordt er nu EXACT bedoeld met verkeersgegevens m.b.t. het opslaan van Internet gegevens? Iedereen roept maar wat en niemand die het, volgens mij, echt weet.

Er stond duidelijk bijvoorbeeld.
Even een paar citaten uit de Wetgevingsresolutie van het
Europees Parlement over het voorstel voor een richtlijn van
het Europees Parlement en de Raad betreffende de bewaring
van gegevens die zijn verwerkt in verband met het aanbieden
van openbare elektronischecommunicatiediensten en tot
wijziging van Richtlijn 2002/58/EG (COM(2005)0438 –
C6-0293/2005 – 2005/0182(COD));

Amendement 57
OVERWEGING 13

Deze richtlijn heeft alleen betrekking op gegevens die
ontstaan of verwerkt worden naar aanleiding van een
communicatie of een communicatiedienst, en niet op gegevens
die de inhoud van de gecommuniceerde informatie vormen. De
bewaring van gegevens moet zo gebeuren dat voorkomen wordt
dat gegevens twee keer worden bewaard. Het ontstaan of
verwerken van gegevens, bij de levering van de betrokken
communicatiediensten (artikel 3), betreft toegankelijke
gegevens. Met name bij de bewaring van gegevens betreffende
e-mail via het internet en internettelefonie kan het
toepassingsgebied worden beperkt tot de eigen diensten van
de aanbieders of de netwerkaanbieders.


Amendement 77
ARTIKEL 4, LID 1, LETTERS A) tot en met F), EN LID 2

a) gegevens die nodig zijn om de bron van een communicatie
te traceren en te identificeren;
(1) in het geval van telefonie over een vast netwerk:
(a) het telefoonnummer van de oproeper;
(b) naam en adres van de abonnee of de geregistreerde gebruiker;
(2) in het geval van internettoegang, e-mail over het
internet en internettelefonie:
(a) de toegewezen gebruikersidentificatie(s);
(b) de gebruikersidentificatie en het telefoonnummer
toegewezen aan elke communicatie die het publieke
telefoonnetwerk binnenkomt;
(c) naam en adres van de abonnee of de geregistreerde
gebruiker aan wie het IP-adres, de gebruikersidentificatie
of het telefoonnummer was toegewezen op het tijdstip van de
communicatie.

(b) gegevens die nodig zijn om de bestemming van een
communicatie te identificeren;
(1) in het geval van telefonie over een vast netwerk en
mobiele telefonie:
(a) het telefoonnummer (de telefoonnummers) van de
opgeroepene(n) en, in het geval van aanvullende diensten
zoals call forwarding of call transfer, het nummer (de
nummers) waarnaar de verbinding is omgeleid;
(b) naam en adres van de abonnee of de geregistreerde gebruiker;
(2) in het geval van e-mail over het internet en
internettelefonie:
(a) de gebruikersidentificatie of telefoonnummer van de
beoogde ontvanger(s) van een internettelefoonoproep;
(b) naam en adres van de abonnee(s) of de geregistreerde
gebruiker(s) en de gebruikersidentificatie van de beoogde
ontvanger(s) van de communicatie.

(c) gegevens die nodig zijn om de datum, het tijdstip en de
duur van een communicatie te bepalen;
(1) in het geval van telefonie over een vast netwerk en
mobiele telefonie:
(a) datum en tijdstip van aanvang en einde van de verbinding;
(2) in het geval van internettoegang, e-mail over het
internet en internettelefonie:
(a) datum en tijdstip van de log-in en log-off van een
internetsessie gebaseerd op een bepaalde tijdzone, samen met
het IP-adres, hetzij statisch, hetzij dynamisch, dat door de
aanbieder van een internettoegangsdienst aan een
communicatie is toegewezen, en de gebruikersidentificatie
van de abonnee of geregistreerde gebruiker;
b) de datum en tijdstip van de log-in en log-off van een
e-maildienst over het internet of internettelefoniedienst
gebaseerd op een bepaalde tijdzone.

(d) gegevens die nodig zijn om het type communicatie te bepalen:
(1) in het geval van telefonie over een vast netwerk en van
mobiele telefonie:
(2) ) in het geval van e-mail over het internet en
internettelefonie:
(a) de gebruikte internetdienst.

e) gegevens die nodig zijn om de communicatie-apparatuur of
de vermoedelijke communicatie-apparatuur van de gebruikers
te identificeren:
(1) in het geval van telefonie over een vast netwerk:
(a) het/de oproepende en opgeroepte nummer(s);
(2) in het geval van mobiele telefonie:
(a) het/de oproepende en opgeroepte nummer(s);
(b) de International Mobile Subscriber Identity (IMSI) van
de oproepende deelnemer.
(c) de International Mobile Equipment Identity (IMEI) van de
oproepende deelnemer.
(d) de International Mobile Subscriber Identity (IMSI) van
de opgeroepen deelnemer.
(e) de International Mobile Equipment Identity (IMEI) van de
opgeroepen deelnemer.
(f) in geval van vooraf betaalde anonieme diensten, datum en
tijdstip van de eerste activering van de dienst en
aanduiding (Cell ID) van de locatie waaruit de activering is
uitgevoerd;
(3) in het geval van internettoegang, e-mail over het
internet en internetdiensten:
(a) het inbellende nummer voor een inbelverbinding;
(b) de digital subscriber line (DSL) of andere eindpunt van
de initiatiefnemer van de communicatie.

(f) gegevens die nodig zijn om de locatie van
mobielecommunicatie-apparatuur te bepalen:
(1) de locatie-aanduiding (Cell ID) bij het begin van de
verbinding;
(2) gegevens voor het identificeren van de geografische
locatie van cells middels referentie aan hun
locatie-aanduidingen (Cell ID's) gedurende de periode dat
communicatiegegevens worden bewaard.


Amendement 78
ARTIKEL 4, LID 2 BIS (nieuw)

2 bis. Gegevens waaruit de inhoud van de communicatie kan
worden opgemaakt, mogen krachtens deze richtlijn niet worden
bewaard.

http://www.europarl.eu.int/news/expert/infopress_page/004-3786-348-12-50-901-20051215IPR03785-14-12-2005-2005--false/default_en.htm


Welke data het precies om gaat staat in artikel 4, lid 1 bis. In enkele
muisklikken kan je er zijn vanaf het originele artikel.

Lidstaten zijn vrij in de interpretatie tot op zekere hoogte. Gegevens die de
inhoud van een communicatie duidelijk maken, worden niet opgenomen.

Anoniem op donderdag 15 december 2005 17:01:
> Gegevens waaruit de inhoud van de communicatie
> kan worden opgemaakt, mogen krachtens deze
> richtlijn niet worden bewaard.

Hmm, uit privacy oogpunt is dat in elk geval iets. Bij
misdaadbestrijding is het natuurlijk interessant om te weten
wie met wie contact gehad heeft en wanneer, maar (als leek)
kan ik me niet voorstellen dat je dan niet zou willen weten
"waar het over ging". Het zou me dan ook niet verbazen als
dit punt ofwel op de helling gaat ofwel dat men zich er
gewoon niet aan houdt.

Uit de brief van minister Donner aan de voorzitter van de
eerste kamer dd 28-11-2005:
http://www.justitie.nl/pers/kamerstukken/include.asp?bestand=/extern/documentportal/Brieven%20TK/20051128_5388400b%20de%20bewaring%20van%20telecommunicatiegegevens.doc.c


Zodra blijkt dat gegevens waaruit de inhoud van de
communicatie kan worden opgemaakt van belang zijn voor
de opsporing, wie bepaalt dan wat proportioneel is? Uit het
volgende maak ik op dat in elk geval de opslagruimte
kennelijk niet zo'n grote rol speelt:


Dus omdat er al veel meer gegevens zullen worden
opgeslagen dan waar de commissie van uitging, gaan we veel
minder meer gegevens opslaan zodra we van IPv4 naar IPv6
gaan. Da's toch logisch, wat een sukkels die commissie.

Belangrijker, hoe ver gaat "koptekst"? Ik ben gewend om zo
duidelijk mogelijke subjects te kiezen, gaan ze die ook
opslaan (of is dat net zo niet-inhoudelijk als een kruisje
achter asielzoeker)?

Erik van Straten

Dan heb je gewoon het normale
traject inzake tapverzoeken dat buiten deze richtlijn valt.
De volksvertegenwoordiging.
Dat stond er niet: het ging er om dat de
verlenging
van het IP-adres niet betekent dat de hoeveelheid te bewaren
gegevens daarmee ook met een factor 4 zou toenemen.

Overigens worden IPv6 adressen waar nodig handig genoteerd
waardoor die factor 4 in de praktijk weg danwel mee kan
vallen. Denk hierbij bijvoorbeeld aan de notatie 2001:abcd::1

Dit kun je gewoon in de huidige logs terugvinden.

Vraagje:
Wie vertrouwt op dit moment de politiek zodanig dat hij
ervanuit gaat dat het altijd zo zal blijven dat die inhoud
niet opgenomen wordt.
Als je communicatie ook maar enigszins verdacht is en
daarbij bedoel ik verdacht in de ogen van de overheden, dan
gaat er natuurlijk wel gelogd worden op de inhoud. En
anders komt er wel commercieele druk vanuit bijvoorbeeld de
stichting Brein.
Als we dit alles nog eens gaan optellen bij de gegevens die
het taggen van allerlei producten met RFID-chips gaat
opleveren dan kun je wel uittellen waar het naartoe gaat.
Misschien ben ik een zwartkijker, maar zoals een vriend van
mij zei:
Wij moeten oppassen
Peter R. slaapt nooit.
Laten we onze belangrijke zaken maar weer per aangetekende
post versturen en het internet reserveren voor de
broodnodige onzin.

greetz

Uit COM(2005) 439 (2005/0182 COD):
Het voorstel gaat qua impact op de burgers en het
bedrijfsleven niet verder dan hetgeen strikt noodzakelijk is
en is dus in overeenstemming met het evenredigheidsbeginsel.
Ter herinnering zij vermeld dat het voorstel uitsluitend
verkeersgegevens betreft die worden verwerkt door de
aanbieders van elektronischecommunicatiediensten. De inhoud
van de elektronische communicatie valt buiten het
toepassingsgebied.
Dat wordt een tapverzoek genoemd, dat buiten
deze richtlijn valt.

Door Anoniem op vrijdag 16 december 2005 17:56:
> Ter herinnering zij vermeld dat het voorstel
> uitsluitend verkeersgegevens betreft die worden
> verwerkt door de aanbieders van elektronische
> communicatiediensten.

Dat is niet waar. Gegevens van niet-beantwoorde oproepen
zullen ook moeten worden opgeslagen. Daarnaast bevat de
administratie die ISP's nu bijhouden m.i. onvoldoende
informatie.

ISP's loggen nu alleen e-mail adressen indien een bericht
hun SMTP-server passeert (/var/log), dus niet indien
een persoon of bedrijf zelf een e-mail server (zenden en
ontvangen) beheert. Ook houden ISP's niet bij welke e-mails
via webbased services zoals bijv. Hotmail worden verzonden,
en zolang daarbij geen sprake is van SSL kan ik me niet
voorstellen dat daar geen aangepaste filters voor gemaakt
zullen worden (anders raad ik terroristen aan om hotmail
accounts te gebruiken voor onderlinge communicatie).
Hetzelfde geldt voor alle andere IP verkeer (gewoon
webtraffic, Skype, IRC etc.) Ik zie niet in hoe dit zou
kunnen zonder routertaps.

Anoniem op donderdag 15 december 2005 20:32:
> het ging er om dat de verlenging van het IP-adres
> niet betekent dat de hoeveelheid te bewaren
> gegevens daarmee ook met een factor 4 zou
> toenemen.

Inderdaad. Anders gezegd, de eerste kamer JBZ-commissie
wist ook niet precies wat zou worden opgeslagen en ging
bij "adresgegevens" (d.w.z. gegevens om een e-mail ontvanger
of afzender uniek te identificeren) kennelijk letterlijk uit
van IP adressen.

Omdat e-mail afzenderadressen eenvoudig te spoofen zijn is
het logisch om meerdere headerregels op te slaan (die
vind ik overigens niet terug in /var/log). Indien per
e-mail alle headers worden opgeslagen zijn die paar
extra bytes per IPv6-adres inderdaad een scheintje, maar
gaat me hier natuurlijk niet om opslagruimte. Het gaat er om
dat zelfs betrokken volksvertegenwoordigers niet precies
weten wat zal worden opgeslagen en dat minister Donner op
hun vragen in vage termen als "koptekst" antwoordt.

> Dan heb je gewoon het normale traject inzake
> tapverzoeken dat buiten deze richtlijn valt.

Precies. Naar verluid zullen 600 aan te trekken AIVD'ers in
deze verkeersgegevens gaan spitten, wat naar (mijn)
verwachting veel extra "verdachten" op zal leveren. D.w.z.
personen die verdacht zijn op basis van weinig zeggende
verkeersgegevens. Daarnaast zou minister Donner aangegeven
hebben van plan te zijn deze verkeersgegevens via de
CIOT-methode
(http://www.cbpweb.nl/documenten/adv_z1999-0270.stm)
toegankelijk te maken voor alle opsporingsambtenaren.

En waar nu voor een tap nog een officier van justitie nodig
is en de ISP handelingen moet verrichten, is straks die
officier voor een full tap wellicht formeel nog een
vereiste, maar de technologie om de knop van
"verkeersgegevens" naar "inhoudelijk" te draaien (ik vermoed
op afstand) is dan gerealiseerd.

In het verslag van de bijeenkomst van de Raad Justitie en
Binnenlandse Zaken van de Europese Unie, 12 oktober 2005 te
Luxemburg (zie
http://europapoort.eerstekamer.nl/9345000/1/j9vvgy6i0ydh7th/vgbwr4k8ocw2/f=/vh5ekqqvcbvo.doc)
staat dat minister Donner m.b.t. de richtlijn onder meer meldde:

In alles wat ik erover lees doet minister Donner zijn
uiterste best om te voorkomen dat hem later, als de
maatregelen veel verder zijn gegaan dan de meesten van ons
nu verwachten, verweten kan worden dat hij iets verzwegen heeft.

Erik van Straten

Die worden ook
door de aanbieders van elektronische diensten verwerkt, dus
wel waar :)
Waarom denk je
dat?
Volgens de
wetgevingsresolutie (van het Europees Parlement) hoeft dit
ook helemaal niet en wordt dit beperkt tot de eigen
diensten van de aanbieders of de netwerkaanbieders. Dus
in de lijn van je voorbeeld moet hotmail de e-mail loggen
wanneer je middels hun webmaildienst post
ontvangt/verstuurd, niet je ISP. Je ISP moet ervoor zorgen
dat naam en adres van de abonnee of de geregistreerde
gebruiker aan wie het IP-adres, de gebruikersidentificatie
of het telefoonnummer was toegewezen op het tijdstip van de
communicatie kan worden achterhaald.
Je
zult in /var/log/maillog per bericht ook IP-adressen vinden
van systemen waarmee contact gezocht is of die contact
gezocht hebben om mail af te leveren danwel te ontvangen.
Dat is raar omdat
dit gewoon bij het Europees Parlement en EURlex is te vinden.
Dat kan niet omdat de gegevens bij
de dienstenaanbieders zelf wordt opgeslagen (logs). M.a.w.
moet er dus via de normale daartoe geëigende wegen deze
gegevens worden verzocht.
De drempel is dat het moet gaan
om een misdrijf waarvoor ten minste voorlopige hechtenis
geldt danwel om verkenning (wbob). Het is dus niet zo dat
men ongebreiteld voor de lol naar hartelust gegevens kan
opvragen om bijvoorbeeld zonder aanleiding even "van
Straten" voor de grap de stuipen op het lijf te jagen.
Een tap werkt in
deze totaal anders dan het bijhouden van verkeersgegevens.
Is dit geen juiste aanname
dan?
Als dat al zo zou zijn, dan kan hem dat
evenmin worden verweten. :)

> Erik van Straten op zondag 18 december 2005 22:39:
> > Gegevens van niet-beantwoorde oproepen zullen ook
> > moeten worden opgeslagen.

Anoniem op maandag 19 december 2005 12:23:
> Die worden ook door de aanbieders van
> elektronische diensten verwerkt, dus wel waar :)

Ik zie niet wat hier grappig aan is. Gegevens van
onbeantwoorde oproepen worden nu niet opgeslagen, volgens de
richtlijn moet dat wel.

> > routertaps
> Volgens de wetgevingsresolutie (van het Europees
> Parlement) hoeft dit ook helemaal niet en wordt dit
> beperkt tot de eigen diensten van de
> aanbieders of de netwerkaanbieders.

Het betreft geen wetgeving maar een richtlijn. En dat het
niet hoeft wil niet zeggen dat het niet gaat gebeuren.
Minister Donner spreekt zichzelf op dit punt ook vaak tegen.
Bijv. in 2004-2005 2321:
en in
antwoord op dezelfde vraag: Voor de laatste twee punten is sniffen van netwerkverkeer en
het opslaan van bijv. de IP en TCP headers van alle SYN+ACK
pakketten noodzakelijk (of pakketten met alleen SYN als je
ook onbeantwoorde verbindingen wilt loggen). Sniffen en
loggen van pakketten of pakketheaders doen ISP's bij mijn
weten nu niet.

> Je zult in /var/log/maillog per bericht ook IP-adressen
> vinden van systemen waarmee contact gezocht is of die
> contact gezocht hebben om mail af te leveren danwel te
> ontvangen.

Dat zijn, tenzij het om spam of virussen vanaf
gecompromitteerde PC's gaat, in verreweg de meeste gevallen
IP-adressen van MTA's. Voor de opsporing is van belang op
welk IP-adres de MUA draaide en dat gegeven staat normaal
gesproken niet in /var/log.

> > vage termen als "koptekst"
> Dat is raar omdat dit gewoon bij het Europees
> Parlement en EURlex is te vinden.

Ik kan het niet vinden, kom maar op met die URL.

> > AIVD'ers in deze verkeersgegevens gaan spitten
> Dat kan niet omdat de gegevens bij de
> dienstenaanbieders zelf wordt opgeslagen

Minister Donner in 2004-2005 2324: Zie ook:
https://www.aivd.nl/werken_bij_de_aivd/vacatures/ict-specialist
(bron: http://www.webwereld.nl/articles/38870).

De optie om internet verkeersgegevens centraal (bijv. bij
CIOT) op te slaan staat bij mijn weten nog open.

> > toegankelijk te maken voor alle
> > opsporingsambtenaren.
> De drempel is dat het moet gaan om een misdrijf
> waarvoor ten minste voorlopige hechtenis geldt
> danwel om verkenning (wbob)

Minister Donner: Noch in 126NA, noch in 126N lid 2 en 3 zie ik iets over de
ernst van het misdrijf waar de betrokkene van wordt
verdacht.

> Een tap werkt in deze totaal anders dan het
> bijhouden van verkeersgegevens.

Ik hoop dat je gelijk hebt maar het verschil is mij nog
steeds niet duidelijk. En ik ga me niet laten overtuigen
door iemand's vermoeden op security.nl, en zeker niet door
anoniem (doe geen moeite). Ik wil dit soort informatie klip
en klaar van bewindslieden vernemen, maar of ze snappen er
zelf geen bal van, of het is in hun belang om geheimzinnig
te doen. Ik vermoed het laatste.

Erik van Straten

gecodeeerde berichtjes in discusie forums:
Achmet zegt, allahs broodjes zijn warm afgelevert bij de toren

Dat bewaren van onbeantwoorde telefoonoproepen gebeurt al.
Sommige telco's kunnen hun klanten bedienen met schitterende
statistieken, misschien nog niet elke telco.
Uit COM(2005) 439 (2005/0182 COD):
Het voorstel gaat qua impact op de burgers en het
bedrijfsleven niet verder dan hetgeen strikt noodzakelijk is
en is dus in overeenstemming met het evenredigheidsbeginsel.
Dat hoeft ook niet. Het Europees
Parlement gaat uit van het loggen aan weerszijde van de
tunnels, door de dienst zelf. MSN-verkeer loopt bijvoorbeeld
over de servers van MSN: dus daar zullen de connecties
worden bijgehouden voor die specifieke dienst. Dat kun je
niet van ISP's verlangen. Het gestelde inzake onbeantwoorde
verbindingen geldt enkel voor telefonie.
Dan kijk nog maar eens.
Als je bijvoorbeeld een mailtje ontvangt van iemand over
Versatel, dan staat daar in je log het IP van Versatel's MTA
die het bij je afleverde. In de log van die MTA (in dit
geval die van Versatel, bij Versatel) staat het IP van de
MUA. Indien iemand een mail verstuurd over je eigen MTA dan
staat er in je eigen log ook het IP van de MUA.
Het gaat er om dat het terug te traceren is.
Volgens mij ging het hier niet om al het
verkeer van iedereen, maar om opgevraagde gegevens
centraal op te slaan. Dat is een groot verschil.

Hmm... dat zal lekker smaken, Achmet zal beloond worden.

8^)

-R.

Anoniem op dinsdag 20 december 2005 08:38:
> Dat bewaren van onbeantwoorde telefoonoproepen
> gebeurt al. Sommige telco's kunnen hun klanten
> bedienen met schitterende statistieken, misschien
> nog niet elke telco.

Statistieken? Ik dacht dat we het over gegevens t.b.v.
opsporing hadden. Daarnaast zou het volgende allemaal
flauwekul zijn?

Stratix: KPMG: Orange/Telfort/Vodafone/T-Mobile: Minister Donner:
> Uit COM(2005) 439 (2005/0182 COD):
> Het voorstel gaat qua impact op de burgers en
> het bedrijfsleven niet verder dan hetgeen strikt
> noodzakelijk is en is dus in overeenstemming
> met het evenredigheidsbeginsel.

Dat is de mening van de opstellers van dit voorstel.
Wat had je verwacht.

> > tunnels
> Dat hoeft ook niet. Het Europees Parlement gaat uit van
> het loggen aan weerszijde van de tunnels, door de
> dienst zelf.

Uhh? Wat minister Donner beschrijft gaat niet over
tunnels tussen ISP's onderling. De "dienst" vindt plaats op
locaties waar niet gelogd hoeft te worden, nl. bij
mensen thuis en/of bij bedrijven.

> In de log van die MTA (in dit geval die van Versatel, bij
> Versatel) staat het IP van de MUA. Indien iemand een
> mail verstuurd over je eigen MTA dan staat er in je
> eigen log ook het IP van de MUA. Het gaat er om dat
> het terug te traceren is.

Indien iemand via Yahoo.com een mailtje naar bijv. een
Chello.nl klant stuurt (die later een crimineel of terrorist
blijkt te zijn) dan staat in /var/log/maillog bij Chello
alleen het IP-adres van een Yahoo MTA, niet van de afzender
MUA. En dat is zeer gewenste info, want als dat binnen de EU
is weet je waar je verder moet sporen. Als het een adres
buiten de EU is, tref je wellicht een ISP die bereid is mee
te werken, en zo niet weet je op basis van dat afzender
IP-adres in elk geval het land.

Natuurlijk had Yahoo in haar logs wel het IP-adres
van de afzender, maar die logs bewaren ze vast niet zo lang
als de EU wil, en mochten ze die logs nog hebben, is het nog
maar helemaal de vraag of ze die afstaan. Hetzelfde geldt
voor iemand die vanuit een groter bedrijf of (niet openbare)
organisatie een e-mail verstuurt (direct of via een MTA);
voor zo'n bedrijf/organisatie is er geen verplichting om te
loggen. En als ik een crimineel zou zijn en m'n eigen
MTA zou draaien, denk je dan echt dat ik daarop logs zou
bewaren?

Ik ben tegen het opslaan van verkeersgegevens van
niet-verdachte personen, maar als je dat dan toch
doet, doe het dan niet half, en sla op MTA's van ISP's ook
de door andere MTA's toegevoegde headers op - maar NIET het
subject (onderwerp), want dat bevat inhoudelijke informatie.

> > De optie om internet verkeersgegevens centraal (bijv.
> > bij CIOT) op te slaan staat bij mijn weten nog open.
> Volgens mij ging het hier niet om al het
> verkeer van iedereen, maar om opgevraagde
> gegevens centraal op te slaan.

Ik schrijf nergens "al het verkeer van
iedereen". Optie 2 in het KPMG rapport behelst het
-ongevraagd- opslaan van alle onderhavige verkeersgegevens
bij CIOT (push) zodat deze last bij ISP's wordt weggenomen.
Zie bijv. http://www.security.nl/article/11723/1/
met minister Donner's mening over deze optie en
http://www.security.nl/article/11738/1 voor de
mening van de providers.

> > 126NA
> Mee eens, maar dan ben je al bezig met strafvordering,
> niet met ongebreiteld gegevens opvragen.

Dat is nou precies het probleem. Straks is er bij het CIOT
een grote database met gegevens die flink kunnen verschillen
in gevoeligheid. Wie bepaalt wie bij welke gegevens mag, en
onder welke omstandigheden? Wie controleert dat, en hoe? Als
een agent zijn eigen vrouw verdenkt van buitenechtelijke
contacten, kan hij dan via CIOT nagaan wanneer en met wie
zij e-mailt?

Erik van Straten

Correct, gegevens die al voor
verschillende doelen worden gebruikt - zoals die de basis
vormen van klantspecifieke statistieken in het mom van
klantenservice - zijn mede interessant voor opsporing.
In het voorgaande bericht schreef ik:
Sommige telco's kunnen hun klanten bedienen met
schitterende statistieken, misschien nog niet elke
telco.
Volgens mij haal je twee dingen
door elkaar: het voorstel tot wijziging van richtlijn
2002/58/EG (COM(2005)0438 –
C6-0293/2005 – 2005/0182(COD)) dat onlangs door Europa is
behandeld en de discussie die in het verleden hier in
Nederland is gevoerd.
Een
Europese Richtlijn geldt binnen de Unie en inderdaad niet in
het buitenland zoals Amerika.
Al zou een Europeaan gebruikmaken van een dienst in het
buitenland, dan kan niet van zijn of haar ISP worden
verlangt dat specifiek verkeer te onderscheppen om te
loggen. De wijze waarop welke gegevens worden verwerkt is
dienst-specifiek. Geen webmail is bijvoorbeeld dezelfde.
Vandaar de logverplichting bij de (Europese) dienstaanbieder
zelf ligt.
Loggen is noodzakelijk voor het beheer, maar waar zou deze
ontheffing te vinden zijn?
Vast niet, maar staat of valt het principe
niet bij zijn of haar logs.
Daar heb je niets aan, deze headers
worden door criminelen zoals spammers reeds gefingeerd. Het
enige waar je hard op kunt vertrouwen is wat je dienst
rechtstreeks kan achterhalen voor wat betreft het systeem
dat er contact mee zoekt. Bovendien moet het mogelijk
blijven om systemen te weren, zonder daar eerst iets van aan
te hebben moeten nemen.
Dit zijn discussie's van
ruim voor de wijziging van 2002/58/EG (COM(2005)0438 –
C6-0293/2005 – 2005/0182(COD)). Van belang is hoe men deze
recent gewijzigde Europese Richtlijn in de lokale wetgeving
gaat implementeren.

Anoniem op woensdag 21 december 2005 13:44:

> Loggen is noodzakelijk voor het beheer,

Dat is het niet. Wel kan het handig zijn bij het achteraf
verklaren van problemen, maar logs kunnen ook een aantasting
van de privacy betekenen.

Overigens bevatten de meeste standalone MUA's een halve MTA
(send only). De meest gebruikte MUA's loggen, in elk geval
by default, niet als ze via SMTP mail verzenden.

> maar waar zou deze ontheffing te vinden zijn?

Hoewel ik geen jurist ben voel ik aan mijn water dat er geen
wet is in Nederland die je ontheft van de
verplichting om te loggen. Wat ik me kan voorstellen is
dat er een wet bestaat die zegt dat je, bijv. als bedrijf,
wel moet loggen, maar die ken ik dan nog niet. Als
zo'n wet bestaat dan verneem ik dat graag.

> > sla op MTA's van ISP's ook de door andere MTA's
> > toegevoegde headers op
> Daar heb je niets aan, deze headers worden door
> criminelen zoals spammers reeds gefingeerd.

Dat je daar niets aan hebt is onjuist. Correct is dat
spammers (en mogelijk andere criminelen dan spammers) vaak
gefingeerde "Received" regels bovenaan de e-mail zetten
(d.w.z. bovenaan op het moment van verzending) in de hoop
onervaren lezers daarmee te misleiden. De eerste betrouwbare
MTA zal hier een Received headerregel boven schrijven
met daarin het IP-adres van de aanbieder; vanaf die
headerregel (en daar weer boven) valt er niets meer te
fingeren door de afzender; immers, hij kan er niet meer bij.

Als je weet (ervaring) van hoe de headers die door MTA's van
de meeste grote providers (met name die met anonieme wegwerp
accounts), er uit zien, is het een koud kunstje om het
IP-adres van de SMTP originator te achterhalen. Ook als dat
een SSH server, een open proxy c.q. een backdoored PC
betreft, is dat een spoor.

Voorbeeld (van vanavond, niets van verzonnen, alleen m'n ISP
gemunged en in de envelope-from de @ vervangen door / om een
onschuldige Joe spam te besparen):

Received: from 66-168-106-3.dhcp.mdvl.ga.charter.com
(66-168-106-3.dhcp.mdvl.ga.charter.com
[66.168.106.3]) by [mijn_ISP_munged] with ESMTP id
jBLIVpGa016539; Wed, 21 Dec 2005 19:31:53 +0100
(CET) (envelope-from bodyak_bella/bk.ru)
Received: from unknown (HELO mxs.mail.ru) (194.67.23.20)
by 66-168-106-3.dhcp.mdvl.ga.charter.com with
SMTP; Wen, 21 Dec 2005 20:28:55 -0800

Er zijn twee mogelijkheden: 66.168.106.3 is de originator,
of het is een (open) relay; in dat geval is 194.67.23.20 de
originator. Echter, uit de hostname mxs.mail.ru leid ik af
dat dit een mailserver is (het IP-adres klopt). Als die niet
gehacked is, is de kans wel erg klein dat deze via een relay
op een dhcp host in de USA zou mailen.

Bovendien zie je dat er vaak fouten worden gemaakt in deze
gefingeerde headers. Bijv. IP-adressen zijn vaak random
waardes, ik heb ze wel met 255 zien beginnen en octets ook
wel eens groter gezien dan 255. In het bovenstaande
voorbeeld is "Wen" getikt i.p.v. "Wed". Ook zou de klok op
die charter PC een flink stuk voor moeten lopen met de
"gelogde" tijd (op zich niet ogebruikelijk maar wel een
aanwijzing). Tenslotte verwacht ik niet dat mxs.mail.ru nog
HELO zegt, maar dat zou weer wel kunnen als deze gehacked is
(of er gewoon een SSH or telnet server o.i.d. op draait).
Maar dan nog is de kans klein dat op een dhcp host bij
Charter een open relay draait. Stel dat dit toch het geval
is. Dan betreft het geen slimme spammer, want hij zou kunnen
weten dat de open relay de header met mxs.mail.ru zou
toevoegen. Of hij is heel slim en gokt dat ik denk dat hij
stom is. Dan is er nog een mogelijkheid: de Charter host is
wel een open relay maar voegt geen headerregel toe. In al
deze gevallen leidt het spoor in bovenstaand voorbeeld naar
66.168.106.3 en is 194.67.23.20 te onwaarschijnlijk en te
onbetrouwbaar om iets mee te doen.

Volgens
http://www.dnsstuff.com/tools/city.ch?ip=66.168.106.3
bevindt de charter aansluiting zich in de omgeving van
Suwanee, Georgia, USA. Of de wetgeving (en/of een lokale
sherrif) in Georgia je behulpzaam zal zijn bij verder
onderzoek weet ik niet (da's m'n vak niet).

Het komt maar zelden voor dat ik twijfel over een
originating IP-adres in een e-mail. In het geval van spam is
het simpel: meestal zijn dergelijke hosts al aangemeld bij
de bekende blacklists, en anders gebeurt dat vaak binnen 24
uur. Zie bijv.
http://cbl.abuseat.org/lookup.cgi?ip=66.168.106.3&.submit=Lookup
of
[ur]http://www.spamcop.net/w3m?action=checkblock&ip=66.168.106.3[/url]
(hmm, abuse bij charter.com bounces, Sober problemen?)

In geval van sporenonderzoek is alleen al het gegeven dat
het woord "dhcp" in de hostname voorkomt, interessant.
Wellich kan d.m.v. ander onderzoek achterhaald worden via
welk botnet zo'n PC wordt aangestuurd, en kun je zo
eventuele verdachten achterhalen. Kortom, een IP-adres van
de originator is de enige zekerheid die je hebt over een
afzender die niet via een MTA van een openbare Europese ISP
e-mailt.

Ik vermoed dat criminelen vaak van anonieme wegwerp e-mail
accounts gebruik maken. Als dat klopt, is het stom om geen
Received headers (verkeersgegevens pur sang) te loggen bij
ISP's waar e-mail door een MTA gaat. Sterker, dan wordt veel
belastinggeld verspild en is het discriminerend jegens
Europeanen die netjes via de MTA van hun ISP's met elkaar
mailen, omdat zij een grotere kans lopen om onterecht (bijv.
door fouten of onjuiste inzichten) als verdachten te worden
aangemerkt.

Mijn vermoeden is echter dat minister Donner met "koptekst"
wel degelijk e-mail headers bedoelt. Alleen heb ik nog
steeds van niemand antwoord gekregen of gevonden op de vraag
of daaronder ook de subject regel (onderwerp) verstaan wordt.

Ik denk dat ik m'n oude Yahoo account maar weer ga
gebruiken. En als onderwerp voortaan net zulke briljante
teksten kies als de meeste Nederlanders, dus "Vraagje" of "LOL".

Erik van Straten

Het begrip 'log' is vrij
ruim, je kunt er vooraf aandachtpunten mee signaleren.
Kunnen en zijn zijn twee verschillende dingen.
Dat
is correct en zijn MUA's geen dienstaanbieders.
Eens, maar ga je in theorie al uit van een
betrouwbare MTA in het traject (los van je eigen,
ontvangende MTA). Als je dan bedenkt dat redelijk wat spam
en phishing mails worden verzonden vanaf achter elkaar
geschakelde gecompromitteerde computers verspreid over de
gekste windstreken in de wereld die de headers fingeren,
bieden de headers in dat geval opsporingstechnisch geen
bruikbaar spoor, wel de logregel met daarin de gegevens van
het systeem die het bericht bij je afleverde. Dat heb ik aan
willen geven.
Maar als je het verder doortrekt kunnen gefingeerde headers
wel als belastend bewijs dienen, dat bijvoorbeeld opzet
duidt e.d.
Dan kunnen zulke headers van nut zijn.
Het nut hangt van het doel af.
Dat ben ik met je eens, en
wellicht ben je dan soms minder afhankelijk van de
medewerking van het buitenland buiten de Unie. Ideaal gezien
vanuit opsporingsoogpunt: Hoe meer gegevens hoe completer,
liever meer of teveel dan te weinig.
Of het proportioneel is dat van
dienstenaanbieders te verlangen te bewaren, is een
tweede. Dat gaat zeker hogere verwerkings- en
opslagcapaciteit verlangen.

Vergeet ook niet de tapmogelijkheid. Ik denk dat het
goedkoper is om mensen die in beeld zijn gekomen en waarbij
meer gedetailleerde gegevens wenselijk zijn individueel te
tappen.
Met zulke blocklists hou je inderdaad mail
afkomstig van voorgaand genoemde gecompromitteerde systemen
goeddeels buiten de deur. Daarnaast kun je natuurlijk de
mailheaders en de mailbody checken tijdens ontvangst en deze
alsnog rejecten. Daar wil je de headers niet van bewaren,
wel de logregel. Anders loopt je log helemaal overvol met
headers van geweigerde mail.
Was het niet zo dat in het algemeen zeker 70% van al het
mailverkeer spam en ander ongein betreft?

Je kunt het hem zelf vragen: http://www.ministerdonner.nl/
Dan te bedenken dat veel van die
wegwerpadressen bij bedrijven worden geweigerd.