Archiefinstellingen bieden via hun websites diverse bestanden aan, denk hierbij aan scans en open data bestanden. Je zou denken dat dit met de intentie is dat deze bestanden ook gedownload en gebruikt worden. Waarom sommige archiefinstellingen hier dan een technische drempel opwerpen is mij dan ook werkelijk een raadsel… Een tweetal voorbeelden van dit minder toegankelijk maken door middel van een veranderende technische sleutel.
Open data Stadsarchief Rotterdam (en andere DE REE klanten)
Het Stadsarchief Rotterdam is één van de klanten van DE REE archiefsystemen die het “open data portaal” component gebruikt. Via deze voorziening stelt het Stadsarchief een groot deel van de nadere toegangen als open data beschikbaar. Wie deze open data wil downloaden moet goed z’n best doen. Ik schreef hier in maart 2016 al over (toen met als lijdend voorwerp het Gelders Archief), helaas is de situatie nog ongewijzigd.
Het is best veel werk om de ruim 6,5 duizend bestanden van het Stadsarchief handmatig te downloaden: het kost twee kliks per bestand en na 20 bestanden weer een klik om bij de volgende 20 bestanden te komen. Dit is niet de manier om gebruik van open data te promoten! Hergebruikers willen, zeker bij dit soort aantallen, eenvoudig de bestanden kunnen downloaden. Dit kan simpelweg via een API die een lijst met beschikbare (URL’s van) bestanden biedt (liefst met filter op “datum laatste wijziging”) die dan stuk voor stuk gedownload kunnen worden.
Helaas, bij websites die gebruik maken van MAIS-Internet-software moet het hierboven geschetste scenario geautomatiseerd worden. Lastig voor de hergebruiker en ook nog eens extra belastend voor het toch al piepende systeem van DE REE. Om het gebruik nog lastiger te maken zijn de URL’s van de te downloaden open data bestanden ook nog eens elke dag anders. Ja wel, in een sector die druk bezig is met persistente URL’s, PID’s en permalinks worden in deze oplossing moedwillig de (technische sleutels in de) links dagelijks gewijzigd.
De link naar het onder CC0 1.0 licentie beschikbaar gestelde bestand “Nadere toegang op het overlijdensregister van de gemeente Rotterdam” (999-09.1952S) is vandaag (24-10-2018):
Wat dit bestand ontoegankelijk gaat maken zit ‘m in het key gedeelte van de URL. Dit is een technische, “geheime” sleutel die door het systeem van DE REE specifiek voor dat bestand wordt gegenereerd. Het probleem is, dat DE REE er dagelijks weer een andere sleutel voor genereert! De sleutel is op zich niet geheim (want wordt genoemd in de link op de website), maar hoe deze sleutel wordt gemaakt is niet openbaar, dus wat de sleutel van een bepaald bestand morgen of overmorgen is weet alleen DE REE.
Wie het bestand morgen via bovenstaande link wil downloaden krijgt een wit scherm (technisch een lege pagina, content-length 0, met HTTP code 200). Het is al slecht dat je het bestand niet krijgt vanwege een verlopen technische sleutel, maar daar komt nog eens bij dat de standaard HTTP foutmeldingen niet worden gehanteerd en de gebruiker niet wordt geïnformeerd over de fout.
Voor de eerder genoemde hergebruikers die de open data harvest door het open data portal te scrapen is deze key een extra hobbel, maar niet onoverkomelijk. Wat je alleen wel bereikt is 1) extra belasting op het systeem omdat deze key voor elk bestand opgevraagd moet worden en 2) dat niemand een directe link naar het te downloaden bestand kan leggen. Tja, want links naar onze bestanden willen we niet omdat …?
E-depot Nationaal Archief (en waarschijnlijk ook alle RHC tenants)
Het Nationaal Archief promoot (digitale) toegankelijkheid. Helaas, bij hun e-depot lijken ze dit even vergeten. Als voorbeeld nemen we een index kaartje uit de collectie van de Kanselarij omtrent de koninklijke onderscheiding van W.H.J. Coret. De URL die GaHetNa meldt om dit kaartje (PDF) te bekijken in de browser is:
Wat we te zien krijgen is een standaard PDF viewer die er voor zorgt dat de diverse browsers de betreffende PDF kunnen weergeven. Wat opvalt is dat in de rij icoontjes rechtsboven het “download” knopje ontbreekt (wat in de PDF viewer dus wel kan, maar door het Nationaal Archief of hun leveranciers niet is aangezet of is uitgezet).
Wie de broncode van de PDF viewer bekijkt ziet de URL van het PDF bestand. In dit voorbeeld is dat de URL:
En ja hoor, ook dit downloadbare bestand is “beveiligd” met een technische sleutel, hier token genoemd. Bij het e-depot blijkt dit token het zelfde te zijn voor alle bestanden in het e-depot te gelden, maar het wijzigt elke 8 uur. Ook hier is het “recept” voor dit token niet openbaar.
De hierboven getoonde link naar de PDF is geldig tot 18:27 (24-10-2018). Daarna werkt de link niet meer (de link naar de viewer is overigens wel “stabiel”, deze bevat geen veranderende technische sleutel). Wanneer je object opvraagt uit het e-depot met een verlopen token dan krijg je geen wit scherm, maar een slechts marginaal betere foutmelding (http 501):
Bescherming of dure drempel?
Ik kan slechts gissen naar de beweegredenen van de organisaties die deze veranderende technische sleutels toevoegen aan URL’s. Ik kan mij niet voorstellen dat men deeplinken naar bestanden tegen wil gaan. Vanuit de aanbieder wil je juist dat jouw materiaal gebruikt wordt, dat het makkelijk kan worden gedownload, dat men er een link naar kan leggen. Vanuit de leverancier wil je dat operaties zo min mogelijk resources kosten zodat de performance van je systeem goed blijft. De veranderende technische sleutels in de URL’s zorgen echter juist voor meer belasting, omdat de technische gebruiker eerst de technische sleutel moet opvragen en dan het bestand gaat downloaden, wat door de controle van de sleutel niet een standaard bestandsdownload is (zoals we het op het web al 25 jaar doen) maar onnodig meer van het systeem vraagt.
Kortom, schaf deze veranderende technische sleutels af! Dat komt de toegankelijkheid van de bestanden ten goede en zorgt voor minder belasting op het presentatiedeel van het systeem.
