Roland Boon

Om me eens wat in Chrome extensions te verdiepen heb ik samen met Ewout (van Bonnevoy) vorig jaar eens een extension ontwikkeld voor Facebook events. Als testje was het een redelijk flauwe plugin, maar het heeft toch nog enthousiaste gebruikers opgeleverd. Zo enthousiast zelfs, dat de community laatst de moeite heeft genomen om de door ons gepubliceerde broncode bij te werken naar een nieuwe versie voor Facebook.

De extension, Facebook Event Gender Count, geeft zoals de naam probeert duidelijk te maken bij een Facebook event aan hoeveel mannen en hoeveel vrouwen er aanwezig zijn. Deze gegevens worden geintegreerd in de vormgeving van Facebook, waardoor het net lijkt alsof het een echte Facebook feature is. De uitwerking was misschien niet de beste als eerste poging tot Chrome extension, maar het resultaat was best leuk.

Nu is de vormgeving van Facebook een klein beetje veranderd sinds het uitbrengen van Facebook Event Gender Count en daardoor was hij stuk gegaan. Niet erg moeilijk op te lossen, maar de extension had test voor ons niet echt prioriteit. Iemand anders dacht daar blijkbaar toch anders over en heeft hem voor ons geupdate. Leuk dat dit middagprojectje weer wat aandacht krijgt en daardoor nog langer blijft werken :)

In de laatste beta versie van Chrome gaan zoekopdrachten in Google standaard via SSL. Ik denk dat de reacties op dit nieuws in ongeveer drie categorieen zijn te verdelen:

1. Ja dus? Lekker belangrijk.
2. Heel goed. Standaard meer veiligheid en privacy is altijd beter.
3. Nee! Mijn Analytics krijgt nu nog minder waarde.

Zelf zit ik wel in de laatste categorie. Ruim een jaar geleden is Google begonnen om zoekresultaten via SSL te ondersteunen voor ingelogde gebruikers, een beveiligde zoekopdracht. Het voordeel voor gebruikers is heel nobel: je zoekopdrachten zijn privacygevoelige data, dus dat wil je beveiligen. De consequentie voor website eigenaren is echter dat ze niet meer kunnen zien via welke zoekopdrachten bezoekers op hun website terecht zijn gekomen. Een groot gemis dus voor hele handige zoekmachineoptimalisatie data.

Zodra een bezoeker vanaf  Google op je website komt via een beveiligde zoekopdracht krijgt de website eigenaar het inmiddels beruchte (Not Provided) keyword te zien. Je ziet dus wel dat de bezoeker vanaf Google kwam, maar niet waarop hij zocht. Met de introductie van Chrome 25 zal dit percentage dus groter worden en het valt te verwachten dat op den duur iedereen dit zal gebruiken. De website (Not Provided) Count verwacht dat dit moment op september 2020 is, maar met initiatieven zoals deze kan dat moment wel eens eerder komen.

Sinds wachtwoorden niet bepaald veilig meer zijn, verbeteren steeds meer grote diensten hun loginsystemen met 2-factor authenticatie. Het is een van de beste dingen die je kunt doen om de beveiliging van je webdiensten te verbeteren en ervoor te zorgen dat je dus niet zo eenvoudig gehackt wordt. Authenticatie kan op 3 verschillende manieren:

1. Iets dat de gebruiker weet
2. Iets dat de gebruiker heeft
3. Iets dat de gebruiker is

De eerste van deze 3 factoren kennen we dus ondertussen wel: een wachtwoord onthouden. Met 2-factor authenticatie wordt daar een 2e factor aan toegevoegd. Aangezien de derde uit dit rijtje nogal lastig is (bijv. een vingerafdruk of irisscan) maakt men gebruik van iets dat een gebruiker heeft.

Deze vorm van beveiligen ken je wel van internetbankieren (je moet je pinpas met random reader hebben, of je telefoon met TAN-code) of van sommige bedrijfsnetwerken (een sleutelhanger met code). Google introduceerde begin dit jaar de Google Authenticator app voor je mobiele telefoon, die de TOTP standaard implementeerd. Deze app doet ongeveer hetzelfde als de sleutelhanger met code, maar het leuke is dat de app gestandaardiseerd en universeel is. Naast je Google account kun je hem dus ook gebruiken voor andere diensten die het ondersteunen.

De afgelopen tijd komen er steeds meer diensten bij die TOTP via de Google Authenticator app implementeren, zoals Dropbox, Lastpass, WordPress en voor de echte geeks ook SSH. Ik denk dat ik binnenkort hiervoor maar eens een module voor m’n favoriete PHP-framework (Kohana) voor ga maken :)

Iedere web developer kent uiteraard de Google Analytics tracking code en de developers die wat gefocust zijn op performance zouden ook deze alternatieve methode moeten kennen. Deze tracking code gaat er echter vanuit dat het een op zichzelf staand stukje javascript is en dat is uiteraard in veel websites niet het geval. In een project waarmee ik onlangs bezig was maakte ik gebruik van jQuery en schreef ik alle javascript in Coffeescript.

Met de jQuery getScript() functie en het deffered object die deze functie teruggeeft kan de tracking code een stuk leesbaarder:

$ ->
  ad = $.getScript 'http://www.google-analytics.com/ga.js'
  ad.done ->
    _gaq.push ['_setAccount', 'UA-XXXXX-X']
    _gaq.push ['_trackPageview']
    _gaq.push ['_trackPageLoadTime']

Het grootste gedeelte van mijn leven ontwikkel ik al dingen op het internet. Met mijn werk voor Red Frog zijn dit vooral zakelijke applicaties, maar privé en voor Bonnevoy zijn het vaak ook wat experimentjes, stukjes herbruikbare code of zelfs nuttige tooltjes voor mijzelf of anderen. Veel van deze kleine projecten heb ik al ergens online staan en zal ik de komende tijd gaan verzamelen op deze site. Dan heb ik voor mijzelf een leuk overzicht en mocht iemand er ooit interesse hebben, dan is het wat eenvoudiger (terug) te vinden.

Ik zal er hoe dan ook achter gaan komen dat de tijd waarin ik projecten heb ontwikkeld erg bepalend zijn voor het niveau van de code en uitwerking. Daar waar nodig zal ik oude projectjes wat bijschaven zodat ze enigszins toonbaar zijn.

Projecten overzicht

Een veel genegeerde les, maar best belangrijk voor performance en veiligheid is: link niet naar resources binnen een (open) source repository. Er zijn meerdere redenen hiervoor (waar ik zo op terug kom), maar de aanleiding om hier bij stil te staan is het thema van mijn nieuwe website. Zoals ik in de vorige post vermeldde gebruik ik het thema wp-svbtle en terwijl ik door de code daarvan aan het kijken was kwam ik al snel deze regel tegen:

<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>

Billy Hoffman schreef een aardig stuk waarin alle nadelen van het serveren vanuit de Google Code repository genoemd worden:

• Er wordt geen HTTP compressie (gzip) toegepast. Compressie is een belangrijke techniek om de laadtijd van je website te verkorten.
• Het wordt niet gecached. De ingestelde cache tijd van Google code is 180 seconden. Dat terwijl de hele reden voor het linken naar een javascript CDN is dat de files vaak al gecached zijn door de client.
• Er wordt geen range request ondersteund, terwijl de accept-ranges header wel gestuurd wordt. De ondersteuning van een range request zorgt ervoor dat de browser bij een afgebroken download weer verder kan gaan waar deze was gebleven.
• Je linkt naar een open source repository. Hiermee creeër je naast risico’s op bugs ook een beveiligingsrisico. Het gebeurd nogal eens dat er een fout wordt gemaakt in de build van een repo. Daarnaast als een kwaadwillende toegang krijgt tot de repository kan hij javascript uitvoeren op jouw website!

Om het wp-svblte thema te verbeteren heb ik een pull request gemaakt waarin html5shiv vanaf de eigen host wordt geserveerd. Er zijn echter nog veel meer projecten waarin dit gebeurd, dus kijk uit als je iets overneemt.

Lang heb ik op mijn persoonlijke adres alleen een placeholder gehad met wat linkjes naar mijn social media pagina’s. Het is zo’n projectje waarvan je weet dat je er eens wat aan moet gaan doen, maar nooit echt prioriteit geeft. Als web developer/internet ondernemer denk ik dat mijn persoonlijke website op zijn minst wat linkjes of artikeltjes moet hebben over internet projecten waar ik mee bezig ben. Daar begin ik nu dus maar eens aan, al was het maar voor mezelf zodat dit eens van de grond komt.

Ik verwacht dat mijn site voornamelijk over web development en internet technologie zal gaan. Daar zal ik dan direct maar mee aftrappen. Als basis van deze website zal ik WordPress gebruiken. Ik weet het, niet echt een heel interessant platform, maar aangezien ik al een PHP host heb en eigenlijk niet teveel tijd in development voor deze site wil stoppen (er zijn interessantere code projecten dan een persoonlijke website) is het toch een makkelijke keuze. Ik gebruik het thema wp-svbtle als basis. Het voldoet voor nu redelijk aan mijn wensen en ik kan het vrij eenvoudig aanpassen.