Přiškrcení českého Velkého bratra

Evropská unie požaduje po členských státech, aby jejich internetoví provideři získávali a uchovávali podrobné údaje o tom, co a jak uživatelé na Internetu dělají. Rozsah údajů vymezuje unijní směrnice z roku 2006. Česká republika ale již od roku 2005 požaduje ještě rozsáhlejší údaje, značně nad rámec unijní směrnice. A teprve teď je šance na určitou redukci na evropskou úroveň.

Problematika uchovávání provozních a lokalizačních údajů, známá také pod termínem „data retention“, je značně rozsáhlou partií, a současně i hodně kontroverzním tématem. Do budoucna o něm určitě budeme slýchat stále více. A to, co se přitom budeme dozvídat, se nám jako občanům asi bude líbit čím dál tím méně – s tím jak  náš stát, zastřešený Unií, bude chtít ukusovat z našeho soukromí  stále více a více. 

Dnešní článek ale bude z tohoto trendu poněkud vybočovat, protože v něm budu přece jen popisovat určité uvolnění, resp. zmínění, týkající se právě Internetu a jeho služeb.

Jak se psala historie?

Abych ale v někom nevzbuzoval plané naděje:  alespoň podle mého názoru nejde o žádný zvrat v celkovém trendu „přituhování“. Jde spíše o jednorázovou nápravu specifické situace, která vznikla zde v ČR koncem roku 2005. Právě tehdy jsme totiž předběhli dobu i evropskou směrnici o data retention (Směrnici Evropského parlamentu a Rady 2006/24/ES), vydanou až v roce 2006, a skrze vyhlášku č. č. 485/2005 Sb. sami sobě naordinovali ještě podstatně přísnější a detailnější požadavky na sledování aktivit uživatelů na Internetu, než jaké posléze přinesla finální podoba evropské směrnice.

Nikdo se pak neměl k tomu, aby věci uvedl na pravou míru: aby přiznal, že jsme něco přepískli, a naše přemrštěné požadavky na uchovávání údajů zase zredukoval na míru danou samotnou evropskou směrnicí. Česká republika dokonce využila možnosti a odložila implementaci předmětné směrnice (2006/24/ES) o plných 36 měsíců, konkrétně do 14. března 2009, právě pokud jde o uchovávání údajů kolem Internetu a internetových služeb.

Podobně se sice zachovala i řada dalších zemí, ale u nich to mělo obvyklou logiku: odložili na pozdější dobu něco přísnějšího, resp. tvrdšího, než co u nich platilo původně. Jen u nás ten odklad nakonec vyzněl přesně opačně, než by zdravý rozum velel: u nás jsme si nejprve uložili ještě přísnější a tvrdší povinnosti, a díky odkladu jsme je pak nemuseli mírnit příliš brzy.

Přichází novela

Nicméně konec odkladu se blíží, a tak i u nás se již daly věci do pohybu. Nakonec se vše spojilo s poslední novelou zákona o elektronických komunikacích (zákonem č. 247/2008 Sb.), která nabyla účinnosti k 1. září. Tato novela se primárně věnovala právě transpozici předmětné evropské směrnice (2006/24/ES) do naší legislativy, a to ve všech oblastech, kterých se tato směrnice týká. Tedy kromě Internetu hlavně pevných a mobilních sítí a služeb.

Pokud jde o hlasové služby, zde novela řeší  i údaje o tzv. prozvánění (neúspěšných pokusech o volání). Ovšem způsobem, který jsem zde na Lupě popisoval v pondělním článku (Stalo se: prozvánění po česku) jako „skulinku“, či spíše „velká vrata“: operátoři musí nově uchovávat také tyto údaje – ale pouze tehdy, pokud jejich systémy příslušná data již dříve generovaly a zpracovávaly. A to nedělaly. Takže pokud operátoři nechtějí, ani dnes nemusí s evidováním neuskutečněných hovorů začít. A mobilní operátoři již dali najevo, že nechtějí.

Dlužno dodat, že takto je to s údaji o prozvánění definováno už v samotné evropské směrnici, a nejde tedy o nějakou tuzemskou švejkovinu.

Ovšem pokud byste v nedávné tuzemské novele (zákoně č. 247/2008 Sb.) hledali nějakou explicitní zmínku o Internetu a jeho službách, nenašli byste ji. Změny týkající se Internetu jsou zde řešeny nepřímo, odkazem na prováděcí předpis (vyhlášku):

Rozsah provozních a lokalizačních  údajů  ……  stanoví prováděcí právní předpis.

Oním prováděcím předpisem bude nová verze dosavadní vyhlášky (č. 485/2005 Sb.). Připravuje ji Ministerstvo průmyslu a obchodu, a zatím existuje jen v předběžné pracovní verzi. Nicméně již z tohoto návrhu, a hlavně jeho srovnáním s dosavadní vyhláškou, si lze učinit dostatečný obrázek o celé situaci. O tom, co a jak jsme původně „přepískli“ a dnes musíme redukovat.

Jak je tomu doposud?

Abychom náležitě docenili změny, které jsou na obzoru, pojďme si nejprve ukázat, jak neuvěřitelně rozsáhlé a podrobné údaje požaduje dodnes platná prováděcí vyhláška č. 485/2005 Sb., kterou připravilo ještě Ministerstvo informatiky ČR (a pod kterou je podepsána ministryně Dana Bérová).

Zůstaneme přitom jen u Internetu a jeho služeb. Přesněji u veřejných sítí, fungujících na principu přepojování paketů, a u jejich služeb, protože prováděcí vyhláška je takto obecná a neomezuje se jen na Internet. Nicméně rozlišuje zde celkem pět oblastí, a u každé z nich vznáší konkrétní požadavky na získávání a uchovávání dat, a to po dobu 6 měsíců:

  • Přístup k sítí: zde ten, kdo připojení poskytuje, musí uchovávat údaje o tom, koho a jak připojil (tj. o každé relaci), přes jakou přípojku, od kdy a do kdy připojení trvalo, jaké koncové zařízení uživatel používal (jeho MAC adresu), jakou měl uživatel IP adresu, i kolik bytů dat přenesl (za celou relaci).
  • Přístup ke schránkám elektronické pošty: zde musí poskytovatel služby uchovávat prakticky vše, kromě samotného obsahu zpráv: odkud a jak uživatel „sahal“ do své poštovní schránky, kolik bytů přitom přenesl, zda používal či nepoužíval šifrování, a také s jakými zprávami manipuloval: kdo byl jejich odesilatelem a příjemcem, i jaký jednoznačný identifikátor (Message ID) měla každá zpráva.
  • Přenos (odesílání) zpráv elektronické pošty: zde musí poskytovatel evidovat stejné údaje jako při příjmu zpráv (přístupu ke schránkám). Opět včetně objemu přenesených dat a informaci o použití či nepoužití zabezpečené komunikace.
  • Serverové služby (kam nutně spadají například WWW servery): jejich provozovatelé musí evidovat každý jednotlivý požadavek, který dostávají, včetně plných URL a také plné identifikace žadatele. Požadována je i forma požadavku (například metody GET či POST), objem přenesených dat, a třeba i odpověď serveru (stavový kód).
  • Ostatní služby: zde vyhláška explicitně vyjmenovává služby typu chat, usenet, instant messaging a IP telefonie. A opět požaduje detailní údaje o každé jednotlivé komunikaci, relaci či transakci, včetně identifikace obou komunikujících stran (IP adresy, porty), objemu přenesených dat, aplikační služby i použitého transportního protokolu, a doby počátku a konce komunikace.

Pokud bych to měl shrnout, dosavadní prováděcí vyhláška (č. 485/2005 Sb.) nejde za hranici představovanou požadavkem na samotný obsah  komunikace. Stejně tak nepožaduje evidenci každého jednotlivého kroku uživatele (s výjimkou elektronické pošty). Nepožaduje například evidenci všech URL adres, na které konkrétní uživatel klikne (a kdy). Na druhou stranu ale požaduje snad úplně všechno ostatní. Včetně toho, že po každém provozovateli nějaké serverové služby (dle 4. oblasti) a vlastně i peer-to-peer služby (dle 5. oblasti) požaduje úplný výčet všech jednotlivých požadavků, včetně toho, od koho pochází.

Opravdu by mne zajímala zkušenost poskytovatelů, kteří takto požadovaná data uchovávají, po předepsaných 6 měsíců: jak velké náklady s tím mají, jak velké objemy dat to jsou, i jaké problémy to přináší. Nikdo, koho jsem kdy oslovil, nebyl ochoten se o tom bavit. Snad se někdo s konkrétními zkušenostmi ozve alespoň anonymně, v diskusi k tomuto článku.

Co se změní?

Pojďme nyní k tomu nejpodstatnějšímu: jaké konkrétní změny jsou na obzoru? S čím počítá a s čím naopak nepočítá návrh nové prováděcí vyhlášky, který již dává naši právní úpravu do souladu s evropskou směrnicí, i pokud jde o internetové služby?

Tak za prvé: nová prováděcí vyhláška zcela odbourává  oblast serverových služeb. Tj. nově už nepožaduje získávání a uchovávání takovýchto údajů (a jejich předávání oprávněným orgánům, na základě jejich žádosti). Důvod je zřejmý,  a je v návrhu nové prováděcí vyhlášky také explicitně zmíněn: služby překračují rámec směrnice. Chtělo by se dodat: konečně!

Další důležitá změna se týká páté oblasti, která až dosud zahrnovala (skrze „neuzavřený“ výčet) i služby jako je chat, usenet či instant messaging. Nyní zahrnuje pouze služby IP telefonie, takže ony ostatní služby z dosahu data retention také vypadávají! Důvod je stejný jako u serverových služeb: pro uchovávání provozních a lokalizačních údajů o těchto službách není opora ani v evropské směrnici.

Významné jsou ale i další změny, byť na první pohled se mohou zdát jen drobné. Tak například všude odpadají požadavky na sledování a evidování objemu přenesených dat. Stejně tak požadavek na sledování toho, zda je či není použito zabezpečené komunikace.

Jak konkrétně vypadají změny?

Další změny již mají spíše „právně-technický“ charakter, když dávají další konkrétní požadavky a ustanovení prováděcí vyhlášky do souladu s dikcí a terminologií evropské směrnice 2006/24/ES. Odpadá například specifické adjektivum „zájmové“ (například „zájmové zařízení“ či zájmový identifikátor“), a některé formulace se zpřesňují, či jen dostávají větší logiku a smysl.

Abychom si o tom všem udělali lepší představu, ukažme si to na prvních dvou oblastech.

První oblast je v dosavadní prováděcí vyhlášce pojata obecněji, jako „přístup k síti“. Nová úprava navrhuje konkrétnější „přístup k Internetu“. Fakticky jde o to, že musíte být nějakým způsobem připojeni, přes nějakého poskytovatele – a ten má povinnost zjišťovat a uchovávat údaje o tom, jak a kdy jste byli přes něj připojeni, jak dlouho, jakou adresu jste přitom měli, kolik dat jste přenesli.

Rozdíl v tom, co konkrétně zde požaduje dosavadní a nová vyhláška, ukazuje následující tabulka.

Dosud (vyhláška 485/2005 Sb.) Nově (návrh)
 – telefonní číslo nebo jiný identifikátor koncového bodu přístupu
typ připojení (zejména dial-up, ADSL, GPRS, kabelový modem, LAN) typ připojení (zejména dial-up, ADSL, GPRS, kabelový modem,LAN)
identifikátor uživatelského účtu identifikátor uživatelského účtu
identifikátor zařízení uživatele služby (zejména MAC, telefonní číslo účastníka u dial-up připojení), identifikátor zařízení uživatele služby (zejména adresa MAC, telefonní číslo účastníka u dial-up připojení),
datum a čas zahájení připojení datum a čas zahájení přístupu ke službě
datum a čas ukončení připojení datum a čas ukončení přístupu ke službě
zájmové identifikátory (zejména IP adresa a v případě nejednoznačnosti identifikace koncového zařízení z IP adresy také číslo portu, například PAT), přidělená IP adresa statická nebo dynamická (v případě nejednoznačnosti identifikace koncového zařízení z IP adresy také číslo portu, například PAT)
status události (například úspěch, neúspěch, řádné nebo mimořádné ukončení připojení)  –
množství přenesených dat v kilobytech [kB] (v příchozím směru/v odchozím směru)  –

Struktura údajů, požadovaných při přístupu k síti/Internetu

Z této tabulky je ihned patrné, že ze sledovaných a uchovávaných veličin odpadá poněkud vágní „statut události“, a hlavně údaj o množství přenesených dat. To naštěstí koreluje s tím, jak po zrušení objemových limitů operátoři přestávají měřit objemy dat, přenesené jednotlivými uživateli.

Co zůstává beze změny, je požadavek na MAC adresu zařízení koncového uživatele, případně telefonní číslo u dial-upu, přidělená IP adresa, a přesný okamžik připojení i odpojení. Dosti problematický mi přijde nezměněný požadavek „vidět skrz NAT“ (viz „v případě nejednoznačnosti identifikace koncového zařízení z IP adresy také číslo portu, například PAT“). Nejen kvůli technické realizaci, ale hlavně kvůli snaze nějak detekovat strukturu sítě za NATem. Ten může být (a často bývá) součástí nějakého firewallového řešení, za které by ani provideři ani stát opravdu neměli pronikat.  

Naopak se nově zavádí povinnost uchovávat „telefonní číslo nebo jiný identifikátor koncového bodu přístupu“, a to dokonce jako jakýsi „první“ identifikátor. Jde zřejmě o identifikaci přípojky jako takové, skrze zařízení na jejím konci (jako je kabelový modem, ADSL modem či nějaké bezdrátového pojítka apod.), zatímco požadovaná MAC adresa se týká až uživatelského zařízení. První možnost (telefonní číslo) mi přijde duplicitní s požadavkem na telefonní číslo u dial-upu.

Druhou oblastí, u které se zastavíme podrobněji, je „přístup ke schránkám elektronické pošty“. Tedy alespoň u dosavadní prováděcí vyhlášky, která rozlišuje mezi příjmem a odesíláním zpráv (přístupem do schránek a přenosem zpráv). Jak již bylo uvedeno výše, nová prováděcí vyhláška tyto dvě oblasti slučuje do jedné jediné (viz pravý sloupec následující tabulky).

Jak lze vidět, poskytovatel poštovních služeb by správně měl evidovat prakticky vše, co se svou schránkou a elektronickou korespondencí děláte, včetně podrobných údajů o každé zprávě, na kterou „jen sáhnete“. Nepožaduje sice uchovávat samotný obsah zprávy, ale jinak chce vědět snad opravdu vše.

Dosud (vyhláška 485/2005 Sb.) Nově (návrh)
identifikátor zájmového uživatelského zařízení (zejména IP adresa a číslo portu) identifikátor zařízení uživatele služby (IP adresa a číslo portu)
identifikátor uživatelského účtu identifikátor uživatelského účtu
identifikátor zprávy na poštovním serveru (ID Message),  –
datum a čas zahájení komunikace datum a čas zahájení přístupu ke službě
 – datum a čas ukončení přístupu ke službě
adresa elektronické pošty odesílatele adresa elektronické pošty odesílatele
adresy elektronické pošty příjemců adresa elektronické pošty příjemce a označení uživatele, který je příjemcem
identifikátor protokolu elektronické pošty (například POP3, IMAP) použitá služba (přístup ke schránce, odeslání zprávy)
množství přenesených dat v kilobytech [kB]  –
použití zabezpečené komunikace (ano – ne, případně jakým způsobem)  –

Struktura údajů, požadovaných při přístupu k poštovním schránkám

Dovolím si předpokládat, že autoři vyhlášky (stávající i nové) mají na mysli vytvoření jednoho záznamu s uvedenými položkami pro každou jednotlivou zprávu elektronické pošty. S tím koresponduje původní požadavek na  identifikátor zprávy (Message ID), nově již nevyžadovaný, či adresa příjemce a odesilatele. Naopak „datum a čas zahájení přístupu ke službě“, stejně jako nově přidané „datum a čas ukončení přístupu ke službě“, se mi zdají poněkud nejasné: má jít o začátek a konec relace přístupu ke schránce (například u POP3), nebo o začátek a konec zpracování dané zprávy? Třeba doby, po kterou uživatel četl svou zprávu, uloženou kdesi na serveru, přes protokol IMAP? To by se ale nedalo moc exaktně měřit.

Jak je i zde názorně vidět, nově odpadá uchovávání informace o velikosti zprávy, resp. množství přenesených dat. Stejně tak odpadá evidování toho, zda uživatel přistupoval zabezpečeným či nezabezpečeným způsobem. Nově však přibývá, kromě „údaje o konci přístupu“, také požadavek na vyřešení případných poštovních aliasů. Právě tak rozumím nově rozšířenému požadavku na „adresu elektronické pošty příjemce a označení uživatele, který je příjemcem“. 

No, ne že by takovéto údaje nebylo možné generovat a uchovávat. Ale jen si zkuste představit, jak náročné a nákladné to bude, při dnešním objemu elektronické poštovní komunikace.

UX16

Serverové služby

Na závěr si ještě pro úplnost ukažme původní čtvrtou oblast, která se týkala serverových služeb: co všechno zde stávající vyhláška č. 485/2005 Sb. požaduje  zaznamenávat a uchovávat – a co už se  nově uchovávat nebude, protože k tomu není opora ani v samotné evropské směrnici.

Dosud (vyhláška 485/2005 Sb.) Nově (návrh)
identifikátor zájmového uživatelského zařízení  –
identifikátor uživatelského účtu  –
datum a čas požadavku na službu  –
identifikátory serveru  –
požadovaný identifikátor URI nebo jiný identifikátor služby  –
parametry identifikátoru URI nebo služby  –
použitá služba (například ftp, http)  –
množství přenesených dat v kilobytech [kB]  –
metoda požadavku (například POST, GET, DEL)  –
status požadavku (například úspěch, neúspěch, time-out, stavový kód)  –

Struktura údajů, požadovaných u serverových služeb

Anketa

Jak hodnotíte samotný princip uchovávání dat?

78 názorů Vstoupit do diskuse
poslední názor přidán 8. 12. 2008 18:20
Zasílat nově přidané názory e-mailem

Školení Jak vytvořit rychle jednoduchý web

  •  
    Jak mít na Internetu blog.
  • Jak si založit web na Wordpressu.
  • Jak pokračovat v jeho provozování.

Detailní informace o školení Jak vytvořit rychle jednoduchý web »