Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites

Transcriptie

1 Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites Pascal Vyncke Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: dr. ir. Michiel Ronsse, dr. Jonas Maebe Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar

2 VOORWOORD ii Voorwoord Het internet is niet meer weg te denken uit ons leven. Enorme aantallen mensen komen samen op communitywebsites (sociale netwerksites). Omdat sommige mensen zich niet altijd aan de regels houden, worden zij dan verwijderd van de website. Mensen blokkeren is spijtig genoeg niet zo eenvoudig. Mijn interesse voor dit onderwerp komt doordat ik er zelf elke dag mee geconfronteerd wordt vanuit SeniorenNet en Bloggen.be. Aangezien ik zelf reeds lang hoop op een oplossing ter zake, was deze masterproef een uitgelezen kans om het probleem grondig te analyseren en zelf een oplossing proberen te zoeken. Zeer aangenaam was het dat mijn promotor dit zelf aangebrachte onderwerp ook heeft aanvaard. Dit werk is er niet alleen gekomen door mijn interesse in de materie, er zijn nog tal van mensen die, elk op hun manier, hun steentje bijgedragen hebben om dit werk te maken tot wat het nu is. Ik wens hierbij mijn promotor professor Koen De Bosschere te bedanken voor de talrijke keren dat hij de nodige tijd en energie vrijmaakte om mij bij dit project te begeleiden. Ook dank ik hem voor het geboden vertrouwen en de kans om een eigen onderwerp aan te brengen en uit te werken. Ik dank tevens de heren Bertel De Groote en professor emeritus Rogier De Corte voor hun juridisch advies omtrent de Wet Verwerking Persoonsgegevens. Pascal Vyncke, juni 2009

3 TOELATING TOT BRUIKLEEN iii Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Pascal Vyncke, juni 2009

4 Ontwikkeling van een sluitende authenticatie van gebruikers van web 2.0 communitywebsites door Pascal Vyncke Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar Promotor: prof. dr. ir. Koen De Bosschere Scriptiebegeleiders: dr. ir. Michiel Ronsse, dr. Jonas Maebe Faculteit Ingenieurswetenschappen, Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. Jan Van Campenhout Samenvatting In dit werk wordt gezocht naar een methode voor authenticatie waardoor websites vervelende bezoekers kunnen weren. Enerzijds wordt een onderzoek gedaan om het probleem beter te begrijpen en wordt een sterkte/zwakte analyse van de huidige courante systemen uitgevoerd. Anderzijds wordt een nieuw systeem ontwikkeld dat aan de opgelegde eisen voldoet. Door het gebruik van een extra medium (mobiele telefoon) wordt een techniek voor authenticatie ontwikkeld. Door het centraliseren van de databank wordt het mogelijk om zowel de identiteit als reputatie van een gebruiker te delen. Trefwoorden Authenticatie, web 2.0, ban, ID en reputatie, rating

5 Development of a secure authentication method for users of web 2.0 community websites Pascal Vyncke Supervisor(s): Koen De Bosschere Abstract This master thesis studies the problem of the effective authentication of problematic users on community websites. We propose a solution that is based on the unique caller id of their cell phone. On top of that authentication system, we developed a community based reputation system. The whole concept has been implemented and will be made available under the name of YouValid. Keywords Authentication, web 2.0, ban, ID and reputation, rating I. INTRODUCTION WEBSITE visitors can cause serious problems on web 2.0 community websites by making arguments, placing spam, slander and other abuse. Currently, moderators can ban such visitors from the website, but they cannot prevent that the same visitors create additional accounts and continue causing trouble. This is a serious problem for many web 2.0 community websites. There are cases of big community websites of hundreds of thousands users that had to be shut down because they were not able to control the problem. Even for websites that succeed in controlling the problem, the moderation effort and cost of fighting recidivist misbehaving visitors is huge. According to a survey among the moderators of it turns out that misbehaving visitors have to be removed from the system on average 18 times before they finally give up. It is clear that they can do a lot of damage in the meantime. The main problem is that there is currently no effective technical means to uniquely identify web 2.0 website visitors. Hence in practice, (i) users can re-register as often as they want, and (ii) they can create havoc on as many websites as they have access too. In this work, we propose to solve both problems at once by creating a central authentication service with community reputation management. The core idea is that users can only create an account on a web 2.0 website through a dedicated authentication service, which also keeps track of the (bad) reputation of users. Hence, a community website can now decide to refuse a new user because he or she is known to have caused too much trouble on other websites. Thanks to this community-base reputation system, moderators can focus their attention more on possible problem users, leading to faster action and a globally better website experience for all other users. The main challenge in this whole project was to find a good solution for the unique identification of visitors. II. STATE OF THE ART IN WEBSITE VISITOR IDENTIFICATION Over 20 technical solutions exist to help a website to identify a visitor. They can be grouped in three categories: 1. based on the visitor s computer. This solution is easy to break: it suffices to change computers, or to change ip-addresses or mac-addresses. Most users can find ways to circumvent this authentication. 2. based on the visitor s identity data such as a national identification number, a bank account number, a fingerprint, etc. Unfortunately, fake numerical identifications can be generated automatically, and verifying them world-wide is neither easy nor cheap. Furthermore, there can also be privacy issues with identity data. The few techniques that can be used globally suffer from accuracy problems (e.g. recognition of fingerprints, or of writing style). 3. based on a physical device like a dongle or a digipass. This is an effective means of authentication, but it is fairly expensive, and only affordable for banks or commercial websites. Since a physical device cannot be delivered to the user immediately, it will keep away occasional users. In this work, we propose to combine categories 2 and 3 by combining a mobile phone (a physical device) with a unique identification number (a caller id). III. MOBILE PHONE IDENTIFICATION A nice property of the mobile phone is that almost every internet user has one. The world currently counts 4 billion mobile phone users, three times more than there are internet users. Furthermore, the phone is a physical device, most people do not have access to a large number of mobile phones and acquiring an extra one incurs an additional cost. Finally, the mobile phone is highly standardized, so it can be used globally. Hence if we succeed in uniquely identifying a mobile phone, we can use that identification to identify its owner. It turns out that the caller id is a good way of identifying the phone. When sending SMS messages, it can be easily spoofed, but when making a regular phone call, it cannot, and even more, it is illegal to spoof it; it can only be hidden. Hence, we propose to base the whole authentication procedure on a simple mobile phone call (in theory we could also allow a fixed phone, but given the number of public telephones, this would not work that well). Making a mobile phone call is very simple, and not expensive for the user given that he or she can call a local number or a toll-free number. This solves the user part. The website part is more complex. Implementing the authentication procedure requires an investment in hardware and in software. Therefore, we decided to develop a web service which can be called from any website. This web service is called YouValid. YouValid hides the complexity of the authentication procedure from the community website developer.

6 The authentication system works as follows. The user registers at a web 2.0 website by creating an account. The website then sends a request to YouVald for a unique authentication code which is then passed on to the user. The user is then asked to make a phone call with his mobile phone to a given phone number (at YouValid), and to enter the authentication code. After the code has been entered correctly, YouValid contacts the website to which the authentication code was originally issued to inform it that the user registered correctly. It also returns a unique You- Valid user ID to the website for future communication. Every time a user calls to the service from the same mobile phone, the website will get the same unique code back from YouValid. Hence, YouValid effectively identifies the caller id - and also the user provided that he or she always calls from the mobile phone with the same caller ID, no matter how the user registered himself at the web 2.0 website, or from which country he or she is calling. IV. COMMUNITY-BASED REPUTATION MANAGEMENT By centralizing all authentication requests at YouValid, and by allowing websites to give feedback on their users, it is possible to collect user profile information across websites. This profile information is then shared among the participating websites. They can ask for profile information about their existing or new users, and they can base their admission policy on that information. E.g., a user looking for opportunities to spread spam messages on community websites will quickly find out that over time it is getting increasingly difficult to create new accounts at websites, even at websites he never used before. The operation of YouValid is depicted in Figure 1. The abuse categories have been defined in collaboration with experienced moderators. It is important to distinguish between several abuse categories because not all categories are relevant for all websites. Examples of abuse categories are spam, slander, pedophilia and wrangler. When a website reports a banned used to YouValid, it also has to give the abuse category and the severity on a scale of 10 within that category. For practical reasons, the 15 ratings are also summarized in one global rating as a weighted average. The weights have also been determined in collaboration with experienced moderators. The ratings are not everlasting. The ratings are decreased weekly, and eventually they become zero again. The rate of decrease depends on the abuse category. B. Privacy An important aspect of the YouValid service is the protection of the privacy of the users. Keeping track of personal data is regulated by the privacy laws in most countries. In Belgium the privacy law protects the individual very well. Because of this law, the user has at any time the right to consult the data YouValid keeps about him. Fortunately, YouValid does not keep information about persons, but about caller IDs. Nevertheless, we decided to send a text message to the mobile phone that was used to authenticate a user whenever the rating increases. C. Scalability The YouValid service is perfectly scalable. The servers can be replicated and installed all over the world, creating the potential of tens of thousands of simultaneously authentications. By using multiple datacenters, almost 100% uptime is possible. The use local phone numbers in different countries allows for a localized service per country or per region. All these phone calls can easily be rerouted to a restricted number of data center, reducing the operational cost of the service. V. CONCLUSION This abstract describes a user authentication and community based reputation management system. It is based on the caller ID of the mobile phone of a website user. The system is cheap, easy to use, not bound to a particular geographical region, and almost instantaneous for the user. The system is completely implemented and ready to be launched under the name You- Valid.com. A potential patent is under investigation. Fig. 1. Operation of YouValid. Arrows 1 to 6 deal with the registration of a new user on the first website (left). Arrows 7 to 12 deal with the registration of the same user on a different website (right). Arrow 13 is a website that reports a ban. Arrows 14 to 18 return the new rating to other websites. Green arrows are user communication, black arrows are communication between website and YouValid, and red arrows are community feedback. A. Rating The reputation of a user is expressed as a rating, represented by a list of 15 positive numbers, one per abuse category. Regular users start at zero, and bad behavior will increase the value of a particular category.

7 INHOUDSOPGAVE vii Inhoudsopgave Voorwoord Toelating tot bruikleen Overzicht Extended abstract Inhoudsopgave Lijst van figuren Lijst van tabellen ii iii iv v vii xi xiii 1 Inleiding Probleemstelling Doelstelling Analyse van het probleem Soort problemen? Blokkeren Anonimiteit Recidivisme: 18x Criteria Vanuit oogpunt website Vanuit oogpunt eindgebruiker State of the art Computerafhankelijke systemen Persoonsafhankelijke systemen Extra medium Overzicht

8 INHOUDSOPGAVE viii 3 Eigen onderzoek Wat is uniek aan een persoon? SMS activatie Beschrijving Onderzoek IMEI nummer Beschrijving Onderzoek GSM-identificatie Beschrijving Architectuur Gecentraliseerde gsm-identificatie met communityfeedback Beschrijving Voordelen Architectuur Veiligheid: CallerID falsification Telefoonsysteem SMS rating feedback Communicatie met website Inleiding Configuratiebestand Een code aanvragen Website krijgt activatie binnen Website bant gebruiker Website trekt ban terug in Website krijgt update binnen Hashwaarde Rating Algemeen Misbruik Berekening rating Totale rating Aanpassing rating in de tijd Schaalbaarheid Schaalbaarheid op serverniveau Schaalbaarheid op het niveau van telefonie Schaalbaarheid naar website Privacy Algemeen

9 INHOUDSOPGAVE ix Specifieke details Toekomst Systeemkosten Eenmalige kosten (geschat budget) Maandelijkse kosten (geschat budget) Uitwerking in praktijk Inleiding Naam Logo Website Scripts en software Demonstratie Datacentrum Toekomstperspectieven en besluit Toekomst Toekomstige mogelijkheid: OpenID Extra mogelijkheden: microbetalingen Besluit A Overzicht van beveiligingsmethoden 94 A.1 Cookie A.2 IP-adres blokkeren A.3 verificatie A.4 Captcha A.5 Elektronische identiteitskaart A.6 Registratie per post A.7 Rijksregisternummer A.8 Rekeningnummer A.9 Overschrijving A.10 Verificatie creditcard A.11 Unieke karakteristieken computer A.12 Biometrische gegevens A.13 Dongle / kaartlezer A.14 MAC-adres A.15 Unieke machinecode A.16 SMS toesturen A.17 Java(script) op website A.18 Externe service A.19 Centrale database adressen

10 INHOUDSOPGAVE x A.20 Remote fingerprinting A.21 Auteursidentificatie Bibliografie 111

11 LIJST VAN FIGUREN xi Lijst van figuren 1.1 Woordwolk categorieën volgens voorkomen Vraag: Ergert u zich soms wel eens aan mensen die op internet aanwezig zijn en zich zeer ongepast gedragen op bvb. forums, gastenboeken, chatboxen, mailgroepen,..., uitgevoerd bij mensen op SeniorenNet Bezoekers die de blokkering omzeilen zorgen voor problemen Vraag: Durft u soms wel iets te doen of iets meer te zeggen omdat je via het internet anoniem bent?, bij bezoekers op SeniorenNet Vraag: Weet u hoe u een ander IP-adres zou moeten krijgen voor je computer (internetverbinding)?, onderzoek bij mensen op SeniorenNet, oktober Overzicht state of the art Vraag: Heeft u een gsm? bij mensen Verwachte penetratie van vaste en mobiele netwerken in 2012 (in procent) Ontwikkeling van ICT wereldwijd van Screenshot SMS spoof programma om als afzender 911 te geven Screenshot FakeSMS.eu waarbij valse afzender en willekeurig bericht ingegeven wordt Drie voorbeelden van ontvangen SMS met valse afzender Verschillende velden uit het SMS protocol Opbouw IMEI nummer Het IMEI nummer van een gsm geeft merk en type terug Een willekeurig IMEI nummer van een generator opgezocht Schematische voorstelling architectuur gsm-identificatie Vergelijking technieken Schematische voorstelling registratie bezoeker op een website

12 LIJST VAN FIGUREN xii 4.3 Schematische voorstelling tweede registratie en blokkering bezoeker Sequentiediagram webservice bij registratie Sequentiediagram webservice bij melding ban Logo Asterisk en Loquendo Toestandsdiagram telefoonsysteem Logo Gnokii open source software Nokia gsm gekoppeld via USB 2.0 aan computer met Linux in VMWare Schema verzending SMS na binnengekregen ban Logo YouValid Beelden van website YouValid.com Database structuur Screenshot demonstratie met weergave privacy gegevens Screenshot X-Lite VoIP demonstratie Foto s datacentrum van servers met YouValid op Relaties webservice, websites en gebruiker A.1 Enkele captcha voorbeelden A.2 Schema auteursidentificatie A.3 Nauwkeurigheid voor verschillende aantallen van auteurs en berichten

13 LIJST VAN TABELLEN xiii Lijst van tabellen 1.1 Categorieën misbruik gesorteerd volgens voorkomen Gsm-code en landcode per land Gewicht voor elke categorie Gemiddeld aantal dagen blokkering per categorie en soort overtreding Vermindering rating per week in aantal dagen

14 INLEIDING 1 Hoofdstuk 1 Inleiding 1.1 Probleemstelling Op communitywebsites (sociale netwerksites) kunnen de mensen met elkaar interageren. Tienduizenden of zelfs honderdduizenden mensen komen zo samen op een website. Net zoals in de echte wereld is er steeds een beperkte groep die slecht en deviant gedrag vertoont. Zij scheppen er genot in om anderen te plagen, te pesten of uit te schelden. In ernstigere vormen komen zelfs oplichting, stalking, laster en hacking voor. Het is deze beperkte groep die een groot probleem kan veroorzaken en de sfeer voor al de rest kan verpesten. Het gaat vaak om niet meer dan 0,1% van de bezoekers. De oplossing bestaat erin om bepaalde gebruikers te blokkeren en de toegang te ontzeggen, al dan niet temporeel of definitief. Om dergelijke gebruikers te ontdekken zijn al diverse systemen ontwikkeld. Eens deze (mis)gebruikers gekend zijn, is de uitdaging hen de toegang tot het systeem te ontzeggen. De huidige systemen zijn niet toereikend gebleken aangezien er geen of een minimum aan financiële input of tijd nodig is om zich terug toegang te verschaffen zodat de gebande gebruiker weer actief kan deelnemen aan het communitysysteem. Een gebruiker met slechte bedoelingen kan in praktijk zo goed als onmiddellijk terug toegang krijgen zonder veel moeite of kosten. Een gebande gebruiker kan namelijk eenvoudig een cookie wissen, IP adres wijzigen, een ander (gratis) adres aannemen, surfen via een anonieme proxyserver, browser/computergegevens faken, enz. Wereldwijd worden alle community websites met dit probleem geconfronteerd, alsook alle

15 1.2 Doelstelling 2 websites die gebruik maken van interactieve diensten zoals chatboxen, forums, blogs, enz. Niet meer dan eens gaan er zelfs websites of diensten aan ten onder. Voorbeelden te over. De omroep NOS Nederland sloot haar forum (waar ze 2 jaar aan hadden gewerkt) in 2007 doordat ze de gebruikers niet meer onder controle kreeg. VTM sloot in 2002 de chatboxen voor Big Brother doordat ze racistische boodschappen niet meer onder controle kreeg. Zo werd Microsoft MSN genoopt in 2003 om wereldwijd al haar chatrooms te sluiten omdat er teveel ruzies waren, pedofielen niet geweerd konden worden en ze niets konden beginnen tegen spammers [1] [2]. Ook is een voorbeeld van een grote web 2.0 communitywebsite bij de wat oudere surfers. is de grootste website voor de actieve 50-plussers met een bereik van meer dan 1,3 miljoen unieke bezoekers per maand. Op deze website zijn 150 vrijwilligers voltijds bezig om de website onder controle te houden en bezoekers op tijd te verwijderen van de site bij problemen. Maar zelfs zij krijgen sommige problemen amper of slechts zeer traag onder controle. Een duurzame oplossing dringt zich op, zoniet zouden de meeste community websites ten onder kunnen gaan aan hun eigen succes. 1.2 Doelstelling Deze masterproef heeft twee doelstellingen. In eerste instantie wordt de ernst van het probleem geanalyseerd en zal er een sterkte/zwakte analyse gemaakt worden van de huidige courante systemen (cookies, IP adres blokkering, verificatie,...) teneinde een klaar beeld te bekomen waar deze systemen precies falen. In tweede instantie wordt een universele oplossing gezocht voor dit probleem. Er mag niet uit het oog verloren worden dat de implementatie van de geboden oplossing niet te moeilijk mag zijn, en dat de drempel voor de modale gebruiker niet te hoog mag worden en voldoende privacy moet behouden blijven. De toegang onmogelijk maken voor een gebande gebruiker zal waarschijnlijk niet haalbaar zijn. Teneinde de kansen op recidives maximaal te reduceren dient te worden gezocht naar een oplossing die de nodige weerstand kan bieden.

16 1.3 Analyse van het probleem 3 Gezien ik webmaster ben van de website SeniorenNet, heb ik de mogelijkheid om van dit instrument gebruik te maken. Enquêtes bij bezoekers of een enquête bij de medewerkers uitvoeren is hierdoor mogelijk. Door gebruik te maken van de reeds bestaande infrastructuur voor het implementeren van de oplossing wordt het financieel haalbaar. 1.3 Analyse van het probleem Een analyse van het probleem heb ik onder andere gedaan op basis van een enquête die uitgevoerd werd bij de medewerkers van SeniorenNet. Samen hebben ze 144 manjaar ervaring met lastige en vervelende bezoekers Soort problemen? Het gaat om diverse problemen waar een website mee geconfronteerd wordt. werden ze door de auteur in 15 categorieën ingedeeld. In totaal Een sortering van vaak (1) tot minder vaak (15) voorkomend werd gemaakt op basis van onderzoek bij diverse ervaren moderators. Elke moderator gaf bij elk van de categorieën een score betreffende de frequentie van het voorkomen van de inbreuk. Per inbreuk werd het gemiddelde genomen. Op dit gemiddelde werd vervolgens gesorteerd. Het resultaat staat in tabel 1.1. Een grafische voorstelling door middel van een woordwolk (tagclaud) geeft dit duidelijker weer in figuur 1.1. Hoe groter en prominenter een trefwoord aanwezig, hoe vaker het misbruik voorkomt. De problemen kunnen ingedeeld worden in twee soorten: Wettelijk strafbare feiten Niet strafbare feiten De niet strafbare feiten komen het vaakst voor en zijn tegelijk het ergst voor een website. Naar een website waar steeds wordt ruziegemaakt, waarop je beledigd of gepest wordt, gaat men niet meer terug. Zo verliest een website bezoekers. Het is in de marketingwereld algemeen bekend dat het tot 10 maal duurder is om een nieuwe klant te werven dan een bestaande klant te houden. Het tegengaan van verlies van bezoekers is daarom belangrijk voor de website.

17 1.3 Analyse van het probleem 4 Volgorde Tabel 1.1: Categorieën misbruik gesorteerd volgens voorkomen Categorie 1 Ruziemakers (bewust sfeer verpesten,...), beledigingen, pesterijen 2 Bewust negatieve reacties plaatsen om andere bezoekers af te breken 3 Mensen die adressen van bezoekers verzamelen om ze vervolgens privé te benaderen 4 Reclame / spam 5 Smaad, eerroof van andere mensen 6 Vulgair gedrag / taalgebruik 7 Bedreigingen naar bezoekers of medewerkers 8 Zich uitgeven voor een andere bestaande persoon 9 Illegale plaatsing content (auteursrechtelijk beschermd, virussen,...) 10 Zich uitgeven voor een ander geslacht, andere leeftijd, andere seksuele geaardheid, ander ras Stalking 12 Racisme, politieke boodschappen 13 Mensen die fraude plegen met het systeem (advertenties omzeilen, hacking,...) 14 Pornografie / kinderpornografie 15 Pedofilie Strafbare feiten als (kinder)porno, schending van auteursrechten of hacken zijn zwaardere misdrijven maar komen gelukkig minder voor. Een onderzoek bij mensen bevestigd dat mensen zich aan dergelijke misbruiken ook daadwerkelijk ergeren. In figuur 1.2 is te zien dat driekwart van de mensen zich hieraan ergeren Blokkeren Het grootste deel van de bezoekers heeft het goed voor met de website en zorgt niet voor ernstige problemen. Er is slechts een klein deel dat wél voor problemen zorgt. Websites wensen deze probleemgroep te blokkeren om zo de goede sfeer te behouden voor alle andere gebruikers. Enkel zo kunnen ze hun bezoekers behouden en verder blijven groeien.

18 1.3 Analyse van het probleem 5 Pesterijen Racisme Ruziemakers Eerroof Pedofilie Kinderporno Bewust mensen afbreken Schending auteursrechten Porno Fraude Spam Verzamelen adressen Beledigingen Uitgeven voor iemand anders Smaad Bedreigingen Illegale content Vulgair taalgebruik Stalking Hacken Figuur 1.1: Woordwolk categorieën volgens voorkomen. De slechte gebruikers moeten echter eerst ontdekt worden. Het achterhalen van dit soort gebruikers kan op diverse manieren gebeuren. Enerzijds kan dit door technologische oplossingen die gebruikerspatronen analyseren, of door het effectief laten opvolgen van de verschillende rubrieken op een website door vrijwilligers. De laatste optie wordt op SeniorenNet gebruikt. Welke techniek ook gebruikt wordt, op een bepaald moment beslist iemand dat een gebruiker de regels overtreden heeft en moet worden uitgesloten van verdere deelname. Op dat moment gaat men over tot blokkering van de persoon. Deze blokkering lost het probleem nog niet op. Uit onderzoek blijkt dat in praktijk met de bestaande technieken 31% tot 68% van de bezoekers die geblokkeerd worden, de blok-

19 1.3 Analyse van het probleem 6 Ja, zeer regelmatig Ja, af en toe Ja, al enkele keren gehad in het verleden Ja, regelmatig Ja, komt al eens voor Neen, nog nooit Figuur 1.2: Vraag: Ergert u zich soms wel eens aan mensen die op internet aanwezig zijn en zich zeer ongepast gedragen op bvb. forums, gastenboeken, chatboxen, mailgroepen,..., uitgevoerd bij mensen op SeniorenNet. kering omzeilen om vervolgens terug binnen te komen en opnieuw voor overlast te zorgen 1. Grafisch is dit voorgesteld in figuur 1.3. Hierdoor blijft de sfeer onaangenaam op de website, met tevens frustraties voor moderators van de website die machteloos staan. Figuur 1.3: Bezoekers die de blokkering omzeilen zorgen voor problemen. 1 Op basis van eigen onderzoek op SeniorenNet. Afhankelijk van de rubriek gaat het van 30,97% tot 67,80%

20 1.3 Analyse van het probleem Anonimiteit Op internet zijn er net als in de gewone maatschappij mensen die vervelend doen, tegen de stroming ingaan en zaken doen die niet mogen. In het echte leven komen dit soort mensen vaak in contact met politie en belanden mogelijk in de gevangenis. Op internet is het anders. Je bent er anoniem of op zijn minst naamloos. Een website heeft vanuit technisch standpunt niet meer dan het IP-adres van een gebruiker. Buiten dit IP-adres weet men nagenoeg niets anders over de gebruiker. Uit onderzoek blijkt dat de anonimiteit mensen aanzet om het minder nauw te nemen met de gangbare regels. De resultaten van een enquête bij vijftigplussers wordt grafisch voorgesteld in figuur 1.4. Bijna 1 op 4 vijftigplussers geeft eerlijk toe dat ze wel eens iets meer durfden te doen of te zeggen op internet omdat men anoniem is, terwijl ze dit in het echte leven nooit zouden gedaan hebben. Waarschijnlijk zal dit aantal ongetwijfeld meer zijn omdat er mensen zijn die dit niet durfden toe te geven. Figuur 1.4: Vraag: Durft u soms wel iets te doen of iets meer te zeggen omdat je via het internet anoniem bent?, bij bezoekers op SeniorenNet De zowat enige gangbare techniek voor het buitenhouden van mensen is door hun IP-adres te blokkeren. Uit onderzoek blijkt dat dit weinig nut heeft. Op de grafische voorstelling van de resultaten in figuur 1.5 is te zien dat een kwart van de vijftigplussers weten hoe ze aan een ander IP-adres kunnen geraken.

21 1.4 Criteria 8 Figuur 1.5: Vraag: Weet u hoe u een ander IP-adres zou moeten krijgen voor je computer (internetverbinding)?, onderzoek bij mensen op SeniorenNet, oktober Recidivisme: 18x Dit alles vertaalt zich ook in het recidivisme. Gemiddeld blijkt dat moderators iemand 18x opnieuw moeten blokkeren alvorens de persoon het opgeeft en van de website wegblijft. Dit betekent een enorme inspanning die moet geleverd worden vanuit de website. 18 keer opnieuw dient de slechte gebruiker door een moderator ontdekt en geblokkeerd te worden. In praktijk betekent dit dat een probleem weken tot maanden blijft aanslepen voordat men eindelijk van de persoon af is. Het geduld van zowel moderator als andere bezoekers wordt hiermee op de proef gesteld. Het vinden van een systeem waarbij een gebruiker moeilijk terug binnen kan komen is daarom van groot belang. 1.4 Criteria Om na te gaan of een systeem bruikbaar is worden een aantal belangrijke criteria gedefinieerd waaraan het systeem dient te voldoen. De criteria worden in twee groepen ingedeeld. Enerzijds vanuit het standpunt van de website (die het systeem gaat gebruiken om bezoekers buiten te houden, bijvoorbeeld SeniorenNet), anderzijds vanuit het standpunt van de eindgebruiker (de persoon die op de website komt).

22 1.4 Criteria Vanuit oogpunt website Vals negatieven. Hoe groot is de kans dat een gebruiker die bewust werd geblokkeerd toch verkeerdelijk door het systeem binnen gelaten wordt, zonder dat de gebruiker hiervoor iets speciaal gedaan heeft. In dit geval faalt het systeem. Bijvoorbeeld: website zet blokkering op IP-adres. Het IP-adres van de gebruiker wijzigt automatisch door zijn provider, waarna deze terug binnenkan; zonder bewust de blokkering te omzeilen. Drempel omzeilen. Indien de website een gebruiker bewust geblokkeerd heeft, hoe moeilijk is het dan voor een gebruiker om de blokkering te omzeilen? De moeilijkheidsgraad is een combinatie van tijd, kennis en geld die een gebruiker moet investeren om de blokkering te omzeilen. Wereldwijd. Het systeem zou ideaal wereldwijd moeten kunnen ingezet worden. Het heeft weinig nut om een systeem te ontwikkelen dat slechts in een kleine regio of één enkel land kan gebruikt worden. Ontwikkeltermijn. Hoelang duurt het voordat het systeem in praktijk kan worden gebracht? Dit is de termijn voor onderzoek en ontwikkeling die nog nodig is voordat het systeem realistisch in praktijk kan worden gebracht. Kost/gebruiker. Hoeveel kost het de website per gebruiker? Ideaal zou zijn dat er geen kost per gebruiker is (naast een eventuele eenmalige opstartkost). Startkosten. Dit zijn de kosten om het systeem in praktijk te integreren en te starten. Hoe hoger deze kosten, hoe minder websites dit financieel kunnen of willen opbrengen. Opbrengsten. Is het mogelijk aan het systeem geld te verdienen? Indien het mogelijk extra inkomsten kan genereren, zal dit een groot pluspunt zijn Vanuit oogpunt eindgebruiker Vals positieve. Hoe groot is de kans dat een gebruiker die niets verkeerd gedaan heeft toch verkeerdelijk uitgesloten wordt? Privacy. Gebruikers zijn erg gesteld op hun privacy. Men is meestal wel bereid om een gedeeltelijke toegeving te doen, maar bepaalde gegevens zoals een foto, geboortecertificaat of thuisadres zijn er meestal teveel aan.

23 1.4 Criteria 10 Gebruiksvriendelijkheid. Ideaal is dat de gebruiker niets van het systeem merkt. Indien het systeem tóch zichtbaar is voor de gebruiker moet het zo eenvoudig mogelijk zijn. Kosten. Hoeveel kost het de gebruiker om op de website te komen? Bij een te grote kost zullen bezoekers vermoedelijk afhaken.

24 STATE OF THE ART 11 Hoofdstuk 2 State of the art Literatuuronderzoek over dit onderwerp geeft 21 systemen. Elk systeem werd apart onderzocht en beoordeeld op de voordelen en nadelen. Een uitgebreide beschrijving per systeem is te vinden in appendix A. Elk van de state of the art systemen is onder te verdelen in één van volgende drie categorieën: computer afhankelijk, persoonsafhankelijk of het gebruik van een extra medium. Elke categorie heeft vergelijkbare voordelen en nadelen, met elk specifiek systeem zijn eigen accenten hierin. 2.1 Computerafhankelijke systemen In deze categorie worden beveiligingssystemen die gebruikmaken van technische kenmerken of geheugen van de computer onderverdeeld. Het betreft zowel eenvoudige systemen als cookies, IP-adres en MAC-adres, als de meer ingewikkelde systemen zoals unieke karakteristieken van de pc en remote fingerprinting. Positief aan beveiligingssystemen in deze categorie is dat de gebruiker zo goed als geen weet heeft van deze systemen. Alles verloopt buiten het gezichtveld van de gebruiker wat een goede gebruiksvriendelijkheid geeft. De meeste systemen zijn vaak niet afhankelijk van de regio waar de gebruiker woont waardoor ze wereldwijd ingezet kunnen worden. Negatief aan elk van de systemen is dat ze relatief eenvoudig te omzeilen zijn waardoor de veiligheid van het systeem onvoldoende wordt voor een goede authenticatie voor een website.

25 2.2 Persoonsafhankelijke systemen Persoonsafhankelijke systemen Een systeem dat gegevens gebruikt die afhankelijk zijn van de gebruiker zélf en zich niet baseert op de technische hardware die een gebruiker heeft worden onder deze categorie geplaatst. Enkele voorbeelden van dergelijke systemen zijn verificatie, het ingeven van het rijksregisternummer, biometrische gegevens of auteursidentificatie. Het uniek zijn van de persoonsafhankelijke kenmerken geeft een bruikbare methode voor een correcte authenticatie. Het probleem is in de meeste gevallen het controleren van deze gegevens op echtheid. Wanneer bijvoorbeeld iemand zijn rijksregisternummer ingeeft kan je moeilijk nagaan of dit toch niet van iemand anders zou zijn. Tevens is het moeilijker om persoonsafhankelijke systemen op wereldwijde schaal te introduceren doordat ze regionale verschillen vertonen. Denk hierbij aan bijvoorbeeld het rekeningnummer. Bij het in praktijk brengen van systemen in deze categorie komt meermaals naar voor dat mensen niet altijd even bereid zijn om deze gegevens te delen met een website. Je rijksregisternummer of vingerafdruk geven aan een willekeurige website roept privacyvragen op. 2.3 Extra medium Sommige systemen maken gebruik van een extra medium zoals bijvoorbeeld een dongle, kaartlezer, de elektronische identiteitskaart of het registreren per post. Door het gebruik van een extra medium wordt het omzeilen van de beveiliging doorgaans moeilijker. De beveiliging verhoogt hierdoor, maar tegelijkertijd is het systeem zeer duidelijk aanwezig voor de gebruiker wat dan weer de gebruiksvriendelijkheid doet dalen. Het grootste nadeel van systemen in deze categorie is dat het toepassen op wereldschaal moeilijk of duur is. Regionale verschillen of de relatief hoge kost per dongle maken het financieel erg bezwarend. 2.4 Overzicht Een analyse van elk van de onderzochte systemen werd samengevat in volgende tabel 2.1.

26 2.4 Overzicht 13 Vals negatieve Drempel omzeilen Wereldwijd Ontwikkeltermijn Kost/gebruiker voor site Startkosten Opbrengsten Vals positieve Privacy Gebruiksvriendelijkheid Kosten voor gebruiker Computer afhankelijke systemen Cookies *** * ***** ***** ***** ***** * ***** ***** ***** ***** IP adres * * ***** ***** ***** ***** * * ***** ***** ***** E mail verificatie **** * ***** ***** ***** ***** * **** **** *** ***** Captcha * * ***** ***** ***** ***** * * ***** ** ***** Karakteristieken computer ** ** ***** *** **** **** * *** *** ***** ***** MAC adres **** ** ***** * ***** ***** * *** ***** ***** ***** Unieke machinecode ***** ** ***** * ***** ***** * *** *** ***** ***** Java(script) *** ** ***** **** ***** ***** * *** **** ***** ***** Remote fingerprinting ** ** ***** ** ** ** * ** *** ***** ***** Persoonsafhankelijke systemen Rijksregisternummer Rekeningnummer Biometrische gegevens Auteursidentificatie **** * ** ***** ***** ***** * **** * ** ***** **** * ** ***** ***** ***** * **** * ** ***** *** ** ***** * **** **** * *** * ** **** ** *** ** ** *** ** * ** ***** ***** ***** Externe service **** **** **** ** **** **** * **** **** *** ***** E mail adres database Extra medium **** ** ** ** ***** ***** * **** *** ***** ***** eid ***** ***** * *** ***** *** * ***** * *** **** Registratie per post **** ** ***** **** * ** * **** * * ***** Overschrijving **** *** ***** *** * *** * ***** * * ***** Kredietkaart ***** **** ***** *** ** *** ***** ***** * * *** SMS toesturen ***** ***** ***** ** * ** **** ***** *** *** *** Dongle ***** *** ***** ** * ** * ***** ** * *****

27 EIGEN ONDERZOEK 14 Hoofdstuk 3 Eigen onderzoek De state-of-the-art studie geeft aan dat er nog onvoldoende goede techniek voorhanden is om bepaalde bezoekers blijvend te weren uit websites en die bovendien voldoet aan de belangrijkste criteria. Het doel van deze masterproef is dan ook om een oplossing te ontwikkelen. 3.1 Wat is uniek aan een persoon? Het uniek identificeren van een persoon is het doel. De specifieke identiteit weten is minder of helemaal niet belangrijk. Indien dezelfde persoon terug wil inschrijven op een website, wil de website weten dat het om dezelfde persoon gaat. Via de bestaande internetprotocollen is dit niet mogelijk. Het IP-adres, MAC-adres, cookies,... voldoen niet. De oplossing bestaat erin om een extra criterium erbij te betrekken. Iets dat niets te maken heeft met de computer, maar wat eigen is aan de persoon zélf. Dit zijn de belangrijkste unieke kenmerken voor een persoon die mogelijk gebruikt kunnen worden voor elektronische identificatie: Identificatiekaart (eid) Kredietkaart Telefoonnummer Rijksregisternummer

28 3.1 Wat is uniek aan een persoon? 15 Postadres Bankrekeningnummer Biometrische gegevens Schrijfstijl GSM / telefoon Voor een aantal van deze kenmerken werden reeds technieken ontwikkeld, maar zonder een afdoende oplossing te bieden. Vooral de mobiele telefoon trekt de aandacht. Deze gsm combineren met internet kan voor een unieke identificatie zorgen. Iedereen heeft tegenwoordig zijn eigen gsm, zeker wie beschikt over internet. Na een eigen onderzoek op de website SeniorenNet bij mensen blijkt zoals op figuur 3.1 te zien is dat 98,10% van de 50-plussers op internet over een gsm beschikt. Bij jongeren zal dit percentage vermoedelijk nog hoger liggen. Figuur 3.1: Vraag: Heeft u een gsm? bij mensen. Zo zijn er in 2007 per honderd inwoners in België 97,8 gsm-abonnees [29]. Ook wereldwijd doet de gsm het enorm goed. Er zijn begin 2009 wereldwijd 4 miljard abonnementen voor mobiele telefoons, waarvan tweederde in ontwikkelingslanden [30] [31]. Men voorspelt tegen 2013 dat er 6 miljard abonnementen zullen zijn. De verwachte groei van de wereldwijde penetratie in 2012 ten opzichte van 2008 is groot. De grafiek 3.2 uit een onderzoek van McKinsey [32] geeft dit grafisch weer.

29 3.2 SMS activatie 16 Figuur 3.2: Verwachte penetratie van vaste en mobiele netwerken in 2012 (in procent) Bovendien zijn er meer mensen die de mobiele telefoon gebruiken dan internetgebruikers, zodat ervan uit kan gegaan worden dat het gebruik van de gsm in combinatie met het internet geen probleem mag vormen. Op de grafiek 3.3 uit [33] is in het donkerblauw het aantal mobiele telefoongebruikers aangeduid en de driehoekjeslijn staat voor zijn het aantal internetgebruikers. 3.2 SMS activatie Beschrijving Het nieuw ontwikkelde systeem betreft een toegangssysteem waarbij de bezoeker van een website een code krijgt op die website. Deze code dient men vervolgens via SMS te versturen naar het nummer van die website. De website is in dit geval de website waarop de eindgebruiker daadwerkelijk wenst te registreren. De website ontvangt de SMS en kan op basis van de code herkennen bij welke registratie deze hoort. Het gsm-nummer is zichtbaar bij een SMS waardoor de afzender gekend is.

30 3.2 SMS activatie 17 Figuur 3.3: Ontwikkeling van ICT wereldwijd van Door het laten toesturen van de code is er enkel een kost voor de bezoeker die zeer beperkt is. Een SMS naar een gewoon nummer kost zo n 0,10 euro. Voor de website zijn er nauwelijks kosten aan verbonden waardoor het hebben van honderdduizenden bezoekers geen financiële drempel zou zijn. Indien de website de gebruiker blokkeert, wordt het gsm-nummer toegevoegd in een eigen blacklist. Wanneer dezelfde gebruiker zich opnieuw wil inschrijven, dient deze opnieuw een SMS te versturen. Op het moment dat de SMS binnenkomt bij de website wordt het nummer van de afzender herkend in de blacklist. De activatie van de registratie wordt zo niet toegelaten. Resultaat is dat de bezoeker niet meer binnen kan. De enige mogelijkheid om de beveiliging te omzeilen is een ander gsm-nummer te verkrijgen. Dit is minder eenvoudig. Het kost geld (10 euro of meer), men kan niet zomaar aan een grote hoeveelheid nieuwe nummers geraken en vaak dient een nieuw nummer geactiveerd te worden. Hierdoor is er een financiële drempel. Maar ook een tijdsdrempel. Het kopen en activeren van een nieuw nummer neemt tijd en energie in beslag. De kans dat iemand dit 18x opnieuw zou doen zoals nu het geval is, zal klein zijn. Het systeem is internationaal en op grote schaal bruikbaar. Het ontvangen van SMS berichten vanuit het buitenland is zonder problemen mogelijk. Lokale nummers in elk land kunnen, maar zijn niet nodig. Het versturen van een SMS naar het buitenland kost vaak niet zoveel extra. Binnen Europa is de limiet recent verlaagd naar 0,11 euro per sms [34]. Het is bovendien ook bruikbaar om mogelijk voor extra financiële inkomsten voor de website te zorgen. In plaats van een gewoon gsm-nummer te gebruiken, kan men een verkort nummer gebruiken wat extra geld opbrengt per sms.

31 3.2 SMS activatie Onderzoek Er werd onderzoek gedaan naar de haalbaarheid en veiligheid van het systeem. spoofing bleek een struikelblok. SMS De afzender van een SMS kan eenvoudig geveinsd (spoofing) worden. Zo is het mogelijk om een SMS te versturen vanaf eender welk nummer als afzender. Hierdoor valt het volledige systeem in het water gezien de authenticatie afhangt van het gsm-nummer. Een eerste mogelijkheid bestaat erin gebruik te maken van het programmatje SMS spoof. Dit is gratis te downloaden voor de iphone en Palm. Op de foto 3.4 is een screenshot te zien waarbij de afzender 911 wordt gegeven, en de ontvanger ook kan gekozen worden. Wie wil kan het programma vrij eenvoudig vinden 1. Figuur 3.4: Screenshot SMS spoof programma om als afzender 911 te geven. Een grotere bedreiging vormt het commercieel uitbaten van SMS spoofing door diverse websites wereldwijd. Ook in het Nederlands is er een dergelijke website beschikbaar: FakeSMS.eu. Een screenshot is te zien in figuur 3.5. Op deze website kan op een eenvoudig manier SMS berichten worden verstuurd naar één of meerdere ontvangers, waarbij het bericht en in het bijzonder de afzender willekeurig kan gekozen worden. 1 In Google SMS spoof download als trefwoorden ingeven geeft honderden websites. Een rechtstreekse link is terje/palm/smsspoof/smsspoof-1.1.zip

32 3.2 SMS activatie 19 Figuur 3.5: Screenshot FakeSMS.eu waarbij valse afzender en willekeurig bericht ingegeven wordt. Deze SMS spoofing werd naar aanleiding van het onderzoek uitgetest. Er werden 2 websites gekozen waarop een betalende account aangemaakt werd. Vervolgens werden SMS berichten verstuurd met valse afzender, die daadwerkelijk aankwamen. Op de foto s in figuur 3.6 zijn de ontvangen berichten te zien. Merk op dat de laatste cijfers bij de eerste zijn, en bij de andere SMS het omgekeerde: Deze testnummers lijken nog realistisch met het als prefix. Er werd eveneens succesvol uitgetest dat ook volledig onbestaande nummers kunnen verzonden worden. Zo werd een SMS met afzender verstuurd en ontvangen. De verklaring ligt in het SMS protocol (PDU protocol). Op figuur 3.7 is een voorbeeld SMS te zien met elk van de velden eronder uitgelegd.

33 3.2 SMS activatie 20 Figuur 3.6: Drie voorbeelden van ontvangen SMS met valse afzender. De 2 velden waar een pijl bij staat zijn 2 identificatienummers van een SMS. De rode pijl geeft de afzender aan. Deze afzender wordt ingevuld door de afzender zelf. Deze wordt niet gecontroleerd door het (gsm)-netwerk. Dit is vergelijkbaar bij het IPprotocol: de afzender kiest zelf wat hij in het veld afzender plaatst. De zwarte pijl geeft het unieke nummer aan van de provider waar de SMS vandaan komt. Het blijkt echter ook niet mogelijk te zijn om hiermee providers die SMS spoofing toelaten te blokkeren. Grote providers als Proximus of Base controleren de afzender niet van een SMS, waardoor ook SMS spoofing mogelijk blijft via applicaties zoals de iphone of Palm. Daarom werd uiteindelijk het idee van SMS activatie verlaten en werd gezocht naar een alternatief.

34 3.3 IMEI nummer 21 Voorbeeld SMS: Base, Proximus, hebben elk hun eigen nummer. Vervalsen afzender mogelijk Figuur 3.7: Verschillende velden uit het SMS protocol 3.3 IMEI nummer Beschrijving Het IMEI nummer is een nummer dat uniek is aan elke gsm en verwerkt zit in de hardware. Overal ter wereld heeft iedere mobiele telefoon een IMEI nummer. Het nummer wordt in de gsm-standaard onder andere gebruikt voor communicatie met het netwerk (naast het IMSI, TMSI, MS-ISDN, MSRN, LAI en CI nummer). Het is het enige nummer uit voorgaande reeks dat door de gebruiker zélf op te vragen is. Door *#06# in te drukken op een gsm wordt het IMEI nummer getoond.

35 3.3 IMEI nummer 22 Het IMEI nummer bestaat uit 19 cijfers en is opgebouwd zoals in figuur 3.8. Figuur 3.8: Opbouw IMEI nummer. De website zou dit IMEI nummer kunnen vragen aan de bezoeker. Aangezien elke gsm maar één IMEI nummer heeft, kan een persoon steeds herkend worden indien deze hetzelfde IMEI nummer ingeeft. De website kan zélf nagaan of het ingegeven IMEI nummer echt is of vals Onderzoek Gedetailleerder onderzoek brengt een aantal nadelen naar boven. Zo blijkt het IMEI nummer niet volledig uniek te zijn over de ganse wereld. Volgens CEIR (Central Equipment Identity Register) zou 10% van de in gebruik zijnde nummers niet uniek zijn [35]. Dit kan vals positieve reacties geven en zo een persoon die toevallig hetzelfde IMEI heeft, blokkeren. Gezien het een gewoon nummer is, kunnen mensen ook zelf IMEI nummers bedenken. Een controlegetal op het IMEI nummer kan het willekeurig gokken van nummers moeilijker maken. Een oplossing zou kunnen zijn om naast het IMEI nummer ook het merk en typenummer van de mobiele telefoon te vragen. Deze gegevens kunnen eveneens nagegaan worden via de website van International Numbering Plans, en kan zo als extra beveiliging dienen. De kans dat iemand een nummer zelf raadt waarbij het controlegetal correct is, en ook het merk en type juist zijn, is relatief klein. Een demonstratie is op de foto 3.9 gemaakt waarbij het IMEI nummer van een gsm is opgezocht op de International Numbering Plans website en waaruit effectief blijkt dat het merk en typenummer opgezocht kunnen worden. Toch is dit uiteindelijk geen veilige oplossing. De website van International Numbering Plans is openbaar toegankelijk. Mensen kunnen het zelf verzonnen nummer opzoeken en nagaan bij welke gsm het hoort [36].

36 3.4 GSM-identificatie 23 Figuur 3.9: Het IMEI nummer van een gsm geeft merk en type terug. Het bestaan van generatorscripts maakt het kwaadwillige bezoekers nog eenvoudiger. Met deze generators kan je correcte IMEI nummers genereren, waarbij je tevens het merk en type gsm kan kiezen [37]. Op figuur 3.10 is er een demonstratie getoond. Links zie je het programma met een IMEI nummer gegenereerd voor een Siemens M35i. Indien dit fake nummer gecontroleerd wordt op de officiële website van Numbering Plans komt het nummer inderdaad overeen met een Siemens M35i. Daardoor is ook het idee van identificatie op basis van IMEI nummer niet bruikbaar in praktijk. 3.4 GSM-identificatie Beschrijving De wereldwijde beschikbaarheid van gsm maakt het interessant om tóch een oplossing te vinden gebruikmakend van de mobiele telefoon. Door de auteur werd een concept voor een nieuw systeem ontwikkeld waarbij de gebruiker van de website dient te bellen naar een speciaal telefoonnummer. Vervolgens dient deze een opgegeven code in te geven via het gsm-toestel om zichzelf te kunnen activeren. Door het inbellen is het gsm-nummer van de beller gekend en kan worden geregistreerd. Indien de gebruiker achteraf wordt geblokkeerd, dan komt zijn nummer in de blacklist.

37 3.4 GSM-identificatie 24 Figuur 3.10: Een willekeurig IMEI nummer van een generator opgezocht. Wanneer de gebruiker opnieuw een account wenst aan te maken op de website, zal deze zich opnieuw dienen te activeren. Hetzelfde telefoonnummer zal herkend worden waarna de gebruiker kan geweerd worden. De gebruiksvriendelijkheid ligt hoger dan bij het versturen van een SMS. Bellen met een gsm kan iedereen, terwijl niet iedereen even goed overweg kan met SMS-berichten. Bij een onderzoek naar aanleiding van deze masterproef op SeniorenNet bij mensen blijkt dat 31,6% moeite heeft (of echt niet kan) om SMS-berichten in te typen en te versturen 2. De voordelen van het eerder geïntroduceerde SMS-systeem blijven gelden. Het systeem is gratis voor de website, de bezoeker moet een klein bedrag voor het telefoontje betalen aan zijn eigen gsm-provider. Bovendien is de ingebouwde drempel dezelfde: het verkrijgen van een nieuw gsm-nummer kost moeite, tijd en geld. Het systeem heeft een tweetal nadelen: Privacy. De website kent het telefoonnummer van de gebruiker. Toch dient dit nadeel mensen op SeniorenNet, oktober Vraag: Kan je relatief goed teksten ingeven via het systeem van de gsm waarbij je voor elk cijfer een knop hebt en voor elke letter 1, 2 of 3 keer achter elkaar moet drukken? Het systeem om te SMS en dus? (het gaat om het ingeven van de teksten, niet om het sms en zelf)

38 3.4 GSM-identificatie 25 niet zwaar door te wegen gezien de gemiddelde gebruiker vermoedelijk niet door heeft dat het telefoonnummer werd bewaard. Het telefoonnummer werd automatisch verkregen door te bellen en werd niet door de gebruiker ingegeven. Startkosten. Het ontwikkelen van de nodige infrastructuur voor dit systeem is significant. Naast het aanvragen van een telefoonlijn dient ook het nodige voorzien te worden zodat software de aanvragen kan verwerken, de ingegeven nummers kan achterhalen, enz Architectuur Een schematische voorstelling van de architectuur in figuur 3.11 wordt stap voor stap besproken. 1. Een bezoeker surft naar de website. Hij registreert zich hierop. 2. De website vraagt een unieke code aan zijn communicatiemodule. 3. De website krijgt van de communicatiemodule een unieke code terug, bvb De website toont op de webpagina de code aan de bezoeker, samen met het telefoonnummer waar deze naartoe moet bellen. 5. De bezoeker neemt zijn gsm en belt naar het nummer. Deze geeft ook de unieke code 1234 in. 6. De communicatiemodule stuurt nu naar de website een bericht om mee te delen dat de gebruiker met unieke code 1234 geactiveerd heeft, en dat zijn telefoonnummer X is. De website kan nu al dan niet de activatie toelaten, afhankelijk van het feit dat het telefoonnummer X in de blacklist voorkomt.

39 3.4 GSM-identificatie 26 Website Communicatiemodule User Figuur 3.11: Schematische voorstelling architectuur gsm-identificatie.

40 GECENTRALISEERDE GSM-IDENTIFICATIE MET COMMUNITYFEEDBACK 27 Hoofdstuk 4 Gecentraliseerde gsm-identificatie met communityfeedback 4.1 Beschrijving De nadelen van het voorgestelde gsm-identificatiesysteem worden opgelost door het invoeren van een gecentraliseerd gsm-identificatiesysteem, terwijl de voordelen behouden blijven. In het voorgestelde systeem zal één website/bedrijf alle technische infrastructuur voorzien. Websites die gebruik willen maken van de dienst hoeven zich hierop enkel maar in te schrijven en zelf geen technische infrastructuur te voorzien. Door middel van een aantal (standaard) scripts wordt de communicatie voorzien met de centrale dienst. De startkost wordt drastisch verlaagd. Voor de website zelf zijn er zeer beperkte kosten voor infrastructuur of geavanceerde scripts. Bellen naar een vast nummer vraagt een beperkte kost voor de gebruiker; het telefoontje duurt onder normale omstandigheden minder dan een minuut. De mogelijkheid bestaat dat bepaalde websites de kosten op zich wensen te nemen door gebruik te maken van een gratis 0800-nummer. Het privacyprobleem wordt tevens sterk gereduceerd. De centrale dienst zal niet het gsmnummer (CallerID genoemd) doorgeven, maar in de plaats hiervan een unieke hashwaarde. Hierdoor blijft de privacy van de gebruiker behouden ten opzichte van elke website waarop deze zich inschrijft. Enkel de betrouwbaarheid van de centrale dienst is hierdoor nog van belang en niet meer van de individuele websites.

41 4.2 Voordelen 28 Een extra voordeel betreft de mogelijkheid voor het integreren van zwarte lijsten. Elke bekende pedofiel zou bijvoorbeeld in een lijst opgenomen kunnen worden. Telkens wanneer deze wil registreren op de website kan een extra code meegegeven worden die waarschuwt (of bvb. enkel voor jongerenwebsites). In België is dit erg omstreden. Recent lokte de website StopKinderPorno.com zeer veel protest uit en werd door de overheid van het internet gehaald [38]. In andere landen zoals de Verenigde Staten is men echter op zoek naar een dergelijk systeem [39] [40]. Door te centraliseren komt er tevens een extra mogelijkheid bij: informatie met elkaar delen. Op deze manier kan de community onderling informatie uitwisselen. Websites kunnen aan elkaar doorgeven dat een bepaalde gebruiker ongewenst is, waardoor deze gebruikers veel beter geweerd kunnen worden op alle aangesloten websites. Hiermee wordt een combinatie gemaakt van identificatie en reputatie (ID en reputation). Dit is een element dat diverse problemen kan oplossen voor websites. Niet enkel de identificatie van een persoon, maar ook zijn reputatie (verleden). Het is vergelijkbaar met de echte wereld. De kracht van identiteitskaarten ligt niet enkel in het feit dat iedereen kan geïdentificeerd worden, maar vooral dat de politie vervolgens via een databank kan opvragen wat je verleden is, je strafblad en of je nog openstaande boetes hebt. Op het internet kunnen websites op deze manier nagaan of een gebruiker gekend is voor spam, illegale content of ruziemaken en zo al dan niet kan beslissen om de gebruiker toe te laten op de website. Een volledige voorstelling van de mogelijkheden en relaties is samengevat in het schema in figuur Voordelen Om de voordelen van het voorgestelde systeem samen te vatten werden de verschillende onderzochte technieken in een tabel samengebracht. De tabel 4.1 is vergelijkbaar opgesteld met het overzicht uit de state-of-the-art studie.

42 4.3 Architectuur 29 We ebsite False negative ** ***** *** ***** ***** Drempel omzeilen *** ** * **** **** Wereldwijd ** ***** ***** ***** ***** Ontwikkeltermijn ** **** **** **** **** Kost/gebruiker *** ***** ***** **** ***** Startkosten ** *** ***** *** **** Opbrengsten nee nee nee mogelijk mogelijk Gebru uiker False positive ** ***** *** ***** ***** Privacy ***** ** **** ** ***** 1 Gebruiksvriendelijkheid ***** **** ** **** **** Kosten ***** **** ***** ***** 2 ***** 2 1: onafhankelijke controleerbare organisatie (contracten overheid, ) 2: 0800 nummer kan gebruikt worden Figuur 4.1: Vergelijking technieken. 4.3 Architectuur Een schematische voorstelling is te vinden op de figuur 4.2. Een bespreking van elke stap volgt. 1. Een bezoeker surft naar de website. Hij registreert zich hierop. 2. De website vraagt een unieke code aan de centrale dienst (register). 3. De website krijgt van het register een unieke code terug, bvb De website toont op de webpagina de code aan de bezoeker, samen met het telefoonnummer waar deze naartoe moet bellen.

43 4.3 Architectuur De bezoeker belt met gsm naar het nummer. De bezoeker komt nu rechtstreeks terecht bij de centrale dienst. Deze gebruiker geeft de unieke code 1234 in. 6. Het register weet aan welke website het de code 1234 uitgegeven heeft, en kan zo de juiste website contacteren. Naar de website wordt toegestuurd dat de gebruiker met unieke code 1234 geactiveerd heeft, en dat de unieke code van de gebruiker hash(callerid X) is. De website kan nu al dan niet de activatie toelaten, afhankelijk van het feit dat de hash in de blacklist voorkomt. Feedback Register Website 4 1 User Figuur 4.2: Schematische voorstelling registratie bezoeker op een website. Het proces is identiek indien dezelfde gebruiker zich op een andere website gaat registreren. Op de figuur 4.3 zijn dit de pijlen 7 tot en met 12.

44 4.3 Architectuur Feedback Register Website 4 1 User 7 10 Website Figuur 4.3: Schematische voorstelling tweede registratie en blokkering bezoeker. Community feedback komt er indien de tweede website de gebruiker nu gaat blokkeren, voor bijvoorbeeld spam. De website stuurt dan de hash van de geblokkeerde gebruiker naar de centrale dienst (feedback) in pijl 13, samen met de reden spam. De centrale zoekt op welke websites dezelfde gebruiker zich geregistreerd heeft. Elk van deze websites krijgt nu een update van de reputatie van de gebruiker in de vorm van een rating (pijlen 14 t.e.m. 18). Hoe hoger dit positief getal is, hoe slechter de reputatie. Ook indien de gebruiker zich nu op een andere nieuwe website gaat registreren, krijgt de website de rating van de gebruiker door (in pijl 6 of 9) en kan ze vervolgens beslissen om de gebruiker al dan niet toe te laten, of haar moderators de opdracht te geven om de gebruiker extra in het oog te houden. Het verloop van de interne verwerking op een hoog niveau bekeken wordt getoond op het schema in figuur 4.4. Links bovenaan belt de gebruiker met zijn gsm. Deze geeft de code in, en de callerid wordt vervolgens doorgegeven aan de controle-eenheid. Die gaat de website opzoeken waar de aanvraag vandaan kwam op basis van de ingegeven code in de PendingRequests databank.

45 4.3 Architectuur 32 Vervolgens kan de rating van de gebruiker opgezocht worden door middel van de feedback informatie (verleden van de gebruiker). Indien er nog geen hash bekend is van de gebruiker wordt een hash gegenereerd. Deze informatie wordt vervolgens door de controle-eenheid gecombineerd en gestuurd via SOAP naar de website waar de gebruiker zich wenst te activeren. PSTN Webinterface Controle PendingRequests Rating FeedbackDB Hash Bellen gsm CallerID, code Code site CallerID CallerID Score, datum Score, datum Code, hash, datum, score CallerID, site Hash Hash, code, site, datum, score CallerID, site, hash Figuur 4.4: Sequentiediagram webservice bij registratie. Een tweede belangrijk onderdeel is wanneer een website een ban doorgeeft (zie figuur 4.5). Deze feedback komt via SOAP binnen op de webinterface. De informatie wordt door de controle-eenheid verwerkt. De rating wordt verwerkt in de feedback database en een nieuwe rating wordt aangemaakt.

46 4.4 Veiligheid: CallerID falsification 33 Vervolgens wordt opgezocht welke websites tevens deze gebruiker geregistreerd hebben. Die informatie gaat terug naar de controle-eenheid die vervolgens elk van de websites gaat contacteren via SOAP om de nieuwe rating (score) van de gebruiker door te geven. PSTN Webinterface Controle PendingRequests Rating FeedbackDB Hash Hash, feedback, site Hash, nieuwe score Hash, nieuwe score Hash, nieuwe score Hash, feedback, site Hash, feedback, site Sites, hash, nieuwe score Site, hash, nieuwe score Site, hash, nieuwe score Site, hash, nieuwescore Update OK Sites? Sites, hash, nieuwe score Figuur 4.5: Sequentiediagram webservice bij melding ban. 4.4 Veiligheid: CallerID falsification De veiligheid van het systeem werd uitgebreid onderzocht. Het moet zeker zijn dat mensen hun telefoonnummer (CallerID genoemd) niet kunnen vervalsen (CallerID falsification) indien men belt naar de service. Bij SMS was dit wel het geval.

47 4.5 Telefoonsysteem 34 CallerID s worden op grote schaal gewijzigd op een legale manier door bedrijven. Bedrijven gebruiken dit bijvoorbeeld om hun honderden uitgaande telefoonlijnen allemaal hetzelfde nummer als CallerID te geven. Elke werknemer heeft een rechtstreeks nummer, maar een klant die terugbelt komt zo steeds bij de receptie terecht en contacteert niet de individuele werknemer. Het gaat hier telkens wel over vaste telefoonlijnen. Er zijn een aantal gevallen bekend van CallerID falsification. In 2004 is er een website Star38.com geweest die deze dienst toegankelijk maakte voor iedereen. Deze werd echter zeer snel gesloten. Er zou tijdelijk een VOIP lek geweest zijn bij een bepaald bedrijf waardoor de CallerID kon worden vervalst. Dit lek werd echter snel terug gedicht. Door middel van het versturen van speciale frequenties nadat opgenomen wordt zou de CallerID kunnen beïnvloed worden [41] [42]. Deze voorvallen vormen geen ernstig probleem. In diverse landen waaronder de Verenigde Staten is het nu illegaal om de CallerID te vervalsen. Mensen begaan op die manier een misdrijf indien men het toch zou doen. Bovendien vraagt het zeer veel technische kennis. De reden waarom ook gekozen wordt voor het bellen met een gsm-toestel is omdat hiermee het vervalsen van de CallerID niet mogelijk is. De CallerID wordt via een ander kanaal verstuurd dan de audio. Tot op de dag van vandaag zijn hiervoor geen technieken of gevallen gekend die de CallerID via gsm zouden kunnen vervalsen. Er mag aangenomen worden dat het vertrouwen op de CallerID als authenticatie voor de website voldoende veiligheid biedt. 4.5 Telefoonsysteem Het systeem dat verbonden is met de telefoonlijn is het belangrijkste onderdeel omdat het de interface is naar de gebruiker. Het bellen en doorgeven van de code gebeurt via de telefoonlijn. Een telefoonlijn werd aangevraagd en gelegd in het datacentrum: 02/ De telefoonlijn die toekomt op de server dient verstaan te worden door de server. Cijfers die de gebruiker indrukt moeten herkend worden, terwijl er ook iets moet gezegd worden

48 4.5 Telefoonsysteem 35 naar de beller toe. Hiervoor moet de server over capaciteiten beschikken om met de telefoonlijn overweg te kunnen. Internationaal is Loquendo TTS de meest bekende. Het is echter een professioneel en betalend programma. Een gratis open source programma dat hetzelfde werk kan verrichten is Asterisk. Een extra plug-in voor Asterisk zorgt ervoor dat we vanuit PHP kunnen communiceren naar de telefoonlijn. Figuur 4.6: Logo Asterisk en Loquendo. Het enige middel voor communicatie met de beller is geluid. Er zijn twee manieren om audio te genereren naar de telefoonlijn: ofwel via een tekst-naar-spraak (text-to-speech) programma, ofwel via op voorhand opgenomen audio. Er werd gekozen voor het systeem met zelf opgenomen audio. Text-to-speech komt onvoldoende natuurlijk over, waardoor het systeem als te artificieel ervaren wordt en de drempel verhoogt voor de gebruiker. Volgende normale stappen komen voor: Verwelkoming van de beller De mogelijkheid om helpinfo op te roepen Vraag naar de code Bedanken voor ingeven van de code... Er zijn eveneens foutsituaties die opgevangen dienen te worden: Foute code ingegeven Gebruiker sluit code niet af met # Vervallen (oude) code

49 4.5 Telefoonsysteem 36 Code reeds geactiveerd Gebruiker zit in zwarte lijst (van centrale service) Te vaak foutieve poging Gebruiker belt via vaste lijn Gebruiker belt met privé nummer Onbekende fout... Voor elke situatie werd een tekst opgesteld en ingesproken. Aangezien een vrouwenstem aangenamer overkomt werd hiervoor gekozen. De audio werd opgenomen met professionele audiosoftware Adobe Audition. 44,1 khz, stereo, 16-bit in WAV-formaat om maximale kwaliteit bij opnames te behouden. De opnames namen ongeveer een halve dag in beslag. Achteraf werd de audio door middel van mastering optimaal gemaakt: ideaal geluidsniveau (amplitude amplify), ruis verwijdering (adaptive noise reduction en FFT (Fast Fourrier Transform) 4096 points noise reduction met profiel), enz. Pas op het einde werd de audio omgezet naar telefoonkwaliteit [43]. Een overzicht van het volledige systeem dat de gebruiker doorloopt is te zien in figuur 4.7. Elke audio staat in een gele kader. Bij elke pijl staat aangegeven wat het event is. Bij de ontwikkeling werden een aantal beslissingen genomen. Een beschrijving van de werking en de redenen waarom hiervoor gekozen werd zal hieronder gegeven worden. Vaste telefoonlijn Bij het opnemen wordt eerst nagegaan wat het telefoonnummer is van de gebruiker. Het systeem verplicht dat er een gsm-nummer dient gebruikt te worden uit veiligheidsoverwegingen. Indien een gebruiker belt met een vaste telefoonlijn wordt dit opgevangen en hij krijgt hiervoor een audioboodschap. Om na te gaan of iemand belt vanaf een gsm-nummer of een vaste lijn wordt de CallerID geanalyseerd. Een telefoonnummer begint eerst met de landcode (voor België 0032), en dan gevolgd door het nummer van ofwel de gsm of de vaste lijn.

50 4.5 Telefoonsysteem 37 Figuur 4.7: Toestandsdiagram telefoonsysteem.

51 4.5 Telefoonsysteem 38 In België begint elk gsm-nummer met het getal 4 (denk aan 0495, 0485, 0476,...). Internationaal is dit in elk land anders. Om het systeem ook toegankelijk te maken voor mensen die vanuit het buitenland bellen, dient dit mee opgenomen te worden in het systeem. Daarom heb ik een reeks codes opgezocht van een aantal belangrijke landen. De landcode vinden van elk land is eenvoudig, het achterhalen van de gsm-codes spijtig genoeg niet. In de tabel 4.1 wordt steeds de landcode vermeld en de kolom ernaast het getal waarmee elk gsm-nummer begint. Deze gegevens werden geïntegreerd in de software zodat er momenteel 29 landen ondersteund worden. Deze lijst kan in een later stadium uiteraard verder uitgebreid worden. De tabel wordt als volgt gelezen: De landcode van Finland is Het nummer van een Finse beller zal daarom beginnen met Indien het om een gsm-nummer gaat, zal daarna het getal 4 volgen, of het getal 50, en dan een nummer. Indien aan één van deze twee voorwaarden voldaan wordt, zal het nummer een gsm-nummer van Finland zijn. Telkens wanneer iemand belt wordt zijn of haar nummer getoetst of het aan één van voorgaande criteria voldoet, zoniet wordt de audio afgespeeld voor vaste lijn. Anoniem bellen Het is mogelijk dat een gebruiker belt met een privélijn. Een eigenschap hiervan is dat de CallerID niet zichtbaar is (indien iemand anoniem belt komt op het scherm anoniem, nummer onderdrukt of nummer onbekend ). Aangezien de authenticatie juist verloopt op basis van de CallerID mag deze gebruiker niet activeren met zijn code. Dit wordt opgevangen en de gebruiker krijgt hiervoor een vriendelijke audioboodschap. Mensen die de nummerweergave uitgeschakeld hebben op hun gsm worden geholpen om dit eenmalig te omzeilen. Er bestaat een speciale code *31# die je voor het nummer kan plaatsen. De gsm-provider herkent deze code en stuurt dan eenmalig de CallerID wel door. Dus in plaats van te bellen naar , bel je naar *31# Code Er werd gekozen om de lengte van de code die een gebruiker dient in te geven variabel te maken. Dit is een afweging tussen gebruiksvriendelijkheid en schaalbaarheid. Door de lengte variabel te maken is het eenvoudig om 10x meer codes in omloop te kunnen hebben door gewoon de cijferlengte met één te laten toenemen. Om te weten wanneer de gebruiker de hele code ingaf, wordt gevraagd het cijfer af te sluiten met het teken #. Zo start de verwerking van de code niet alvorens de gebruiker de volledige code ingaf. Het

52 4.5 Telefoonsysteem 39 kan immers zijn dat de ene gebruiker een code van 3 cijfers dient in te geven, terwijl een andere misschien wel 6 of 7 cijfers dient in te geven. Er wordt voorzien dat een gebruiker vergeet om het #-teken in te drukken. Indien na 10 seconden geen #-teken werd ingedrukt, wordt er een speciale audio afgespeeld om te vragen om alsnog het #-teken in te drukken. Indien de gebruiker dit opnieuw niet doet, zal terug vanaf het begin gestart worden en de volledige audio afgespeeld worden om te vragen de code in te geven. De gebruiker was misschien gestopt omdat deze bvb. een fout had ingedrukt. Codes zijn slechts beperkt bruikbaar. Na een bepaalde periode zijn de codes niet meer te gebruiken om te activeren. De houdbaarheid van een code wordt gekozen door de website waarop de gebruiker zich wil registreren. Zij kunnen in aantal uur kiezen hoelang de code beschikbaar blijft, met een maximum van 7 dagen. De beperking zorgt ervoor dat het aantal codes niet uitgeput geraakt. Zelfs als het systeem extreem populair wordt, kunnen op deze manier codes na een bepaalde tijd hergebruikt worden, waardoor codelengtes korter gehouden kunnen worden en de gebruiksvriendelijkheid maximaal blijft. Nadat een code vervallen is, wordt deze nog niet onmiddellijk opnieuw in circulatie genomen en blijft ze nog een tijd in quarantaine. Momenteel blijft een code nog 1 maand geblokkeerd, al kan deze termijn eenvoudig gewijzigd worden. Dit biedt de mogelijkheid om gebruikers die toch te laat hun code willen activeren een aangepaste boodschap te laten horen. De audioboodschap legt hen dan duidelijk uit dat de code vervallen is en dat ze een nieuwe moeten aanvragen. Na de quarantaineperiode wordt de code terug vrijgegeven en kan ze opnieuw gebruikt worden. Blokkering Er is voorzien dat een gebruiker door de website zelf kan geblokkeerd worden. Dit kan om meerdere redenen voorkomen. Indien de gebruiker op basis van de privacywet stopzetting van de verwerking van zijn gegevens heeft gevraagd zal hij niet meer kunnen activeren. Zo voorkomen we dat iemand met een slechte rating toch terug binnen zou kunnen. Maar ook andere redenen van blokkering kunnen voorkomen. Bijvoorbeeld iemand die het systeem wil aanvallen door (geautomatiseerd) duizenden telefoons te doen naar het systeem.

53 4.6 SMS rating feedback 40 3 pogingen Indien een gebruiker een foutieve code ingeeft, krijgt hij/zij hiervoor een audio afgespeeld. Het kan bijvoorbeeld voorkomen dat iemand een foutje heeft ingedrukt. Men kan dan opnieuw proberen om de juiste code in te geven. Er is een limiet van 3 pogingen om een code in te geven voor de veiligheid van het systeem. Zo wordt voorkomen dat men duizenden codes zou uitproberen om zo andere codes te kunnen raden. Na 3 pogingen wordt een andere audio afgespeeld en wordt vervolgens de lijn verbroken. Onbekende fout Het systeem is erop voorzien dat indien er een onbekende fout optreedt, er een standaard audio zal afgespeeld worden om de gebruiker hiervan te verwittigen. Op deze manier wordt zo gebruiksvriendelijk mogelijk een onbekend probleem naar de gebruiker toe gecommuniceerd. Aangezien er bij het bellen heel wat moet gebeuren (nummer nazien, hash genereren, code opzoeken in databank, sites contacteren,...) kan het gebeuren dat er ergens iets faalt of bvb. de database uitligt. In plaats van plots niets meer te horen, wordt dit opgevangen via een audioboodschap. Gepersonaliseerde activatie Doordat we weten voor welke website de gebruiker zich wilde registreren dankzij de code is het mogelijk om een andere boodschap af te spelen afhankelijk van de website. Zo kan de bevestiging voor SeniorenNet anders zijn dan bijvoorbeeld voor Bloggen.be. Verschillende audio-opnames werden hiervoor al gemaakt, met inbegrip van een algemene boodschap die geen verwijzing geeft naar een welbepaalde website. In een later stadium zou het kunnen dat websites die betalen voor de dienst een gepersonaliseerde boodschap kunnen geven naar de gebruiker, terwijl kleine websites die gratis gebruik maken van het systeem bij activatie enkel maar een algemene audio laten afspelen. Bij de ontwikkeling van de software en database werd reeds rekening gehouden met deze voorziening. 4.6 SMS rating feedback Omwille van privacy redenen (elders uitgebreid uitgelegd) dient de gebruiker verwittigd te worden wanneer zijn rating omhoog gaat. Dit dient via SMS te gaan. Een SMS geautomatiseerd versturen via een website is minder eenvoudig. Enerzijds kan

54 4.6 SMS rating feedback 41 hiervoor een contract worden aangegaan met een extern bedrijf. Prijzen van een SMSbericht liggen hierdoor ongeveer dubbel zo hoog als een normaal SMS bericht 1. Anderzijds kan ervoor gekozen worden om zelf een systeem te ontwikkelen voor de verzending van SMS berichten. Voor deze oplossing werd gekozen. Er werd gebruik gemaakt van de speciale open source software Gnokii (figuur 4.8) die het mogelijk maakt om te communiceren met de gsm via Linux. Een opstelling werd gemaakt met een nieuwe Nokia gsm en SIM-kaart. Figuur 4.8: Logo Gnokii open source software In datacentra zijn gsm-toestellen niet toegelaten. Daarom is het niet mogelijk om de gsm rechtstreeks te koppelen met de centrale service in het datacentrum. Als oplossing werd de gsm bij de auteur thuis gekoppeld aan een Windows Vista pc en door middel van VMWare een virtuele Linux machine geplaatst waarop Gnokii werkt. Een foto van de opstelling waarbij de Nokia gsm aangesloten is op de pc door middel van USB is te zien op 4.9. Omwille van firewall en veiligheidsredenen is het niet mogelijk om vanaf de webserver in het datacentrum rechtstreeks contact te maken met de pc thuis om een sms te laten versturen. Daarom werd het omgekeerd. De Linuxmachine thuis maakt via een crontabopdracht elke minuut contact met de webserver en vraagt de lijst op van te verzenden SMS-berichten. Gezien dit om een gewone http vraag gaat, is dit wel perfect veilig. De thuiscomputer krijgt via de http vraag de lijst van de berichten en nummers waarnaar SMS berichten verstuurd dienen te worden. Een ontwikkeld script verwerkt deze gegevens en gaat vervolgens door middel van Gnokii commando s SMS-berichten versturen met de gsm. 1 Een van de goedkoopste is SMSbox, die echter 0,19 cent/sms vraagt; en een reeks extra eisen stelt ivm verbruik per maand,...

55 4.7 Communicatie met website 42 Figuur 4.9: Nokia gsm gekoppeld via USB 2.0 aan computer met Linux in VMWare. Het voordeel hiervan is dat het systeem goedkoper SMS-berichten kan versturen. In de gsm steekt momenteel een gewone SIM-kaart. Momenteel is het een gewone Proximus Pay&Go kaart, maar dit kan bijvoorbeeld gewijzigd worden naar een abonnement met bvb SMS en per maand of zelfs onbeperkt aantal SMS en om de kosten verder te drukken. Er werd voorzien dat telkens wanneer een ban gerapporteerd wordt, er ook een SMS verstuurd wordt naar het gsm-nummer van de gebruiker. Het schema in figuur 4.10 geeft nog een volledige verduidelijking. 4.7 Communicatie met website Inleiding De nodige communicatie gaat over en weer tussen het centrale systeem en de website op een client-server gebaseerde wijze: Een activatiecode aanvragen Activatie door gebruiker meedelen Ban meedelen van gebruiker

56 4.7 Communicatie met website 43 Figuur 4.10: Schema verzending SMS na binnengekregen ban. Update score meedelen van gebruiker Ban terug intrekken Voor communicatie is gekozen voor SOAP (Simple Object Access Protocol). SOAP is een protocol dat XML-berichten verstuurt over http. De website kan communiceren met de service door middel van standaard gemaakte scripts die de website kan integreren in haar bestaande webpagina s. In totaal gaat het om 5 PHP-scripts met telkens één functie die men krijgt, één configuratiefile en een reeks libraryfiles waar de websitebeheerder niets mee moet doen. Deze laatste voeren het échte werk uit (maar door inkapseling (encapsulation) en informatie verberging (information hiding) hoeft de gebruiker hier niets van te zien). Om de integratie voor de website zo eenvoudig mogelijk te maken is er voorzien dat bij elke aanvraag de website zelf een referentie kan meekiezen. Dit is een string van maximaal 255 tekens die men kan meesturen. Het voordeel hiervan is dat men de eigen interne ID of interne referentie van haar tabel mee in het veld geeft. Bij een respons geeft het systeem

57 4.7 Communicatie met website 44 deze string ook mee terug, zodat de website snel en eenvoudig kan opzoeken waar wàt bij hoort. Dit maakt het mogelijk dat de website gewoon verder kan blijven werken met de eigen interne referenties of ID s zonder teveel te moeten aanpassen in de eigen databank. Men is op deze manier niet verplicht om gebruik te maken van de ID s die door het systeem zelf worden gegenereerd. Men heeft dus de keuze: ofwel de ID s gebruiken die door het systeem geleverd worden (en dus moet men een aantal aanpassingen doen om hiermee te kunnen werken en bewaren), ofwel de interne ID s meesturen via een variabele (mix van beide kan uiteraard ook). Naast een referentie kan ook een sectie worden meegegeven. Dit is ook steeds een stringvariabele van maximaal 255 karakters die men zelf mag kiezen. Deze kan gebruikt worden om mee te geven over welk onderdeel van de website de aanvraag ging. Indien een website bvb. meerdere onderdelen heeft (forum, chat,...) en een gebruiker moet voor elk van de onderdelen apart activeren, kan men via deze manier meegeven voor welk onderdeel de aanvraag was. Zo wordt het mogelijk gemaakt dat dezelfde website toelaat dat dezelfde gebruiker op verschillende onderdelen van de website apart kan activeren, en toch eenvoudig kan terugvinden welke activatiecode voor wélk onderdeel bedoeld was. Zo wordt extra flexibiliteit geboden naar de website toe. Het is uiteraard geen verplichte variabele, maar steeds optioneel Configuratiebestand Het configuratiebestand met naam config vars.inc.php kan de gebruiker eenvoudig aanpassen. In principe kan dit bestand automatisch gegenereerd worden voor de website en hoeft deze hier ook niets voor aan te passen. In het bestand staat de websiteid en de url s van de webservice Een code aanvragen In het voorbeeldbestand website vraagt code.php staat de functie die de website oproept om een code aan te vragen aan de webservice. Het bestand bestaat vooral uit een reeks variabelen die uitgelegd worden en die bijna allemaal optioneel zijn voor maximale gebruiksvriendelijkheid. De website (client) vraagt aan de webservice (server) de code. Voor maximale flexibiliteit zijn er dus wel een reeks variabelen die een website kan opgeven:

58 4.7 Communicatie met website 45 De taal van de gebruiker ($language). Zo wordt een telefoonnummer gekozen zodat de gebruiker in zijn eigen taal verwelkomd zal worden. Indien deze variabele niet doorgegeven wordt, zal de standaardwaarde gekozen worden van de taal van de website. Zo is bvb. een Nederlandstalige website die zich registreert waarschijnlijk in 99,9% van de gevallen tevreden met een Nederlandstalig telefoonnummer. De geldigheid van de code ($validity). De website kan kiezen hoeveel minuten de code geldig blijft om te activeren, gaande van minimum 1 minuut tot maximaal 7 dagen. Indien men niets doorgeeft wordt 24 uur (1.440 minuten) als standaard genomen. Type telefoonnummer ($phonenumbertype). Men kan kiezen uit een gewoon lokaal nummer, gratis nummer, 0900-nummer,... Het land ($phonenumbercountry). Afhankelijk van het land wordt een lokaal nummer genomen indien dit mogelijk is. Eigen referentie ($myreference) De referentie die men zelf mag kiezen en eenvoudiger maakt voor integratie van het systeem in de eigen website; optioneel en zelf te kiezen. Eigen sectie ($mysection) Dit kan men meegeven indien men wil weten voor welk onderdeel van de site de gebruiker de code aanvraagt; optioneel en zelf te kiezen. Uitgebreide output ($VERBOSE OUTPUT) Normaal gezien is er geen output, maar door deze variabele op true te zetten krijgt men uitgebreide debugoutput. Een website beschikt dus over een zeer grote flexibiliteit voor het aanvragen van een code. Het kan het type telefoonnummer kiezen, het land en de taal. Op deze manier kan gekozen worden voor het meest ideale telefoonnummer dat voldoet aan de wensen van de website. Een website kan zeer eenvoudig een code aanvragen door een gewone oproep: $responsedata = CodeRequest($websiteID, $language, $validity, $phonenumbertype, $phonenumbercountry, $myreference, mysection, $url code request, $VERBOSE OUTPUT); Vervolgens kan men uit de variabele $responsedata alle informatie halen. Men krijgt volgende informatie terug: De code die de gebruiker dient in te geven

59 4.7 Communicatie met website 46 Datum/tijd wanneer de code werd uitgegeven Datum/tijd tot wanneer de code geldig is Een unieke activatieid; deze is uniek voor elke activatie en zal worden teruggegeven indien de gebruiker ook activeert. Dit is de reguliere manier om een activatie van een gebruiker te koppelen met de originele aanvraag van de code. De taal van het telefoonnummer Het telefoonnummer waar de gebruiker naartoe dient te bellen De eigen referentie die de site meestuurde (string door haar gekozen). Dit is de optionele manier om een activatie van een gebruiker te koppelen met de originele aanvraag van de code De sectie die de site zelf meestuurde (string door haar gekozen). Opvragen gaat op eenvoudige wijze, bvb. $responsedata[ code ] voor de code of $responsedata[ phonenumber ] voor het telefoonnummer. In het voorbeeld PHP script dat men krijgt, staat in commentaar een voorbeeld hoe men elke variabele kan gebruiken, samen met een voorbeeld voor het afhandelen van fouten. Alle communicatie die via SOAP wordt gedaan, is verborgen voor de gebruiker. Dit zijn de berichten die in werkelijkheid worden verstuurd via http. De vraag voor een code (gestuurd door het script vanaf de site die code aanvraagt): POST /webservice/code request.php HTTP/1.0 Host: User-Agent: NuSOAP/0.7.3 (1.114) Content-Type: text/xml; charset=iso SOAPAction: Content-Length: 961 <?xml version= 1.0 encoding= ISO ?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle= xmlns:soap-env= xmlns:xsd=

60 4.7 Communicatie met website 47 xmlns:xsi= xmlns:soap-enc= > <SOAP-ENV:Body> <ns5943:getcode xmlns:ns5943= > <Coderequest xmlns:ns4125= urn:getcode xsi:type= ns4125:coderequest > <websiteid xsi:type= xsd:string > </websiteID> <language xsi:type= xsd:string >DU</language> <validity xsi:type= xsd:string >1000</validity> <phonenumbertype xsi:type= xsd:string >0</phonenumberType> <phonenumbercountry xsi:type= xsd:string >BE</phonenumberCountry> <myreference xsi:type= xsd:string > bla bla bla 32b7</myReference> <mysection xsi:type= xsd:string >mysection</mysection> </Coderequest> </ns5943:getcode> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Het antwoord van de webserver is opnieuw een SOAP bericht in XML-formaat over http: HTTP/ OK Date: Wed, 06 May :49:27 GMT Connection: close X-SOAP-Server: NuSOAP/0.7.3 (1.114) Content-Type: text/xml; charset=iso Content-Length: 970 <?xml version= 1.0 encoding= ISO ?> <SOAP-ENV:Envelope xmlns:soap-env= xmlns:xsd= xmlns:xsi= xmlns:soap-enc= xmlns:tns= urn:coderequest > <SOAP-ENV:Body> <ns1:getcoderesponse xmlns:ns1= > <return xsi:type= tns:activationcode > <code xsi:type= xsd:int >69956</code>

61 4.7 Communicatie met website 48 <issued xsi:type= xsd:string > :49:27</issued> <valid untill xsi:type= xsd:string > :29:27</valid untill> <activation id xsi:type= xsd:string > </activation id> <language xsi:type= xsd:string >DU</language> <phonenumber xsi:type= xsd:string > </phonenumber> <your reference xsi:type= xsd:string > bla bla bla 32b7</your reference> <your section xsi:type= xsd:string >mysection</your section> </return> </ns1:getcoderesponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> In het XML formaat zijn de variabelen te herkennen samen met de doorgestuurde waarden ervan. De website hoeft geen kennis te hebben van deze XML berichten, gezien het analyseren van deze XML-bestanden en omzetten in bruikbare variabelen in de PHP programmacode voor de gebruiker reeds wordt gedaan in de aangeleverde scripts Website krijgt activatie binnen Op het moment dat een gebruiker belt naar het systeem en zijn code correct heeft ingegeven, zal de betreffende website worden verwittigd. Hiervoor gaat er een SOAP oproep naar een pagina die staat op de server van de website. Deze url is gekend bij de service en wordt telkens opgeroepen wanneer iemand op die website activeert. Het telefoonsysteem gaat een oproep doen naar de url en stuurt hierbij volgende variabelen terug: De gebruikte activatiecode door de gebruiker De activatieid die exact overeenkomt met de ID gegeven bij aanvraag van de code zodat de aanvraag en activatie aan elkaar kunnen gekoppeld worden. De datum/tijd dat de gebruiker de activatie deed. De gebruikersid die activeerde. Dit is een unieke hashwaarde van het telefoonnummer. De totale score (rating) van de gebruiker.

62 4.7 Communicatie met website 49 Datum sinds wanneer de gebruiker voor het eerst gekend is bij de webservice (van eender welke website) Het totaal aantal websites waar de gebruiker op geregistreerd is. Het totaal aantal websites dat doorgegeven heeft de gebruiker geband te hebben. Een variabele die extra informatie geeft over de gebruiker. Dit zou het mogelijk maken om in de toekomst extra info door te geven dat het bvb. een admin gebruiker is,... De taal van de gebruiker Het land waar het gsm-nummer vandaan komt waarmee de gebruiker activeerde. Het gsm-nummer zelf blijft geheim, maar zo heeft de website wel een idee uit welk land het telefoonnummer kwam. De referentie doorgegeven door de website zelf bij het aanvragen van de code; dit is de extra manier om eenvoudig de aangevraagde code te linken met de activatie. De doorgegeven sectie van de website waar de gebruiker zich op wilde registreren. De gedetailleerde rating per misbruikcategorie van de gebruiker. Elke variabele is ook hier toegankelijk gemaakt, bvb. de variabele $input[ user total sites registred ] geeft in de PHP code voor de website onmiddellijk het aantal websites waar de gebruiker geregistreerd is. Er is voorzien dat de website down is op het moment dat de gebruiker zich via telefoon heeft geactiveerd. In dat geval gaat de webservice de informatie bewaren in een aparte tabel die als wachtlijn gaat fungeren met een servicediscipline FCFS (First Come First Served). Een speciaal crontab programma wordt elke minuut opgeroepen en zal de gefaalde activaties alsnog proberen te bezorgen bij de website. Elke minuut wordt opnieuw een poging gedaan totdat de website terug bereikbaar is en de activatie kan ontvangen. Op deze manier zorgen we ervoor dat een gebruiker die aan de telefoon hoorde dat zijn activatie correct was, ook daadwerkelijk bezorgd werd bij de website, zelfs indien deze tijdelijk onbereikbaar was. De wachttijd nadat een website terug werkt is op deze manier gemiddeld < 1 minuut. De capaciteit van de database om gefaalde activaties te bewaren in de wachtlijn is in

63 4.7 Communicatie met website 50 principe eindig (gezien de harde schijf beperkt is). Maar de database kan zonder problemen tientallen miljoenen records bewaren, waardoor de kans op een overflow van de wachtlijn verwaarloosd kan worden Website bant gebruiker Op het moment dat een website beslist om een gebruiker te bannen, heeft men de mogelijkheid om dit ook te melden aan de webservice. Zo werken alle websites samen op een communitygebaseerde manier om de reputatie van een gebruiker correct te houden. Zo profiteert elke website van de knowhow van een andere om een gebruiker ook sneller te kunnen weren. Het doorsturen van een ban is even eenvoudig als bvb. een code aanvragen. Een voorbeeldcode werd hiervoor gemaakt in het website vraagt ban.php bestand. Ook bij het doorgeven van een ban is voorzien dat de website eigen interne variabelen kan meegeven om beter te werken met het systeem. Er is ook rekening gehouden met toekomstige mogelijkheden: namelijk dat een website de webservice kan gebruiken om haar eigen interne administratie op orde te houden. Men kan bij de ban namelijk naast een eigen interne referentie ook de naam van de moderator meegeven die de ban uitvoerde en een eigen interne reden opgeven. Deze gegevens kunnen door niemand anders gezien worden, behalve door de website die ze doorgaf. In de toekomst kan zo een adminmodule gemaakt worden waarbij de website gegevens kan opvragen van alle doorgestuurde bans. Men kan zo ook gaan selecteren op alle uitgevoerde bans door bijvoorbeeld een welbepaalde moderator. Dit kan zeer handig zijn. Het moderatorwerk is vaak kwestie van interpretatie. Websites werken dikwijls met vrijwilligers als moderators. Het is niet ondenkbaar dat een moderator om één of andere reden wraak wil nemen of verkeerde mensen bewust gaat bannen. Ook met betaalde moderators valt dit risico niet volledig uit te sluiten. Het is dan achteraf perfect mogelijk om alle bans van een bepaalde moderator ongedaan te maken en zo de rating te herstellen van de mensen die verkeerdelijk geblokkeerd werden. Hetzelfde systeem kan ook handig zijn om statistieken te maken voor de website, of om bijvoorbeeld een andere moderator toe te laten om via het systeem op te zoeken wie de gebruiker blokkeerde en waarom.

64 4.7 Communicatie met website 51 Bij de doorzending van een ban zijn er een reeks variabelen die men kan of moet meegeven. De verplichte zijn: De userid van de persoon die men wil bannen. Dit is de unieke hashwaarde die men meekreeg op moment van activatie van de gebruiker. De categorie van reden waarom men de gebruiker heeft geband. Een getal dat de categorie van misbruik voorstelt (abuse category). Tevens kan men een aantal optionele velden mee geven: De ernst van het vergrijp. Men kan op een schaal van 0 tot 10 doorgeven hoe ernstig men de overtreding vond. Deze waarde is mee bepalend voor de berekening van het aantal extra punten dat zal komen bij de rating van de gebruiker. De reden van blokkering. Dit is een string van 255 karakters die men kan meegeven. Deze informatie kan gezien worden door andere websites. Drie velden die opnieuw helpen om de integratie van de website en gebruiksvriendelijkheid van de service te verbeteren. Er kan een interne reden opgegeven worden, een interne referentie en de naam van de moderator die de blokkering doorvoerde. De aanvraag is opnieuw zeer eenvoudig en slechts één enkele regel: $responsedata = ReportBan($websiteID, $userid, $reasoncategory, $seriousnesslevel, $reason, $internal bannedby, $internal reason, $internal reference, $url ban report, $VERBOSE OUTPUT); De webservice reageert en stuurt via SOAP een aantal gegevens terug. Zo worden volgende gegevens teruggestuurd: De userid, de hashwaarde van de zonet gebande persoon. De banid. Een unieke code voor elke ban wordt uitgegeven. De bedoeling is dat de website deze banid bewaart. Met deze code kan achteraf een ban terug worden ingetrokken en de rating van een persoon terug hersteld worden naar het originele niveau. De interne referentie die de site zelf kon meesturen indien gewenst.

65 4.7 Communicatie met website 52 Datum/tijd sinds wanneer de gebruiker geband is. Dit is normaal de huidige datum/tijd tenzij bvb. indien de gebruiker reeds geband werd door dezelfde website, dan wordt de originele datum/tijd teruggegeven. Ook hier zijn alle variabelen bijzonder eenvoudig toegankelijk via PHP, bijvoorbeeld $responsedata[ banid ] geeft de banid terug. Op het moment dat de website de ban instuurt, wordt een nieuwe rating van de persoon berekend en bewaard in de databank. Deze nieuwe rating wordt bovendien meegedeeld aan elke website waarop de gebruiker geregistreerd is. Elk van deze websites wordt gecontacteerd via SOAP en krijgt een update. Indien de website op dat moment down zou zijn, wordt de aanvraag bewaard in een aparte tabel in de databank die als wachtlijn gaat fungeren met een servicediscipline FCFS (First Come First Served). Een apart crontabprogramma zal vervolgens elke minuut proberen om de bewuste website te contacteren met de nieuwe rating van de persoon. Op deze manier wordt elke website ervan verzekerd steeds de updates te ontvangen, ook al is men tijdelijk down geweest Website trekt ban terug in Het is voorzien dat een website de ban van een gebruiker terug intrekt. De reden hiervoor kan zeer divers zijn. Een website geeft uiteindelijk de gebruiker een tweede kans, de moderator maakte een fout of er was iets anders mis wat aanleiding geeft om de ban terug ongedaan te maken. Enkel en alleen de originele website die de ban rapporteerde aan de webservice kan de ban terug intrekken. Dit door de userid (de hashwaarde) samen met de banid terug te sturen via de functie die uitgewerkt is in website trekt ban terug in.php. Hier staat eenvoudige voorbeeldcode om de ban terug in te trekken. De website geeft dus 2 variabelen mee (verplicht): De userid waarover het gaat. Dit is dus de unieke hashwaarde van de gebruiker. De banid. De ID die men terugkreeg op het moment dat de gebruiker werd geband.

66 4.7 Communicatie met website 53 Een ban terug intrekken kan met volgende eenvoudige functie: $responsedata = Dropban($websiteID, $userid, $banid, $url ban drop, $VERBOSE OUTPUT); Als antwoord krijgt men normaal een OK terug; tenzij er een fout is in de gegevens en bijvoorbeeld de banid foutief is. Op het moment dat een ban terug ingetrokken wordt, gaat de webservice de rating van de gebruiker herstellen zoals deze origineel was. Dit kan worden uitgevoerd doordat bij het aanpassen van de rating specifiek wordt bijgehouden wat de originele rating was en hoeveel erbij gekomen is. Op het moment dat een ban terug ingetrokken wordt, zal de nieuwe rating de huidige zijn, waar de bijgekomen punten terug afgetrokken worden. Merk dus op dat er niet hersteld wordt naar de originele rating, maar dat het effectief bijgevoegde aantal punten er terug afgetrokken wordt. Dit is verschillend voor 2 redenen. De eerste reden is dat indien meerdere websites een ban geven op dezelfde gebruiker, en één ervan de ban terug intrekt, het herstellen naar het originele aantal zou maken dat meerdere bans worden uitgewist. Een tweede reden is dat er elke week punten afgetrokken worden van de rating van de gebruiker. Door het zomaar te herstellen op het originele aantal, gaan zo een aantal weken aftrek verloren en is de gebruiker alsnog benadeeld. Bijvoorbeeld: persoon X heeft op 1 januari een rating van 10; bij een extra ban wordt zijn rating met 3 punten verhoogd naar 13. Stel dat elke week de rating met 1 punt verlaagd wordt. Na 8 weken wordt zijn laatste ban terug ingetrokken. Indien nu de rating terug hersteld zou worden naar 10 zou de gebruiker nadeel ondervinden. Zijn huidige rating is op dat moment 13-8 = 5. Na herstel zou het dan terug op 10 vallen. Moest de laatste ban nooit uitgevoerd geweest zijn, zou de gebruiker intussen op 2 staan. Door het origineel toegevoegde aantal terug af te trekken van de huidige score (5-3 = 2) krijgt de gebruiker zijn werkelijke rating en ondervindt hij geen nadeel van de terug ingetrokken rating. Op moment van intrekking van de ban wordt zijn nieuwe rating meegedeeld aan elke website waarop de gebruiker zich geregistreerd heeft. Zo wordt dus elke website geïnformeerd over het feit dat de rating van de gebruiker verlaagde. Er werd tevens voorzien dat indien de website down zou gaan, dit opgevangen wordt.

67 4.7 Communicatie met website Website krijgt update binnen Het laatste script dat de website voorziet is om updates van een gebruiker binnen te krijgen. Deze updates geven door dat de rating van een gebruiker verhoogd is (na een ban) of juist verlaagd is (na het intrekken van een ban). In de pagina website krijgt userupdate.php staat een voorbeeldscript uitgewerkt voor de website zodat ze dit snel en eenvoudig kan integreren. De website krijgt een oproep die gedaan wordt door de webservice en waarbij volgende variabelen gegeven worden: De gebruikersid die activeerde. Dit is een unieke hashwaarde van het telefoonnummer. De totale score (rating) van de gebruiker. Datum sinds wanneer de gebruiker voor het eerst gekend is bij de webservice (van eender welke website). Het totaal aantal websites waar de gebruiker op geregistreerd is. Het totaal aantal websites dat doorgegeven heeft de gebruiker geband te hebben. Een variabele die extra informatie geeft over de gebruiker. Dit zou het mogelijk maken om in de toekomst extra info door te geven bvb. dat het een admin gebruiker is,... De taal van de gebruiker. Het land waar het gsm-nummer vandaan komt waarmee de gebruiker activeerde. Het gsm-nummer zélf blijft geheim, maar zo heeft de website wel een idee uit welk land het telefoonnummer kwam. De referentie doorgegeven door de website zelf bij het aanvragen van de code; dit is een extra manier om eenvoudig de aangevraagde code te linken met de activatie. De gedetailleerde rating per misbruikcategorie van de gebruiker.

68 4.8 Hashwaarde 55 Merk op dat hier niet de sectie meegegeven wordt van de gebruiker. Hier is dit niet zinvol aangezien het over een gebruiker gaat. Indien deze op een website gekend is op meerdere secties (forum, chat,...) geldt de nieuwe score uiteraard voor elk van die secties. Elke variabele is ook hier zeer toegankelijk gemaakt, bvb. de variabele $input[ user total sites registred ] geeft in de PHP code voor de website onmiddellijk het aantal websites waar de gebruiker geregistreerd is. 4.8 Hashwaarde Wanneer een gebruiker zich activeert via het telefoonsysteem krijgt de website via SOAP een XML waarin een herkenningscode staat voor de gebruiker. Deze unieke code is niet het gsm-nummer van de gebruiker, maar een hashwaarde daarvan. De belangrijkste reden hiervoor is behoud van privacy. De website kent op deze manier het gsm-nummer niet van de gebruiker, waardoor dit nummer ook niet misbruikt kan worden. Gebruikers hoeven zich geen zorgen te maken dat ze na een registratie gaan opgebeld worden door een callcenter om hen iets te verkopen. Bovendien moet dit de drempel verlagen zodat mensen weten dat ze ten opzichte van de website anoniem blijven. Om te voorkomen dat websites onderling hashwaarden gaan doorgeven van gebruikers wordt ervoor gezorgd dat de hashwaarde afhangt van de website. De hash van het gsmnummer van dezelfde persoon zal dus anders zijn naar elke website. Zo dient de centrale dienst altijd gecontacteerd te worden en is het omzeilen van de dienst niet mogelijk. De hashwaarde wordt als volgt berekend (waarbij $ staat voor een variabele): $UserIDForWebsite = sha1($uniquecode1. sha1($websiteid. md5($uniquecode2. $callerid). $RandomStringUserid)); Om de string afhankelijk te maken van de website worden er 2 waarden opgenomen die afhankelijk zijn van de website waar de hash naartoe gaat. $RandomStringUserid en $WebsiteID zijn twee waarden die uniek zijn voor elke website. $RandomStringUserid is een willekeurige string van karakters die wordt gegenereerd bij registratie van de website, $WebsiteID is een positief natuurlijk getal dat uniek is voor de website. $UniqueCode1 en $UniqueCode2 zijn twee geheime strings die mee in de hash worden opgenomen. Het zijn strings die voor elke website en elke gebruiker hetzelfde zijn. Zij

69 4.8 Hashwaarde 56 fungeren als een soort van paswoord en moeten het moeilijker maken om de exacte string te achterhalen waarvan de hashwaarde wordt berekend. $callerid is het telefoonnummer van de gebruiker die op dat moment inbelt. Er worden 2 hashalgoritmen gebruikt. MD5 (Message-Digest algorithm 5) en SHA-1 (Secure Hash Algorithm 1). Het MD5 algoritme wordt gebruikt om het telefoonnummer te combineren met een geheime code tot een string van vaste lengte van 128-bit of 32 hexadecimaal. MD5 alleen is echter niet voldoende veilig. Er zijn voldoende methoden in de literatuur beschreven die aanvallen kunnen uitvoeren op MD5 om zo de originele string te kunnen achterhalen. Daarom wordt de MD5 string gecombineerd met SHA1. De MD5 string samen met een tweede unieke code die afhangt van de website wordt gecombineerd en een hash van berekend. Dit geeft een 160 bit of 40 karakter hexadecimale string. Deze string wordt op zijn beurt opnieuw gecombineerd met een unieke code en er wordt opnieuw een 160 bit of 40 karakter hexadecimale string gemaakt. Deze laatste string is de unieke code van de gebruiker die naar de website wordt gestuurd. Het originele telefoonnummer achterhalen is extreem moeilijk. Het SHA-1 algoritme zou in plaats van 280 op 269 operaties mogelijk kunnen achterhaald worden [44]. Dit zou echter niet volstaan. Vervolgens zou men opnieuw een SHA1 met 269 moeten achterhalen, en dan nog een MD5 string. Een complexiteit van 269 is vooralsnog zeer moeilijk. Tienduizenden tot honderdduizenden computers en de nodige financiën zouden ervoor nodig zijn om dit te kraken. Het is niet van vitaal belang dat het originele telefoonnummer zou kunnen achterhaald worden. Het zou de veiligheid van het systeem niet teniet doen, enkel de voordelen van privacy minder sterk maken. Het is echter bijna niet denkbaar dat iemand dergelijke energie wil steken in het reverse engineeren van de hash. Hash algoritmen hebben nog een tweede nadeel. Er is een kans dat 2 strings afgebeeld worden op dezelfde hashwaarde. Dit is ook logisch om in te zien. Langere strings worden afgebeeld op een kortere string. Gezien de set van mogelijke lange strings veel groter is dan de set van kleinere strings is het normaal dat er botsingen optreden en dubbele hashstrings voorkomen.

70 4.8 Hashwaarde 57 De kans is echter bijzonder klein dat op vergelijkbare strings dergelijke botsingen optreden. Hashalgoritmen als MD5 en SHA-1 zijn juist ontworpen om licht verschillende strings op totaal andere hashwaarden af te beelden. Maar gezien het feit dat de hashwaarde de unieke identificatie is van de gebruiker voor de website, is het belangrijk om rekening te houden met een eventuele botsing. Daarom wordt na elke berekening van de hashwaarde nagegaan of deze uniek is en nog niet voorkwam voor de betreffende website. In het (zeer zeldzame) geval dat dit toch zo zou zijn, wordt er een andere hashwaarde berekend. Dit op volgende wijze: $UserIDForWebsite = sha1(rand(99999, ). $UniqueCode3. $UniqueCode1. sha1($websiteid. md5($uniquecode2. $callerid). $RandomStringUserid)); Het gaat om dezelfde functie, waarbij echter wat in het vet cursief aangeduid is, wordt toegevoegd. Er wordt een random waarde genomen, in combinatie met een derde unieke en geheime string. De $UniqueCode3 moet normaal zorgen voor de zekerheid dat de hashwaarde een totaal andere waarde zal geven. Om de zekerheid nog te verhogen is er een randomwaarde toegevoegd. Na generatie van deze nieuwe hashwaarde wordt opnieuw nagegaan of deze nog niet gekend is in de databank. Theoretisch gezien blijft de kans namelijk bestaan dat deze al aanwezig is, al is deze kans astronomisch klein. Indien dit tóch zou voorvallen, wordt voorgaande functie opnieuw uitgevoerd in een while-lus totdat wel een nieuwe hashwaarde wordt gevonden. De functie rand(99999, ) zorgt ervoor dat bij elke nieuwe uitvoering van de functie telkens een andere waarde in de hash komt, zodat de hashwaarde telkens anders is. Merk op dat de hashwaarde enkel uniek moet zijn ten opzichte van de website waarnaar ze gestuurd wordt. Het is geen probleem indien er eenzelfde hashwaarde zou optreden naar verschillende sites toe. De combinatie hashwaarde en website is uniek. Wanneer er tussen de service en de website wordt gecommuniceerd, is uiteraard steeds de website gekend, zodat de juiste gebruiker kan teruggevonden worden door middel van de hash. Dit geeft als extra voordeel dat bij het opzoeken van een hashwaarde in de database veel minder records moeten doorlopen worden en gewerkt kan worden met een index op de websiteid. Zo kan het terugvinden van een hashwaarde veel sneller.

71 4.9 Rating 58 De hashwaarde is echter niet meer uniek te bepalen op basis van enkel het telefoonnummer. Er kon namelijk ook gebruik gemaakt zijn van een random waarde. Daarom is ervoor gekozen dat de hashwaarde eenmalig berekend wordt voor een gebruiker voor elke website apart. Deze hashwaarde wordt mee bewaard in de databank. Indien dezelfde gebruiker naar dezelfde site terugbelt, wordt de originele hashwaarde opgezocht in de databank en niet opnieuw berekend. Zo is het steeds perfect mogelijk om te achterhalen welke waarde moet gestuurd worden naar welke website. 4.9 Rating Algemeen Elke gekende gebruiker krijgt een rating (groter dan of gelijk aan 0) die zijn reputatie voorstelt. Hoe hoger deze rating, hoe slechter de gebruiker. Er is een rating per misbruikcategorie en een totale rating over alle categorieën heen. Uit de enquête blijkt dat 75,0% van de moderators niet enkel een totale rating wensen maar ook per categorie. Toch heeft ook 25,0% geen boodschap aan de specifieke informatie en wil gewoon een algemene rating. 70,4% van de moderators geeft aan dat ze een gebruiker sneller zouden blokkeren indien deze reeds gekend is voor een vergelijkbaar feit op een andere website. Om de rating zoveel mogelijk te modelleren volgens normaal verwachtingspatroon, wordt rekening gehouden met diverse onderdelen: Geschiedenis gebruiker Ernst vergrijp Soort vergrijp Gewicht van site die gebruiker blokkeert Uit onderzoek bij de moderators blijkt dat een gebruiker die zich net geregistreerd heeft, meer kans heeft om geblokkeerd te worden dan een gebruiker die al lang gekend is. Gebruikers zijn meestal van bij het begin af slecht. Wanneer iemand pas na lange tijd (maanden

72 4.9 Rating 59 of jaren) geblokkeerd wordt, blijkt dit vaak het gevolg te zijn van onenigheid met de moderators. Dit soort blokkeringen is voor andere websites minder erg dan iemand die bijna onmiddellijk voor problemen zorgt. Iemand die minder dan 30 dagen gekend is op de website krijgt hierdoor extra punten in de rating. Mathematisch wordt de berekening gemaakt door het aantal dagen gekend op de website af te trekken van het getal 30. Indien dit getal groter dan 0 is, wordt dit getal gedeeld door 3 zodat het totaal aantal tussen 0 en 10 ligt. Indien het getal kleiner is dan of gelijk aan 0, blijft het op 0 en telt er niets extra bij de rating. Formeel: Waarbij de notatie (...)+ gebruikt wordt om de grootheid max(0,...) aan te duiden. Indien het een positieve waarde heeft wordt die waarde genomen, indien het een negatieve waarde heeft, wordt 0 genomen. Een ban van een grote website is belangrijker dan een ban van een kleine website. Grote websites hebben beter opgeleide en gecontroleerde moderators, terwijl kleine websites mogelijk bestaan uit één enkele gefrustreerde moderator. Hiervoor worden twee parameters berekend die gebruikt worden in het model. Enerzijds de PageRank. Deze PageRank is berekend door Google. De rank ligt tussen 0 en 10 en geeft aan hoe belangrijk de website wordt geacht door Google. Hoe meer websites linken naar de betreffende site, hoe hoger de rank. Een kleine website of een site die juist gestart is, krijgt daarom een PageRank van 0. Deze PageRank wordt opgehaald door middel van een speciaal programma dat dagelijks via crontab loopt. Elke rank die ouder is dan 1 week wordt opnieuw opgehaald zodat de recentste rank gekend is. Anderzijds wordt een OwnRank berekend. Deze ranking wordt gemaakt voor elke website die gekend is bij de service. Ook deze rank wordt via crontab dagelijks gestart, maar voor elke website slechts wekelijks bijgewerkt. Het is een exponentiële schaal die op volgende manier berekend wordt: de website met het hoogste aantal verschillende registraties van bezoekers wordt genomen. Dit aantal wordt nummer 10 op de schaal. Dit getal wordt voorgesteld als het getal X. Van X wordt het logaritme genomen. Dat getal wordt gedeeld

73 4.9 Rating 60 door 10. Voor elk getal van de schaal dat overblijft (0-9) wordt dit getal vermenigvuldigd met het inverse logaritme. Formeel: Voorbeeld: Stel is het aantal gebruikers dat de grootste website heeft. De schaal wordt: Indien een gebruiker slechts op één website geband wordt, maar op vele andere sites gekend is en daar niet op wordt geband, dan wordt de ban minder belangrijk geacht. Het is mogelijk dat de persoon een probleem heeft met een moderator en dus niet algemeen slecht is. Daarom dient de rating minder sterk verhoogd te worden in dit geval. De parameter wordt daarom berekend op basis van het aantal websites waar de gebruiker op geband is, en daar wordt het aantal websites van afgetrokken waarop de gebruiker niet geband is. Om er zeker van te zijn dat de gebruiker reeds enige tijd gekend is op de site, worden enkel sites meegeteld waar de gebruiker langer dan 30 dagen op gekend is. Dit laatste getal wordt beperkt tot 5 om positieve feedback niet teveel te laten meetellen in verband met misbruik (zie verder). In formulevorm geeft dit: Aantal = ((# bans op andere websites voor eender welke misbruikcategorie) - (#sites meer dan 30 dagen gekend en niet geband)) Indien de gebruiker in het verleden ook al een ban heeft gekregen uit dezelfde misbruikcategorie, wordt er een extra van 10 punten bijgerekend. Een recidivist is namelijk slechter dan iemand die iets voor de eerste keer deed. De rating moet aan diverse criteria voldoen en van diverse factoren afhangen. Zo moet er ook rekening gehouden worden met het feit dat het systeem misbruikt zou kunnen worden om iemands rating te beïnvloeden.

74 4.9 Rating Misbruik Er moet rekening gehouden worden met het feit dat mensen de rating willen beïnvloeden, zowel positief als negatief. Een mogelijke negatieve beïnvloeding kan op volgende manier. Door zeer veel kleine websites te registreren op de service, vervolgens iemand zijn gsm te lenen ( stelen ), op elk van de sites te activeren, en vervolgens de gsm terug te geven. Vervolgens laat men de gebruiker op elk van de websites blokkeren waardoor de rating zou toenemen. Om dit te voorkomen werden de PageRank en OwnRank ingevoerd. De PageRank geeft de grootte van de website aan. Kleine websites die maar kort bestaan en amper bezoekers trekken hebben een PageRank van 0. De OwnRank geldt voor het aantal registraties gekend bij de dienst. Pas na een minimum aantal registraties stijgt de OwnRank van 0 naar 1. Dit aantal ligt hoger dan redelijker wijze mag aangenomen worden dat iemand zomaar aan verschillende gsm s kan geraken om te frauderen. Indien zowel de PageRank als de OwnRank 0 zijn, zal de doorgegeven ban niet meetellen, om zo deze negatieve beïnvloeding tegen te gaan. Dergelijke praktijken komen bovendien al snel aan het licht gezien het feit dat bij elke ban de gebruiker per SMS wordt op de hoogte gebracht. Een mogelijke positieve beïnvloeding kan op volgende manier: Door zeer veel kleine websites te registreren op de service. Vervolgens registreert men zichzelf op al deze websites en blokkeert men zichzelf niet. Doordat de gebruiker nu gekend is op vele sites die hem niet blokkeren krijgt hij een betere score. De beïnvloeding is er enkel indien de gebruiker effectief een ban binnenkrijgt. Door dit soort van positieve beïnvloeding zal het aantal punten dat bij de ranking bijkomt iets lager liggen. Bijvoorbeeld 5 extra punten in plaats van 6. Dit wordt gedeeltelijk tegengegaan door te verplichten dat de gebruiker al langer gekend moet zijn op de websites alvorens het positief meetelt. Slechts na 1 maand zal dit kunnen meetellen voor positieve beïnvloeding. Ten tweede werd de positieve beïnvloeding beperkt tot maximaal 5 punten op een totaal van 60, waardoor de invloed beperkt wordt.

75 4.9 Rating Berekening rating Bij een binnenkomende ban wordt het aantal punten berekend dat zal bijgeteld worden bij de huidige rating van de persoon. Hierbij worden alle hiervoor uitgelegde waarden gebruikt. Elk van de waarden ligt tussen 0 en 10. Elke waarde wordt vermenigvuldigd met een parameter pi om bepaalde parameters meer of minder belangrijk te maken. In het huidige systeem zijn alle pi = 1, maar in de toekomst zou bvb. de PageRank minder belangrijk kunnen worden terwijl bvb. de OwnRank als belangrijker wordt geacht. Elk van de parameters kan bovendien verschillend zijn afhankelijk van de misbruikcategorie. Om te voldoen moet de som van alle parameters pi gelijk aan 6 zijn, zodat na optelling de totale waarde tussen 0 en 60 blijft liggen. De 6 waarden die opgeteld worden gaan vervolgens gedeeld worden door 6 om terug tussen 0 en 10 te liggen, en vervolgens afgerond tot een natuurlijk getal.

76 4.9 Rating Totale rating De gebruiker heeft een rating voor elk van de 15 misbruikcategorieën. Door moderators wordt echter ook gevraagd naar een totale rating. In dit geval is men niet geïnteresseerd in gedetailleerde informatie maar in een totale reputatie van de gebruiker. Hiervoor gaan elk van de categorieën opgeteld worden om zo een totale som te geven in een totale rating. Omdat echter elk van de overtredingen niet als even zwaar worden ervaren, dient er nog een gewicht te worden gegeven aan elk van de categorieën. Zo is het zondigen tegen spam minder erg dan stalking of pedofilie. Om de totale rating zoveel mogelijk te laten overeenkomen met wat mensen als natuurlijk ervaren voor ernst van overtredingen werd door middel van een enquête de ernst van elk van de categorieën nagegaan bij de moderators. Voor elke categorie werd daarna de gemiddelde ernst berekend en dan hierop gesorteerd. Vervolgens werd er een normering toegepast zodat het laagste getal (3,7 voor spam) het gewicht 1 kreeg. Elk van de categorieën werd hierop berekend. Vervolgens werden de gewichten afgerond tot op 1 cijfer na de komma. De resultaten zijn te vinden in tabel 4.2. Deze gewichten worden nu gebruikt voor het samentellen van de verschillende ratings om een zo betrouwbaar en natuurlijk mogelijk resultaat te bieden voor totale reputatie (groter dan of gelijk aan 0) van een gebruiker Aanpassing rating in de tijd Mensen vinden het normaal dat iemand zijn of haar leven kan beteren. Zo mag een ban je niet de rest van je leven blijven achtervolgen. Daarom wordt de rating hier ook op aangepast. Er is gekozen om elke week een bepaald aantal punten af te trekken van de rating. Hoeveel er precies wordt afgetrokken werd als volgt berekend.

77 4.9 Rating 64 Voor een zwaarder vergrijp wordt een langere termijn genomen dan voor een lichter vergrijp. Hiervoor werd ook een enquête uitgevoerd en werd nagegaan hoe lang mensen vinden dat iemand moet worden uitgesloten na een bepaalde overtreding. Dit werd nagegaan voor elk van de misbruikcategorieën, en telkens werd gevraagd hoelang men de persoon wilde weren na een lichte of zware overtreding die paste in de betreffende categorie. Het gemiddeld aantal dagen om geblokkeerd te blijven bij een overtreding is te vinden in tabel 4.3. In het finale systeem is er meer onderscheid tussen licht en zwaar, namelijk op een schaal van 0 tot 10. Hiervoor werden zowel de lichte als de zware overtredingen samengeteld. Indien mensen aangaven dat men nooit nog mocht terug binnenkomen werd 3 jaar gerekend. Op internet is 3 jaar zeer lang. Vervolgens werd het totaal aantal dagen berekend dat men zou blokkeren, en vervolgens een gemiddelde. Dit werd berekend met volgende PHP script dat de resultaten verwerkte. $query = SELECT * from specials.thesisonderzoek opgekuist ; $result = $mysql->query($query); $totaalpercentage = 0; while ($data = $mysql->fetch Array($result)) { $i = 0; while ($i <= 15) { if (trim(strtolower($data[ q9 l.$i])) == nooit ) { $totaal l[$i] += 1095; } else { $totaal l[$i] += $data[ q9 l.$i]; } $i++; } $i = 0; while ($i <= 15) { if (trim(strtolower($data[ q9 z.$i])) == nooit ) { $totaal z[$i] += 1095; }

78 4.9 Rating 65 else { } $totaal z[$i] += $data[ q9 z.$i]; } } $i++; Om de vermindering per week te berekenen werd uitgegaan van het feit dat iemand de zwaarste sanctie kreeg met een rating van 10 negatieve punten. Na het aantal berekende dagen in de misbruikcategorie moet iemand met score 10 terug op 0 kunnen komen. Dit wordt gedaan door 10 te delen door het aantal dagen dat de persoon zou moeten geblokkeerd worden, en dit vervolgens te vermenigvuldigen met 7 om het per week te krijgen. Dit geeft voor elk van de categorieën de getallen in tabel 4.4. De cijfers in de laatste kolom worden in het systeem gebruikt om elke week af te trekken van de rating van de gebruiker. Hiervoor werd een programma geschreven dat door de server automatisch elke week wordt gestart. Indien de score na aftrek kleiner dan 0 wordt, zal de score terug naar 0 gebracht worden. Ratings onder 0 zijn niet mogelijk. De totale rating wordt steeds herberekend op basis van de nieuwe ratings van elk van de misbruikcategorieën. De verlaging wordt niet automatisch meegedeeld aan elke website die een rating kent van de gebruiker. Deze wordt enkel meegedeeld aan nieuwe sites waar de gebruiker zich op registreert, of bij specifieke vraag van een website om de score opnieuw toe te sturen. Dit heeft als doel om het verkeer te verminderen dat over en weer moet gaan tussen de websites en de centrale dienst. Indien elke week de nieuwe score van de honderdduizenden gebruikers naar de honderden ingeschreven sites wordt gestuurd, dan zou dit schaalbaarheidsproblemen opleveren. Bovendien is de gebruiker reeds gekend bij de site en zij weten dat de score langzaam afneemt.

79 4.10 Schaalbaarheid Schaalbaarheid De schaalbaarheid (scalability) van het systeem werd eveneens onderzocht Schaalbaarheid op serverniveau De belasting van een enkele oproep is zeer klein. Eén enkele goed geconfigureerde Linuxserver kan op deze manier eenvoudig tienduizenden oproepen tegelijk verwerken. Een zwaardere server of een extra server kan het dubbele aan indien nodig. Alle bellers worden gelijktijdig verwerkt. Gezien de lage serverload die elke gebruiker vraagt, kan er door processor-sharing voor gezorgd worden dat iedereen als het ware gelijktijdig bediend wordt. Omdat het systeem ervoor gaat zorgen dat gebruikers toegelaten worden op een website, is het vervelend indien het systeem zou uitliggen. Indien het systeem succesvol is zouden bezoekers in één klap op honderden of duizenden sites niet meer kunnen registreren. Om dit te voorkomen in de toekomst zou hiervoor een eenvoudige aanpassing kunnen gemaakt worden om de uptime te maximaliseren. Niet enkel aan de kant van het datacentrum kan een aanpassing gebeuren (meerdere servers die invallen voor elkaar bij problemen). Ook aan de kant van de website kan in de scripts een aanpassing doorgevoerd worden. Dit is volledig transparant voor de website, het gaat dan enkel om wat de scripts op de achtergrond doen. Er zou op geregelde tijdstippen (bvb. wekelijks) een aanvraag kunnen gebeuren naar de webservice met de vraag om een lijst te krijgen van alle servers die beschikbaar zijn. Zo kunnen servers geplaatst worden in meerdere datacentra ter wereld. Op het moment dat één van hen down gaat en het script geen verbinding meer krijgt met zijn gewone server, gaat het de andere servers af in het lijstje. Op deze manier is de kans op downtijd bijna nihil. De kans dat meerdere servers in onafhankelijke datacentra tegelijk plat gaan is zeer klein. Elk van de servers in de verschillende datacentra dient over dezelfde informatie te beschikken. Hiervoor wordt een synchronisatie tussen de servers continu uitgevoerd zodat elk van de servers identieke informatie bevatten (op vertragingen van een aantal seconden na). Bij het uitvallen van een server beschikken alle andere servers over de volledige database. Indien de server hersteld wordt, zal er eerst een synchronisatie gebeuren met een van de actieve databanken alvorens de server terug benaderd kan worden door websites.

80 4.10 Schaalbaarheid Schaalbaarheid op het niveau van telefonie Het is mogelijk om meerdere telefoonlijnen te koppelen aan dezelfde server. Het aantal verschillende telefoonnummers is virtueel onbeperkt. Voor elke website kan op deze manier eenvoudig een apart telefoonnummer aangevraagd worden. Wereldwijde telefoonnummers zijn tevens geen probleem. Het is mogelijk om op een server die in Brussel staat telefoonlijnen te laten toekomen met een buitenlands nummer. De prijzen zijn hiervoor bovendien ook niet zo hoog. Enkele prijzen die geldig waren in april 2009 voor een telefoonlijn van volgende landen: Nederland: 16,53 euro per maand Frankrijk: 12,96 euro per maand Verenigd Koningkrijk: 13,91 euro per maand Verenigde Staten: 11,43 euro per maand Thailand: 30 euro per maand Rusland: 120 euro per maand Het is ook mogelijk om de zones te kiezen van het telefoonnummer. Zo zou voor België zowel een 03, 02 als 09 nummer genomen kunnen worden, en voor de Verenigde Staten bijvoorbeeld een telefoonnummer per staat. Deze kunnen allemaal toekomen op dezelfde server. Ook mogelijkheden om te kiezen zijn voorzien. Zo kan een gratis 0800-nummer verbonden worden met hetzelfde systeem en kan een bedrijf zo de telefoonkosten op zich nemen in plaats van de beller om zo de drempel nog verder te verlagen. Ook 0800-nummers van het buitenland kunnen gekoppeld worden. Een probleem zou ontstaan indien een groot aantal gebruikers tegelijk naar hetzelfde nummer zouden bellen. Voor een gewoon nummer betekent dit in praktijk dat een 10-tal gelijktijdige oproepen op hetzelfde nummer geen probleem vormen. Wanneer dit aantal echter systematisch hoger gaat liggen zijn speciale lijnen nodig. Dit zijn speciale E1 connecties die moeten gelegd worden en die zeer duur zijn. De eenmalige setupkost kan hiervoor oplopen tot euro voor de connectie en nog eens euro

81 4.11 Privacy 68 voor speciale hardware voor de server. Voordeel is echter wel dat met deze speciale connecties er tot tienduizenden gelijktijdige telefoonoproepen afgehandeld kunnen worden op hetzelfde nummer. Om het E1-connectieprobleem op te lossen kan geopteerd worden om voor elke website een apart telefoonnummer aan te vragen. Dit komt financieel voordeliger uit Schaalbaarheid naar website Het aantal berichten naar een website blijft beperkt. Enkel bij aanvraag van een registratie, een ban of een activatie zijn er berichten. Deze berichten worden via SOAP verstuurd en zijn relatief klein. Zelfs bij zeer veel gebruikers en websites vormt het geen probleem voor het dataverkeer. De (SOAP) aanvraag van een code is bytes, het (SOAP) antwoord is bytes. Een enkele 1 Mbps datalijn van de server naar het internet kan zo 52 request- en responsaanvragen verwerken. Het is vandaag de dag geen uitzondering meer dat dataservers met het internet verbonden zijn via een gigabit lijn; SeniorenNet heeft bvb. een uplink die mag gaan tot 2 Gbps. Deze lijn zou tot request- en responsaanvragen per seconde kunnen verwerken, wat meer is dan verwacht kan worden van dit systeem. Grotere datalijnen zijn bovendien te verkrijgen indien dit toch nodig zou blijken. Communicatie gebeurt via SOAP wat een protocol is dat maximale ondersteuning geeft naar elke soort van webserver. Hierdoor kan virtueel elke website ter wereld het systeem integreren, ongeacht of die nu gemaakt is in PHP, JSP, ASP, Perl of een andere technologie Privacy Algemeen Het ontwikkelde systeem valt onder de Wet Verwerking Persoonsgegevens (WVP). Rond deze wetgeving werd daarom ook uitgebreid onderzoek gedaan. De werking van het systeem werd bijgestuurd om volledig in orde te zijn met huidige en toekomstige wetgeving. In eerste instantie werd er na eigen onderzoek een vraag tot advies geformuleerd aan de Privacy Commissie, zonder resultaat. Artikel 29 uit de WVP stelt dat de commissie

82 4.11 Privacy 69 enkel advies geeft aan Regering, van de Wetgevende Kamers, van de Gemeenschaps- of Gewestexecutieven, van de Gemeenschaps- of Gewestraden, van het Verenigd College of van de Verenigde Vergadering bedoeld in artikel 60 van de bijzondere wet van 12 januari 1989 met betrekking tot de Brusselse instellingen, of van een toezichtscomité. Advies werd verkregen door de heren Bertel De Groote van het departement Handelswetenschappen en Bestuurskunde van de Hogeschool Gent en tevens van professor emeritus Rogier De Corte. De verwerking van de gegevens valt onder de WVP die stelt in artikel 1 1 dat alles wat voldoet aan volgende beschrijving onder de WPV valt: iedere informatie betreffende een geïdentificeerde of identificeerbare natuurlijke persoon. Als identificeerbaar wordt beschouwd een persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificatienummer of van één of meer specifieke elementen die kenmerkend zijn voor zijn of haar fysieke, fysiologische, psychische, economische,culturele of sociale identiteit. Tevens stelt de wet in Art Deze wet is van toepassing op elke geheel of gedeeltelijk geautomatiseerde verwerking van persoonsgegevens, alsmede op elke niet-geautomatiseerde verwerking van persoonsgegevens die in een bestand zijn opgenomen of die bestemd zijn om daarin te worden opgenomen.. Met het gsm-nummer dat wordt bewaard via een geautomatiseerd systeem kan iemand geïdentificeerd worden, door bijvoorbeeld gewoon naar het nummer te bellen. Het gaat hierbij wel om een naamloos gegeven, dat echter niet mag verward worden met een anoniem gegeven. Bij naamloze gegevens is er geen naam aanwezig, maar kan de identiteit indien gewenst wel achterhaald worden (zoals bij een gsm-nummer), terwijl bij anonieme gegevens dit niet het geval is. De wet WVP is dus van toepassing, want de enige uitzondering staat vermeld in Art Deze wet is niet van toepassing op de verwerking van persoonsgegevens die door een natuurlijk persoon in activiteiten met uitsluitend persoonlijke of huishoudelijke doeleinden wordt verricht., welke duidelijk niet van toepassing is. Momenteel is er geen specifieke wetgeving rond negatieve lijsten (ook wel zwarte lijsten genoemd). Hier komt echter op relatief korte termijn verandering in. Er zijn ontwerpen in de maak om dit ook wettelijk te bepalen. Bij negatieve lijsten gaat het om informatie die doorgegeven wordt en die een negatieve invloed kan hebben op iemands mogelijkheden of

83 4.11 Privacy 70 vrijheden. Gezien het systeem een rating doorgeeft waarop een website kan beslissen om iemand te blokkeren, gaat het hier dus om een negatieve lijst. Om ook voor de toekomst veilig te blijven werd gezocht naar een oplossing om ook te blijven voldoen aan alle wettelijke voorwaarden en eisen. De wet behoudt een aantal rechten voor iemand waarvan de persoonsgegevens worden verwerkt. In artikel 2 van de WVP wordt het recht gegeven Iedere natuurlijke persoon heeft in verband met de verwerking van persoonsgegevens die op hem betrekking hebben, recht op bescherming van zijn fundamentele rechten en vrijheden, inzonderheid op bescherming van zijn persoonlijke levenssfeer.. Er moet duidelijk opgegeven worden wat het doel is. Artikel 4 1 maakt dit duidelijk voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden te worden verkregen. Persoonsgegevens mogen volgens artikel 5 verwerkt worden wanneer de verwerking noodzakelijk is voor de uitvoering van een overeenkomst waarbij de betrokkene partij is of voor de uitvoering van maatregelen die aan het sluiten van die overeenkomst voorafgaan en die op verzoek van de betrokkene zijn genomen;. In artikel 9 1 wordt ook gezegd dat er een aantal gegevens moeten verstrekt worden indien persoonsgegevens worden verwerkt, onder andere de naam en het adres van de verantwoordelijke voor de verwerking en, in voorkomend geval, van diens vertegenwoordiger. Spijtig genoeg is de WVP wetgeving niet altijd evengoed voorzien voor de elementen die worden ontworpen in deze thesis, waardoor er een aantal aanpassingen of speciale constructies moeten gemaakt worden Specifieke details Er werd onderzocht of het bewaren van enkel een hashwaarde van het gsm-nummer (en dus het gsm-nummer zelf niet meer) zou voorkomen dat het systeem onder de WVP zou vallen en dus geen verdere problemen in verband met privacy zou kunnen veroorzaken. Hierover zijn echter de meningen verdeeld, maar uiteindelijk kan worden aangenomen dat het blijft gaan om persoonsgegevens en dat de WVP hier van toepassing blijft. Rechters zouden in deze zin de uitspraak kunnen doen. Ook al zou de hashwaarde strikt in één richting werken, waarbij met de hashwaarde zelf het originele telefoonnummer niet kan worden teruggevonden, dan nog kunnen rechters uitspraak doen oordelend dat de WVP van toepassing is. Dit omdat het een verwerking blijft van een origineel persoonsgegeven. Bovendien zou het niet meer bewaren van het gsm-nummer ook het nut van het systeem geen goed doen, omdat mensen dan strikt anoniem zouden blijven. Ook bij een klacht van

84 4.11 Privacy 71 bvb. de politie zou dan geen gsm-nummer gegeven kunnen worden. Het verwerken van de persoonsgegevens is toegelaten indien er een contract is met de gebruiker en in dit contract de verwerking wordt uitgelegd zodat de verwerking noodzakelijk is voor de uitvoering van het contract. Een contract is voor de wet echter niet enkel schriftelijk en getekend op papier. Daarom is het mogelijk dat een gebruiker die zich registreert bij een website een contract aangaat indien dit duidelijk gespecificeerd is in de algemene voorwaarden. Bovendien vereist de wet dat de gebruiker steeds weet wie de verantwoordelijke is van de verwerking van de persoonsgegevens. Om aan deze eisen te voldoen werd voorzien dat elke website die aansluit bij de centrale dienst een standaard tekst moet opnemen in de algemene voorwaarden voor registratie van haar gebruikers. Elke gebruiker gaat op deze manier een contract aan met de website zélf waarop hij op dat moment registreert. De verantwoordelijke voor de verwerking wordt zo de website waarop de gebruiker zich registreert. In de voorwaarden wordt vervolgens aangegeven dat de effectieve verwerking wordt gedaan door het centrale systeem. Gezien er negatieve informatie kan worden doorgegeven over een gebruiker, kan het voorkomen dat iemand met een zeer slechte rating zijn informatie wil schrappen, om op deze wijze zijn daden uit te wissen. In artikel 12 1 staat Eenieder is bovendien gerechtigd om wegens zwaarwegende en gerechtvaardigde redenen die verband houden met zijn bijzondere situatie, zich ertegen te verzetten dat op hem betrokken gegevens het voorwerp van een verwerking vormen. Om zeker te zijn dat iemand de verwijdering kan vragen van de gegevens wordt beroep gedaan op de uitzondering die in art staat behalve wanneer de rechtmatigheid van de verwerking gesteund is op de in artikel 5, b) en c) bedoelde redenen. Namelijk door een contract aan te gaan met de gebruiker kan hij hiervan de verwijdering niet vragen. Wel is het mogelijk dat de gebruiker het contract verbreekt. Hierdoor moet de verwerking van de persoonsgegevens stoppen. Let echter wel dat enkel de verwerking stopt, de gegevens op zich dienen niet verwijderd te worden. Bij het opzeggen van het contract is het toegelaten om nog eenmalig een verwerking te doen alvorens de verwerking te stoppen. Het is hierdoor mogelijk om elk bestaand lid te verwittigen dat de gebruiker om stopzetting vraagt van zijn gegevens en nog de huidige rating door te spelen. Pas daarna mag er geen verwerking meer zijn van de gegevens en mag de rating niet meer doorgegeven worden aan nieuwe websites die zich registreren bij het systeem.

85 4.11 Privacy 72 De constructie waarbij de gebruiker een contract aangaat met elke website waar hij zich registreert, biedt hierdoor een voordeel voor het systeem (en uiteindelijk een nadeel voor de gebruiker). Indien iemand wenst dat de verwerking van zijn rating stopt, moet hij het contract verbreken met elke website. Een contract verbreken met één website heeft namelijk slechts tot gevolg dat enkel de gegevens van die specifieke website niet meer verwerkt mogen worden, maar nog wel alle andere gegevens van de andere websites (gezien hij met elk van die andere nog een contract lopende heeft). Een gebruiker heeft hierbij nog wel een wapen in handen. Hij kan het contract verbreken waarbij hij recent werd geband. Hierdoor mag de informatie van de ban niet meer verwerkt worden naar de andere aangesloten websites en mag deze niet meer meetellen in zijn rating. Een ban zou zo onzichtbaar worden voor de andere websites. Er mag bovendien niet meegegeven worden dat er beschikking is over negatieve informatie (zonder in detail te gaan), gezien de gegevens niet meer verwerkt mogen worden. De wet laat echter een oplossing toe voor dit zwakke punt. Het is volledig wettelijk in orde om te bewaren dat de gebruiker om stopzetting vroeg, en hierna elke dienstverlening te weigeren. Daarom werd er voor gekozen dat de gebruiker centraal geblokkeerd wordt vanaf het moment dat een gebruiker stopzetting vraagt na een negatieve rating. Hierdoor kan de gebruiker zich niet meer registreren op één van de aangesloten websites. Door volledige dienstverlening te weigeren heeft het totaal geen zin voor een gebruiker om na een negatieve rating stopzetting te vragen. Men krijgt daarna geen toegang meer op geen enkele van de aangesloten websites. Dit gevolg weegt zwaarder door dan een eventuele negatieve rating. In de wet staat in artikel 10 1 De betrokkene die zijn identiteit bewijst, heeft het recht om vanwege de verantwoordelijke voor de verwerking te verkrijgen [...] verstrekking in begrijpelijke vorm van de gegevens zelf die worden verwerkt, alsmede alle beschikbare informatie over de oorsprong van die gegevens en de procedure hiervoor is daartoe richt de betrokkene een gedagtekend en ondertekend verzoek aan de verantwoordelijke voor de verwerking. Er moet ook op gereageerd worden: De inlichtingen worden onverwijld en ten laatste binnen vijfenveertig dagen na ontvangst van het verzoek meegedeeld. Het probleem is echter dat indien iemand zijn identiteit bewijst (in praktijk wordt kopie van paspoort gevraagd) dit niet voldoende is. Enkel met de naam of adres kunnen we geen

86 4.11 Privacy 73 gegevens terugvinden. De wetgever hield geen rekening met het feit dat er, zoals in dit systeem, wel persoonsgegevens worden bewaard (het gsm-nummer) zonder dat de naam of adres van de persoon in de databank gekend zijn. Toch vormt dit juridisch geen probleem. De persoon moet zijn gsm-nummer mee vermelden in dit geval waardoor de opzoeking wél kan gebeuren. Met het feit dat men zo gegevens van iemand anders kan opvragen (door het gsm-nummer op te geven van iemand anders) dient geen rekening gehouden te worden. De wetgever gaat ervan uit dat mensen niet frauderen. Wij als centrale systeem moeten hier geen rekening mee houden en gewoon de gevraagde gegevens verstrekken. Om het nog gebruiksvriendelijker te maken en de schriftelijke procedure zoveel mogelijk te vermijden (aangezien dit kostbare werkuren vraagt) is het mogelijk om online de gegevens rechtstreeks op te vragen. De gebruiker kan dan eenvoudig via de website alle gegevens opvragen. Indien iemand echter overgaat tot de schriftelijke procedure zijn we nog steeds verplicht om ook via de schriftelijke weg te reageren. De gevolgde procedure via de website gaat verder dan wat strikt wettelijk verplicht is. Het is positief naar de gebruiker toe dat we open en eerlijk zijn over de gegevens. De voorgestelde aanpassingen in het systeem werden in praktijk uitgewerkt Toekomst Er werden twee specifieke aanpassingen gedaan aan de architectuur om ook in orde te zijn voor toekomstige wetgeving rond negatieve lijsten. Een eerste aanpassing zorgt ervoor dat de negatieve rating niet onbeperkt blijft meetellen. De wetgever gaat ervan uit dat iemand zijn leven betert. Een negatieve rating mag je dus niet heel je leven blijven achtervolgen (geen finaliteit). Daarom werd ervoor geopteerd om de rating op 0 te zetten indien van een gebruiker gedurende 2 jaar geen bans meer worden ingestuurd. Merk op dat de vermindering per week hiervoor niet werd aangepast. De vermindering per week blijft zoals berekend op basis van de enquêtes. Pas op de dag dat er 2 jaar lang geen ban gekend wordt, zal de rating op 0 geplaatst worden. Wanneer iemand een rating van 200 heeft, en er zou per week één punt afgaan, zou deze na 2 jaar nog een rating hebben van 94. Na 1 jaar en 364 dagen is zijn rating 94, één dag

87 4.12 Systeemkosten 74 later wordt deze dan gereset tot 0. Indien binnen de 2 jaar een nieuwe ban binnenkomt, begint vanaf die dag terug de 2 jaar te lopen. Een tweede aanpassing heeft tot doel schadeclaims te voorkomen. Een gebruiker gaat in de toekomst een forfaitaire schadevergoeding kunnen vragen van duizenden euro indien er een fout werd gemaakt in een negatieve lijst. De geleden schade moet hierbij zelfs niet bewezen worden. Om dit gevaar te voorkomen is het eenvoudig om de gebruiker te verwittigen op het moment dat een negatieve rating wordt ingevoerd. Indien de persoon verwittigd wordt heeft deze de mogelijkheid om bij een fout dit alsnog recht te zetten, waardoor de schadevergoeding niet meer van toepassing is. De wetgever heeft dit ingebouwd met het idee dat mensen soms al jaren op negatieve lijsten staan zonder dit zelf te weten. De gebruiker dient hiervoor gecontacteerd te worden. De enige mogelijkheid hiervoor is het gsm-nummer. Daarom werd in het systeem geïntegreerd dat er een sms wordt verstuurd. Zo wordt de gebruiker verwittigd en is het systeem juridisch in orde. Het zou ideaal zijn indien de aanpassing van de rating pas zou gebeuren 24 uur nadat de SMS werd verstuurd. Dat is op dit moment in het systeem niet het geval, maar dit kan bij invoering van de betreffende wet uiteraard eenvoudig aangepast worden Systeemkosten Om het systeem in praktijk uit te werken, dienen we over de nodige hardware te beschikken. Een schatting van de kosten zijn in volgende tabellen weergegeven. De kosten zijn gegroepeerd als eenmalige en als maandelijks terugkerende kosten Eenmalige kosten (geschat budget) 2 servers die elkaars back-up zijn. Raid voor het tegengaan van falen van een harde schijf, zodat het systeem nog blijft doorlopen. (2 x 4117 euro voor een Quad Core Intel Xeon L5420, 2.5GHz, 2x6M Cache, 1333MHz FSB, 16GB Memory, 667MHz

88 4.12 Systeemkosten 75 (8x2GB Dual Ranked FB DIMMs), 1 TB RAID 1, plus 1 TB voor back-up). Samen: 8234 euro 24 Port Fast Ethernet Stackable Switch: 349 euro Open source Asterisk, open source Gnokii, open source Linux server: 0 euro Installatiekosten, aanvraag telefoonlijn in datacentrum, extra kabels, euro Testkosten: telefoonkosten om naar het systeem te bellen en uit te testen 120 euro Eenmalige kost datacenter: contract aangaan, installatiekost rack, euro TOTAAL (excl. 21% BTW) eenmalig: euro Maandelijkse kosten (geschat budget) Een Belgisch 02-nummer met meerdere oproepen tegelijk mogelijk 14 euro Datacenter: 2 x 116 euro voor racks, plaats, huur, euro Dataverkeer: 1 Mbit, voldoende voor normaal gebruik, kan tot 52 request/responses per seconde aan. Bij groot succes is het vooral deze factor die zwaarder in de kosten zal doorwegen. 100 euro Noodstroom. Indien reguliere stroom uitvalt, zodat het systeem blijft lopen op noodstroom aangeleverd door het datacenter. 25 euro 2e dataprovider. Indien de reguliere glasvezel uitvalt (door bvb. graafwerken), zodat er kan teruggevallen worden op een 2e glasvezel van een andere dataprovider. 50 euro Onderhoud en updaten servers. 2 x 300 euro voor elk van de servers voor update en beveiliging. 600 euro Domeinnaam: 2 x 2 euro, voor 2 domeinnamen, een.com en.be, samen 4 euro. Monitoring: bewakingsfrequentie van elke 3 minuten gedurende 24/7/365, met SMS melding bij problemen door externe service. 22 euro TOTAAL (excl. 21% BTW) maandelijks: euro

89 4.13 Uitwerking in praktijk Uitwerking in praktijk Inleiding Voor deze masterproef werd het volledig systeem, in praktijk gerealiseerd. Gezien het systeem een groot potentieel heeft, wordt ook gepland dit naar de toekomst toe daadwerkelijk te commercialiseren. Om een concept om te zetten in een werkbaar product dienen er een aantal extra elementen te worden voorzien. Denk hierbij aan het bedenken van een naam, een logo, een domeinnaam registreren, een website ontwerpen, voorbeeldscripts maken, enz Naam Een eerste belangrijk onderdeel van commercialisering van het project is het bedenken van een naam. Omdat het systeem wereldwijd gebruikt zou kunnen worden was een.com domeinnaam gewenst. Het vinden van een vrije.com domeinnaam is minder evident. Zowat 90 miljoen dergelijke domeinnamen zijn geregistreerd [45]. Zowat elke combinatie die uitgeprobeerd werd is reeds bezet. Bovendien is het nodig dat de naam Engelstalig is, goed in de mond ligt en goed te onthouden is. Het is belangrijk dat een naam meer vanuit de marketing gekozen werd dan vanuit ingenieursstandpunt. Daarom is het niet nodig om de technologie te verwerken in de naam (dus niet spreken over gsm, authenticatie,...) maar iets dat een gewone gebruiker kan aanspreken. De naam YouValid.com die de lading dekt werd bedacht. You van de persoon waarover het gaat, en Valid van validatie. Jij wordt gevalideerd of jij bent gevalideerd wil de naam dus betekenen. Zo is het een korte en duidelijke marketingnaam voor de gecentraliseerde gsm-identicaitie/authenticatie met communityfeedback. De domeinnaam werd geregistreerd op 25 maart Eveneens werden YouValid.be, YouValidate.com, YouValidate.be en YouAreValid.com geregistreerd. Dit om cybersquatting (domain squatting) te voorkomen en zeker te zijn dat de url s naar dezelfde dienst verwijzen.

90 4.13 Uitwerking in praktijk Logo Ontwerp van een aantrekkelijk en functioneel logo is de volgende stap. Voor YouValid werd uiteindelijk het logo ontworpen in figuur Figuur 4.11: Logo YouValid Het groene ventje slaat op de you (jij). De V stelt het teken voor dat je gebruikt bij het afvinken. De groene kleur werd gekozen omdat dit gevoelens als veilig en in orde oproept. Hiermee straalt het logo de naam uit: jij wordt (of bent) correct gevalideerd. Het logo is dus niet vanuit technologisch standpunt bekeken, maar vanuit het standpunt van de eindgebruiker Website Volgende stap is het maken van een website. Hiervoor werd enerzijds een design gemaakt, en anderzijds de inhoud van de website. Het design dient professionalisme uit te stralen en duidelijk te zijn. zakelijke dienst. Het gaat om een Belangrijk is om de website te richten naar 2 verschillende doelgroepen, en bij het ontwerp hiermee rekening te houden: Website ontwikkelaars Eindgebruikers

91 4.13 Uitwerking in praktijk 78 De website voor de ontwikkelaars moet reclame maken voor het systeem, samen met de nodige technische informatie en mogelijkheden van het systeem. Gezien er vanuit gegaan mag worden dat de ontwikkelaars informatici zijn die Engels kunnen, mag deze website in het Engels staan. Later kan eventueel gekozen worden om ook dit onderdeel te vertalen naar meerdere talen voor internationalisering. De website voor de eindgebruikers is de site die de mensen zien die van de dienst effectief gebruik maken. Het YouValid systeem is normaal gezien transparant voor de gebruiker. Toch is er een website nodig die bijvoorbeeld extra informatie kan leveren in verband met privacy (bijvoorbeeld het opzoeken welke gegevens in de databank worden bijgehouden) en om eventueel bij problemen extra informatie te vinden. Deze website bevat dus totaal andere informatie dan die voor de ontwikkelaars. Bovendien beschikken vele eindgebruikers niet zomaar over de kennis van meerdere talen, waardoor deze website in meerdere talen moet ontwikkeld worden. Om te starten zal de website enkel in het Nederlands beschikbaar zijn, maar later dus ook in het Engels, Frans, Duits en later ongetwijfeld nog vele andere talen. De pagina s werden hiervoor ontworpen en ingevuld met de nodige teksten en informatie. Enkele screenshots zijn te zien op foto Scripts en software Het volledige systeem werd ontwikkeld in PHP als scriptingtaal op een Apache webserver met een MySQL database. De structuur van de tabellen is schematisch voorgesteld in figuur Bij de ontwikkeling van het project werd rekening gehouden met het feit dat het gebruikt zou worden door externe websites. Zo werden er voor elk van de onderdelen voorbeeldscripts gemaakt in PHP. Men kan deze in de toekomst downloaden en aanpassen aan de eigen eisen. De PHP code gebruikt geen functies die op een standaard PHP installatie niet beschikbaar zouden zijn. Zo wordt maximale ondersteuning nagestreefd. Om het zo gebruiksvriendelijk mogelijk te maken werden alle functies voor de externe websites gemaakt, en gezorgd voor abstractie zodat alles steeds toegankelijk is door telkens één functie op te roepen met een aantal parameters. Er is gezorgd voor maximale encapsulatie

92 4.13 Uitwerking in praktijk 79 Figuur 4.12: Beelden van website YouValid.com en eenvoud. Alle verwerking van variabelen, input, output en de SOAP communicatie is verborgen voor de gebruiker. Er werd in de standaard scripts uitgebreide commentaar voorzien in het Engels bij elk van de variabelen zodat het duidelijk is wat elk van de variabelen betekent. Ook wordt er rekening mee gehouden dat er fouten in kunnen staan. Aan de kant van YouValid worden variabelen altijd extra nagezien of ze correct doorgegeven zijn. Op deze manier is het mogelijk om in kwestie van een aantal uur een website aan te passen om te werken met YouValid. Bij wijze van experiment heb ik op slechts één namiddag werk het onderdeel Mailgroepen van SeniorenNet volledig kunnen aanpassen voor Youvalid. Doordat gekozen werd voor SOAP communicatie is het mogelijk om ook websites die geen PHP ondersteunen eenvoudig mee te koppelen aan YouValid. SOAP wordt ondersteund door Java, ASP, C++,... en daardoor is dit het protocol bij uitstek naar elke soort van

93 4.13 Uitwerking in praktijk 80 webserver. Momenteel is enkel PHP beschikbaar. Na de lancering zal er ook gewerkt worden aan een JSP en ASP versie om de ondersteuning nog te maximaliseren Demonstratie Bij de presentatie van de masterproef wordt er een live demonstratie gegeven van de werking van het systeem. De demonstratie zal gebeuren op de YouValid website waarbij de gebruiker zijn privacygegevens kan opvragen. Op deze manier wordt niet enkel het telefoonsysteem gedemonstreerd maar ook de rating getoond. De gebruiker kan zeer eenvoudig zijn privacygegevens opvragen. Dit systeem is identiek gebaseerd op het systeem dat externe websites zouden gebruiken. Voor elk van de onderdelen zijn dezelfde scripts gebruikt en verloopt de communicatie dus ook via het SOAP protocol. De gebruiker surft naar de website en krijgt het telefoonnummer en de code te zien om naar te bellen. Deze codes werden verkregen door een SOAP oproep te doen naar de webservice. De gebruiker kan vervolgens bellen naar het telefoonnummer en activeren. Eenmaal geactiveerd via telefoon zal de website automatisch doorschakelen naar een nieuwe pagina. Er is namelijk een Ajax script in verwerkt dat elke seconde automatisch nagaat of er activatie was, en zo ja, doorschakelt naar de pagina voor detail. Bij de activatie via telefoon wordt door de webservice net zoals bij een andere externe website, een SOAP oproep gedaan naar het privacygedeelte om mee te delen dat er activatie was, en wordt dit zo in de databank bewaard. Vervolgens krijgt de gebruiker op de pagina zijn gegevens te zien: sinds wanneer hij gekend is, hoeveel sites hem geblokkeerd hebben, totale rating en detail rating per misbruikcategorie, welke sites hem wanneer geblokkeerd hebben, datum/uur van elke telefonische activatie, enz. U vindt een screenshot van deze pagina in figuur Omdat het ook nuttig is via telefoon te horen wat er precies gezegd wordt, zal de demonstratie niet via een gewone gsm worden gedaan omdat het niet gehoord kan worden. Voor de demonstratie werd voorzien dat er via een VoIP programma over het SIP-protocol (Session Initiation Protocol) met een computer kan gebeld worden op de telefoonlijn. Zo kunnen de luidsprekers van de computer gebruikt worden. Het programma X-Lite werd

94 4.13 Uitwerking in praktijk 81 hiervoor gebruikt (een screenshot is te zien in figuur 4.15). Er dient op gedrukt te worden dat dit uitsluitend voor de demonstratie mogelijk is gemaakt. Gewone gebruikers kunnen NIET via VoIP activeren, gezien dit de authenticatiewaarde zou ondermijnen Datacentrum De nodige technische infrastructuur werd voorzien en geïnstalleerd om het concept in praktijk te brengen. Doordat de masterproef in samenwerking is met SeniorenNet, kon het systeem geïmplementeerd worden op een bestaande server van SeniorenNet. Aangezien er beschikking is over een zeer krachtige server die slechts een fractie van zijn capaciteit benut, zijn er nog voldoende resources over om een ganse tijd te groeien. De server met zijn bijzondere configuratie werd ook mee opgenomen in de bestaande backups zodat er tevens een permanente back-up van de volledige software en databank loopt in een ander datacentrum in Nederland. Een brand, blikseminslag, diefstal, vandalisme, overstroming of hacker kunnen er dus niet de oorzaak van zijn dat alle informatie uit de databanken definitief verloren gaat. Om snelle respons bij problemen te garanderen is er dubbele monitoring op de servers. Enerzijds controleren de servers elkaar. Bij een probleem wordt er automatisch een SMS verstuurd. Anderzijds is er een server in de Verenigde Staten die het geheel op afstand bekijkt. Zo worden problemen met bijvoorbeeld de uplink, DNS of routering ontdekt die lokaal in het datacentrum niet ontdekt zouden worden. Tevens is er een Remote Power Switch waarmee op afstand een server bij problemen kan worden gereset, zodat een plaatselijke interventie in het datacentrum zelf niet nodig waardoor kostbare tijd wordt bespaard. Een rechtstreeks en apart IP-adres met aparte dataverbinding naar de servers maakt het mogelijk dat ook bij een zeer zware DDoS-attack op de servers kan ingelogd worden via een aparte toegang zodat dergelijke aanvallen weggefilterd kunnen worden. Er is tevens een extra monitorserver die continu niets anders doet dan het netwerkverkeer van alle servers te monitoren om DDoS-attacks zo snel mogelijk te ontdekken, weg te filteren indien mogelijk of een SMS te versturen indien het niet geautomatiseerd weggefilterd kan worden. Op foto 4.16 zijn de effectieve servers te zien die staan in het datacentrum InterXion te Zaventem. De rode pijl wijst naar de effectieve webserver waar het systeem op draait. Andere foto s geven de gang aan waar de servers geïnstalleerd staan in het datacentrum. Rechts

95 4.13 Uitwerking in praktijk 82 zijn twee foto s van de router en switch, waarbij bovenaan de gele kabel de verbinding is met het datacentrum en de glasvezel.

96 4.13 Uitwerking in praktijk 83 Tabel 4.1: Gsm-code en landcode per land Land Landcode Gsm-code Australië België China Cyprus Denemarken Duitsland Finland ,50 Frankrijk Griekenland Hongarije , 30, 70 India Indonesië Italië Japan ,90 Luxemburg Mexico Nederland Nieuw-Zeeland Oostenrijk Portugal Rusland Spanje Tsjechische Republiek ,7 Turkije Verenigd Koninkrijk Zuid-Afrika ,8 Zweden Zwitserland

97 4.13 Uitwerking in praktijk 84 Tabel 4.2: Gewicht voor elke categorie Categorie Ernst Gewicht GEWICHTEN (afgerond) Reclame / spam 3, ,0 Bedreigingen 4, , ,1 Illegale plaatsing content 4, , ,2 Stalking 4, , ,3 Bewust negatieve reacties 5, , ,5 Smaad, eerroof van andere mensen 5, , ,5 Uitgeven voor andere bestaande persoon 5, , ,6 Vulgair gedrag / taalgebruik 5, , ,6 Racisme, politieke boodschappen 6, , ,8 Uitgeven voor een ander geslacht 6, , ,8 Pornografie / kinderpornografie 7, , ,0 adressen verzamelen 7, , ,1 Hacking,... 8, , ,4 Ruziemakers 10, , ,9 Pedofilie 11, , ,2

98 4.13 Uitwerking in praktijk 85 Tabel 4.3: Gemiddeld aantal dagen blokkering per categorie en soort overtreding Categorie Soort overtreding Dagen blokkeren Reclame / spam Lichte 64,3 Vulgair gedrag / taalgebruik Lichte 157,8 Bewust negatieve reacties Lichte 168,1 Ruziemakers Lichte 210,3 Uitgeven voor een ander geslacht Lichte 239,3 Illegale plaatsing content Lichte 284,2 Uitgeven voor andere bestaande persoon Lichte 294,3 Smaad, eerroof van andere mensen Lichte 298,7 Racisme, politieke boodschappen Lichte 309,5 adressen verzamelen Lichte 338,2 Bedreigingen Lichte 427,3 Uitgeven voor een ander geslacht Zware 468,5 Stalking Lichte 494,8 Vulgair gedrag / taalgebruik Zware 500,9 Reclame / spam Zware 540,6 Hacking,... Lichte 578,6 Bewust negatieve reacties Zware 606,8 Racisme, politieke boodschappen Zware 620,4 Uitgeven voor andere bestaande persoon Zware 649,2 Illegale plaatsing content Zware 661,7 Ruziemakers Zware 707,8 Pornografie / kinderpornografie Lichte 713,0 adressen verzamelen Zware 726,0 Pedofilie Lichte 759,1 Smaad, eerroof van andere mensen Zware 793,1 Stalking Zware 798,3 Bedreigingen Zware 809,3 Hacking,... Zware 847,0 Pornografie / kinderpornografie Zware 1.059,3 Pedofilie Zware 1.184,1

99 4.13 Uitwerking in praktijk 86 Tabel 4.4: Vermindering rating per week in aantal dagen Categorie Totaal blokkeren Gemiddeld Verminderen/week Reclame / spam ,115 Bedreigingen ,106 Illegale plaatsing content ,098 Stalking ,090 Bewust negatieve reacties ,076 Smaad, eerroof van andere mensen ,075 Uitgeven voor andere bestaande persoon ,074 Vulgair gedrag / taalgebruik ,073 Racisme, politieke boodschappen ,065 Uitgeven voor een ander geslacht ,064 Pornografie / kinderpornografie ,056 adressen verzamelen ,054 Hacking, ,049 Ruziemakers ,039 Pedofilie ,036

100 4.13 Uitwerking in praktijk 87 Figuur 4.13: Database structuur

101 4.13 Uitwerking in praktijk 88 Figuur 4.14: Screenshot demonstratie met weergave privacy gegevens.

102 4.13 Uitwerking in praktijk 89 Figuur 4.15: Screenshot X-Lite VoIP demonstratie Figuur 4.16: Foto s datacentrum van servers met YouValid op.

103 4.13 Uitwerking in praktijk 90 Figuur 4.17: Relaties webservice, websites en gebruiker.

104 TOEKOMSTPERSPECTIEVEN EN BESLUIT 91 Hoofdstuk 5 Toekomstperspectieven en besluit 5.1 Toekomst Het feit dat het systeem bij de opstart onmiddellijk op SeniorenNet en Bloggen.be kan toegepast worden is een enorm pluspunt om het gelanceerd te krijgen. SeniorenNet heeft een maandelijks bereik van meer dan 1,3 miljoen mensen, Bloggen.be 1,5 miljoen. Het project YouValid is momenteel nog niet gestart. Technisch gezien is alles klaar. Er zijn echter andere redenen om te wachten. Er wordt momenteel nagegaan hoe de technologie beschermd kan worden door middel van een patent en/of hoe er kan samengewerkt worden met andere partners om van het systeem een maximaal succes te maken. Zo zijn er reeds contacten geweest met Dries Buytaert van Mollom en Drupal om samen het systeem te commercialiseren. Dries heeft contacten met diverse grote websites die potentieel geïnteresseerd zijn in het systeem. Om deze reden is de website niet beschikbaar voor het gewone publiek en werd de integratie in SeniorenNet ook nog niet in praktijk bekend gemaakt aan de bezoekers. Een eerste bescherming werd reeds gemaakt via i-depot. Het volledige concept, architectuur en uitwerking werd gedeponeerd bij het Benelux Bureau voor Intellectuele Eigendom, voor een minimumtermijn van 5 jaar, met een optie voor onbeperkte verlening.

105 5.2 Toekomstige mogelijkheid: OpenID Toekomstige mogelijkheid: OpenID OpenID is een systeem waarbij gebruikers kunnen inloggen op een website met een gebruikersnaam en wachtwoord. Het bijzondere aan dit systeem is echter dat je dezelfde gebruikersnaam en wachtwoord kan gebruiken op alle sites die het systeem ondersteunen. Vandaag de dag zijn dat al duizenden websites wereldwijd. Het combineren van OpenId en YouValid zou een interessant potentieel kunnen bieden. Dit rechtstreeks combineren werd onderzocht en is niet mogelijk. Wat echter wel kan is dat er een aparte service wordt opgezet die OpenID gaat combineren met het YouValid systeem en zo een centrale ID database wordt. Op deze manier zou een gebruiker slechts éénmaal moeten bellen en met die gebruikersnaam vervolgens in duizenden websites binnen kunnen. Zo wordt de drempel nog verder verlaagd en wordt een waardevol ID systeem gecreëerd. Dit systeem maakt gebruik van YouValid en kan onafhankelijk door derden gemaakt worden. 5.3 Extra mogelijkheden: microbetalingen Het voorgestelde systeem kan in licht gewijzigde vorm ook toepasbaar zijn voor microbetalingen. Wereldwijd is er vraag naar een goed en gebruiksvriendelijk systeem voor het betalen van kleine bedragen via het internet. Momenteel is hiervoor nog niet veel beschikbaar. Betalingen van enkele eurocenten of euro via Visa zijn erg duur. Het systeem van YouValid kan gebruikt worden voor betalingen door gebruik te maken van betaallijnen. Door het integreren van bijvoorbeeld een 0900-lijn kan de gebruiker op deze manier voor een betaling zorgen. Het systeem kan flexibel gemaakt worden door het gebruik van diverse soorten van betaallijnen. Er bestaan 0900, 0901, 0902, 0903, 0904,... lijnen die elk een andere kostprijs hebben voor de gebruiker. Door elk soort telefoonlijn te koppelen aan het systeem is het mogelijk om een ander bedrag te laten betalen.

106 5.4 Besluit 93 Een beperkt aantal wijzigingen in de architectuur zijn nodig. Zo is er reeds voorzien dat een website bij aanvraag van een activatiecode kan meegeven wat voor soort telefoonlijn zij wenst. Door extra codes in te voeren voor elk soort bedrag kan zo het juiste telefoonnummer teruggegeven worden. Bij activatie krijgt een website de bevestiging. Normaal gezien gaat het dan vooral om de unieke code (hash) van de gebruiker (als authenticatie). Bij betaling echter gaat het dan juist om de ingegeven code door de gebruiker, zodat de website weet dat er betaald werd. Het concept van microbetalingen kan verder onderzocht worden voor verdere uitwerking. 5.4 Besluit Er is grote vraag naar een oplossing voor identificatie van gebruikers op het internet. De diverse bestaande technieken blijken onvoldoende nauwkeurig te zijn of ze zijn onhaalbaar op wereldschaal. Door verder onderzoek blijkt dat het niet evident is een sluitende oplossing te vinden. Authenticatie met SMS bleek interessant te zijn, maar door SMS spoofing niet bruikbaar. Het voorgestelde concept met gecentraliseerde gsm-identificatie voor authenticatie van gebruikers met communityfeedback bleek heel wat mogelijkheden te bieden. Ze is schaalbaar op wereldschaal en heeft weinig nadelen. Het enige zwakke punt zou kunnen zijn dat gebruikers weigerachtig staan tegenover het bellen naar een computer om zich eenmalig te kunnen activeren op een website. Het combineren van ID en reputatie blijkt diverse voordelen te hebben die websites kunnen gebruiken om de sfeer op de website beter te kunnen bewaken. Het biedt tevens economische voordelen zoals een werklastvermindering voor moderators. Door het gecentraliseerde systeem dient de gebruiker zich weinig zorgen te maken rond privacy. Het centraliseren laat tevens toe het systeem op korte termijn te lanceren zodat vele websites hiervan gebruik kunnen maken. De nieuwe techniek zal nog verder uitgewerkt worden om daadwerkelijk gecommercialiseerd te worden: schrijven van een handleiding, vertalen in verschillende talen, enz. Er wordt momenteel gezocht naar partners, alsook een patentaanvraag zit mogelijk in de pijplijn.

107 OVERZICHT VAN BEVEILIGINGSMETHODEN 94 Bijlage A Overzicht van beveiligingsmethoden Elk van de 21 onderzochte systemen wordt in deze appendix kort besproken samen met hun voor- en nadelen. A.1 Cookie Op de computer van de bezoeker wordt een klein bestandje bewaard via de browser (cookie). Telkens wanneer deze terug komt op de website kan zo herkend worden dat hij geblokkeerd werd waardoor hij geen toegang krijgt. Sterke punten van het systeem zijn dat het zeer eenvoudig is, waardoor de startkosten en ontwikkeltermijn verwaarloosbaar zijn. Bovendien is er geen kost per gebruiker. Zwakke punten aan het systeem zijn dat het wissen of blokkeren van cookies ervoor zorgt dat het systeem omzeild wordt. Dit kan zeer eenvoudig en zonder veel computerkennis gedaan worden. Cookies zijn meestal niet permanent, waardoor een blokkering vaak maar tijdelijk is. Ook zijn ze computerafhankelijk. Indien de persoon vanaf een andere pc inlogt kan hij alsnog binnen. Bovendien is de kans op vals positieve aanwezig. Indien meerdere mensen van dezelfde computer gebruik maken, worden ze allemaal geblokkeerd. A.2 IP-adres blokkeren Het IP-adres waarmee de bezoeker op de website komt, wordt door de website geblokkeerd. Bij de eerstvolgende keer dat hij opnieuw wil inloggen op de website, wordt het IP-adres

108 A.3 verificatie 95 herkend en niet meer toegelaten. Er zijn vier sterke punten. Ten eerste zijn er amper kosten verbonden aan het ontwikkelen en integreren van het systeem in de website. Ten tweede is er geen kost per gebruiker en ten derde kan het wereldwijd gebruikt worden. Tot slot is het gebruiksvriendelijk voor eindgebruiker aangezien deze het systeem niet ziet. Er zijn drie zwakke punten aan het systeem. Zo is er ten eerste een hoge kans op vals negatieve. Meestal wijzigt het IP-adres van een gebruiker automatisch. Internetabonnementen van de meeste providers zijn dynamische IP-adressen. Hierdoor wordt de juiste persoon niet meer geblokkeerd, terwijl een onschuldige wel geblokkeerd wordt. Het tweede zwakke punt is dus een reële kans op vals positieve. Gezien IP-adressen roteren bij een provider, zal een andere gebruiker hetzelfde IP-adres krijgen en zo mogelijk niet meer binnen geraken. Ten derde is er een lage drempel om de beveiliging te omzeilen. Het IP-adres is te wijzigen door de gebruiker (bvb. kabelmodem of adsl-modem uittrekken en terug insteken). Ook het gebruik van een anonieme proxysever of het gebruiken van het (onbeveiligd) draadloos internet van iemand anders omzeilt de beveiliging. A.3 verificatie Om zeker te zijn dat het adres dat ingegeven wordt door een bezoeker op de website correct is, wordt verificatie gebruikt. Bij het registreren stuurt men een naar het adres van de gebruiker. Vervolgens dient deze op een link te klikken waarin een unieke code verwerkt zit. Enkel indien het adres wel degelijk van de gebruiker is, kan er worden geactiveerd. Dit systeem heeft vier sterke punten. Ten eerste zijn er relatief weinig kosten om het systeem te integreren in de website. Ten tweede is het systeem wereldwijd inzetbaar en ten derde zijn er geen kosten per bezoeker op de website. En tot slot is er weinig kans op vals positieve. De kleine kans dat een gebruiker in iemand anders naam zou kunnen activeren, is zeer klein. Er zijn vier zwakke punten aan verificatie. Het belangrijkste is dat de beveiliging zonder veel moeite kan worden omzeild. Het is relatief eenvoudig voor gebruikers om aan extra adressen geraken. diensten als GMail, Hotmail, Yahoo, enz. maken het mogelijk om binnen een minuut een nieuw adres aan te maken. Er bestaan tevens

109 A.4 Captcha 96 wegwerp adressen of eenmalige adressen waarmee je eenmalig enkele s op kan laten toekomen en vervolgens het adres niet meer gebruikt. Een andere mogelijkheid bestaat erin om een eigen domeinnaam te registreren en zo een catch all adres te hebben. Hierbij heeft de gebruiker de mogelijkheid om eender wat voor staat altijd te laten toekomen, waardoor een persoon bijna een onbeperkte hoeveelheid adressen kan aanmaken. Providers in binnen- en buitenland zoals Telenet en Skynet maken het mogelijk voor hun gebruikers om via een webinterface op enkele minuten hun adres te laten wijzigen. Een tweede zwak punt is een lagere gebruiksvriendelijkheid, gezien het feit dat er extra actie wordt gevraagd van de gebruiker. Een vierde nadeel ligt bij privacy en spam. Gebruikers geven niet zo graag hun adres, zeker niet in het kader van de actuele spamproblematiek. Een laatste nadeel is de kans op vals negatieve waarbij zonder dat de gebruiker bewust het systeem wil omzeilen, toch terug binnen kan geraken. Mensen wijzigen op internet relatief vaak van adres, waardoor de koppeling met de originele blokkering niet meer gekend is. A.4 Captcha De gebruiker dient bij een captcha een code over te typen die hij ziet. Enkele voorbeelden zijn te zien in figuur A.1. De code is vaak met een speciale achtergrond en moeilijk leesbaar. Het systeem gaat geen gewone gebruikers buitenhouden, maar heeft tot doel om geautomatiseerde registraties tegen te gaan. Captcha is de afkorting van Completely Automated Public Turingtest to tell Computers and Humans Apart. Figuur A.1: Enkele captcha voorbeelden.