Gebruik van mijn browser betekent akkoord met mijn gebruiksvoorwaarden, een idee van David Rosenthal, digitaal conservator uit Amerika. Hij vroeg zich af waarom al die sites wegkomen met “Gebruik van onze site betekent akkoord met onze voorwaarden” en of dat niet om te keren was. Dan stel jij voorwaarden aan gebruik van je browser, en dat is niet gek als je bedenkt dat die bedrijven echt dingen dóen met je browser in plaats van alleen passief een tekst en een plaatje op te sturen.
In de kern geen gek argument. Als bezoek van een website akkoord impliceert met voorwaarden waaraan alleen in lichtgrijze tekst onderaan wordt gerefereerd, dan zou je dat ook om kunnen keren. Bijvoorbeeld door in het HTTP verzoek een header op te nemen (“License:”) met een link naar jouw voorwaarden. Ja, dat is nauwelijks opvallend en op een gekke plek, maar niet minder gek dan zo’n lichtgrijze zin. En als de een bindend is, waarom de ander dan niet?
Als eigenaar van een computer heb je zeggenschap over wat daarop gebeurt. Dat weten we in Nederland uit het XS4All/Ab.Fab arrest: de intenetprovider mocht reclame weren van het directmailbedrijf op grond van haar eigendomsrecht op de mailservers. Als dat voor een bedrijf geldt, dan ook voor mij als consument. Eigendom is eigendom. En zeker als je de cookiewet erbij haalt – er mag niets op mijn pc komen zonder mijn toestemming, en waarom zou ik daar geen voorwaarden aan kunnen verbinden?
Persoonlijk geloof ik niet dat browsewraplicenties (want dat zijn dit) rechtsgeldig zijn, precies vanwege dit soort dingen die dan mogelijk worden. Het kan niet waar zijn dat het ophangen van een bordje of het neerzetten van voorwaarden an sich leidt tot gebondenheid daaraan. Er moet iets zijn van een handeling waardoor je aangeeft ermee gebonden te zijn. Enkel een link is niet genoeg, ook niet met een toverformule die een willekeurige handeling tot akkoord verklaart. Door deze blog te lezen, zegt u toe namens uw werkgever drie jaar lang exclusief met ICTRecht zaken te zullen doen, en garandeert u bevoegd te zijn deze toezegging te doen. Giechel.
Maar stel dat je zegt, zoals die sites doen is het wél rechtsgeldig want het is nu eenmaal maatschappelijk aanvaard dat voorwaarden via lichtgrijze zinnen worden aangereikt. Ben je er dan met Rosenthals tegenargument? Dat betwijfel ik dan nog steeds. Hij stopt de tegenvoorwaarden op een wel érg rare plek, in de HTTP headers. En het is bepaald nog niet maatschappelijk aanvaard dat er voorwaarden in headers staan.
Arnoud
Waar dan wel, Arnoud?
Het is voor de websites zelf gebruikelijk om de tekst in de body te zetten, niet in de headers. Dus dan doen we het als volgt:
Dan stuurt de webserver mij een HTML document terug met de blogtekst erin, dus dan mag ik er vanuit gaan dat Arnoud akkoord is, gezien zijn webserverconfiguratie. Uiteraard zijn onredelijke voorwaarden ongeldig, zoals ze dat andersom ook zijn. Mochten de websitemakers een standaard willen omdat juridische tekst zo lastig te lezen is met software, stel ik voor dat ze zelf met een standaard komen en die toepassen. Misschien iets met HTTP headers?
Ach je weet al hoe die standaard er uit gaat zien toch?
Het is een sympathiek voorstel maar de reden dat we allemaal massaal akkoord gaan met de cookiemeldingen en website voorwaarden is omdat we graag die content willen. Iedereen zal dus weer snel z’n eigen voorwaarden weg halen en akkoord gaan met de voorwaarden van de websites….
Ik maak nog wel eens gebruik van TorBrowser, daar is al enige tijd iets soortgelijk gaande. Sites die gebruik maken van CloudFlare kunnen vaak niet bezocht worden via Tor, omdat CloudFlare Tor-IPs blacklist. Om daar omheen te werken heb ik nu een extensie toegevoegd waarmee ik met één druk op de knop de site kan opvragen via de WayBack Machine.
Op die manier kun je dit vraagstuk ook oplossen. Stuur een verzoek met voorwaarden, krijg je terug dat de website daar niet aan wil dan ga je wel via de WayBack Machine.
Dit lijkt me niet echt nuttig want waybackmachine maakt een snapshot zodra er een verandering van de website wordt gedetecteerd. Je hebt dan dus zeker een verouderde versie van de website.
Och, dat gold ook voor die eerste lichtgrijze tekst onderaan…
De lichtgrijze zin komt aan bij de persoon waar hij voor bedoeld is. De HTTP header komt niet aan bij de persoon waar hij voor bedoeld is. Het eerste kan niet worden afgeschoten op grond van art. 3:37 lid 3 BW en het laatste wel.
Hoe kun je aantonen dat verzonden HTML bij een persoon aankomt? Het is niet zo moeilijk om websites automatisch te downloaden. (“scrapen” of “spideren”)
In een groot aantal van de gevallen zou dat niet eens betwist worden. Een beter argument bij het downloaden is stellen dat de gebruiker van de algemene voorwaarden tekortsgeschoten is in haar informatieplicht.
Als juridische constructie is het misschien onwerkbaar, maar als juridisch argument is het heel interessant. Als we dit onredelijk vinden, moeten we die algemene voorwaarden op websites dan misschien ook onredelijk vinden? Het komt tenslotte op het zelfde neer: “als jij met mij praat, dan geef je daarmee aan akkoord te zijn met mijn algemene voorwaarden”. Sterker nog: server-side voorwaarden worden jou pas gegeven after-the-fact: nadat je al tegen de server hebt gepraat. Dat maakt de claim dat je akkoord bent gegaan met de voorwaarden nog dubieuzer.
Voor veilige communicatie op het internet is het nodig dat partijen vooraf goed kunnen inschatten wat de consequenties zijn van bepaalde handelingen. Een probleem is natuurlijk dat een groot deel van web-handelingen door software wordt gedaan: (praktisch) alle webservers zijn geautomatiseerd (er zit nooit een mannetje achter een bureau die GET-requests beoordeelt en op basis daarvan een response formuleert), en clients zijn ook wel eens geautomatiseerd (bijv. web crawlers, caching proxies of browser plug-ins). Die software is niet bepaald in staat om een enorme variatie aan potentiële consequenties te doorzien. Dat is natuurlijk ook meteen waar de schoen wringt bij dit voorstel: de webserver is niet in staat om jouw “algemene voorwaarden” te parsen. We hebben een formaat nodig dat wel “machine readable” is.
Een heel eenvoudig formaat is het binaire onderscheid “heeft geen consequenties” / “heeft (mogelijk) wel consequenties”. Dat verschil bestaat al, in de vorm van verschillende HTTP methods (helaas wordt dat niet altijd gerespecteerd). Een GET zou geen consequenties moeten hebben voor de client, maar het lijkt me redelijk dat een GET-response ook geen consequenties zou moeten hebben voor de server. Bepaalde consequenties zijn natuurlijk onvermijdelijk (dat de andere partij zal beschikken over de informatie die je opstuurt), maar daar heb je zelf controle over.
Het lijkt mij “normaal” dat een GET-request (dus normaal pagina bezoeken, niet formulier opsturen / op knop klikken) geen consequenties heeft. Je gaat niet akkoord met algemene voorwaarden, je sluit er geen overeenkomst mee, het leidt niet tot een transactie of het aangaan van een schuld/verplichting en dergelijke. Je blijft gebonden aan de wetten op de plaats waar je je bevindt, maar daar blijft het bij. Het zelfde zou dan moeten gelden voor het reageren op een GET-request.
Misschien zouden toezeggingen (“ik beloof X”), gedaan in een request of in een response, wel geldig kunnen zijn (daarbij maakt het medium namelijk niet uit: mondeling, op papier of digitaal). Toezeggingen (“ik beloof X”) zijn wel anders dan voorwaarden (“u gaat akkoord met X”). Natuurlijk moeten toezeggingen wel geloofwaardig zijn: als je een toezegging verstopt in een URL van de vorm http://mijnwebsite.nl/ikverkoopmijnzielaandeduivel, dan is het niet geloofwaardig dat iemand daar echt, bewust (niet geautomatiseerd) en goed geïnformeerd mee akkoord is gegaan als ‘ie een GET-request op die URL doet.
Voor de eerste pagina is dat dubieus, maar meestal bezoek je meer dan een pagina. Als de voorwaarden helder zijn getoond en je een tweede pagina bezoekt lijkt het me redelijk te veronderstellen dat je akkoord bent.
Dan zijn licenties in de header wel weer zinvol. Je stuurt een HTTP HEAD met jouw voorwaarden, indien akkoord antwoordt de server met zijn voorwaarden. Pas als de client ook akkoord is (eventueel na interactie met de gebruiker), wordt er een HTTP GET gedaan.
De do not track HTML header zou je kunnen zien als een gestandaardiseerde gebruikersvoorwaarde. Mijn indruk is dat de meeste webservers zich daar niet veel van aantrekken.
Dan moet je als gebruiker ook wel weer de geretourneerde statuscodes volgen: 200 OK betekent dan dat de server er mee akkoord is, terwijl 203 Accepted zou moeten betekenen dat ze er nog over nadenken. 451, unavailable for legal reasons, lijkt me dan een duidelijke aanwijzing dat ze het er niet mee eens zijn.