Runkeeper: delen van data kwam door bug

Volgens Runkeeper verstuurde zijn Android-app per ongeluk locatiegegevens naar een derde partij als de smartphone niet in gebruik is. De Noorse consumentenbond diende daar vorige week een klacht over in. De bug zou inmiddels verholpen zijn.

Uit onderzoek van Runkeeper zelf, naar aanleiding van de Noorse klacht, kwam de bug aan het licht, aldus het bedrijf. De weeffout betrof de integratie van de advertentiedienst van een derde partij. De app kon bij draaien op de achtergrond ontwaakt worden door bijvoorbeeld pushnotificaties en door de bug zou de app in die gevallen onbedoeld gps-data doorgeven.

Runkeeper heeft daarop een nieuwe versie van zijn Android-app uitgebracht waarin de betreffende advertentiedienst helemaal niet meer zit. Hoewel de bug volgens het bedrijf niet in de iOS-versie zit, is ook bij die app de dienst verwijderd. Die vernieuwde app komt beschikbaar zodra Apple deze heeft goedgekeurd.

De Noorse consumentenbond Forbrukerrådet legde vorige week een klacht neer bij de privacyautoriteit van het land over de handelwijze van de populaire jogging-app. Volgens de bond zou onderzocht moeten worden of hiermee geen Noorse en Europese privacyregels gebroken worden. Uit de klacht en het bijbehorende onderzoek van de bond uit februari wordt niet duidelijk of destijds contact met Runkeeper is opgenomen over het delen van de data.

Reacties (68)

[defixje]

Ze zullen wel gedacht hebben "Google komt er mee weg, dus kunnen die smoes ook wel gebruiken".

Ik neem aan dat je eerst alles uitgebreid test voordat je het in de store zet. Dat dit een bug geweest zou zijn komt bij mij erg ongeloofwaardig over, omdat je een background proces moet proggen om het te laten werken als de app niet in gebruik is. Dus dat is geen bug maar een bewuste toevoeging.

Maar ja ze moeten wel wat verzinnen natuurlijk, redden wat er te redden valt.

[Reactie gewijzigd door defixje op 23 juli 2024 01:36]

[The Lord]

Dat gevoel van de smoes kreeg ik ook.

Het volledig verwijderen van de advertentie code kan er ook op wijzen dat dit alles in die code zat verpakt en in één keer mee is gecompileerd.

Dat lijkt mij net zo goed laakbaar; een stuk code toevoegen zonder goede review is nog steeds de verantwoordelijkheid van Runkeeper. Zodoende ook het (al dan niet bewust) lekken van de locatiegegevens.

[Verwijderd]

Opzettelijk of slecht programmeerwerk?

Maar wat verwachten we er van, in een wereld waarin bijvoorbeeld Pechtold van D66 meent dat we geld verdienen door innovatief te doen. Ofwel, hij is gek op 'start-ups'. Dus we moeten faciliteren in en rond het onderwijs dat jongeren leren programmeren. We moeten allemaal app-bouwers worden in een economie waar een vaste baan zeldzamer wordt en met allerlei schnabbels ons geld verdienene.

Wat je dan krijgt is een start-up van een paar jongens die de fiets led-verlichting willen geven die te programmeren valt me boodschappen. Alles en iedereen kan iets verzinnen en een gat in de markt schieten. Er is altijd wel iemand die er het nut van inziet...

En dan is dus de vraag, al die gozertjes die zich al helemaal rijk wanen met hun app-idee in een of andere 'store', kunnen die wel goed programmeren? Of is het allemaal min of meer in elkaar geflanste troep.

En als je in elkaar geflanste troep in een genetwerkt gadget propt, wat verwacht je dan van de resultaten?

Maar dit is toch wat we willen? Allerlei apps voor de meest vreemde niches? En dat allemaal op tablet en smart phones en health gadgets.

Ik maak me al vanaf het begin zorgen over de informatie die een smart watch opneemt. Je hartslag, route, locatiegegevens. Medische gadets die je slaap tracken, het lijkt allemaal zo leuk.

Er is een Guust strip waarin Guust een opname maakt van zijn eigen slaap zodat ie het later terug kan luisteren, of ie wel lekker geslapen heeft. Wie had ooit gedacht dat dit geen grap was?

Dit is mijn probleem met te veel informatoe genereren uit je eigen leven. Je datamined jezelf, en omdat alles aan internet hangt, via een of andere cloud van je smart watch, is er een onmiddelijk beveiligingsprobleem.

Pacemakers die draadloos benaderd kunnen worden... Insuline apparaten... Er is geen grens aan wat men draadloos wil doen. Hier zie je het probleem. En dit geval gaat nog herhaald worden.

Big Data geilt er nu al op om velden in de spreadsheet toe te kunnen voegen over je gezondheidstoestand...en verzekeraars zullen die info graag kopen. Allemaal in je eigen voordeel uiteraard, wat double speak is voor hun voordeel. Want zo kunnen ze aan het equivalent werken van social engineering, ofwel, voor elke klant een custom-verzekering. Je betaald minder premie als je hardloopt en je resultaten in hun cloud zet. Maar het voordeel zal vooral zijn voor henzelf.

Wie van nature geen sporter is en op termijn, geen smart watch heeft, die betaald relatief meer premie, net als er onderscheid is op basis van de postcode check zoals laats op tv was, waar je ineens veel meer blijkt te betalen in dezelfde straat voor een verzekering.

En dus, ook hier kan ik de vraag beantwoorden hoe ik dan de dans ontspring van het niet meegaan in dit soort zaken. Ik heb geen smart watch en ik gebruik geen cloud diensten. En op een dag kost me dat geld, maar op een dag blijkt ook er een hack of bug in software te zitten waardoor informatie op straat ligt. En daar ontsnap ik dan alvat aan, met vooruitwerkende kracht.

En wie zegt nu dat ik niet vooruitdenkend ben?

[MiNi1993_NL]

Aan de andere kant hebben we ook veel aan die technologie te danken. Patiënten die worden gebeld om naar het ziekenhuis te komen ivm een defecte pacemaker. Dat soort zaken kunnen je leven redden!

Maar dan ben ik benieuwd hoe je hier op de site komt, vast middels onion routing? Alle veligheid is uiteindelijk schijn, ik denk dat we ons daar uiteindelijk overheen moeten gaan zetten. Met al onze smartphones delen we al meer informatie dan we zelf doorhebben, maar het bied ons dan ook wel weer een hulp in veel verschillende zaken.

Ik ben het met je eens dat je goed moet nadenken welke data je wel of niet opslaat. Maar we gaan ook steeds verder met the internet of things, no way dat onze informatie "van ons" blijft in de komende 10 jaar.

[i-chat]

Dat gevoel van de smoes kreeg ik ook.

Het volledig verwijderen van de advertentie code kan er ook op wijzen dat dit alles in die code zat verpakt en in één keer mee is gecompileerd.

Dat lijkt mij net zo goed laakbaar; een stuk code toevoegen zonder goede review is nog steeds de verantwoordelijkheid van Runkeeper. Zodoende ook het (al dan niet bewust) lekken van de locatiegegevens.

de vraag is dan of het dan wel strafbaar is, maar als we dan toch gaan vragen naar strafbaarheid, waarom zoeken ze nu pas uit, heeft deze consumentenbond (om meer zieltjes te winnen) besloten om eerst een klacht bij de privacy authoriteit te deponeren in plaats van bij het bewuste bedrijf, of hebben ze alleen maar een belletje gedaan bij een calcenter die hier helemaal geen protocol voor heeft... en dus ook niet kon weten we ze moest doen...

kortom: eerst maar eens laten uitzoeken wat er nu prcies loos is voor we met modder en hete pek gaan smijten.

[The Lord]

de vraag is dan of het dan wel strafbaar is

Onder Nederlands recht is dit in principe nog een vraag; voor zover ik weet is er geen jurisprudentie over een gelijk geval. Desondanks acht ik de kans heel groot dat de AP in een dergelijk geval een flinke boete op kan (en na juni zal) opleggen als duidelijk is dat er onvoldoende aandacht aan code review is geschonken.

heeft deze consumentenbond (om meer zieltjes te winnen) besloten om eerst een klacht bij de privacy authoriteit te deponeren in plaats van bij het bewuste bedrijf, of hebben ze alleen maar een belletje gedaan bij een calcenter die hier helemaal geen protocol voor heeft... en dus ook niet kon weten we ze moest doen...

Zonder een idee te hebben of het bij het bedrijf is gemeld: onder Nederlands recht hoef je het niet bij het bedrijf te melden. Het is natuurlijk wel aardig om dit in eerste instantie ook te doen. Geen protocol staat hier gelijk aan je zaken niet op orde hebben; zodoende voldoe je niet aan de wet.

[YGDRASSIL]

Dat ze veel meer locatiegegevens doorkregen dan normaal viel natuurlijk ook niet op. Duh

[Bor]

omdat je een background proces moet proggen om het te laten werken als de app niet in gebruik is. Dus dat is geen bug maar een bewuste toevoeging.

Heb je het artikel wel gelezen? De uitleg staat notabene in het bericht van Runkeeper zelf;

..found a bug in our Android app involving the app’s integration with a third-party advertising service. Like other Android apps, when the Runkeeper app is in the background, it can be awakened by the device when certain events occur (like when the device receives a Runkeeper push notification). When such events awakened the app, the bug inadvertently caused the app to send location data to the third-party service.

Er is dus helemaal geen background service geprogrammeerd om dit te doen maar bepaalde andere runkeeper events hebben onterecht een trigger gegeven waardoor de locatie data werd verstuurd.

[defixje]

Heel leuk dat ze dit verzinnen, maar het ging er niet om dat na een push bericht pas werd verstuurd maar constant data heen en weer ging.

Hun uit leg strookt totaal niet met de waarheid, want dan zou sporadisch data verstuurd worden na een push bericht. Dit was niet het geval, het geval was dat elke x minuten er locatiegegevens verstuurd werd.

Zie ook het rapport:

Runkeeper:

• Runkeeper contains many third-party trackers. These trackers have access to important information about the phone and its user, such as the device identifier.
• Runkeeper sends the GPS position to kiip.me, which is a third-party tracker.
• Runkeeper tracks the GPS position even when the phone is not in use (see the 48h analysis: see section 19)

Dus om op je vraag te antwoorden, ja ik heb het artikel gelezen, en nee het berust niet op de waarheid.

[Bor]

De nuance zit in de "like"

...like when the device receives a Runkeeper push notification.

Het gebeurt dus blijkbaar bij meer triggers dan alleen een push notificatie. Zonder meer achtergrond informatie kun je de conclusies die jij trekt simpelweg niet trekken.

[Reactie gewijzigd door Bor op 23 juli 2024 01:36]

[defixje]

Ik heb wel meer achtergrond informatie, want ik heb het hele rapport gelezen. Helaas is die niet meer online beschikbaar, maar ik kan je verzekeren dat dit een open socket was met calls die elke x minuten werden getriggerd. Dus niks geen push, of andere trigger. Maar een bewuste toevoeging aan de app.

[sfc1971]

alles uitgebreid test

Iedere programmeur: Ja zeker!

Ik doe nu al 18 jaar ontwikkeling en al die jaren loop ik al tegen projecten aan waar eigenlijk niemand echt weet wat de hele applicatie doet. Niet van piep kleine web shops, wordt die PDF met voorwaarden nou wel of niet mee gestuurd tot enorme applicaties van internationale bedrijven waar geen enkele index was geplaatst op een gloednieuwe database. Ik heb databases moeten uitpluizen door in de applicatie een waarde te veranderen en dan een diff te draaien op de dump om maar uit te vinden waar een waarde werd opgeslagen omdat niemand het meer wist. Persoon database, Sofi nummer is een unieke sleutel... met duplicaten... ooopsje, ontdek ik daarom zomaar even fraude op vrij grote schaal als junior.

Nee, alles getest?

Bugje? Nee, dit is moedwillig geplaatst ooit maar heel goed mogelijk dat het erdoor heen is geglipt in een momentje van de rechter hand weet niet wat de linker hand doet.

[defixje]

Ik doe nu al 18 jaar ontwikkeling en al die jaren loop ik al tegen projecten aan waar eigenlijk niemand echt weet wat de hele applicatie doet.

Nou dan heb je in die 18 jaar niet veel geleerd? Ik neem aan dat je als Senior dan werkt, dus in mijn ogen heb je dan ook de verantwoordelijkheid aan te geven dat er wat processen veranderd dient te worden bij de klant/werkgever.

De websitejes daargelaten, maar applicaties zonder CR of Testing is gewoon uit den boze, vooral als je het hebt over applicaties met gebruikersgegevens. Dan is het gewoon schandalig, als je dat niet eens op orde hebt.

[Powermage]

Testen is leuk en gebeurt best wel vaak, maar dan nog.

Bedrijf A heeft ooit door bedrijf B software laten ontwikkelen, vervolgens omdat het niet goed ging heeft C de ontwikkeling overgenomen en het fors doorontwikkeld totdat C failliet ging, waardoor partij E het ontwikkelwerk heeft over genomen.

Wat denk je, dat in een vrij forse applicatie Partij A dan heel veel geld naar partij C schuift om elke stuk code door te pluizen of dat het gewoon door ontwikkeld as-needed word en er soms nog hele gekke dingen uit de kast komen?

[servies]

@defixje
In theorie: een absolute JA

In de praktijk is het vaak:
"Nee, het moet nu in gebruik worden genomen, dat testen gebeurt dan wel live"
"Functionaliteit beschrijven? Waar denk je dat je voor betaald word, dat wordt toch nooit gelezen / die code beschrijft zichzelf wel..."
"Testen? Het compileert toch, en voor grondig testen is geen budget beschikbaar, dat wordt te duur / daar wilde de klant niet voor betalen"
etc. etc. etc...

[Reactie gewijzigd door servies op 23 juli 2024 01:36]

[sfc1971]

Nou dan heb je in die 18 jaar niet veel geleerd? Ik neem aan dat je als Senior dan werkt, dus in mijn ogen heb je dan ook de verantwoordelijkheid aan te geven dat er wat processen veranderd dient te worden bij de klant/werkgever.

Tja, of ik doe dit, ruim de boel zo goed mogelijk op en pak dan weer een nieuw project op?

Dit waren allemaal verschillende projecten voor verschillende opdrachtgevers.

Zou inderdaad vrij slecht zijn als ik al 18 jaar bij het zelfde bedrijf aan het zelfde project werkt en dit nog steeds voorkwam.

[anboni]

Wat heerlijk naief

De praktijk is gewoon dat zaken als testen en quality control ondergeschoven kindjes zijn. Dan kun je als senior 1000 keer aangeven dat de processen niet op orde zijn, als de opdrachtgever vindt dat het geen prioriteit heeft houdt het gewoon op.

[Apache]

Dat begint toch wel best te veranderen. Maar om eerlijk te zijn, die verandering moet van bij de developers komen.

Management heeft nu eenmaal helemaal andere doelstellingen dan een developer. Een developer moet op een hele deftige manier software opleveren. Maar laat (hopelijk liet) zich vaak overtuigen door simpele zinnetjes als: "kan dat echt niet sneller?" en dan antwoord die vaak braaf: "ja, maar ..." en vanaf de "ja" is de manager al tevreden. Het is op zich niet fout om nee te zeggen op dat moment.

Opleveren zonder testen is immoreel. Van mijn laatste 3 grote projecten waren er 2 met vanaf het begin 100% testcoverage afgedwongen op de relevante modules. Ja, eigenlijk is alles relevant. Maar het domein, de applicatie laag, kan allemaal relatief eenvoudig getest worden. En alles van integraties met andere systemen zit in de infrastructuur laag en kan je in die testen wegmocken. Hoe het sap systeem zich gedraagt, hoe die rest service van het andere systeem je informatie teruggeeft. Ook wel de decorruption layer genoemd.

Als je technisch alles juist steekt qua architectuur (clean architecture, hexagonal architecture, allemaal hetzelfde), en nog makkelijker, je testen gewoon eerst schrijft, zodat je weet wat je eigenlijk verwacht voor je de implementatie maakt, zouden heel wat projecten veel beter lopen. Managers zeggen nee, dat kost teveel geld, al die tijd in testen steken. Die win je enorm snel terug, die kost is gewoon hidden als je het niet hebt gedaan. Constant bugfixes, lopen klooien, hier iets aanpassen, daar breekt het ...

Geen testen schrijven is immoreel. En vragen of je mag testen MOET zelfs niet. Als ik morgen iemand over de vloer krijg die mijn keuken komt installeren dan moet die mij toch niet komen vragen of hij zijn black en dekker mag gebruiken, of dat ik liever heb dat die zijn makita bovenhaalt. Die jongen moet mijn keuken installeren, en dat moet echt fancy spancy zijn aan het eind van de rit zodat ik die keuken met plezier 20j kan gebruiken.

Dit boek is een enorme aanrader. En hopelijk komt daarmee het besef dat agile vooral draait om de processen, hoe we dat invullen qua ontwikkeling hebben we ook nog een beter en professionelere aanpak nodig, en dat wordt imho ingevuld door software craftsmanship.

[Kefke]

Dat begint toch wel best te veranderen. Maar om eerlijk te zijn, die verandering moet van bij de developers komen.

Tja, ik wil wel testen, maar als de projectmanager alles zo goedkoop mogelijk wil houden om te kunnen concurreren met andere bedrijven en daarom te weinig tijd voorziet om te testen kan ik dat wel aankaarten, maar uiteindelijk zal het er toch op neer komen dat we slechts enkele dingen testen en niet alles.

[Apache]

En daar komt agile dan weer bij kijken. De project manager moet developers niet lastig vallen met "details" als budget etc die bij zijn job horen. Die moet het team opvolgen, barrieres uit de weg ruimen, en dan kijken naar hoeveel story points levert het team op op 1 sprint, dat 3 sprints lang meten, een velocity berekenen (of in jira kijken) en dan gewoon rapporteren hoe lang het hele project ongeveer zal duren. (wat ook continue opnieuw ingeschat zal worden, story per story met de kennis die het team opdoet).

Een project manager is niet meer dan een boekhoudster. Die maakt de rapportering en geeft advies. Zij beslist niet welke uitgaven gemaakt gaan worden. Dat doet de zaakvoerder.

[Kefke]

En daar komt agile dan weer bij kijken. De project manager moet developers niet lastig vallen met "details" als budget etc die bij zijn job horen.

Ach, ik heb al zo veel softwareontwikkeling methodes zien passeren die allemaal beloven dat ze dit probleem gaan oplossen, maar uiteindelijk komt het er toch altijd op neer dat één of andere manager eist dat alles sneller en goedkoper moet en we moeten besparen op testen, want ik als ontwikkelaar heb niks te zeggen over het budget.

[LuCarD]

Onzin. Testen maakt programmeren niet duurder. Ik denk zelfs dat het goedkoper wordt. Al onze nieuwe services en frontends hebben een test coverage van 100% inclusief JS. Daarnaast hebben we nog wat integratie testen om te kijken of alle componenten wel met elkaar werken. We missen alleen nog een goede coverage van acceptatie testen, die is bij ons beperkt.

Dit zorgt ervoor dat wij wijzigingen snel en veilig kunnen doe. Totale kosten zijn imho uiteindelijk lager

[Gorefest]

100% testcoverage is gewoon niet mogelijk.
Testing only detects the precense of bugs, not the absence.

Ben het met je eens dat je een goed begin het halve werk is.

[Apache]

100% testcoverage is natuurlijk inderdaad niet meer dan checken dat elke regel code ooit 1x gehit is in een test. Dat is inderdaad nog iets anders dan alle code paths die door je applicatie lopen. Maar als je elke unit op zich al elk pad test. En je doet dat voor de andere componenten ook. Als je die aan mekaar knoopt mag je wel een aardig getest resultaat verwachten.

[BitJager]

Idd als de opdrachtgever er niet wil in investeren sta je met je rug tegen de muur. Je zou er van schrikken hoeveel grote namen hier nog steeds het nut niet van inzien en 't is allemaal leuk en aardig tot er eens iets fout gaat en staan ze aan je bureau met de vraag van hoe dit toch in godsnaam mogelijk is.

De kalmte bewaren op zo een momenten is een kunst.

[Verwijderd]

Kun je me een lijstje geven van 'goede bedrijven'? Ik ben nog op zoek! De discussie over kwaliteit en prioriteit wordt in elk IT bedrijf gevoerd tussen management en seniors en daarbij is er maar 1 partij die uiteindelijk beslist. De waarheid ligt zoals altijd in het midden. Management maakt een risico afweging en dus kosten/baten afweging. 'Goede bedrijven' maken goede afwegingen en dan nog zal dus nooit alles uit en te na getest worden, immers kost manuren (=de duurste resource van een IT bedrijf). In dit geval is het afbreukrisico lijkt mij glashelder en lijkt het er idd op dat hier moedwillig een keuze is gemaakt om regels te overtreden. Maar goed dat is aan de rechter. Verder is het natuurlijk PR en communicatie die hier nu een mooie draai aan moet geven in de publieke opinie, want er moet wel geld verdient worden.

[Finraziel]

Waar zie jij iemand klagen? Ik zie volgens mij alleen mensen die uitleggen dat in de praktijk er vaak niet zo uitvoerig getest wordt als dat je graag zou willen. Dat is geen klagen, dat is gewoon aangeven hoe het in de praktijk vaak werkt. Ergens anders gaan werken en net doen alsof het niet bestaat en vervolgens op een forum gaan verkondigen dat er altijd getest wordt, dat is pas raar...

[Tha_Butcha]

Als je werkt, betaalt je baas het salaris. Dat salaris komt van de opbrengsten van het bedrijf. Het bedrijf genereert die opbrengsten d.m.v. klanten...

[Vexxon]

Precies hetzelfde wat ik dacht. Er zit wat mij betreft niets anders op dan experts naar de code te laten kijken om te beoordelen of het inderdaad om een bug ging.
Precies de reden waarom ik steeds mi der apps gebruik en vooral terugga naar de browser met de juiste plugins.

[Reactie gewijzigd door Vexxon op 23 juli 2024 01:36]

[himlims_]

sowieso; de meeste apps bieden vaak minder of beperkte functionaliteit tozv de website. toch 'moeten we een appje'

[acemoo]

Dat lijkt me niet echt relevant voor runkeeper, volgens mij kan je er heel wat dingen mee dat niet met de website kan.

[himlims_]

doorgeven van adresboek, foto's etc. lijkt me ook niet heel relevant voor een hardloop app.

[acemoo]

Sociale interactie.
Zorg ervoor dat al je vrienden kunnen zien dat je bezig bent. (foto's + adresboek)
Onderling wedstrijden houden (adresboek)

[Xaverius]

Ik vind het meenemen van een telefoon al onlogisch bij het hardlopen om je route te registreren, laat staan dat je een laptop of desktop moet meenemen hiervoor (zonder GPS)... Oh, wacht...

Ontopic, of die bug er nu met opzet in zat of niet, hij is er nu uit. En er is misschien wat meer bewustzijn gecreëerd over de mogelijkheden van een app wat je eigenlijk niet wil hebben.

[Stoelpoot]

Of het was gewoon echt een bug Op zich is het geen scenario waar je snel aan zal denken tenzij er echt een team achter zit die dit soort dingen gaat zoeken zoals nu. TheAppDoesNotSendGPSDataWhenAwokenInBackgroundTest klinkt als een erg obscure en onwaarschijnlijke Unit Test.

[Zezura]

Nee valt wel mee, apple heeft bijvoorbeeld, een paar mooie tools waarbij je dit allemaal snel en gemakkelijk kan meten.
Waarbij je cpu, memory, energy, gpu, netwerk en nog vele andere.
Daarmee kan je dus meten en bijhouden hoe je app draait en wat het doet.
En zo iets moet opvallen, zeker in de achtergrond, dan zou je moeten zien dat het actief word, en dat er een bepaald process draait of waarbij locatie/gps ineens inschakelt.

Een goede programmeur heeft een debug build met output naar console op belangrijke punten, waaraan hij kan zien wat er gebeurd en welke exit er wordt gebruikt in een functie of constructie.

[Zezura]

Het feit dat ze het ineens helemaal doen verwijderen vind ik een verdachte keuze,
waarbij ik het gevoel heb dat ze dit juist bewust deden.
Nu ze betrapt zijn natuurlijk verwijderen want nu kunnen ze het niet meer gebruiken.

Als het een gewoon normaal advertentie platform was geweest hadden ze de bug hersteld.
het helemaal verwijderen helpt juist mee om het verdacht te maken.

[Reactie gewijzigd door Zezura op 23 juli 2024 01:36]

[Verwijderd]

Je kan beter liegen dan de waarheid vertellen want anders krijg je claims aan je broek.

[Adimeuz]

En dat is precies de instelling die deze wereld zo verrot maakt. Heb je willens en wetens gegevens doorverkocht (zal de toekomst wellicht uitwijzen) zonder toestemming, dan mag je mijns inziens met de billen bloot. Dat hele verdraaien van de werkelijkheid, ver-schri-ke-lijk!

[Bor]

Je gaat er gemakshalve dan wel vanuit dat men opzettelijk de feiten verdraait. Er is geen aanwijzing dat dit het geval is. Bovendien zou het aantal claims veel groter zijn wanneer dit soort zaken aan het licht komen en men niet reageert of hierover liegt.

[Bor]

Erg jammer dat men niet meer openheid van zaken geeft.


- Wat is er nu precies verstuurd en naar wie.
- Is de data bij de 3rd party opgeslagen en verwerkt?
- Hoe lang wordt de data daar opgeslagen?
- Heeft men er alles aan gedaan om de 3rd party over te halen om de data te vernietigen?
- Waarom is dit niet tijdens bijvoorbeeld een audit of software review naar boven gekomen?

Zo zijn er meer vragen waarop geen, of een vaag antwoord komt. Juist in dit soort gevallen is openheid van zaken erg belangrijk! De communicatie is nu wel erg karig. Dit schept geen vertrouwen na een incident als deze.

[Reactie gewijzigd door Bor op 23 juli 2024 01:36]

[Aeternum]

"Waarom is dit niet tijdens bijvoorbeeld een audit of software review naar boven gekomen?"
Dat is denk ik afhankelijk van de test procedure... als het allemaal unit testing is en geautomatiseerd, wat ik me goed voor kan stellen. Dan merk je dat soort dingen niet op.

[Stoelpoot]

Hoe bedoel je? Elke app heeft toch een TheAppDoesNotSendUserDataWhenAwokenInBackGroundTest Unit Test? Nee, dit vind ik inderdaad in een standaard testprocedure ook een logisch oversight. Hier zijn echt teams voor nodig zoals nu is gebeurd die dit soort dingen analyseren. En binnen een bedrijf kost dat tijd en geld, wat het in werkelijke resultaten waarschijnlijk niet waar kan maken als er ook geautomatiseerd wordt getest wat de meeste bugs er wel uit haalt.

[5pë©ïàál_Tèkén]

Ai, pijnlijk dit. Je kan met veel rottigheid wegkomen, mits je intrinsiek je verantwoordelijkheid neemt. Meteen gaan wijzen naar een van je partners (waar zij uit financieel belang mee in zee gingen) en die dan de zwarte piet toespelen klinkt als verantwoordelijkheid afschuiven. Dit is totaal ongeloofwaardig omdat zij zelf verantwoordelijk zijn voor de app (ook voor hetgeen ze uitbesteden) en omdat ze aan deze bug verdienden.

Ik hoop dat Runkeeper hier niet mee wegkomt but then again - hoe juridisch strafbaar is wat er hier gebeurd? Er wordt in de EULA/ToS gemeld dat er data wordt verzameld en verstuurd. Alleen gebeurt dit meer dan gemeld. Dat is iets anders dan iets niet vermelden in de EULA/ToS en het vervolgens wel doen. Bij het eerste gaat het om de mate waarin data wordt verzameld (waar de gebruiker toestemming voor heeft gegeven), bij de tweede gaat het om wel/niet verzamelen.

[polthemol]

als je meer verstuurd dan wat in je EULA staat vermeld, dan komt het op hetzelfde neer als dat je iets verstuurt zonder het te vermelden in de EULA Je bent dingen aan het doen die niet in de EULA staan en waar de user geen akkoord op heeft gegeven.

De vraag is of een user / consumentenverengiging / noem maar op, zin heeft om daar een rechtzaak over te gaan voeren. Dat is imo ook het geniepige: je kunt je er heel moeilijk tegen verdedigen, simpelweg omdat je geen resources hebt.

[casparvl]

Volgens mij is dit een hele mooie manier om de aandacht af te leiden van wat echt telt, namelijk: wie is er verantwoordelijk? Zeggen dat er een 'bug' in je software zat, is zoveel als zeggen 'het was per ongeluk'. Dat klinkt heel onschuldig, maar als ik met een voetbal per ongeluk de ruit van de buurman in schiet, ben ik nog steeds verantwoordelijk en moet ik die vergoeden.

Of het juridisch ook zo werkt weet ik niet, maar wat mij betreft is runkeeper gewoon verantwoordelijk voor zijn eigen app, inclusief eventuele bugs en kunnen ze wel degelijk verantwoordelijk gehouden worden voor het niet correct afhandelen van deze data. Wat de gevolgen daarvan zouden moeten zijn laat ik in het midden, maar ik kan mij voorstellen dat privacy-autoriteiten wellicht bestuurlijke boetes op kunnen leggen?

[Timfonie]

Exact. Er zouden juridische regels moeten zijn die datalekken hoe dan ook bestraffen, of ze nou moedwillig of per ongeluk veroorzaakt zijn. In het laatste geval kan de straf wel een stuk lager zijn, maar zeker nog voldoende om er voor te zorgen dat bedrijven/ontwikkelaars extra aandacht besteden aan het bewaken van privacy.
Vergelijk het met het verschil tussen moord met voorbedacht rade versus dood door schuld.

[blurryilluzion]

Sja, of het waarheid is of gewoon een goed bedacht excuus weten we niet. Maar wel netjes dat het direct wordt opgepakt: De app gewoon weg uit de stores tot er een nieuwe versie is.

[Reactie gewijzigd door blurryilluzion op 23 juli 2024 01:36]

[Marty007]

Dat weten we wel... think about it..

[dennissimeau]

Yeah Right.
Lijkt me toch wat meer code nodig dan alleen je advertentiedienst integreren om ook locatiegegevens naar specifieke 3rd party adverteerders te sturen.

[dehardstyler]

Dit verhaal heeft natuurlijk alle schijn tegen, maar het zou eventueel waar kunnen zijn. Wel een hele vervelende bug en gelijk een deuk in het vertrouwen. ( Wat natuurlijk al vrij miniem is, als je ziet welke gegevens gevraagd worden. )

[OrangeTux]

Dit was voor mij de aanleiding mijn abbonnement bij Runkeeper op te zeggen. Ik ben overgestapt naar MeeRun. Deze app heeft een heldere, korte privacy policy. De app is offline te gebruiken. Data synchroniseren met hun servers is optioneel en gebeurt alleen na expliciete toestemming. Ik heb de uitgebreide versie van de app, kost iets van 5 euro, een aantal keer gebruikt en die bevalt me prima.

[pven]

Op Runkeeper-HQ: 'K*T! Ze hebben het ontdekt! Wat nu !? .. Oh, doe als Google en zeg dat het een bug is'