Overheden verzamelen op grote schaal tweets zonder gebruikers te informeren

| AE 13617 | Privacy | 40 reacties

Overheidsinstanties zoals het ministerie van sociale zaken, de Belastingdienst en de Nederlandse Voedsel- en Warenautoriteit (NVWA) verzamelen op grote schaal tweets over onder andere hun beleid zonder Twittergebruikers hierover te informeren. Dat meldde Security.nl onlangs op gezag van onderzoek door AG Connect en Trouw. Het gaat om sentimentanalyse, data-analyse waarbij bakken met tweets zeg maar als “positief” of “negatief” worden gelabeld zodat je kunt zien hoe je beleid valt bij de mensen. Ook hier heerst dus die misvatting dat dat mag omdat Twitter openbaar is. Kunnen we eens ophouden met “ja maar openbare bron” als argument?

Het idee achter sentimentanalyse is dat je op basis van grote datasets de werkelijkheid kunt meten, en dat dat een stuk goedkoper/makkelijker is dan steeds een enquête eruit doen of 1200 Nederlands bellen. Waar zeker wat in zit, en we hebben ook genoeg tools (zoals van Microsoft) die op basis van statistische tekstanalyse kunnen zeggen of een tweet over een onderwerp gaat en daar dan positief of negatief over is. Dat kun je dan over de tijd meten, groeperen naar locatie van gebruikers (Randstad versus de provincie, bijvoorbeeld), groei of daling signaleren en ga zo maar door.

Punt is natuurlijk wel, dat begint allemaal bij een enorme verzameling berichten van Twitter. En tweets (met Twitternaam) zijn nu eenmaal persoonsgegevens en dus valt het verzamelen en tot sentimenten omturnen van die gegevens onder de AVG. Mag dat? Ja, in principe wel: dit is een vorm van wetenschappelijk en statistisch onderzoek en dat kun je binnen de grondslag van het gerechtvaardigd belang (art. 6 lid 1 sub f AVG) prima rechtvaardigen. (Ook bij overheden, omdat dit niet gaat om uitoefening van een publiekrechtelijke taak.) Toestemming van de twitteraars is dus niet nodig.

Wat wél nodig is, is dat mensen worden geïnformeerd over dit verdere gebruik. Dat staat gewoon in de AVG, en is iets dat altijd moet bij data harvesting. Ik geef toe dat dit bij een klantanalyse wat makkelijker is, daar zet je het in je privacyverklaring of je stuurt een update in het portaal. Bij dit soort gebruik van Twitterdata is er maar één manier en dat is iedereen een tweet sturen (DM’s sturen kan niet altijd). Daar zouden we gek van worden als iedereen dat deed, maar dat is voor een individuele organisatie niet disproportioneel of onmogelijk. (Bij data-verzameling met een drone of sensoren op straat is het natuurlijk een ander verhaal qua complexiteit, dus dan is een bordje of banner genoeg.)

Ik zie in de reacties her en der boosheid met het argument “kom op, Twitter is openbaar en iedereen doet het”. Dat laatste is vast waar, maar verandert niets aan het punt dat de makkelijke toegankelijkheid van de bron géén argument is onder de AVG. Je bent niet vogelvrij omdat men kan scrapen zonder ingewikkelde contracten of toelatingsprocedure. En vanuit juridisch perspectief zou dat ook heel raar zijn, dat het legaal is om iets te doen omdat het heel makkelijk is, en dat alleen bij moeilijk scrapen je mensen zou moeten gaan informeren of zo?

Arnoud

 

Webshop die geen back-ups maakte verliest rechtszaak van softwareleverancier

| AE 12971 | Ondernemingsvrijheid | 9 reacties

Een webshop die geen back-ups van haar boekhoudgegevens maakte, en door een probleem met een softwarekoppeling klantgegevens verloor, heeft de rechtszaak tegen de leverancier van de koppeling verloren. Dat meldde Security.nl vorige week. De koppeling bleek gegevens van crediteuren in het boekhoudprogramma te overschrijven met debiteurenboekingen. Volgens het Gerechtshof staat het vast dat de webshop geen back-ups maakte en heeft de softwareleverancier met recht aangevoerd dat de webshop zelf verantwoordelijk is voor het regelmatig maken van back-ups. “Dat zij dat achterwege heeft gelaten, terwijl het wel mogelijk was, is dan ook een omstandigheid die haar valt toe te rekenen”, aldus het hof.

Het gaat concreet om een koppeling tussen het bekende webshoppakket Magento en Exact Online, waardoor de transacties van de Magento webshop worden doorgestuurd naar de boekhoudsoftware van Exact. Meelezende QA specialisten mogen even wegkijken, voor de rest:

Het boekhoudprogramma maakt gebruik van een tabel van nummering waarbij voor debiteuren en crediteuren dezelfde tabel wordt gebruikt. Beide groepen krijgen om die reden een verschillend startnummer. Voor debiteuren (klanten met een account en gastklanten zonder een account) is in dit geval gekozen voor een nummer beginnend met 3.000 respectievelijk 7.000 en voor crediteuren beginnend met 1-2.999 en vanaf 15.000. De crediteuren moeten handmatig worden ingevoerd, de debiteuren (zowel de bestellingen van klanten met een account als die van gastklanten) worden door de koppeling automatisch in het boekhoudprogramma ingevoerd.
Deze wijze van scheiden van relaties staat onder programmeurs ook wel bekend als een WTF want op deze manier is het natuurlijk mogelijk dat het aantal aankopen zo oploopt dat je de 15.000 aantikt en dat je debiteur dan een crediteur is. En dat gebeurde ook, omdat er een foutje zat in het toekennen van nummers bij klanten die als gast bestellen:
Hallo … De gast accounts beginnen bij 7000. Inmiddels hebben we al meer dan 8000 gast accounts, waardoor je dus uit komt op de nummering van de crediteuren.
Dit hoort natuurlijk niet te gebeuren, en pijnlijk voor de webshop was vervolgens dat men geen backup had van de relevante tabellen zodat het een berg werk was om alle debiteuren en crediteuren weer in ere te herstellen. Is dit nu het soort fout waar je voor aansprakelijk bent vanuit je zorgplicht als ICT-er? Helaas komt het Hof niet aan die vraag toe, maar ze bevestigt wel dat we zoiets best “eigen schuld” kunnen noemen.

Iedereen die met digitale gegevens werkt in de bedrijfsvoering, moet daar gewoon backups van hebben. Want of het nou gaat om ransomware, dikke vingers of een API koppeling die debiteuren moet invoeren maar die soms als crediteur aanmerkt, als je die data kwijt bent dan heb je een enórm probleem.

Juridisch gezien kom je dan uit bij “eigen schuld” (art. 6:101 BW): weliswaar ontslaat dat de leverancier niet van aansprakelijkheid, maar hij hoeft minder van de schade te vergoeden omdat de gevolgen mede aan de webwinkel te wijten zijn.

Het is aannemelijk dat geen handmatig herstel met de gevorderde kosten nodig was geweest als de door [de webwinkel] gestelde tekortkoming achterwege zou zijn gebleven (zo die na bewijslevering zou komen vast te staan). Maar dat geldt ook indien [de webwinkel] zelf de nodige zorgvuldigheid zou hebben betracht door een back-up te maken. De kosten van de advocaat in verband met het verhaal van herstelkosten bij [de leverancier] zouden ook niet gemaakt zijn.

Je kunt je natuurlijk afvragen of de leverancier niet meer had moeten doen. Nee, niet in dit geval:
Het hof betrekt daar ook bij (i) dat het ging om een standaardkoppeling tegen een lage prijs zonder abonnement, (ii) dat de koppeling als zodanig jarenlang goed heeft gefunctioneerd, (iii) dat [de webwinkel] zelf voor Exact Online heeft gekozen, (iv) dat zij zich in de werking en de beperkingen daarvan kennelijk niet voldoende heeft verdiept, (v) dat de koppeling is hersteld en (vi) dat [de webwinkel] niet onderbouwd heeft gesteld dat zij door het tijdelijk kwijtraken van enkele gegevens van crediteuren (andere financiële) problemen heeft ondervonden.
Met name dat laatste geeft voor mij de doorslag: er zijn geen daadwerkelijke problemen, alleen maar rotzooi die opgeruimd moest worden omdat er geen backup was. Heel vervelend, maar dát is dan het gevolg van je eigen schuld.

Ondertussen blijft wel open de vraag of de leverancier beter had moeten programmeren, bijvoorbeeld een check dat het debiteurennummer altijd kleiner dan 15.000 had moeten zijn. Als je een koppeling met Exact verkoopt, en die heeft deze rare constructie in haar database-tabellen, dan moet je zulke dingen wel doen lijkt me. Maar kennelijk komt het weinig voor dat Exact Online-gebruikers meer dan 8000 klanten zonder registratie hebben?

Arnoud

Raad van State: Tweede Kamer hoeft broncode van debat-app niet openbaar te maken

| AE 12600 | Informatiemaatschappij | 1 reactie

De Tweede Kamer hoeft de broncode van de Debat Direct-app definitief niet openbaar te maken, meldde Tweakers donderdag. Dit is de einduitspraak in die zaak van laatst, waarin een IT’er al sinds 2018 probeert toegang te krijgen tot de broncode van de Debat Direct app van het parlement. De Raad van State oordeelt nu dat dit niet kan, omdat de ingezette wetten – de Wob en de Wet hergebruik overheidsinformatie – niet van toepassing zijn op de Tweede Kamer als orgaan. Het artikel bij Tweakers gaf vele reacties, inclusief speculatie waarom de overheid toch zo moeilijk zou doen met het achterhouden van deze informatie. Die nota bene feitelijk al online staat, want het is Javascript.

Mijn gevoel bij de zaak is dat men dacht, een Apple + Android app én een webapp dan kan iedereen erbij. Er is dan geen reden om ook nog de API’s vrij te geven. Misschien kortzichtig/naïef, maar ik zie het praktijkgerichte argument wel dat “iedereen er nu toch naar kan kijken”? De vraag om API’s is marginaal te noemen.

Je houdt dan het principiële punt over, en dat is natuurlijk een zeer geliefde kluif voor juristen. (Wat zegt een advocaat in een contractenzaak als eerste? “Pacta sunt servanda”. En als tweede? “Dit lijkt een eenvoudig geschil, maar het gaat om het principe”. De rechter weet dat het dan een lange dag gaat worden.)

Bij een principieel punt moet natuurlijk je algemene regels aandragen om je zaak te onderbouwen, en dan gaan andere belangen meespelen. Zoals hier, als je zegt “in principe heeft de burger recht op de broncode” dan moet je een wet zoals de Wet hergebruik overheidsinformatie erbij slepen. En dan is er een principieel verweer: de TK valt buiten die wet. Je wilt dan niet als TK het precedent scheppen dat je voor software wél onder die wet valt. Waarom niet? Uit principe niet. Dat werkt twee kanten op.

Vervolgens liet men de advocaten los en die zijn vanuit dat principieel verweer gaan terugvechten. Er is dan niemand die een stap terugdoet, zoals door te zeggen “jongens alles stáát al online” of “weet je wat, hier is een API definitie en onze endpoint staat hier, zullen we de rest van het geld besteden aan wat nuttigs”. Want het ligt onder de rechter, dus blijf je eraf.

Zoals ik wel vaker zeg, geen complot veronderstellen waarin simpele incompetentie of naïviteit genoeg is als verklaring.

Arnoud

Google wint van Oracle, maar de rest van de wereld heeft daar weinig aan

| AE 12602 | Intellectuele rechten | 10 reacties

Google heeft geen inbreuk gemaakt op het copyright van softwarebedrijf Oracle toen het de code uit de programmeertaal Java gebruikte voor zijn mobiele besturingssysteem Android. Dat meldde RTL Nieuws onlangs. De Amerikaanse Supreme Court bepaalde namelijk dat de relevante code een fair use was onder eventuele auteursrechten van Oracle op diens Java-implementatie. Leuk voor Google,… Lees verder

Gaat het om open source of open API’s bij de overheid?

| AE 12568 | Regulering | 6 reacties

De overheid heeft een moeizame relatie met ict, zo poneert een interessant Tweakers-artikel over openbaarheid bij overheids-ICT-projecten. Al geruime tijd (sinds 2002, Motie-Vendrik) worstelt men met het idee van openheid bij software en data die door de overheid wordt ontwikkeld. Het sterkst is het pleidooi geweest voor het openen (bevrijden) van software. Maar zelf neig ik… Lees verder

Mag ik de hardcoded sleutel van een app gebruiken voor mijn eigen aanroepen?

| AE 11944 | Ondernemingsvrijheid | 36 reacties

Een lezer vroeg me: Ik wil gebruik maken van een online tool vanuit mijn eigen software. Helaas is een zakelijke licentie op die tool veel te duur. Nu zat ik in de bijbehorende app voor consumentengebruik te kijken, en die blijkt met een hardcoded key te authenticeren. Ik kan daarmee dus perfect een aanroep simuleren,… Lees verder

Googles gebruik van de Java API is nu toch weer geen fair use

| AE 10509 | Intellectuele rechten | 13 reacties

Googles gebruik van de Java API packages is geen fair use, las ik bij ITenRecht. Dit is de vierde stap in hoger beroep van de Google/Oracle rechtszaak over auteursrecht op de Java API die al enige jaren loopt. In eerste instantie bleek de API niet beschermd, in hoger beroep wel, toen bleek Googles gebruik een… Lees verder

Mag je de Twitter API scrapen voor wetenschappelijk onderzoek?

| AE 8877 | Intellectuele rechten | 9 reacties

Een lezer vroeg me: Deze meneer heeft een mooie data-analyse gemaakt van Donald Trump zijn tweets: Trump zelf gebruikt een Android-apparaat en een ghostwriter nuanceert de boel vanaf een iPhone. Daarbij vroeg ik mij af of dit zomaar mocht. Twitter zegt van wel bij onderzoeksdoeleinden (onder bepaalde voorwaarden). Zoals dat je je dataset niet mag… Lees verder