Juridisch advies 3rd party dienst

[Mocro_Pimp®]

Ik heb een (met SSL verborgen) API van een dienst gebruikt om, zeg maar, een dienst voor de gebruikers van die dienst te bieden.

Het gaat om een functionaliteit dat zakelijke gebruikers erg graag wilden zien, maar het bedrijf in kwestie weigerde daar aan te gehoorzamen.

Uiteindelijk heb ik dus de API onderzocht en daar een eigen dienst omheen gebouwd.

Nu ben ik bijna klaar om de dienst te gaan lanceren, maar ik heb nogal vraagtekens aan de juridische kant van dit.

Online kwam ik dit artikel tegen van Mr.ir. Arnoud Engelfriet, ICT-jurist, gespecialiseerd in internetrecht.

Samengevat schrijft hij dat het grijs gebied is, maar dat het wellicht kan als mijn app dus meerwaarde heeft voor de gebruikers, zonder daarbij de oorspronkelijke eigenaar te benadelen.

Hoever dat " benadelen" kan gaan is nogal vaag. Mijn dienst benadeelt bijv. niet financieel, maar neemt wel resources van diens server door meer queries te doen... Maar je zou ook kunnen zeggen dat het totaal aantal queries van alle gebruikers juist heel erg afneemt.

En hoe het zit met het noemen van het gedeponeerd merk op mijn eigen website?
Mag ik schrijven: Log hier in met je XXX-account. Waarbij XXX dus het merk is van de andere partij.

Talloze vragen die mij nogal terughoudend maken.

Tips en advies zouden heel erg welkom zijn.

[ Voor 3% gewijzigd door Mocro_Pimp® op 24-12-2017 20:00 ]

[S_Chief]

Hij is ook actief op Tweakers (@Arnoud Engelfriet). Misschien kan hij je een duwtje in de goede richting geven.

[MAX3400]

Klinkt nogal shady allemaal.

Je zou allicht kunnen beschrijven wat het doet op basis van "algemene termen en protocollen" zonder de daadwerkelijke officiele dienst te noemen.

Laat ik het subtiel brengen; er zijn al vaker ontwikkelaars voorzien van cease&desist notices tereijl hun dienst minder "erg" gebruik maakte van de originele dienst.

[Mocro_Pimp®]

MAX3400 schreef op zondag 24 december 2017 @ 20:48:
Klinkt nogal shady allemaal.

Je zou allicht kunnen beschrijven wat het doet op basis van "algemene termen en protocollen" zonder de daadwerkelijke officiele dienst te noemen.

Laat ik het subtiel brengen; er zijn al vaker ontwikkelaars voorzien van cease&desist notices tereijl hun dienst minder "erg" gebruik maakte van de originele dienst.

Ik wil het best wel toelichten. Ik vind er ook helemaal niets "shady" aan. Maar dat is mijn perspectief (en dat van de gebruikers). Omdat de oorspronkelijke app nogal uniek is, moet ik voorzichtig zijn met teveel informatie vrijgeven in dit nog iets te vroege stadium.

Het enige dat er gebeurt zijn twee drie soorten acties: Gebruiker registreert zijn 3th-party account. Hierbij wordt de API gebruikt om dit te bevestigen.

Normaliter moet de gebruiker heel de dag door de app in de gaten houden voor matches. Mijn dienst automatiseert dat.

Vervolgens wordt de API alleen gebruikt als er een match is dat aan de opgegeven criterea voldoet van de gebruiker.. Hiermee wordt de actie uitgevoerd die de gebruiker anders zelf had moeten ondernemen.
Dit gebeurt "in de naam van" de gebruiker.

[ Voor 8% gewijzigd door Mocro_Pimp® op 24-12-2017 21:24 ]

[joppybt]

Ga je de eindgebruikers vragen om hun inloggegevens van de API?
Houd er rekening mee dat je daarmee ook een enorm stuk verantwoordelijkheid en waarschijnlijk zelfs aansprakelijkheid krijgt. Als er iets 'mis' gaat kan je dat een boel geld kosten.
(en algemene voorwaarden waarmee je aansprakelijkheid uitsluit zijn vaak niet geldig)

[Mocro_Pimp®]

joppybt schreef op zondag 24 december 2017 @ 21:58:
Ga je de eindgebruikers vragen om hun inloggegevens van de API?
Houd er rekening mee dat je daarmee ook een enorm stuk verantwoordelijkheid en waarschijnlijk zelfs aansprakelijkheid krijgt. Als er iets 'mis' gaat kan je dat een boel geld kosten.
(en algemene voorwaarden waarmee je aansprakelijkheid uitsluit zijn vaak niet geldig)

Nee ik vraag de gebruikers alleen om gebruikersnaam en wachtwoord. Dit is genoeg om een accesstoken te krijgen. Die wordt dan ook nogeens helemaal niet meer gebruikt.

Bij het uitvoeren van de laatste api call worden de gebruikersnaam en ww als een versleutelde string voor authenticatie gebruikt. Meer niet.

Wat voor verantwoordelijkheid en aansprakelijkheid heb je in gedachten? Op welk gebied?

[MAX3400]

Mocro_Pimp® schreef op zondag 24 december 2017 @ 22:24:
[...]

Wat voor verantwoordelijkheid en aansprakelijkheid heb je in gedachten? Op welk gebied?

Ik denk dat er bedoeld wordt: jouw app zorgt voor geautomatiseerd handelen bij een match. Tenminste, zo begrijp ik het uit je andere post. Indien jouw app niet op tijd reageert of verkeerd handelt, wat is dan het gevolg?

Kijk, als voorbeeld even 2 financiele / bestaande apps: met Bux kan je op koersen wedden, zeg maar. Normaal doet je dat ook handmatig en daardoor maak je winst/verlies. Stel nou dat jou app hier iets automatisch in doet (bij een daling van de koers, snel in Bux een short invoeren). Als jouw app dat verkeerd doet, maakt de gebruiker van jouw app automatisch verlies.

Of een dating-app; als er een match is tussen 1 persoon en meerdere anderen, maak je automatisch kans op een date en een tegoedbon (voorbeeld). Jouw app moet dus zsm op "JA, IK ACCEPTEER" klikken. Stel nou dat je verkeerd klikt of jouw app is "vertraagd" waardoor ik als betalende dating-gebruiker al 4 leuke dates en 4 tegoedbonnen ben misgelopen. Dan kan ik jou daarvoor aansprakelijk houden (al dan niet via een rechtzaak) of jouw app in een store volledig affikken qua reviews.

Als laatste, ook gebaseerd op de blog die je al linkte; zodra jij geld verdient met jouw app en daardoor inkomsten weghaalt bij de originele app/eigenaar, moet je er eigenlijk al niet aan beginnen.

[Mocro_Pimp®]

MAX3400 schreef op zondag 24 december 2017 @ 22:29:
[...]

Ik denk dat er bedoeld wordt: jouw app zorgt voor geautomatiseerd handelen bij een match. Tenminste, zo begrijp ik het uit je andere post. Indien jouw app niet op tijd reageert of verkeerd handelt, wat is dan het gevolg?

Kijk, als voorbeeld even 2 financiele / bestaande apps: met Bux kan je op koersen wedden, zeg maar. Normaal doet je dat ook handmatig en daardoor maak je winst/verlies. Stel nou dat jou app hier iets automatisch in doet (bij een daling van de koers, snel in Bux een short invoeren). Als jouw app dat verkeerd doet, maakt de gebruiker van jouw app automatisch verlies.

Of een dating-app; als er een match is tussen 1 persoon en meerdere anderen, maak je automatisch kans op een date en een tegoedbon (voorbeeld). Jouw app moet dus zsm op "JA, IK ACCEPTEER" klikken. Stel nou dat je verkeerd klikt of jouw app is "vertraagd" waardoor ik als betalende dating-gebruiker al 4 leuke dates en 4 tegoedbonnen ben misgelopen. Dan kan ik jou daarvoor aansprakelijk houden (al dan niet via een rechtzaak) of jouw app in een store volledig affikken qua reviews.

Als laatste, ook gebaseerd op de blog die je al linkte; zodra jij geld verdient met jouw app en daardoor inkomsten weghaalt bij de originele app/eigenaar, moet je er eigenlijk al niet aan beginnen.

Ah zo. Ik waardeer je input.
Van misgelopen inkomsten van de andere partij of verliezen van de gebruikers is geen sprake.
Sterker nog, de efficientie van de gebruikers gaat omhoog en daarmee ook de (potentiele) effectiviteit van de derde partij.

Het is echt een toevoeging die gebruikers zullen hartelijk ontvangen.

Voor juridische kwesties in deze categorie maak ik mij dan ook geen zorgen.

Het gaat mij meer om het noemen van de andere partij op mijn website. Uiteraard weten gebruikers wie die andere partij is en moeten zij een account hebben bij deze partij. Het zijn ook nog eens gesloten kringen.

En ook het gebruiken van een API die eigenlijk was verborgen met SSL.

[StevenK]

Als jij gebruikt maakt van wat je zelf noemt een verborgen API dan loop je het reële risico dat dit strafrechtelijk net zo gezien wordt als een SQL injectie en dus als een strafbare computervredebreuk.

[NMe]

Juridisch advies heeft niks met programmeren te maken.

PRG>>AZ

[Mocro_Pimp®]

NMe schreef op zondag 24 december 2017 @ 23:54:
Juridisch advies heeft niks met programmeren te maken.

PRG>>AZ

Ja ik was er niet zeker van maar aangezien het gerelateerd is aan geprogrammeerd software dacht ik van wel.

[Mocro_Pimp®]

Mijn onzekerheid is weggenomen door dit artikel, wederom door Mr.ir. Arnoud Engelfriet.

[Reptile209]

Mocro_Pimp® schreef op zondag 24 december 2017 @ 23:21:
[...]


Ah zo. Ik waardeer je input.
Van misgelopen inkomsten van de andere partij of verliezen van de gebruikers is geen sprake.
Sterker nog, de efficientie van de gebruikers gaat omhoog en daarmee ook de (potentiele) effectiviteit van de derde partij.

Het is echt een toevoeging die gebruikers zullen hartelijk ontvangen.

Voor juridische kwesties in deze categorie maak ik mij dan ook geen zorgen.

Het gaat mij meer om het noemen van de andere partij op mijn website. Uiteraard weten gebruikers wie die andere partij is en moeten zij een account hebben bij deze partij. Het zijn ook nog eens gesloten kringen.

En ook het gebruiken van een API die eigenlijk was verborgen met SSL.

Ik zou hier toch voorzichtig mee zijn. Voor eigen gebruik is dat allemaal best, maar als je het breder gaat verspreiden zie ik toch wel wat beren op de weg:

- jij gaat inloggegevens van de aanbieder verwerken. Men heeft alleen jouw woord dat er verder niks met die gegevens gebeurt (opslaan, doorsturen, lekken)
- je haalt mensen weg van de website van de aanbieder. Je resultaten komen daar weliswaar vandaan, maar er gaat allerlei interactie verloren (webstatistieken, banners, tracking binnen de site, andere zaken die een bezoeker beinvloeden). Misschien is dat ook wel de/een reden dat ze het zelf niet willen doen.
- je bent een risico voor hun goede naam als je die naam gebruikt. Stel dat jouw app groot wordt en dan een schandaal veroorzaakt (verkeerde actie uitgevoerd, gegevens gelekt, en hebt je secretaresse ge-#metoo-'t, ...), dan hebben zij daar last van. En geen mogelijkheid meer om dat te voorkomen.
- als de (onofficiele en ongedocumenteerde?) Api opeens verandert of wordt gestopt, dan doet jouw dienst het opeens niet meer. En dan?

Ik zou toch overwegen om een demo naar het bedrijf te sturen, en te vragen om het samen verder te ontwikkelen en uit te brengen.

[Mickey77]

Mocro_Pimp® schreef op maandag 25 december 2017 @ 01:03:
Mijn onzekerheid is weggenomen door dit artikel, wederom door Mr.ir. Arnoud Engelfriet.

Je geeft weinig info dus ik denk dat niemand met zekerheid kan zeggen of het is toegestaan wat je doet. Gezien de twee artikelen zou ik Arnoud contacteren. Maar op basis van wat je schrijft, denk ik dat je veel te optimistisch bent. Hoewel Arnoud aangeeft dat het onder bepaalde omstandigheden is toegestaan om een API te gebruiken en om te 'reverse engineeren', geeft hij ook aan dat het lang niet altijd mag.

Ik acht de kans groot dat je bewust of onbewust die stukjes in zijn artikelen pakt die voor jou goed uit komen en stukjes negeert die niet zo goed uit komen. Want je wilt jouw werk zo graag publiceren! Ik lees zinsnedes van jouw kant die mij die indruk geven. Een zin als: "Het gaat om een functionaliteit dat zakelijke gebruikers erg graag wilden zien, maar het bedrijf in kwestie weigerde daar aan te gehoorzamen." is niet netjes geformuleerd. Het zou moeten zijn "het bedrijf geeft aan deze functionaliteit niet toe te gaan voegen". het gebruik van woorden als weigeren en gehoorzamen vind ik niet passend en dat zul je zelf ook moeten erkennen.

Ik denk dat je er van uit moet gaan dat
a) je een dreigbrief zult krijgen die je aan het twijfelen zal brengen (zodat je alsnog Arnoud moet inschakelen) en
b) dat je dienst vrij snel zal worden geblokkeerd door hun, zodat deze niet meer werkt.

Om je vraag te beantwoorden: ik zou sowieso niet de naam XXX tonen op jouw website waar men in moet loggen. Eventueel kun je er een hyperlinkje onder plaatsen "welke inlog" en dat je dan per email de mensen die het niet begrijpen uitlegt dat het de inlog van XXX is. Zodra je XXX direct toont denk ik dat de tegenpartij al snel zal zeggen dat je inbreuk maakt.

Ten aanzien van de inbreuk die je maakt zijn er natuurlijk verschillende denkbare inbreuken. Van het reverse engineeren tot aan de extra druk die jouw queries leggen op hun server. Ik denk echt dat als jij veel queries gaat runnen vanaf jouw server dat ze dat gaan stellen als inbreuk. Daarbij hoeven ze niet perse de letter van de wet te volgen zoals jij die ziet in Arnouds werk. Als ze jouw inbreuk gelijk stellen aan een DDOS (wat het niet is, ik weet het), dan staat de politie eerder voor de deur dan je denkt. Wil je dat soort gedoe?

Ik ben het eens met reptile209: "Ik zou toch overwegen om een demo naar het bedrijf te sturen, en te vragen om het samen verder te ontwikkelen en uit te brengen."

Toevoeging: heb je de voorwaarden van eindgebruikers voor hun dienst goed uitgeplozen? Als daarin bijvoorbeeld is opgenomen dat het gebruikers niet is toegestaan om in enige automatische vorm de dienst te gebruiken, dan ben je al het haasje. Dan kunnen ze jouw dienst scharen onder de voorwaarden voor eindgebruikers en stellen dat je in overtreding bent van hun voorwaarden.

[ Voor 6% gewijzigd door Mickey77 op 25-12-2017 10:24 ]

[O88088]

Samengevat schrijft hij dat het grijs gebied is, maar dat het wellicht kan als mijn app dus meerwaarde heeft voor de gebruikers, zonder daarbij de oorspronkelijke eigenaar te benadelen.

Onderschat het niet. Nu willen ze het misschien niet zelf doen, maar als ze zien dat jouw dienst succesvol is kan dat zomaar veranderen.

[TripleQ]

En wat als de API wordt aangepast?
Of ze gaan jou actief blokkeren?

Ga jij je gebruikers dan uitleggen dat het niet meer werkt?

[Yucon]

Heb je een vermoeden waarom ze het niet willen implementeren? Je lijkt er van uit te gaan dat het luiheid/geen zin/desinteresse is, maar het kan natuurlijk ook een bewuste commerciele beslissing zijn.

In dat laatste geval zullen ze je een stuk anders benaderen dan in het eerste geval.

[laurens0619]

Of het officieel mag kan ik niet beantwoorden, staat er iets over in de terms and services op hun site? Snapchat heeft hier bv een apart stuk over beschreven.

Tegelijk zie je het wel vaker gebeuren:

- Tinder (turbomatch), fire for tinder
- msn (trillium)
- WhatsApp (wa plus)
- pokemon go
Etcc

Zijn allemaal grote namen en vaak zie je kat en muis spel voor blokkeren, vooral met pokemon go (ze zijn er dus niet blij mee )

IANAL maar ik zou zeggen, als er niets in term of use of the service beschreven staat dat het grijs gebied is. Staat er iets over in, kun je eerder blokkade/claims verwachten.

Maar je vraag is juridisch, dan lijkt het mij eenvoudig. Vraag schriftelijk toestemming

[ Voor 52% gewijzigd door laurens0619 op 25-12-2017 11:53 ]

[Croga]

Mocro_Pimp® schreef op zondag 24 december 2017 @ 19:56:
Samengevat schrijft hij dat het grijs gebied is, maar dat het wellicht kan als mijn app dus meerwaarde heeft voor de gebruikers, zonder daarbij de oorspronkelijke eigenaar te benadelen.

Hoever dat " benadelen" kan gaan is nogal vaag. Mijn dienst benadeelt bijv. niet financieel, maar neemt wel resources van diens server door meer queries te doen... Maar je zou ook kunnen zeggen dat het totaal aantal queries van alle gebruikers juist heel erg afneemt.

Dit is zo'n beetje het belangrijkste deel. Benadelen kan op veel verschillende manieren;
- Ga jij geld verdienen met je werk? Zo ja dan benadeel je ze. Dat geld zou anders namelijk naar hen zelf gegaan zijn. (En als je er geen geld mee gaat verdienen; waarom doe je het dan?)
- Verkeer wat niet naar hun eigen website gaat maar naar die van jou kan ook benadelen zijn. Ze kunnen dan tenslotte hun eigen advertenties niet laten zien en/of hun eigen naam wordt niet meer genoemd.
- Zoals je zelf al aangeeft wordt de load op hun server groter en worden ze daarmee benadeelt.

Houdt daarnaast ook rekening met database recht. Als jij de informatie die zij met veel moeite verzamelt hebben één op één door geeft dan schendt je daarmee het database recht. En ook dat is niet toegestaan.

Ik zie in ieder geval veel meer redenen waarom dit níet zou mogen dan redenen waarom dit wél zou mogen.

En om nog maar een keer aan te halen: Jij gaat aansprakelijk zijn voor deze gegevens. Als jij geautomatiseerd een bepaalde trigger uit gaat vragen dan ben jij verantwoordelijk voor de juistheid van die trigger. Als jouw gebruiker actie onderneemt op basis van die trigger en de trigger blijkt onjuist te zijn dan gaat de gebruiker jou aanklagen.

[F_J_K]

Mocro_Pimp® schreef op zondag 24 december 2017 @ 19:56:
En hoe het zit met het noemen van het gedeponeerd merk op mijn eigen website?
Mag ik schrijven: Log hier in met je XXX-account. Waarbij XXX dus het merk is van de andere partij.

Je gaat dus persoonsgegevens verwerken en aan een ander geven, zonder overeenkomst met die ander. Daar vind de nieuwe (en ook de oude) privacy-wetgeving wat van.

Sowieso: als het in het voordeel van het bedrijf is dan kan je het gewoon met ze bespreken. Stiekem gaat niet werken, als de gebruikers het weten dan weten zij het ook. Ook zonder juridische stappen kunnen ze gewoon de API iets aanpassen of jouw IP's blokkeren.

Mocro_Pimp® schreef op maandag 25 december 2017 @ 01:03:
Mijn onzekerheid is weggenomen door dit artikel, wederom door Mr.ir. Arnoud Engelfriet.

Je vraag gaat niet over reverse engineeren?

Kudo's voor de 'donder op dan doe ik het zelf wel'-mentaliteit, maar er zitten wat haken en ogen aan.

[Kurkentrekker]

Gewoon toestemming vragen. Als je op de een of andere manier bang bent dat je die niet gaat krijgen, dan is daar het antwoord op de vraag of je ermee in de problemen gaat komen.

Natuurlijk is er nog een grijs gebied tussen waar het juridisch misschien wel mag, maar ze er toch een probleem van gaan maken. Ben je in dat geval bereid het juridische gevecht aan te gaan? En heb je daar de middelen voor?

[anboni]

De vraag was:

Ga je de eindgebruikers vragen om hun inloggegevens van de API?

En dan is dit je antwoord?

Mocro_Pimp® schreef op zondag 24 december 2017 @ 22:24:
Nee ik vraag de gebruikers alleen om gebruikersnaam en wachtwoord. Dit is genoeg om een accesstoken te krijgen. Die wordt dan ook nogeens helemaal niet meer gebruikt.

Bij het uitvoeren van de laatste api call worden de gebruikersnaam en ww als een versleutelde string voor authenticatie gebruikt. Meer niet.

En niet alleen vraag je om de inloggegevens, je gaat ze ook nog eens opslaan. Verder vraag ik me dan af: waarom moet die laatste call expliciet met gebruikersnaam+wachtwoord als er al eerder een accesstoken was gegenereerd? De enige reden die ik kan bedenken, is dat er op dat punt een extra bevestiging moet zitten dat de gebruiker echt deze actie wil uitvoeren (zeg maar als electronische handtekening).

Echt, je vraag gaat over veel meer dan het reverse engineeren van die API.

[GlowMouse]

F_J_K schreef op maandag 25 december 2017 @ 11:42:
[...]

Je gaat dus persoonsgegevens verwerken en aan een ander geven, zonder overeenkomst met die ander. Daar vind de nieuwe (en ook de oude) privacy-wetgeving wat van.

De privacy-wetgeving staat toe dat je persoonsgegevens onder meer mag verwerken als je expliciete toestemming hebt van degene van wie de persoonsgegevens zijn, of als dat noodzakelijk is ter uitvoering van een overeenkomst. Als een gebruiker de dienst van TS afneemt, dan mag TS de gegevens verwerken die daarvoor noodzakelijk zijn, waaronder gebruikersnaam/wachtwoord. De dienst met de API heeft daar niets mee te maken.

Mocro_Pimp® schreef op zondag 24 december 2017 @ 19:56:
Hoever dat " benadelen" kan gaan is nogal vaag. Mijn dienst benadeelt bijv. niet financieel, maar neemt wel resources van diens server door meer queries te doen... Maar je zou ook kunnen zeggen dat het totaal aantal queries van alle gebruikers juist heel erg afneemt.

De belangrijkste nadelen zijn al genoemd door Reptile209. De vraag is wel telkens of het om een gerechtvaardigd belang gaat. Als het bijvoorbeeld alleen om analytische data gaat dan weegt dat minder zwaar dan wanneer er inkomsten worden misgelopen.

En hoe het zit met het noemen van het gedeponeerd merk op mijn eigen website?
Mag ik schrijven: Log hier in met je XXX-account. Waarbij XXX dus het merk is van de andere partij.

Dat mag, maar je moet niet de indruk wekken dat je XXX bent. Zie bv. https://blog.iusmentis.co...elkom-bij-merknaam-sites/

Als je toestemming gaat vragen aan de API-aanbieder is de kans groot dat men dat liever niet heeft, en je moet er zoals genoemd rekening mee houden dat jouw ip-adressen geblokkeerd gaan worden. Zorg dus dat je daar een pasklare oplossing voor hebt om te voorkomen dat je dienst niet meer werkt. Wellicht dat een blokkade onrechtmatig is, maar dan moet je (proces)kosten maken om dat recht te halen (en ondertussen werkt je dienst niet). Als je je dienst kunt aanbieden als browser plug-in, is een blokkade eenvoudiger te omzeilen. Je moet er dan wel zeker van zijn dat je dienst is toegestaan. Mocht de wederpartij gaan procederen, kunnen ze eigenlijk maar twee dingen eisen: dat je stopt en dat je hun schade vergoedt. Zelfs als er geen schade is geleden, kan zo'n proces wel prijzig worden, en ook als je wint kost dat nog duizenden euro's.

[F_J_K]

GlowMouse schreef op maandag 25 december 2017 @ 13:50:
De privacy-wetgeving staat toe dat je persoonsgegevens onder meer mag verwerken als je expliciete toestemming hebt van degene van wie de persoonsgegevens zijn, of als dat noodzakelijk is ter uitvoering van een overeenkomst. Als een gebruiker de dienst van TS afneemt, dan mag TS de gegevens verwerken die daarvoor noodzakelijk zijn, waaronder gebruikersnaam/wachtwoord. De dienst met de API heeft daar niets mee te maken.

Maar mag de TS dan vervolgens persoonsgegevens aan een derde partij geven zonder verwerkersovk of anderszins controle van de TS dat dat andere bedrijf er goed mee omgaat? (Maar je hebt gelijk, misschien voldoet het als je de persoon ook expliciet laat zeggen dat het bedrijf diezelfde gegevens al heeft).

[Verwijderd]

Mocro_Pimp® schreef op maandag 25 december 2017 @ 01:03:
Mijn onzekerheid is weggenomen door dit artikel, wederom door Mr.ir. Arnoud Engelfriet.

Hoe kom je erbij dat Arnoud meester in de rechten en ingenieur is? Hij is een jurist en daar houd het wel op.

[GlowMouse]

F_J_K schreef op maandag 25 december 2017 @ 13:55:
[...]

Maar mag de TS dan vervolgens persoonsgegevens aan een derde partij geven zonder verwerkersovk of anderszins controle van de TS dat dat andere bedrijf er goed mee omgaat? (Maar je hebt gelijk, misschien voldoet het als je de persoon ook expliciet laat zeggen dat het bedrijf diezelfde gegevens al heeft).

Het bedrijf heeft de gegevens inderdaad al. Praktisch voert het bedrijf enkele taken uit in naam van de klanten. Als jij mijn belastingaangifte gaat invullen, hoef jij ook geen bewerkersovereenkomst met de Belastingdienst te sluiten. Je doet dan dingen in mijn naam.

Verwijderd schreef op maandag 25 december 2017 @ 14:05:
[...]

Hoe kom je erbij dat Arnoud meester in de rechten en ingenieur is? Hij is een jurist en daar houd het wel op.

Volgens je link is hij mr.ir. Hij is geen advocaat, maar wel meester in de rechten en ingenieur.

[Verwijderd]

GlowMouse schreef op maandag 25 december 2017 @ 14:08:
[...]

Het bedrijf heeft de gegevens inderdaad al. Praktisch voert het bedrijf enkele taken uit in naam van de klanten. Als jij mijn belastingaangifte gaat invullen, hoef jij ook geen bewerkersovereenkomst met de Belastingdienst te sluiten. Je doet dan dingen in mijn naam.
[...]
Volgens je link is hij mr.ir. Hij is geen advocaat, maar wel meester in de rechten en ingenieur.

Ik heb niets gezegd.

[Kurkentrekker]

Nvm

[ Voor 99% gewijzigd door Kurkentrekker op 25-12-2017 14:13 ]

[MAX3400]

GlowMouse schreef op maandag 25 december 2017 @ 14:08:
[...]

Het bedrijf heeft de gegevens inderdaad al. Praktisch voert het bedrijf enkele taken uit in naam van de klanten. Als jij mijn belastingaangifte gaat invullen, hoef jij ook geen bewerkersovereenkomst met de Belastingdienst te sluiten. Je doet dan dingen in mijn naam.

Niet helemaal.

Als jij naast me zit met alle papieren en ik reken alles door en vul het in terwijl jij inlogt op DigiD, is er geen overeenkomst nodig. Als jij al je papieren in mijn brievenbus flikkert en verwacht dat ik inlog op jouw DigiD (al dan niet gemachtigd), is die overeenkomst wel nodig.

Topicstarter maakt gebruik van user+pass van klanten om hiermee een cookie/session/whatever op te zetten. Op dat moment is de app van topicstarter dus bezig met andermans credentials. Daar zit enige nuance in "hoe" en "waar" precies dit plaatsvindt maar zodra topicstarter ook maar 1 bitje opslaat van alle benodigde credentials om de sessie in stand te houden, is er een overeenkomst nodig.

[Mocro_Pimp®]

MAX3400 schreef op maandag 25 december 2017 @ 14:13:
[...]

Niet helemaal.

[...]

Topicstarter maakt gebruik van user+pass van klanten om hiermee een cookie/session/whatever op te zetten. Op dat moment is de app van topicstarter dus bezig met andermans credentials. Daar zit enige nuance in "hoe" en "waar" precies dit plaatsvindt maar zodra topicstarter ook maar 1 bitje opslaat van alle benodigde credentials om de sessie in stand te houden, is er een overeenkomst nodig.

Uiteraard gaat dit allemaal met toestemming van de persoon die de gegevens invult. Een felle disclaimer met duidelijke vermelding dat de dienst niet ondersteund is door de andere partij is ook op zijn plaats. Kortom: De gebruikers weten dat het een aanvullende dienst is van een externe partij. Deze gebruikers WILLEN de aanvulling gebruiken, omdat het hun tijd bespaart.

Een goede vergelijking zou zijn: Stel dat een Uber-chauffeur automatisch wordt gekoppeld aan klanten binnen x KM met een minimale rit van bedrag € y. _{(Ik ga ervan uit dat dat niet het geval is)}

Zou Uber zoiets (op strategisch niveau) erg vinden? De gebruikers in iedergeval zeker niet.

[Malfunctions]

Dat lijkt me nou net geen goede vergelijking omdat je daarmee inbreuk maakt op de positie van Uber zelf.

Om het maar niet te hebben over dat iets dergelijks enkel voordelig is vanuit het perspectief van de chauffeur en niet voor de klant. Die wordt namelijk zijn keuzevrijheid ontnomen.

[Barrycade]

Vraag me alleen af of de originele diensten aanbieder wat over misbruik / gebruik van de API in zijn voorwaarden heeft staan.

Als daarin wat staat over Misbruik/ Fair Use overschrijding / Gebruik van de website staat.

Want dan zouden de klanten zelf ook problemen kunnen krijgen als ze tooltje van TS gaan gebruiken die blijkbaar een eenzijdig voordeel oplevert voor de klant (en dus niet direct voor de aanbieder).

[Yucon]

.

[ Voor 99% gewijzigd door Yucon op 25-12-2017 20:35 . Reden: pagina 2 niet gezien.. ]

[GlowMouse]

Barrycade schreef op maandag 25 december 2017 @ 15:08:
Vraag me alleen af of de originele diensten aanbieder wat over misbruik / gebruik van de API in zijn voorwaarden heeft staan.

Als daarin wat staat over Misbruik/ Fair Use overschrijding / Gebruik van de website staat.

Zelfs als die voorwaarden bestaan, is het de vraag is of zulke voorwaarden als onredelijk bezwarend vernietigbaar zijn. Voor banken wordt het heel normaal dat derden via api's acties uitvoeren. De aanbieder zal een goed verhaal moeten hebben waarom acties niet geautomatiseerd uitgevoerd mogen worden (de serverload is geen argument omdat de dienst van TS het totaal aantal aanvragen juist reduceert).

[jeanj]

Banken worden gedwongen door regel of wetgevimg on derden toegang te gaan geven. Echter zo iets heeft ook negatieve kanten, zie het voorbeeld van de energie markt. De gegevens van gebruikers hebben al twee keer op straat gelegen.

Ja je kan leuke diensten ontwikkelen, echter de beveiliging is zo sterk als de slechte schakel, en er komen een heleboel schakels erbij.... Daarnaast zal de druk om de gegevens "vrijwillig" te delen worden vergroot, omdat je toch niets hebt te verbergen....

Terug OT, zoals de artikelen van Arnoud aangeven, reverse engineren mag binnen voorwaarden, daar zit denk ik niet het probleem. Het probleem zit hem meer in het databanken recht. Echter zomder meer informatie over de orinele dienst, is dat moeilijk te beantwoorden. Ook het privacy aspect hangt van de implementatie af.

Verder geef je aan dat de orginele dienst niet "gehoorzaamd" deze functionaliteit te implementeren. Misschien is het een bewuste keuzen van hen, om meer traffic te generen of gaan ze zelf aanvullende betaal diensten implementeren. Hebben ze toegelicht waarom dit niet willen implementeren?