Ubuntu 11.10 upgraden naar 12.04
Vandaag is Ubuntu 12.04 uitgebracht door Canonical. Upgraden kan normaal gesproken heel eenvoudig via de Update Manager, maar toen ik op Upgrade klikte, werd het upgradeprogramma wel gedownload maar niet uitgevoerd.
Dan maar handmatig upgraden met do-release-upgrade. Dat lukte ook niet, maar toen werd wel duidelijk waar het probleem zat:
$ do-release-upgrade Checking for a new ubuntu release Get:1 Upgrade tool signature [198 B] Get:2 Upgrade tool [1550 kB] Fetched 1550 kB in 0s (0 B/s) authenticate 'precise.tar.gz' against 'precise.tar.gz.gpg' extracting 'precise.tar.gz' Can not run the upgrade This usually is caused by a system where /tmp is mounted noexec. Please remount without noexec and run the upgrade again.
Ik heb /tmp inderdaad als noexec gemount. De oplossing is om /tmp opnieuw te mounten, maar nu mét exec:
sudo mount -o remount,exec /tmp
KnProxy
Voor de mensen die geen toegang tot een vrij internet hebben is hier een gratis openbare proxy beschikbaar:
Het is een iets aangepaste versie van het open source KnProxy. De aangepaste broncode is hier te downloaden.
Voordelen:
- Ongecensureerde internettoegang
- Je surft anoniemer (met een ander IP-adres)
Beperkingen:
- De verbinding tussen je computer en de proxy is niet versleuteld. Dat betekent dat de sites die je bezoekt onderweg onderschept kunnen worden met een Man-in-the-middle attack.
- Alleen het HTTP-protocol wordt op dit moment ondersteund.
- Je moet zelf op blijven letten op wat voor informatie je invult op sites en voor spyware op je pc.
Let me Wolfram|Alpha that for you
Krijg je ook altijd vragen over wat de integraal van sin(x) van 0 tot π is, wat het 578324e cijfer van pi of het 642374264e priemgetal is, of wat het antwoord op de ultieme vraag van het leven, het universum en alles is? Wordt je ook altijd moe van vragen over wat log(-i) is, de stand van de maan op de 15e woensdag van 2025, of hoeveel monsters er in Loch Ness zitten? Dan is dit tooltje de oplossing!
In navolging van LMGTFY (Let me Google that for you) heb ik LMWATFY (Let me Wolfram|Alpha that for you) gemaakt. Je vult in waar je met Wolfram|Alpha naar hebt gezocht, en krijgt een link naar een pagina waar je vraag automatisch ingetypt wordt, gevolgd door de vraag “Was dat nou zo moeilijk?”, waarna de vraag aan Wolfram|Alpha wordt gesteld.
Geolocation met HTML 5
Met HTML 5 is het voor sites mogelijk geworden om de fysieke locatie van een gebruiker te bepalen. De officiële specificatie is nog in Editor’s Draft-fase. Dat betekent dat er in principe nog dingen aan de standaard kunnen veranderen, maar aangezien de meeste browsers (Internet Explorer 9, Firefox, Chrome, Safari en Opera) ondersteuning inmiddels hebben ingebouwd is het onwaarschijnlijk dat er nog grote functionele wijzigingen worden gedaan.
Een browser mag zelf bepalen hoe de huidige positie wordt bepaald. Een mobieltje kan bijvoorbeeld de GPS-ontvanger of het telefoonnetwerk gebruiken om zijn plaats te bepalen, en een laptop kan informatie over Wifi-netwerken in de buurt gebruiken.
Hoe werkt het?
De Geolocatie-functies zijn geïmplementeerd in de het Geolocation-object, dat te verkrijgen is met navigator.geolocation. Dit object heeft drie methods:
- getCurrentPosition(successCallback, [errorCallback], [options]): Vraagt de huidige positie aan. Het argument ‘successCallback’ is verplicht en is een functie die wordt aangeroepen als de positie is bepaald. ‘errorCallback’ is niet verplicht, en mag worden gebruikt om een functie mee te geven die wordt aangeroepen als er een fout is opgetreden (bijvoorbeeld als de positie niet binnen een bepaalde tijd kon worden bepaald). Met ‘options’ kunnen specifieke opties worden meegegeven zoals bijvoorbeeld een timeout. Deze functie geeft zelf geen waarde terug.
- watchPosition(successCallback, [errorCallback], [options]): Deze functie heeft precies dezelfde argumenten, maar er zijn twee functionele verschillen met de getCurrentPosition-functie. Als deze functie wordt aangeroepen, wordt de positie namelijk niet één keer bepaald (‘one-shot’ zoals bij getCurrentPosition), maar wordt er telkens gekeken of de positie niet is veranderd. Telkens als er een andere of nauwkeurigere positie is gevonden wordt de successCallback aangeroepen. Deze functie geeft een getal (van type ‘long’) terug waarmee de watchPosition kan worden geannuleerd.
- clearWatch(watchId): annuleert een watchPosition met een bepaald ‘watchId’ (zodat de callbacks niet meer worden aangeroepen). Die watchId is gelijk aan de waarde die de functie watchPosition heeft teruggegeven.
De functie die als ‘successCallback’ wordt meegegeven bij de eerste twee functies moet één parameter hebben (bijvoorbeeld function successCallback(position) { ... }). In die parameter wordt de positie (met type “Position”) meegegeven. Dit type heeft de volgende attributen:
- position.timestamp: de tijd waarop de positie is bepaald (type DOMTimeStamp)
- position.coords.latitude en position.coords.longitude: de geografische positie die is gevonden (type double, latitude = breedtegraad, longitude = lengtegraad)
- position.coords.accuracy: de nauwkeurigheid van de gevonden positie in meters (type double). De kans dat de werkelijke positie binnen een straal van ‘position.coords.accuracy’ ligt is ten minste 95%.
- [position.coords.altitude] en [position.coords.altitudeAccuracy]: de hoogte van de gebruiker en de nauwkeurigheid van de hoogte (beide type double). Een browser is niet verplicht om deze waarde mee te geven. Als de browser de hoogte niet weet mag er ‘null’ terug worden gegeven.
- [position.coords.heading] geeft de richting waarin de gebruiker zich beweegt aan. Dit is een double tussen 0° en 360°. Als de richting onbekend is mag null worden teruggegeven, en als de gebruiker stilstaat moet de waarde NaN (‘not a number’) zijn.
- [position.coords.speed] geeft (de horizontale component van) de snelheid van de gebruiker aan, in meters per seconde. Het type is double en de snelheid is altijd positief. Als de snelheid niet bekend is moet null worden teruggegeven.
De functie die als errorCallback wordt meegegeven moet ook één parameter hebben, waarin een PositionError-object komt te staan (voorbeeld: function errorCallback(error) { ... }). Het PositionError-object heeft de volgende attributen:
- error.code: een numerieke foutcode. Mogelijke waarden zijn error.PERMISSION_DENIED (numerieke waarde = 1. Betekent dat de gebruiker geen toestemming heeft gegeven om de locatie op te halen), error.POSITION_UNAVAILABLE (waarde 2, betekent dat de positie niet kon worden opgehaald) en error.TIMEOUT (waarde 3, het ophalen van de positie duurde langer dan de gedefinieerde timeout).
- error.message: een foutbericht met een beschrijving van de fout. Dit attribuut kan gebruikt worden voor debugging, maar het is niet de bedoeling om dit foutbericht aan de gebruiker te tonen.
De laatste parameter van de functies getCurrentPosition en watchPosition is van het type PositionOptions. Dit type heeft deze attributen:
- options.enableHighAccuracy: geeft aan dat de site graag een zo nauwkeurig mogelijke positie wil. De browser is niet verplicht om zich te houden aan deze vraag (het is meer een soort hint), en de nadelen zijn dat het mogelijk meer tijd of energie kost om de positie te bepalen.
- options.timeout: geeft aan binnen hoeveel milliseconden de positie bekend moet zijn. Als de positie na die tijd nog niet bekend is, wordt de errorCallback aangeroepen. De tijd voordat de gebruiker toestemming heeft gegeven om de plaats te bepalen wordt niet meegerekend met de timeout.
- options.maximumAge: geeft aan dat de positie die wordt teruggegeven niet ouder mag zijn dan maximumAge milliseconden. De browser mag posities namelijk cachen. Om een nieuwe positie die niet is gecached te krijgen kan dit attribuut op 0 worden gezet.
Toestemming
De gebruiker moet altijd eerst toestemming geven voordat een site de locatie mag bepalen. Sommige browsers (zoals Chrome) onthouden die keuze automatisch voor de toekomst, bij andere browsers (zoals Firefox) moet er standaard voor iedere positie-aanvraag opnieuw toestemming worden gegeven. Zo’n venster verschijnt automatisch als je getCurrentPosition of watchPosition aan wil roepen, en ziet er zo uit (in Firefox):
Voorbeeld
Klik hier voor een voorbeeld waarbij duidelijk wordt hoe de geolocatie-functies moeten worden gebruikt.
Hoe DigiNotar het internet onveilig maakte
(Deze post is een bewerkte versie van een artikel dat ik voor het vak Academische Vaardigheden Informatica heb geschreven.)
Tegenwoordig worden er vele miljarden e-mails per dag verstuurd, en doet bijna iedereen aan internetbankieren. Het wordt heel normaal gevonden dat je je wachtwoord in kunt voeren op de website van je bank zonder dat je je zorgen hoeft te maken dat iemand het wachtwoord onderschept. Toch kan alle internetcommunicatie in principe worden afgeluisterd door bijvoorbeeld je internetprovider of de overheid, of het nou gaat om e-mailverkeer of communicatie tussen jou en de bank. Hoe is het dan toch mogelijk om veilig via internet te communiceren, en wat deed DigiNotar daarbij fout?
Versleuteling
Als twee partijen op een veilige manier willen communiceren is het mogelijk om onderling een geheim ‘wachtwoord’ (sleutel) af te spreken waarmee alle informatie wordt versleuteld. Zonder die sleutel kan een aanvaller geen berichten meer ontsleutelen. Deze encryptie noemen we symmetrisch, want een bericht kan met dezelfde sleutel worden ontcijferd als waarmee het bericht is versleuteld. Toch is er nog wel een belangrijk probleem: hoe zorg je ervoor dat beide partijen dezelfde sleutel gebruiken? Je kunt de sleutel niet zomaar via internet versturen, want dan kan de aanvaller de sleutel ook onderscheppen en daarmee ook alle andere berichten ontcijferen.
Asymmetrische encryptie
Om dat probleem op te lossen is asymmetrische cryptografie ontwikkeld. Daarbij worden twee sleutels gebruikt. De ene sleutel is publiek en kan alleen worden gebruikt om informatie te vercijferen. Deze publieke sleutel wordt vervolgens verstuurd naar degene die een bericht wil versleutelen. Als de aanvaller deze sleutel onderschept, kan hij de sleutel niet gebruiken om de berichten weer te ontcijferen. Daar is een andere sleutel voor nodig: de geheime sleutel. Die sleutel wordt niet publiek gemaakt en wordt naar niemand verstuurd, maar is alleen bij de ontvangende partij bekend. De ontvanger kan vervolgens met die sleutel het bericht weer ontcijferen.
Deze manier van communicatie is echter nog steeds niet helemaal veilig. Een slimme aanvaller zal de publieke sleutel onderscheppen, en in plaats daarvan zijn eigen publieke sleutel doorsturen naar de verzendende partij. De afzender zal zijn geheime bericht dan versleutelen met de publieke sleutel van de aanvaller in plaats van de publieke sleutel van de bedoelde ontvanger. De aanvaller kan alle berichten vervolgens ontcijferen en lezen, en eventueel met de publieke sleutel van de ontvanger weer versleutelen en doorsturen naar de bedoelde ontvanger. Op die manier weten de afzender én de ontvanger niet dat alle berichten worden meegelezen.
Certificaten
Degene die een bericht wil sturen heeft dus een manier nodig om te controleren dat hij de juiste publieke sleutel heeft ontvangen. Als de aanvaller dan de echte publieke sleutel onderschept en in plaats daarvan zijn eigen publieke sleutel stuurt, kan het slachtoffer dat detecteren en besluiten om het bericht niet te versturen. Door digitale certificaten te gebruiken is het mogelijk om na te gaan of een bepaalde publieke sleutel echt afkomstig is van degene met wie je wilt communiceren. Een vertrouwde derde partij (‘trustedthird party’) zal de identiteit van de ontvanger verifiëren. In de praktijk zijn die vertrouwde derde partijen de certificaatautoriteiten (CA’s) zoals VeriSign, Comodo en vroeger ook DigiNotar. Nadat zo’n certificaatautoriteit de identiteit van degene die een certificaat aan wil vragen heeft gecontroleerd zal de CA een certificaat uitgeven. In dat certificaat staat onder andere de publieke sleutel van de ontvanger, en het certificaat wordt ook ondertekend door de CA. Daardoor kunnen anderen controleren of het certificaat echt is, en of de publieke sleutel dus correct is.
DigiNotar
DigiNotar was zo’n certificaatautoriteit en mocht dus certificaten uitgeven voor andere websites. In juli 2011 werd het bedrijf gehackt. Bij die hack zijn er ten minste 531 certificaten gestolen, waaronder certificaten voor google.com, microsoft.com, facebook.com en cia.gov. Al die websites konden door de hacker worden afgeluisterd. De hack werd opgeëist door een Iraanse hacker die eerder al Comodo hackte. Het is wel duidelijk dat de certificaten zijn gebruikt om ruim 300.000 Iraanse IP-adressen af te luisteren (zie figuur 1). Ook een aantal proxies en exit-nodes van het Tor-project werden afgeluisterd. Dat zijn systemen die worden gebruikt om internetcensuur te omzeilen.
Figuur 1: Geografische distributie van de IP-adressen die een vals DigiNotar-certificaat hebben ontvangen
Uit een onderzoek dat direct na de hack door het beveiligingsbedrijf Fox-IT is uitgevoerd bleek dat er op het gebied van veiligheid nogal wat was aan te merken op DigiNotar. Zo was de software die op de servers van DigiNotar was geïnstalleerd oud en niet geüpdatet. Ook de wachtwoorden die DigiNotar gebruikte waren niet veilig en konden gemakkelijk worden achterhaald met een brute-force aanval. Bovendien zaten alle servers in hetzelfde Windows-domein, waardoor één wachtwoord genoeg was om toegang te krijgen tot alle servers, en het netwerkverkeer werd niet gelogd. Daarnaast was er op de servers geen antivirussoftware aanwezig. Door al die beveiligingsfouten is het de hacker gelukt om met een aantal standaardtools en speciaal ontwikkelde scripts toegang te krijgen tot de servers van DigiNotar en valse certificaten uit te geven.
Gevolgen
Alle grote browsers hebben de DigiNotar-certificaten binnen enkele dagen nadat de hack bekend werd geblokkeerd. Daardoor werden alle certificaten die door DigiNotar zijn uitgegeven niet meer vertrouwd. DigiNotar kon dus geen certificaten meer uitgeven en op 20 september is DigiNotar om die reden failliet verklaard. Doordat alle DigiNotar-certificaten werden ingetrokken kregen bezoekers van websites die echte DigiNotar-certificaten gebruikten ook beveiligingswaarschuwingen. Dat was met name een probleem voor DigiD en andere Nederlandse overheidswebsites die voor veel mensen plotseling niet meer goed bereikbaar waren. Pas na een aantal dagen waren de overheidswebsites overgestapt op andere certificaten en weer goed bereikbaar.
Hoe nu verder?
Het is niet de eerste keer dat er een certificaatautoriteit is gehackt en dat er valse certificaten zijn uitgereikt. Eerder dit jaar werd Comodo al slachtoffer van een hack, waarbij er valse certificaten zijn uitgegeven voor onder andere www.google.com, login.live.com en login.yahoo.com. Ook bij de verificatie van de identiteit van degene die een certificaat aanvraagt gaat er wel eens iets mis. Zo heeft VeriSign in 2001 ten onrechte twee certificaten uitgegeven aan iemand die beweerde Microsoft te vertegenwoordigen. Beveiligingsexperts waarschuwen al jaren dat het hiërarchische beveiligingsmodel van certificaatautoriteiten niet veilig is. Er zijn meer dan 650 CA’s, maar er hoeft maar één CA onderuit te gaan en iedere versleuteling van communicatie is waardeloos, zoals bleek bij DigiNotar. Het is duidelijk dat er op termijn een betere oplossing voor het verifiëren van de identiteit van website nodig is.
Daarom zijn er inmiddels een aantal alternatieven ontwikkeld, zoals CAcert.org en Convergence. Bij die projecten wordt er niet meer op één partij vertrouwd, maar op een hele groep mensen. In het geval van CAcert.org zijn dat zogenaamde ‘assurers’. Zij verifiëren de identiteit van mensen die een certificaat willen door elkaar daadwerkelijk te ontmoeten, en ze controleren ook de identiteit van de andere assurers. Hoe meer assurers je identiteit hebben gecontroleerd, hoe meer je certificaat waard wordt. Bij Convergence wordt het certificaat van een website gecontroleerd door aan ten minste twee andere partijen (‘notaries’) te vragen of ze hetzelfde certificaat zien. Hoewel beide projecten op dit moment nog een aantal tekortkomingen hebben, zal het slechts een kwestie van tijd zijn voordat er een alternatief voor de verificatie van certificaten in gebruik wordt genomen.
Bronnen
- http://www.scribd.com/doc/64011372/Operation-Black-Tulip-v1-0
- http://nos.nl/artikel/269697-iraniers-bespioneerd-na-hack-in-nederland.html
- http://nos.nl/artikel/269899-cia-mossad-providers-doelwit-hack.html
- http://www.informationweek.com/news/security/management/231700001
- http://www.cacert.org/policy/AssurancePolicy.php
- http://www.nu.nl/diginotar/2605914/donner-zegt-samenwerking-met-diginotar.html
- http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/
- http://blog.gerv.net/2011/09/updated-diginotar-cn-list/
- http://my.opera.com/rootstore/blog/2011/09/08/diginotar-second-step-blacklisting-the-rootw
Plaats de eerste reactie »
Het input-element in HTML 5
Gisteren hebben we een aantal verschillen tussen HTML 4 en HTML 5 gezien. Een van die verschillen is het <input>-element. Zo zijn er een aantal soorten invoervelden bijgekomen. Een groot voordeel van die nieuwe invoervelden is dat het veel gebruikersvriendelijker wordt om bijvoorbeeld een getal of een e-mailadres in te voeren. Zo wordt in Opera automatisch de mogelijkheid gegeven om een e-mailadres uit het adresboek te selecteren, en als je op een iPod een telefoonnummer in moet voeren dan zal er een toetsenbord met alleen cijfers worden weergegeven. Wil je een datum invoeren? Dan wordt er een handige kalender weergegeven. (Zie deze blog voor screenshots.) Vandaag zullen we de nieuwe mogelijkheden voor invoervelden in HTML 5 eens bekijken.
In HTML 4 waren een aantal soorten invoervelden mogelijk, zoals ‘text’ voor tekstvelden of ‘password’ voor wachtwoordvelden (deze velden zijn in feite hetzelfde als tekstvelden behalve dat de tekst vervangen wordt door sterretjes). Het type van een inputveld werd meegegeven met het type-attribuut, zoals de onderstaande tabel illustreert:
| Type | Voorbeeld |
|---|---|
<input type="text" name="text" value="Voorbeeld" /> |
|
<input type="password" name="password" value="Voorbeeld" /> |
|
<input type="checkbox" name="checkbox" value="Voorbeeld" checked="checked" /> |
|
<input type="radio" name="radio" value="Voorbeeld" /> |
|
<input type="submit" name="submit" value="Voorbeeld" /> |
|
<input type="reset" name="reset" value="Voorbeeld" /> |
|
<input type="file" name="file" value="Voorbeeld" /> |
|
<input type="hidden" name="hidden" value="Voorbeeld" /> |
|
<input type="image" name="image" value="Voorbeeld" src="http://blog.simondevries.com/wp-content/uploads/2011/12/example.gif" /> |
|
<input type="button" name="submit" value="Voorbeeld" /> |
Als je een veld wilde hebben waar bijvoorbeeld alleen getallen in mogen, was het nodig om daar Javascript voor te gebruiken. Daarom zijn er in HTML 5 een heel aantal nieuwe velden gemaakt:
| Type | Voorbeeld |
|---|---|
<input type="color" /> |
|
<input type="date" /> |
|
<input type="datetime" /> |
|
<input type="datetime-local" /> |
|
<input type="email" /> |
|
<input type="month" /> |
|
<input type="number" /> |
|
<input type="range" /> |
|
<input type="search" /> |
|
<input type="tel" /> |
|
<input type="time" /> |
|
<input type="url" /> |
|
<input type="week" /> |
Op dit moment worden de nieuwe invoervelden nog niet door iedere browser ondersteund. Opera, Google Chrome en Safari ondersteunen de meeste invoervelden al wel, maar bijvoorbeeld Firefox en Internet Explorer nog niet. Als je een nieuw invoerveld gebruikt in een browser die dat veld nog niet ondersteund, zal de browser het veld weergeven als een tekstveld.
Sommige velden hebben extra attributen, bijvoorbeeld het type number en range. Deze twee invoervelden zijn bedoeld om een getal te kiezen. Bij type="number" krijg je een tekstveld waar je alleen getallen in kunt vullen, terwijl je bij type="range" een slider of scrollbalkje krijgt. Bij die velden zijn de volgende attributen in te stellen:
- min: geeft het kleinste getal dat in het invoerveld mag komen aan.
- max: geeft het grootste getal dat in het invoerveld mag komen aan.
- step: geeft aan hoeveel de getallen die in het invoerveld mogen komen moeten verschillen van elkaar. Als bijvoorbeeld
step="5"dan mogen alleen de getallen …, -5, 0, 5, 10, … in het veld geplaatst worden. - value: geeft de standaardwaarde van het invoerveld aan.
Als de code <input type="range" min="-4" max="2" step="2" value="-2" /> levert bijvoorbeeld een slider op die de waarden -4, -2, 0 en 2 aan kan nemen en die standaard op -2 staat ingesteld. In Google Chrome ziet dat er bijvoorbeeld zo uit: 
De attributen min, max, step en value kunnen overigens ook worden gebruikt op datumvelden (de typen date, datetime, datetime-local, month, time en week).
HTML5 vs. HTML4: de belangrijkste verschillen
Gisteren hebben we gezien hoe de HTML 5-specificatie zich ontwikkeld tot een officiële W3C standaard. De nieuwe standaard is nodig om het gebruik van een aantal nieuwe technologieën mogelijk te maken, en om een aantal andere tekortkomingen van HTML 4 te verhelpen. Vandaag zullen we eens kijken naar de belangrijkste verschillen van HTML 5 met HTML 4.
Allereerst zijn er een aantal nieuwe elementen (tags) gedefinieerd om een duidelijkere structuur in HTML 5-documenten mogelijk te maken. In HTML 5 kan <section> worden om een document te splitsen in verschillende secties, en <article> kan worden gebruikt om bijvoorbeeld blog-posts of nieuwsberichten aan te geven. In de <header>-tag (niet te verwarren met de <head>!) kunnen bijvoorbeeld de titel van een website worden opgenomen, en in de <footer> bijvoorbeeld informatie over de auteur. De navigatie kan in een <nav>-tag worden gezet. Andere nieuwe tags voor de structuur zijn <aside>, waarin dingen die niet direct aan het onderwerp zijn gerelateerd (‘off-topic’ content) kunnen worden geplaatst, <hgroup> waarmee je een sectie een titel kunt geven, en <figure> waarmee een figuur (of filmpje e.d.) kan worden gescheiden van de rest van de content. Met <figcaption> is het mogelijk om zo’n figuur een bijschrift te geven.
| XHTML 1.0 | HTML 5 |
|---|---|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
<!DOCTYPE html> |
Al deze tags maken het mogelijk om content veel duidelijker te structureren. Dat maakt het bijvoorbeeld voor zoekmachines makkelijker om te bepalen welke tekst bij het artikel hoort en welke niet, en welke tekst belangrijk is en welke niet. Het heeft ook voordelen voor de toegankelijkheid (accessibility) van websites. Zo kunnen screen readers bijvoorbeeld makkelijker navigeren in de tekst, en mobiele apparaten kunnen websites beter aanpassen aan het mobiele platform.
Er zijn nog meer nieuwe elementen, maar daar zal ik alleen de belangrijkste van behandelen. Dat zijn <video> en <audio>, waarmee video en audio in een pagina kunnen worden ingevoegd (het is dus niet meer nodig om multimedia te embedden of Flash te gebruiken om filmpjes af te spelen). Een andere vernieuwing is het <canvas>-element, waarmee je een soort tekendoek krijgt. Daar kun je vervolgens met scripts op tekenen.
Verder heeft het <input>-element een aantal nieuwe mogelijkheden gekregen. Het type-attribuut is uitgebreid met een aantal nieuwe waarden, zoals ‘date’, ‘email’ en ‘number’. Daardoor kan de browser zelf bijvoorbeeld een kalender weergeven als er een datum moet worden ingevoerd. Morgen zullen we in detail kijken welke nieuwe mogelijkheden het <input>-element precies heeft gekregen.
Tot slot zijn er een aantal API’s gedefinieerd. Een API kan in een script gebruikt worden om bepaalde functionaliteit te krijgen. In HTML 5 zijn er onder andere nieuwe API’s beschikbaar om audio en video af te spelen, en om offline webapplicaties mogelijk te maken. Deze API’s zullen we de komende tijd ook beter bekijken.
 |
 |
 |
HTML5: een introductie
Het is al weer een tijdje geleden dat de HTML 4.01-standaard een ‘W3C Recommendation’ werd (1999!), dus werd het wel eens tijd voor een update. De strijd tussen XHTML 2.0 en HTML 5 is inmiddels in het voordeel van HTML 5 beslist, voornamelijk omdat XHTML 2.0 totaal niet compatibel met HTML 4 of XHTML 1.0 is.
De nieuwe HTML 5-standaard is nog lang niet af, maar er is al wel een Working Draft beschikbaar. De standaard wordt ontwikkeld door het World Wide Web Consortium (W3C), een internationale organisatie die standaarden ontwikkeld voor het World Wide Web. Een nieuwe standaard, dus ook HTML5, wordt altijd in fasen (‘Maturity Levels’) ontwikkeld:
- Working Draft
Dit is een soort ‘kladversie’ die wordt gepubliceerd door het W3C zodat de ‘gebruikers’ van de specificatie (de web developers) er commentaar op kunnen leveren. Meestal verandert de nieuwe standaard na de Working Draft nog veel.
- Candidate Recommendation
De auteurs van de standaard zijn nu tevreden over de functionaliteit van de standaard. Nu is het aan de ontwikkelaars (browserfabrikanten) om aan te geven of de standaard goed te implementeren is. - Proposed Recommendation
Nu hebben zowel de gebruikers als de ontwikkelaars de kans gehad om commentaar te geven op de standaard. De standaard wordt nu naar het ‘W3C Advisory Council’ gestuurd. Zij moeten de standaard goedkeuren. Over het algemeen worden er in deze fase nauwelijks wijzigingen in de standaard aangebracht.
- W3C Recommendation
Nu de standaard uitgebreid is getest en is goedgekeurd door het W3C Advisory Council is goedgekeurd, en het W3C raadt aan om de standaard in de praktijk te gebruiken. Als er achteraf fouten worden ontdekt of nieuwe inzichten ontstaan, worden er Errata en later nieuwe revisies gepubliceerd.
Zoals gezegd bevindt de HTML 5-specificatie zich in de eerste fase (Working Draft). Er kan dus nog veel aan de specificatie veranderen, maar een aantal onderdelen zijn al vergevorderd. De laatste versie van de specificatie is de Editors Draft. Het W3C streeft ernaar om HTML 5 in 2014 uit te brengen als Recommendation.
Het is natuurlijk veel interessanter om HTML 5 eens inhoudelijk te behandelen, maar het is ook goed om te weten hoe zo’n nieuwe standaard wordt ontwikkeld en welke partijen erbij worden betrokken. Het is namelijk belangrijk dat de standaard voldoet aan de wensen van de gebruikers, en bovendien ook implementeerbaar is voor browsermakers. Morgen zullen we zien wat er nou eigenlijk in de specificatie staat en wat de grootste veranderingen zijn.