Maar ik klikte alleen per ongeluk op die hyperlink in de mail!

| AE 7075 | Privacy | 43 reacties

bevestigingslinkEen lezer vroeg me:

Onlangs diende ik een aanvraag in bij een bedrijf. Ik kreeg een mail en moest op een link klikken om de bestelling te bevestigen. Toen keek ik even niet uit en klikte ik per abuis op die link. En nu zegt het bedrijf dat ik (als consument) vast zit aan die bestelling omdat zij niet kunnen zien of mijn klik opzettelijk of per ongeluk was. Wat nu?

Een overeenkomst komt volgens de wet tot stand doordat je een aanbod aanvaardt. Daarbij gelden in het algemeen geen eisen zoals schriftelijkheid. Zolang de handeling maar duidelijk bedoeld is als een akkoord, is het een akkoord.

Natuurlijk kun je per ongeluk zo’n handeling verrichten. Of je zegt voor de grap ja en de wederpartij hoort de ondertoon niet. De wet kent daarom de regel van art. 3:35 BW: als de wederpartij er redelijkerwijs op mocht vertrouwen dat je het serieus bedoelde, mag hij je eraan houden ook als jij het eigenlijk niet wilde doen.

De vraag is dus: mag de wederpartij bij het klikken op zo’n link concluderen dat je dat serieus bedoelde?

Specifiek bij zulke hyperlinks is geen jurisprudentie bekend, voor zover ik weet. Mijn gevoel zegt me dat je hier pech hebt als je per ongeluk op die link klikt. Er is geen manier om na te gaan dat je dit niet bedoelde en de handeling op zich is iets dat normaliter zeer bewust gebeurt. Ik vind het dan ook redelijk dat je als wederpartij concludeert dat de link met opzet en doelbewust is aangeklikt.

Natuurlijk moet de link wel expliciet aangemerkt zijn als “Klik hier om te bevestigen dat u een contract wil” en niet “Meer informatie” of “Ok” of zoiets nietszegends.

Overigens, mogelijk dat je via de Wet koop op afstand de overeenkomst nog kunt ontbinden. Bij de meeste bestellingen (ook aanvragen voor diensten) kan dat tot 14 dagen na contractsluiting, en bij productleveringen tot 14 dagen na levering van het product.

Wat vinden jullie? Had je maar beter op moeten letten, of moet een bedrijf dat zo werkt er rekening mee houden dat mensen per ongeluk klikken?

Arnoud

Deel dit artikel

  1. Ik ben van mening dat een bedrijf wat zo werkt er vanuit moet gaan dat de link ook per ongeluk geklikt kan worden, of door beveiligingssoftware gevolgd zou kunnen worden.

    Als onderneming wil je daar geen gezeur over, hoe moeilijk moet het zijn: Klik op link ter bevestiging, toon een formulier met de bestelling en laat een checkbox bij het woord akkoord zien. Klik op checkbox klik op submit. Dat lijkt mij vrij ondubbelzinnig.

  2. Het lijkt mij toch dat als je meteen een mail stuurt met “sorry, dat was onbedoeld”, dat je de koop dan nog kunt ontbinden voordat deze daadwerkelijk behandeld wordt? Tuurlijk, men zal in het verkoopsysteem de order terug moeten draaien. Maar dat is dan het enige.

    Als je pas een dag later reageert, dan kan het te laat zijn ja.

    • Je hebt hier twee regelingen die van toepassing zijn. Art. 3:37 lid 5 BW bepaalt dat je een aanvaarding kunt intrekken door gauw een tweede bericht te sturen die de ontvanger eerder of gelijktijdig bereikt als je aanvaarding. Als de aanvaarding via elektronische weg is verstuurd, is dat onmogelijk (R.E. van Esch, Juridische aspecten van elektronische handel, Deventer: Kluwer 2007, p. 159).

      Het tweede artikel is art. 6:227c BW, wat bepaalt dat je mag annuleren zolang de overeenkomst nog niet is bevestigd door de verkoper:

      Indien een wederpartij van een dienstverlener langs elektronische weg een verklaring uitbrengt die door de dienstverlener mag worden opgevat hetzij als een aanvaarding van een door hem langs elektronische weg gedaan aanbod, hetzij als een aanbod naar aanleiding van een door hem langs elektronische weg gedane uitnodiging om in onderhandeling te treden, bevestigt de dienstverlener zo spoedig mogelijk langs elektronische weg de ontvangst van deze verklaring. Zolang de ontvangst van een aanvaarding niet is bevestigd, kan de wederpartij de overeenkomst ontbinden. Het niet tijdig bevestigen van de ontvangst van een aanbod geldt als verwerping daarvan.
      Als de verkoper automatisch een bevestiging stuurt, ben je dus te laat, maar anders kun je de overeenkomst nog ontbinden.

  3. Het is natuurlijk een optelsom. Als je op de website een handeling verrichtte, en daarna binnen 5 minuten met een bevestigingsmail een bevestiging geeft, dan vind ik het ophouden.

    Maar als die knop per ongeluk een maand later was aangeklikt, had het knopje niet meer mogen werken. (verlopen) Anders is het wel heel makkelijk om dan nog per ongeluk aan te klikken. Of als hij niet actief om die mail had verzocht (verzoek om “meer informatie”), maar je krijgt gewlijk een mail waarmee je direct onherroepelijk kan bestellen… Sja, daar vroeg je niet om, dus ga je ook niet uit van de verstrekkende gevolgen van het niet goed lezen voordat je klikt.

    En als laatste vind ik dat een belletje of een mail binnen 5 minuten om aan te geven dat het per ongeluk was, duidelijk genoeg moet zijn, dat er geen sprake was van een vrijwillig akkoord, ongeacht wat er op die knop stond. (Tenzij er echt failsafes in zaten zoals “weet u het zeker dat …?”)

  4. Het lijkt mij redelijk om er vanuit te kunnen gaan dat iemand die op een bevestigingslink klikt, de bestelling willde bevestigen. Nog meer “weet u het zeker”, “weet u het echt wel zeker” bij alle mogelijke interacties is alleen maar ontzettend irritant. En zoals Arnoud al aangeeft, als je in een echte winkel per ongeluk “ja” zegt, zit je ook aan de koop vast. Met geautomatiseerde bestelprocessen online kun je er best vanuit gaan dat er al kosten gemaakt zijn enkele seconden nadat je op die link klikt, bijvoorbeeld een domeinnaam vastgelegd.

    Soms doe je iets per ongeluk en is het dus een gevalletje pech. We hoeven niet alle gevallen van pech en tegenvallers maximaal juridisch of technisch uit te sluiten. Wie misklikt, moet op de blaren zitten.

    • @Thijs: Wie zegt er nu per ongeluk “Ja” in een winkel?? en dan nog wordt het dan -als er geen bandopnames zijn- een welles-nietes spel. Per ongeluk klikken is wel iets sneller gebeurd.

      Om te voorkomen dat je als bedrijf later te maken krijgt met de extra kosten voor het retourneren en re-stocking wanneer de klant wenst gebruik te maken van zijn retourneerrecht onder “De Wet Koop op Afstand” zou ik altijd een bevestigingsmaal naar de klant sturen (eventueel met het verzoek de koop te bevestigen).

      • Ik heb wel eens iets in m’n winkelwagentje gelegd bij de Albert Heijn (“even over nadenken”) om er pas bij het uitpakken thuis achter te komen dat ik dat niet tijdighad teruggelegd. Dat product is gescand en betaald dus de AH mag vermoeden dat ik dat product wilde kopen. Zij kunnen niet ruiken dat ik dat ene artikel uitkoos als “even nadenken” en nog geen wil had te kopen. Maar inderdaad het is zeldzamer in zulke situaties.

        Een twijfelgeval vind ik altijd het bakje brood bij een restaurant. Regelmatig zetten ze dat zomaar neer, of vragen ze “wilt u een broodje vooraf”. Hoe weet je dan dat ze dat willen verkópen of dat het juist gratis is als service? Zeker als ze het zomaar neerzetten word ik altijd érg geïrriteerd als het achteraf op de rekening staat.

        • Oh, dat bakje brood heb ik nog nooit gecontroleerd in een rekening maar het lijkt mij vrij logisch dat als jij iets krijgt waar je niet expliciet voor vraagt, dat het dan gratis is. Uiteindelijk maakt het niet uit want je betaalt er links of rechtsom toch voor. Nou is het zo dat ik meestal een fooi geef in een restaurant dat neer komt op afronden naar boven met briefjes (dat is een andere cultuur dan met name de VS). Mocht de service slecht zijn of ik zie dat men mij dingen in rekening brengt waar ik niet om heb gevraagt dan betaal ik gewoon geen cent meer, en eventueel is het dan ook de laatste keer dat ik bij dat restaurant kom. Probleem opgelost.

          Veel vervelender in restaurants is de onmogelijk idiote hoeveelheden zout in het eten. Veel meer dan je nodig hebt. Als je al op een zoutarm dieet zit, dan valt dat extra op dwz het komt extra hard aan. De reden dat ze het doen? Zodat je meer drinkt. Terwijl lekker en gezond eten prima samen kunnen. Waarom niet het nuttige met het aangename combineren? Dat ze dat bij McDonalds niet doen zal niemand verbazen, maar een gemiddeld restaurant zou zich niet tot zo’n niveau hoeven te verlagen.

          Ontopic, ik denk dat het er om gaat hoeveel wilsbekwame handelingen er aan vooraf gaan. Je wilt de klant niet steeds vragen of-ie het zeker weet (dat maakt de klant mogelijk onzeker of aan het twijfelen) maar aan de andere kant wil je ook tevreden klanten, en omzet draaien. Als het een belangrijke, dure deal is (zeg, een auto van 20.000 EUR) dan mag er best een extra “weet u het zeker?” terwijl de Cinnastix van Dominos (we blijven het toch over eten houden he ;)) a 1,50 EUR niet een extra confirmatie nodig heeft. En toch doen webwinkels het (vziw!) wel netjes. Ga je naar checkout (winkelwagen icoontje) dan krijg je netjes een lijstje te zien wat je zoal koopt, wat het kost, de totale prijs, de BTW. Dat is van een veel hoger niveau dan het per ongeluk klikken op een e-mail. Dan kan zelfs als je muis per ongeluk uitschiet, en op een smartphone kan het ook snel gebeuren.

          Wat ik mij ook afvraag is zodra je dan op zo’n link klikt, kun je het dan ook nog makkelijk cancellen daarna, en zo ja hoe? E-mailen zou kunnen maar vereist handmatige handelingen van beide partijen. Daar is geen van beide partijen bij gebaat. Bovendien zal het allemaal niet vaak gebeuren, en onder het mom van klant is koning zouden bedrijven niet moeilijk moeten doen.

  5. Ik vind dat het bedrijf verkeerd zit: http://www.w3.org/TR/webarch/#safe-interaction

    De hyperlink in de e-mail had moeten verwijzen naar een pagina waarin de klant met een knop (NIET met een hyperlink!) de bestelling kan bevestigen.

    Als de aanbieder zijn klanten niet wil vermoeien met zo’n twee-staps methode, dan moet hij ook zelf maar de risico’s dragen: als iemand gaat klagen, dan moet dit in het nadeel van de aanbieder uitkomen.

    PS. Ik ken het bovenstaande principe doordat het ook bij Bitcoin URIs heeft gespeeld.

    • Sterker nog, de HTTP spec zelf zegt EXPLICIET “the user did not request the side-effects [performed by a GET request], so therefore cannot be held accountable for them”: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

      Er zijn/waren ook browsers die bij voorbaat al links gaan volgen om de pagina’s alvast te cachen, zodat die sneller verschijnen op het moment dat je erop klikt. Of stel, je mail is (per ongeluk, slechte beveiliging, whatever) via het publieke internet te benaderen en de spider van Google komt langs en “klikt” op je link. Dit soort dingen zijn allemaal reden waarom je je echt hebt te houden aan bovenstaande regel uit de spec.

      Als zelfs de internetstandaard die bepaalt hoe het web in elkaar zit vindt dat dit niet kan denk ik dat je best een sterke zaak hebt om te beargumenteren dat zo’n “klik op de link om te accepteren” nooit bindend kan zijn.

      • Een RFC gáát niet over de vraag of de wederpartij iets mag opvatten. Met die passage wordt volgens mij meer bedoeld dat een GET request geen onverwachte dingen mag doen, bv. in een dynamische webapplicatie. Een link “delete database” zou met een HTTP DELETE commando moeten worden gegeven, zodat de gebruiker het merkt als hij die link wil activeren.

        Ik weet zeker dat ze niet bedoelen dat een HTTP GET nooit een juridisch bindend resultaat mag opleveren. Anders gaat menig “bestel nu” knop bij webshops ook ineens de mist in.

        • Ik weet zeker dat ze niet bedoelen dat een HTTP GET nooit een juridisch bindend resultaat mag opleveren. Anders gaat menig “bestel nu” knop bij webshops ook ineens de mist in.

          Ik denk dat het juist WEL wordt bedoeld: volgens mij is dit afgeleid van het “safe interaction” principe waar ik naar heb gelinkt. Het komt erop neer dat je onbezorgd (“blind”) op allerlei hyperlinks moet kunnen klikken zonder je zorgen te hoeven maken over de consequenties. Je vraagt alleen informatie op; er zouden geen bij-effecten moeten zijn, zoals het plaatsen van een bestelling.

          Een “knop” is daarbij iets anders dan een “hyperlink”. Klikken op een knop kan, op technisch niveau een “HTTP POST” opleveren, een hyperlink alleen een “HTTP GET”. De “safe interaction”-regels gelden alleen voor “HTTP GET” (en voor URIs; er zijn dus geen HTTP POST URIs).

          Dat technische verschil is van belang, omdat dit er voor zorgt dat de gebruiker zich softwarematig kan beschermen tegen onveilige interacties. Een e-mail client kan bijv. zo gemaakt worden dat alleen hyperlinks worden weergegeven, en knoppen pas na het aanschakelen van extra inhoud. Een browser zou een “weet u het zeker” dialoog kunnen weergeven bij het klikken op een POST-knop. Dit stelt de gebruiker in staat om het “per ongeluk verkeerd klikken” probleem drastisch in te perken.

          • Ik kan me niet voorstellen dat een technische spec juridische gevolgen gaat definiëren van een protocol. Los daarvan: ook een formulier met http GET heeft knoppen in de standaard renderingen van browsers.

            Verder denk ik dat de praktijk belangrijker is, zeker als die 80% afwijkt van de specificatie. Je zou alle websites de kost moeten geven die bv. nieuwsbriefinschrijvingen beheren met GET-uri’s. Het breekt voor mijn gevoel té veel in de praktijk als je dan als rechter formalistisch zegt “de gebruikte methode is onjuist, gaat niet door”.

            • De technische spec definieert niet de juridische gevolgen, maar het definieert wel de taal, en de taal kan best juridische gevolgen hebben.

              Ik vind dat iemand zich er best op moet kunnen beroepen: “ik deed alleen maar een HTTP GET, dus ik vroeg alleen maar informatie op”. Een met HTTP GET gemaakte overeenkomst kan best juridisch geldig zijn, maar alleen als die geldigheid niet door één van beide partijen wordt betwist. Als de “link-klikker” zegt “ik klikte alleen maar op een link; ik wilde helemaal geen overeenkomst aangaan”, dan heeft ‘ie wel een goed punt, zelfs als 80% van de andere mensen (onterecht, maar wel rechtsgeldig) hyperlinks gebruikt voor hun overeenkomsten.

            • Point taken; de praktijk is anders. Maar het komt helaas ook vaak genoeg voor dat het geen formulier betreft en de linkjes gewoon als links zijn gestyled.

              Bovendien zijn er van die weirdo’s (zoals ik, en genoeg mensen die ik ken) die tekstgebaseerde mailprogramma’s zoals mutt gebruiken waarin er geen sprake is van “styling”, en alle links er exact hetzelfde uitzien. Ik laat HTML-mail automatisch door lynx halen om het te converteren naar tekst. Alle links worden dan vergaard in voetnoten. Het gebeurt me wel eens af en toe dat ik dan per ongeluk de verkeerde link pak, omdat de HTML van veel van die marketing-emails er vaak echt als prut uitziet als je het als tekst rendert. Ga je me echt zeggen dat ik, omdat die gasten EN niet de moeite nemen om een gefatsoeneerde tekstversie aan te leveren EN zich niet aan de voorschriften van standaarden houden, daarom eraan gehouden kan worden als ik de link copy/paste in een browser?

            • Zijn er in de praktijk ook browsers die GET-links alvast vantevoren ophalen om ze sneller te kunnen renderen als de gebruiker er op klikt? Er zijn volgens mij in ieder geval browser-plugins die een mini-versie van een webpagina laten zien als je over een link hovert, zodat je weet waar je naartoe gaat. (Die werken natuurlijk alleen op GET-links, want GET-links hebben geen bij-effecten, volgens de spec.)

              Dsu als ik zo’n plugin heb, en een bedrijf beweert dat ik een aanbod heb geaccepteerd door op een knop te klikken, kan ik dat eenvoudig weerleggen, en tevens de schuld bij het bedrijf neerleggen aangezien ze zich niet aan de spec hebben gehouden.

              Toch?

                • Een ‘gewone’ hyperlink kan via een klein beetje Javascript ook een HTTP POST uitvoeren. Ook als je helemaal nergens op klikt, kan met Javascript een HTTP POST worden uitgevoerd. Als gebruiker heb je helemaal niet door wat voor HTTP request er door je browser wordt gemaakt en heb je er ook geen invloed op. Dat maakt een juridisch onderscheid tussen HTTP GET en POST erg lastig.

                  • En die JS kan dan weer worden uitgeschakeld door mailclients of browsers die om veiligheidsredenen geen JS accepteren (ja, ik gebruik ook NoScript op mijn thuiscomputer). Er zijn gewoon teveel zaken om rekening mee te houden, en een goede aanpak die al die zaken omzeilt is een bevestigingspagina die onomstotelijk duidelijk maakt dat je akkoord gaat.

                    Sowieso, we vergeten ook allemaal even dat het e-mail betreft: wat als iemand die mail onderschept en de link voor jou klikt? Dan kun je ook nog eens gaan proberen te bewijzen dat jij dat niet was. Het is dus sowieso beter als het bovendien nog eens achter een beveiligd inlogsysteem zit.

                    Tl;dr: beveiliging is moeilijk, laten we lekker gaan (web)shoppen

                • Het probleem is dat je het aanbod (de link) op twee verschillende manieren presenteert naar de gebruiker. Aan de ene kant staat er in taal dat het gaat om het accepteren ergens van. Als je daarentegen naar de manier van presenteren (een link) dan mag je er vanuit gaan dat je juist nog niet accepteert.

                  In dat opzicht werkt denk ik art. 3:35 BW niet. Immers kon je er helemaal niet op vertrouwen dat ik werkelijk het aanbod wilde aannemen. De actie van het klikken op een link is namelijk te ambigu om een dergelijk vertrouwen te scheppen.

                • Dat kan best zo zijn, maar in dit geval gaat het er om welke intentie er achter de klik zit. En het is makkelijk te verdedigen dat een proces dat leidt tot een GET-request nooit de intentie kan hebben om juridisch iets te aanvaarden, aangezien in de http-specificatie staat dat een GET-request nooit tot side-effects mag leiden, en een juridische aanvaarding een side-effect is.

                  Als zodanig leg je de schuld dus neer bij degene die zich niet aan de specificaties heeft gehouden, namelijk de webwinkel die een GET-request accepteert als een juridische aanvaarding.

                  Ik ga er vanuit dat de CookiesOK plugin POST-requests stuurt. En afgezien daarvan is de plugin er specifiek voor bedoeld om automatisch juridisch dingen te aanvaarden (cookies), dus dan ben je wel verantwoordelijk als het dan een keer iets verkeerds aanvaardt.

                  • Voor mij is een technische specificatie niet van belang bij de vraag wat de juridische uitkomst van een handeling is. Waar het meer om gaat, is in hoeverre die specificatie ook daadwerkelijk in de praktijk gevolgd wordt. Als ik een nieuwe header introduceer waarmee ik aangeef niet getrackt te willen worden maar geen bedrijf trekt zich er wat van aan, dan heb ik mischien wel een RFC maar geen juridisch bindende handeling.

                    Ik weet niet of het GET of POST stuurt, maar bedoel je nu dat ook bij GET het wél bindend is mits de kliktool maar ontworpen is om bindende acties te ondernemen? Dan ben je er toch meteen, dat is een bestelknop toch ook?

                    • Wat ik wil zeggen is dat je kunt argumenteren dat een tool is bedoeld om geen bindende acties te ondernemen, en dat je dat argument kunt bewijzen met de http-specificatie over GET-requests (de tool werkt volgens de specificaties, en de specificaties roepen iets over de bindendheid van de acties). Zodat je dus verder kunt argumenteren dat als deze tool per ongeluk toch een bindende actie doet, dat de schuld daarvan dus bij het bedrijf ligt, die diezelfde specificatie niet juist heeft geimplementeerd. En dat je dus niet gebonden bent aan die actie.

                      En, afgezien daarvan, dat een specificatie iets roept vind ik toch zeer zeker wel een vorm van bewijs. Op zijn minst ligt nu de bewijslast bij de andere kant (om aan te tonen dat in de praktijk de specificatie niet wordt gevolgd).

                • Arnoud het volgen van links op de achtergrond was een vrij standaard methode om het browsen ‘te versnellen’ voor er breedband was. Bijvoorbeeld http://en.wikipedia.org/wiki/GoogleWebAccelerator , maar ook ingebouwd in bijvoorbeeld Mozilla browsers.

                  Een akkoord achter een link is dus link 😉 En je doet niet iets ongewoons als je links prefetcht. Het is dus niet alleen door de RFC waardoor je er bij een get request niet vanuit mag gaan dat er een akkoord op iets is gegeven. Je kan er niet vanuitgaan omdat het geen uitzondering is dat er get requests worden gedaan zonder interactie van de gebruiker en dus kan je er niets uit afleiden of een wilshandeling.

        • Een RFC gáát niet over de vraag of de wederpartij iets mag opvatten. Met die passage wordt volgens mij meer bedoeld dat een GET request geen onverwachte dingen mag doen, bv. in een dynamische webapplicatie. Een link “delete database” zou met een HTTP DELETE commando moeten worden gegeven, zodat de gebruiker het merkt als hij die link wil activeren.Ik weet zeker dat ze niet bedoelen dat een HTTP GET nooit een juridisch bindend resultaat mag opleveren. Anders gaat menig “bestel nu” knop bij webshops ook ineens de mist in.

          De gedachte achter GET is dat er geen side effect is dan het opvragen van een resource (afgezien van wat logging). Een browser, CDN of proxy mag besluiten een GET request 0 (cache), 1 of meerdere keren (prefetch) uit te voeren.

          Bij een POST request is dat niet het geval (vandaar dat je bij het verversen van een pagina die het resultaat is van een POST request ook de vraag van je browser krijgt of je het request opnieuw wilt verzenden).

          Bij een GET request kan je dus altijd aanvoeren dat je proxy of browser een prefetch heeft gedaan (en sterker nog: dat is ook een reëele mogelijkheid).

          Een ‘Bestel nu’ knop bij een webshop die technisch in orde is zal altijd een POST request zijn.

  6. Ik vind dit alleen maar aanvaardbaaar als dit een extra bevestiging is van de consument op een eerdere aanvaarding via een site. Er moet hieraan vooraf al een bestelling zijn gedaan, die nu nog bevestigd moet worden. In zo’n geval heb je meestal al naam, adres en vaak ook nog je bankgegevens verstrekt.

    Het moet dus niet een vrijblijvende offerte aanvraag zijn, die per mail moet worden bevestigd. Dan lijkt die link me wat te makkelijk. Hoevaak meld je je niet voor de een of andere nieuwsbrief aan (!), of klachtensite, waar je dan nog op een link moet klikken om je aanmelding te bevestigen. Het lijkt mij dat als het een vrijblijvende offerte is dat er alleen maar een link mag zijn om te bevestigen dat je de offerte hebt ontvangen. Niet een akkoord met de offerte zelf, de aanvaarding.

    Zeker niet als het een aanbod is dat per direct ingaat, als het iets betreft waar geen 14 dagen bedenktijd voor is. Zoals een directe dienst.

    Deze casus is m.i. nogal leeg. Gewoon een paar zinnen zonder duidelijk te maken waar het hier nu specifiek over gaat. Aanvraag staat er, aanvraag voor wat, je vraagt toch geen stoel aan, dus het zal dan wel een dienst zijn. En die dienst zal dan wel per direct ingaan. Anders zou er bij die link moeten staan dat men 14 dagen bedenktijd heeft, want dat moet volgens de nieuwe wetgeving.

    Ik vind linken sowieso link! Moet denken aan die sms diensten, iemand zit een onschuldig spelletje te spelen en klikt op een button en ineens blijk je aan een of andere sms dienst vast te zitten waar je dan wekelijks voor betaald. Dat gaat dan via je provider en je komt er pas na een paar maanden achter dat je steeds 25 euro te veel betaald. Consumentensites staaan er vol van.

  7. Wat gebeurt er als je niet op de link hebt geklikt en toch daarna wordt gesteld dat je aan een beweerdelijke afgesloten overeenkomst “vastzit”.? Zie o.a het artikel “wie draait er aan de knoppen ” van EMLS en het artikel “1.2 miljard namen, inloggegevens en e-mailadressen liggen op straat” .

  8. Ik had laast bij een speciale aanbieding van een duitse webwinkel geklikt op een knop die duidelijk gemarkeerd was als bestellen met betaalverplichting. Daarna moet ik mijn gegevens invullen en het afleveradres. De site crashte echter bij het berekenen van mijn vervoerskosten van duitsland naar mijn NL afleveradres en ik kon met geen mogelijkheid meer in het bestelproces terugkomen om dat af te maken en zelfs niet meer mogelijk om het product nog een keer te bestellen (omdat ik de laatste had gekocht) Een week later begon het bedrijf mij aan een overeenkomst te herinneren. Ik heb het toen uitgelegd en het was verder geen probleem maar het had wel lastig kunnen zijn omdat ik inmiddels een ander vergelijkbaar product ergens anders had besteld.

  9. In een ver verleden had ik door snel-snel-snel willen zijn en niet willen wachten totdat de mail geheel geladen is, nog wel eens last van verschuivende inhoud in een mail. Waardoor een klik bedoeld voor een link ‘unsubscribe’ nog wel eens kon eindigen op een productplaatje met anchor. Met als gevolg dat mijn browser de link achter dat object ging bezoeken. Ik kan mij voorstellen dat met deze uitleg het mogelijk is dat je misklikt, maar de vraag is dan: wat hád je willen klikken in datzelfde mailtje? Een anchor om de bestelling te annuleren (wat in mijn ervaring een zeldzaamheid is)? Een link waarbij je je account/betaal/adresgegevens kan inzien en/of aanpassen?

    Omdat de webwinkel niet kan zien welke intentie je had bij het klikken, is het mijn mening dat je beter je klant kan leiden naar een pagina met daarop alle gegevens voor de bestelling, en een grote dikke vette knop ‘Ik bevestig mijn bestelling zoals hierboven aangegeven’.

  10. Als je iets verkoopt wat maatwerk is of als speciale bestelling geldt (dat kan een domeinnaam zijn, of een op maat gemaakte inloopkast) dan kun je als winkelier je best doen om te verifiëren of de bestelling klopt. Blind aannemen dat een bestelling van een wildvreemde “wel zo bedoeld zal zijn” brengt risico’s met zich mee. Bedrijfsrisico?

  11. Computerhackers zijn in staat op grote schaal bankrekeningen te plunderen, gegevens van bedrijven, instellingen en particulieren te verkrijgen. De kennis en de gebruikte inbraak-technologie van de hackers worden steeds slimmer.

    In de eerste week van augustus 2014 werd bekend dat een buitenlandse hackers-groep de grootste verzameling internetgegevens ooit heeft gehackt namelijk 1.2 miljard namen, inloggegevens en e-mailadressen.

    De onbekende digitale tegenstanders zijn gecommitteerd om hun acties te richten op organisaties waar ze waardevolle data kunnen stelen, dienstverlening kunnen ontregelen en toegang kunnen verkrijgen voor misbruik, zowel nu als wel in de toekomst.

    Ook bestaat er een techniek (FF-programma) waardoor computers kunnen worden geïnfecteerd om op afstand bestanden te kopiëren, screenshots te maken en om toetsaanslagen te registreren.

    Uit een nieuw rapport van een Amerikaanse beveiligingsbedrijf en de Amerikaanse denktank Center for Strategic and International Studies is berekend dat cybercrime de wereldeconomie jaarlijks zeker 325 miljard euro kost. De afdeling operaties van het European Cybercrime Center (EC3) laat via haar afdelingshoofd weten dat bedrijven bang zijn voor reputatieschade en laten daarom vaak nog niet weten als ze doelwit zijn geweest van cyberaanvallen.

    De Nederlandse rechtsstaat heeft een groot probleem. Er zijn 2 miljard mensen die internet gebruiken. De achterdeuren zijn onvoldoende beveiligd. Hoe hebben de Nederlandse Rechtbanken en Gerechtshoven, Raad van State en Hoge Raad hun achterdeuren vergrendeld?

    Aan de betrouwbaarheid en vertrouwelijkheid van het elektronisch verzenden van verzoeken en mededelingen met betrekking tot de rolberichten worden weliswaar eisen gesteld doch ook het door rechtbanken en gerechtshoven daarvoor gebruikte systemen dienen niet alleen in staat te zijn om de verzenders van berichten te identificeren doch ook te controleren of de bij de griffie binnenkomen berichten authentiek zijn doch ook afkomstig van de verzenders.

    EMLS verwacht dat datalekken zich ondanks ict-protocollen en toegepaste beveiligingsmaatregelen zich zullen blijven voordoen ondanks de NEN-ISO Code voor Informatiebeveiliging

    Zie ook: http://www.bijzonderstrafrecht.nl/2014/kamerbrief-over-de-aanpak-van-botnets/#sthash.IwIytBhB.dpbs

    EMLS opent de discussie en geeft als voorzet : Digitaal procederen, bankieren en transacties plegen stop er mee want je weet niet nooit zeker wie er echt aan de knoppen draait.

  12. Nog afgezien van de discussie omtrent RFCs, die denk ik niet rechtstreeks van toepassing zijn geldt natuurlijk dat het niet heel gebruikelijk is dat een blauwe hyperlink dingen veranderd. Maar soms wel: bevestigen van account aanmaken. Dat maakt het juist een lastig geval.

    Ik zou zelf echter zeggen dat het juist wel kan gebeuren dat je per ongeluk op een link klikt. Ten eerste heb ik zelf de rare gewoonte om telkens tekst te selecteren met de muis, terwijl ik dingen lees. Dan ben ik dus redelijk onnadenkend aan het klikken rond lopende tekst, en kan best per ongeluk een link volgen in plaats van een nieuwe selectie te slepen. Ten tweede moet je op mobiele telefoons en tablets natuurlijk met je dikke worstvingers wel aan het scherm slepen om te scrollen. Ook daarbij is het niet onmogelijk per ongeluk een link te openen.

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