Research and Development 1/^Archief/2009-2010/13/Logboek

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Ramon van Sparrentak" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Dennis Brentjes" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Frank van der Graaff" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Note: als kleine opmerking na een bepaalde tijd moesten we een logboek bijhouden voor een afstudeer project vanaf dat moment heb ik alleen dat logboek bijgehouden en zou ik deze aan de hand van die andere updaten. Dit is wel gebeurt maar daardoor is best veel informatie weggevallen omdat deze nou eenmaal niet in dat andere logboek vermeld stond omdat dit logboek een andere focus had dan het standaard logboek van R&D

daarom zie je ook vanaf een bepaald moment alleen maar activiteiten per week en ook niet meer precies wat er gebeurd maar een omschrijving daarvan.

Logboek Cursus R&D1

Week 9

Woensdag 3 maart 15:30 - 17:30

• onderzoek gedaan naar het huidige mail protocol (smtp en de extensies daarop) en hoe deze met spam en veiligheid in het algemeen om gaan. dit blijkt nogal zwaar mee te vallen. het ligt namelijk aan de server die je zelf benaderd hoe goed de beveiliging is. en het is niet al te moeilijk om zelf een server op te zetten en daar de instelling zo te veranderen dat je via smtp 1.0 gewoon mailtjes kan sturen naar iedereen.
• geprobeerd via het telnet protocol een simple mailtje te versturen om te onderzoeken hoe communicatie precies gaat tussen een mailclient en de mail server. overigens niet gelukt. Later is dit overigens wel gelukt het domein moet wel bestaan (zo is de science smtp ingesteld) maar het e-mail adress zelf hoeft dan weer niet echt te zijn.
• onze wiki pagina flink onder handen genomen zodat deze wat leesbaarder en wat meer accesable wordt en makkelijker uitbreidbaar ook wat templates voor commentaar klaar gezet zodat deze makkelijk gecopypaste kunnen worden en dus hergebruikt.

Week 10

9 Maart 12:00 - 12:45

• Dennis: ingelezen in netwerk communicatie in de programmeertaal Java en C++. De vergelijking komt later in de wiki te staan. het komt er in het kort op neer dat de meeste programmeer talen van vandaag een simple concept sockets bevatten. dit kunnen datagram of streaming sockets zijn met respectievelijk udp en tcp protocol data over en weer sturen. hiermee kun je dus een simpel client/server protocol implementeren. maar het lijkt wel of C++ meer "boekhoeding" betreft dan java dit moet later nog eens goed uitgezocht worden als we ontwerp beslissingen gaan nemen.

10 maart ~16:00

• stukje text van gisteren "gesubmit" op de wiki. en opengesteld ter discussie over welke van de twee het handigste lijkt. Het extra werk in c++ wat ik dacht dat er was bleek wel mee te vallen. en er dus op dit moment nog geen voorkeur voor een van de 2 programmeer talen. we kijken of er later een aspect ter sprake komt die wel voor een van deze 2 talen voorkeur heeft.

11-13 maart verschillende tijden

• korte brainstorm sessies in mailverkeer en op de werkplaats over wat ons protocol allemaal moet kunnen. Dit is natuurlijk de verbinden openen en het mailtje zelf verwerken. maar er komen vooral security problemen bij kijken. ons oplossing strategy is namelijk het sturen van spam te ontmoedigen en dit kan door beter identificatie en het moeilijker maken om anonieme mailtjes in bulk te versturen. hier zijn heel wat ideeën onstaan die we 1 voor 1 nagaan op hun validiteit en kwaliteit.

Week 11

14 en 15 maart verschillende tijdstippen

• vooral via de mail en chat programma's gekeken waarom iets wel of niet / beter of slechter werkt dan de andere oplossingen die we bedacht hadden. de uitslag hiervan is dus een rough draft van ons protocol (iets wat we wat concreter hadden willen hebben dan het nu is) en deze staat in de werkplaats onder het kopje nsSMTP. deze zal de komende week meer verfijnd en concreter worden.

16 maart ~ 15:00

• Nog een gat in ons protocol waarbij er weer een verantwoordelijkheid lag bij de server ontdekt(eventueel van een gebruiker met slechte bedoelingen) waarbij het weer mogelijk was om de server zo in te stellen dat je weer ongehinderd bulk mail kon versturen die wel authentiek lijkt voor de ontvanger. Hier is door ons weer over nagedacht en een oplossing voor gevonden waarbij gebruik wordt gemaakt van captcha of iets wat daar op lijkt om authenticatie achteraf te laten gebeuren nadat een mailtje is geweigerd door een client. en door middel van whitelisting te zorgen dat eenmaal vertrouwd deze mailtjes zonder deze achteraf controle wel worden geaccepteerd.

Week 12

23 maart ~ 12:00

• het protocol verder samengesteld van onze ideeën een best wel grote teleurstelling is het feit dat we echt niet onder blacklisten/whitelisting heen kunnen. Dit is namelijk hoe de huidige spamfilters (spam en ham princiepe) ook al de meeste beslissingen nemen over of het daadwerkelijk spam is of niet. Ons protocol kan hier nog steeds iets aan toevoegen namelijk dat spam niet meteen je inbox in vliegt maar eerst nog extra verificatie nodig heeft zodat er zowieso een mens verantwoordelijk is voor het vestuurde bericht en dat de schrijver van de mail een paar seconden extra kost om een mailtje te versturen. Hier ging het ons in de eerste plaats om, het ontmoedigen van het sturen van bulk e-mailberichten. een normaal persoon dat op zijn hoogst 10 mailtjes per dag verstuurd zal hier geen problemen mee hebben, maar een spam bot/persoon heeft hier daadwerkelijk een groot probleem. verder willen wij dat de ontvanger hier het minste last van heeft. nadelen van de huidige implementatie is het feit dat bedrijven hun nieuwsbrieven ook willen versturen, maar dit geeft problemen voor personen die dit bedrijf niet gewhitelist heeft. aan de andere kant als jij een nieuwsbrief wilt ontvangen heb je hier (meestal, anders is het tegen de wet) bewust voor gekozen en is het best mogelijk om het meteen te laten automatiseren dat het e-mail adress gewhitelist word. M.a.w het is nog steeds een goed project ook al zijn er nog wat haken en ogen aan die tijdens de development fase techninsche implementaties voor gevonden moeten worden. Uitgebreide specificatie hier

in de loop van deze week

• besproken over wat we allemaal in het verslag opnemen en in welke volgorde ook al een aantal werkplaatsen aangemaakt in de wiki voor constructieve kritiek op stukjes die in het verslag gaan.

in het weekend

• besproken hoe we de presentatie gaan doen, wie wat doet en nadenken over mogelijk commentaar dat we gaan krijgen we hebben ook besproken dat Dennis de inleiding zou doen, Frank wat algemene informatie over het protocol en Ramon het concrete voorbeeld aan de hand van plaatjes.

• alvast 2 stukjes verslag (prototypes) uitgewerkt en op de wiki geplaatst een over het belang van spam bestrijding en een over de technische implementatie van een client server protocol. hier zal over gepraat worden of deze hoe ze zijn in het verslag komen of dat er nog aan gesleuteld moet worden.

Week 13

maandag

• Vershillende versies van de presentatie gaan rond. met slides die iedereen wil hebben tijdens de presentatie en achtergronden. deze werdt later deze dag samengevoegd tot de uiteindelijke presentatie. nog een korte bespreken over hoelang het gaat duren en wat iedereen concreet verteld zodat er niet al te veel dubbel zit.

Week 16

woensdag

• Overlegd wat we met onze derder partner doen en een afspraak gemaakt voor het maken van een simpel UML klasse diagram voor orientatie en al een structuur overzicht van ons protocol

donderdag

• Uiteindelijk realisatie van een ruw klasse diagram die we voor het grootste gedeelte zo kunnen gaan implementeren. er zijn nog een aantal dingen die niet zeker zijn vanwege het we het gedrag van deze types of functies niet kunnen voorspellen op het moment. ook zijn er een verwachte problemen met het identificeren van nieuwe datastukken omdat we hier unieke bit patronen voor nodig hebt en bijvoorbeeld ascii representatie gebruikt alle 8² bit patronen.

Week 19

• door de vakantie heeft het werk een tijdje stilgelegen althans van mijn kant (Dennis) Ramon heeft tijdens deze vakantie periode wel wat code op "papier" gezet

Woensdag 10:30 - 13:30

• Samen de stukken code bekeken besproken hoe de code nu werkt en of we dit goed vinden. ook de laatste hand gelegd aan een paar klasse waar nog geen invulling voor was. Verder heeft Ramon gezocht naar manieren om signatures te maken en te kunnen signen, iets waar ons protocol naar streeft als extra beveiliging.
• Foutje rechtgezet naar aanleiding van het verkeerd inschrijven voor voortgangsbespreking.
• Besproken wat ons volgende doel wordt namelijk de ontvangende server. we hebben nu onze datastructuren dus om deze inkomende server te realiseren zal niet al te moeilijk worden. De enigste obstakel zal waarschijnlijk het faciliteren van een captcha zijn.

Zaterdag

• Mail contact over afspraak met Daan (de afstudeerstudent) over een vervolg afspraak ook kwam er een vervolg programmeer afspraak ter sprake, maar hier zijn geen concrete tijden voor afgesproken.

week 20

De code nog wat aangepast een aantal dingen toegevoegd en eruitgehaald. Zo zouden we signatures toevoegen maar dit was te lastig en hielp niet om onze doelstellingen te bereiken, daarom hebben we dit maar weg gelaten. Verder hebben we nog wel simpele dingen zoals CC en BCC toegevoegd omdat dit toch wel erg basic is.

week 21

Ramon was ziek (dit wist ik toen nog niet) en heb dus de presentatie alleen moeten voorbereiden en maken. Verder heb ik niks meer van Ramon gehoord en heb deze week verder niks gedaan

week 22

Deze week heb ik vooral geprobeerd contact te zoeken met Ramon. Hier rolde niets concreets uit. Ik heb hem nog geprobeerd te betrekken bij het maken van een test implementatie van ons protocol maar dit is niet gelukt.

week 23

Ik ben begonnen aan de test implementatie van ons protocol dit was erg lastig omdat ik weinig code ervaring heb en omdat er een conceptueel probleem was met ons protocol en de voorziene onderzoeks methode. Hierdoor moest ik het protocol afzwakken en daarmee de testen doen.

week 24

Ik heb het onderzoek uitgevoerd en vervolgens de resultaten geanalyseerd op dit moment kwam ik tot de conclusie dat de resultaten onrepresentatief zijn, door verschillende redenen. Ik wist niet hoe ik hier mee om moest gaan behalve deze te vermelden in het verslag. Verder ben ik begonnnen met het verslag te schrijven dingen zoals het theoretisch kader enzovoorts.

week 25

Deze week heb ik het verlag afgemaakt en de presentatie voorbereid. Verder heb ik groepje 1 hun verslag gepeerreviewed en hierdoor een aantal goede ideeën opgedaan voor mijn eigenverslag.

week 26

Deze week heb ik de presentatie afgemaakt en voorbereid voor de voordracht. verder heb ik iemand (buiten de studie) mijn verslag laten proofreaden en zijn mening gevraagd (vooral over stijl en uitleg van begrippen). Deze was niet zo goed ontvangen, maar hier kwam wel goede feedback over en heb ik mijn verslag nog kunnen aanpassen. Ook het meeste commentaar van de peerreview heb ik geaccepteerd en verwerkt in mijn verslag.