VTech wil dat gebruikers erkennen dat gegevens bij zijn dienst onveilig zijn

verbodIn de categorie ergernissen waar je ’s ochtends van gaat bloggen: VTech, de maker van elektronisch speelgoed, heeft in zijn algemene voorwaarden opgenomen dat gebruikers erkennen dat informatie die ze via de Learning Lodge-portaal sturen onderschept kan worden. Dat las ik bij Tweakers gisteren. Om scheve jeuk van te krijgen. Ja, het is een standaardzin die ongetwijfeld bij meer bedrijven voorkomt en nee het heeft nul waarde. Maar waarom laten we bedrijven er steeds mee wegkomen?

VTech maakt onder meer elektronisch speelgoed en kwam negatief in het nieuws toen gegevens van meer dan 11 miljoen mensen, waaronder 6,4 miljoen kinderen, lekten door brakke beveiliging van het bedrijf. En wat doe je dan als bedrijf? “These Terms and Conditions have been updated as of December 24, 2015” op je site zeggen met dus

YOU ACKNOWLEDGE AND AGREE THAT ANY INFORMATION YOU SEND OR RECEIVE DURING YOUR USE OF THE SITE MAY NOT BE SECURE AND MAY BE INTERCEPTED OR LATER ACQUIRED BY UNAUTHORIZED PARTIES. YOU ACKNOWLEDGE AND AGREE THAT YOUR USE OF THE SITE AND ANY SOFTWARE OR FIRMWARE DOWNLOADED THEREFROM IS AT YOUR OWN RISK.

Ja, in hoofdletters ook nog. Nee, dat hoeft niet (het is geen exoneratie immers). En leuk en aardig om dat zo te moeten acknowledgen, maar dat heeft dus geen waarde. Privacybescherming verandert geen millimeter door welke disclaimer of andere zin in algemene voorwaarden. Zeker waar het gaat om beveiliging niet: het is gewoon niet toegestaan je beveiligingsplicht tot nul te reduceren. Zelfs niet als de consument expliciet zegt, doe het maar een kilootje minder met je security.

Maar waar ik dan dus écht jeuk van krijg, is de obligate vervolgzin:

Some jurisdictions do not allow the exclusion of certain warranties or the limitation or exclusion of liability for incidental or consequential damages. Accordingly, some of the above limitations may not apply to you.

Het zou écht verboden moeten worden om naar consumenten toe iets van deze strekking te mogen zeggen. Wat er staat: wij zijn niet aansprakelijk, tenzij de wet zegt van wel. Maar iedereen weet dat consumenten weinig begrip van de wet hebben. Daarom vereisen we heldere, duidelijke en complete informatie van verkopers – en wat mij betreft vallen daar de algemene voorwaarden ook onder. Ik vind dus dat je gewoon enkel en alleen positief geformuleerde dingen mag zeggen over je aansprakelijkheid, en dat “may not apply” of “dit doet geen afbreuk aan uw wettelijke rechten” op een zwarte lijst moeten komen. Ga als bedrijf maar gewoon uitzoeken wat de rechten zijn van je consument-klanten en schrijf dat op, het is schandalig dat je dat werk bij je klant legt.

Dus nee. Onzinnig, inhoudsloos en de betreffende jurist mag zich gaan schamen. Maar de eerstvolgende keer dat er iets misgaat bij VTech, weet je al wat de persvoorlichter gaat zeggen en ik heb géén idee hoe het bedrijf te bewegen dit aan te passen. Ergerlijk. En ja, ik ga nu mijn ochtendkoffie halen.

Arnoud

24 reacties

  1. (…) het is gewoon niet toegestaan je beveiligingsplicht tot nul te reduceren.
    En wat mij betreft zou het ook verboden mogen zijn dit te proberen. Zijn de algemene voorwaarden in strijd met de wet? Boete, en ga maar aanpassen op straffe van een dwangsom.

    En nu zijn het in dit geval nog algemene voorwaarden in het Engels. Maar vaak genoeg worden de Engelse algemene voorwaarden naar de Nederlandse taal vertaald, zonder ze te vertalen naar het Nederlands recht; dat vind ik ook altijd tenenkrommend. Ik snap heus wel dat Nederland niet het enige land is waar Nederlands gesproken wordt, en dat het kan dat als een Nederlander in Engeland iets koopt het Nederlands recht niet van toepassing is, maar daar moet toch een nettere en vooral betere oplossing voor te verzinnen zijn.

  2. … ik heb géén idee hoe het bedrijf te bewegen dit aan te passen.

    Andere consumenten overigens wel. Er wordt al opgeroepen om VTech volledig te boycotten. En als niemand meer je product koopt dan zit je flink in de problemen. Zeker als je daarnaast nog forse boetes en chades mag gaan betalen voor de datalekken. Op Facebook is er al een groep hiervoor.

    Aan de andere kant, dit valt natuurlijk allemaal onder het Internet-Of-Things en bij IoT zie je wel heel veel producten die eigenlijk gewoon hun data lekken naar de buitenwereld. Immers, de producten moeten zo goedkoop mogelijk worden en beveiliging kost geld zonder dat de gebruiker er de voordelen van merkt. (Wel de nadelen wegens het instellen van wachtwoorden, accounts en meer.)

    1. Ja, die 14 gebruikers die de facebookpagina ‘boycot vtech’ liken daar gaat men echt wakker van liggen. En leg maar eens aan je kind in de Intertoys uit dat hij dit apparaat niet mag kopen van zijn verjaardagsgeld omdat de fabrikant niet nietjes met de privacy omgaat 😉

      1. En leg maar eens aan je kind in de Intertoys uit dat hij dit apparaat niet mag kopen van zijn verjaardagsgeld omdat de fabrikant niet nietjes met de privacy omgaat.
        Dat ben ik best bereid uit te leggen. Dat is opvoeding. Mijn kinderen mogen ook niet bij elke website die ze tegenkomen een account aanmaken. Als ze een video op YouTube willen plaatsen, gelden daar ook beperkingen voor.

      2. Mee eens. Met 14 volgelingen is die groep niet echt heftig te noemen. Maar het is wel een begin. Het was sowieso de eerste facebook pagina die ik via Google vond. De oproep vanuit de beveiligers is een meer recente oproep, die eigenlijk pas deze maand naar voren kwam. Die Facebook groep zal mogelijk dus gaan groeien. Op Reddit is ook al het een en ander verschenen in de afgelopen 24 uur. Ook nu.nl gaf aandacht aan deze boycot, hoewel deze waarschijnlijk tussen de overige nieuwsberichten verdwijnt. Toch, als er genoeg media-aandacht gaat komen op de ontwikkelingen van de afgelopen 48 uur dan kan het nog een lang staartje krijgen voor VTech.

        En hoe ouders dit aan hun kinderen mogen uitleggen? Dat hangt mede af van de winkeliers, die mogelijk merken dat ze geen klanten krijgen zolang ze VTech-spullen verkopen. Als ouder ga je dan namelijk juist dergelijke winkels boycotten, niet alleen het product.

        Ik vraag mij zelfs af of Nederlandse winkeliers verantwoordelijk gehouden kunnen worden voor deze datalekken in plaats van de fabrikant zelf. Immers, de winkeliers zijn diegenen die het product verkopen en dus onveilige producten aan consumenten leveren. VTech zal zich misschien niet druk maken om de boete op datalekken maar de Bart Smit om de hoek heeft het geld er niet voor! En het is de winkel die het product levert, niet de fabrikant.

    2. Met de recente waarschuwing van James Clapper dat IoT door geheime diensten gebruikt gaat worden om te spioneren (wat door reageerders op het arstechnica artikel soms wordt vertaald tot: “we doen dit al”) heb ik toch de stille hoop dat er iets van bewustwording op gaat treden.

      Je mag me er echter gerust om uitlachen: ik ben inderdaad soms wel een ongeneeslijke naïeve optimist.

  3. Even advocaat van de duivel spelen:

    Die “may not apply in all jurisdictions” voorwaarde is praktisch gezien toch gewoon noodzakelijk? Het enige alternatief is dat je je als fabrikant moet gaan verdiepen in de verschillen in wetgeving tussen alle landen waar je verkoopt. Als er dan ergens een kleine jurisdictie is (Nederland) waarin men zich ook nog eens druk maakt om zo’n “may not apply” voorwaarde, dan loont het al snel niet meer om je producten op die markt te verkopen. Daarbij: de gemiddelde consument leest de voorwaarden überhaupt niet; als je toch de moeite neemt om het te lezen, dan ben je blijkbaar geïnteresseerd in dit soort zaken, en dan zou je ook wel uit kunnen zoeken wat de Nederlandse wet er over zegt.

    En wat is er nu precies mis gegaan bij VTech? Dat data unencrypted werd verstuurd? Ik ben er voor dat dat wordt aangepakt, maar moeten we dan niet ook e-mail software gaan aanpakken, die geen geïntegreerde PGP heeft (bijna alle dus)? Of websites die geen HTTPS gebruiken? Daar zou blog.iusmentis.com ook onder vallen: bij het posten van comments hoef je weliswaar niet te verwachten dat je post privé blijft, maar mensen zouden wel eens anoniem willen posten / plusjes geven / blog-posts lezen, en HTTPS zou daar bij kunnen helpen.

    1. Nee, “may not apply” is een te makkelijk afschuiven van je verantwoordelijkheid. Jij wil verkopen in Nederland? Dan zorg jij maar voor een tekst die klopt met Nederlandse wetgeving. En misschien is het dan niet lonend voor jou, maar winkels in de EU gaan steeds vaker centraal inkopen dus dan ben je gelijk de hele EU kwijt als markt als je niet uitkijkt.

      1. Daar komt bij dat dit soort wetgeving zo goed als altijd gebaseerd is op geharmoniseerde Europese regelgeving. Zo moeilijk is het dus niet om dat kloppend te maken. Richtlijn 85/374/EEG is nou ook niet bepaald de nieuwste dus genoeg tijd gehad om te implementeren.

    2. Moderne email-providers passen al regelmatig encryptie toe dus PGP heb je daar niet voor nodig. Daar heb je dus TLS voor.

      En HTTPS toepassen op alle websites? Ik zou wel willen maar ik weet hoe lastig dit kan zijn. Zeker als je meerdere domeinen vanaf een enkele server wilt hosten, via IIS. Plus, certificaten kunnen geld kosten. Bovendien ook lastig voor ontwikkelaars wegens extra complexiteit, vooral bij web services. En dat terwijl deze beveiliging geen garanties biedt dat het echt veilig is. Zeker als niemand het slotje ook daadwerkelijk nakijkt! Een Man-in-the-Middle aanval is best populair en veel overheden kunnen een dergelijke truuk uithalen zonder dat je dit al te makkelijk opmerkt!

      Tja, om dit blog nou veilig te noemen? Sowieso heb je geen specifieke accounts hier en kun je jezelf voordoen als iedereen. Ik kan dus een post plaatsen onder jouw naam! Je account is namelijk niet beschermd met enig wachtwoord. En als ik je email adres weet dan kan zelfs Arnoud vrijwel niet meer bepalen of jij het bent of dat ik de boel zit te neppen. (En ik kan jou waarschijnlijk uitschrijven van al je inschrijvingen op de diverse posts hier!) Kortom, voor een ICT-jurist is dit blog wel erg “onveilig”. 🙂

        1. Ik weet het. Desondanks krijg je het onder IIS nooit goed werkende indien je meerdere domeinnamen wilt hosten vanaf 1 PC. Bij Microsoft leggen ze uit waarom deze problemen er zijn. Maar goed, een wildcard certificaat kan mooi gebruikt worden voor een enkel domein, maar ik heb watb.nl en wimtenbrink.nl als domeinnamen en om beiden te beveiligen heb ik meerdere IP adressen nodig! Da’s irritant. Dan heb je een SAN Certificaat nodig. Die zijn helaas niet gratis en ik wil weer niet teveel uitgeven aan een domein die ik alleen voor test-doeleinden gebruik en voor eigen vermaak. Het grootste probleem is daarnaast dat het van beheerders en ontwikkelaars wel enige kennis en ervaring vraagt, terwijl het in de meeste gevallen gewoon een simpel, eenmalig klusje betreft zodat er weinig oefening mogelijk is. De installatie mag dan eenvoudig gaan, maar als er problemen ontstaan die opgelost moeten worden dan is dat voor veel beheerders en ontwikkelaars knap lastig om uit te zoeken!

          1. Goeie reden om alleen Unix en Apache te gebruiken. Maar of het daar handig mee kan, weet ik niet, zelf heb ik geen certificaat, vind ik ooit niet nodig met vrijwel alleen ophalend verkeer.

            Microsoft en Internet zijn nooit vrienden geweest. MSN betekent MicroSoft Network, ooit bedoeld als initiatief NAAST internet, met het idee het weg te vagen. Goddank mislukt.

              1. Dat is niet volledig juist, Apache kan SNI gebruiken waarmee het wel mogelijk is om meerdere SSL certificaten per IP te gebruiken. Voorwaarde is wel dat de client dit ook ondersteund, maar zoals in het geciteerde artikel te zien is kan elke moderne client dit aan. Het lijkt dan dus een IIS-specifiek probleem. (Apache draait overigens ook prima op Windows.)

                Off-topic: of de tools onvriendelijker zijn of niet blijft een persoonlijke keuze, ik ben van mening dat het configureren van Apache op Linux eenvoudiger is dat IIS op Windows. Maar dat is natuurlijk ook een kwestie van ervaring en text-based vs. grafische user interfaces.

                1. SNI wordt ook door IIS ondersteund dus dat is het probleem niet. Het probleem zijn meer de kosten ervan die het voor veel hobby-hosters eigenlijk te duur maakt. Daarnaast is de installatie ervan best wel lastig als het niet meteen goed gaat. Eigenlijk is het een probleem met het TLS protocol, dat eerst om een certificaat vraagt voordat het de gewenste domeinnaam doorgeeft. Een virtuele host heeft echter die naam nodig om te weten welk certificaat er nodig is. SNI is een aanpassing op het TLS protocol die tegenwoordig door de meeste partijen wel is toegepast. Maar het is voor beheerders en ontwikkelaars wel weer extra techniek die ze moeten leren, en dat is het grootste probleem! Want de reden dat veel sites onveilig zijn komt door een gebrek aan kennis en ervaring bij de beheerders en ontwikkelaars! En dat komt omdat het opzetten van een site geen alledaagse bezigheid is. Er zijn er maar weinigen die dagelijks een nieuwe website moeten neerzetten, inclusief beveiliging. En als een site eenmaal werkt dan kan het weken, maanden duren voor men weer iets aan de beveiliging moet aanpassen.

                  Off-topic: het voordeel van een grafische interface blijkt pas zodra deze extra informatie gaat weergeven over wat het doel van bepaalde opties precies is. Plus, het geven van een totaal-overzicht van alle functionaliteit. Domeinen en websites opzetten is voor de meeste gebruikers geen alledaagse bezigheid en dus zullen velen weinig moeite willen doen om de textuele interface te gebruiken met een handleiding ernaast…

      1. Moderne email-providers passen al regelmatig encryptie toe dus PGP heb je daar niet voor nodig. Daar heb je dus TLS voor.
        Die passen encryptie toe op transport (tussen systemen), niet op de opslag. Dus ook al heb je transport-encryptie, dan nog kan je e-mai op alle tussenstations gelezen worden.

        PGP lost dat probleem op door de inhoud van de e-mail te versleutelen zodat alleen verzender en ontvangen ‘m kunnen lezen. Voor zover ik weet doen e-mail providers dat niet. Apple, Microsoft en Google in ieder geval niet.

        1. Je bedoelt, de opslag van de emails op de mailserver? Want het verkeer van de server naar jouw mailreader is beveiligd. En van je mailreader naar je provider is ook beveiligd. (Nou ja, als TLS is aangezet!) Het enige wat mis kan gaan is als jouw mailserver communiceert met een onbeveiligde mailserver maar anders is ook die verbinding gewoon veilig. Blijft dus alleen de opslag van je email over en ik ga er van uit dat providers ook dit beveiligen. (Google in ieder geval!) Alleen je eigen mailreader mogelijk niet. (Of gebruik webmail en je hebt dat probleem niet!) PGP versleutelt bovendien alleen de inhoud van de email, niet de headers. Maar de ontvanger moet wel de bijbehorende sleutel hebben om deze te kunnen lezen, anders heb je er niets aan. En dat gebeurt via de publieke sleutel, die in principe iedereen kan opvragen. Dus kan iedereen alsnog je email lezen! Overigens levert de versleuteling van PGP soms ook problemen op. Bij het gebruik van mailinglijsten maar ook met sommige mail providers wordt de email soms iets aangepast of worden er regels commentaar aan toegevoegd. Een disclaimer of een opmerking van “deze email is gecontroleerd door ACME Virusscanner en 100% veilig gevonden” kan dan ervoor zorgen dat de encryptie verward raakt en de email dus onleesbaar wordt of als onbetrouwbaar wordt aangemerkt. Dit probleem ben ik onder andere tegengekomen bij het plaatsen van een digitale handtekening bij mijn emails, die vervolgens lang niet altijd goed aan kwamen. (En dan die grapjas die dacht mijn emails te kunnen vervalsen door het certificaat te kopieren/plakken bij een nepmail en vervolgens een nieuwe internet provider mocht gaan zoeken…)

          1. Maar de ontvanger moet wel de bijbehorende sleutel hebben om deze te kunnen lezen, anders heb je er niets aan. En dat gebeurt via de publieke sleutel, die in principe iedereen kan opvragen. Dus kan iedereen alsnog je email lezen!

            Huh? Ik begrijp een boel van de door jou genoemde kritiekpunten op PGP, maar deze klopt volgens mij niet. Bij PGP heb je een publieke en een private sleutel; de publieke deel je met iedereen, en de private houd je voor jezelf. Encrypten (en controleren van handtekeningen) kan met de publieke sleutel; dat kan iedereen dus. Decrypten (en maken van handtekening) kan alleen met de private sleutel, dus dat kan je alleen zelf.

            In jouw tekst klopt de zinsnede “en dat gebeurt via de publieke sleutel” dus niet: voor het lezen heb je juist de private sleutel nodig. Je conclusie dat iedereen alsnog je email kan lezen klopt dus ook niet.

            Het klinkt misschien een beetje raar dat je met de publieke sleutel wel kunt encrypten, maar niet kunt decrypten, maar dat is de essentie van asymmetrische encryptie (zoals gebruikt door PGP).

            1. PGP werkt als volgt: je hebt een publieke en prive-sleutel. De publieke sleutel is in principe dus bij iedereen bekend. Dat betekent dat als jij met je prive-sleutel een email ondertekent, iedereen deze via de sleutel gewoon kan lezen. Ofwel, erg veilig is het niet. Het enige wat iedereen weet is dat jij de afzender ervan bent want dat is wat de sleutel doet: bevestigen dat jij de afzender bent.

              Het is dan ook meer bedoeld voor voor anderen die jou een bericht willen sturen. Ze versleutelen deze dan met jouw publieke sleutel en jij bent dan de enige die de email kan lezen. En dat is dus relatief veilig. Alleen, als je met 200 mensen regelmatig berichten uitwisselt dan moet je dus 200 publieke sleutels in je systeem hebben, voor iedere ontvanger eentje. En als je een bericht naar meerdere personen wilt versturen dan moet het bericht meerdere keren worden verstuurd, iedere keer weer met een andere versleuteling.

              Kortom, met PGP kun je niet veilig verzenden zonder gebruik te maken van andermans publieke sleutel! Gebruik je je eigen publieke sleutel dan kan niemand, behalve jijzelf, deze lezen. Dus gebruik je je prive-sleutel en dan kan iedereen hem lezen met je publieke sleutel.

              En zoals gezegd moet je mail-app dus voor iedere ontvanger de PGP publieke sleutel ophalen en voor iedere ontvanger dus apart encrypten met de publieke sleutel van de ontvanger. Leuk als je een mailinglijst beheert met 500 erg aktieve leden…

              Maar goed, hier zijn vaker misverstanden over…

              Vis TSL/SLL gaat het overigens wel goed. Je mail-app vraagt dan een publieke sleutel van je provider en gebruikt deze vervolgens om het bericht door te sturen. Je provider zoekt vervolgens contact met de providers van de geaddresseerden en probeert ook hier weer een beveiligde verbinding te maken door per provider de publieke sleutel op te vragen en vervolgens de mail beveiligd door te sturen. Ten slotte maakt de ontvanger contact met zijn provider, vraagt een publieke sleutel op en de emails kunnen dan ontvangen worden.

              Dat laatste traject is door gebruik van de publieke sleutel o te decrypten dus wel af te luisteren door anderen, die de sleutel ook al bezitten. Maar voor het opvragen van die sleutel moet je wel eerst inloggen bij je ail provider. Niet iedereen heeft dus toegang.

              Maar het kan ook anders Je mail-app kan een publieke sleutel sturen naar de mailprovider die vervolgens wordt gebruikt om de mail mee te encrypten. Om het te lezen heb je dan de prive-sleutel nodig en die heb je alleen zelf Dan is het opnieuw veilig.

    3. En wat is er nu precies mis gegaan bij VTech? Dat data unencrypted werd verstuurd?

      Nou, nee, zeker niet alleen dat. SQL injection, MD5 zonder salt, geen TLS waar dan ook, gedateerde software, en dan deze nog:

      One of these is getKids and all it needs is the ID of the parent. No authentication token, no authorisation that the user can actually access the kid’s details, nothing more than a sequentially incrementing number. There’s also getParent which does exactly the same thing so the bottom line is that you don’t even need a data breach because as it stands today, you can simply enumerate the API. As an attacker, I can request the details on every single parent and get name, email and post code then take that parent ID and get every single child they’ve registered.

      Dit is dus gewoon nalatigheid – dit zijn problemen waar we al ruim 10 jaar een oplossing voor hebben, en er is geen enkel geldig excuus voor. Hier meer.

  4. Als VTech in hun algemene voorwaarden verklaart zich niet aan de Nederlandse privacywetgeving te houden, mag je dan als winkelier überhaupt wel spullen van VTech aanbieden? Het lijkt me dat de producten in ieder geval niet-conform zijn, want je kan ze niet volledig gebruiken zonder je privacy op te geven.

    1. Of, interessanter: kunnen de winkels die VTech-spul verkochten opdraaien voor de boetes van het datalekken? Immers, de winkelier is het aanspreekpunt betreffende garanties en fabrikage-fouten, niet de fabrikant. Verkopen zou wel mogen maar als de winkeliers dan kunnen opdraaien voor deze boete dan denk ik niet dat ze het nog zullen verkopen…

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.