Waarom?

Twitter moet geld verdienen en dat zullen ze op verschillende manieren willen doen. Los van de reeds aangekondigde advertenties in de vorm van Promoted Tweets, zal Twitter ook andere bronnen willen aanboren. Eén van die bronnen gaat de enorme hoeveelheid data zijn die Twitter kan destilleren uit de miljarden tweets van alle gebruikers. Data-minen in die berg is de natte droom van elke marketeer.

In die berg ontbreekt een belangrijk deel aan informatie, nl. de informatie over de links die getweet worden. De meeste links op Twitter zijn die van het verkorte soort, zoals http://mindb.us/1. Zo’n verkorte link zorgt ervoor dat je meer kan met je 140 tekens die je hebt voor een tweet. URL shorteners schoten in de afgelopen jaren als paddestoelen uit de grond, want degene die de url verkort is degene die over de waardevolle data beschikt. Data zoals wie heeft de link geplaatst, welke zijn het populairst, welke links schieten omhoog in populariteit, welke vallen weg, etc.

Bit.ly is de marktleider, maar ook Google met Goo.gl, Facebook met fb.me en zelfs onze eigen, oer-hollandse Hyves met Hyv.es zijn het gevecht aangegaan met een eigen url shortener. Uiteraard heeft Twitter ook een eigen url shortener, t.co om het gevecht met Bit.ly aan te gaan.

Als het Twitter lukt om Bit.ly van de troon te stoten dan zal het ze hoogstwaarschijnlijk wel lukken om de eerder genoemde berg aan informatie in combinatie met de informatie van alle verkorte url’s te veranderen in een berg goud.

Dat zal dus het belangrijkste motief zijn geweest om nu de officiële Twitter-buttons aan te kondigen.

Net niet

We zijn er nog niet helemaal uit, en zolang we de nieuwe Twitter-buttons nog niet echt in werking hebben gezien blijft het speculeren, maar zoals het er nu uitziet zijn die Twitter-buttons het toch echt net niet.

De button is zeer makkelijk te plaatsen op 3 verschillende manieren, maar alle drie die manieren zijn, tja, vreselijk. Optie 1 is met een iFrame. En alhoewel onze Retweet-button ook met een iFrame werkt, zou ik daar liever vanaf willen, want iFrames zuigen. Twitter gaat hier dus niet helpen.

Optie 2 is met Javascript. Dat klinkt beter, alleen jammer genoeg doet dat Javascriptje niks anders dan automatisch de iFrames plaatsen uit optie 1. Jammer.

Optie 3 is een do-it-yourself button met good old HTML, maar die mist dan weer de tweetcount. Dat is helemaal jammer.

Uiteraard gebruikt Twitter z’n eigen shortener als je op de retweet-button klikt, want daar is het uiteindelijk allemaal om te doen. Als zoethoudertje kun je wel een custom url doorgeven om de url van het artikel zelf te overriden. Hier kun je dan de url ingeven die uit je eigen shortener is gekomen, maar Twitter zals die dan toch alsnog verkorten met t.co. Dus dan krijg je twee redirects van twee vershillende shorteners achter elkaar.

En daar wringt de schoen, want veel bedrijven gebruiken een branded url shortener om met hun links ook hun merk te branden. Voorbeelden zijn Pepsi met pep.si, Foursquare met 4sq.com, Yahoo met yhoo.it en Mindbus met Mindb.us. Die bedrijven zullen wel twee keer nadenken voordat ze de nieuwe Twitter-button zullen gaan gebruiken.

Waarom is Twitter de concurrentie met Bit.ly niet frontaal aangegaan door in combinatie met de officiële buttons ook een branded shortener service te leveren? Of is dat iets wat we de komende tijd nog kunnen verwachten? Als ze tegen die tijd dan ook de nodige verbeteringen hebben aangebracht in de manier waarop de buttons worden geplaatst, dan is het de volgende keer wel helemaal raak.

Gerelateerde blogposts:

1. password is geen wachtwoord: 3 regels voor veilige wachtwoorden
2. De coolste url shortener ooit

In welke fase mijn IP adres/browser/karma valt weet ik niet, maar sinds een paar dagen krijg ik via mijn Opera custom search een nieuwe Google result pagina te zien. Als je op een kleine doelgroep wilt testen, dan moet je een Opera gebruiker nemen, dus dat zou er mee te maken kunnen hebben. Niet dat een half procent op miljarden een kleine test zou zijn, maar goed, met Google is het altijd een beetje gokken.

Opvallend zou je wel de enigszins gestylede en vergrote zoek elementen, de afgezwakte ‘secundaire’ links, de opgeleukte logo elementen en natuurlijk de nieuwe toolbar aan de linkerkant kunnen noemen. Daar hebben we eigenlijk de optische verschillen al mee gehad. Na jaren van dezelfde Google doet het opeens wat moderner aan, bijna een beetje Bing…

In ieder geval zet Google duidelijk in op simpel (hoe kan het ook anders?). Duidelijke knoppen, de bekende blauwe links in de resultaten en niet te veel afleiding. Of het moet met (gebruikergestuurde) relevantie te maken hebben. In de jacht naar relevantie geeft Google de gebruiker steeds meer tools in handen. Er waren natuurlijk al wat testjes voorbijgekomen gericht op actualiteit, bij de image search kwamen steeds meer opties en personalised search wordt (weliswaar vooral ‘onder water’) ook steeds belangrijker.

Met de nieuwe SERP lijkt Google je vooral te willen aansporen om te verfijnen, zodat je vooral maar krijgt waar je naar op zoek bent. Het zoekwoord ‘mindbus‘ is wat dat betreft wat saai. Google kan daar niet zo veel van maken en geeft je geen voorzetjes. Zoek je op ‘volcanic ash‘, dan gaat het redelijk los. ‘News’, ‘Images’ en ‘Videos’ worden aangeboden als filter, de search filters tonen ‘Latest’ en ‘Past 2 days’ en ook de wat obscuurdere tools als ‘Wonder wheel’ en ‘Timeline’ komen boven drijven. Door op ‘More’ te klikken kan je overigens op elk resultaat elk filter instellen. Weliswaar een extra klik, maar een wereld van verschil in overzichtelijkheid enerzijds en functionaliteit anderzijds.

Ook de resultaten zelf worden qua indeling aangepast op het actuele nieuws in een (Twitter)feedbox. Ook niet nieuw trouwens, maar nog niet heel breed ingezet. De indeling is overigens zelf ook nog enigszins te wijzigen in het results filter waardoor je meer of meer shopping results kunt laten tonen of je resultaten met afbeeldingen (vanaf de site of een preview) kunt verrijken.

Ik heb het vermoeden dat de grotere uitrol niet lang meer kan duren, dus: binnenkort in een browser bij jou in de buurt!

Wat bijpassende plaatjes:

Mindbus

Mindbus – ‘uitgevouwen’

Actuelere zoekopdracht

Gerelateerde blogposts:

1. De donkere kant van het Google advertentie netwerk
2. 5 redenen waarom Google adverteert voor Chrome
3. Google test caffeïne zoekmachine update live

Maar maken de indrukwekkende specificaties van de huidige, gemiddelde huis-tuin-en-keuken-PC het ding meteen tot een fat client? Volgens mij niet, net zo min als  dat Usain Bolt dik is omdat hij toevallig de 100 meter in 9,58 loopt. Het is maar net hoe je er naar kijkt.

Het thin-clientconcept is niet opeens onjuist, als je vaststelt dat de thin clients zich in de afgelopen 10 jaar hebben ontwikkeld. Dat een thin client van nu betere specificaties heeft dan 10 jaar geleden, zegt niks.

Dat men gebruik maakt van de beschikbare resources op die client doet ook niks af aan het server-thin-clientmodel. Dat is slechts een  getuigenis van de inventiviteit van de programmeurs die de applicaties bouwen.

Als je het stuk van Michel leest dan zou je kunnen denken dat we bijna van geluk mogen spreken dat onze trouwe PC’s als client fatter en fatter zijn geworden, en dat we dankzij die ontwikkeling nu kunnen genieten van allerlei hippe, desktopsoftware-achtige webapplicaties terwijl aan de andere kant van de lijn de servers qua ontwikkeling hebben stilgestaan, maar de Wet van Moore geldt aan beide kanten van de lijn. Niet alleen de thin clients (de PC’s) hebben zich ontwikkeld; de servers zijn net zo snel in de vaart der volkeren opgestoten. En niet te vergeten die (pijp)lijn tussen server en client is enorm verbeterd. Waar je vroeger een vermogen moest neertellen voor 1Mbit down, tikt bij mij thuis de speedtest makkelijk de 60 Mbit aan.

Alleen als je uitgaat van de beperkte definitie dat een thin-clientmodel het concept omvat dat 1 processor het werk van meerdere clients kan afhandelen kun je bij de huidige webapplicaties niet spreken van een thin-clientmodel. Maar waarom zou dat de definitie zijn van een thin client? Waar komt die definitie überhaupt vandaan?

Als ik de door Michel gehanteerde definitie van Wikipedia erbij haal, dan gaat het om een client die over zeer weinig bronnen beschikt en zeer sterk afhankelijk is van de server. Nou kun je eindeloos discussiëren over wat “zeer weinig bronnen” en “zeer sterk afhankelijk” nou precies betekent, maar we kunnen wel vaststellen dat het gaat om relatieve grootheden. Mijn PC beschikt bijvoorbeeld over zeer weinig bronnen om de content van alle websites ter wereld te kunnen indexeren, en daarom is mijn computer sterk afhankelijk van de ruim één miljoen servers van Google om dat te doen. Dat soort webapplicaties voldoen naar mijn mening aan het thin-clientmodel, en ik word daarbij ondersteund door Wikipedia, die webapplicaties überhaupt als een subgroep van thin clients definiëert.

Juist de gecombineerde ontwikkeling van de thin client, de servercapaciteit en de beschikbare bandbreedte heeft ervoor gezorgd dat  er steeds meer kan binnen die subgroep: Google docs, webbased IDE’s, online gaming, noem het maar op. Dankzij die applicaties is het een feit dat de noodzaak voor een fat client minder en minder is geworden.

Volgens mij wordt het pleit helemaal beslecht als je de definitie van de fat client ernaast legt. Een fat client blijft functioneel onafhankelijk van zijn netwerkverbinding. Thin clients zijn dus het tegenovergestelde, nl. voor hun werking afhankelijk van hun netwerkverbinding. Dat is precies wat we de afgelopen jaren hebben zien ontstaan: Een complete afhankelijkheid van je internetverbinding voor het draaien van applicaties die 10 jaar geleden nog volledig stand-alone op je oude trage, slome en dikke PC draaiden.

Juist na een weekend waarin er op 1 dag 300.000 iPads zijn verkocht, die slechtere specificaties hebben dan mijn PC van 10 jaar geleden (256MB Ram en 1Ghz CPU) lijkt het thin-clientmodel dus meer dan ooit het dominante paradigma te zijn geworden.

Gerelateerde blogposts:

1. Hoe thin zijn thin clients?

Een definitie van thin client: “Een thin client is hierbij een client die zelf over zeer weinig bronnen beschikt, en zeer sterk afhankelijk is van de server, die het verwerken van data voor zijn rekening neemt”
(bron: Wikipedia)

Architectuur
In essentie is een webapplicatie natuurlijk een (software gebaseerde) server – thin client architectuur. De webserver verwerkt de input, doet berekeningen op de data die op de server staan en stuurt enkel het resultaat terug naar de browser in HTML. De browser hoeft alleen de HTML te parsen en te tonen aan de gebruiker. Alle user input binnen de browser wordt gebundeld weer teruggestuurd naar de server voor verwerking, waarbij de client zelf geen state hoeft bij te houden. Deze simpele architectuur zorgt ervoor dat men op relatief eenvoudige apparaten met verschillende operating systemen, met enkel een browser die HTML interpreteert toegang heeft tot enorm veel verschillende online applicaties.

Tien jaar geleden was bovenstaande al mogelijk op de eerste generaties PDAs (met Wifi adapter of GSM simmodule) of met mobiele telefoons uitgerust met WAP mogelijkheid. Maar de ontwikkeling van de hardware van deze apparaten heeft niet stilgestaan en is net zo hard meegegroeid als de ontwikkeling van de hardware van de servers zelf. Vergelijk een moderne telefoon met een van 10 jaar geleden, of een modern minibook, tabletPC of laptop met een van 10 jaar geleden, of een moderne PC met een van 10 jaar geleden, dan zul je zien dat de prestaties een aantal ordes van grootte hoger zijn. De wet van Moore uit 1965 gaat nog steeds op (elke 24 maanden verdubbelt het aantal transistors op een chip zonder kostenstijging).

Client side
Deze prestatiestijging gaf mogelijkheden om telkens meer werk dat de server zou moeten doen, op de client te laten uitvoeren. Juíst omdat de processorkosten op de client zo goedkoop zijn en blijven, is het efficiënter om zoveel mogelijk werk door je duizenden bezoekende browsers te laten uitvoeren, dan op je dure webserver, waardoor de applicatie veel schaalbaarder is. Voornamelijk bij zaken als video rendering, compileren van software of andere berekeningsintensieve taken kan een centrale server die dit alles voor zijn clients moet afhandelen, al gauw performance gebreken vertonen.
Een bijkomend voordeel is dat je minder bandbreedte gebruikt.

De afgelopen 15 jaar hebben we de opkomst van Javascript, (Shockwave) Flash, Flex, VML, Java Applets, ActiveX, Silverlight gezien, stuk voor stuk client side software dat intensief gebruikt maakt van de lokale processorkracht. De allernieuwste browser Internet Explorer 9 maakt zelfs gebruik van de lokale GPU in je PC voor supersnelle grafische berekeningen. Het zal niet lang meer duren voordat de andere browserontwikkelaars volgen.
Google Gears dat door Google is ontwikkeld maakt het mogelijk om lokaal op de client in een doorzoekbare database te werken.
Een van de meest aansprekende nieuwe elementen van SharePoint 2010 voor ontwikkelaars is de mogelijkheid om software te laten werken vanaf de desktop. In Sharepoint 2007 moesten applicaties nog fysiek op SharePoint servers draaien maar in 2010 is dat niet meer nodig.

Er is een enorme verschuiving van de databewerking naar plugins (of native capabilities) in de browser, waardoor je erg interactieve webapplicaties kunt bouwen, bijna vergelijkbaar met locale applicaties.

Distributed computing
Zoals de browserontwikkelaars hebben ingezien dat de PC allerminst een thin client is geworden, zo heeft ook de academische wereld dit ingezien. Er zijn vele projecten die gretig gebruiken maken van lokale prestaties zoals bijvoorbeeld BOINC en distributed.net of het populaire zoeken naar buitenaards leven met SETI@home.

Helaas heeft dit ook een keerzijde, en proberen hackers en professionele cybercriminele organisaties controle te krijgen over de beschikbare reken- en geheugencapaciteit verbonden aan het internet: een botnetwerk bestaat bij de gratie van het fat client zijn van de zombie PCs. Een brute force attack van een wachtwoord duurt met 100.000 zombies geen 23 jaar, maar slechts 2 uur.

Het oorspronkelijke concept achter server – thin client is dat 1 processor makkelijk het werk van meerdere clients kon afhandelen. Eén (server)processor handelde dus meerdere applicaties af in dit soort architectuur. Inmiddels is dat concept achterhaald en exact het tegenovergestelde geworden: één applicatie draait op verschillende processoren. Het opkomende Cloud Computing is gebaseerd op dit concept en maakt optimaal gebruik van de beschikbare rekenkracht in het netwerk. Overigens is het verdienmodel van Cloud Computing 1:1 gecorreleerd aan de verbruikte processorkracht, de hoeveelheid geslagen data en het dataverkeer van en naar de client. Je zult als ontwikkelaar voor software in de Cloud dus nog steeds blijven zoeken naar mogelijkheden om de locale resources van je consumers optimaal te benutten.

Eye of the beholder
Alhoewel schijnbaar de noodzaak voor fat clients sterk afneemt door het enorme aanbod aan functionaliteit via de online applicaties, is vanuit het perspectief van de developer duidelijk zichtbaar dat er op de achtergrond een behoorlijk aantal processen zich lokaal afspelen om de phatte webapplicatie die je hebt gebouwd te tonen in de van oorsprong thin client browser.
Niet omdat dit technisch gezien noodzakelijk is, maar puur omdat het economisch gezien voordeliger is.

Gerelateerde blogposts:

1. Usain Bolt en de iPad zijn niet dik en andere thin client mythes

Dat veel developers, designers en frontenders IE6 graag dood zouden willen (en vaak al zelfs al dood verklaren) is wel duidelijk. IE6 staat garant voor hoofdpijn, extra uren, frustratie, onbegrip en alle mogelijke combinaties daarvan.

IE6 is uit een tijd dat Microsoft als bedwinger van Netscape (en als uitvoerder van bedenkelijke taktieken) een alomvattend marktaandeel had weten op te bouwen. De browser oorlog was gewonnen en in Redmond leunden ze met een sigaartje achterover. De gebruikers waren er, wisten niet beter en de ontwikkelaars konden stampvoeten wat ze wilden. IE6 was de standaard en je klanten hield je tevreden door om de échte standaarden heen te werken en je producten op IE6 af te stemmen.

Die tijd is geweest. Het gepruttel uit de nerdhoek leverde een mooi open source project op: Firefox. Die browser was wél veilig, hield zich wel aan algemene standaarden en was bovendien niet van Microsoft. Het duurde even, maar uiteindelijk kreeg Firefox genoeg marktaandeel om de browserafdeling van Microsoft wakker te schudden. Een nieuwe browser oorlog was gestart en standaarden, snelheden en Acid Tests waren de nieuwe munitie. Andere (en soms veeeeel kleinere) partijen bleken ook goed te kunnen schieten waardoor de browser mix een veel interessantere geworden is.

Firefox claimt langzaam meer marktaandeel, Google lanceert Chrome, Apple doet wat beter zijn best met Safari, Opera mikt op de lange termijn met kwaliteit en een mobiele browser en Microsoft is bezig met de derde full blown IE versie in vier jaar.

Maar waarom is IE6 dan nog niet dood? De belangrijkste reden is dat IE6 te lang min of meer de enige keus is geweest. IE6 werd meegeleverd met Windows XP, applicaties werden er op afgestemd, sites werden er op gebouwd en de druk om te innoveren (of te veranderen) was er niet.

Aardig wat bedrijven zijn nu nog ‘veroordeeld’ to IE6. Systeembeheer heeft de beveiliging ervan eindelijk onder controle, de applicaties draaien onder niks anders en de managers willen geen geld uittrekken om dat te veranderen. Het internet moet dan ook maar bezocht worden met een browser die daar eigenlijk niet geschikt meer voor is.

Daarnaast weten verbazend veel mensen niet eens wat een browser is en interesseert ze dat ook helemaal niet. Ze klikken op een wereldbolletje en voila: het internet. En zolang het werkt, werkt het. Gaat het fout, dan vloeken ze wat en zoeken ze een site die het wel doet. Aan hun computer ligt het niet, want die heeft destijds maar liefst 2000 gulden gekost.

Beide bovengenoemde groepen gebruikers sterven langzaam uit. Niet omdat ze standaarden, snelheid of Acid Tests nou zo belangrijk vinden, maar omdat andere mensen dat belangrijk vinden. Uiteindelijk gaat systeembeheer of het management overstag, uiteindelijk koopt je moeder een nieuwe computer, uiteindelijk zegt de buurjongen dat IE voor lutsers is of uiteindelijk zegt Microsoft zelf dat het tijd is voor een nieuwe browser.

Moeten we als webbouwer dan IE6 nog wel blijven ondersteunen? Natuurlijk (8%!), maar niet actief en niet officieel (extra hoofdpijn moet ook facturabel zijn). De meningen zijn verdeeld (niet of wel), maar zo moeilijk is het toch ook weer niet? Sowieso is less more, maar met wat conditional comments en wat hacks kun je bijna elke website bruikbaar
maken voor bijna elke browser. Met de <em> op ‘bruikbaar’. IE6 gebruikers zien je site alleen in IE6 en als het werkt, dan werkt het. Dat je coole jQuery slider niet getoond wordt of je mooie drop shadow ontbreekt weten ze niet en missen ze daardoor niet. Maar ondertussen kopen ze wel een product of bellen ze wel je sales afdeling.

Zakt het IE6 gebruik onder de 1% dan praten we verder. Nog even doorbijten.

Do it yourself Augmented Reality

Het bedrijf met de welluidende naam Boffswana heeft een leuke en simpele Flash applicatie gemaakt die het mogelijk maakt om met behulp van een webcam te spelen met een virtueel groen poppetje ‘Proto’:

1. Print op een A4 dit PDF uit
2. Sluit je webcam aan
3. Open de pagina met de Flash applicatie (de Flash Applicatie staat onder het filmpje),  klik op ‘Start’ en zorg dat de Flash player toegang heeft tot de webcam (klik op Allow)
4. Richt je webcam om het A4 met het symbool
5. Er verschijnt een groen poppetje dat reageert op op beweging, probeer hem maar eens aan te raken ;-)

Bron: http://www.nrcnext.nl/blog/2010/02/17/ook-zonder-hippe-telefoon-genieten-van-augmented-reality/

Gerelateerde blogposts:

1. YouTube filmpjes in 3D

1. Push richting Thin Clients
   Google wil met de advertentiecampagnes voor Chrome sturen op een versnelde ontwikkeling richting de Thin clients. Chrome is ontworpen om te fungeren als een soort OS waarbij je in de tabs verschillende programma’s in de vorm van Thin clients kan laten draaien. Deze Thin clients, zoals Google Docs, Google Apps zullen op den duur veel desktop applicaties van Microsoft vervangen.
2. Gebruikers bewust maken van een keuze tussen browsers
   De Europese commissie heeft, in het kader van bestrijden van het monopolie van Microsoft, in december een voorstel aangenomen waarbij gebruikers van Windows de keuze moet worden geboden welke browser ze willen gebruiken. Gebruikers van IE krijgen dit voorjaar de vraag om OPT IN te geven voor het gebruik van IE. Als je gebruikers deze keuze geeft dan kan je er maar beter voor zorgen dat je merk “Google Chrome” geramd zit, de campagne is vooral branding dus. Al Verney (Google Nederland) maakt in het artikel op Marketingfacts een mooie vergelijking: “Volgens eigen onderzoek weet maar 25% van de Nederlandse internetgebruikers wat een browser is. Logisch gevolg daarvan is dat veel mensen ook niet weten dat er keuze is tussen browsers. Terwijl je waarschijnlijk meer tijd in je browser doorbrengt dan in je auto!”
3. Focus van de Browserwar leggen op Snelheid
   Google legt veel nadruk op de snelheid van de Browser, Chrome komt op in veel tests als snelste uit de bus komt. Ook bij SEO legt Google nadruk op performance. Als je dit doet zullen sites snel werken en vervaagt de scheiding tussen desktop applicaties en webapplicaties en zul  je je  Browser ook steeds meer gaan ervaren als een OS.
4. Vergroten van de controle op gebruik(ers)
   Via de browser heb je absolute controle over het internetgebruik van gebruikers, je krijgt waardevolle gegevens over het gebruik en kan je eigen applicaties pushen.
5. Doelgroep verbreden
   De huidige gebruikersgroep van Chrome bestaat vooral uit early adopters, die nieuwe producten oppikken via the internets. Om de doelgroep wat te verbreden zul je ook offline moet adverteren om het product aan de man en vooral ook de vrouw te brengen.

De vraag blijft natuurlijk, hoe gaat dit uitpakken voor het marktaandeel van Chrome. Inmiddels is dat wel het Safari voorbij, dat lijkt me niet zo moeilijk, maar waar gaat het naartoe?

Gerelateerde blogposts:

1. Top 10 regels om een viral ook echt viraal te maken
2. Wie zit er achter Jos van Oss, de carniviral hit van 2010?
3. De donkere kant van het Google advertentie netwerk

Als je nu een van deze wachtwoorden wil gebruiken, dan krijg je de melding dat het wachtwoord wel heel makkelijk te raden is.

Andere wachtwoorden worden wel toegelaten, maar krijgen wel tijdens het invoeren al een kwalificatie mee. In oplopende volgorde van geweldigheid krijgen de wachtwoorden de kwalificatie ‘weak’, ‘good’, ‘strong’ of ‘very strong’.

Maar wat zijn nu goede wachtwoorden, en wat niet? En hoe kun je er voor zorgen dat de kans zo klein mogelijk is dat een account gehackt wordt.

Gebruik geen woorden als wachtwoorden

Je kunt een wachtwoord beter zien als een wachtcode, of een wacht-willekeurige-opeenvolging-van-cijfers-tekens-en-letters. Woorden (werkwoorden, zelfstandige naamwoorden, bijvoegelijke naamwoorden, kortom woorden die in een woordenboek staan) maken het wachtwoord erg gevoelig voor een dictionary attack. Een dictionary attack maakt gebruik van een lijst van mogelijke wachtwoorden en probeert die allemaal uit. In tegenstelling tot een normale brute force attack die elke mogelijk combinatie van cijfers en letters uitprobeert, gaat een dictionary attack uit van een lijst van meest waarschijnlijke wachtwoorden (zoals de 369 die Twitter in de ban heeft gedaan). Dictionary attacks slagen omdat de gemiddelde internetter een neiging heeft om korte wachtwoorden te kiezen die bestaan uit één simpel woord dat gevonden kan worden in een woordenboek, of op makkelijk voorspelbare varianten van zulke woorden, door bijvoorbeeld één cijfer er aan toe te voegen.

Maak wachtwoorden niet te kort en gebruik cijfers en leestekens

Als de dictionary attack niet werkt, dan kunnen de zware jongens nog altijd de brute force taktiek hanteren. Hierbij worden alle mogelijke combinaties van tekens uitgeprobeerd. Als je alleen maar cijfers gebruikt in je wachtwoord dan kan een beetje PC een wachtwoord van 8 cijfers in 10(!) seconden kraken. Als je daarentegen cijfers, hoofd- en kleine letters en leestekens door elkaar gebruikt heeft diezelfde computer er 23 jaar voor nodig om alle mogelijkheden uit te proberen.

Gebruik (zoveel mogelijk) verschillende wachtwoorden

In Lord of the Rings had de Dark Lord Sauron er goed aan gedaan om niet één administrator-ring te maken. “One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them”; vanuit een beveiligingsperspectief is dat ongelooflijk stom niet raadzaam. Hetzelfde geldt voor wachtwoorden. 70% van de internetters gaf in een onderzoek aan geen gebruik te maken van een uniek wachtwoord per website. Eén wachtwoord gebruiken voor alle accounts, betekent ook dat maar één wachtwoord gekraakt moet worden om alles te kraken. En wellicht is daar niet eens een dictionary attack voor nodig, want niet elke website slaat wachtwoorden op in de database op een manier waarbij het onmogelijk is om te achterhalen wat het wachtwoord is en zelfs dan ben je nog niet 100% safe.

Wachtwoorden onthouden

OK, dus je maakt gebruik van unieke wachtwoorden en ze zijn allemaal lang en complex genoeg. Maar je moet ook nog een boodschappenlijstje onthouden (vergeet de melk niet), de verjaardag van je schoonmoeder en zinloze dingen zoals “Rensenbrink … tegen de paal!” Wachtwoorden ga je vergeten, zeker die wachtwoorden die je niet vaak gebruikt. een methode om unieke wachtwoorden te onthouden is om alle wachtwoorden via bepaalde regels die alleen jijzelf snapt en onthoudt, (deels) af te leiden uit de naam van de website of service waarop je probeert in te loggen. Bijvoorbeeld: De laatste letter van de website, de eerste letter, de eerstvolgende letter uit het alfabet ten opzichte van de derde letter, SHIFT + 4 getallen van een oud telefoonnummer en de karakters 2EZ.

Een tweede manier is om gebruik te maken van een password manager. En alhoewel je dan alle wachtwoorden weer beveiligt met 1 overall-wachtwoord en dit dus in principe wel een zwak punt is, is dit nog altijd heel veel beter dan voor  alles een en hetzelfde wachtwoord te gebruiken, bijvoorbeeld: password

Gerelateerde blogposts:

1. De officiële Twitter-buttons zijn het net niet
2. De coolste url shortener ooit

De keuze was snel gemaakt: Worpress, de grootste Open Source Blog community ter wereld.  Als zelfs de The New York Times WordPress gebruikt dan zal het wel goed zijn. Ook niet geheel onbelangrijk in deze afweging is de geweldige hoeveelheid goede plugins.

Mocht je ook eens aan de slag gaan met WordPress op IIS dan een tip: De instalatie op Microsoft IIS server werkt goed, echter de friendly urls komen niet helemaal mooi uit en krijgen de vorm:
http://www.yourdomain.com/index.php/2006/09/02/…../
dit is niet wat je wil omdat index.php wordt opgenomen in de url. Om dit te verhelpen is er een url rewritng ISAPI filter beschikbaar dat index.php er tussenuit haalt. Als gevolg van het gebruikt van het ISAPI filter zijn er helaas geen 301 redirects in te stellen, dus onze ouwe pagina’s zullen snel uit de Google ranking vallen. Jammer maar voor ons blog niet heel ernstig, we weten natuurlijk wel hoe het moet. UPDATE: inmiddels werken de 301 redirects wel en kunnen onze ouwe posts ook weer gevonden worden. Dat kunnen we niet zeggen van het AD dat onlangs bij de Livegang van z’n nieuwe site ook geen redirects had ingesteld met desastreuze gevolgen.

Happy 2.0 blogging

Gerelateerde blogposts:

1. Starten met lokale zoekmachineoptimalisatie
2. Google test caffeïne zoekmachine update live
3. De revolutie van webfonts door Typekit