Ook als budgethoster heb je een zorgplicht dat de website het doet (en waarschijnlijk zijn je AV niet van toepassing)

| AE 12700 | Ondernemingsvrijheid | 28 reacties

Ook als je een website maakt voor €199 en die host voor €60 per jaar, dan nog ben je aansprakelijk voor de gevolgen van downtime (in de zin van: de website is geheel down). Dat maak ik op uit een recent vonnis uit Rotterdam. Het optionele servicepakket van €10 per maand en de AV (te vinden op de website) waren daarbij geen factoren van belang. Het laat maar weer eens zien hoe belangrijk goede communicatie is.

Het bedrijf lijkt er een van zovelen te zijn die het mkb bedient: eenvoudige offertes, lage prijzen, op basis van WordPress als cms en recht-voor-zn-raap communicatie:

Productoverzicht: -Standaard website, inclusief hosting en domein ( [domeinnaam] ) -Whatsappfunctie -Analyse software bezoekers website (…)”
Na oplevering leek de site een jaartje prima te werken, maar op 2 maart 2020 bleek de site onbereikbaar voor klanten. Op de navolgende dagen bleek contact met de hoster/designer niet mogelijk, waarna eind mei een ingebrekestelling werd gestuurd en vanwege tegenvallende resultaten werd opgezegd. Vervolgens werd de hoster boos omdat niet voor het hele jaar 2020 was betaald.

Dat voelt een tikje raar, de site doet het niet, je zegt op en dan komt de hoster geld bij jou claimen. Maar het argument was: er was een optioneel servicepakket, dat is niet afgenomen en bovendien bestond op grond van de AV geen aansprakelijkheid voor indirecte schade.

Nee, dat vond de rechter ook niet zoals het hoort:

Ongeacht wat de precieze oorzaak van de onbereikbaarheid is, staat daarmee naar het oordeel van de kantonrechter vast dat [gedaagde] zijn verplichtingen ten aanzien van de hosting van de website (in het bijzonder de onbelemmerde bereikbaarheid op het internet gedurende de looptijd van de overeenkomst) per 2 maart 2020 niet is nagekomen. [eiseres] heeft onweersproken gesteld dat de domeinnaam door een derde partij gehackt was. Voor zover er inderdaad sprake was van het hacken van de domeinnaam dient die omstandigheid voor rekening en risico te komen van [gedaagde] , nu zij – als domeinhouder en verantwoordelijke voor de hosting van de website – verantwoordelijk was voor de bereikbaarheid van de website, waarvan naar het oordeel van de kantonrechter ook deel uit maakt het voorkomen van blootstelling aan door derden veroorzaakte digitale inbreuken op die bereikbaarheid.
Mijn samenvatting: als een site het helemaal niet doet, moet jij als hoster dat oplossen. Een hack kan, maar dat is juridisch wel jouw probleem. (Ja, er is overmacht maar niet iedere hack is overmacht, en op zijn minst moet je probéren het op te lossen.) En dat servicepakket, de upsell naar een SLA zeg maar:
Uit de offerte van [gedaagde] van 11 juli 2018 volgt dat het optionele ondersteuningspakket slechts ziet op te verlenen service en gratis updates van de websites. De situatie die zich thans heeft voorgedaan – het volledig onbereikbaar zijn van de website – valt hier niet onder.
Betalen dus, want wanprestatie. Maar daarvoor had de ondernemer dus nog zijn algemene voorwaarden in de achterzak, die indirecte schade (wat in de ICT grofweg alle schade betekent) keihard uitsluit. Op de offerte stond daarover
“Op deze aanbieding zijn onze algemene voorwaarden van kracht. Deze kunt u op onze website vinden.”
En dat wordt door de rechter binnen een seconde van tafel geveegd. De jurisprudentie is duidelijk: geen dieplink, geen toepasselijkheid.

Betalen dus, maar hoe veel dan? In dit geval was de onbereikbaarheid kennelijk zo ernstig uit de hand gelopen dat de klant maar een geheel nieuwe website met nieuwe domeinnaam had laten bouwen. Want de domeinnaam stond dus op naam van de hoster. En dan krijg je dus de kosten van de nieuwe site (€560) plus – nee, serieus – de kosten van het opnieuw beletteren van de bedrijfsfiets (€294) voor je kiezen.

Het lastige bij dit vonnis is dat alles in vrij absolute termen is geformuleerd. Maar dat komt door de vrij extreme situatie: een site geheel down gedurende lange tijd, nul respons (althans niet bewezen dat er is teruggebeld) en niet betwiste schade, die ook nog eens best redelijk gebudgetteerd was. Het is dus niet zo dat iedereen in elke situatie met een dagje downtime een geheel nieuwe site moet betalen. Maar de les voor mij is wel dat als je hosting belooft, je gewoon voor hosting moet zorgen en niet te makkelijk moet denken “ik verkoop apart een SLA en de AV staan op mijn site”. Daarmee kom je nergens.

Arnoud

Deel dit artikel

  1. Tja, je SAAS aanbiedt, met de S van service, dus je bent een dienstaanbieder, dan moet de dienst het wel doen. Het zou waarschijnlijk anders zijn geweest voor een IAAS aanbod. Dan is duidelijker het beheer in handen van de klant. Maar dat verkoopt natuurlijk slecht aan MKB-ers dus bieden we extra’s (diensten) aan. En dan gaat het fout.

  2. Ik weet natuurlijk niet wat er precies is afgesproken tussen de partijen, en wat daarvan bewijsbaar is, maar ik zou het volledig normaal vinden (en daar ga ik ook vanuit bij mijn websitebouwer en hoster) dat ik als website-eigenaar zelf verantwoordelijk ben voor updates en anti-hacking maatregelen.

    Uiteindelijk, om in real-life termen te blijven: Je koopt een opgezet budget-tentje, en een jaar lang een kampeerrecht op een veldje, maar dat wil nog niet zeggen dat de leverancier/campingbeheerder verantwoordelijk is dat het tentje een jaar lang alle stormen en aanvallen van vandalen overleeft.

    Mijn eerste reactie is: de rechter heeft het niet goed begrepen….

    • De analogie wordt kloppender als je zegt, je huurt een kampeerplaats met tent, je moet zelf spullen meenemen (onderhoud/updates) en als er wat gestolen wordt dan heb je pech. Dan kom je na een week kamperen na een wandeling terug en is de tent weg. Ik zou dan zeggen, probleem verhuurder want ik huurde de tent van hem.

      Of, omdat het om een domeinnaamkaping ging, het kampeerterrein is ineens omgeven met containers zodat je er niet meer op kunt. Of iets realistischer, is geheel ondergelopen doordat de rivier overstroomde. Is dat ook een “aanval van vandalen”? En maakt het dan uit of de verhuurder een week lang niets laat horen en niet zoals gebruikelijk bij campings een baggerbedrijf laat langskomen om het terrein weer schoon te maken?

      • Ik vindt niet dat de analogie kloppender wordt. De website (design en databestanden) is het tentje. De hosting is het kampeerrecht op het veldje. Je hebt eenmalig betaald voor het tentje en het opzetten daarvan, de rest is aan jou.

        Hier is trouwens het probleem complexer, merk ik: het gaat om drie dingen: de website, de hosting, en de domeinnaam. Maar zelfs dan klopt de analogie: de domeinnaam is een mooie grote herkenbare vlag die ook op hetzelfde veldje staat. Wiens verantwoordelijkheid is het dat de vlag en het tentje en het veldje een jaar lang bij elkaar blijven?

        • De hosting is het kampeerrecht op het veldje.

          Het dwaalt wel heel erg af. We zijn wel erg ver voorbij de analogie. Dus even terug. Hosting is het in de lucht brengen en houden van een website.

          Zoals de gedaagde partij zelf uitlegt: “Om je website in de lucht te houden, heb je jaarlijks hosting nodig en dien je jouw domeinnaam te registreren”

          Ok, dus je hebt hosting nodig om de website in de lucht te houden. Website uit de lucht impliceert dus hosting niet in orde. Laten we het niet moeilijker maken.

            • Ik weet niet zo goed waar je naartoe wilt, en ik vind de steeds nieuwe analogieen die je introduceert de discussie nogal vertroebelen. Een analogie gaat altijd maar tot een bepaald punt op en dan gaat er iemand zeggen “de analogie klopt niet”.

              Het ging hier om een hoster die de domeinnaam die hij had geregeld voor zijn klant, niet beschikbaar heeft kunnen houden. Dus als je zo graag een analogie wilt: de hoster zou drinken regelen voor de klant en heeft dat niet gedaan. De klant is nu door dorst omgekomen.

              Of anders gezegd: indien de hoster had gedaan wat hij beloofd had, was er geen probleem geweest.

              Of zoals de rechtbank oordeelt:

              Onder hosting van de website dient, naar algemeen spraakgebruik, te worden verstaan het plaatsen van de website op een (web)server, die er voor zorgt dat de website altijd in verbinding staat met het internet en bereikbaar is. Op basis van de overeenkomst diende [gedaagde] derhalve de door hem ontwikkelde website op een (web)server te plaatsen en er voor zorg te dragen dat de website te allen tijde in verbinding staat met het internet, in elk geval voor de duur van de overeenkomst. Daarnaast diende [gedaagde] de domeinnaam – de unieke naam van de website op het internet – te registreren bij een hostingprovider.
              en dan
              Ongeacht wat de precieze oorzaak van de onbereikbaarheid is, staat daarmee naar het oordeel van de kantonrechter vast dat [gedaagde] zijn verplichtingen ten aanzien van de hosting van de website (in het bijzonder de onbelemmerde bereikbaarheid op het internet gedurende de looptijd van de overeenkomst) per 2 maart 2020 niet is nagekomen

              De enige toepasselijke vergelijking is dan ook “zo klaar als een klontje”.

    • In het vonnis staat het volgnde (uit de offerte geciteerd):

      Wat krijgt u bij de website: – Design passend op uw branche – Inclusief domeinnaam registratie – Inclusief Hosting – Inclusief drie e-mailadressen – Responsive design: automatisch aanpassen aan het scherm van de gebruiker
      Het is het totaalpakket dat afgenomen wordt, als dienst (SaaS). Bij dat soort dienstmodellen is de demarcatiepunt de inhoud: de klant regelt de inhoud (de tekst), de rest (software, middleware, hardware) wordt door de leverancier aangeboden en beheerd. Als klant heb je hier geen doen meer mee. Zie ook de Pizza as a Service analogie. De demarcatie die je hier beschrijft klopt bij PaaS: hardware, OS en webserver in beheer van de leverancier, website en alles daar boven beheerd door de klant. Maar aangezien het pakket dat verkocht is inclusief website is, is hier in mijn ogen geen sprake van.

      • Niet eens: Er worden twee afzonderlijke dingen geleverd: CaaS, en afzonderlijk daarvan een websiteontwerp. In jouw pizza-analogie: het gas, de oven en het vuur worden voor jou geleverd/beheerd. En afzonderlijk daarvan wordt er alreeds een pizza naar jouw wensen gemaakt in die oven. Maar dat wil niet zeggen dat je altijd maar nieuwe verse pizza’s mag verwachten.

  3. Ik denk dat hier gewoon sprake is van een technische kloof tussen de aanbieder en de MKB’er. Voor mij als iemand die ook wel eens iets doet met ICT is het mij vrij duidelijk dat de diensten die worden aangeboden bestaan uit het maken van een website en het hosten ervan (als jaarlijks terugkerende kostenpost).

    Dus daar zijn geen dingen inbegrepen als updates, veranderingen aan de site etc. Het is gewoon een eenmalige dienst (de site maken) + een plek aanbieden waar hij kan draaien.

    Dit voelt een beetje alsof je een fiets koopt bij een fietsenmaken, en – omdat het handig is en de fietsenmaker connecties heeft – ook meteen een jaarabonnement voor een fietsparkeergarage bij jou in de buurt. Na een paar jaar heeft de fiets ineens een lekke band, dus wat doe je dan? Je klaagt de fietsenmaker aan omdat hij niet gratis je band wil plakken en je dus een nieuwe fiets moest kopen, en omdat je oude fiets nog op dezelfde plek in de parkeergarage staat moet je ook een nieuw jaarabonnement afsluiten ervoor.

    • Vanuit juridisch perspectief gaat het dan inderdaad mis bij “een plek aanmaken waar hij kan draaien”. Want wie realiseert dat “kunnen draaien”? Een website is niet een auto die je aflevert en die het dan doet. Het is een dienst, die doet het alleen maar zolang jij als hoster er naast zit. Dat je dat 99% automatiseert (server herstart automatisch, load balancing gaat vanzelf, een webserver redt zichzelf een heel eind, zelfs bij 5xx errors) dat maakt niet dat de server het probleem van de klant wordt.

      Inderdaad is er gezegd dat updates bij de klant horen. Maar redelijkerwijs zou ik dat lezen als, het soort updates die de klant kan doen. Dus WordPress bijwerken. Hoe had de klant in vredesnaam de serversoftware zelf kunnen bijwerken? Of wat had de klant moeten doen als de netwerkstekker er door de schoonmaker in het DC uitgehaald werd?

      Daar komt bij dat het ging om een “hack” op de domeinnaam, dus niet een lek in de serversoftware of in WordPress. Ik zie met de meest kale IaaS-dienstverlening nog niet hoe een door de hoster beheerde (en op naam van hoster staande) domeinnaam dan ineens probleem klant is.

      • Het gaat inderdaad mis bij de ‘expert’ en de ‘leek’ en de verwachtingen die beide partijen hebben. Ik als technisch persoon zie zo’n site wel als een auto, en dat ik dan toevallig ook via de maker ervan een parkeerplaats huur maakt die maker niet verantwoordelijk voor het onderhoud ervan.

        Het gedeelte ‘hack op de domeinnaam’ is mij ook niet helemaal duidelijk, dat klinkt alsof de domeinnaam verlopen is en iemand anders heeft hem gejat, of erger, het account waar die domeinnaam op staat is in handen gevallen van een derde partij. Veel meer hacks op domeinnamen kan ik niet bedenken.

        Dat zou ik dan inderdaad wel toerekenen aan degene waar ik de domeinnaam van huur, dat is alsof je parkeerplaats ineens aan een ander is gegeven en jij mag er niet meer parkeren.

        • Even focussen dan op de hosting sec. De afspraak zoals genoteerd is letterlijk “Productoverzicht: Standaard website, inclusief hosting en domein” met als kanttekening dat het “Optioneel: Ondersteuningspakket ” niet is afgenomen. Hierin zat “3 uur service per maand, gratis updates aan uw website”.

          Gezien de aard van een en ander veronderstel ik een simpele VM met daarin Linux, Apache, WordPress. Ik ben het met je eens dat je als afnemer nu WordPress en plugins moet bijwerken, en natuurlijk zelf alle content e.d. Hoe zie jij updates aan de Apache webserver die eronder zit, en het Linux OS dáár weer onder?

          Vervolgens heeft de hoster de rekening naar het DC niet betaald, waardoor die de IP connectivity afsluit. Of de hoster maakt een dikkevingertypefout in de hypervisor waardoor mijn VM uitgezet wordt. Welk risico als klant dien ik hierin te dragen volgens jou?

          • Het probleem is een beetje dat we niet weten uit het vonnis wat er is misgegaan, terwijl dat wel uiterst belangrijk is.

            Jij hebt het over onderhoud aan de server. Natuurlijk rust die plicht op de hoster. Maar ik zie nog niet direct in het vonnis dat dat is misgegaan (Maar misschien zie ik iets over het hoofd)

            je zegt ‘Vervolgens heeft de hoster de rekening naar het DC niet betaald, waardoor die de IP connectivity afsluit.’ Ik weet niet wat je met DC bedoelt, maar ik zie nergens in het vonnis dat de hoster een betaling aan een leverancier niet heeft doorgevoerd en dat dat de oorzaak van de problemen zou zijn.

            Er is sprake van dat de website en/of de domeinnaam gehackt zou zijn, maar wat dat dan precies is, is niet duidelijk. Ik zou in eerste instantie stellen dat de websitehouder verantwoordelijk is om niet gehackt te worden (verantwoordelijk paswoordbeheer, updates aan wordpress en plugins doorvoeren) en dat ook het restrisico primair voor rekening van de websitehouder zou moeten komen. Als je ondanks redelijke maatregelen gehackt wordt, is dat pech, maar niet de verantwoordelijkheid van de hoster.

            Eigenlijk is het gewoon jammer dat we onvoldoende info hebben om te beoordelen of de hoster een oplichter is of dat de klant voor een dubbeltje op de eerste rij wilde zitten.

            • Ik schetste een variatie op de casus, omdat de interessanter vraag zit bij échte downtime door een storing die binnen de macht van de leverancier ligt. zoals dat het datacenter (DC) waarin deze de fysieke server heeft staan, de internetkabel eruit trekt omdat de rekening niet is betaald of omdat een andere eindklant op die server spam verstuurt of iets dergelijks. Zeg maar de gemeente die het grasveld ontruimt vanwege harddrugsgebruik door diverse kampeerders, en ook jouw tent is met een bulldozer geruimd.

              • Maar dat is toch op zich geen interessante vraag? Dan heeft de hoster gewoon wanprestatie geleverd.

                Het interessante zit hem juist in: waar ligt de grens tussen verantwoordelijkheid van de klant en van de hoster?

                Vanaf het begin heb ik deze zaak geinterpreteerd als: de klant heeft iets gedaan of nagelaten waardoor de website niet meer werkt. Ik had er nooit bij stilgestaan dat het zou kunnen dat de hoster iets technisch fout gedaan heeft. (en eigenlijk nog steeds niet: dan had de hoster het immers gemakkelijk kunnen fixen)

                    • Hoeft niet per se. De klant heeft gevraagd om een verhuistoken, en dat niet gekregen. Of dat is omdat hoster de domeinnaam vasthield om betaling af te dwingen, of omdat hoster zelf geen controle meer had over de domeinnaam, weten we niet. Dan kunnen we alleen afgaan op de niet bestreden stelling van eiser “dat de domeinnaam door een derde partij gehackt was”.

                      Ook heeft hoster eerder als “oplossing” (!) aangeboden “het ontwikkelen van een nieuwe website”. Nou is dat sowieso onrealistisch, wellicht heb je als hoster misschien geen backup van een tijd geleden meer, maar je zou toch wel verwachten dat gedaagde in de hoedanigheid van ontwikkelaar van de site tenminste nog de bronbestanden of een ZIP file van het gemaakte zou hebben. Behalve als je de domeinnaam kwijt bent, dan is dit nog een beetje een verhaal. En dat zou betekenen dat hoster op dat moment de controle over het domein al kwijt was…

                      • Zo zie je maar, iedereen trekt zijn eigen conclusies uit een incompleet verhaal.

                        Mijn interpretatie was: Het werkte op een gegeven moment niet meer (oftewel door een hack, oftewel door een fout van de klant) en toen heeft de hoster uitgelegd wat er mis was en wat er aan gedaan kon worden, maar dat dat niet zijn schuld/verantwoordelijkheid is. Maar de klant was daarmee niet akkoord en er is een conflict ontstaan en geescaleerd, en als gevolg daarvan WIL de hoster het verhuistoken niet geven.

                        Wat me vooral stoort in het vonnis is de zin in punt 5.3: ‘Ongeacht wat de precieze oorzaak van de onbereikbaarheid is, ….’. Dat is in mijn optiek juist essentieel: Wie is verantwoordelijk dat de goedwerkende website op een gegeven moment niet meer bereikbaar was.

                        Maar we zullen er wel niet uitkomen, met zulke beperkte gegevens geeft iedereen zijn eigen draai aan het verhaal.

                        • Ik heb nog even met jouw interpretatie in het achterhoofd het vonnis opnieuw doorgelezen.

                          Feit blijft dat de hoster zijn case slecht heeft onderbouwd, maar blijkbaar ook als enige oplossing ziet dat er een nieuwe website voor de klant moet worden ontwikkeld. Als je diensten biedt aan kleine ondernemers met weinig technische affiniteit dan dien je toch echt wel uit hoofde van goed vakmanschap te zorgen voor deugdelijke backups, al is het maar van het moment dat je de site overdroeg aan de klant.

                          Daarnaast is het registreren van de domeinnaam met de hoster blijkbaar ook als admin-contact een zeer slechte gewoonte die (volgens mijn herinnering) verboden is door de SIDN. Hetzelfde geldt mijns inziens voor het in gijzeling houden van een domeinnaam bij een zakelijk conflict.

                          • Absoluut, de hoster heeft zijn case slecht gebracht door te focussen op zijn niet-van-toepassing zijnde AV.

                            En het lijkt ook dat de hoster niet helemaal netjes is geweest.

                            De enige manier waarop dit conflict (althans tussen redelijk handelende partijen) zo groot kon worden is inderdaad als de domeinnaam kwijt was. En dan lijkt het er inderdaad op dat eerder de schuld van de hoster als van de klant zou zijn.

                            Maar het probleem is: het vonnis geeft geen aanleiding om dit te veronderstellen. Zo eist de klant (zie punt 2.7) ‘een verhuistoken op te vragen bij de registrar zodat de domeinnaam overgezet kan worden naar een nieuwe dienstverlener.’ Dat geeft al aan dat blijkbaar de domeinnaam toch nog steeds bij de hoster zit.

                            Ook stelt de rechter (punt 5.2) ‘[gedaagde] staat, als ontwikkelaar van de website, geregistreerd als domeinhouder van de website.’

                            Mijn scenario blijft: website is op een gegeven moment onverstandig beheerd geweest (en misschien gehackt) en daardoor onbereikbaar geworden. Hoster vindt dat dit de verantwoordelijkheid van de klant is, klant vindt andersom, en het conflict is geescaleeerd.

  4. Zo eist de klant (zie punt 2.7) ‘een verhuistoken op te vragen (…) Dat geeft al aan dat blijkbaar de domeinnaam toch nog steeds bij de hoster zit.

    Ook als ik zeker wist dat het domein was gehacked en niet meer onder controle was van de hoster, zou ik dit doen als klant. Je dwingt dan de hoster om toe te geven dat deze het domein niet meer onder zijn controle heeft en/of te proberen deze controle te herwinnen.

    Ipv daarvan werd het domein opgeheven

    Voor NL domeinen kan je het bij SIDN escaleren als de hostingprovider het token niet geeft. Ze forceren dan de verhuizing (en spreken de hostingprovider bestraffend toe).

    En gelukkig is er die quarantaine, die is precies voor dit soort ongelukken bedoeld.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS