Het bewijs wordt geleverd door het controlepaneel

Een lezer vroeg me:

Bij mijn webhoster heb ik een controlepaneel waarmee ik mijn domeinnamen en sites kan beheren. Laatst bleek er echter ineens een domeinnaam verdwenen uit de lijst. Deze was opgeheven volgens de provider, en dat had ik goedgekeurd via het controlepaneel, zo bleek uit hun logs. En die waren “dwingend bewijs”, zeggen ze. Maar ik heb niets gedaan! Hoe kan ik nu bewijzen dat hun controlepaneel het fout heeft?

Hoofdregel uit het bewijs is dat degene die een bepaald gevolg claimt, de oorzaak moet bewijzen. In dit geval zegt de provider dat ze de domeinnaam niet meer actief hoeven te houden, dus moeten zij bewijzen dat er een opdracht tot opheffen gekomen is.

De provider beroept zich op het controlepaneel, waarmee de klant de opdracht tot opheffen kan geven. Op zich is dat een prima manier: de logs van zo’n paneel leggen objectief vast wat er is gedaan, en daaruit kun je (rechts)gevolgen afleiden.

Veel providers versterken hun situatie nog meer door in de algemene voorwaarden te bepalen dat bepaalde logs of registraties dwingend bewijs zijn. Dat wil zeggen, wat daarin staat is de enige waarheid. Je kunt zelfs zo ver gaan om tegenbewijs uit te sluiten.

Mag dat? Niet snel. Bij consumenten staat dit op de zwarte lijst:

[een beding] dat de bevoegdheid van de wederpartij om bewijs te leveren uitsluit of beperkt, of …

Bij zakelijke contracten geldt de zwarte lijst niet, maar ook bij zakelijke contracten kan een algemene voorwaarde worden aangevochten als deze al te evident onredelijk is. En dat zal hier snel wel opgaan denk ik. Want de wet bepaalt al (art. 151 Rv) tegen dwingend bewijs tegenbewijs openstaat.

Het wordt alleen wel moeilijk want meestal ís er niets, afgezien van de logs van dat controlepaneel. Dus hoe ga je dan bewijzen wat er is gebeurd?

Gelukkig kwam men er hier snel uit: de bug bleek reproduceerbaar en met een schermfilmpje van hoe ineens de domeinnaam verdween was de provider snel overtuigd. Maar als zoiets er niet is, of als het een eenmalig freak incident was, dan wordt het toch moeilijk.

Arnoud

51 reacties

  1. Zou die hoster dan niet ook een email terug moeten sturen naar de klant om deze duidelijk te melden dat het domein opgeheven zal worden? Zo’n email zou ook meehelpen als bewijs dat de klant van tevoren wist dat het domein verwijderd zal worden. (En dan kan de klant het weer ongedaan maken.)

  2. Algemene voorwaarden die dit tot dwingend bewijs verklaren acht ik onredelijk voor zowel consumenten als niet-consument. Immers in bieden gevallen wordt in significante wijze, in het nadeel van de tegenpartij, afweken in de balans tussen de rechten en plichten die uit de overeenkomst samen vloeien. Zoals gebleken is kan een bug dit ook veroorzaken en de klant krijgt geen toegang tot de software om aan te tonen dat er een bug in zit.

  3. Ik ben degene die deze vraag had gesteld. Goed om te weten dat er hier een verschil tussen zakelijk en consumenten is!

    Mijn geval is trouwens niet goed afgelopen. Het enige wat de hosting provider mij antwoordt, in steeds verschillende bewoordingen, is “Het filmpje is onmogelijk” en “We kunnen het alleen terugdraaien als u per domein €15 betaalt”.

    Versio heeft logs die laten zien dat de opdrachten tot opzegging vanaf mijn IP-adres kwamen. Ik heb inmiddels het sterke vermoeden dat de wachtwoordmanager-plugin (Lastpass) ervoor zorgde dat er automatisch wordt opgezegd, zonder dat er iets daarover in beeld komt. Het is namelijk zo dat alle mogelijkheden in het controlepaneel met javascript worden verborgen en getoond wanneer ze door de gebruiker worden opgevraagd. De domein-verwijder-knop is dus weggestopt achter een andere menu-optie en is vanaf het begin af aan aanwezig in het browserscherm, ook al is deze niet zichtbaar. Ook de velden om je keuze te bevestigen zit al in dezelfde html-code, maar worden verborgen, totdat je op de knop ‘opzeggen’ hebt gedrukt. Lastpass maakt geen onderscheid tussen elementen die zichtbaar zijn en elementen die onzichtbaar zijn en behandelt de het paneel als een inlogpagina (er wordt immers ergens om log in gegevens gevraagd). Lastpass stond ingesteld op automatisch inloggen, waardoor mijn credentials werden ingevuld en verstuurd.

    Ik vind dit slecht ontworpen natuurlijk, maar volgens Versio is het een gebruikersfout. Ze sturen overigens wel een mail voor als je niet gezien zou hebben dat het verwijderen gelukt is, waar ik natuurlijk onmiddelijk op reageerde. De reactie daarop is inmiddels bekend …

    1. Ik vind het natuurlijk vervelend voor je, maar kan in dit geval Versio niet ongelijk geven. Zij kunnen niet verantwoordelijk zijn voor de plugins en extensies die men geïnstalleerd heeft en kunnen slechts op een eindig aantal platforms en browsers testen. Neemt niet weg dat ik server logs nog steeds een dubieus middel vind, maar dat doet in dit geval niet ter zake. Daarnaast zou het ze natuurlijk sieren als ze bij een onmiddelijke reactie op het opzegmailtje in plaats van de volledige prijs slechts de kostprijs zouden rekenen. Klantenbinding heet dat.

      1. Nee; ook kostprijs berekenen is fout als de klant niet werkelijk dat domein heeft opgezegd. Tenminste als je ’t hebt over klantenbinding. Hoe ’t dan juridisch gezien (en of ’t verstandig is…) precies zit als je Lastpass toegang geeft tot jouw domeinbeheer, is een tweede…

  4. Als programmeur vind ik dat de oplossing van Versio om die knop te tonen bepaald geen schoonheidsprijs verdient. Een zichzelf respecterende en gebruikers kennende programmeur had zoiets nooit mogen bouwen. Want we weten allemaal:”if you make something idiot-proof, the Universe builds a better idiot”. Dit maakt juridisch natuurlijk geen fluit uit, maar om alle schuld zomaar rücksichtslos af te schuiven op een gebruiker, dat gaat mij te ver als je zelf zulke domme fouten maakt.

  5. Toch is zo te horen die webapplicatie standards-compliant, en de browser(-plugin) niet. In mijn ervaring veroorzaakt Lastpass vaker dit soort problemen.

    Grappig hoe Matthijs zijn post over dingen die op de client gebeuren ineens helemaal nlijkt te kloppen trouwens.

    Versio kan ik enkel gelijk geven. Met tools als Greasemonkey kan je een website wel van alles laten doen. Dat zou wel erg makkelijk je verantwoordelijkheid afschuiven zijn. Qua klantenbinding denk ik dat ze al genoeg supporttijd in dit slechte verhaal hebben zitten. Op Koos leggen ze echt al geld toe, wees maar niet bang. (En even heel bot gesteld zitten ze natuurlijk eigenlijk helemaal niet op klanten te wachten die zoveel aandacht nodig hebben).

    Juridisch interessant is dan ook of de maker van Lastpass aansprakelijk is. Of heeft die disclaimer die je bij dat soort software accepteert ook waarde bij ernstige nalatigheid?

    1. Ik denk niet dat je de maker van Lastpass aansprakelijk kunt houden, ook niet als er geen disclaimer is. Schade komt alleen voor vergoeding in aanmerking als deze in redelijk verband staat met het product, en een belangrijke factor daarbij is de voorzienbaarheid. Had de maker van Lastpass moeten weten dat zijn tool allerlei acties automatisch zou uitvoeren waarbij om een wachtwoord wordt gevraagd?

      Als er een bug report bij Lastpass ligt waarin dit staat én hij weigert het te fixen, dan misschien. Maar de reden van weigering zal heel erg uitmaken: “kan niet detecteren of je op een controlepaneel zit” is heel wat anders dan “geen zin in”.

      1. Had de maker van Lastpass moeten weten dat zijn tool allerlei acties automatisch zou uitvoeren waarbij om een wachtwoord wordt gevraagd?

        Even heel zwart/wit erin: ja, want dat is eigenlijk wat het product in basis doet. De tool moet in mijn optiek kunnen omgaan met situaties waarin het wachtwoord als ‘veiligheidsmaatregel’ wordt gevraagd bij handelingen die veel impact hebben, of op z’n minst de gebruiker waarschuwen dat deze functionaliteit wegvalt bij het gebruik van LastPass.

        Zoals gezegd, ik heb meer situaties gezien waarbij LastPass de veroorzaker van ellende was. Het is rommel maar de maker verdient er intussen goed aan.

        1. Zoals gezegd, ik heb meer situaties gezien waarbij LastPass de veroorzaker van ellende was. Het is rommel maar de maker verdient er intussen goed aan.
          Je bent wel makkelijk met je oordeel over deze software hoor. Heb je er ervaring mee? Heb je de software in het verleden wel eens getest? En waarom krijgt Lastpass dan zoveel goede reviews als het rommel is? (CNet, PC-Mag, Mozilla, Google Play) Sorry, hoor. Maar als ik merk dat er vest veel goede reviews te vinden zijn, dan vind ik jouw opmerking over “rommel” wel heel apart klinken. Je hebt wel recht op je eigen mening, maar velen zijn het kennelijk niet met jou eens. Daarnaast, de software is in principe gratis, hoewel je een premium versie kunt kopen. Alleen voor grote bedrijven die vaak met veel wachtwoorden te maken hebben is er een prijskaartje. Zeker indien het om bedrijven gaat waar medewerkers met elkaar wachtwoorden moeten delen. Bij bedrijven is het vooral handig omdat LastPass sterke wachtwoorden genereert en centraal opslaat, waarna medewerkers via een login op die centrale plek ervoor kunnen zorgen dat ze overal kunnen inloggen zonder dat ze de wachtwoorden hoeven te weten.

          Maar goed, bij de meeste software ontstaan de problemen vaak door verkeerd gebruik van de software. Ik ga er van uit dat de software niet uit zichzelf naar een control panel gaat browsen, vervolgens op de knop “Delete domain” klikt, daarbij inlogt en ook nog even alle bevestigings-dialoogjes aanklikt. De gebruiker zal toch enige handelingen zelf uitgevoerd moeten hebben die uiteindelijk tot het probleem hebben geleid. En mogelijk zelfs gewoon blindelings wat popups hebben weggeklikt die om bevestiging hebben gevraagd.

          Verder valt het mij op dat de domeinen vrijwel direct verdwenen lijken te zijn. Mijn eigen registar VIP registreert domeinen per jaar, waarbij je per domein kunt aangeven of je wel of niet automatisch wilt verlengen en waarbij je een bevestiging per email ontvangt als je de verlenging hebt uitgezet. Je kunt daarnaast op een overzicht-scherm al je domeinnamen bekijken waarbij er een waarschuwings-symbool (screenshot) staat bij alle domeinen die niet worden verlengd! Lijkt mij sowieso handig om regelmatig in de gaten te houden!

    2. Dat Versio op dit moment al tijd en geld genoeg in het probleem heeft gestoken ben ik met je eens. Dat station is allang gepasseerd. Maar het zou mooi zijn als je, ook bij een actie die je zelf onbedoeld hebt uitvervoerd, kon opbellen met “oeps, foutje, sorry” en zij dan in plaats van “de logs bewijzen het, dus dat gaat je geld kosten”, “geen probleem meneer / mevrouw, dat fixen we voor u” hadden gezegd. Maar goed, dat is een keuze die je als bedrijf maakt.

      1. kon opbellen met “oeps, foutje, sorry” en zij dan in plaats van “de logs bewijzen het, dus dat gaat je geld kosten”, “geen probleem meneer / mevrouw, dat fixen we voor u” hadden gezegd.

        Ik denk dat er twee discussies door elkaar lopen hier. “Kunnen jullie het terugdraaien?” / “Ja hoor maar dat kost wel 15 euro administratiekosten” “Ik heb nooit dit domein opgezegd jullie control panel is brak” / “Uw browser heeft dat wel degelijk gedaan hier zijn de server logs”

  6. @Arnoud, is er een maximale diepte aan comments ofzo? Ik kan niet op Wim zijn post 50206 reageren, zelfs niet met URL hacking. Het linkje “Reageer op deze reactie” ontbreekt.

    @Wim

    Je bent wel makkelijk met je oordeel over deze software hoor. Heb je er ervaring mee? Heb je de software in het verleden wel eens getest?
    Volgens mij heb ik al tweemaal eerder in dit topic gemeld dat ik er ervaring mee heb dus waar je weer vandaan haalt dat dit een niet-onderbouwd en snel oordeel is dat begrijp ik niet. Submitten van de login-gegevens van website A naar website B, het niet meer laten functioneren van login-pagina’s, en – zoals hier – met hidden fields aan de haal gaan. Wanneer er op mijn werk problemen met onze webapplicatie worden gemeld die met inloggen te maken hebben vragen we tegenwoordig standaard of LastPass is geinstalleerd en laten we eventueel op een andere PC opnieuw proberen.

    Je weet vast ook dat eindgebruikers een andere definitie van rommel hebben dan specialisten dus die reviews daar hecht ik niet zoveel waarde aan. Desgevraagd kan ik nog wel 10 stukjes software noemen die echt crap zijn maar toch een goede C.Net review hebben gekregen.

    Verder valt het mij op dat de domeinen vrijwel direct verdwenen lijken te zijn. Mijn eigen registar VIP registreert domeinen per jaar, waarbij je per domein kunt aangeven of je wel of niet automatisch wilt verlengen en waarbij je een bevestiging per email ontvangt als je de verlenging hebt uitgezet. Je kunt daarnaast op een overzicht-scherm al je domeinnamen bekijken waarbij er een waarschuwings-symbool (screenshot) staat bij alle domeinen die niet worden verlengd!
    .nl Domeinregistraties zijn abonnementen voor onbepaalde tijd. Jouw registrar factureert misschien per jaar, dat is net iets anders.
    En de meeste providers bieden daarnaast óók de mogelijkheid om een domein per direct op te heffen en daar praten we hier over.

    1. Er zijn inderdaad maar 3 levels diep mogelijk met reacties.

      En mooi, jouw definitie van “rommel” is nu ten minste duidelijk, maar gebruikers hebben kennelijk behoefte aan dergelijke software, dus bestaat het en is het ook nog vrij populair. Er is dus duidelijk ook een behoefte aan dergelijke software, waardoor dergelijke rommel ook een bestaansrecht lijkt te krijgen. Maar weet jij dan een beter alternatief voor deze software voor de gebruikers van jouw websites?

      En ja, .nl domeinen zijn beschikbaar voor onbepaalde tijd maar omdat de prijs voor een domeinnaam best goedkoop is, zullen veel abonnementen toch voor een lange periode zijn. Want 25 cent per maand declareren? Nee, dat doen registars dus niet, want de kosten van het innen zijn al hoger. Okay, mogelijk dat met webhosting erbij de prijs al redelijker wordt maar het blijven prijzen die nauwelijks lonen om halverwege de maand per direct op te zeggen. Als ik bij de betreffende webhost kijk, zie ik dat ze per jaar factureren, en met een prijs van een paar Euro per jaar lijkt restitutie ook niet echt een punt te zijn. Dus nogmaals, als je een domeinnaam voor een jaar hebt betaald, (voor EUR 3.99 bij een .nl domein) waarom verdwijnt deze dan meteen bij opzegging? En waarom geen extra waarschuwing per email? Of bevestiging per email? Is dit een slordigheid van de hoster of is de gebruiker toevallig ook automatisch aan het bevestigen en/of waarschuwings-mailtjes aan het negeren?

      1. Waarom een opzegging onmiddellijk verwerkt wordt? Omdat het nou eenmaal zo werkt. En omdat een provider per kwartaal bij de SIDN afrekent, bijvoorbeeld. Ik snap dan ook niet zo goed wat je bedoelt met dat restitutie “niet echt een punt lijkt te zijn” omdat het om een paar euro per jaar gaat. Juist wel, omdat het ontzettende marge-business is. Van die € 3,99 die jij per jaar betaalt blijft ex. BTW € 3,29 over en jouw provider betaalt € 0,90 per kwartaal aan SIDN.

      2. Domeinen worden bij registrars meestal per jaar geregistreerd en betaald. Maar opzeggen per direkt kan over het algemeen wel, net zoals halverwege een jaar ook besloten kan worden op het domein over te doen aan een andere eigenaar. Dus als de klant aangeeft een domein per direkt op te willen zeggen, dan kan je dat als provider uitvoeren. Nu wil dat niet altijd zeggen dat er sprake is van restitutie, maar dat is een ander verhaal.

        Waarom kost het geld om een opgezegd domein weer te herstellen? Een opgezegd domein wordt vaak (in ieder geval bij .nl domeinen) in quarantaine geplaatst, zodat een domein van iemand die zicht vergist niet gelijk weggekaapd wordt door een derde. Maar het kost een provider geld om een domein weer uit die quarantaine te halen. En dat is een bedrag dat aanmerkelijk hoger is dat de jaarlijkse kosten voor een domein (denk aan iets van 40 a 50 euro). Het doel hiervan is om mensen ertoe te dwingen om niet al te makkelijk een domein op te zeggen en zich later weer te bedenken (wat administratieve rompslomp met zich meebrengt.

        Coulantie van een hosting provider betekent dat zij die kosten zelf moeten dragen. Bij een grote klant is dat tot daar aan toe, maar bij een klant die een pakketje heeft van 30 euro per jaar betekent dat een aardige kostenpost. En zo groot zijn de marges op hosting voor particulieren en MKB niet.

        (Werk zelf bij een hostingbedrijf.)

        Semi-Offtopic: het is sowieso opmerkelijk waar klanten recht op menen te hebben die misschien een paar tientjes per jaar betalen aan hosting. ‘Ik betaal, dus het moet het maar altijd doen. En jullie moeten maar een failover server hebben die automatisch gaat werken als de normale server uitvalt. En ik wil altijd kunnen bellen als ik ergens mee zit, in plaats van een supportticket (per mail) aan te moeten maken.’ Dat kan natuurlijk allemaal best en bestaat ook, maar niet voor een paar tientjes per jaar. Je krijgt waar je voor betaald, dus als je goedkoop uit wilt zijn, dan krijg je minder service en minder garanties. (Dit is niet gericht op de vraagsteller, maar een algemene constatering.)

  7. @Wim wel goed lezen he :), er is gewoon een bevestiging per e-mail gestuurd:

    Ze sturen overigens wel een mail voor als je niet gezien zou hebben dat het verwijderen gelukt is

    Maar weet jij dan een beter alternatief voor deze software voor de gebruikers van jouw websites?
    De meeste webbrowsers hebben een goede password manager. Die van Chrome is gedistribueerd maar dat heeft ook nadelen. Die van IE gebruikt de Windows API (vroeger Protected Storage) en die is behoorlijk veilig. Verder dan dat moet je volgens mij niet willen gaan met je wachtwoorden. Er zijn genoeg veilige methodes die je uit je hoofd kan gebruiken. Ook Lastpass heeft al een paar (1) (2) security issues achter de rug.

  8. @Richard, dat weten we ook pas sinds de reactie van Koos Looijesteijn 27 oktober 2012 @ 15:18 (Arnoud, een comment nummer zou echt handiger zijn! 😉 ) Maar dat is geen mail waarin je bevestigt dat je wilt verwijderen maar een mededeling dat bij deze het domein is verwijderd. Ik zou juist willen zien dat gebruikers het verwijderen moeten bevestigen via een email. Mijn provider doet dat, dus anderen zouden dat voorbeeld moeten volgen.

    Ik vind het wachtwoord-beheer van Chrome overigens wel prettig omdat Chrome ze “in de cloud” opslaat. Misschien niet helemaal veilig omdat iemand met mijn Google wachtwoord dus ook al mijn andere wachtwoorden kan bekijken maar dat is een risico dat je met al dit soort oplossingen hebt. En nee, Lastpass heb ik niet nodig omdat ik een makkelijk te onthouden wachtwoord-schema hanteer waarin de naam van de website plus een vaste tekst, een nummer en speciale tekens in is verwerkt. Iedere site dus een ander wachtwoord! Alleen, onthouden? Dat doet Chrome dus meestal voor mij, op enkele belangrijke websites na.

    1. Richard, dat weten we ook pas sinds de reactie van Koos Looijesteijn 27 oktober 2012
      ‘Pas’? Die was toch voor jouw statement dat er geen mail was gestuurd? En eerst zei je “En waarom geen extra waarschuwing per email? Of bevestiging per email?” en daarna “Maar dat is geen mail waarin je bevestigt dat je wilt verwijderen maar een mededeling dat bij deze het domein is verwijderd.”.

      Mijn provider doet dat, dus anderen zouden dat voorbeeld moeten volgen.
      Eh…

      Anyway, ik ben dus van mening dat LastPass op diverse gebieden meer kwaad doet dan goed, aan side effects en risico’s.

      1. ‘Pas’? Die was toch voor jouw statement dat er geen mail was gestuurd?
        Kan wel, maar met de nieuwe, geneste layout is het eenvoudiger dergelijke posts te missen.

        De Lastpass kwestie doet mij denken aan hoe in een ver verleden de diverse search engines in staat waren om op diverse websites allemaal gegevens te doen verdwijnen, simpelweg door het volgen van enkele linkjes. Nog steeds houden er soms sites geen rekening met een webspider die gewoon alle URL’s die het tegenkomt langsloopt om het Internet te indexeren. Een simpele URL naar de optie “delete record” werd dan dus regelmatig aangeroepen met als gevolg dat websites data verloren. En ja, daar kun je dan de diverse webspiders van de schuld geven. Maar de schuld ligt uiteindelijk gewoon bij het ontwerp van de site, die kennelijk toestaat dat er zonder bevestiging per email domeinen verwijderd kunnen worden. Dit zijn toch zaken die een provider toch beter zal moeten beschermen.

        1. Daar ben ik het niet in met je eens. Wanneer de gebruikersinterface al extra maatregelen neemt maar deze door een browser-add-on onderdrukt worden, dan ben je nergens. Straks wordt er zo’n bevestigingsmail gestuurd en dan gooit er weer een onhandig verwoorde out-of-office reply roet in het eten en dan ga je weer iets nieuws verzinnen wat een provider moet doen. Krijgen we een e-mail met een captcha erin. En als ik een keertje twintig domeinen wil opzeggen ben ik straks drie uur bezig. Qua je voorbeeld: er is zoiets als robots.txt. Als die URL’s daar gewoon netjes geblocked worden, en er komt toch een spider, wiens fout is het dan?

          Maar goed, ik wilde bij je eerste regel al “the ship of failure floats on a sea of excuses” roepen: there is always a bigger idiot. Je kan dingen maar tot op zekere hoogte hufter-proof maken en daarna mag de gebruiker toch ook wel een stukje verantwoordelijkheid nemen.

          1. Daar ben ik het niet in met je eens. Wanneer de gebruikersinterface al extra maatregelen neemt maar deze door een browser-add-on onderdrukt worden, dan ben je nergens. Straks wordt er zo’n bevestigingsmail gestuurd en dan gooit er weer een onhandig verwoorde out-of-office reply roet in het eten en dan ga je weer iets nieuws verzinnen wat een provider moet doen.
            Dat was het idee van diverse website-bouwers toen bleek dat webcralwers ook de delete-opties langs ging en dus complete systemen kon wissen. Op The Daily WTF kun je nalezen hoe webcrawlers dit konden doen en dat dit gewoon dommigheid is van de website bouwers. Je moet er gewoon rekening mee houden dat een geautomatiseerd script niet per ongeluk van alles kan verwijderen. En dat betekent dus ook een goed systeem voor gebruikers om bepaalde opdrachten te bevestigen. Een website idiot-proof maken is voor sommigen teveel gevraagd, lijkt mij. Toch moet je rekening houden met gekke dingen die soms kunnen gebeuren. Dat een bevestigings-mail door de spamfilter wordt opgegeten is minder erg dan zonder mail-bevestiging domeinen verwijderen. Een gebruiker die bewust een domein verwijdert weet dat hij vervolgens zijn email (en spamfilter) moet controleren. (Kun je altijd nog even op het scherm melden. Wie het onbewust doet kan de email gewoon negeren.

            Betreffende robots.txt, dat werkt dus alleen tegen legitieme webcrawlers. Er zijn genoeg webcrawlers die dergelijke instellingen gewoon negeren en websites scannen om op een kwetsbare plek in te kunnen breken. Idiot-proof zou de standaard moeten zijn, want er zijn genoeg idioten op het Internet. (Ok kwaadwillenden, hackers, script-kiddies en andere saboteurs.)

            1. Uiteraard moet een site hufterproof zijn maar een addon die gewoon een formulier invult en verstuurt kan je echt helemaal niets tegen doen en is toch echt de verantwoordelijkheid van de gebruiker. Natuurlijk kan je leuke captcha er bij zetten die het voor normale gebruikers nog vervelender maakt maar een slimme add-on ontwikkelaar bouwt dat er strak ook gewoon in.

              Dat je als hoster een bevestiging moet sturen lijkt me wel gepast maar de verantwoordelijkheid blijft in dit geval toch echt bij de gebruiker liggen die er voor heeft gekozen om automatisch formulieren in te vullen.

              1. Niet hufter-proof maar idiot-proof. Gebruikers die hun account via automatische scripts beheren zijn er massaal. Login-schermen zijn voor velen irritant en het liefste zien mensen een gewone gebruikers-interface dat draait op hun favoriete besturings-systeem waarbij ze heel eenvoudig alles kunnen beheren. Denk hierbij aan servers die webservice-API’s aanbieden voor gebruikers om hun eigen systeem omheen te bouwen. Wat velen dan ook doen. De een gebruikt daarbij automatische scripts, de ander bouwt een complete applicatie, maar allemaal bedoeld om het beheer te vereenvoudigen. Is wat de software waar ik op mijn werk aan meebouw ook doet: een aantal API’s aanbieden naast de normale gebruikers-interface en de tablet-interface zodat gebruikers hun eigen software daarom heen kunnen bouwen. Vandaar ook dat je bij de “gevaarlijke” opdrachten ook altijd een extra controle moet inbouwen. Laat de gebruiker twee verschillende handelingen uitvoeren, met de nadruk op “verschillende”. Klikken op een link in een email, een code intypen die per SMS is ontvangen, een TAN code invoeren vanaf een TAN lijkt, allemaal beschermende maatregelen tegen de gebruikers die teveel automatiseerden. En ja, het lijkt overkill als het gaat om simpel domein-beheer waarbij de domeinen minder dan een tientje kosten, maar gebruikers met een domein investeren vaak meer in hun domeinnaam. Hosting, email, externe services richting klanten… Allemaal afhankelijk van een domeinnaam en dus erg kostbaar als een domein opeens, per direct is opgezegd. Dus hosters moeten daar gewoon rekening mee houden door een extra controle in te bouwen.

                1. Ik zou werkelijk niet weten waarom ik als software-ontwikkelaar rekening zou moeten houden met zo vergaande roekeloosheid van de gebruiker. Dubbelcheck: ja, zich misdragende clients die niet wijd verbreid zijn: nee. En zoals eerder gezegd, op die manier kan je wel bezig blijven. De kosten van al die maatregelen moet je op andere klanten afwentelen en zeker bij prijsvechters is dat geen valide businessmodel.

                  Gebruik van een API is mijns inziens toch echt iets heel anders en kan je niet vergelijken met een normale web-interface die wordt verziekt door roekeloze add-ons.

                  Vergelijking met bots gaat ook niet op. Er zijn keurige specificaties waar die bots zich aan houden zoals robots.txt en ook rel=”nofollow” links.

                  1. Simpel, eigenlijk. Een gebruiker is roekeloos en maakt iets kapot en stelt de dienstverlener vervolgens verantwoordelijk voor de schade. Zo ook in deze situatie tussen vraagsteller en Versio. Versio heeft een logbestand waaruit duidelijk de schuld van de gebruiker naar voren komt, en de gebruiker stelt dat Versio een betere bescherming had moeten bieden. En zoals Arnoud al aangeeft, de maniet die Versio gebruikt om met hun bewijs te komen staat op de zwarte lijst, indien de gebruiker een consument is. En ook een bedrijf zou mogelijk hier onder uit kunnen komen. Het resultaat is dan dat Versio mogelijk gedwongen kan worden om het domein -zonder kosten voor de gebruiker- te herstellen. Aan de andere kant, de bedragen waar het hier om gaat zijn waarschijnlijk te laag om voor te procederen. Voor beide partijen geldt dat er een baten-kosten analyse gemaakt moet worden, waarbij beide partijen zullen beseffen dat een gang naar de rechter voor beiden duurder zal zijn dan een simpele schikking. En omdat Versio niet toe lijkt te geven, moet de vraagsteller dus overwegen om toe te geven. Of om een consumenten-organisatie in te schakelen om zo alsnog zijn gelijk te krijgen. Niet zinvol als vraagsteller bedrijfsmatig bezig is.

                    Toch zul je als web designer rekening moeten houden met gebruikers die fouten maken en vervolgens de software de schuld geven. De extra moeite die je neemt om software idiot-proof te maken kan uiteindelijk heel veel nare, juridische gevolgen schelen. Het is ook niet om de gebruiker te beschermen, maar om jezelf te beschermen tegen domme gebruikers die automatische scripts gebruiken voor hun account-beheer.

                    En nogmaals, je opmerking over bots die robot.txt en de rel=”nofollow” respecteren, prima. De meesten zullen dit inderdaad doen. Maar er zijn genoeg amateurs die een eigen webcrawler bouwen en al dat doort zaken compleet negeren. En de een zal dit doen om sites af te zoeken naar bepaalde informatie of specifieke media, en de ander doet dit om te zoeken naar een kwetsbare plek om te hacken. De RIAA/MPAA/BUMA/STEMRA/BREIN huren mogelijk ook bedrijfjes in die dergelijke crawlers maken om websites te doorzoeken op illegale uploads en daarbij zullen ze ook het een en ander domweg negeren. Sowieso hoort iedere web developer al het verschil tussen GET en POST te weten, waarbij ze moeten beseffen dat je nooit GET moet gebruiken voor knoppen zoals ‘edit’, ‘delete’ en ‘insert’.

                    Het probleem is gewoon dat gebruiker en dienstverlener elkaar in dit soort gevallen de schuld zullen geven. En als de schade voor de gebruiker behoorlijk oploopt kan het voor de gebruiker lonend worden om juridische hulp in te schakelen om zo de schade te claimen bij de dienstverlener, ook al is de dienstverlener onschuldig aan de fout. Je krijgt dan een hoeveelheid anti-reclame over je heen plus de proceskosten die je misschien kunt verhalen op de gebruiker als je de rechter van je gelijk weet te overtuigen, maar voorkomen is beter dan genezen. En 99.9% van de gebruikers zullen verstandig zijn maar er zitten er altijd een paar tussen die tegen vreemde zaken oplopen. De vraagsteller in dit geval is geen idioot want Versio moet gewoon een extra controle uitvoeren als een domein wordt verwijderd. Alleen indien de vraagsteller ook in de email had aangegeven dat het domein verwijderd kon worden… Tja… Maar dan heeft Versio ook beter bewijs dat de vraagsteller dit echt wilde.

                    1. Zo, Wim, je bent wel standvastig 🙂 Ik denk dat je in principe gelijk hebt, in een perfecte wereld. Maar als ik vandaag besluit een domeinregistratie- / hostingbedrijf op te richten voor goedkoop, ik wil namelijk concurreren op prijs en niet op kwaliteit, dan ga ik geen uren spenderen om een huftiotproof controlepaneel neer te zetten. Overal disclaimers dat alles wat je doet op eigen verantwoordelijkheid is, dat wel. En wellicht is het ongedaan maken van de domheid van mijn klanten tegen betaling zelfs wel onderdeel van mijn businessmodel. Wat MartijnV al zei, je krijgt waar je voor betaalt.

                    2. En zoals Arnoud al aangeeft, de maniet die Versio gebruikt om met hun bewijs te komen staat op de zwarte lijst

                      Nee dat is niet waar, het is alleen zo dat op de zwarte lijst staat dat dit het enige bewijs zo mogen zijn en dat de klant geen ander bewijs zou mogen aandragen. Het bewijs wat er ligt is dat er vanaf dat ip-adres een actie is gedaan om het domein op te heffen. Als de klant aannemelijk zou kunnen maken dat dat niet waar is, mag dat bewijs gewoon mee gewogen worden.

                      Als je deze actie nog eens per mail zou moeten bevestigen komen er weer andere claims (van mij). Ik heb namelijk de naam opgezegd, dit bevestigd met mijn wachtwoord. Dan mag ik er vanuit gaan dat de opzegging ook gedaan wordt. Als ik dan de mail mis waarin ik nogmaals moet bevestigen loopt mijn domeinnaam gewoon door met bijbehorende kosten.

                      Het gaat hierbij niet om zomaar een linkje die aangeklikt kan worden (want in dat geval heb je 100% gelijk) maar om een extra stap waarbij er om je wachtwoord gevraagd wordt. Als jij besluit om je software zo in te stellen dat ie klakkeloos je wachtwoord overal invult én op submit klikt dan vraag je om problemen.

                    3. Versio heeft een logbestand waaruit duidelijk de schuld van de gebruiker naar voren komt (…)En zoals Arnoud al aangeeft, de maniet die Versio gebruikt om met hun bewijs te komen staat op de zwarte lijst

                      Versio gebruikte de logfile als argument in de discussie of de gebruiker wel of niet een handeling had verricht en dat is prima. Om dat dwingend bewijs te noemen, dat staat op de zwarte lijst. Maar die logfile an sich, daar is natuurlijk niets mis mee.

                      De rest van je betoog beschouw ik als een herhaling van eerder gedane zetten dus het lijkt me niet nodig om daar weer op te reageren.

                    4. Versio hanteert hun logbestand als dwingend bewijs en dat mag dus niet. Ja, ze kunnen het logbestand als bewijs opvoeren maar of het ook duidelijk als bewijs dient, betwijfel ik. Dan wil ik namelijk eerst weten wat er precies in dat logbestand staat. En of een IP adres voldoende bewijs is? Als de klant een goed verhaal klaar heeft liggen dan gaat dat logbestand ten onder als bewijs.

                      En als Versio bij het verwijderen van een domeinnaam nogmaals om een wachtwoord vraagt, vind ik als beveiliging niet voldoende. Als een wachtwoord in verkeerde handen is gevallen (of door een automatisch script wordt beheerd) dan levert dat problemen op zoals in deze post van Arnoud wordt beschreven. Dat stelt als beveiliging maar weinig voor. De procedure dat je dergelijke acties nogmaals met je wachtwoord moet bevestigen is gewoon onveilig. Een twee-stappen verificatie is beter. Maar dat is mijn mening.

                      Matthijs Wensveen heeft een goed punt als hij het heeft over dat webhosting tegenwoordig zo goedkoop mogelijk moet zijn. Maar goed, dat geldt overal wel. Maar de goedkoopste zijn betekent nog niet dat je bepaalde verantwoordelijkheden kunt ontlopen. Denk aan de auto-industrie, waarbij enkele fabrikanten het al voor elkaar krijgen om nieuwe auto’s te bouwen met een vraagprijs van een paar duizend Euro. Je mist dan wel zaken zoals airco, stuurbekrachtiging, radio of electrische ramen maar je koopt er wel een vervoersmiddel voor. Desondanks zullen auto’s in Nederland aan een bepaalde minimum standaard moeten voldoen. En ik ben van mening dat dit ook geldt voor de beveiliging van sites waar in waardevolle zaken gehandeld wordt. En ja, domeinnamen zijn best waardevol, als je hoort wat sommige bedrijven bereid zijn om ervoor te betalen. Het verlies van een domeinnaam kan extra, verborgen kosten met zich mee brengen. (Bijvoorbeeld: je klanten kunnen je site niet meer vinden en gaan dus elders bestellen…)

  9. @Wim: Dat het beter kan, ben ik het mee eens maar iemand die die zulk soort tools (en ja, ook ik vind het rommel) gebruikt is daar toch echt zelf verantwoordelijk voor. Net als het veilig houden van je wachtwoord voor waardevolle zaken, het up-to-date houden van je pc en software, etc. Je kan daar het controle paneel echt niet verantwoordelijk voor houden.

    Het bewijs wordt, volgens mij, niet als dwingend bewijs opgevoerd maar gewoon als bewijs. Als de klant een heel goed verhaal heeft waardoor dat bewijs onderuit gaat, prima. Maar in dit geval is het verhaal van de klant dat zijn addon het heeft opgezegd wat dus bewijst dat het daadwerkelijk door hem (of door hem gecontroleerde zaken) is opgezegd.

    1. iemand die die zulk soort tools (en ja, ook ik vind het rommel) gebruikt is daar toch echt zelf verantwoordelijk voor.
      Oh, dat ontken ik ook niet. Die software is ook echt rommel, zoals er best nog wel meer rommel bestaat. Maar moet je daar dan geen rekening mee gaan houden?

      Dergelijke rommel wordt regelmatig aangeprijst als shareware met gratis variant en een premium-versie met extra mogelijkheden. En dat lokt altijd gebruikers die een beetje onwetend zijn van wat de gevolgen van dergelijke software kan zijn. Maar dergelijke software lost wel problemen voor hen op die ze denken te hebben en die volgens hen door dit soort software wordt opgelost. Zelf ben ik daar wat makkelijker in: if ben software ontwikkelaar; ik maak mijn eigen rommel wel. 🙂 Maar al gebruikt de gebruiker rommel, dat is nog steeds geen reden om beveiliging niet serieus te nemen. Helaas zie ik vaak genoeg dat bedrijven beveiliging maar een lastig iets vinden en het liefst zou iedereen alle gebruikers-accounts in een Excel-sheetje inclusief wachtwoorden willen bijhouden want dat is het gemakkelijkste. (Ja, ook voor hackers.)

      Voor software ontwikkelaars moet gewoon gelden dat de gebruiker minimaal de vermogens heeft van een getrainde Chimpanzee. (Let op: minimaal!) Iedere fout, bug of probleem in je software kost je een een banaan of zelfs een tros bananen, afhankelijk van de grootte van de bug, en het doel is de Chimpanzee te laten verhongeren. Is het veel werk om software Chimpanzee-proof te maken? Dat valt best mee, indien je weet wat je doet. Een ervaren programmeur zou hier weinig problemen mee moeten hebben. Aan de andere kant, er zijn programmeurs die hypotheek-gericht werken. Simpel gesteld betekent dit dat de programmeur een hypotheek moet aflossen en daarvoor afhankelijk is van zijn baan. Die inkomsten zijn onmisbaar dus moet hij zorgen dat hij voor de werkgever onmisbaar wordt. Door slordiger te werken ontstaan er meer fouten in de code zodat de programmeur meer werk te doen heeft, en dus langer doorbetaald wordt. En omdat er steeds weer nieuwe fouten in de code komt, weet een programmeur zo zijn baan te behouden tot aan zijn pensioen. En van die fouten profiteren ook de leiding-gevenden van die programmeur, de project-eigenaren en alle andere betrokkenen omdat het product continu door ontwikkelt moet worden. Het bedrijf zelf heeft er een beetje last van, maar kan functioneren omdat de software net goed genoeg is voor het meeste, allerdaagse gebruik. Alleen de enkele uitzondering zorgt voor problemen en vraagt dus verdere ontwikkelingen, wat weer meer werk is voor de programmeur die zo zijn hypotheek verder afbetaalt. Ik heb geen hypotheek…

      1. Shareware?? Die term heb ik al sinds Commander Keen ongeveer niet meer gehoord ;-P

        Wat betreft je Chimpansee vs Hypotheek theorie, daar geloof ik geen snars van. Ten eerste valt het niet mee om bugvrije software te maken. Überhaupt is het niet gemakkelijk om software veilig te maken. Of een eenvoudige UI te maken die een Chimpansee (beetje neerbuigend vind je niet?) Joe User in 1 keer snapt. Niets daarvan is eenvoudig. Ten tweede geloof ik niet dat er veel programmeurs zijn die bewust slechte code kloppen zodat ze onmisbaar worden. Er zijn helaas nou eenmaal veel slechte programmeurs, die goedbedoelde bagger produceren. Het lijkt me ook een riskante onderneming, want je wordt wel vervangen als je klanten het zat zijn om voor de meest voor de hand liggende fouten te moeten betalen, of als je collega’s je code niet begrijpen omdat het spaghetti is.

        Maar goed, het wordt een beetje off-topic hier 🙂

        1. Zo neerbuigend is de term “getrainde Chimpanzee” ook weer niet. Het is immers de minimum-vereiste die ik stel aan de kennis van de gebruiker. De gebruiker hoeft de software niet te snappen, maar moet niet de kans krijgen om door ondeskundig gebruik de boel vakkundig te slopen. Want niet iedere gebruiker is een Einstein die alles meteen snapt. Je kunt je software natuurlijk ook zodanig maken dat alleen slimme gebruikers alles door hebben en de minder slimme gebruikers dus regelmatig in de problemen komen. En dan geld in rekening brengen als je de boel voor die gebruikers keer op keer moet herstellen. Ik kan mij voorstellen dat er bedrijven zijn die dit als business-plan hanteren. Ik vind dat gewoon niet kunnen. Betreffende programmeurs die bewust slechte code schrijven… Ach, een uitzondering zal het echt bewust doen maar velen doen het toch onbewust. Ze maken fouten en leren daar niet van zodat ze een volgende keer weer in de fout gaan. Ze houden hun kennis niet goed bij, zijn hun eigen vaardigheden niet aan het oefenen en maken zich ook niet druk om de kwaliteit van het eindproduct. En nee, dat doen ze niet bewust, maar het zorgt er wel voor dat de producten waar ze aan werken vrij veel onderhoud nodig hebben. Of producten die keer op keer voor problemen zorgen.

          Zo ook in deze situatie. Een klant klaagt over Versio omdat er “spontaan” domeinen werden verwijderd en al is dat de schuld van de klant, als ik Versio was zou ik meteen mijn procedures aanpassen om dergerlijk dom gedrag in de toekomst tegen te gaan. En natuurlijk even nadenken over de klant-tevredenheid want hier is natuurlijk sprake van een ontevreden klant. Ok al is de klant een beetje dom geweest door LAstPass te gebruiken. Want kijk eens naar de gevolgen! Een complete blogpost over deze slechte service van Versio! Wie zou hier nog bij Versio een domeinnaam willen registreren? 🙂

  10. Op Security.nl een mooi artikel over dit onderwerp! De Britse “My Vodafone” verbiedt op dit moment het plakken van het wachtwoord in het betreffende invoerveld. Het resultaat is dan ook dat diverse password managers dan ook niet met deze pagina werken en mensen dus weer hun eigen wachtwoord moeten bijhouden. De reactie van Fabian76 geeft dan ook aan waarom Vodafone zo een foute beslissing heeft genomen omdat gebruikers via password managers juist lange wachtwoorden kunnen gebruiken en onthouden, en voor iedere site een nieuw, uniek wachtwoord kunnen genereren. Doordat het plakken niet meer mag gaan die gebruikers vast weer terug naar korte, makkelijk te onthouden wachtwoorden die ze dan voor diverse sites hergebruiken. Dus tools als Keepass en LastPass hebben om die reden ook een bestaansrecht, hoe rommelig ze ook zijn. Ze helpen immers mee om te zorgen dat gebruikers veiliger omgaan met hun wachtwoorden.

    1. Doordat het plakken niet meer mag gaan die gebruikers vast weer terug naar korte, makkelijk te onthouden wachtwoorden die ze dan voor diverse sites hergebruiken.
      Dat is tenminste een risico wat iedereen wel min of meer snapt. Dat LastPass en consorten een te interessante aanvalsvector zijn (omdat de verhouding moeite vs. opbrengst heel voordelig uitvalt) dat snappen aanzienlijk minder mensen.

      NB offtopic maar terzijde, over de term ‘user’ of ‘gebruiker’ : http://jacks.tumblr.com/post/33785796042/lets-reconsider-our-users

      1. Maar vind je dat een acceptabel risico? De LinkedIn hack van enkele maanden gelden toonde aan dat veel mensen dan hele eenvoudige wachtwoorden gaan gebruiken. Een hacker die alleen accountnamen heeft weten te verkrijgen zou dan minimaal 10% van de accounts kunnen hacken met een dictionary-aanval. LastPass kan dan wel vervelend doen met zijn automatisch inlog, maar zorgt er wel voor dat gebruikers lastigere, moeilijk te raden wachtwoorden gaan gebruiken. Hackers moeten dan een andere aanvalsvector gaan bedenken op dergelijke websites. Door de LinkedIn hack heb ik zelf direct mijn email adres en wachtwoord aangepast en mijn wachtwoord was sowieso al vrij complex. (En mijn email adressen zijn ook per account uniek, dankzij mijn domeinnaam.) Maar er zijn genoeg gebruikers die 1 email adres gebruiken met 1 wachtwoordt voor de 40+ online accounts die ze hebben. Ik ben dan ook meer een voorstander van het OpenID systeem zodat je bij b.v. Google, Facebook, Twitter of andere provider inlogt om daarmee op honderden andere sites in te kunnen loggen. Dan hoeven gebruikers minder wachtwoorden te houden en zullen ze dus sneller een complexer wachtwoord kiezen. Dan is dan ook wel weer noodzakelijk omdat een hacker dan met een enkele aanval opeens tientallen accounts kan overnemen, maar een dergelijke aanval is een stuk lastiger. Want “iusmentis@1966#2012.wimtenbrink” is veel lastiger te raden dan “123ABC”… Oh, gatver… Nu moet ik mijn wachtwoord voor Arnoud’s blog wijzigen! 🙂

        1. “iusmentis@1966#2012.wimtenbrink” Neem van mij aan: het aantal werknemers en/of consumenten die zo’n lang wachtwoord neemt (laat staan wil), is hooguit een paar procent. Zeker als ze dat moeten invullen op “40+” sites. Ze zullen dat al gauw moe worden en een veel korter wachtwoord kiezen. Kijk ook maar eens in gelekte wachtwoordbestanden op pastebin enzo: zelden zie je zulke lange wachtwoorden. Men wil ze gewoon niet. (Ik ook niet.)

          1. Ach, qua wachtwoorden ben ik altijd al een beetje vreemd geweest. Ik kan snel typen dus lange wachtwoorden onthouden is geen groot probleem. Mijn langste wachtwoord die ik heb gebruikt was 8 jaar geleden voor een website die alleen letters als wachtwoord toestond. Ik koos toen “osewiesewosewiesewallakristalla” als wachtwoord. Voor wie het kinderliedje kent, heel eenvoudig! 🙂 Desondanks toch lastig te raden. Ik heb ook wel eens discussies hierover gehad met een systeembeheerder die geen wachtwoorden langer dan 12 tekens toestond. Zijn uiteindelijke motivatie was uiteindelijk: “Ik heb het hier voor het zeggen en ik bepaal wat wel en niet mag!” Tja, tegen dergelijke dommigheid is ook weinig in te brengen. Maar ik heb op deze site wel eens eerder aangegeven dat het eenvoudig is om lange wachtwoorden te gebruiken die per website uniek zijn. “iusmentis@1966#2012.wimtenbrink” is daar een mooi voorbeeld van. Je neemt de naam van de website, plakt er een speciaal teken en je geboortejaar achter (of een ander, makkelijk nummer) gevolgd door een tweede, speciaal teken (en herhaal nummer en teken eventueel een paar keer) en ten slotte een makkelijk te onthouden woord zoals b.v. je naam. Je krijgt dan al snel een vrij veilig wachtwoord dat makkelijk te onthouden is.

            Maar ja, mensen hebben niet alleen een hekel aan lange wachtwoorden omdat ze het moeten onthouden. Veel mensen kunnen ook niet al te snel typen en lange wachtwoorden zijn dan vervelend. Dat merk ik ook aan collega’s die soms ge-ergerd wachten tot ik mijn wachtwoord heb ingevuld. Zes tekens is voor hen al meer dan genoeg dus als ze moeten wachten tot ik er 12 heb ingevoerd… 🙂 Vandaar ook dat ik het OpenID initiatief zo prettig vind. Je logt eenmaal in bij de OpenID provider en je hebt vervolgens toegang tot tientallen websites. En natuurlijk is de wachtwoord-functie van Google Chrome ook prettig. Scheelt mij weer typwerk. 🙂

            Maar dat er mensen zijn die geen lang wachtwoord willen, begrijpelijk. Maar die willen volgens mij dan ook geen goede veiligheid…

            1. Ik kan snel typen dus lange wachtwoorden onthouden is geen groot probleem.
              Fantastische logica dit. Maarre, kan je echt zo snel typen?
              Dat merk ik ook aan collega’s die soms ge-ergerd wachten tot ik mijn wachtwoord heb ingevuld

              1. Mijn wachtwoork kost me meestal maar twee tot drie secondes, maar na de eerste 6 toetsaanslagen worden anderen al ongeduldig. Wanneer ze het verder op zien lopen dan begint de ongeduld echt toe te nemen. Maar goed, dat was erger toen “osewiesewosewiesewallakristalla” nog mijn wachtwoord was. Maar goed, sowieso ben ik vaak de gehele dag aan het typen en dan krijg je wel een redelijke snelheid. Ook b.v. met mijn lange antwoorden waar sommige personen regelmatig over klagen. En dat terwijl het mij nauwelijks meet tijd kost dan als ik dit alles uit zou spreken. 🙂

                  1. Een muis? Wat is dat? 🙂 Om eerlijk te zijn, ik gebruik vaak de shortcut keys en vrij weinig de muis. Moet je tijdens het lezen maar eens op CTRL-W drukken als je Chrome of Firefox gebruikt. Lachen! 🙂 Ik werk al meer dan 30 jaar met computers en in mijn begintijd was de muis nog vrij onbekend. In het DOS tijdperk was ik er wel vroeg bij met mijn muis, maar er waren maar weinig programma’s die de muis ondersteunen. In Visual Studio kun je je eigen shortcuts instellen wat ik dan ook doe voor de commando’s die ik regelmatig gebruik. En ook in de webbrowser kun je veel uitvoeren zonder een muis te gebruiken. B.v. omhoog en omlaag scrollen met CTRL+Pijltje of door velden heen klikken met de TAB toets. Of de submit-knop aanroepen vanuit ieder invoerveld dat geen multi-line veld is. Voor de enkele keer dat ik de muis nodig heb, ligt de muis gewoon naast mijn toetsenbord. En ja, er zijn wel taken waarbij ik de muis veel gebruik, maar daarbij hoef ik vaak niet te typen. En als ik veel moet typen heb ik de muis niet zo hard nodig.

                    1. Heb je dan misschien ook Linux i.p.v. Windows? 😉 Ik zit nu bijv. te klooien met ctrl+F4 wat niet werkt (bij een emailtje) binnen een TS-sessie, om wat voor reden dan ook… Moet ik toch weer de muis pakken om op ’t kruisje te klikken.

                    2. Ik gebruik af en toe Linux vanuit een virtuele machine maar dan vaak in console-mode, met een command-prompt. 🙂 Dan is een muis niet erg handig. En verder beheer ik wel eens een Linux server vanuit de webbrowser, en die draait dan weer onder Windows. Ik heb daarnaast ook nog een Bamboo tablet aan mijn PC gekoppeld, wat er soms ook voor zorgt dat ik de muis niet gebruik.

Geef een reactie

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