DIPLOMOVÁ PRÁCE. Podpora pro rodičovský mód v KDE Bc. Jiří Holomek. Vedoucí práce: Mgr. Petr Krajča, Ph.D

DIPLOMOVÁ PRÁCE

Podpora pro rodičovský mód v KDE

2015

Bc. Jiří Holomek

Vedoucí práce: Mgr. Petr Krajča, Ph.D.

Studijní obor: Informatika, prezenční forma

Bibliografické údaje Autor:

Bc. Jiří Holomek

Název práce:

Podpora pro rodičovský mód v KDE

Typ práce:

diplomová práce

Pracoviště:

Katedra informatiky, Přírodovědecká fakulta, Univerzita Palackého v Olomouci

Rok obhajoby:

2015

Studijní obor:

Informatika, prezenční forma

Vedoucí práce:

Mgr. Petr Krajča, Ph.D.

Počet stran:

77

Přílohy:

1 USB flash disk

Jazyk práce:

český

Bibliograhic info Author:

Bc. Jiří Holomek

Title:

Parental mode in KDE

Thesis type:

master thesis

Department:

Department of Computer Science, Faculty of Science, Palacký University Olomouc

Year of defense:

2015

Study field:

Computer Science, full-time form

Supervisor:

Mgr. Petr Krajča, Ph.D.

Page count:

77

Supplements:

1 USB flash disk

Thesis language:

Czech

Anotace Práce se zabývá analýzou možností filtrování obsahu webových stránek a omezení funkcionality (tzv. rodičovský mód) pro desktopové prostředí KDE za pomocí frameworku Kiosk a frameworku KConfig. Pro rodičovský mód bude přeportován nástroj pro ovládání Kiosku z KDE3 do KDE4. Navržený filtr obsahu webových stránek, vzhledem k volbě jazyka Python a návrhu, je použitelný i v jiných systémech jako je Windows nebo Mac OS.

Synopsis The thesis deals with analysis of options of web content filtering and functions limitation (ie. the parental mode) for the KDE desktop environment using Kiosk framework and KConfig framework. For the parental mode there will be ported tool to control Kiosk from KDE3 to KDE4. The filter of web content, in consideration of the choice of Python language and its design, is also applicable in other systems such as Windows or Mac OS.

Klíčová slova: Kiosk; KDE; rodičovský mód; filtrování obsahu; klasifikace dokumentů Keywords: Kiosk; KDE; parental mode; content filtering; document classification

Děkuji vedoucímu práce Mgr. Petru Krajčovi, Ph.D. za cenné rady při tvorbě této diplomové práce. Dále děkuji své rodině za podporu během doby studia.

Místopřísežně prohlašuji, že jsem celou práci včetně příloh vypracoval/a samostatně a za použití pouze zdrojů citovaných v textu práce a uvedených v seznamu literatury.

datum odevzdání práce

podpis autora

Obsah 1 Úvod

9

2 Rodičovský mód a filtrování obsahu webových stránek 2.1 Možnosti rodičovského módu . . . . . . . . . . . . . . . . 2.1.1 Restrikce pro osobní počítač . . . . . . . . . . . . 2.1.2 Restrikce pro mobilní zařízení . . . . . . . . . . . 2.2 Filtrování obsahu webových stránek . . . . . . . . . . . . 2.2.1 Umístění filtru . . . . . . . . . . . . . . . . . . . 2.2.2 Útok typu Man In The Middle . . . . . . . . . . . 2.2.3 Samotné filtrování . . . . . . . . . . . . . . . . . 2.2.4 Standardy pro hodnocení webových stránek . . . 2.2.5 Úprava výsledků vyhledávačů . . . . . . . . . . . 2.2.6 Blokování přespříliš vs. málo . . . . . . . . . . . . 3 Možnosti rodičovské kontroly dle platforem 3.1 Windows . . . . . . . . . . . . . . . . . . . . . . . 3.2 Mac OS . . . . . . . . . . . . . . . . . . . . . . . 3.3 Linux . . . . . . . . . . . . . . . . . . . . . . . . 3.4 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Android . . . . . . . . . . . . . . . . . . . . . . . 3.6 Srovnání operačních systémů . . . . . . . . . . . . 3.7 Dostupné aplikace pro filtrování webových stránek

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

10 10 10 11 12 12 12 13 14 18 19

. . . . . . .

20 20 25 29 29 32 34 35

4 KDE 37 4.1 Přechod mezi major verzemi KDE . . . . . . . . . . . . . . . . . . 37 4.2 Spiny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5 Kiosk framework 5.1 Konfigurační soubory a jejich hierarchie 5.2 Action restrictions . . . . . . . . . . . 5.3 URL restrictions . . . . . . . . . . . . 5.4 Control Module Restrictions . . . . . . 5.5 Resource Restrictions . . . . . . . . . . 5.6 KioskTool . . . . . . . . . . . . . . . . 5.7 Další možné restrikce . . . . . . . . . . 6 Automatická klasifikace dokumentů 6.1 Klasifikace textových dokumentů . . 6.2 Předzpracování dat . . . . . . . . . . 6.3 Klasifikátory . . . . . . . . . . . . . . 6.3.1 Support Vector Machine . . . 6.3.2 Naivní Bayesovský klasifikátor 6.3.3 Vyhodnocení výsledků . . . .

5

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

39 40 41 42 43 43 44 44

. . . . . .

45 45 46 50 50 52 56

7 Dosažené výsledky 58 7.1 Kiosk a KioskTool . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2 Aplikace TimeKicker . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.3 Filtr obsahu webových stránek . . . . . . . . . . . . . . . . . . . . 63 Závěr

72

Conclusions

73

A Obsah přiloženého USB flash disku

74

Seznam zkratek

75

Literatura

76

6

Seznam obrázků 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Útok typu MITM přes HTTP . . . . . . . . . . . . . . . Útok typu MITM přes HTTPS . . . . . . . . . . . . . . GUI pro nastavení přístupu k PC ve Windows 8 . . . . . Hodnocení PEGI, zdroj [8] . . . . . . . . . . . . . . . . . GUI pro časové nastavení přístupu k PC v Mac OS 10.10 Nastavení omezení v systému iOS . . . . . . . . . . . . . Výběr profilu na uzamknuté obrazovce v Androidu . . . GUI aplikace Kiosk admin tool. . . . . . . . . . . . . . . Tokenizace - převod textu na tokeny . . . . . . . . . . . SVM - možná proložení přímky. . . . . . . . . . . . . . . SVM - geometrický popis, zdroj [22] . . . . . . . . . . . . Aplikace KioskTool – port pro KDE4 . . . . . . . . . . . Aplikace TimeKicker – nastavení profilu . . . . . . . . . Aplikace TimeKicker – notification v KDE4 . . . . . . . Aplikace BanTheWeb – nastavení profilu . . . . . . . . . Upozornění uživatele na neoprávněný přístup . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

13 14 22 23 27 30 33 44 46 51 52 60 61 62 69 70

Seznam tabulek 1 2 3 4 5 6 7 8

Statistiky používání hodnocení obsahu na velkém vzorku webových stránek s pornografickým obsahem . . . . . . . . . . . . . . Statistiky používání hodnocení obsahu na nejnavštěvovanějších webech v kategorii pornografie dle žebříčku [5] . . . . . . . . . . . Statistiky použití operačních systémů, zdroj dat [7] . . . . . . . . Příklad základních pravidel stemmingu – algoritmus Porter’s stemmer, zdroj [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Příklad pro Naivní bayesovský klasifikátor . . . . . . . . . . . . . Procentuální úspěšnost a doba běhu klasifikátorů na nezpracovaných dokumentech . . . . . . . . . . . . . . . . . . . . . . . . . . Procentuální úspěšnost a doba běhu klasifikátorů na viditelném textu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procentuální úspěšnost a doba běhu klasifikátorů na extrahovaném obsahu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 17 20 48 54 65 65 67

Seznam zdrojových kódů 1 2 3 4 5

PICS - použití metatagu . PICS - použití tagu rating PICS - popis více kategorií Meta tag rating . . . . . . Meta tag rating s využitím

. . . . . . . . . . obsahu . . . . . RTA . . 7

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 15 16 16 16

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Nastavení RTA ratingu pro celý APACHE server . . . . . . . . . Ukázka konfiguračního souboru KDE . . . . . . . . . . . . . . . Kiosk - nastavení příznaku immutable . . . . . . . . . . . . . . . Kiosk - zamknutí skupiny nastavení . . . . . . . . . . . . . . . . Kiosk - nastavení profilů pro uživatele a skupiny . . . . . . . . . Kiosk - restrikce menu Úpravy . . . . . . . . . . . . . . . . . . . Kiosk - vzor pro zápis pravidel . . . . . . . . . . . . . . . . . . . Kiosk - restrikce přístupu na disk . . . . . . . . . . . . . . . . . Kiosk - restrikce kcm modulů . . . . . . . . . . . . . . . . . . . Kiosk - restrikce aplikací spouštějících se po startu . . . . . . . Určení pravděpodobnosti slova na základě Document Frequency Multinomiální model - trénování corpusem dokumentů [1] . . . . Multinomiální model - klasifikace dokumentu [1] . . . . . . . . . Bernoulliho model - trénování corpusem dokumentů [1] . . . . . Bernoulliho model - klasifikace dokumentu [1] . . . . . . . . . . Obsah meta tagu keywords . . . . . . . . . . . . . . . . . . . . . Kiosk - Zákaz editace proxy . . . . . . . . . . . . . . . . . . . .

8

. . . . . . . . . . . . . . . . .

17 40 41 41 41 42 42 43 43 43 50 53 54 55 55 66 70

1

Úvod

V dnešní době mají uživatelé zařízení s přístupem k internetu téměř neomezené možnosti k získávání informací. Často je ale potřeba aktivity uživatelů omezit, a to ať už se jedná o zaměstnance ve firmě, studenty ve škole nebo malé děti. Nemusí se jednat pouze o pohyb uživatelů na webu, občas je potřeba upravit i oprávnění k lokálním prostředkům v zařízení. Téma diplomové práce jsem si vybral zejména proto, že jsem se chtěl zapojit do vývojářské komunity KDE a chtěl jsem tak přispět svým dílem k lepší funkcionalitě tohoto desktopového prostředí, které je určené pro Linux. Tento projekt je vyvíjen pod licencí GPL. Součástí KDE je sada frameworků, které usnadňují vývoj aplikací určených pro toto prostředí. Jedním z těchto frameworků je i Kiosk, jehož nástroje se dají použít pro vytvoření tzv. rodičovského módu. Tyto nástroje se používají pro zamykání jednotlivých (hlavně) grafických komponent systému nebo samotných aplikací. Z dokumentace plyne, že lze snadno vypnout např. přístup k terminálu, nastavení plochy nebo tiskového serveru. Problém je, že od doby napsání této dokumentace pro KDE3 se udělalo hodně změň a úpadek zájmu o používání Kiosku vedl k ignoraci předchozí kompatibility nastavení restrikčních klíčů v nových verzích komponent, a proto je mnoho těchto klíčů nefunkčních, nebo funkčních pouze částečně. Hlavním cílem této práce je revize používaných klíčů v KDE5, oprava vzniklých bugů vzhledem k nekompatibilitě se způsobem použití klíčů v KDE3 a přeportování nástroje pro ovládání tohoto frameworku, protože od verze KDE3 se změnily i cesty pro ukládání konfiguračních souborů a jiné podstatné věci, díky nimž je nástroj v současné době nepoužitelný. Dále bude doplněna funkcionalita, která umožní použití více restrikcí pro vytvoření lepšího rodičovského módu. Dílčím cílem je pak navržení algoritmu pro filtrování obsahu webových stránek a zpracování analýzy, ve které se zaměřím na použití funkcí rodičovské kontroly i na jiných platformách než je Linux a otestuji jejich silné a slabé stránky.

9

2

Rodičovský mód a filtrování obsahu webových stránek

Motivací pro použití rodičovského módu a filtrování obsahu webových stránek může být několik. Především se tyto restrikce používají pro děti, protože je nechceme pustit někam, kam by neměly mít přístup. Další sférou uplatnění je použití tohoto módu na pracovišti – buď proto, aby řadový zaměstnanec nemohl do administračních věcí, nebo, a to se používá v současné době mnohem častěji, aby nemohl přistupovat na některé weby – hlavně sociální sítě. Tyto restrikce se používají na základě toho, že víme, kdo se zařízením bude pracovat. Může se ale stát, že chceme vytvořit rodičovský mód i tam, kde nevíme, kdo se zařízením bude zacházet. Jedná se o tzv. kiosky – veřejné terminály, používané hlavně pro prezentaci produktů, v internetových kavárnách aj. V této kapitole rozebereme, co je to přesně rodičovský mód, jaké restrikce se dají aplikovat pro jeho vytvoření a jak lze efektivně filtrovat obsah webových stránek.

2.1

Možnosti rodičovského módu

Rodičovským módem se označuje soubor resktrikcí, kterými je možné omezit přístup uživatele k jednotlivým aplikacím, službám nebo hardwarovému vybavení zařízení. Klasickým případem může být omezení používání tiskárny nebo instalace aplikací. Možnostem restrikcí webu se věnuje blíže Kapitola 2.2. 2.1.1

Restrikce pro osobní počítač

Níže je výpis restrikcí, které by vedly k možnosti ideální kontroly nad osobním počítačem tak, aby administrátor mohl přesně definovat, co uživatel s omezeným oprávněním smí a nesmí dělat: 1. časově omezený přístup k zařízení 2. časově omezený přístup k aplikacím s možností definice limitů pro jednotlivé aplikace resp. kategorie aplikací (např. hry) 3. přístup k aplikacím na základě věku 4. administrace systému (změna času, nastavení síťové karty aj.) 5. instalace / odebrání aplikací 6. sledování filmů a poslech hudby 7. přístupný obsah na webu 8. používání periferie - velkokapacitní zařízení, tiskárny 9. limity pro tisknutí 10

10. časově omezený přístup k webovým službám (web, FTP), případně možnost zakázání jednotlivých protokolů a komunikace mimo lokální síť Body 1, 2 a 3 by měly být nastavitelné buď na základě toho, kdy k nim může uživatel přistupovat nebo jak dlouho smí u dané entity strávit. Samozřejmostí je i možnost úplného vypnutí entity. Ideální způsob je i správa profilů restrikcí a jejich následné přiřazení k uživatelským profilům v počítači. Správa restrikcí, kdy se musí pro každého uživatele vyplňovat jednotlivě, je neefektivní a na zařízeních s větším počtem uživatelů nereálná k použití, protože změny je nutné dělat pro každého uživatele zvlášť (příkladem může být zákaz používání nově nainstalované aplikace pro některé uživatele – jednodušší je upravit jeden profil, který je přiřazen několika uživatelům). Bohužel žádný z dostupných operačních systémů nedisponuje všemi výše uvedenými možnostmi, podrobnější rozbor dle systému lze nalézt v Kapitole 3. 2.1.2

Restrikce pro mobilní zařízení

I přesto, že je tato práce zaměřená na KDE a tedy potažmo na osobní počítače, tak jsem do zpracování zahrnul i mobilní zařízení jako jsou chytré telefony a tablety, jež disponují už také vyspělými operačními systémy. Rád bych shrnul a porovnal, jakým způsobem lze aplikovat rodičovský mód pro tato zařízení. Z předchozí sumarizace možností restrikcí pro osobní počítače by se na mobilní zařízení daly aplikovat body 1 – 7. Dále lze zahrnout následující: 1. telefonování 2. psaní SMS zpráv 3. používání nákupů v aplikacích 4. použití technologií jako je GPS, WiFi, Bluetooth aj. 5. změna hlasitosti 6. úpravy kontaktů 7. datový limit pro použití mobilního internetu U technologií jako je GPS je vhodné aplikovat i detailnější nastavení než jen „povolit“ a „zakázat“. Příkladem může být např. sledování pohybu dětí přes mobil. Rodič chce, aby GPS byla zapnutá, ale aby s ní dítě nemohlo zacházet a vypnout ji. V takovou chvíli se hodí, když jsou restrikce pro rodičovský mód voleny širšeji, a tak lze např. GPS nechat zapnutou, zakázat editaci jejího nastavení a povolit seznam aplikací, kterým má být poloha zařízení zpřístupněna. Další možností, jak zlepšit možnosti rodičovského módu na mobilním zařízení, by mohlo být použití telefonování a psaní zpráv pouze na povolené kontakty s možností nastavení denních limitů pro délku komunikace (např. počet sms zpráv). 11

2.2

Filtrování obsahu webových stránek

Filtrováním se rozumí zákaz celého nebo části obsahu, ke kterému se uživatel snaží dostat. Může se jednat např. o zakázání přístupu na sociální sítě nebo zákaz nezletilým prohlížet obsah pro dospělé. Blokování se dá navrhnout několika způsoby a také se dá v síti postavit na různá místa – nemusí být jen lokálně na PC. Každé řešení má svá pro i proti. Pro nadcházející text je potřeba znát pojem proxy server. Proxy server by se dal označit jako prostředník mezí komunikujícími stranami. Může se jednat buď o fyzické zařízení, nebo aplikaci, která přijímá požadavky od klienta, posílá je na cílové zařízení a data poté přeposílá zpět. Proxy server může požadavky a data jen předávat nebo je může upravovat, což je vlastnost, která se používá při filtrování webových stránek. Proxy slouží i pro jiné účely jako je např. load balancing (rozdělení zátěže mezi více serverů) nebo cache webových stránek. 2.2.1

Umístění filtru

Prvním řešením je použití filtru přímo lokálně v počítači. Lze ho implementovat jako rozšíření do webového prohlížeče, jako aplikaci samotného webového prohlížeče, nebo jako lokální proxy server, který filtruje veškerý odchozí a příchozí provoz z resp. do počítače. Výhodou lokálního řešení je rychlá instalace a možnost definice parametrů dle uživatelů daného zařízení, ale v případě, že je v síti více počítačů, je toto řešení neefektivní a pro budoucí správu nevhodné. Pokud se pro filtrování použije doplněk do webového prohlížeče, tak se uživatel stále může dostat na web přes jiný prohlížeč, aniž by byl provoz filtrován. Druhým řešením je použití filtru na serveru, přes který proudí komunikace z lokální sítě. Výhodou je, že zařízení zapojené do sítě je automaticky zapojeno do filtrování a že správa jednotlivých profilů se dělá pouze na jednom místě. Nevýhodou je, že se nedá na síťové (případně transportní) vrstvě odlišit, který uživatel z daného počítače právě komunikuje se serverem, protože na těchto vrstvách se řeší pouze IP adresa počítače, nikoliv který uživatel je do počítače aktuálně přihlášen. Tento typ filtrování používají často poskytovatelé internetu. Třetím řešením je kombinace výše dvou zmíněných způsobů. Výsledkem pak je, že proxy server ví, kdo přesně s ním komunikuje, a může pak filtrovat obsah pro daného uživatele, i když se v síti hlásí např. na více zařízení. Většina takových programů je realizována podobně jako útok typu MITM (Man In The Middle). 2.2.2

Útok typu Man In The Middle

Informace k této sekci byly čerpány z [2]. Typ útoku MITM je jeden ze známých problémů v informatice a kryptografii obecně. Jednoduše by se dalo říci, že mezi dva komunikující uzly se dostane další, který jejich komunikaci monitoruje, případně pozměňuje (analogie s filtry webového obsahu). Uvedu příklad: zařízení A (Alice) chce komunikovat se zařízením B (Bob). Pokud se na jejich 12

Obrázek 1: Útok typu MITM přes HTTP komunikační kanál dostane zařízení C (Cecil), pak může odposlouchávat jejich komunikaci, viz Obrázek 1. Obranou proti útoku je např. použití šifrování – zabezpečené komunikace, ale i zde je určité řešení pro útočníka. Místo běžného odposlouchávání komunikace se Cecil vloží mezi Boba a Alici, aby data nejen odposlouchával, ale i modifikoval. Pro Boba se tváří jako Alice, pro Alici jako Bob. Alice i Bob žijí v domnění, že komunikují jeden s druhým, ale jejich komunikace je monitorována a měněna (kvůli podvrženým bezpečnostním klíčům) Cecilem. Postup zahájení komunikace lze vyčíst z Obrázku 2. Dalším stupněm ochrany je použití veřejných šifrovacích klíčů elektronicky podepsaných certifikátem, který je vytvořený u certifikační autority (dále CA). I tento způsob se dá obejít tím, že si útočník vytvoří vlastní CA a v tu chvíli, kdy jí komunikující strany věří – berou v platnost klíč podepsaný touto CA, tak útočník opět může číst a měnit probíhající komunikaci mezi uzly, protože do certifikátů vystaví takové klíče, aby sám mohl komunikaci dešifrovat. I proti tomuto útoku se dá bránit a to tak, že nevěříme neověřeným CA. Existuje hierarchie CA, a tak můžeme ověřovat certifikát samotné CA u vyšších CA. Některé CA mají tzv. self-signed certifikát (podepsaný sami sebou) a pak je na nás, zda takové certifikační autoritě věříme nebo ne. Důvodem, proč zde uvádím útok MITM je, že chceme-li filtrovat i provoz, který je běžně šifrovaný, musíme ve filtru použít obdobný postup jako výše zmíněný. 2.2.3

Samotné filtrování

Budeme–li uvažovat, že pro filtr webových stránek se použije proxy server, tak samotná komunikace bude probíhat následovně: 1. uživatel zadá URL adresu 2. proběhne komunikace s proxy 3. proběhne komunikace proxy do internetu 13

Obrázek 2: Útok typu MITM přes HTTPS 4. proxy přijme data 5. proxy pošle data klientovi K filtrování na proxy může docházet jak směrem od uživatele (mezi body 2 a 3), tak směrem k uživateli (mezi body 4 a 5). Proxy server může být umístěn lokálně v PC, na bráně do internetu, nebo může ležet i mimo lokální síť. Filtrace směrem od uživatele se zakládá většinou na analýzách, kde se používá technika white listu (dále WL) a black listu (dále BL), což je seznam povolených resp. zakázaných URL adres. Filtrace směrem k uživateli se zakládá již na sofistikovanějších řešeních, kdy dochází ke kontrole příchozích HTTP hlaviček a procházení obsahu samotné webové stránky. Základní možností je použití zakázaných slov, kdy se stránka zamítá v případě, že je v ní obsažené nevhodné slovo ze seznamu předdefinovaných výrazů. Slova lze buď porovnávat 1:1 na shodu, ale efektivnější je použití převodu zdrojového textu a seznam slov na malá písmena a použití metody tzv. wildcard zápisů slov. Je pak možné použít např. výraz porno*, čímž zabráníme i výskytu slov jako pornografický, pornografie aj. Další alternativou je použití klasifikačních algoritmů, které na základě obsahu hledají podobnosti ve vzorovém corpusu (trénovací množina dokumentů) a v případě kategorizace do nepřístupné kategorie je stránka zamítnuta. Klasifikačním algoritmům se blíže věnuje Kapitola 6.3. Obsah webové stránky můžeme označit za nevhodný i bez hlubších kontrol a to v případě, že se stránka sama ohodnotí pomocí zavedených standardů pro hodnocení obsahu. 2.2.4

Standardy pro hodnocení webových stránek

Webové stránky lze označit hodnocením, aby je webové prohlížeče, případně webové filtry, mohly lépe identifikovat, a tak se rozhodnout, zda je stránka pro uživatele vhodná nebo nikoliv. Pro toto hodnocení se používají tzv. META informace, které se umisťují do hlavičky HTML dokumentu, tedy dovnitř tagu . 14

Níže jsou popsány systémy hodnocení a na konci podkapitoly je i vysvětlení, proč jakékoliv snažení zavedení standardu pro hodnocení skončilo neúspěchem – ve smyslu, že se nezačalo používat ve velkém. PICS a POWDER Informace k této sekci byly čerpány z [3]. PICS neboli Platform for Internet Content Selection by se dalo volně přeložit jako platforma pro výběr (ohodnocení) obsahu. Toto hodnocení vzniklo v roce 1995 na základě požadavků pro zavedení prvního standardu, aby bylo možné lehce filtrovat obsah na webu. V roce 2007 se tento systém hodnocení přestal udržovat a přešel pod nový systém jménem POWDER – Protocol for Web Description Resources. U systému POWDER vývojáři vydrželi následující tři roky a v roce 2010 se přestalo vyvíjet i na tomto systému. Tím, že se přestalo vyvíjet, je myšleno popisování obsahu a kontrola dodržování hodnocení. Níže ve Zdrojovém kódu 1 a 2 jsou dva způsoby, jak lze webovou stránku označit pomocí PICS. <meta http-equiv="PICS-Label" content=’(PICS-1.1 "http://www.classify.org/safesurf/" l r (SS ~~000 1))’ />

Zdrojový kód 1: PICS - použití metatagu

(PICS-1.1 "http://www.classify.org/safesurf/" 1 r (SS~~000 1))

Zdrojový kód 2: PICS - použití tagu rating Jak lze vyčíst ze zdrojového kódu, tak důležitá část samotného hodnocení je řetězec "SS~~000 1". První část řetězce "SS~~"je ochranná certifikační známka, za níž následuje řetězec tří znaků, povinná mezera a jedna číslice. Z tříznakového řetězce je důležitý pouze poslední znak, první dva byly jen uvažovány do budoucna kvůli rozšíření systému, a tak je jejich výchozí stav 00. Číslicí 1–9 a případně písmenem A lze označit kategorii obsahu, který se na stránce nachází. K obsahu lze navíc nastavit, v jaké formě se tam nachází. K tomu slouží poslední číslice v hodnocení a opět nabývá hodnot 1–9. Kategorie, které se dají popsat, jsou např. pornografie, násilí, drogy, hazard aj. Přesný výpis kategorií lze nalézt na http://www.classify.org/safesurf/. Díky tomu, že by se mělo v hodnotícím tagu objevit vše, co se na aktuální stránce nachází, tak může dojít k tomu, že se musí použít více kategorií hodnocení. Syntaxe zápisu je uvedena ve Zdrojovém kódu 3. 15

<meta http-equiv="PICS-Label" content=’(PICS 1.1 "http://www.classify.org/safesurf/" l r (SS ~~000 4 SS~~001 5 SS~~004 2 SS~~007 2 SS~~008 3))’ />

Zdrojový kód 3: PICS - popis více kategorií obsahu

POWDER k hodnocení stránek, resp. popisu jejich obsahu, přistupuje jinak. Pro popis obsahu se vytváří XML, ve kterém je dle specifikace vypsáno, co přesně se na webu nachází. Uvádět příklady zde nebudu, protože popis obsahu je celkem robustní, ale více lze přečíst v dokumentaci k hodnocení na http://www.w3.org/TR/powder-dr/. Meta tag RATING Informace k této sekci byly čerpány z [4]. Druhý systém hodnocení je použití meta tagu rating. <meta name="rating" content="val">

Zdrojový kód 4: Meta tag rating Místo hodnoty val ve Zdrojovém kódu 4 lze zapsat do obsahu tagu jakýkoliv řetězec, ale nejpoužívanější jsou „general“, „mature“, „restricted“, „14 years“ a „safe for kids“. Spolu s meta tagem rating je používáno i hodnocení RTA – Restricted To Adults, volně přeloženo jako „Omezeno pro dospělé“. Je-li stránka hodnocena systémem RTA, pak je obsahem položky content textový řetězec, který má prefix i postfix RTA. Čísla uvnitř řetězce v současné době neslouží k bližšímu popisu obsahu. <meta name="RATING" content="RTA-5042-1996-1400-1577-RTA" />

Zdrojový kód 5: Meta tag rating s využitím RTA V případě použití RTA má vlastník webu dvě možnosti jak hodnocení implementovat. Buď využije meta tag rating, jak je popsáno v kódu 5, nebo použije hodnocení pomocí HTTP hlavičky. To lze buď implementovat do jednotlivých skriptů aplikace, nebo lze použít i jako globální nastavení pro celý webový server. Při používání HTTP serveru APACHE toho lze dosáhnout pomocí editace httpd.conf a přidáním kódu 6.

16

Header set Rating "RTA-5042-1996-1400-1577-RTA"

Zdrojový kód 6: Nastavení RTA ratingu pro celý APACHE server

Používání metod pro hodnocení v roce 2015 Když jsem přišel na to, že existují standardy pro hodnocení webových stránek, tak jsem věřil, že vytvoření filtru pro webové stránky bude snadná záležitost. Program pro kontrolu příznaků v HTML hlavičce by byl napsaný za chvíli, ale nejdřív jsem pro jistotu ověřil, jak moc se tato hodnocení skutečně používají v reálném prostředí. Výsledky lze vyčíst z Tabulky 1. Množina Zkoumané stránky Hodnocení PICS Hodnocení meta tagem rating (celkem) Hodnocení meta tagem rating s RTA Hodnocení HTTP hlavičkou RTA

Počet 86 650 213 2 425 1 751 97

Tabulka 1: Statistiky používání hodnocení obsahu na velkém vzorku webových stránek s pornografickým obsahem Jako vývojář webového filtru bych nečekal, že se tyto standardy budou používat v tak malé míře. Problémem je, že jsem přemýšlel nad použitím ratingů jako vývojář webového filtru, ne jako vlastník webových stránek, jehož cílem je co největší návštěvnost a jakékoliv použití ratingu by návštěvnost jistě snížilo. Standardy pro hodnocení není nařízené používat, je to pouze doporučené, a tak je na vlastnících webu, zda tak učiní či nikoliv. V Tabulce 2 lze pro porovnání vidět statistiky pro 150 nejnavštěvovanějších stránek s pornografickým obsahem. Je dobrým zjištěním, že oblíbené stránky s touto tématikou jsou hodnoceny ve větší míře než stránky se stejnou tématikou obecně. Množina Zkoumané stránky Hodnocení PICS Hodnocení meta tagem rating (celkem) Hodnocení meta tagem rating s RTA Hodnocení HTTP hlavičkou RTA

Počet 150 8 75 64 12

Tabulka 2: Statistiky používání hodnocení obsahu na nejnavštěvovanějších webech v kategorii pornografie dle žebříčku [5]

17

Pokud bychom postavili filtr jen na základě použití standardů pro hodnocení, tak bychom se dostali na úspěšnost cca 2.8 %, což skutečně není vhodné řešení. 2.2.5

Úprava výsledků vyhledávačů

Pokud uživatel zná přesnou URL, tak je nutné analyzovat její obsah, abychom se rozhodli, zda je vhodná pro zobrazení či nikoliv. Pokud ale uživatel URL nezná, tak k vyhledání obsahu použije jeden z vyhledávačů. Zde je další prostor pro optimalizaci, protože největší vyhledávače nabízejí něco, čemu se říká „bezpečné vyhledávání“. Pokud tuto možnost zapneme, tak vyhledávač aplikuje svoje algoritmy pro zobrazení nalezených výsledků. Některé vyhledávače mají ještě detailnější nastavení tohoto režimu – zda ho aplikovat na text, obrázky nebo i video. Použitím tohoto režimu dost pomůžeme filtrům webových stránek, protože uživatel se nedostane ani k URL s nevhodným obsahem, pokud ji nezná, aby tak na ni mohl pokračovat. Některé vyhledávače změnu nastavení „bezpečného vyhledávání“ vkládají do URL, takže s ním dále pracují metodou GET. Většinou se ale používá ukládání do session, když se v nastavení vyhledávače odešle formulář pomocí metody POST. Dá se tedy říct, že vhodnou úpravou GET a POST požadavků lze docílit toho, že uživatel bude vždy nucen používat „bezpečné vyhledávání“, i když se bude snažit změnit nastavení tohoto režimu. Vezmeme-li v potaz žebříček nejnavštěvovanějších webových vyhledávačů [6] a prvních pět zástupců, tak všichni mají implementované použití „bezpečného vyhledávání“. Jedná se o vyhledávače Google, Yahoo!, Bing, Ask a Aol. Metodu GET v současné době používá už jen vyhledávač Ask, kde použitím parametru adt=0 v URL docílíme toho, že se nevhodné výsledky budou filtrovat. Ještě do nedávna (prosinec 2014) metodu GET používal i vyhledávač Google pomocí safe=strict, ale nyní už tento parametr nefunguje. Google podporu „bezpečného vyhledávání“ implementoval i do podobných portálů, které provozuje, jako je např. videoserver youtube.com. Dalším řešením je zakázat normálně dostupné vyhledávače a povolit jen vyhledávače, které jsou určené přímo pro děti jako jsou např. tyto: 1. www.safesearchkids.com – při zadání nevhodného slova se vyhledávač tváří, že dané slovo neexistuje 2. www.kidrex.org – stejná funkcionalita jako předchozí 3. www.kidzsearch.com – při zadání nevhodného slova vyhledávač upozorní uživatele, že se pokouší dostat k obsahu, ke kterému nemá přístup Jistě se nabízí otázka, proč jsem neuvedl žádný z českých vyhledávačů jako je seznam.cz, atlas.cz nebo centrum.cz, důvod je ale zřejmý. Žádný z těchto vyhledávačů nedisponuje možností „bezpečného vyhledávání“.

18

2.2.6

Blokování přespříliš vs. málo

Problémem při filtrování webových stránek je nalezení míry mezi tzv. overblockingem (blokování přespříliš) a underblockingem (blokování málo). Nastavíme-li algoritmus příliš přísně, bude blokovat i stránky, které neobsahují potencionálně nechtěný obsah, pokud ho ale nastavíme mírně, dochází k neblokování stránek, které nevhodný obsah mají. Pro toto měření slouží metrika "over vs. underblocking". Vyberou se stránky s potencionálně nevhodným obsahem, které však nemají být blokovány a stránky s potencionálně vhodným obsahem, které blokovány být mají. Čím menší je počet chyb v blokování, tím je algoritmus přesnější. Přesné metriky a způsoby hodnocení lze nalézt v Kapitole 6.3.3.

19

3

Možnosti rodičovské kontroly dle platforem

Pro tuto kapitolu jsem zvolil v současné době 5 nejvíce používaných operačních systému: jsou jimi Windows, Linux, Mac OS, iOS a Android. K tomuto výběru jsem dospěl na základě statistik přístupu na web ze zařízení viz. Tabulka 3. Zejména v posledních letech začala stoupat oblíbenost iOSu a Androidu. Jedná se o operační systémy určené hlavně pro mobilní zařízení jako jsou chytré telefony a tablety. Do této kategorie patří i další operační systémy jako BlackBerry OS, Symbian OS, Ubuntu Phone nebo Windows Phone, ale ty nejsou tak populární jako hlavní dva zástupci.

2012 2013 2014 2015

Win 8 2.1 % 8,2 % 17,1 % 21,5 %

Win 7 52,9 % 56,1 % 54,9 % 52,5 %

Win XP 25,8 % 15,3 % 7,3 % 4,6 %

Linux 4,9 % 4,8 % 5,3 % 5,4 %

Mac OS 8,9 % 9,3 % 9,8 % 10,0 %

iOS 0,6 % 1,1 % 1,2 % 1,2 %

Android 0,2 % 1,3 % 2,3 % 3,0 %

Tabulka 3: Statistiky použití operačních systémů, zdroj dat [7]

3.1

Windows

Systém Windows disponuje vestavěnou rodičovskou kontrolou již od verze Windows XP. Tento program umožňuje nastavovat restrikce pro jednotlivé uživatele počítače. Průzkum funkcionality byl proveden na osobním počítači se systémem Windows 8. Rodičovská kontrola se nastavuje ve správci účtů, které se v systému Windows 8 už netýkají pouze lokálního vytvoření v počítači, ale účty jsou vázané na registraci přímo u společnosti Microsoft online a je vyžadována emailová adresa. Po registraci více účtů je potřeba vybrat z uživatelů „správce“ rodiny, který bude mít administrátorská práva k nastavení omezení pro účty, které mají nastavený typ účtu „dítě“. Díky online registraci je toto nastavení možné ovládat vzdáleně, což se hodí v případě, že administrátor nastavil některý z filtrů příliš přísně a dítě u počítače se tak nemůže dostat k datům, ke kterým potřebuje mít přístup a potřebuje ho ihned. Online řešení je také výborná věc kvůli statistikám, protože rodič se může kdykoliv podívat, kde se jeho dítě na webu pohybuje, kam chodí nejčastěji, na které stránky se snažilo dostat a byly mu zablokovány aj. Sběr informací se dá vypnout pro jednotlivé účty, ale ve výchozím nastavení je zapnutý. Filtrování webu U filtrování webových stránek lze nastavit BL a WL. Dále je možné zapnout funkci automatického filtrování obsahu webu dle následujících kategorií:

20

Pouze seznam povolených položek Uživatel může prohlížet weby, které jsou v seznamu povolených webů. Weby pro dospělé jsou blokovány. Určené pro děti Uživatel může prohlížet weby, které jsou v seznamu povolených webů, a weby určené pro děti. Weby pro dospělé jsou blokovány. Všeobecně prospěšné Uživatel může prohlížet weby, které jsou v seznamu povolených webů, weby určené pro děti a weby v kategorii Všeobecně prospěšné. Weby pro dospělé jsou blokovány. Online komunikace Uživatel může prohlížet weby, které jsou v seznamu povolených webů, weby určené pro děti, weby v kategorii Všeobecně prospěšné, Sociální sítě, Webový chat a Webový e-mail. Weby pro dospělé jsou blokovány. Upozornit na weby pro dospělé Uživatel může prohlížet všechny weby, ale bude upozorněn, pokud je podezření, že web obsahuje obsah pro dospělé. Je-li zvolena kterákoliv z předchozích možností (až na poslední), tak se automaticky zapíná i funkce bezpečného hledání. V nastavení systému se píše, že funkcionalita je pro Bing, Google, Yahoo a jiné oblíbené vyhledávací weby, nicméně kompletní seznam Microsoft nikde neuvádí. Také chybí bližší definice kategorií a třeba pod názvem „Všeobecně prospěšné weby“ si lze těžko představit konkrétní množinu stránek, které by do této kategorie mohly spadat. Poslední možností v tomto nastavení je zakázání stahování souborů z webu. Samotné hodnocení webových stránek funguje tak, že se využívá vzdálený proxy server společnosti Microsoft, přes který proudí veškeré požadavky. Pokud požadovaná stránka již byla Microsoftem někdy hodnocena, pak se výsledek hodnocení dohledá. Pokud proxy server navštěvuje stránku poprvé, tak jí nejdříve analyzuje, což v některých případech trvá i 10 sekund než se obsah požadované stránky dostane zpět k uživateli. Stránky, které fungují na protokolu HTTPS, nejsou kontrolovány na obsah. Proxy u takových stránek pouze porovnává, zda není na jejich BL, což je v tomto případě i seznam stránek, které nahlásili uživatelé jako závadné.1 Časový přístup Časový přístup do zařízení lze omezit dvěma způsoby. První z nich nabízí administrátorovi týdenní kalendář, kde může pro jednotlivé dny definovat přístup 1

Např. web seznam.cz je blokován kvůli „pornografii“. Požádal jsem helpdesk o uvolnění z BL, protože v jejich online nástroji pro to je formulář popříp. o zdůvodnění hodnocení, ale ani po měsíci se mi nedostalo žádné reakce.

21

uživatele v půlhodinových intervalech, viz Obrázek 3. Grafické okno pro ovládání je intuitivní, ale možnost zadávat pouze půlhodinové intervaly mi nepřijde vhodná. Na druhou stranu lze díky tomuto ovládání nastavit několik intervalů použití PC během jednoho dne, což je šikovné řešení. Druhým způsobem je nastavení přístupu podle času stráveného u zařízení. Ve zjednodušeném režimu lze nastavit obecně čas pro všední dny a víkend, nebo lze přepnout do rozšířeného režimu a nastavit jednotlivé dny v týdnu. Zapsat čas jde pomocí dvou rozbalovacích menu – hodiny a minuty. Vývojáři do nabídky s minutami umístili pouze možnosti 0, 15, 30, a 45. Lepším řešením by bylo nechat uživatele zvolit jakýkoliv počet minut. V systému Windows 7 bylo možné nastavit pouze přístup dle denní doby, ale čas strávený u zařízení nikoliv. Uživatel je o času vypršení notifikován v případě, že se přihlásí do systému a zbývá mu méně jak 15 minut, následná notifikace je 2 minuty před samotným odhlášením. Pokud se uživatel přihlásí v nepovolenou hodinu, tak mu je sděleno, kdy se může přihlásit znovu, případně mu je nabídnuta alternativa prodloužení sezení u zařízení v případě, že je k dispozici u zařízení i správce rodiny. Ten v dialogu zadá své heslo, a následně nastaví čas navíc. V rozbalovacím menu jsou opět pouze omezené možnosti a to 15 minut, 30 minut, 1 hodina, 2 hodiny, 4 hodiny a 8 hodin. Notifikace o zbývajícím času nejsou nastavitelné v administrátorské části.

Obrázek 3: GUI pro nastavení přístupu k PC ve Windows 8

22

Omezení her a aplikací z Windows Store Od verze Windows 8 společnost Microsoft spustila svůj vlastní online obchod s aplikacemi, kde od vývojářů požaduje ratingy aplikací, aby tak pro systém Windows bylo jednodušší aplikace identifikovat. Toto hodnocení se děje dle stupnice Pegi. Ta obsahuje celkem pět kategorií, a to PEGI 3, PEGI 7, PEGI 12, PEGI 16 a PEGI 18. Číslo označuje orientační věk, na základě kterého by se administrátor měl rozhodnout, kterou kategorii zvolí. Tento rating je v Evropě asi nejpoužívanější a kromě her se používá i ve filmovém průmyslu, takže podobné nálepky jako na Obrázku 4 lze vidět i na obalech s filmy. Pegi kromě kategorií dle věku používá ještě druhou metriku, a tou je popis obsahu. Používají se pro to kategorie Diskriminace, Drogy, Hazardní hry, Násilí, Online, Sexuální obsah, Strach a Vulgární jazyk. Ve verzi Windows 7 bylo možné filtrovat hry i podle této metriky, ale do Windows 8 se tato funkcionalita nedostala. Díky ní šlo např. zakázat veškeré hry, které se hrály Online nebo i přesto, že uživatel měl přístup k hrám 18+, tak nemohl hrát ty, ve kterých byl použit vulgární jazyk. Další z věcí, kterou ve Windows 8 vypustili, na rozdíl od předchozí verze, je globální zákaz her a globální zákaz her bez hodnocení. Mohly se tak vypnout veškeré hry, takže při instalaci nebylo nutné vždy upravovat rodičovskou kontrolu nebo šlo přenechat starání se o kontrolu hodnocení her samotnému systému, kdy nehodnocené hry šlo jednorázově vypnout.

Obrázek 4: Hodnocení PEGI, zdroj [8]

Omezení aplikací Systém Windows nalezne všechny spouštěcí soubory typu EXE a jejich seznam nabídne uživateli. V případě, že by požadovaná aplikace nebyla v seznamu, tak ji lze ručně dohledat přes dialogové okno na disku. Aplikace mezi sebou nemají závislosti, což v případě některých může vést k problému. Příkladem může být prohlížeč Google Chrome, kde povolení k použití hlavní aplikace k běhu samotné aplikace nestačí. Závisle aplikace lze dohledávat pouze tak, že se administrátor přihlásí na omezený účet, aplikaci spustí a v případě, že si aplikace k sobě 23

volá další programy, tak administrátor pro každý takový proces jednotlivě vystaví výjimku. Pro běh samotné aplikace Google Chrome je třeba povolit ještě spouštěcí soubory delegate_execute.exe a na64.exe (umístěné ve stejné složce jako je hlavní spouštěcí soubor aplikace). Statistiky Statistiky lze buď prohlížet online na webu https://familysafety.microsoft.com, nebo v ovládacích panelech v rodičovské kontrole pod každým jednotlivým účtem, kde je ovšem statistik méně. Lokálně lze sledovat nejnavštěvovanější weby, poslední blokované weby, čas strávený na počítači podle data, nejpoužívanější aplikace a hry. Na webu lze dále nalézt i seznam souborů, které uživatel stahoval, nebo co konkrétně stahoval z obchodu Windows Store. Shrnutí a nalezené nedostatky Poslední verze rodičovské kontroly, která se objevila ve verzi Windows 8, se tváří dostatečně robustně. Je možné filtrovat obsah webových stránek, ale nedají se přesně definovat kategorie obsahu, které by měly být filtrovány. Správce počítače tak neví, zda bude filtrována pouze pornografie, nebo i webový obsah týkající se zbraní, násilí aj. I v případě povolení kategorie webů „Všeobecně prospěšné“ jsou stránky zabývající se tématikou zbraní a násilí dostupné. Na testovací množině stránek bylo dále zjištěno, že weby ohodnocené pomocí RTA a PICS standardů jsou blokovány správně. Jak již bylo zmíněno v Kapitole 2.2.5, Google změnil svojí politiku používání „bezpečného vyhledávání“. Microsoft na to zatím nereagoval, takže bezpečné hledání na Googlu již nefunguje, jak by mělo při zapnuté rodičovské kontrole, a tak má uživatel umožněn přístup k nevhodnému obsahu. Problémem je, že se v nastavení vyhledávače dá odeslat formulář na vypnutí „bezpečného vyhledávání“ a tento požadavek není nijak upravován před odesláním, takže se nastavení projeví. Vyhledávač Ask je také podporován rodičovskou kontrolou, avšak vyhledávač Aol nikoliv. Zákaz stahování souborů respektuje pouze aplikace Internet Explorer, takže pokud administrátor chce toto nastavení používat, je nucen z webových prohlížečů zapnout uživateli jen Internet Explorer. V nastavení rodičovské kontroly není zmíněno, že toto nastavení funguje pouze v aplikaci Internet Explorer. Zajímavým zjištěním je, že systém Windows nepočítá čas strávený v „systému“ v případě, že je operační systém pouze uzamčen (klávesová zkratka Fn+L). Jelikož systém při uzamčené obrazovce nevypíná výstup ze zvukové karty, tak není problém pro uživatele tímto způsobem poslouchat hudbu i v případě, že by tak dlouho neměl mít vůbec do systému přístup. Obdobným způsobem lze realizovat stahování souborů, použití sdílených zařízení počítače aj. Online na webu je možné provést i nastavení, která lokálně v systému nejsou vůbec dostupná. Jedná se např. o detailní nastavení hodnocení her – ve webové 24

aplikaci je na výběr z celkem 12 žebříčků. Nastavení zákazu her bez hodnocení je dostupné také pouze online. Pozitiva: + nastavení časových limitů + online nástroj pro vzdálenou správu + mailové notifikace o aktivitě a požadavcích uživatele Negativa: - absence profilů a jejich přiřazování uživatelům - absence detailnějšího filtrování webových stránek - bezpečné hledání nefunguje na Googlu - poskytování veškerých statistik počítače (instalované programy, navštívené weby aj.) společnosti Microsoft - některá nastavení dostupná pouze online

3.2

Mac OS

Testování proběhlo na Mac OS 10.10 – Yosemite. Systém Mac OS také disponuje vestavěnou rodičovskou kontrolou, která umožňuje nastavovat restrikce pro jednotlivé uživatele jak lokálního počítače, tak jiného počítače se systémem Mac OS v lokální síti. Obdobně jako ve Windows se zapíná ve správci účtů. Ani zde není možnost vytváření omezených profilů, které by se následně přidělovaly uživatelům. Je zde alespoň možnost kopírování nastavení jednoho uživatele a jeho následné vložení k jinému uživateli, takže přidáme-li do zařízení nový uživatelský účet, tak je jeho nastavení jednodušší, pokud lze aplikovat restrikce z jiného účtu. Následná správa je ale stejně složitá jako ve Windows. Nastavení je taktéž členěno do několika kategorií. Omezení aplikací Pod touto záložkou nalezneme restrikce jednotlivých aplikací. Na aplikace z App Storu (obchod s aplikacemi provozovaný firmou Apple Inc) lze použít restrikce s věkovým omezením, případně zakázání všech aplikací z App Storu. Dále lze zakázat úpravy v Docku (spodní lišta s aplikacemi na ploše) a zapnout jednoduchý „Finder“, který se snaží upravit zacházení s plochou tak, aby bylo intuitivnější pro děti a uživatele nezkušené s tímto systémem.

25

Filtrování webu Filtrování webu lze zapnout na základě funkce „Automaticky omezit přístup k webovým stránkám pro dospělé“. Tato funkce se dá následně upravit pouze vytvořením BL a WL s tím, že stránky běžící na protokolu HTTPS, které nejsou uvedeny na WL, jsou automaticky blokovány. Se zapnutím jakékoliv filtrace webu se automaticky zapíná i aktivace bezpečného vyhledávání ve vyhledávačích. Přesný výčet podporovaných vyhledávačů opět není nikde uveden. V případě, že jako webový prohlížeč je používáno Safari, tak se WL objeví v prohlížeči jako seznam záložek. V případě vložení URL do WL se nebere v potaz její přesná cesta ale doména, takže pokud uživateli povolíme example.com/movies, povolujeme tím i automaticky stránky pod stejnou doménou včetně poddomén. Stránka example.com/music tak bude fungovat a stejně tak i static.example.com. Výhodou je použití výrobcem předdefinovaného WL pro děti, který je lokalizovaný pro aktuálně zvolenou zemi v systému – jsou zde weby pro děti a dětské vyhledávače. Lidé Tato záložka slouží pro restrikce v komunikaci uživatele s dalšími uživateli online. Lze tak nastavit zákaz pro hraní multiplayerových her přes aplikaci Game Center a přidávání kamarádů tamtéž. Další možností je omezení komunikace přes email (vestavěný klient v systému) a iChat (aplikace pro chatování, taktéž vestavěná v systému). Obě omezení lze nastavit pouze formou WL – seznam emailových adres, se kterými je možné komunikovat. Bohužel opačné nastavení chybí, a tak pokud je potřeba zakázat komunikaci jen s jedním uživatelem, je toto nastavení pracné a nové kontakty nemají šanci komunikovat bez zásahu administrátora. Pro případ použití nových kontaktů je zde schvalovací proces, kde lze v administraci zadat emailovou adresu, na kterou mají chodit žádosti o svolení ke komunikaci. Časový přístup Nastavení se zakládá na všedních dnech a víkendu. Nelze definovat čas strávený u počítače přesně podle dní v týdnu. Nastavit lze interval 30 minut až 8 hodin – s krokovým nastavením 30 minut. K omezení času, kdy uživatel může k zařízení přistupovat, je zde použita tzv. večerka, kdy lze definovat hodiny intervalem, opět pro všední dny a víkend, kdy se uživatel nemůže přihlásit. Notifikace o vypršení času také nejsou nastavitelné, stejně jako ve Windows. Uživatel je notifikován o času vypršení 5 minut před uplynutím limitu a následně při vypršení limitu. V obou dialozích je možné s heslem administrátora prodloužit přístup – lze vybírat z nastavení 15 minut, 30 minut, 1 hodina, 2 hodiny, 4 hodiny a zbytek dne.

26

Obrázek 5: GUI pro časové nastavení přístupu k PC v Mac OS 10.10 Jiné V poslední záložce lze nastavit několik dalších možností: Vypnout vestavěnou kameru Zabrání uživateli v přístupu k vestavěným kamerám a kamerám v připojených monitorech. Vypnout diktování Zabrání uživateli v zapnutí funkce Diktování na panelu předvoleb Diktování a řeč. Skrýt vulgární výrazy ve slovníku Omezí přístup k nevhodnému obsahu ve zdrojích, jako jsou slovníky, tezaury a Wikipedie. Omezit správu tiskáren Zabrání uživateli ve změnách nastavení a také v přidávání a odstraňování tiskáren. Zakázat změnu hesla Zabrání uživateli ve změnách hesla na panelu předvoleb Uživatelé a skupiny. Omezit vypalování CD a DVD Zabrání uživateli ve vypalování CD a DVD v aplikaci Finder.

27

Statistiky Statistiky uživatele lze sledovat pouze lokálně, nikoliv přes webovou aplikaci. Uchovávají se pro navštívené a zablokované weby, používané aplikace a iChat. Lze je filtrovat dle nastavení kalendáře za poslední den, týden, měsíc, 3 měsíce, 6 měsíců, rok a za celé období. Podle konkrétního data se bohužel filtrovat nedá. Shrnutí a nalezené nedostatky Systém Mac OS také nabízí rozsáhlé řešení pro vytvoření rodičovského módu. Vhodné je použití kopírování nastavení jednoho uživatele pro jiného. Lepším řešením by však bylo doimplementovat správu profilů a umožnit administrátorovi vytvářet profily a ty následně přiřazovat uživatelům. Pokud se používají interní aplikace pro mailovou komunikaci a chat, tak je možné omezovat seznam kontaktů, s nimiž je možné komunikovat. Časové omezení přístupu k zařízení je dosti limitující, protože není možné nastavit jednotlivé dny v týdnu, ale pouze všední dny a víkend. Tím, že lze nastavit pro každou kategorii pouze jeden interval, tak lze toto omezení skutečně používat jen pro funkci „večerky“. V omezení webových stránek chybí veškeré bližší nastavení, jako je možnost upřesnění nevhodného obsahu, věkové omezení aj. Pokud uživatel přistoupí na stránku, která je kontrolou vyhodnocena jako nevhodná, není možnost URL přidat do seznamu adres, které jsou potencionálně blokovány neprávem, který by pak administrátor mohl kontrolovat a povolit/zamítnout. Jediná možnost pro dotyčného je tedy dostat administrátora k počítači, aby adresu povolil a tím ji přidal do WL. Bezpečné vyhledávání funguje na všech pěti vyhledávačích zmíněných v Kapitole 2.2.5 korektně a jsou podchyceny všechny způsoby pro vypnutí tohoto režimu. Na testovací množině stránek bylo dále zjištěno, že weby ohodnocené pomocí RTA a PICS standardů jsou blokovány správně. Funkce pro omezení přístupu k nevhodnému obsahu ve zdrojích jako jsou slovníky, tezaury a Wikipedie funguje jen pro výrazy v anglickém jazyce. Dále nefunguje přidání do WL správcem systému, které se provede pomocí dialogového okna vyvolaného z prohlížeče při blokaci URL adresy. Dle helpdesku Applu je toto jen momentální problém ve verzi systému 10.10.3 a měl by být vyřešen pomocí nadcházející aktualizace. V předchozí verzi systému 10.9 toto nastavení bylo funkční. Podobný problém je ve verzi 10.10.3 i se statistikami jednotlivých uživatelů, kde se nezaznamenává veškerá jejich aktivita, ale jen část. Instalace aplikací se obecně zakázat nedá, ale i když si uživatel aplikaci přenese „nakopírováním“ odněkud, tak ji stejně nespustí, pokud jsou zapnuté restrikce aplikací. Mac OS se totiž dívá na seznam aplikací, které uživatel může spustit a není-li na tomto seznamu, tak spuštění přeruší. Pozitiva: + kopírování uživatelských profilů 28

+ restrikce tiskáren + funkční mód pro „bezpečné vyhledávání“ v pěti nejnavštěvovanějších vyhledávačích Negativa: - nedostatečné možnosti časových restrikcí přístupu k zařízení - skrývání vulgárních výrazů na webu funguje jen pro anglický jazyk - v testované verzi 10.10.3 nefunguje korektně přidávání do WL

3.3

Linux

U systému Linux se nedá jednoznačně říct, na kterou distribuci se přesně zaměřit. Existují i distribuce, které jsou určené přímo pro děti a „rodičovským módem“ je celý systém. Takovými distribucemi jsou např. DoudouLinux, SuliX, AbulÉdu nebo Ubuntu Christian Edition. Distribuce jsou upravované pro děti hlavně z funkčního hlediska, tedy aby systém byl pro děti co nejintuitivnější a nejlehčí na ovládání. Distribuce Ubuntu Christian Edition v sobě má i filtr webových stránek. Ostatní restrikce jako časově omezený přístup k PC nebo povolené/zakázané aplikace nejsou přítomné v těchto distribucích. Kdybychom se omezili na nejpoužívanější desktopová prostředí místo na konkrétní distribuce, tak by byl výčet kratší než seznam všech distribucí. Nejpoužívanějšími desktopovými prostředí jsou GNOME, KDE, Cinnamon, Xfce a UNITY. Až na KDE a jeho Kiosk mód žádné desktopové prostředí v sobě neobsahuje integrovanou podporu pro rodičovský mód. Kiosku se blíže věnuje Kapitola 5. Pro vytvoření částečného rodičovského módu lze buď použít některou z dostupných aplikací jako je nanny nebo timekpr, které podporují základní časové restrikce, nebo využít jeden z PAM (Pluggable Authentication Modules), což jsou moduly užívané k ověření uživatele. Na základě konfiguračních skriptů pak lze např. nastavit, kdy uživatel může využít přihlášení do systému, ale časové restrikce omezující strávený čas v systému do těchto skriptů zapsat nelze.

3.4

iOS

iOS je mobilní operační systém vytvořený společností Apple Inc. Původně byl určen pouze pro mobilní telefony iPhone, později se však začal používat i na dalších mobilních zařízeních této firmy, jako jsou iPod Touch, iPad a Apple TV. Průzkum funkcionality byl proveden na zařízení iPad 2 se systémem iOS8 verze 8.3. Rodičovskou kontrolu lze nastavit v iOSu na zařízeních iPhone, iPad a iPod touch. Nastavení lze nalézt v menu pod Nastavení/Obecné/Omezení. Při aktivaci je požadováno heslo, které lze zresetovat při zapomenutí jen zresetováním zařízení do továrního nastavení. 29

Samotné nastavení skýtá poměrně širokou škálu funkcí. Lze blokovat přístup k jednotlivým aplikacím a aplikace, které jsou umístěny přímo v systému a mají mezi sebou navíc vazby, se zakazují kaskádově, takže např. pokud chceme zakázat Fotoaparát, tak se zakáže automaticky i aplikace FaceTime. Výhodou je, že zakázané aplikace vizuálně zmizí ze systému a spouštěcí ikony nejsou vidět, takže to uživatele „neprovokuje“ zkoušet vše, co by mohl mít povolené, ale skutečně vidí pouze aplikace, ke kterým má přístup. K aplikacím se váže i nastavení, jak s nimi zacházet - instalovat je, mazat a nebo dělat nákupy v aplikacích. Každá možnost se dá jednotlivě nastavit. Přístup k „obsahu“ lze modifikovat pomocí předvolených filtrů. Obsahem se rozumí hudba, filmy, TV pořady, knihy, aplikace a samotné procházení webových stránek. Každá země má jiné hodnocení pro nevhodný obsah a to nemusí být založené jen na věku. Apple Inc proto doplnil toto nastavení o výběr státu, podle kterého se dá snáze vybírat z lokálních filtrů obsahu. Pokud zvolíme např. USA, je k dispozici žebříček Motion picture rating system, který klasifikuje obsah do celkem 5 kategorií a to – G, PG, PG-13, R a NC-17. V případě výběru České republiky je k dispozici pouze žebříček se třemi kategoriemi a to U, 15+ a 18+.

Obrázek 6: Nastavení omezení v systému iOS Z obsahu lze omezit následující kategorie: hudba a knihy (explicitní obsah), filmy (dle ratingu země, případně úplné zakázání), TV pořady (povolit/zakázat), aplikace (dle ratingu země nastavené v App Storu) a nastavení hesla pro nákupy (neplatí jen pro App Store, ale i iTunes a iBooks Store – další online obchody společnosti Apple Inc). V omezení webových stránek lze nastavit pouze základní věci a to BL, WL 30

společně v kombinaci s filtrováním obsahu pro dospělé, nebo vytvoření pouze seznamu webů, kam uživatel smí přistupovat (pouze WL). Systém v sobě má již některé WL weby předdefinované – jedná se o weby určené pro děti jako je např. Yahoo! Kids nebo PBS Kids. Weby nejsou lokalizované dle zvolené země v zařízení (v systému Mac OS od stejného výrobce toto funguje). Problémem je, že „Filtrování obsahu pro dospělé“ je filtr vytvořený výrobcem systému a nikde není blíže specifikováno, jak funguje nebo co přesně filtruje. Aplikacím lze zabránit v získávání informací z přístroje. Zakázat se dají tyto kategorie: polohové služby, kontakty, kalendáře, připomínky, fotografie, užití GPS polohy, užití technologie Bluetooth, mikrofon, účet na Twitteru a Facebooku (často používáno pro rychlou registraci a získání osobních dat jako je jméno, příjmení, email a datum narození) a reklamy. Dobrou funkcí je omezení nastavování GPS – je možné GPS nechat neustále zapnutou, a tak lze sledovat pohyb přístroje (uživatele). Dále lze zakázat zacházení s nastavením zařízení, používání mobilních dat, aktualizace aplikací na pozadí a limit hlasitosti. Limit hlasitosti lze nastavit na maximální povolenou úroveň, která bude brána v potaz jen v případě použití interní aplikace pro poslech hudby nebo sledování filmu. Asistovaný přístup Asistovaný přístup leží mimo nastavení restrikcí uživatelského účtu. Lze ho nalézt v Nastavení/Obecné/Zpřístupnění/Asistovaný přístup. Opět lze nastavit kód pro přístup k tomuto nastavení. Poté je možnost upravovat přístup pro jednotlivé aplikace přímo ze spuštěných aplikací. Při běhu aplikace stačí zmáčknout třikrát home button (hlavní tlačítko), vyplnit bezpečnostní kód a poté lze nastavit jednotlivé restrikce pro aktuálně otevřenou aplikaci. Pro zrušení všech restrikcí stačí opětovně třikrát zmáčknout home button, vyplnit kód a restrikce ukončit. Pokud se aktivuje Asistovaný přístup, lze zablokovat možnost odejít uživatele z aktuálně puštěné aplikace, nastavit, která HW tlačítka může používat, kam na obrazovce nesmí klikat, a jak dlouho smí u aplikace strávit. Tento režim je vhodný pro případ, kdy chceme návštěvníkovi dát přístup pouze do jedné aplikace a omezit mu tak přístup k celému zařízení. Shrnutí Mezi hlavní nedostatky bych zařadil absenci profilů. Rodičovský mód lze pouze zapnout nebo vypnout a vztahuje se na jedno zařízení. Lepším řešením je mít možnost vytvořit více profilů a mezi nimi přepínat. V nastavení přístupu na web lze v rámci automatických filtrů zapnout jen filtrování „obsahu pro dospělé“. Testováním bylo zjištěno, že do této kategorie

31

spadá pornografie a vulgární výrazy. Bezpečné vyhledávání funguje jen ve vyhledávači Bing – v ostatních vyhledávačích při vyhledání je blokována stránka s výskyty, protože jsou v nich vulgární výrazy (uživatel dá vyhledat slovo „porn“ a stránka se seznamem odkazů je filtrem následně zablokována). Na rozdíl od systému Mac OS se zadáním adresy do WL nebo BL nebere v potaz její doména, ale skutečně jen adresa. Může tak dojít k tomu, že chceme dítěti omezit stránku facebook.com, ale ono stále bude schopné se na sociální síť dostat přes mobilní verzi na m.facebook.com. Při přístupu na blokovanou stránku lze zadáním bezpečnostního kódu tuto stránku umístit do WL.

3.5

Android

Android je mobilní operační systém vytvořený společností Android Inc, která vznikla v roce 2003, ale již po dvou letech byla odkoupena firmou Google Inc. Android Inc od této doby vystupuje jako dceřinná firma Googlu. Průzkum funkcionality měl být proveden na zařízení Samsung Galaxy ACE 2 se systémem Android verze 4.2, ale tato verze Androidu nemá žádné vestavěné funkce pro vybudování rodičovského módu. V současné době je nejnovější verzí Android 5.0, který již rodičovský mód podporuje, ale dle [9] jen pro tablety. K zařízení, které by tuto verzi podporovalo, nemám přístup, takže průzkum funkcionality byl proveden na instalaci ve virtualboxu. Než se dostaneme k popisu samotného rodičovského módu, tak bych se rád pozastavil nad tím, že rodičovský mód není dostupný v mobilech, ale jen v tabletech. Šlo by to pochopit, kdyby „rodičovský mód“ nebyl v Androidu vůbec implementovaný, ale když je vyvinut, tak je otázkou, proč není přístupný i pro mobily. Poprvé se rodičovský mód objevil v Androidu 4.3. V mobilech tak lze maximálně nastavit PIN kód k přístupu na Google Play (obchod s aplikacemi) a zde nastavit i úroveň zabezpečení vzhledem k věku uživatele, takže pak není schopný si stáhnout aplikace, které pro něj nejsou určené. Tímto nastavením lze i omezit nakupování placených aplikací a automatické placení z napojených platebních služeb na Google Play v již nainstalovaných aplikacích. Pro omezení přístupu na web by se musela nainstalovat aplikace, kterou by uživatel používal jako webový prohlížeč a měla by v sobě implementovaný filtr obsahu. Takovou aplikací je třeba Ranger Pro Safe Browser. Pro vytvoření ideálního rodičovského módu by bylo třeba nainstalovat několik dalších aplikací a stejně by pak zacházení s telefonem nebylo komfortní, protože by se přístup musel měnit na několika místech. Rodičovský mód pro tablety Rodičovský mód lze nastavit v sekci Nastavení/Zařízení/Uživatelé. Tyto uživatelské profily slouží pro práci s tabletem. Ve chvíli, kdy je zamknutá obrazovka a uživatel chce zařízení odemknout, tak mu je nabídnuto, do kterého profilu se chce

32

přihlásit. V případě, že je profil chráněn heslem, tak uživatel musí pro přihlášení ještě zadat heslo.

Obrázek 7: Výběr profilu na uzamknuté obrazovce v Androidu Při přidání účtu máme dvě možnosti – buď přidáme uživatele nebo omezený profil. Přidáním uživatele vytvoříme zcela nový účet v Androidu, kde je pak možné instalovat vlastní aplikace, měnit si tapety aj. Hardwarové nastavení je sdílené mezi všechny uživatele zařízení, takže v případě, že si jeden uživatel vypne WiFi, tak se vypne i všem ostatním. Omezený profil vytvoří omezené prostředí aktuálně přihlášeného uživatele, takže se restrikce např. aplikují na jím nainstalované aplikace. V omezeném profilu lze zakázat jednotlivé nainstalované aplikace, přístup do galerie, telefonování a posílaní sms zpráv (některé tablety poslední dvě zmíněné možnosti podporují). Služby Googlu jako je Gmail nebo Calendar jsou zakázané v omezeném profilu a nedají se aktivovat. Lze zakázat i vstup do menu, takže uživatel má k dispozici jen aplikace na ploše. To se hodí, protože např. vstup do nastavení se vypnout nedá, a tak si uživatel může vypínat WiFi, GPS aj. přes menu Nastavení. Pokud omezíme vzhled sekundárního menu, které je v Androidu k dispozici po gestu přejetí dotykem shora dolů, tak tím vytvoříme vhodné prostředí pro rodičovský mód. U používaných technologií zařízením lze omezit pouze nastavení GPS, a to na zapnuto/vypnuto.

33

Shrnutí Obecně se dá říci, že systém Android nedisponuje dobrou podporou pro rodičovský mód. Hlavním nedostatkem je absence rodičovské kontroly na mobilních telefonech. V samotném nastavení pak chybí omezení webových stránek a některých interních aplikací, což vede k tomu, že je nelze zakázat, a tak je uživatel může používat (např. Google hledání, Hlasové hledání, Správce souborů). Naopak lze pochválit možnost vytváření profilů a jejich přepínání při přihlašování do zařízení ze zamknuté obrazovky. Jediným způsobem, jak efektivně vytvořit v systému Android rodičovský mód, je instalace dalších aplikací k tomu určených, popříp. celého launcheru (hlavní aplikace starající se o plochu a další aplikace). Z launcherů lze použít např. Kids Space Launcher, který podporuje časové restrikce, restrikce aplikací, webový prohlížeč v sobě obsahuje funkci filtrování obsahu aj.

3.6

Srovnání operačních systémů

Osobní počítač V rámci porovnávání systémů na osobním počítači budu brát v úvahu pouze systémy Windows a Mac OS, protože Linux nedisponuje vestavěnou podporou pro rodičovský mód (až na desktopové prostředí KDE). Správa uživatelských nastavení je v obou systémech téměř stejná. Mac OS má navíc pouze kopírování nastavení jednoho uživatele k jinému uživateli. Windows zase umožňuje provádět správu přes webové rozhraní. Tím, že jsou nástroje pro správu ve Windows dostupné i online a ne jen z jiných počítačů v lokální síti, jak je tomu v Mac OSu, je toto řešení mnohem použitelnější. Navíc použití webového rozhraní umožňuje ovládat systém i z jiných zařízení, nezávisle na instalovaném systému. Filtr webových stránek nabízí v systému Windows více možností a lze tak např. jednorázově vypnout sociální sítě. V obou systémech ale chybí nastavení nepřístupných kategorií obsahu webových stránek. Většinou se pod pojmem zakázání „obsahu pro dospělé“ skrývá pouze skrytí pornografie a vulgárních výrazů. Při přístupu na nevhodnou stránku lze v systému Windows požádat o výjimku a tato adresa je následně zařazena do seznamu požadavků pro odblokování. Díky online správě se na tuto akci dá vyvolat interakce ve formě poslání emailu a je-li správce u počítače, tak může rovnou z mailu udělit výjimku. V systému Mac OS lze stránku na WL přidat pouze správcem, kterému se musí „nadiktovat“, protože seznam požadavků pro odblokování není implementován. Časový přístup k zařízení je jednoznačně lépe vyřešen v systému Windows, protože umožňuje nastavit limity pro jednotlivé dny v týdnu a hlavně lze také nastavit i více časových intervalů použití během jednoho dne (případ, kdy chceme uživateli umožnit přístup na počítač třeba jen ráno a večer). Systém Mac OS umožňuje nastavit jen obecně limity pro všední dny a víkendy.

34

Zakazování aplikací je na podobné úrovni v obou systémech. Při spouštění zakázané aplikace systém Mac OS umožňuje vystavit jednorázovou výjimku pro její spuštění. V systému Windows ji lze pouze přidat mezi povolené aplikace, pokud ji chceme spustit. Statistiky jsou lépe řešené v systému Windows, kde lze nastavit i konkrétní období, pro které chceme statistiky vidět. Mobilní zařízení Pro mobilní telefony v současné době funguje jen vestavěná kontrola v iOSu. Pro tablety funguje rodičovská kontrola i v Androidu. Ve prospěch Androidu mluví pouze správa profilů. Na poli mobilních zařízení v možnostech restrikcí jednoznačně vede iOS i přesto, že se dá nastavovat pouze jeden restrikční profil na zařízení.

3.7

Dostupné aplikace pro filtrování webových stránek

Níže přikládám popis čtyř nejlépe hodnocených aplikací dle žebříčku[10], které jsou ovšem placené. Celkový přehled funkcionality jednotlivých aplikací lze najít také v [10]. Poté zmiňuji jednu aplikaci, která je zdarma a má podle mého názoru srovnatelné výsledky s konkurenčními placenými aplikacemi. Net Nanny Tato aplikace v posledních letech vyhrála několik ocenění na poli ochrany osobního počítače, a proto vývojáři aplikaci uzpůsobili i pro mobilní zařízení se systémem iOS a Android. Aplikace umožňuje filtrovat webový obsah na základě 18 kategorií. Procházení webu lze také časově omezit. Funkce nahrazování explicitního obsahu se hodí v případě, že se na stránce, která je potencionálně neškodná, objeví vulgární výrazy. K tomu může dojít např. u komentářů pod článkem. Nevhodný obsah je nahrazen nastaveným řetězcem znaků. • Cena: 5–40 $, záleží na cílovém systému • Kompatibilita: Windows XP+, MacOS X 10.7+, Android 2.2+, iOs 5.0+ WebWatcher Od Net Nanny se liší v absenci funkce nahrazování vulgárního obsahu, ale tato aplikace umí navíc zaznamenávat screenshoty, aby šlo analyzovat přesněji pohyb uživatele u zařízení. • Cena: 99.95 $ • Kompatibilita: Windows XP+, MacOS X 10.6+, Android 2.1+, iOs 6.0+

35

McAfee Safe Eyes Opět stejná funkcionalita jako Net Nanny, pouze chybí nahrazování vulgárního obsahu. Tato aplikace není podporována mobilními operačními systémy. • Cena: 49.95 $ • Kompatibilita: Windows XP+, MacOS X 10.7+ Profil Parental Filter Oproti předchozím nedokáže blokovat online hry a nepodporuje systém Mac OS. • Cena: 39.99 $ • Kompatibilita: Windows XP+, Android 2.1+, iOs 6.0+ K9 Web Protection Aplikace umožňuje filtrovat webový obsah na základě šesti kategorií. Dále umožňuje vytvářet statistiky, blokovat přístup k webu na základě časového intervalu a také podporuje mód pro bezpečné vyhledávání. Více viz [11] • Cena: Zdarma • Kompatibilita: Windows XP+, MacOS X 10.7+, Android 2.1+, iOs 6.0+

36

4

KDE

Než se dostaneme k samotnému Kiosku, je třeba říct alespoň něco o KDE a o tom, jakým způsobem probíhá vývoj tohoto desktopového prostředí. Informace k této kapitole byly čerpány z [12]. KDE je souhrnný název, kterým se označuje jak celá komunita vývojářů a přispivatelů, tak samotný software. Prvotní myšlenkou, již v roce 1996, bylo vytvořit uživatelsky příjemnější grafické prostředí. Postupem času se pod vývoj KDE dostal i samotný vývoj aplikací zaměřených na toto desktopové prostředí. Hlavní aplikace jsou distribuovány již v základní instalaci KDE. Jak jsem zmínil výše, tak KDE je vyvíjeno komunitou vývojářů – většinou neplacených opensource nadšenců, ale jsou mezi nimi i vývojáři placení firmou Red Hat, kteří kromě vývoje řeší i schvalování nové funkcionality, datum vydání nových verzí aj. Hlavním komunikačním kanálem komunity jsou mailinglisty a IRC kanály. Pro vývoj kódu se používá verzovací nástroj GIT. Vývojáři používají pro udržování dva hlavní GIT servery, a to git://git.kde.org a git://anongit.kde.org. První zmíněný je pro commitování nových verzí kódu, druhý je pouze pro čtení. Důvod rozdělení je kvůli loadbalancingu (rozložení zátěže), kdy se pro čtení využívá fyzicky více serverů. Vývojářský „kodex“ v komunitě KDE má 4 hlavní zásady: 1. aplikaci vypusť s rozumnou funkcionalitou, zlepšovat se může později 2. používej dostupné nástroje místo vymýšlení vlastních 3. frázi „měli bychom udělat“ nahraď frází „uděláme“ 4. stále vylepšuj stávající řešení Problém může nastat, pokud se vývojář řídí bodem 1, ale bod 4 ho již nezajímá. To vede k vývoji aplikací, které nejsou udržovány a původně zamýšlená funkcionalita není ani dopracována.

4.1

Přechod mezi major verzemi KDE

Jak už tomu bývá v rámci vývoje softwaru, i u KDE se rozhodli pro předělání jádra a zevnějšku celého prostředí. Byly kladeny nároky na nové věci, o kterých se ve starších verzích ani nevědělo. Jednalo se např. o widgety na ploše, intuitivnější interakci s uživatelem, optimalizace pro malé a nebo naopak velké monitory aj. Při přechodu na novější verzi je vždy otázkou výkon, protože se očekává, že nová verze bude subjektivně lepší a rychlejší. Bohužel se při přechodu z verze KDE3 na KDE4 stalo to samé co s příchodem KDE2. Ve verzi 4.0 bylo příliš mnoho problémů s výkonem, což znepříjemňovalo práci a uživatelé se hromadně 37

vraceli zpět k verzím 3.X. Kritici označovali verzi 4.0 jako verzi, která měla zůstat vývojářskou a k normálním uživatelům se neměla vůbec dostat. Jejich výtky byly opodstatněné, protože dokonce oproti verzím KDE3.X chyběly i oblíbené funkce a vzhled prostředí se nedal v rámci grafického rozhraní jednoduše upravovat. Řešení stability a výkonu však nebylo na vývojářích KDE, ale na implementátorech desktopového prostředí a vývojářích jednotlivých distribucí. Také se objevilo mnoho názorů, že tvůrci KDE přestali jednat s uživateli kvůli zpětné vazbě. Dokonce se v jedné chvíli uvažovalo o FORKu (rozdělení) projektu a rozdělení vývojového týmu na dva. Na druhou stranu ale byly i reakce pozitivní a do komunity se přidalo dalších 166 vývojářů, kterým se projekt KDE zalíbil a chtěli s ním pomoci. V současné době je major verze KDE již KDE5. Implementátoři nyní pracují na zabudování KDE5 do jednotlivých distribucí. V květnu 2015 vyšla první oficiální distribuce s KDE5 (Fedora Linux). Jelikož mým cílem je podporovat vývoj KDE i mimo zadání diplomové práce, tak se port Kiosku nevěnuje jen KDE4 ale rovnou i KDE5.

4.2

Spiny

Jako spin se označuje upravená instalace distribuce. Tyto úpravy vznikají na základě dvou hlavních důvodů, a to je buď potřeba uživatelů použít jiné desktopové prostředí, nebo nainstalovat si systém a mít v něm předinstalované aplikace podle zaměření – pro tyto potřeby jsou vytvářeny spiny výhradně pro hráče, programátory nebo třeba designery, kde spin obsahuje volně dostupné nástroje, se kterými je možné vytvářet grafiku [13]. Poslední zmíněný používají i grafici, kteří vytváří grafiku pro celou distribuci Fedora Linux, kde výchozím desktopovým prostředím je v současné době GNOME. Mezi ostatní spiny s úpravou desktopového prostředí patří KDE Plasma, Xfce a LXDE. Na první zmíněné je zaměřená tato diplomová práce. Aplikace pracující s komponentami systému jsou programovány většinou na míru na základě desktopového prostředí, a to je důvod, proč nástroj Kiosktool nebude funkční v hlavním desktopovém prostředí GNOME – to totiž neobsahuje potřebné frameworky.

38

5

Kiosk framework

Pro nadcházející text je potřeba znát pojem framework. Framework je softwarová struktura, která slouží jako podpora při programování a vývoji a organizaci jiných softwarových projektů. Může obsahovat podpůrné programy, knihovny API (Application Programming Interface – rozhraní pro vývoj aplikací), podporu pro návrhové vzory nebo doporučené postupy při vývoji. Cílem frameworku je převzetí typických problémů dané oblasti, čímž se usnadní vývoj tak, aby se návrháři a vývojáři mohli soustředit pouze na své zadání. – zdroj [14] Kiosk je framework, který byl poprvé zapracován do KDE verze 3. Umožňuje administrátorům upravovat pracovní prostředí pro jednotlivé uživatele systému. Omezit lze téměř cokoliv – ať už se jedná o banalitu, jako je nastavení pozadí plochy, přístup k tiskovému serveru, shellu nebo omezení částí aplikací. Informace k této kapitole byly čerpány z [15] a [16]. Vývojáři si od tohoto frameworku slibovali, že přispěje k rozšíření použitelnosti linuxu obecně i do sfér, jako je školství nebo kancelářské práce. Dle reakcí uživatelů v mailinglistu, kterých je v současné době 222, se tak i stalo, ale ne zřejmě v takové míře, jak bylo zamýšleno. Nyní mnozí uživatelé tvrdí, že je tento projekt „mrtvý“ a není nikdo, kdo by se chtěl aktivně podílet na vývoji. Navíc z celého seznamu se ozvali pouze dva uživatelé, kteří by měli zájem o port pro nové KDE. Jeden z nich, Marco Menardi, dělá správce sítí ve škole, kde provozuje Ubuntu s KDE, a důvod, proč stále používá verzi 3, je kvůli Kiosku, neboť v nové verzi není schopen docílit požadovaných možností zamknutí funkcionality. Budeme-li se v následujících podkapitolách bavit o restrikcích aplikací, tak ty platí pouze pro aplikace, které jsou napsané v jazyce C++ a používají pro vykreslování knihovny samotného KDE. Příkladem může být aplikace Dolphin nebo Konqueror. Pro kontrolu oprávnění se používá framework KConfig. Ten v KDE5 patří do první kategorie frameworků (není závislý na žádných jiných frameworcích). V KDE4 frameworky do kategorií dle závislosti rozdělované ještě nebyly. Konkrétně se používá třída KAuthorized a její 4 metody: • bool KAuthorized::authorize(const QString & action) • bool KAuthorized::authorizeControlModule(const QString & menuId) • QStringList KAuthorized::authorizeControlModules(const QStringList & menuIds) • bool KAuthorized::authorizeKAction(const QString & action) Voláním těchto metod z aplikací lze vyčíst aktuální nastavení frameworku Kiosk v konfiguračních souborech KDE. V případě, že by Kiosk framework měl být podporovaný i aplikacemi v jiném jazyce než C++, tak by bylo nutné napsat 39

knihovnu, která bude respektovat hierarchii konfiguračních souborů a dokáže z nich korektně vyčíst aktuální nastavení, případně vytvořit rozhraní, které bude komunikovat s frameworkem Kconfig.

5.1

Konfigurační soubory a jejich hierarchie

Aplikace v KDE používají stejné API pro vytvoření, přistupování a změnu konfiguračních souborů. Tyto soubory mají stejnou syntaxi. Jedná se o dvojici výrazů, kde je klíčové slovo jednoznačně určující nastavení a jeho hodnota. Mezi ně se vkládá znak „=“. Bílé znaky kolem znaku „=“ a na začátku resp. konci řádku nejsou brány v potaz. Aby se rozlišilo, pro kterou aplikaci, nebo část systému, má nastavení platit, se před seznam nastavení vypisuje skupina do hranatých závorek. [KDE Action Restrictions] action/lock_screen=false logout=false switch_user=false

Zdrojový kód 7: Ukázka konfiguračního souboru KDE

KDE nevyužívá pro konfiguraci pouze jeden soubor, ale je jich více. Je zavedený tzv. kaskádový systém, kdy je předem daná priorita umístění souborů a podle ní se postupuje ve vytváření konečné konfigurace. V případě, že se stejné nastavení objevuje ve více souborech, v potaz bude bráno to, které se nachází v konfiguračním souboru s nejvyšší prioritou. Pro zjištění hierarchie konfiguračních souborů se používají v KDE dvě globální proměnné – $KDEDIRS a $KDEHOME, které ukazují na složky, v nichž se mohou nacházet konfigurační soubory, popříp. se tyto soubory nachází ještě v podsložce .kde. V KDE5 se bere v potaz navíc složka $KDEHOME/.config. $KDEDIRS je seznam cest, které systém používá v případě, že hledá soubory (konfigurační soubory, fonty, výchozí obrázky aj.). Jednotlivé cesty jsou od sebe odděleny znakem „:“. $KDEHOME je ukazatel na cestu do složky aktuálně přihlášeného uživatele. Priorita v $KDEDIRS je určena zprava doleva a $KDEHOME má prioritu nejvyšší. Problémem je, že nejvyšší prioritu mají právě konfigurační soubory umístěné přímo v $KDEHOME, což znamená, že nastavíme-li nějaké omezení globálně, uživatel je schopný si ho ve svém souboru opět zpřístupnit. I na toto ale pomýšlí Kiosk, a tak byla přidána možnost nastavit příznak tzv. immutable (do češtiny lze přeložit jako neměnitelné). Ten zajistí, že přidáním řetězce [$i] k nastavení, se předejde prioritnímu přepsání z uživatelské (případně jiného konf. souboru s nižší prioritou) konfigurace. Jako immutable lze nastavit i celou skupinu přidáním řetězce [$i] za jméno skupiny. Takto lze zamknout i celý konfigurační soubor. To se provádí umístěním řetězce [$i] na první řádek konfiguračního souboru. 40

[ScreenSaver] AutoLogout[$i]=true AutoLogoutTimeout[$i]=600

Zdrojový kód 8: Kiosk - nastavení příznaku immutable

[ScreenSaver][$i] AutoLogout=true AutoLogoutTimeout=600

Zdrojový kód 9: Kiosk - zamknutí skupiny nastavení

Změna nastavení v aplikacích se projeví většinou až po jejich restartování. Jedná-li se však např. o nastavení v konfiguračním souboru kdeglobals, pak se změna projeví až po odhlášení a přihlášení – resp. po restartu desktopového prostředí. V KDE3 a KDE4 lze restartovat desktopové prostředí pomocí vypnutí procesu přes „killall plasma-desktop“ a jeho následné zapnutí přes „plasma-desktop &“. V KDE5 se proces nejmenuje plasma-desktop ale plasmashell. Z administrátorského hlediska není vhodné upravovat konfigurační soubory jednotlivě uživatelům, a proto lze využít funkcionalitu pro vytvoření profilů a jejich přiřazení skupině uživatelů (linuxová skupina uživatelů) nebo přímo uživateli. Opět toho lze docílit pomocí úpravy správných konfiguračních souborů, a to /etc/kde4rc (pro KDE4 a KDE5), kde se ve skupině [Directories] přepíše nastavení pro umístění profilů a určí se soubor, který mapuje profily nastavení na jednotlivé uživatele nebo skupiny uživatelů, např. userP rof ileM apF ile = /etc/Kuserprof iles Zde už je možné ve skupinách [Groups] a [Users] nastavit přímo mapování na profily. [Users] JanaCh=Profil_c1 EsterK=Profil_c2 [Groups] Deti=Profil_c3

Zdrojový kód 10: Kiosk - nastavení profilů pro uživatele a skupiny

5.2

Action restrictions

Výhodou KDE je, že interní aplikace sdílí stejné knihovny pro vykreslování grafických komponent. Pro uživatele je potom snadnější zacházet s novými programy, 41

protože jejich ovládání je podobné. Jedná se o akce jako je Otevřít, Uložit, Tisk, Nápověda aj. Nastavení se provádí v konfiguračním souboru kdeglobals, který byl v KDE3 umístěn v /share/config, v KDE4 v /etc/kde4/share/config nebo ve složce s výchozím profilem. V KDE5 se složka kde4 nepoužívá a využívá se složky .config. Zdrojovým kódem 11 lze zakázat globálně ve všech KDE aplikacích najednou položky menu Úpravy – konkrétně se jedná o položky Zpět, Vpřed, Kopírovat, Vložit a Vyjmout. [KDE Action Restrictions][$i] action/edit_undo=false action/edit_redo=false action/edit_cut=false action/edit_copy=false action/edit_paste=false

Zdrojový kód 11: Kiosk - restrikce menu Úpravy

5.3

URL restrictions

Kiosk nabízí omezení URL adres, na které se dá přistupovat. Toto nastavení berou v potaz pouze interní KDE aplikace – pro procházení webu lze použít aplikaci Konqueror. Omezení lze specifikovat na základě referrera nebo cílové destinace. U obojího lze nastavit protokol, hostname nebo konkrétní cestu. Pokud nepoužijeme znak „!“ na konci protokolu, tak se bere vypsaná hodnota jako prefix, tedy pro hodnotu http bude odpovídat i protokol HTTPS. V kódu 12 se nachází přesný tvar zápisu pravidel. rule_N=,,,,<protocol>,,< path>,<enabled>

Zdrojový kód 12: Kiosk - vzor pro zápis pravidel V dnešní době weby používají více subdomén, většinou se jedná o adresy, na kterých je umístěn statický obsah, nebo mobilní verze stránek. Než abychom vypisovali všechny možné domény, tak lze použít „wildcard“ zápis. Příkladem může být nastavení hostname na *.policka.cz, které odchytí i takové stránky jako static.policka.cz nebo m.policka.cz. Tato funkcionalita se dá použít i pro zamezení přístupu uživatelů na disk. Jeli hostname vynechán a jako protokol použit file, pak se cesta bere z lokálního systému souborů. Cesty lze kombinovat i se systémovými proměnnými. Zdrojovým kódem 13 lze zamezit uživateli pohyb na disku jen do své home složky a tmp složky. 42

[KDE URL Restrictions][$i] rule_count=6 rule_1=open,,,,file,,,false rule_2=list,,,,file,,,false rule_3=open,,,,file,,$HOME,true rule_4=list,,,,file,,$HOME,true rule_5=open,,,,file,,$TMP,true rule_6=list,,,,file,,$TMP,true

Zdrojový kód 13: Kiosk - restrikce přístupu na disk

5.4

Control Module Restrictions

Přes Control center (Ovládací panely) lze nastavit mnoho aspektů systému – jednotlivé nastavení se dělí do skupin jako jsou fonty, plocha, barvy aj. Těmto skupinám se říká „kcm moduly“ a lze je jednotlivě uzamknout. Konkrétní příklad lze vidět v kódu 14, kdy zakážeme editaci pozadí a nastavení proxy serveru. [KDE Control Module Restrictions][$i] kde-background.desktop=false proxy.desktop=false

Zdrojový kód 14: Kiosk - restrikce kcm modulů Pomocí příkazu kcmshell --list pro KDE3 nebo kcmshell4 --list pro KDE4 a KDE5 lze zjistit seznam dostupných modulů, které lze tímto nastavením blokovat. Syntaxe zápisu je <module-name>.desktop=false. Ve verzi KDE5 je sice dostupný příkaz jako z předchozí verze, ale k dispozici je i nový kcmshell5 --list, takže se dá předpokládat, že příkaz ze starší verze bude fungovat jen dočasně.

5.5

Resource Restrictions

Ve složce /share je mnoho souborů, které jsou sdílené aplikacemi – jedná se např. o ikony, zvuky nebo uživatelské profily aplikací. Nachází-li se ale stejný obsah v $KDEHOME/share, pak je tento obsah brán přednostněji. I toto je chování, kterému lze zamezit použitím Kiosku. Syntaxe zápisu je =false. Lze zakázat uživatelské aplikace spouštějící se po startu, jeho specifické konfigurační skripty aj. [KDE Resource Restrictions] autostart=false

Zdrojový kód 15: Kiosk - restrikce aplikací spouštějících se po startu

43

5.6

KioskTool

Všechny restrikce lze ručně vypisovat do konfiguračních souborů, ale jednodušší bylo napsat GUI aplikaci, která se o to stará automaticky. V aplikaci funguje systém profilů a správy celých skupin. Na Obrázku 8 je možné vidět nástroj KioskTool pro KDE3, který ovšem díky změnám v nové verzi KDE není možné v KDE4 ani přeložit a nainstalovat kvůli používaným knihovnám a umístění konfiguračních skriptů.

Obrázek 8: GUI aplikace Kiosk admin tool. Nástroji KioskTool a jeho portu pro KDE4 se věnuje Kapitola 7.1.

5.7

Další možné restrikce

Kiosk se věnuje hodně přístupu k lokálním prostředkům, ale opomíjí dvě podstatné kategorie nastavení pro rodičovský mód. První z nich je časový přístup k zařízení a druhou je filtrování webových stránek, které v současné chvíli lze praktikovat jen formou WL a BL. Proto je vhodným rozšířením dopracování této funkcionality pro vytvoření lepšího rodičovského módu.

44

6

Automatická klasifikace dokumentů

V této kapitole je uveden přehled možností, které vedou k vytvoření klasifikátoru textových dokumentů. Je zde popsán celý postup od začátku zpracování textu až po automatické řazení do kategorií.

6.1

Klasifikace textových dokumentů

Mějme dokument d ∈ X, kde X je množina všech dokumentů, dále konečnou množinu tříd C = {c1 , c2 , . . . , cj }, kam můžeme jednotlivé dokumenty zařadit. Třídy lze nazývat i kategorie popř. štítky – pak se říká, že dokument je označen štítkem. Mějme trénovací množinu dokumentů hd, ci, kde hd, ci ∈ X × C. Příkladem může být třeba hd, ci = hP řidejte 2 vajíčka a mouku, receptyi kdy říkáme, že věta „Přidejte 2 vajíčka a mouku“ spadá do kategorie „recepty“. Trénováním klasifikátoru na trénovacím corpusu se snažíme nalézt funkci γ, která by klasifikovala další dokumenty do kategorií, tedy γ:X→C Tomuto procesu učení se říká supervised learning (učení s učitelem), kdy klasifikátor trénujeme na množině dokumentů, které jsou již označené. Další způsob klasifikace je unsupervised learning (učení bez učitele), kdy máme pouze množinu dokumentů, které nejsou označeny kategorií do které spadají. V takovém případě se používají klasifikátory pracující se shlukováním vlastností v textu a hledající podobnosti. Výsledkem pak je rozřazení dokumentů do kategorií, které následně musí uživatel pojmenovat. V klasifikaci textových dokumentů se tato metoda moc nepoužívá. Třetí způsob použití klasifikátorů je semi-supervised learning, což je metoda kombinující předchozí dva způsoby klasifikace. K trénování je možné použít jak dokumenty označené třídou, do které spadají, tak dokumenty neoznačené. Většinou je označených dokumentů malý počet a neoznačených naopak velký. Trénování pak probíhá tak, že se klasifikátor trénuje na množině označených dokumentů a na neoznačených vykoná klasifikaci. Tam, kde je největší pravděpodobnost odhadu třídy, se berou tyto dokumenty pro další kolo pro dotrénování klasifikátoru. Tento postup se provádí do té doby, než je neoznačených dokumentů co nejméně nebo než se nepřestane zmenšovat pravděpodobnost zařazení nezařazených dokumentů – tedy chvíle, kdy dojde k přetrénování klasifikátoru. Proces klasifikace se dělí také podle toho, do kolika tříd bude dokument klasifikován a to na: Binární klasifikace Provádí se pouze do dvou tříd. Je to základní přístup, kdy lze třídy i popsat 45

jako pozitivní a negativní příklady – tedy zkoumaný dokument buď spadá do třídy A, nebo je mimo, a tak je ve třídě B. Příkladem může být např. určení, zda je přijatý email SPAM. Diskrétní klasifikace Provádí se do více než dvou tříd. Každý dokument spadá nejvýše do jedné třídy. Příkladem může být např. určení jazyka zkoumaného textu. Vícelabelová klasifikace Provádí se do více tříd. Každý dokument může spadat do více tříd. Příkladem může být např. určení kategorie článku.

6.2

Předzpracování dat

Předtím, než je možné samotný dokument předložit ke klasifikaci, je nutné provést několik kroků. Tento postup se provádí jak pro dokument, který má být klasifikovaný, tak pro dokumenty v trénovacím corpusu. Nejdříve je třeba provést tzv. tokenizaci, kdy ze zdrojového textu dokumentu na základě pravidel vypreparujeme „vlastnosti“, na nich lze následně provádět jazykové operace a poté se provádí převod na tvar, se kterým bude moci klasifikátor pracovat, např. reprezentace dat vektorem vah. Tokenizace Tokenizace je proces, kdy řetězec znaků (dokument) rozdělujeme na jednotlivé tokeny. To se děje na základě definovaných pravidel, podle kterých tokeny vytváříme. Tato pravidla se nejčastěji zapisují pomocí regulárních výrazů, ve kterých definujeme, co vše může token obsahovat. Pokud bychom použili výraz [a-zA-Z0-9]{3,}, tak za token bude považován každý řetězec, ve kterém se nachází alespoň 3 znaky a bude obsahovat pouze malá písmena, velká písmena nebo číslice. Pokud bychom délku neomezovaly, mohl by převod vypadat jako na Obrázku 9.

Obrázek 9: Tokenizace - převod textu na tokeny Není vhodné omezovat horní hranici délky tokenu ve fázi samotného hledání vzorů v textu. Pokud bychom za oddělovač nepovažovaly jen „bílé znaky“, tak by se mohlo stát, že řetězec o větší délce se rozdělí nechtěně na dva. Došlo by 46

tak k tomu, že řetězec, který chceme ignorovat, by reprezentoval dokonce více tokenů, které pro nás nemají správnou informační hodnotu. Je-li zdrojový dokument prostý text, pak tokenizace není nijak složitá. Problém nastává, pokud se jedná o dokument ve značkovacím jazyce jako je HTML, XML aj. Pro takové dokumenty je potřeba provést hlubší analýzu, pro kterou neexistuje unifikovaný přístup. Pokud chceme správně aplikovat tokenizaci, tak je potřeba znát jazyk dokumentu. Můžeme tak aplikovat dodatečná pravidla. Pro text v hebrejštině by to byla tokenizace v opačném směru, protože text je psaný zprava doleva. Pro angličtinu se dá např. před samotnou tokenizací použít nahrazování apostrofů a zkrácených výrazů jako je aren’t. Tokeny aren a t nemají takovou vypovídající hodnotu jako are a not. Další problém může nastat, pokud klasifikujeme text napsaný v jazyce, který nepoužívá mezery (čínština) nebo dlouhá slova složená z více normálních slov (němčina). V takovém případě se musí aplikovat další algoritmy. Nejlehčím způsobem je hledání nejdelší shody, ale ve skutečnosti je toto řešení nepřesné a musí se už ve fázi tokenizace aplikovat pravidla pro analyzovaný jazyk textu pro správnou analýzu takových řetězců. Stopwords Stopwords (český ekvivalent stopslova) jsou slova, která se v dokumentech objevují příliš často, a tak jejich informační hodnota není přínosem v klasifikaci dokumentů. K jejich odstranění lze přistupovat dvojím způsobem. Buď použijeme seznam stopslov, který je dostupný pro jazyk, jehož dokumenty právě analyzujeme, nebo si vytvoříme seznam vlastní. Výhodou druhé metody je, že je seznam orientovaný podle dokumentů, které právě hodnotíme, takže nám neuniknou slova, která se normálně používají v hojné míře, ale v našich dokumentech se nevyskytují v takovém počtu. Seznam můžeme vytvořit na základě frekvence výskytů slov napříč trénovacím corpusem dokumentů pro každou třídu dokumentů. Jsou ale případy, kdy se použití stopslov nehodí. Pokud bychom vzali v úvahu anglický seznam stopslov a větu „To be, or not to be“, tak by nám z ní nezůstalo nic, protože se skládá pouze ze stopslov. Lemmatizace a stemming Lemmatizace je proces, kdy se převádí token (slovo) na svůj základní tvar – tzv. lemma. Lemmatizátory buď fungují tak, že vyhledají slovo v databázi a k němu i základní tvar, nebo na základě pravidel jazyka a základních tvarů slov se snaží slovo nalézt. První řešení je vhodné v případě, kdy si můžeme dovolit používat spolu s nástrojem i velkou databázi dat. Druhé řešení je vhodné použít tam, kde je kladen důraz na minimalizaci objemu dat aplikace a není potřeba úplná 47

přesnost lemmatizátoru. Stemming se stará o převod základního tvaru slova na kmen slova. Tento proces často používají vyhledávače pro dohledání relevantních výsledků na základě dotazu. Příkladem může být anglické sloveso „be“. Pokud aplikujeme lemmatizaci a stemmer na řetězec „He is ten years old“, vznikne nám „He be ten year old“. Sloveso „is“ se převedlo na základní tvar „be“, což pomůže v relevantnosti dotazů. Pokud by někdo neuměl anglicky a snažil se vyhledat řetězec se stejným významem, ale napsal by „He are ten year old“, tak bez použití lemmatizace a stemmingu by byla shoda jen částečná. Pravidlo SSES → SS IES → I SS → SS S→

Ukázka užití mattresses → mattress abilities → abiliti process → process dogs → dog

Tabulka 4: Příklad základních pravidel stemmingu – algoritmus Porter’s stemmer, zdroj [1] V Tabulce 4 se nachází část pravidel, která se používají pro úpravu tokenů ve fázi stemmingu. Pro stemming existuje několik algoritmů a liší se hlavně v tom, co je považováno za základní tvar. Uvedu příklad na dvou stemmerech. Stemming budeme aplikovat na větu „I have a few abilities like sewing and copywriting.“. První stemmer algoritmus se jmenuje Porter. Větu uvedenou výše stemmer upraví na I have a f ew abil like sew and copywrit. Dalším příkladem je algoritmus Lancaster, který větu upraví na i hav a f ew abl lik sew and copywrit. Lze pozorovat, že mezi algoritmy jsou rozdíly, což vede ke generování jiného slovníku (jedinečné tokeny napříč trénovacím corpusem). Ke snížení velikosti slovníku pomáhá i použití „stopslov“, zmíněných v předchozí podkapitole. Po této fázi lze aplikovat ještě tzv. pos-tagging, který přiřadí lemmatu mluvnickou kategorii. U podstatných jmen, přídavných jmen, zájmen a sloves lze dále přidávat informace, zda jsou v singuláru nebo plurálu. U podstatných jmen, přídavných jmen, zájmen a číslovek lze ještě doplnit informaci, ve kterém se nacházejí pádu. Váha tokenu Abychom mohli text převést do takové podoby, aby se s ním dalo pracovat, je potřeba slovům přiřadit váhu příp. pravděpodobnost, které pak udávají jakou měrou slovo určuje výslednou třídu, do které patří celý dokument. Lze použít několik způsobů: 48

Boolean hodnocení je základní metoda, kdy se slovo hodnotí 1 (True), pokud se ve vzorovém corpusu v dané třídě vyskytuje a 0 (False) pokud nikoliv. Document frequency (dále DF) je metoda založené na prostém spočítání výskytů slova v jednotlivých dokumentech – tedy v kolika dokumentech z příslušné třídy je slovo, které hodnotíme, obsaženo. Obdobným hodnocením je Collection frequency (dále CF), které udává počet výskytů v celé kolekci dokumentů dané třídy. Pro výsledné určení váhy se počet většinou normalizuje pomocí délky všech dokumentů v případě CF nebo počtem dokumentů v případě DF. Nevýhodou CF je, že počítá s množinou dokumentů jako s jedním dlouhým textem, a tak slova, která se nadmíru vyskytují jen v několik dokumentech, mohou ovlivňovat nepříznivě výslednou váhu. Term frequency - Inverse document frequency (dále TFIDF) je metoda, která pro každý dokument spočítá nejdříve term frequency slova pomocí nd , tft = |d| kde nd je počet výskytů slova t v dokumentu d a |d| je počet slov v celém dokumentu. Dále se vypočítá inverse term frequency pomocí idft = log

N , dft

kde N je celkový počet dokumentů a dft je DF, tedy počet dokumentů napříč celou kolekcí, ve kterých se dané slovo nachází. Výsledná váha se vypočítá pomocí tf idft,d = tft,d × idft pro každý dokument d [1]. Pokud bychom chtěli převést DF na pravděpodobnost, tak je potřeba spočítat i frekvenci slova mimo třídu. Ve Zdrojovém kódu 16 je napsaná funkce v jazyce Python, která v binární klasifikaci určuje pravděpodobnost jednotlivým slovům, že na jejich základě dokument spadá do kategorie – v tomto případě kategorie good nebo bad. Na vstupu funkce přijímá term (zkoumané slovo), celkový počet dokumentů v kategorii good a celkový počet dokumentů v kategorii bad. Funkce gethash vrací počet dokumentů, ve kterých se slovo vyskytuje v kategorii good nebo bad. Pravděpodobnost je přiřazována tak, že slovo, které se nevyskytuje vůbec v kategorii good, ale pouze v kategorii bad, dostane přiřazenu pravděpodobnost 0.99, pokud je tomu naopak, tak 0.01. Není možné používat pravděpodobnost 1 resp. 0, protože takové hodnoty by pak nepříznivě ovlivňovaly výpočet celkové pravděpodobnosti, že dokument spadá do dané třídy. Toto je nejjednodušší způsob, jak přiřazovat slovům pravděpodobnosti. N-gramy N-gram je sekvence n po sobě jdoucích slov. Je-li n rovno 2, pak se nazývá bigram či digram, je-li n rovno 3, pak se nazývá trigram. Použitím digramů a trigramů 49

1 2 3 4 5 6

def get_p(term, ngood, nbad): g = gethash(term, ’good’) b = gethash(term, ’bad’) p = max(0.01, min(0.99, (min(1, (b/nbad) / (min(1, (g/ngood)) + min(1, (b/nbad))))))) return p

Zdrojový kód 16: Určení pravděpodobnosti slova na základě Document Frequency

v klasifikaci dokumentů nám pomáhá zpřesnit klasifikaci, neboť můžeme zachytit závislosti mezi jednotlivými slovy. Některé klasifikátory dokonce neuvažují ani unigramy – samotná slova a zaměřují se pouze na digramy a trigramy. S N-gramy se dále zachází jako s tokeny, takže jejich použitím nám roste velikost slovníku.

6.3

Klasifikátory

Klasifikačních algoritmů je celá škála, ale dle nastudované literatury [1], [17], [18] a [19] jsem se rozhodl pro porovnání tří hlavních klasifikátorů, které by měly dosahovat dobrých výsledků. Jsou jimi Support Vector Machine, Multinomiální naivní Bayesovský klasifikátor a Bernoulliho naivní Bayesovský klasifikátor. Poslední dva zmíněné algoritmy se liší v tom, jakým způsobem se určuje pravděpodobnost jednotlivým slovům a jak se zachází se slovy, která se vyskytla v trénovací množině, ale v klasifikovaném dokumentu ne. Multinomiální model spojí dokumenty a pracuje s nimi jako s jedním dlouhým textem, kdežto Bernoulliho model uvažuje dokumenty jednotlivě a bere v potaz i slova, která byla v trénovací množině, ale v klasifikovaném dokumentu se nenachází. Existují i jiné klasifikátory jako rozhodovací stromy, neuronové sítě, k-nejbližších sousedů aj., ale ty zde neuvádím, protože pro hodnocení HTML dokumentů bude nejdůležitější samotné předzpracování dokumentu. 6.3.1

Support Vector Machine

Support Vector Machines (dále jen SVM, českým ekvivalentem je metoda podpůrných vektorů) je způsob strojového učení, kdy se využívá metoda učení s učitelem. Zaměříme se pouze na binární klasifikaci, kterou budeme využívat v klasifikátoru HTML dokumentů. SVM nabízí velmi progresivní a novou metodu, kterou rozpracovali koncem 20. a začátkem 21. století Vladimir Naumovič Vapnik a Alexej Jakovlevič Červoněnkis. Této metody lze využít především pro klasifikační úlohy, rovněž ale nachází uplatnění v regresním modelování a neparametrických odhadech hustoty. [20]

50

V lineárním modelu při binární klasifikaci je úkolem SVM nalézt nadrovinu, která vhodně rozděluje prostor jednotlivých vlastností (bodů). Ideálním řešením je případ, kdy body leží v opačných nadrovinách. Další optimalizací je maximalizace vzdálenosti nejbližších bodů od této roviny, aby klasifikace nových dokumentů mohla probíhat přesněji. Na Obrázku 10 vlevo je případ, kdy jsou sice body v opačných nadrovinách, ale rozdělení není voleno optimálně pro pozdější klasifikaci. Vpravo je správné proložení.

Obrázek 10: SVM - možná proložení přímky. Lineární SVM lze matematicky popsat takto – mějme trénovací data D a množinu n bodů, pak D = {(xi , yi ) |xi ∈ Rp , yi ∈ {−1, 1}}ni=1 , kde yi je buď +1 nebo -1 (binární klasifikace) a tím určuje, kam xi spadá. xi je p-dimenzionální vektor. Každou nadrovinu lze zapsat jako množinu bodů x splňujících w·x−b=0 Operace · je skalární součin a w je normálový vektor k nadrovině. Pokud jsou data lineárně separovatelná, tak se zvolí dvě nadroviny (každá pro jednu třídu), mezi nimiž se snažíme nalézt následně co největší vzdálenost. Nadroviny lze popsat jako w·x−b=1 pro třídu yi = 1 a w · x − b = −1 pro třídu yi = −1 [21]. Hledání nadroviny je tedy optimalizační problém, kdy se hledá maximální vzdálenost podpůrných vektorů od dělící nadroviny. Podpůrné vektory jsou ty, které leží nejblíže nadrovině. Hledáme minimální ||w||, protože vzdálenost mezi nadrovinami je 2/||w||, jak lze vidět na Obrázku 11. 51

Obrázek 11: SVM - geometrický popis, zdroj [22] Samotná klasifikace probíhá tak, že se zjišťuje, do jaké nadroviny spadá zkoumaný vektor příznaků. 6.3.2

Naivní Bayesovský klasifikátor

Naivní Bayesovský klasifikátor je algoritmus, který využívá techniku učení s učitelem a aplikuje se zde Bayesův teorém s „naivním“ předpokladem o nezávislosti mezi jednotlivými jevy (slovy). Bayesův teorém se dá matematicky popsat jako: P (A|B) =

P (A) P (B|A) , P (B)

kde A a B jsou jevy, P (A) a P (B) je pravděpodobnost, že nastane jev A resp. B nezávisle jeden na druhém a P (A|B) je pravděpodobnosti, že nastane A, pokud nastal jev B, P (B|A) obdobně obráceně. Nechť y je kategorie dokumentů a x1 ...xn je vektor popisující jednotlivá slova dokumentu, pak lze Bayesův teorém aplikovat následovně P (y|x1 , . . . , xn ) =

P (y) P (x1 , . . . , xn | y) . P (x1 , . . . , xn ) 52

S použitím předpokladu o nezávislosti lze upravit dále P (xi |y, x1 . . . , xi−1 , xi+1 , . . . , xn ) = P (xi |y) , pro všechna i, následně zjednodušením dostaneme P (y) ni=1 P (xi | y) P (y|x1 , . . . , xn ) = . P (x1 , . . . , xn ) Q

Díky tomu, že P (x1 , . . . , xn ) je konstanta daná vstupem, lze rovnici pomocí úměrnosti přepsat na následující P (y|x1 , . . . , xn ) ∝ P (y)

n Y

P (xi | y)

i=1

a z toho dostáváme rovnici pro klasifikaci yˆ = arg max P (y) y

n Y

P (xi | y).

i=1

Přepsáno slovy – pro každou třídu (v případě binární klasifikace pro dvě) se spočítá pravděpodobnost, že dokument spadá přímo do této třídy a bere se ta, kde je výsledná pravděpodobnost nejvyšší. Záleží tedy na tom, jakým způsobem se zvolí pravděpodobnosti jednotlivých slov, jestli se volí na základě DF, CF nebo jiným způsobem, a jak se zachází se slovy, která se nevyskytla v trénovacím corpusu. Dále lze popsat dva modely podle toho jak pracují s vlastním počítáním pravděpodobností slov. Multinomiální model Pseudokód trénovací fáze a vytvoření slovníku s pravděpodobnostmi multionomiálního modelu lze vyčíst z kódu 17. 1 2 3 4 5 6 7 8 9 10 11

TrainMultinomialNB(C,D) V ← ExtractVocabulary(D) N ← CountDocs(D) for each c ∈ C do Nc ← CountDocsInClass(D, c) prior[c] ← Nc /N textc ← ConcatenateTextOfAllDocsInClass(D, c) for each t ∈ V do Tct ← CountTokensOfTerm(textc , t) for each t ∈ V do condprob[t][c] ← P Tct +1 t0

12

(Tct0 +1)

return V, prior, condprob

Zdrojový kód 17: Multinomiální model - trénování corpusem dokumentů [1]

53

V trénovací fázi se spojí všechny dokumenty do jednoho textu a počítá se s počtem výskytu slova v celém textu – tedy CF ne DF. Při počítání pravděpodobnosti se každý výskyt inkrementuje o 1 (v kódu 17 na řádku 11), abychom se vyhnuli nulové pravděpodobnosti slova pro danou třídu. Po fází trénování přichází fáze samotné klasifikace a ta se pro tento model provádí dle kódu 18. Tento model při klasifikaci nebere v potaz slova, která se vyskytla v trénovacím corpusu, ale v klasifikovaném dokumentu se nenacházejí. 1 2 3 4 5 6 7

ApplyMultinomialNB(C, V, prior, condprob,d) W ← ExtractTokensFromDoc(V, d) for each c ∈ C do score[c] ← log prior[c] for each t ∈ W do score[c] += log condprob[t][c] return arg maxc∈C score[c]

Zdrojový kód 18: Multinomiální model - klasifikace dokumentu [1]

Trénovací corpus

Testovací corpus

Č. 1 2 3 4 5

Obsah dokumentu vajíčka mouka vajíčka cukr vajíčka vajíčka vajíčka kvasnice kuře snáší vajíčka vajíčka vajíčka vajíčka snáší kuře

třída = Recept? Ano Ano Ano Ne ?

Tabulka 5: Příklad pro Naivní bayesovský klasifikátor V Tabulce 5 lze vyčíst ukázkový příklad, na kterém si ukážeme, jak lze počítat pravděpodobnosti zařazení dokumentu do cílové třídy. Pro trénovací corpus budou použity dokumenty 1 – 4. Test bude proveden na dokumentu č. 5. Nejdříve si spočítáme pravděpodobnost, že dokument je, resp. není, ve třídě recept - Pˆ (r) = 3/4, Pˆ (¯ r) = 1/4. Dále spočítáme pravděpodobnosti jednotlivých slov: Pˆ (vajíčka|r) = (5 + 1)/(8 + 6) = 3/7 Pˆ (kuře|r) = Pˆ (snáší|r) = (0 + 1)/(8 + 6) = 1/14 Pˆ (vajíčka|¯ r) = (1 + 1)/(3 + 6) = 2/9 ˆ ˆ P (kuře|¯ r) = P (snáší|¯ r) = (1 + 1)/(3 + 6) = 2/9 V první části výpočtu je vždy počet výskytů slova v dané třídě inkrementovaný o 1 a je dělen součtem délky všech dokumentů dané třídy a délky slovníku. Výpočet pro finální zařazení se provede následovně: Pˆ (c|d5 ) ∝ 3/4 · (3/7)3 · 1/14 · 1/14 ≈ 0.0003 54

Pˆ (¯ c|d5 ) ∝ 1/4 · (2/9)3 · 2/9 · 2/9 ≈ 0.0001 S použitím multinomiálního modelu by byl dokument zařazen do třídy „recept“. Bernoulliho model Pseudokód trénovací fáze a vytvoření slovníku s pravděpodobnostmi Bernoulliho modelu lze vyčíst z kódu 19. 1 2 3 4 5 6 7 8 9 10

TrainBernoullilNB(C,D) V ← ExtractVocabulary(D) N ← CountDocs(D) for each c ∈ C do Nc ← CountDocsInClass(D, c) prior[c] ← Nc /N for each t ∈ V do Nct ← CountDocsInClassContainingTerm(D, c, t) condprob[t][c] ← (Nct + 1)/(Nc + 2) return V, prior, condprob

Zdrojový kód 19: Bernoulliho model - trénování corpusem dokumentů [1] V trénovací fázi se se bere v potaz počet dokumentů, ve kterých se slovo vyskytlo, ne přímo jeho přesný počet výskytů – tedy DF. Po fází trénování přichází fáze samotné klasifikace, a ta se pro tento model provádí dle kódu 20. Tento model při klasifikaci dokumentů bere v potaz i slova, která se nevyskytují v dokumentu, ale v trénovacím corpusu ano. Navíc pro klasifikaci se berou pouze unikátní slova (vyskytuje-li se slovo v textu vícekrát, pak se klasifikuje pouze jednou) a to u dlouhých textů může vést k nesprávnému začlenění. 1 2 3 4 5 6 7 8 9

ApplyBernoulliNB(C, V, prior, condprob,d) Vd ← ExtractTermsFromDoc(V, d) for each c ∈ C do score[c] ← log prior[c] for each t ∈ V do if t ∈ Vd then score[c] += log condprob[t][c] else score[c] += log(1-condprob[t][c]) return arg maxc∈C score[c]

Zdrojový kód 20: Bernoulliho model - klasifikace dokumentu [1] Opět si ukážeme výpočet na ukázkovém příkladu z Tabulky 5. Nejdříve si spočítáme pravděpodobnost, že dokument je, resp. není, ve třídě recept - Pˆ (r) = 3/4, Pˆ (¯ r) = 1/4. Dále spočítáme pravděpodobnosti jednotlivých slov. Nyní je třeba spočítat i pravděpodobnost slov, která se nevyskytují v klasifikovaném dokumentu: 55

Pˆ (vajíčka|r) Pˆ (kuře|r) = Pˆ (snáší|r) Pˆ (mouka|r) = Pˆ (cukr|r) = Pˆ (kvasnice|r) Pˆ (vajíčka|¯ r) ˆ ˆ P (kuře|¯ r) = P (snáší|¯ r) ˆ ˆ ˆ P (mouka|¯ r) = P (cukr|¯ r) = P (kvasnice|¯ r)

= = = = = =

(3 + 1)/(3 + 2) = 4/5 (0 + 1)/(3 + 2) = 1/5 (1 + 1)/(3 + 2) = 2/5 (1 + 1)/(1 + 2) = 2/3 (1 + 1)/(1 + 2) = 2/3 (0 + 1)/(1 + 2) = 1/3

V první části výpočtu je vždy počet dokumentů, ve kterých se slovo vyskytlo v dané třídě inkrementovaný o 1 a je dělen počtem všech dokumentů dané třídy inkrementovaný o konstantu – v tomto případě 2. Výpočet pro finální zařazení se provede následovně: Pˆ (c|d5 ) ∝ 3/4 · 4/5 · (1/5)2 · (1 − 2/5)3 ≈ 0.005 Pˆ (¯ c|d5 ) ∝ 1/4 · (2/3)3 · (1 − 1/3)3 ≈ 0.022 S použitím bernoulliho modelu by byl dokument zařazen do třídy „není recept“. 6.3.3

Vyhodnocení výsledků

Nejprve uvedu základní pojmy, které jsou důležité při vyhodnocování úspěšnosti klasifikátoru: True positives (dále jen TP) Počet dokumentů, které klasifikátor zařadí správně do „pozitivní“ třídy (např. spam je skutečně označen jako spam). True negatives (dále jen TN) Počet dokumentů, které klasifikátor zařadí správně do „negativní“ třídy (např. legitimní email je skutečně označen jako legitimní). False positives (dále jen FP) Počet dokumentů, které klasifikátor zařadí nesprávně do „pozitivní“ třídy (např. legitimní email je označen jako spam). False negatives (dále jen FN) Počet dokumentů, které klasifikátor zařadí nesprávně do „negativní“ třídy (např. spam je označen jako legitimní email). Pro interpretaci výsledků se pak používá několik měřítek: Precision (přesnost) Lze spočítat pomocí T P/(T P + F P ) Recall (pokrytí) Lze spočítat pomocí T P/(T P + F N ) 56

F-measure precision∗recall Lze spočítat pomocí precision a recall jako 2 ∗ precision+recall , zjednodušeně 2∗T P pak 2T P +F P +F N k-fold cross-validation Metoda, pomocí které se automaticky zkoumá přesnost klasifikátorů. Vstupní množina již ohodnocených dokumentů je rozdělena na k podmnožin. Následně se provede k testů a v každém z nich je bráno k − 1 podmnožin pro trénování klasifikátoru a jedna množina pro testování. Vyhodnotí se přesnost pro každý běh a výsledná přesnost se většinou sečte a dělí počtem k. Je ale vhodné sledovat i výsledky jednotlivých testovacích kol, protože můžeme narazit na případ, kdy se některý z pokusů výrazně liší od ostatních.

57

7

Dosažené výsledky

Vzhledem k tomu, že od doby zadání této diplomové práce uběhl delší čas a do distribucí se pomalu začíná dostávat další major verze KDE5, tak jsem vývoj aplikací uzpůsobil jinak. Nástroj pro správu restrikcí je sice přeportován pro KDE4 a funkční, ale další vývoj pro novou funkcionalitu jsem na něm nedělal a to z důvodu, že do KDE5 je v plánu umístit tuto aplikaci jako součást systému – vytvořit ho jako KCM (KConfig Modul) přímo do systémového nastavení tak, aby následně byla tato správa restrikcí dostupná už na čisté instalaci desktopového prostředí. Na základě předchozího jsem tedy místo dopracování nové funkcionality do nástroje KioskTool vytvořil dva samostatné nástroje, které navíc nejsou závislé na desktopovém prostředí a jejich struktura je rozdělena na dvě části tak, aby se do KCM musela posléze zanést jen logika nastavování, ale o samotné hlídání restrikcí se budou starat mnou vytvořené skripty. Bylo nutné vytvořit nástroj pro omezení přístupu k počítači na základě času a pro tento účel vznikla aplikace TimeKicker. Dále jsem vyzkoušel několik postupů pro klasifikaci HTML dokumentů a jeden z nich na základě dosažených výsledků pak implementoval do nástroje pro filtrování webového obsahu, nazvaný BanTheWeb. Vývoj probíhal v distribuci Fedora 21 s desktopovým prostředím KDE a pro testy na desktopovém prostředí UNITY jsem využíval distribuci Ubuntu 14.04. Aplikace jsou dostupné na GitHubu pod účtem mafrez. Aplikace KioskTool je psaná v jazyce C++, ostatní aplikace jsou psané v jazyku Python. V duchu programátorského kodexu KDE jsem hledal dostupné nástroje pro testování klasifikátorů a základ pro filtr webových stránek – tedy knihovnu pro proxyserver. Pro Python jsem našel veškeré potřebné nástroje.

7.1

Kiosk a KioskTool

Prvním krokem bylo projití dostupných restrikčních klíčů dle dokumentace a soupis těch, které jsou funkční pro KDE4, které jsou funkční jen částečně a které nejsou brány v potaz vůbec. Seznam klíčů je možné nalézt na mém blogu http://holomek.org/kiosk-keys. Záměrně neuvádím seznam restrikčních klíčů ani do přílohy této práce, protože v případě potřeby jsou dostupné online a díky tomu, že to je komunitní projekt a práce na něm nepřestává s odevzdáním této práce, tak se seznam bude upravovat a doplňovat i v budoucnu, aby byl aktuální. Podobné testování proběhlo i na KDE5, které ještě není plně dostupné, ale díky Danu Vrátilovi, který připravil testovací balíček KDE5 již pro Fedoru 21, bylo možné nové KDE5 testovat. Otázkou bylo, jak reagovat na zjištění nefunkčních klíčů, nebo klíčů, které fungovaly jen částečně. Nabízela se možnost použití bugzilly, ale vzhledem k tomu, že jsem našel na bugzille hlášené bugy o Kiosku staré několik let a nevyřešené, 58

tak jsem volil cestu komunikace po irc kanálu a to přímo přes #kde-devel. Proběhla komunikace s několika uživateli a hlavní informací pro mě bylo, že v tuto chvíli se samotnému Kiosku nikdo věnovat nechce a že by to chtělo, aby se někdo pustil do sepsání všech funkčních/nefunkčních věcí na Kiosku, z čehož by se udělal TODO list, který by sloužil jako výchozí bod pro vývojáře, co chyby opraví. Z vlastní iniciativy jsem tedy opravil sám věci, které byly podle mě do očí bijící, a to bylo použití klíčů pro ovládání hlavní menu nabídky kicker a kickoff. Problémem bylo, že Kiosk byl implementován pouze v jednom menu, takže v případě užití restrikcí stačilo přepnout z jednoho stylu menu do druhého a uživatel mohl akce využívat dál. Tím se dostáváme k tomu, že restrikce nejsou aplikovány na vrstvě samotného volání akcí, ale jedná se pouze o skrytí možnosti „prokliku“ v panelech, případná reakce na klávesovou zkratku. Lze tedy říct, že necháme-li zkušenému uživateli přístup k terminálu, restrikce může obejít. Terminál se ale Kioskem dá zablokovat také. Hledání nových klíčů probíhalo tak, že jsem vyhledal všechna místa ve zdrojových kódech KDE, kde byly použity metody popsané na začátku Kapitoly 5. Následně jsem vzal argumenty, se kterými tyto metody byly volány, a srovnal seznam se seznamem klíčů, které byly v dokumentaci. Tento test proběhl kvůli tomu, abychom zjistili, zda se začaly používat nové klíče, ale jejich implementaci nikdo nezanesl do dokumentace. Takových klíčů byly ale pouze jednotky. V souvislosti s menu kickoff a kicker mnou byly implementovány nové klíče pro ukázku možností Kiosku. Tyto klíče slouží pro vypnutí možností „Uspat do paměti“ a „Uspat na disk“. Klíče byly implementovány do poslední verze plasma-desktop 5.3 a její vývojová verze je také umístěná na GitHubu pod účtem mafrez. V release verzi 5.4 už toto nastavení bude dostupné pro všechny. Vzhledem ke stabilitě je na virtuálním PC na USB flash disku v příloze použito KDE4, aby bylo možné otestovat i ostatní nástroje. Tím, že jsem se začal o Kiosk zajímat a udělal tu část práce, do které se nikomu nechtělo (kompletní revize – soupis toho, co funguje, nefunguje a co se bude implementovat dál), tak jsem vytvořil správné prostředí pro další spolupráci s komunitou. Nyní se ozývají uživatelé, kteří mají zájem o práci na samotném Kiosku. Aplikace KioskTool Klíče frameworku Kiosk byly implementovány a restrikce šlo aplikovat v prostředí KDE3 pomocí aplikace s grafickým rozhraním. V KDE4 resp. KDE5 došlo k několika zásadním změnám, a proto bylo nutné KioskTool přeportovat pro novější verzi desktopového prostředí. Aplikaci je nyní možné bezproblémově nainstalovat do KDE4. Aplikace si sama o sobě neukládá žádná statická data, pouze vyčítá potřebné profily z konfiguračních souborů. Při spuštění se aplikace podívá na seznam uživatelů a skupin 59

v počítači, následně přečte z konfiguračních souborů, který uživatel má přiřazený jaký profil a tato data zobrazí. Profily je možné editovat, mazat a vytvářet nové. Samozřejmostí je přiřazení profilu uživateli nebo celé skupině uživatelů. Nosnou částí aplikace je samotné nastavování profilu, které se děje na základě seznamu klíčů.

Obrázek 12: Aplikace KioskTool – port pro KDE4 Tím, že aplikace pro nastavení možných klíčů používá své vlastní konfigurační soubory, tak je snadné této aplikaci „předat“ seznam nových klíčů. To se hodí v případě, že by framework Kiosk chtěly podporovat i jiné aplikace než vestavěné v samotném desktopovém prostředí. Stačí, když se při jejich instalaci nakopíruje soubor *.kiosk do konfigurační složky aplikace KioskTool. Jelikož záleží na tom, kde je aplikace KioskTool nainstalovaná, tak jsem vytvořil skript, který projde složky nainstalovaných aplikací, a v případě, že u některé najde soubor *.kiosk, tak jej zkopíruje do složky KioskToolu, čímž se zařídí, že KioskTool bude schopný aplikovat restrikce, které se uloží do konfiguračních souborů KDE a podporované aplikace pak na tyto restrikce budou schopné reagovat. Vzhledem k tomu, že implementace KioskToolu pro KDE5 je nyní součástí „Google Summer of Code 2015“, tak jsem na přeportování samotné aplikace jako KCM modulu pro KDE5 nepracoval. Pro potřeby testování lze nastavovat restrikce pro účet, na kterém je uživatel aktuálně přihlášen a změny pozorovat díky restartu desktopového prostředí (přesný návod je v README na USB flash disku u aplikace KioskTool), nebo nastavovat restrikce jinému účtu a do toho se následně přihlásit. Ve verzi KDE 60

na virtuálním stroji se objevuje při zapnutí nástroje chyba, kdy je vyžadován přístup do KDE Wallet Manager. Jedná se o chybu KDE, ne přímo aplikace KioskTool, a bude v dalších verzích KDE odstraněna.

7.2

Aplikace TimeKicker

Pro rozšíření rodičovského módu jsem vytvořil aplikaci s názvem TimeKicker – restrikce uživatelů u počítače dle času. Návrh aplikace umožňuje její použití i pro jiné desktopové prostředí než jen KDE. Je to možné díky rozdělení aplikace na několik modulů. Aplikace je napsaná v jazyku Python, konkrétně verze 2.7. Ke svému fungování kromě standardních knihoven potřebuje pouze knihovnu PyQt, která se stará o vykreslení grafických komponent aplikace. Hlavní část je stejná pro všechny distribuce Linuxu a desktopová prostředí – jedná se o GUI celé aplikace a způsob, kterým si vyčítá ze systému seznam uživatelů a provádí úpravu jejich nastavení. Pro vyčtení jednotlivých uživatelských účtů, skupin, vazeb mezi nimi aj. se používají moduly pwd a grp. Pro běh aplikace je důležité znát jen UID (systémové ID uživatele) a GID (systémové ID skupiny uživatelů). Ostatní data o uživatelích si aplikace vyčítá jen v případě nastavování přes grafické rozhraní, ale nejsou uložená staticky. Tím je aplikace schopna správně reagovat na změnu informací o uživateli.

Obrázek 13: Aplikace TimeKicker – nastavení profilu Pro načítání a ukládání statických dat je použit modul pickle, který dokáže ukládat datové struktury do textových souborů. V tomto případě se nejedná o velký objem dat a pickle je dostupný už v základní instalaci Pythonu. Pro ukládání dat se využívá datová struktura slovník, jež má tři hlavní části – profily, 61

uživatelské nastavení a skupinové nastavení. V nastavení jsou uložené vazby mezi ID profilu a ID uživatele, resp. skupiny uživatelů. V profilech jsou jednotlivé profily včetně detailního nastavení. Uvedený hlavní pickle soubor s nastavením se nachází ve složce s aplikací. Aplikuje se nastavení tzv. efektivního profilu. Pokud má uživatel přiřazen profil přímo ke svému UID, používá se právě ten. Pokud uživatel nemá přiřazen profil ke svému UID, ale je přiřazen k GID (do které patří), tak se jako efektivní profil projeví ten z jeho skupiny. Druhou částí aplikace je skript spouštějící se po přihlášení do systému. Jelikož se počítá s určitou gramotností administrátora systému, tak vkládání tohoto skriptu do položek „spuštění po startu“ je na něm. Šlo by to samozřejmě udělat automaticky v aplikaci TimeKicker, ale vzhledem ke změnám v jednotlivých verzích KDE se fyzické umístění složky, kam se skripty ukládají, měnilo, a tak jsem vzhledem k obecnosti nechal tento úkon na administrátorovi systému. Aby bylo možné kontrolovat nastavení restrikcí, zapisovat statistiky a zároveň byla zaručená bezpečnost aplikace proti napadení nebo vypnutí, tak je třeba nastavit spouštěcímu souboru SUID a správná práva. To lze provést pomocí příkazu chmod a hodnoty 4711. Tím zajistíme, že soubor může kdokoliv pouze spustit a skript poběží s právy vlastníka souboru. Tento spuštěný proces může přistupovat následně k nastavením restrikcí, zapisovat statistiky a zároveň ho obyčejný uživatel nemůže vypnout, protože k tomu nemá dostatečné oprávnění. Instalace, umístění v systému a bližší specifikace jsou popsány na konci kapitoly 7.3. Aplikace se spustí po přihlášení do systému, vyčte aktuální nastavení a podle toho se rozhoduje, jak bude pokračovat dál. Nejdříve se provede kontrola, zda se uživatel vůbec může přihlásit, následně pokud je pro dnešní den nastavený omezující čas a pokud ano, tak kolik z tohoto limitu již dnes využil. Pokud vše vyhovuje, tak dojde k úspěšnému přihlášení. Následně aplikace zobrazuje uživateli systémové hlášení o tom, kolik mu ještě zbývá času, a to je právě věc, která je závislá na použitém desktopovém prostředí společně s příkazem pro odhlášení. Proto je potřeba využít skript startup.py dle cílového desktopového prostředí. V rámci diplomové práce jsem vytvořil univerzální skript pro KDE4/KDE5 a UNITY. Pro notifikace uživateli se používá příkaz notify-send, pro odhlášení pkill. Oba tyto příkazy jsou dostupné jak v prostředí KDE tak UNITY.

Obrázek 14: Aplikace TimeKicker – notification v KDE4

62

7.3

Filtr obsahu webových stránek

Abychom mohli zkonstruovat samotný filtr webových stránek, je třeba nejdříve zvolit způsob, kterým budeme dolovat data z HTML dokumentů, jak je budeme upravovat a který klasifikátor následně použijeme. Pro dolování relevantních dat, která jsou směrodatná při klasifikaci HTML dokumentů, neexistuje unifikovaný přístup, a proto jsem navrhl postup, na který budeme následně aplikovat způsob klasifikace popsaný v Kapitole 6 – tedy lemmatizaci, stemming, stopslova a klasifikátor. Cílem je najít takový postup, který bude úspěšný v klasifikaci HTML dokumentů do kategorií a zároveň její výpočet nebude časově ani paměťově příliš náročný, protože při procházení webových stránek nemůžeme HTML stránku analyzovat v řádu sekund. Veškeré testy jsou zaměřené pro nalezení binárního klasifikátoru, jehož výsledkem bude odpověď na otázku „lze stránku zobrazit uživateli?“. Jak už jsem zmínil výše, jako implementační jazyk jsem si vybral Python, protože pro něj existuje několik vhodných knihoven pro strojové učení. Tyto knihovny jsou navíc multiplatformní, takže se dá říct, že aplikace poběží všude tam, kde je nainstalovaný interpret jazyka Python 2.7 a k němu jsou doinstalované potřebné knihovny. Pro samotné stahování dat se používá urllib2, která je dostupná v základní instalaci Pythonu. Pro parsování HTML se používá knihovna BeautifulSoup4 a lxml. Pro klasifikátor se používá knihovna scikit-learn. Tyto tři knihovny je nutné doinstalovat pro běh programu. Samotný filtr bude realizovaný jako aplikační proxy server s využitím knihovny mitmproxy, který dle výsledků analýz bude mít v sobě zabudovaný nejefektivnější z nalezených klasifikátorů. Klasifikaci dokumentů omezíme pouze na anglické texty, ale celý postup se dá aplikovat i na texty v jiném jazyku. Důvod omezení pouze na anglické stránky je díky tomu, že to je nejpoužívanější jazyk mezi webovými stránkami a tvoří více jak polovinu obsahu všech webů. V žebříčku na druhém místě dle [23] je ruština s necelými šesti procenty, takže rozdíly jsou skutečně propastné. Sběr dat Pro vytvoření trénovacího corpusu jsem použil databázi URL adres z [24], které byly v minulosti označeny nálepkou „Obsah pro dospělé“. Jelikož je databáze udržována pouze tak, že se do ni URL vloží a dále se nekontroluje, zda je stále aktivní, nebo je její obsah již jiný, tak jsem napsal funkci, která odfiltrovala část dat, které by mohly negativně ovlivnit trénovací corpus. Tento algoritmus postupně prošel všechny stránky a v případě, že suffix domény odpovídal uvažovaným pro filtraci (au, uk, us, com, info, net, org) a stránka ještě byla aktivní (návratový kód 200), tak se provedla její analýza. V analýze jsem kontroloval text obsažený na webu, abych odfiltroval stránky v jiném jazyku než angličtina a stránky, které už neobsahovaly závadný obsah – většinou to byly domény, které byly na prodej. Ze stejného zdroje jsem použil i databázi adres 63

pro cestování, nákupy aj., což mi sloužilo jako druhá množina webových stránek – tedy ty legitimní k zobrazení. Postup při vyhodnocování klasifikátoru V následujících částech jsou provedeny testy na HTML dokumentech a pokaždé je používán stejný postup pro výběr tokenů. Neuvažuje se velikost písmen. Text je převáděn na malá písmena, protože v hodnocení obsahu HTML dokumentů velikost písmen nehraje velkou roli a pouze by tím rostla velikost slovníku. Za token se považuje takový řetězec, který je složen pouze z písmen, číslic a jeho minimální délka je 3 znaky. Číslice jsou uvažovány kvůli praktikám některých webů s nevhodným obsahem, kde se snaží obejít filtry použitím např. číslice 0 místo písmena o. Příkladem může být slovo c0ck. Dále se při vyhodnocení používá anglický seznam stopslov, lemmatizátor z knihovny NLTK a takto upravená data jsou následně převáděna do podoby, která se hodí na vstup klasifikátorů. V převádění na vstup klasifikátoru se používá DF, CF i TFIDF (přesný popis v Kapitole 6.2). Pro samotnou reprezentaci dokumentů byl zvolen modul Numpy. Numpy je základní Python knihovna pro práci s numerickými daty, konkrétně s 1 až nrozměrnými maticemi. Implementace je z velké části napsána v C a Fortranu a používá BLAS knihovny. Numpy tak umožňuje pracovat s numerickými daty ve stylu Python kontejnerů a zároveň zachovat rychlost kompilovaných jazyků. Více o Numpy lze najít na http://www.numpy.org/. Následně se data zpracují příslušným klasifikátorem a to buď Naivní Bayesovský – Multinomiální model (ve statistikách zkráceno na NB–M) nebo Naivní Bayesovský – Bernoulliho model (ve statistikách zkráceno na NB–B) nebo Support Vector machine (ve statistikách zkráceno na SVM). Zároveň je všude kromě úspěšnosti klasifikátoru uvedena i časová náročnost samotné klasifikace. Na základě testů jsem pro trénování klasifikátoru zvolil množinu 100 dokumentů z každé třídy. Samotná klasifikace probíhala na 1500 stránkách s pornografickým obsahem a na 1500 stránkách s normálním obsahem. Test probíhal pomocí upravené metody k-fold regression, popsané v Kapitole 6.3.3. Jako k byla zvolena 3. Klasifikace HTML dokumentů bez úprav Aby bylo možné zjišťovat posun v úspěšnosti jednotlivých řešení, vyzkoušel jsem nejdříve aplikovat postup klasifikace na nijak neupravený HTML dokument, tedy i se strukturálními značkami. Úspěšnost a časová náročnost klasifikátorů se nacházejí v Tabulce 6. Velikost slovníku dosáhla na 37 016 položek. Problémem je, že se pro vyhodnocování berou i veškeré strukturální značky jako je img, ref aj., což vede k chybné klasifikaci u velkého počtu dokumentů.

64

NB–M CF NB–M TFDIF NB–B DF SVM CF SVM TFIDF

TP/% 88.26 89.81 82.95 79.25 86.7

FP/% 11.74 10.19 17.05 20.75 13.3

TN/% 95.27 85.47 100.0 84.93 91.87

FN/% 4.73 14.53 0.0 15.07 8.13

F-measure/% 91.47 87.90 90.68 81.57 89.00

Čas/s 29.43 30.38 61.17 79.63 66.01

Tabulka 6: Procentuální úspěšnost a doba běhu klasifikátorů na nezpracovaných dokumentech Klasifikace probíhá příliš dlouho a je vidět, že metoda SVM má oproti Bayesovskému klasifikátoru na těchto datech problém s výkonem. Úspěšnost Bernoulliho modelu na legitimních dokumentech je daná jeho návrhem, ale u pornografických dokumentů je výkon naopak mnohem nižší než u Multinomiálního modelu. My hledáme co nejvyšší míru TP. Pro filtr webového obsahu je nejdůležitější tato metrika, protože je mnohem důležitější zachytit co možná nejvíce dokumentů s pornografickým obsahem i za cenu chybného označení některých dokumentů s legitimním obsahem. Dalším jednoduchým způsobem je použití pro klasifikaci pouze viditelného textu. Úspěšnost a časová náročnost klasifikátorů se nacházejí v Tabulce 7. Velikost slovníku dosáhla na 13 343 položek.

NB–M CF NB–M TFDIF NB–B DF SVM CF SVM TFIDF

TP/% 95.8 97.13 83.87 91.6 93.33

FP/% 4.2 2.87 16.13 8.4 6.67

TN/% 97.6 93.47 100.0 94.8 98.47

FN/% 2.4 6.53 0.0 5.2 1.53

F-measure/% 96.67 95.38 91.23 93.09 95.79

Čas/s 3.41 3.43 3.4 3.57 3.45

Tabulka 7: Procentuální úspěšnost a doba běhu klasifikátorů na viditelném textu Až na TP u Bernoulliho modelu došlo k významnému zlepšení a hlavně oproti předchozímu testu klasifikátory běžely mnohem kratší dobu. Výkonnostní problém mezi SVM a NB nebyl na těchto datech znát. SVM je pomalejší metoda v případě, že je příznakový vektor příliš velký. U použití pouze viditelného textu přicházíme o mnoho cenných dat, na základě kterých můžeme stránky hodnotit, a proto je potřeba najít způsob, jak z HTML stránky extrahovat směrodatná data. Použití stemmingu a n-gramů nebylo v těchto testech uvažováno.

65

Předzpracování dokumentu Namísto toho, abychom vybrali z HTML dokumentu pouze viditelný text, uděláme hlubší datamining a k jednotlivým slovům přidáme ještě jejich umístění – dodáme tím textově sémantickou informaci, kde se slovo nacházelo. Tato myšlenka byla prvotně uvedena v [25], kdy se tento způsob používal pro hodnocení spamu. Sémantická informace se dodávala kvůli tomu, že některá slova měla mít jinou váhu pro klasifikaci, pokud se vyskytla v předmětu emailu. Jelikož se mimo studium věnuji SEO (optimalizace pro vyhledávače), tak jsem při procházení webových stránek s pornografií přišel na několik poznatků, které se dají aplikovat pro extrahování relevantních dat. Před hledáním samotných slov odstraníme z dokumentu vložené javascript kódy, styly z hlavičky, inline styly z tagů a komentáře. Tím se zbavíme často velké části dat, které při klasifikaci dokumentů nepotřebujeme. Extrahovaní dat se provádí z hlavičky, konkrétně z tagů title, meta - description, meta - keywords a z těla dokumentu se vyčítají všechny tagy, které v sobě obsahují položky alt nebo title a nadpisy H1 - H6. K tomu se přidá viditelný text. Sice se nám zvětší samotný slovník, ale přesnost klasifikace se zvětší také. Tento postup nám pomůže, protože i když se web snaží maskovat, že se na něm pornografie nevyskytuje (některé video servery) – vulgární výrazy nejsou uvedeny ve viditelném textu, tak ve skrytém většinou jsou. Důvod je užívání tzv. blackhat SEO pro to, aby byl web dobře dohledatelný přes vyhledávače. Pokud aplikujeme přidání sémantiky k jednotlivým slovům podle toho, kde se nacházejí, tak Kód 21 se přepíše na řetězec „CFKWporn CFKWsex“. Tím i v klasifikátoru budeme mít stále informaci, kde se vlastní slovo na webové stránce vyskytovalo. Tento postup je vhodný díky tomu, že slovo „porn“, které se vyskytne v klíčových slovech by mělo nabývat určitě větší váhy, než když se jednorázově vyskytne někde v textu. <meta name="keywords" content="porn, sex">

Zdrojový kód 21: Obsah meta tagu keywords Úspěšnost a časová náročnost klasifikátorů takto předzpracovaného textu se nacházejí v Tabulce 8. Velikost slovníku dosáhla na 20 114 položek. Dle výsledných hodnot jsem se rozhodl, že v nástroji pro filtrování obsahu webových stránek použiji Multinomiální model naivního Bayesovského klasifikátoru s použitím TFIDF pro výběr vah slov. Další optimalizace Na základě dalšího výzkumu výkonnosti s použitím stopslov, n-gramů a lemmatizace jsem došel k závěru, že budu používat pouze stopslova. 66

NB–M CF NB–M TFDIF NB–B DF SVM CF SVM TFIDF

TP/% 96.33 98.4 84.8 94.33 94.6

FP/% 3.67 1.6 15.2 5.67 5.4

TN/% 98.2 96.07 100.0 96.53 99.0

FN/% 1.8 3.93 0.0 3.47 1.0

F-measure/% 97.24 97.27 91.77 95.38 96.73

Čas/s 4.35 4.37 4.41 4.6 4.45

Tabulka 8: Procentuální úspěšnost a doba běhu klasifikátorů na extrahovaném obsahu Lemmatizace je proces, který celou klasifikaci v průměrném případě desetkrát zpomalí a zlepšení se pohybuje max. o 0.4 %. V případě použití n-gramů bylo zjištěno, že pro klasifikaci webového obsahu jsou unigramy důležité a při použití pouze digramů dochází k výraznému snížení přesnosti klasifikátoru (5 – 10%). Při použití unigramů i digramů se přesnost zvyšuje pouze napatrně (0.1 – 0.3%), ale čas klasifikace roste v průměrném případě na trojnásobek doby hodnocení samotných unigramů. Užitím stopslov zmenšíme velikost slovníku a výsledná klasifikace probíhá přesněji. Časový nárůst samotné klasifikace je cca 10%. Ve výsledné aplikaci, kde se bude hodnotit vždy jen stahovaný dokument, je toto nepatrné zpomalení, a proto se stopslova budou využívat v aplikaci pro hodnocení webového obsahu. Při použití stopslov se zmenšil slovník na 19 863 položek. Nejpoužívanější slova Dle statistik přikládám 12 slov, které v trénovacím corpusu měly největší váhu pro výsledné zařazení stránky do kategorie pornografie: porn, amateur, sex, teen, hot, free, videos, pussy, big, girl, fucked, gets BanTheWeb Aplikace BanTheWeb využívá podobné grafické rozhraní jako aplikace TimeKicker – využívá její celou správu profilů pro uživatelské účty. Liší se jen samotné nastavení profilů. V aplikaci je na základě předchozích výsledků implementovaný Multinomiální model naivního Bayesovského klasifikátoru, který určuje váhy pomocí TFIDF s využitím stopslov z anglického jazyku. Nástroj pro filtrování je implementovaný jako lokální proxy s využitím knihovny mitmproxy. Aplikace umožňuje nastavit restrikce pro časové omezení přístupu uživatele na web. Opět lze nastavit jak čas, kdy lze na web přistupovat, tak jak dlouho tuto službu smí uživatel denně využívat. Čas přistupování k webu je počítán v minutových intervalech – pokud nedošlo ke komunikaci s proxy během poslední minuty (ne interval 60 sekund, ale minuta ve smyslu čítače na hodinách), tak je doba používání přístupu na web inkrementována o 1 a tato hodnota je následně 67

porovnávána s nastaveným limitem. Nastavení je limitující pro případ, že v prohlížeči zůstanou webové stránky, které si na pozadí volají skripty pro další data. Uživatel sám nemusí být na webu aktivní a přesto je mu z nastaveného limitu čas odebírán. Aplikace podporuje nastavení režimu bezpečného hledání pro vyhledávač googlu. Je to možné díky nastavení už na síťové vrstvě, kdy jakýkoliv požadavek na server google.com, případně jinou jazykovou mutaci, je přesměrován přes doménu forcesafesearch.google.com. Můžeme tak zamezit hledání nevhodného obsahu i v případě, kdy se uživatel přihlásí do svého účtu na google.com a komunikace probíhá přes HTTPS. Tato restrikce se uloží při prvním přesměrování požadavku do cookie, a proto je nutné v případě vypnutí „bezpečného vyhledávání“ vymazat soubor cookie, nebo restartovat webový prohlížeč. Některé prohlížeče kontrolují certifikáty přísněji a pokud webový server vyžaduje HTTP Strict Transport Security (HSTS) pro určení, zda se má prohlížeč připojovat pouze zabezpečeně, tak není možné přidat pro tento certifikát výjimku. Aby proxyserver mohl bez problémů procházet i HTTPS provoz, tak je potřeba do prohlížeče přidat certifikát vlastní certifikační autority, která je umístěna v proxyserveru. Díky tomu je pak sice schopna proxy filtrovat veškerý HTTPS provoz, ale v případě použití filtru pro přístup dětí na web je toto chování chtěné. Je na administrátorovi systému, zda tento certifikát do prohlížeče vloží nebo ne – činí se tak přístupem na doménu mitm.it, kdy proxy tento požadavek přeloží jako žádost o přidání certifikátu a vyvolá dialogové okno pro jeho přidání. Omezení vyhledávačů umožňuje zakázat jiné vyhledávače než je Google. Implementovaný je seznam prohlížečů dle [6]. Omezení sociálních sítě umožňuje zakázat přístup uživateli na weby s označením sociální síť: podporované jsou v tuto chvílí Google+, Facebook, Twitter, Tumblr, Linkedin, Instagram, Friendster a MySpace. Do budoucna bude toto nastavení doplněno o možnost limitovat uživateli čas strávený na sociálních sítích. Řešení tohoto problému není jednoduché díky tomu, že mnoho webů používá API sociálních sítí pro komentáře, „To se mi líbí“ aj. Implementace BL a WL počítá s doménou přidaného webu, aby bylo možné filtrovat veškeré subdomény, případně všechny webové stránky nacházející se na dané adrese. Do budoucna toto nastavení bude rozšířeno o „wildcard“ zápis, aby se dalo přesně definovat, zda se mají zakázat/povolit jen subdomény, stránky na hlavní doméně, nebo jen jedna samotná URL. Skrytí závadného obsahu funguje na základě předdefinovaného seznamu nevhodných slov a jeho nahrazování v HTML obsahu. Slova jsou následně na stránce nahrazena za řetězec "***". Omezení obsahu pro dospělé je implementace klasifikátoru HTML dokumentů. V tuto chvílí se klasifikuje pouze pornografický obsah, ale konstrukce je koncipována tak, aby změnou vstupních dat mohlo dojít k rozšíření tohoto řešení. 68

Obrázek 15: Aplikace BanTheWeb – nastavení profilu Dalším rozšířením bude interakce s uživatelem na blokované stránky, případně na překročení limitu. Při testování nástroje jsem narazil na stránky, které klasifikátor nebyl schopný odhalit, jednalo se o stránky s tématikou „shemale“, kde se jako alternativa k tomuto slovu často používalo synonymum „bananaboy“. Ke špatné klasifikaci došlo kvůli tomu, že stránky s podobnou tématikou nejsou v trénovacím corpusu, a tak je klasifikátor nemohl odhalit, protože i zbytek textu nenapovídá obsahu klasické stránky s pornografickým obsahem. Pokud bychom ale takový dokument použili pro trénovací corpus, tak by jeho odhalení následně bylo jednoduché, protože slovo jako „shemale“ se v trénovacím corpusu legitimních stránek nevyskytuje. Aby bylo možné filtrovat veškerý provoz, je třeba nastavit proxy globálně pro celý systém. V případě KDE se jedná o KCM modul Proxy. V případě GNOME/UNITY se toto nastavení provádí v nastavení sítě. V KDE toto nastavení bohužel není chráněno heslem, jako tomu je v GNOME/UNITY. V rámci diplomové práce jsem vznesl požadavek na mailinglist kdedevel, aby se toto nastavení doimplementovalo i do KDE. Prozatím se v KDE vynucení proxy provádí tak, že po nastavení příslušných hodnot se provede zamknutí KCM modulu přes framework KIOSK. To se provede umístěním klíče 22 do konfiguračního souboru .kdeglobals. Až vývojářský tým KDE doimplementuje změnu nastavení proxy chráněnou heslem, tak toto nastavení již nebude nutné provádět. Není-li obsah stránky dostatečně velký pro testování (zvolena byla hranice 50 slov), tak se na webovou stránku vkládá upozornění, že klasifikátor nemohl 69

[KDE Control Module Restrictions][$i] proxy.desktop=false

Zdrojový kód 22: Kiosk - Zákaz editace proxy

automaticky rozpoznat její obsah. Stránka je uložena na tzv. „greylist“ a administrátor pak vidí v administraci aplikace přehled těchto stránek a může se sám rozhodnout, zda takovou stránku zařadí na BL nebo WL. Takto jsou hodnocené webové stránky jako je např. www.nasa.gov, jejichž obsah je vytvářen až v prohlížeči, po načtení stránky, pomocí volání javascriptových funkcí na pozadí. Aplikace dále obsahuje možnost dotrénování klasifikátoru a přehled statistik s možností filtrace podle uživatele nebo období. Přímo ze statistik lze i stránky umístit do globálního WL nebo BL, případně dotrénovat samotný klasifikátor. Ve statistikách se objevují i stránky, které nebyly analýzou hodnoceny – buď se jedná o stránky z WL nebo se jedná o stránky, jejichž obsah byl menší jak 10 slov (externí zdroje reklam, javascript soubory načítané s hlavičkou „Content-Type: text/ html“ aj.). V případě, že uživatel přistoupí na adresu, kam nemá přístup, popříp. se snaží dostat na web ve chvíli, kdy jej má mít omezen, tak se mu jako cílová stránka zobrazí HTML dokument s upozorněním, že na takový požadavek nemá nárok a co má dělat dál.

Obrázek 16: Upozornění uživatele na neoprávněný přístup

Instalace aplikací Jak aplikace TimeKicker, tak aplikace BanTheWeb mají vytvořený instalační balíček, který se vždy skládá z BASH skriptu a archivu ve formátu tar.gz, který obsahuje potřebné soubory. Instalační skript je nutné spouštět s právy uživatele root, neboť obsah se kopíruje do složky /usr/local/share/app_name, kam se uloží všechny zdrojové soubory. Následně se ještě využívá složka, kam 70

se uloží spouštěcí aplikace – /usr/local/bin. Vlastnická práva jsou přičtena uživateli root. Jelikož v některých desktopových prostředích, jako je např. KDE, je z bezpečnostního hlediska nefunkční použití SUID nad skripty, tak jsem napsal jednoduché jednorázové aplikace v jazyce C, které udělají tzv. „wrapper“ a pouze spustí skript s příslušnými právy. Aby nebylo nutné „wrapper“ při instalaci překládat, tak jsem do instalačního balíčku přeložil aplikaci jak na 32bitovém, tak 64bitovém systému. Při instalaci si BASH skript zjišťuje přes uname -m, o jakou se jedná architekturu, a na základě toho kopíruje do systému příslušný soubor. V případě, že by aplikace na cílovém systému nefungovala, tak jsou v instalačním balíčku přiloženy i zdrojové kódy jednotlivých aplikací. Umístěním aplikací do /usr/local/bin docílíme toho, že je možné aplikace spouštět odkudkoliv. Administrátorská část aplikací potřebuje ke svému spuštění práva uživatele root. Jelikož některé distribuce linuxu nepodoporují přístup příkazu sudo do cesty /usr/local/bin, tak je potřeba v takovém případě upravit cestu pro tento příkaz. To lze učinit přes sudo visudo. V případě, že administrátor chce pro uživatele aplikovat restrikce, je třeba umístit do jeho aplikací po startu příkaz TimeKickerStartup popříp. příkaz BanTheWebStartup. Je nutné pří zadávání uložit desktopový soubor s vlastnickými právy uživatele root, aby si uživatel nemohl sám soubor smazat a tím restrikce vypnout. Vše je detailně popsané v README na přiloženém USB flash disku i s ukázkou desktopových souborů.

71

Závěr Hlavním cílem této práce bylo vzkříšení projektu Kiosk a doplnění tohoto frameworku pro rodičovský mód o novou funkcionalitu. Proběhla revize restrikčních klíčů umožňující nastavení jednotlivých omezení. Část nefunkčních klíčů byla opravena vlastními silami, na části pracuje komunita KDE, která k tomuto vývoji neodmyslitelně patří. Navrhnul jsem nové klíče, které jsem sám implementoval do desktopového prostředí KDE5. Aplikace KioskTool byla přeportována pro prostředí KDE4. Pro aktuálně nastupující prostředí KDE5 se bude aplikace implementovat jako součást celého prostředí. Užití klasifikátorů pro nezpracované HTML dokumenty se ukázalo jako nereálné řešení vzhledem k časovým nárokům samotné klasifikace a její úspěšnosti. Metoda SVM na těchto dokumentech vykazovala oproti ostatním modelům významný výkonnostní problém vzhledem k velikosti vektoru příznaků. Braní v potaz pouze viditelného textu webové stránky klasifikaci významně zrychlilo a výkonnostní rozdíly mezi modely se srovnaly, ale úspěšnost nebyla ještě dostačující. Pro dokumenty tedy byla napsaná funkce na extrahování relevantního obsahu, což zpřesnilo samotnou klasifikaci. Pro nástroj filtrování webového obsahu byl nakonec vybrán Multinomiální model naivního Bayesovského klasifikátoru s využitím TFIDF. Rodičovský mód KDE byl doplněn o 2 aplikace. První z nich umožňuje omezovat přihlášení uživatele do systému a čas strávený v něm. Druhou aplikací je filtr webového obsahu, do nějž byl zapracován vybraný klasifikátor. Oba nástroje jsou koncipované pro fungování na Linuxu obecně, ne jen v desktopovém prostředí KDE. Na těchto nástrojích budu dále pracovat a momentálně připravuji na svém serveru rozhraní s webovými službami, aby samotný klasifikátor obsahu byl na jednom místě a filtrovací aplikace umístěná v počítači s ním mohla komunikovat přes internet. Webová služba bude volně přístupná, takže ji budou moci využívat i jiné aplikace. Výhodou takového řešení bude sběr statistik a možnosti zpřesňování klasifikace na základě uživatelské odezvy. Dále plánuji vydání článku v anglickém jazyce, jehož obsahem bude sumarizace a porovnání podpory rodičovské kontroly na různých platformách. Sumarizaci jsem provedl v rámci této práce, aby se začalo více mluvit o slabých stránkách jednotlivých řešení a aby byly opraveny.

72

Conclusions The main aim of this thesis was the “resurrection” of Kiosk project and addition of new functionality to the framework for parental mode. There was a revision of the restriction keys done allowing to set up the limitations. A part of the dysfunctional keys was fixed on my own and part is being worked on by KDE community which belongs inseparably to this development model. I designed new keys which were implemented into the desktop environment of KDE5 by myself. The KioskTool application was ported for KDE4 environment. The application will be implemented as part of the desktop workspace for the upcoming KDE5. Using document classification for raw HTML documents showed as an unacceptable solution according to the time consumption and precision of classification process. SVM classifier on these documents was much worse than other classifiers and this was because of size of feature vector. Another step was classification based on visible text from HTML documents. Classification process was much faster in every classifier, but precision was not still acceptable. A function for extracting relevant content from the documents for their classification was written by myself and this improoved precision for document classification. Newly developed web filtering application is based on Multinomial model of Naive Bayes classifier with using of TFIDF. Two applications were added to the parental mode of KDE. The first of them allows to restrict the user log in into the system and the time spent in it. The second application is a filter of web page content, in which was incorporated selected classifier. Both tools are designed to function in Linux in general, not only in the KDE. I will continue to work on the development of the tools that were newly created for the parental mode. I am currently preparing interfaces with web services on my server. It will be done the way that the code of the classifier itself will be on one place and the filtering application located in the computer locally would be able to communicate with it via the Internet. The Web service will be freely accessible, so that it can be used by other applications. The advantage of such a solution will be to collect statistics and options of refining classification based on user feedback. Next I am planning to release an article in the English language, which will contain summaries and comparisons of the parental controls support on various platforms. I worked on the summarization within this thesis, that more people will start to talk about the weak sides of each solution and then they should be corrected.

73

A

Obsah přiloženého USB flash disku

bin/ Instrukce pro spuštění programů KioskTool, TimeKicker a BanTheWeb. doc/ Text práce ve formátu PDF, soubory potřebné pro vygenerování PDF dokumentu textu (v ZIP archivu) src/ Kompletní zdrojové texty programů KioskTool, TimeKicker a BanTheWeb virtualpc/ Appliance systému Fedora 21 s desktopovým prostředím KDE4. readme.txt Instrukce pro instalaci a spuštění programů KioskTool, TimeKicker a BanTheWeb, včetně všech požadavků pro jejich bezproblémový provoz. Dále je obsažen návod na spuštění Virtuálního stroje, kde jsou všechny programy předinstalované a připravené k otestování. Navíc USB flash disk obsahuje: data/ Ukázková a testovací data použitá v práci a pro potřeby testování práce. install/ Zdrojové kódy hlavních knihoven potřebných pro provoz programů KioskTool, TimeKicker a BanTheWeb, které nejsou standardní součástí operačního systému určeného pro běh programů.

74

Seznam zkratek API Application Programming Interface BL Black list CA Certifikační autorita CF Collection frequency DF Document frequency FN False negatives FP False positives GPS Global Positioning System GUI Graphical User Interface KCM KConfig Module KDE Common Desktop Environment MITM Man In The Middle OS Operační systém PAM Pluggable Authentication Modules PICS Platform for Internet Content Selection POWDER Protocol for Web Description Resources RTA Restricted To Adults TFIDF Term frequency - Inverse document frequency TN True negatives TP True positives WL White list

75

Literatura [1] MANNING, Christopher D.; RAGHAVAN, Prabhakar; SCHÜTZE, Hinrich. Introduction to Information Retrieval. New York, NY, USA: Cambridge University Press, 2008. ISBN 0521865719, 9780521865715. [2] STREBE, Matthew; PERKINS, Charles. Firewally a proxy-servery. First. Brno: Computer Press, 2003. 472 s. ISBN 80-7226-983-6. [3] W3C. Platform for Internet Content Selection. 2015. Dostupný z: hwww.w3.org/PICS/i. [4] ASACP. Restricted To Adults rating. 2015. Dostupný z: hwww.rtalabel.org/i. [5] Discover Top Porn Sites! 2015. Dostupný z: hwww.theporndude.comi. [6] EBIZMBA. Top 15 Most Popular Search Engines | April 2015. 2015. Dostupný z: hwww.ebizmba.com/articles/search-enginesi. [7] STATISTICS, OS Platform. W3Schools. 2015. Dostupný z: hwww.w3schools.com/browsers/browsers_os.aspi. [8] KOTAKU. How The UK Video Game Age Rating System Works. 2015. Dostupný z: hwww.kotaku.co.uk/2015/01/13/uk-video-game-age-rating-system-works-doesnti. [9] BREWIS, Marie. How to set up parental control on Android: restrict Android app permissions . 2015. Dostupný z: hwww.pcadvisor.co.uk/how-to/google-android/3461359/parentalcontrol-on-android/i. [10] TOPTENREVIEWS. Parental Software Review. 2015. Dostupný z: hhttp://parentalsoftware-review.toptenreviews.comi. [11] SYSTEMS, Blue Coat. K9 Web Protection. 2015. Dostupný z: hwww.k9webprotection.com/i.

[12] WEBMASTERS, KDE. About KDE. 2015. Dostupný z: hwww.kde.org/community/whatiskde/i. [13] REDHAT, Inc. Meet our spins. 2015. Dostupný z: hhttp://spins.fedoraproject.org/en/i. [14] Framework. 2015. Dostupný z: hhttp://cs.wikipedia.org/wiki/Frameworki. [15] COMMUNITY, KDE. KDE System Administration/Kiosk/Introduction. 2015. Dostupný z: hhttps://techbase.kde.org/KDE_System_Administration/Kiosk/Introductioni. [16] COMMUNITY, KDE. KDE System Administration/Kiosk/Keys. 2015. Dostupný z: hhttps://techbase.kde.org/KDE_System_Administration/Kiosk/Keysi. [17] MIYAHARA, Koji; PAZZANI, Michael J. Collaborative Filtering with the Simple Bayesian Classifier. In. Proceedings of the 6th Pacific Rim International Conference on Artificial Intelligence. Melbourne, Australia: Springer-Verlag, 2000, s. 679–689. ISBN 3-540-67925-1. [18] PERNKOPF, Franz. Bayesian Network Classifiers Versus Selective k-NN Classifier. Pattern Recogn. 2005, roč. 38, č. 1, s. 1–10. ISSN 0031-3203.

76

[19] YANG, Yiming; LIU, Xin. A Re-examination of Text Categorization Methods. In. Proceedings of the 22Nd Annual International ACM SIGIR Conference on Research and Development in Information Retrieval. Berkeley, California, USA: ACM, 1999, s. 42–49. SIGIR ’99. ISBN 1-58113-096-1. [20] TRILOBYTE. SVM - Support Vector Machines. 2015. Dostupný z: hwww.trilobyte.cz/QCExpert/SVM-Support-Vector-Machines.htmli. [21] BYUN, Hyeran; LEE, Seong-Whan. Applications of Support Vector Machines for Pattern Recognition: A Survey. In. Proceedings of the First International Workshop on Pattern Recognition with Support Vector Machines. London, UK, UK: Springer-Verlag, 2002, s. 213–236. SVM ’02. ISBN 3-540-44016-X. [22] CHENG, P.J.; KAN, M.Y.; LAM, W.; NAKOV, P. Information Retrieval Technology: 6th Asia Information Retrieval Societies Conference, AIRS 2010, Taipei, Taiwan, December 1-3, 2010, Proceedings. 2010. LNCS sublibrary: Information systems and applications, incl. Internet/Web, and HCI. Dostupný také z: hhttps://books.google.cz/books?id=UmeTSy3ygTECi. ISBN 9783642171864. [23] Languages used on the Internet . 2015. Dostupný z: hhttp://en.wikipedia.org/wiki/Languages_used_on_the_Interneti. [24] URL Blacklist. 2015. Dostupný z: hwww.urlblacklist.comi. [25] GRAHAM, Paul. Better Bayesian filtering . 2015. Dostupný z: hwww.paulgraham.com/better.htmli.

77