Gebruikers van Hue-lampen worden in de toekomst verplicht een account aan te maken, meldde Tweakers onlangs. "Hue-accounts zijn gemaakt om de beveiliging van je systeem te verbeteren. Binnenkort moet je ingelogd zijn" werd bij de laatste update gemeld. Frustrerend, Hue stond bekend als een van de grootste partijen die lokale aansturing van domotica mogelijk maakte, maar het is niet de eerste keer dat een software-update een apparaat wezenlijk anders laat werken. Dus vandaag de vraag: mag dat allemaal zomaar?
Redelijkerwijs gewekte verwachtingen
Vroeger was de maatschappij lekker overzichtelijk; een product is een ding en dat zit in een doos en dat koop je. Was er iets mis mee, dan had je mogelijk recht op garantie en dankzij Europa vanaf 1999 ook recht op conformiteit, oftewel wettelijke garantie; het product moet aan de redelijkerwijs gewekte verwachtingen voldoen. Daarnaast had je dienstverlening. Inhoudelijk is daar minder voor geregeld, maar over de randzaken genoeg: stilzwijgende verlenging, opzegging, zorgplicht en zo nog een en ander. Het verschil tussen producten en diensten sprak eigenlijk vanzelf.
Sinds de jaren tachtig is er een markt voor software. Software zag eruit als een product: er zat een ding in een doos en als je dat in je computer stak, ging het leuke dingen doen. Soms werkte dat niet helemaal en dan kwam er hopelijk een update of je zocht een workaround of alternatief. De kleine lettertjes waren daarbij vrij duidelijk; de software wordt geleverd 'as-is without warranty of any kind including but not limited to fitness for any particular purpose'. Ook dit ging soort van vanzelf goed; softwarekopers wisten wat ze konden verwachten, updates kwamen er (meestal) en bugs werden opgelost (meestal).
Van hard naar soft
Software verscheen ook steeds vaker in producten. Het aanpassen van firmware is immers een stuk eenvoudiger voor een fabrikant dan het herzien van een hardwareontwerp, dus je bent een stuk sneller met een nieuwe editie van je product. Die regels over conformiteit gingen nog steeds vanzelf goed, want of iets nou door software komt of door hardware, maakt niet uit bij de beoordeling of het product aan de verwachtingen voldoet.
Dit veranderde langzaam maar zeker. Producten konden 'in het veld' updates krijgen, wat lange tijd met name voor de professionele markt van belang was (nieuwe firmware), maar zich uitbreidde naar de consumentenmarkt. Toen apparaten aan internet konden, zoals bij patient zero, de LG Internet Digital DIOS, kreeg dat een geheel eigen dynamiek. Dat had dan weer te maken met de opkomst van het grote datagraaien; 'data is the new oil', heet dat bij productmanagers. Je wilt zoveel mogelijk weten over je klanten, die dan ineens gebruikers heten. Om die gegevens te verzamelen, moet je ze ergens aan koppelen en dan is een gebruikersaccount de makkelijkste plek.
Zo'n apparaat-met-account is op zich een ding dat in een doos zit. Het is óók een stuk software, want in overwegende mate komt de functionaliteit van het ding door de software die er is ingebed. Veel van de dingen die het ding vervolgens doet, zijn juridisch aan te merken als dienstverlening. Dat past dus niet meer zo mooi in dat wettelijke systeem van producten enerzijds en diensten anderzijds. En als dingen niet goed passen, dan gaat het rammelen.
De eisen aan verwachtingen
Laten we desondanks eens kijken hoever we komen met een juridische analyse. We hebben dus een aantal apparaten gekocht en door een software-update is de werking daarvan nu anders. Het apparaat kan niet meer direct lampen aansturen of als lamp zijnde aangestuurd worden; nu is een account vereist. 'Hij doet het niet meer zoals eerst' is dan de klacht en dan kom je in het consumentenrecht als eerste bij die conformiteitseis uit: 'De afgeleverde zaak moet aan de overeenkomst beantwoorden.'
Wanneer is dat zo? Als de zaak 'de eigenschappen bezit die de koper op grond van de overeenkomst mocht verwachten' (art. 7:17 BW). Dit wordt nader uitgewerkt in 7:18 BW. De zaak moet met name:
-
wat de beschrijving, het type, de hoeveelheid en kwaliteit, functionaliteit, compatibiliteit, interoperabiliteit en andere kenmerken betreft, voldoen aan de overeenkomst;
-
geschikt zijn voor elk bijzonder door de koper gewenst gebruik dat de koper aan de verkoper uiterlijk bij het sluiten van de overeenkomst heeft meegedeeld en dat de verkoper heeft aanvaard;
-
geschikt zijn voor de doeleinden waarvoor zaken van hetzelfde type gewoonlijk worden gebruikt, indien van toepassing rekening houdend met technische normen of bij ontstentenis van deze normen de sectorspecifieke gedragscodes;
-
de hoeveelheid hebben en de kenmerken bezitten, onder meer met betrekking tot duurzaamheid, functionaliteit, compatibiliteit en beveiliging, die voor hetzelfde type zaken normaal zijn en die de koper redelijkerwijs mag verwachten;
-
van updates worden voorzien, als bepaald in de overeenkomst.
Wie nu opmerkt dat er wel heel vaak synoniemen voor 'gewoon' of 'redelijk' staan hier, heeft helemaal gelijk; dit zijn open normen, bedoeld om de discussie langs bepaalde lijnen te voeren en niet om harde criteria neer te zetten waaraan getoetst kan worden. Wel valt op dat ze allemaal uitgaan van de situatie bij verkoop, behalve die laatste. De overeenkomst moet vastleggen of en wanneer er updates komen, en dan is de zaak non-conform als die niet komen zoals afgesproken.
De redelijkheid van wijzigingen
Is er vanaf de dag van verkoop een account verbonden aan het gebruik van het product, dan is dat op zichzelf dus prima. Het moet wel gemeld worden, want dat staat dan weer in artikel 6:230l BW; de verkoper is verplicht om vooraf alle relevante aspecten te melden van 'de functionaliteit van een zaak met digitale elementen, digitale inhoud of een digitale dienst, met inbegrip van toepasselijke technische beveiligingsvoorzieningen'. Een account is een 'digitale dienst' en valt hier dus weer onder.
Een account dat achteraf wordt toegevoegd, is juridisch wat ingewikkelder, want daar voorziet de wet dus niet in. Althans, niet direct. Het kan wel, maar dan moet eerst de overeenkomst worden gewijzigd: "Vanaf heden is een account verplicht." Dan meld je dat conform je informatieplicht en dan zitten de verwachtingen weer goed. Alleen, dat mag niet zomaar. Afspraak is afspraak en afspraken moeten worden nagekomen, niet gewijzigd.
De algemene voorwaarden vermelden natuurlijk ergens iets als: 'These terms are subject to change at any time. Your continued use constitutes express acceptance'. Maar daarmee is zo'n bedrijf er nog niet, want algemene voorwaarden moeten binnen de wet blijven. Specifiek voor algemene voorwaarden staan er lijsten in artikel 6:236 en 6:237 BW. Zaken die op die eerste lijst (de zwarte) staan, zijn simpelweg niet toegestaan; de tweede lijst (de grijze) bevat 'vermoedelijk' verboden zaken, maar de ondernemer kan nog wel met tegenargumenten proberen te laten zien dat er niets onredelijks aan is.
Een algemeen wijzigingsbeding is verboden bij wet.
Zo'n algemeen wijzigingsbeding is verboden. Letterlijk het eerste item op de zwarte lijst betreft voorwaarden die 'geheel en onvoorwaardelijk het recht ontnemen de toegezegde prestatie op te eisen'. Met dat generieke beding kun je elke eerdere toezegging ongeldig verklaren en of je dat nou doet of niet, omdat het ermee kan, is het beding verboden.
Een specifiek wijzigingsbeding? De Hue-voorwaarden vermelden: 'We are always trying to improve the Services and the Products, so they may change over time. We may update the Services by providing (bug) fixes or modifications, introduce new features or functionality, change or discontinue (temporary or permanently) any feature or functionality, component or content, impose limits on certain features or restrict access to parts or all of the Services.' Dit is niet direct verboden op grond van die zwarte lijst. Op de grijze lijst staat wel een opmerking over een voorwaarde die 'de bevoegdheid verleent een prestatie te verschaffen die wezenlijk van de toegezegde prestatie afwijkt', maar daarvan kan de ondernemer dus alsnog betogen dat het in zijn geval wél moet kunnen. Dat is waar die tekst die ik net heb aangehaald, over gaat. Het doorvoeren van verbeteringen en het corrigeren van fouten is een op zich redelijk argument waarom je de prestatie mag aanpassen.
De redelijkheid van een account
Discutabeler wordt het als de oude voorwaarden, uit augustus 2021, expliciet iets vermelden over accounts: "The Services may require that you have a user account in order to use the Services." Dan weet je dus in het algemeen dat er een account kan komen, hoewel niet wanneer en voor welke delen precies. Als men dan met een verhaal komt waarom een useraccount nu toegevoegd wordt vanuit de behoefte tot beveiliging en kwaliteitsverbetering, dan zit je vanuit juridisch perspectief wel een heel eind goed.
Natuurlijk, er is genoeg in te brengen tegen het verplichten van een account. Het enkele feit dat je nu op afstand ergens bij kunt waar je voorheen fysiek op de locatie moest zijn, maakt dat de dienst aantrekkelijker is voor een aanvaller. En dan kan een ander je huis bedienen, je videostreams afnemen of je auto van het slot doen. Ook introduceert het een extra laag complexiteit in de software, want die moet nu steeds controleren of de gevraagde handeling wel geautoriseerd is en dergelijke.
Het punt is alleen: de afweging is niet of een account echt significant veilig of verstandig is. Het juridisch criterium is of het redelijk is dat een bedrijf die keuze maakt. En 'redelijk' is een veel lagere lat dan 'het moet wel echt veilig gebeuren'. De rechter zal kijken naar de redenen en de afweging die een bedrijf daarbij maakt. En omdat ondernemen nu eenmaal een grondrecht is, is dat meer een sanity check dan een inhoudelijk meedenken. Als het geen totale onzin is, is het iets wat een bedrijf mag beslissen.
Veiligheid als argument
Is veiligheid dan helemaal geen argument? Ja en nee. Er zijn genoeg wetten die beveiligingseisen opleggen. De AVG natuurlijk (bij persoonsgegevens), de NIS2-regels bij vitale bedrijven en technologie (zoals routers), over een aantal maanden de Cyber Resilience Act voor alle producenten voor internet-of-things (zoals slimme lampen) en zo kan ik nog wel even doorgaan. Alleen: allemaal hanteren die een open norm waar je als bedrijf dan aan moet toetsen. Bij de CRA dromen ze van certificering door een onafhankelijke instantie, alleen is nog niet duidelijk wat de normen moeten zijn en hoe dat allemaal moet gebeuren zonder vijf jaar te moeten wachten voordat je update goedgekeurd is.
Veiligheid is wel en niet een argument.
In alle gevallen komt het erop neer dat een bedrijf keuzes moet maken om de securityeisen in te vullen en dan zijn best moet doen om dit goed uit te voeren. Specifieke resultaten worden niet geëist. Ergens terecht, je kunt ook moeilijk eisen dat een update drie maanden lang geen exploits mag opleveren of iets dergelijks. Het zijn echter de consequenties die altijd wat zwak zijn. Gaat het mis, dan ben je aansprakelijk voor niet-kwantificeerbare gevolgen en moet je een nieuwe update maken, en dat is het wel zo ongeveer. Dat is dus weinig incentive voor een bedrijf om écht in te zetten op security, maar het betekent ook: security is een zwak argument om te betogen dat een bedrijf niet mag doen wat het goeddunkt met zijn productlijn. Het is vanuit het perspectief van de rechter een keuze die een bedrijf mag maken, waarbij het rekening moet houden met zekere minimumeisen en randvoorwaarden.
Een ander argument is gebruikersgemak. Ik rekende erop dat ik mijn Hue-systeem zou kunnen gebruiken zonder account. Dat is dus niet heel sterk, omdat in de voorwaarden stond dat dit kan veranderen. Dan kan het je nog steeds overvallen, maar je kunt moeilijk stellen dat je mocht rekenen op levenslang accountloos het licht uit te doen. Helaas blijft onder de wet dan niets anders over dan je apparaten de deur uit te doen.