GitHub-gemeenschap reageert zeer kritisch op toevoeging telemetrie aan Audacity

De GitHub-gemeenschap rond de opensource-audiobewerkingsprogramma Audacity is niet te spreken over de toevoeging van telemetrie aan het programma. Het gaat om een opt-in, hoewel een dark pattern gebruikt wordt om gebruikers over te halen.

De telemetrie verzamelt de variabelen ip-adres, sessiestart en -einde, foutmeldingen, gebruikte bestandstypen, os- en appversie en gebruik van effecten, generators en analysetools. De developers maken gebruik van Universal Google Analytics en Yandex Metrica. Dat omdat die eerste 'wat hele strenge quota heeft'.

De ontwikkelaars onderstrepen dat de telemetrie alleen werkt in de builds die door de Github-CI gemaakt worden op basis van de officiële repository en dat er voor wie vanaf de source compileert speciaal een CMake-optie komt om de telemetrie-code bij te voegen, dus dat gaat ook om een opt-in. Ook zeggen ze dat ze niet aan cross-site tracking doen en dat ze overwegen om Google en Yandex te vervangen door een andere dienstverlener die 'aan onze eisen voldoet'.

De makers stellen dat ze momenteel geen informatie hebben over stabiliteit per platform en hoe groot de userbase is, waarbij telemetrie juist kan helpen. Ook kunnen ze 'geen goed geïnformeerde beslissingen maken over welke platformen te ondersteunen' en hebben ze bij bugs geen goed idee van de schaal waarop deze voorkomen.

De reacties onder de bekendmaking zijn voor de overgrote meerderheid negatief. Wat betreft emoji-reacties op de extra post over telemetrie, daar is meer dan 3000 keer met een duimpje omlaag gereageerd en 180 maal met een duimpje omhoog. Enkele gebruikers roepen dat het naar aanleiding hiervan tijd is voor een fork van de software. Audacity werd nog geen week geleden overgenomen door Muse Group, het bedrijf achter Ultimate Guitar.

Telemetrie Audacity

Door Mark Hendrikman

Redacteur

08-05-2021 • 12:44

160

Reacties (160)

160
156
93
13
1
33
Wijzig sortering
Ik moest even Googlen

What is dark patterns?
A dark pattern is "a user interface that has been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.".
https://en.wikipedia.org/wiki/Dark_pattern
Ben zelf UX designer bij een groot bedrijf, heb hier (helaas) al meerdere discussies gehad of het 'moreel te verantwoorden was' om een dark pattern te hanteren voor het eigen gewin. Denk aan betalingen, waarbij de optie 'eerder uitbetalen' a 2% fee standaard is geselecteerd in plaats van het reguliere betaaltermijn.

Uit onze analyses blijkt ook dat het merendeel vrij snel doorklikt, zonder exact te lezen wat ze nou selecteren. Het is niet voor niets dat de UX researchers allen een master in de psychologie hebben afgerond, niet alleen om jou als gebruiker te begrijpen kan ik je vertellen.

In dit geval wordt de gebruiker wel degelijk verleid om op de primaire CTA te klikken, ze maken handig gebruik van de kleur. Het is natuurlijk wel discutabel om dit binnen deze context te voeren, valt wel onder de noemer 'niet bewust van wat ik doe' - omdat de primaire CTA eigenlijk altijd doorgaan is en men daar nou eenmaal snel op klikt.

Dit is mooi artikel hoe je misleid wordt: https://www.interaction-d...pics/sneaking-into-basket
Als je weet dat websites je dagelijks verleiden & misleiden met dark UX pattern(s), kan je hier ook bewuster op reageren. Hetzelfde als 2 zakken chips: actie! nu 2 voor €1,99 terwijl een zak normaal €0,99 kost.

[Reactie gewijzigd door steffeh op 25 juli 2024 03:09]

Dit is ook een punt waar in de wereld te weinig over gepraat wordt. We zijn mens, en wij als mens hebben door de evolutie heen bepaalde zaken geoptimaliseerd. Echter, sommige zaken en zwakke punten waren vroeger niet van levensbelang om te overleven.

De huidige samenleving verandert snel, we weten steeds meer over de mens. Je kunt daarmee twee dingen mee doen, goede dingen die de gehele mens ten goede komt. Of als individuele mensen / bedrijven deze zwakke punten exploiteren.

Het is als een zwak punt in de beveiliging in de computer die je kunt exploiteren. Het probleem met de mens: we kunnen niet zo ff onze emoties en onze diepe psychologische zaken even "updaten".

Is het ethisch verantwoord? En hoe leg je dit vast? Het probleem is dat ook hierdoor een grotere kloof komt tussen zwakker begaafde mensen en hoog opgeleide mensen die een lesje psychologie hebben gehad. Voornamelijk zie je dit terug in financiële keuzes, en misleidingen.

In principe valt het onder het hacken en exploiteren van menselijke psychologische zwakke punten.
Een mooier voorbeeld zou de 1+1 gratis acties zijn van de supermarkten en drogisterijen (Kruidvat helemaal). De producten zijn veel en veel duurder dan in andere landen. Als je over de grens eens kijkt, zoals bij Duitsland, heb je totaal andere prijzen.
Ik moet zeggen, het "Dark pattern" van dit toestemmingsdialoog is wel een van de meest lichte van de donkere patronen die ik heb gezien. Ze hebben de ja-knop klik-mij-blauw gemaakt, dat is het.

Niet eens de nee-knoptekst lichtgrijs gemaakt zodat het lijkt alsof je hem niet kan aanklikken, en ook geen scrollen of extra klikken nodig om nee te zeggen.

De goede korte samenvatting en de link naar de uitgebreide privacy policy direct in beeld, daar zouden veel apps een voorbeeld aan kunnen nemen.

Full disclosure: ik ben developer, dus ik ben me ook heel bewust van de voordelen van telemetrie, ook voor gebruikers.
Ik moet zeggen, het "Dark pattern" van dit toestemmingsdialoog is wel een van de meest lichte van de donkere patronen die ik heb gezien. Ze hebben de ja-knop klik-mij-blauw gemaakt, dat is het.
Dat klinkt misschien als een 'lichte' aanpak, maar het effect is niet mis; als je gaat meten hoeveel mensen op 'accepteren' klikken als die gehighlight is vs. hoeveel mensen dat doen bij op gelijke voet gepresenteerde opties, dan levert de gehighlighte aanpak een veel hogere ratio op.

Er is een reden dat deze techniek veel wordt gebruikt binnen de marketing, en gezien het effect kun je hem dan ook absoluut niet als 'lichte' techniek aanmerken, ondanks het aan de oppervlakte onschulding uitziende uiterlijk.
De goede korte samenvatting en de link naar de uitgebreide privacy policy direct in beeld, daar zouden veel apps een voorbeeld aan kunnen nemen.
Een van de kritiekpunten is nu juist dat de samenvatting onvoldoende is; Google en Yandex worden nergens genoemd maar zitten verstopt achter een linkje, terwijl dat nu juist een van de belangrijkere aspecten zal zijn in het maken van een beslissing. Dus nee, "goed" kan ik hem zeker niet noemen.
Full disclosure: ik ben developer, dus ik ben me ook heel bewust van de voordelen van telemetrie, ook voor gebruikers.
Die voordelen zijn een heel stuk beperkter dan ontwikkelaars graag willen geloven. Het is een beetje een versie-in-het-klein van de cult der statistiek; het geloof dat als je maar genoeg data verzamelt, je daar per definitie op statistische wijze een nuttig inzicht uit kunt halen. In de praktijk is dat niet het geval, en mis je dan doorgaans de menselijke factor, die cruciaal is om het grotere plaatje goed te begrijpen.

Omgekeerd kun je dan juist de beperkte inzichten van telemetry wel ook verkrijgen uit simpelweg met je gebruikers in gesprek gaan, en is telemetry dus vaak een nutteloze (en onnodig invasieve) toevoeging in de praktijk. Een van de weinige gevallen waar het wel nuttig is, is eigenlijk bij crash reporting.

Edit: Hier is een bron die hier wat verder op ingaat, van een gerenommeerd onderzoeksbureau.

[Reactie gewijzigd door svenslootweg op 25 juli 2024 03:09]

Omgekeerd kun je dan juist de beperkte inzichten van telemetry wel ook verkrijgen uit simpelweg met je gebruikers in gesprek gaan,
en is telemetry dus vaak een nutteloze (en onnodig invasieve) toevoeging in de praktijk. Een van de weinige gevallen waar het wel nuttig is, is eigenlijk bij crash reporting.
Simpelweg met je gebruikers in gesprek gaan is helaas verre van simpel (of goedkoop) in de echte praktijk. Zeker als je userbase wat meer dan 10 mensen is.

Succes met aan de CFO verkopen dat je een half callcenter voor een paar weken moet inhuren om uit te vinden hoe vaak gebruikers die ene knop echt gebruiken zodat je op basis daarvan beslissen of je die 10K regels buggy legacy code niet gewoon kan shift-deleten.

Een elastiek APM cluster ( ik wil geen reclame voor ze maken hier, ze zijn closed source gegaan) kan dat voor een paar tientjes per maand voor je beantwoorden.

Telemetrie is in mijn praktijk een lifesaver gebleken want de gegevens zijn accuraat, volledig, begrijpelijk, niet gekleurd door emotie of verborgen agenda's en daardoor zijn de bugs en performance issues (veel) makkelijker te vinden en te verhelpen.

En natuurlijk is het aan de ontwikkelaars om niet elke irrelevante poep en scheet te willen meten en die dan ook nog een eeuwigheid te bewaren. IMHO is dat namelijk het probleem, en niet telemetrie of de privacygevoeligheid van de nooit-zo-anoniem-als-je-zou-willen gegevens an sich.

Overigens is het artikel van Nielsen waar je naar linkt een artikel over UX/usability testen.
Dat is een heel nauw en specifiek gebruiksscenario van telemetrie gegevens. De meeste telemetrie wordt gebruikt uit hoofde van APM ( Application Performance Monitoring ) en dat is veel breder dan dat, je meet niet alleen of je features bruikbaar zijn voor de gebruiker, maar ook hoeveel die features kosten in termen van cpu, geheugen, netwerk bandbreedte etc, etc,...
In dit geval vind ik eigenlijk dat ze het heel netjes doen. Ja de 'doorgaan'-knop is benadrukt door de kleurstelling, maar de tekst in de knop geeft al direct aan dat je niet gewoon 'doorgaan' klikt.

Het feit dat de technische details achter een link zit vind ik niet zo bezwaarlijk, het blijft anders toch weer een discussie over welke details je in het hoofdscherm moet tonen.
"Netjes" zou zijn om geen enkele optie default te maken, en duidelijk te zijn over welke partijen de data ontvangen.

Dit is niet "netjes" - dit is "de bedoeling is nog steeds om mensen over te halen, maar we laten het netjes genoeg eruit zien dat andere mensen makkelijker kunnen doen alsof het probleem niet bestaat", en helaas trappen er weer genoeg Tweakers in. Dit ontwerp is damage control, niet privacy-first.

[Reactie gewijzigd door svenslootweg op 25 juli 2024 03:09]

Ook 2+1 acties of de welbekende x,99 prijzen in de winkel of 3 maten popcorn in de bios dan maar afschaffen?

Dat zijn in principe hetzelfde soort trucjes. Het is gewoon een kwestie van nadenken aan de kant van de consument....
Ook 2+1 acties of de welbekende x,99 prijzen in de winkel of 3 maten popcorn in de bios dan maar afschaffen?
Ja
Dat zijn in principe hetzelfde soort trucjes. Het is gewoon een kwestie van nadenken aan de kant van de consument....
Het feit dat je het trucjes noemt geeft toch al aan dat er mensen intrappen. Als het niet werkte dan werden dit soort trucjes niet gebruikt. Blijkbaar let het gros van de mensen niet op. En waarschijnlijk jij en ik ook niet in wat minder duidelijke gevallen.

[Reactie gewijzigd door Mangu429 op 25 juli 2024 03:09]

Tsjah, dat is onvoorkomelijk het resultaat van kapitalisme. Winst maken ten koste van alles.

“Nee, dit is niet kapitalisme”.
Fout, zo is het misschien niet bedoeld, maar er is geen andere mogelijke uitkomst. De mens wilt altijd meer.

[Reactie gewijzigd door Jaatoo op 25 juli 2024 03:09]

Dat zijn in principe hetzelfde soort trucjes. Het is gewoon een kwestie van nadenken aan de kant van de consument...
Denk je eens in... al die denkkracht (=energie) van miljoenen consumenten die dagelijks ingezet moet worden om de valkuilen van commerciele partijen te ontwijken. Die kan niet worden ingezet voor het welzijn van mensen en de mensheid! Niet voor school, niet voor de zorg voor je kinderen, partner wie dan ook. Dark patterns heten niet voor niets zo - het zijn echt duistere praktijken. Het resultaat is ontmenselijking, omdat normaal (instinctief) menselijk gedrag er toe leid dat je in de valkuil ligt. Dit is vooral een probleem voor de mensen die het (tijdelijk) met weinig moeten stellen.
Dit is onhaalbaar. Bedrijven willen geld verdienen en doen dat op verschillende manieren.

Je kunt hier niets tegen doen, zelfs niet met wetgeving. Want dan worden er wel weer andere workarounds ontwikkeld.

Zelfs als je zo ver gaat als het instellen van “standaard producten”, verbod op variërende formaten, inhoud, kleuren, verpakkingen, prijzen, acties, gebruiksvoorwaarden etc kom je hier nog niet om heen.

Zolang er geld verdient wordt aan de consument moet de consument altijd nadenken wat hij doet. Een beetje common sense en gewoon lezen lijkt mij niet te veel gevraagd. Als we dat niet eens meer kunnen/willen, dat is wat mij betreft nog schadelijker dan dat bedrijven op deze manier winst willen maken. Dan zijn we gewoon een stel zombies.

[Reactie gewijzigd door Jaatoo op 25 juli 2024 03:09]

Kan ook zijn dat die grote knop de eerste tabstop is en de "Don't send" knop blauw wordt zodra je op tab drukt.

Als dat zo is, dan is die 'dark pattern' uitspraak naar mijn bescheiden mening wat overdreven. Op een dialoogvenster is een van de twee knoppen altijd geselecteerd zodat je met je toetsenbord kan kiezen. En ja, als developer mag je dan kiezen welke van de twee de default is.
Kan ook zijn dat die grote knop de eerste tabstop is en de "Don't send" knop blauw wordt zodra je op tab drukt.
Dan nog is het gewenste antwoord al voorgeselecteerd. Zelfs als beide knoppen dezelfde kleur zouden hebben dan nog hoort geen van de knoppen vooraf geselecteerd te zijn.
(Tabstop verwijderen of plaatsen op bijvoorbeeld de link naar de voorwaarden.)
Dat zou je kunnen zeggen, maar dialoogvensters hebben meestal de 'akkoord'/'ja' knop standaard geselecteerd zodat je op enter kunt drukken. Dan heb je de escape-knop om 'nee' te zeggen.
Hoezo? Je klikt op "Manage cookies" en daarna op "Save and exit". Klaar.

De wet zegt dat wanneer je op de manage-knop van de cookie consent klikt, het verplicht is om dan alleen de absoluut noodzakelijke cookies by default aan te hebben staan, al de rest moet uitstaan. Beter gezegd: de absoluut noodzakelijke cookies vallen buiten het cookie consent, dus daar hoef je niet eens wat voor te vragen. Dus als je op manage klikt, en dan op save, dan heb je volgens de wet de minimale set aan cookies geaccepteerd. Je moet zelf alle andere cookies accepteren.

Dat ze uiteraard proberen om je op de "Accept All" knop te laten klikken door die prominent in beeld te brengen, of zelfs de "Save" knop ergens ver weg te stoppen, of bijvoorbeeld te vervangen door een klein onopvallend kruisje in de rechterbovenhoek (of, doe eens gek, de linkerbovenhoek), daar zegt de wet in principe niks over.
Dat ze uiteraard proberen om je op de "Accept All" knop te laten klikken door die prominent in beeld te brengen, of zelfs de "Save" knop ergens ver weg te stoppen, of bijvoorbeeld te vervangen door een klein onopvallend kruisje in de rechterbovenhoek (of, doe eens gek, de linkerbovenhoek), daar zegt de wet in principe niks over.
De wet zegt dat het even makkelijk (dus gelijk aantal handelingen; even herkenbare stappen; etc.) moet zijn om toestemming te geven als om deze in te trekken cq. niet te geven.

Als ik met één klik op een grote vet aangezette knop alles kan accepteren; moet ik ook met één klik op een grote vet aangezette knop die op hetzelfde scherm zichtbaar is, alles kunnen weigeren.

Punt.

[Reactie gewijzigd door R4gnax op 25 juli 2024 03:09]

Volgens mij is er meer dan 100 cookies die je handmatig uit kunt schakelen. Kijk nog eens goed op de website op racing365.nl. Ga naar sub-sub-sub "instellingen beheren". Er zit heel veel extra cookies verstopt achter -nogmaals- sub-sub-sub menu's. Niet alleen op de "groene" knop klikken , maar op de gehele horizontale balk met tekst klikken. Dan krijg je no meer cookie opties om uit te vinken ;)
Persoonlijk vindt ik de term “dark pattern” ook wat overdreven.

Het zijn gewoon psychologische trucjes waar sommige mensen vatbaar voor zijn, net als dat winkels doen met bijvoorbeeld 2+1 gratis acties.

Naar mijn mening heel normaal dat een bedrijf zijn winst probeert te optimaliseren. Dat is nou eenmaal kapitalisme.
Alleen heb je bij een 2+1gratis een maal als ondernemer voordeel, terwijl hier geen duidelijke limiet zit op wanneer het stopt.
Daarbij lijkt ook niet duidelijk wie de winst allemaal uit de verzamelde gegevens krijgt. Klinkt niet heel evenwichtig om zo aan anderen te blijven verdienen met maar 1x instemmen via een trucje bij je klanten.
Wat Jaatoo volgens mij bedoeld is dat we voorbeelden hebben gezien van "dark pattern" waar je echt moeite moet doen om überhaupt te weten waar het over gaat. Of waar positief en negatief wordt omgedraaid. In vergelijking daarmee, vind ik dit een storm in een glas water.

Het meest brutaalste wat ik ooit heb gezien was een popup of je gebruikersgegevens wou delen waarbij de "Ja" knop degene was die je moest aanklikken zodat het niet gebeurde. De enigste manier om dat door te krijgen was op een pijltje naar beneden te klikken om de hele tekst te zien. Maar ik zweer je, die was zo geprogrammeerd dat pas ergens tussen de drie a vijf klikken het daadwerkelijk uitklapte.
Door het gelijk te stellen is er geen reactie gegeven dat het erger kan. Daarbij lijkt me dat het erger kan ook niet relevant. Het punt is dat een bedrijf de klanten hoe dan ook onredelijk lijkt te verleiden door er voor meerdere partijen lange tijd voordeel uit proberen te halen.
De manier waarop ze de "Deel anonieme gegevens" knop aanbevelen is precies de zienswijze die Steve Jobs gebruikte om de gebruikersomgeving van MacOS heel lang geleden gebruikersvriendelijker te maken.

Ik zie alleen het accent op die knop op zich niet als een probleem. Met als extra goedmaker dat de tekst in de knop zelf (naar mijn mening) feitelijk juist is. De knop om te weigeren is niet gekleurd op een manier om hem minder zichtbaar te maken dan de rest van de gebruikersomgeving met duidelijke omschrijving van wat het doet.

Het is bijna 20 jaar geleden dat ik ooit een boek over UI ontwerp heb gelezen. Maar ik zie hier echt geen enkel probleem. Ik vind dat iets dat al meer dan 20 jaar gemeengoed is in UI ontwerp. Niet zomaar bestempeld kan worden als een misleidend iets.

Maar als ik iets mis heb hoor ik het graag.
Delen zou standaard opt-out moeten zijn. Door de manier waarop de knoppen zijn ontworpen is het nu standaard opt-in
De manier waarop ze de "Deel anonieme gegevens" knop aanbevelen is precies de zienswijze die Steve Jobs gebruikte om de gebruikersomgeving van MacOS heel lang geleden gebruikersvriendelijker te maken.
Het UX patroon van Apple/Jobs inzake kleuring van knoppen ging over het onderscheid maken tussen de primaire keuze, die vaak gekoppeld zat aan voortgang door een applicatie, en secundaire keuzes, die vaak naar een (tijdelijke) zijtak versprongen of terug uit gingen naar een vorige staat/stap.

Ook destijds bestond bij dat patroon al de voetnoot dat het niet toegepast diende te worden bij essentieel equivalente keuzes.

En dat is hier het geval: wel of niet accepteren van telemetrie is een op zichzelf staande keuze van de gebruiker zonder enig verder gevolg voor hoe de applicatie daarna verder opstart of merkbaar gedraagt. Het is een equivalente keuze.

[Reactie gewijzigd door R4gnax op 25 juli 2024 03:09]

Het is bijna 20 jaar geleden dat ik ooit een boek over UI ontwerp heb gelezen. Maar ik zie hier echt geen enkel probleem. Ik vind dat iets dat al meer dan 20 jaar gemeengoed is in UI ontwerp. Niet zomaar bestempeld kan worden als een misleidend iets.
Dus als misleidende praktijken maar lang genoeg duren dan is het opeens allemaal goed. Vreemde redenatie.
Wanneer door dit soort "nudging" er mensen op 'ja' klikken die op 'nee' geklikt zouden hebben als ze alles gelezen hadden, hebben die mensen dus geen expliciete toestemming gegeven. Oftewel, in gevallen waar expliciete toestemming verkrijgen wettelijk verplicht is, mag je dit soort trucjes niet gebruiken.

Dat het in ander UI ontwerp al lang gebruikt wordt is prima, maar voor het verkrijgen van expliciete toestemming is dit gewoon niet geschikt.
Het is letterlijk gewoon een kwestie van lezen ipv gewoon maar op de blauwe knop klikken of enter blijven rammen.

Ik noem dat geen “dark pattern”. Ik noem dat verantwoordelijkheid van de gebruiker.
Grappig dat je dat zegt. Er was laatst een KvW aflevering over dit fenomeen. Schijnt dat fabrikanten de prijs van losse artikelen overdreven duur maakt en dan de 2+1 gratis actie gebruikt om wat vergelijkbare prijzen te gebruiken t.o.v. bijv. Duitsland. Kort gezegd worden we gewoon keihard genaaid. Zowel bij het kopen van losse artikelen als de "actie".
Wanneer je verplicht bent expliciete toestemming te verkrijgen, zoals bij het verzamelen van persoonsgegevens, dan zijn dat soort trucjes gewoon verboden. Dat is ook vrij logisch, want als die trucjes werken, zorgen ze er dus voor dat mensen wel toestemming geven, terwijl ze dat niet gedaan zouden hebben als ze gedwongen waren er echt even over na te denken. Dat is natuurlijk op geen enkele manier als expliciete toestemming uit te leggen.
Dank voor je inspanning.
Het bedrijf dat heeft overgenomen, had van te voren wat beter moeten onderzoeken wat ze nou eigenlijk kochten ipv dit soort vervelende trucs uit te halen.
Weer een mooi product dat vernaggeld wordt helaas...
Had er inderdaad wel bij mogen staan, want dat is een term die voor mensen die niet in UX-design zitten waarschijnlijk weinig betekent
> A dark pattern is "a user interface that has been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.".

Hetzelfde als al de Cookie popups dus. Waarbij de optie "toestemmen" vaak mooi rood of groen gekleurd is en "huidige settings" een mooie witte kleur heeft als de achtergrond, waardoor de knop VEEL minder opvalt dan de knop waarmee je al je privacy buitensmijt!

Zie ik op 90% van de Cookie popups.

Denk dat zelf Tweakers zich daaraan schuldig maakt ( is zo lang geleden dat ik die popup gezien heb. Geheugen 8)7 ).

Edit:

Effen bekeken in Anonieme mode: Holly O-) shit ... Je hebt zelf geen keuze meer bij Tweakers. Toestemmen met cookies of geen toegang.

> Accepteer cookies ...
Om deze pagina op Tweakers te kunnen bekijken, moet je cookies accepteren.
> ... of neem een abonnement
Als alternatief is het mogelijk om Tweakers trackingvrij te bezoeken met een betaald abonnement.

Heuuuu? Dat is toch illegaal? Zeker als je ziet wat de tracking in de cookiebeleid volop is met 3de partijen zoals Google ...

Verborgen, gans op de bodem van de pagina ( https://tweakers.net/info/algemene-voorwaarden/cookies/ )

> Wil je cookies van specifieke partijen uitzetten, dan kan dat via Your Online Choices. Wil je de toestemming voor het plaatsen van cookies op Tweakers intrekken, dan kan dat via deze pagina.

Aka, Default op-in en goed verborgen zodat de meeste gebruikers standaard dit niet vinden / uitzetten. Jongens toch! :(

Edit 2:

Je hebt enkel de "keuze" om de cookies uit te zetten ( waardoor je terug op de loop van "geen toegang tot je cookie zet" komt ). M.a.w, je kan dus niet de trackers zoals Google uitzetten. De andere website "youronlinechoices" werkt langs geen kanten.

[Reactie gewijzigd door Wulfklaue op 25 juli 2024 03:09]

We hebben ons er allemaal al kwaad over gemaakt, het genereert wat mij betreft precies het tegenovergestelde. Als Tweakers mij niet moet omdat ik trackers en ads blokkeer, dan ga ik NOOIT van mijn leven betalen.
Het grappige is, dat ik het Premium verhaal nog wel accepteerde, ik was eigenlijk van plan om mijn portemonnee te trekken zodra de paywall erop ging, maar sinds de cookiestunt zijn ze mij kwijt als betalende klant, en ben ik nog veel harder gaan blocken.
Met uitzondering van overheidswebsites heeft elke website het recht je te weigeren als je geen cookies accepteert. Als dat je niet bevalt, ga dan bij je volksvertegenwoordiger klagen. Die hebben dit "pareltje" van wetgeving bedacht.

Zou het DPG Media sieren als ze verder gingen en wel wat mogelijk zouden maken als je geen cookies wil? Tuurlijk! Maar ze zijn je niks verplicht op dat vlak en ik denk dat klagen daar niks aan gaat veranderen.
Een cookiewall is een niet toegestane manier en je moet altijd de keuze geven welke cookies wel en welke niet, en vooraf ingevulde checkboxes mag ook niet. Hier heb je 33 paginas over hoe het nu echt zit: https://edpb.europa.eu/si...nes_202005_consent_en.pdf

Bijna geen enkele website voldoet daar overigens aan. Maar er wordt niet gehandhaafd helaas.
De hele zogenaamde cookiewet is gewoon een belachelijke wet.

Ze hadden beter mensen kunnen informeren over browsersettings aangezien elke moderne browser een optie heeft om cookies te blokkeren.

Nee, dat helpt niet tegen alle trackers maar zoals de wet nu is opgezet lijkt dat ook niet de intentie. Dan hadden ze beter keihard kunnen zeggen: “Alle vormen van tracking is verboden.” Dat ze dat niet hebben gedaan heeft natuurlijk ook een reden....
Dat is wat er gebeurt als je van edge naar chrome wil overstappen in de 'Default Programs' settings van windows. Hoe hard ik er ook op let. Ik maak de fout nog wel eens.
Hoe bedoel je? Ik snap niet precies wat je bedoeld.
Ultimate Guitar is wat dat betreft inderdaad niet de flinkste.
Toen ze het opensource project van "Musescore" overnamen hebben ze het ook eerst wat verbeterd om het daarna te gebruiken als cash grab. Pas op, ze hebben veel betekend voor Musescore met hun dedicated developer team. Het is een oprecht professionele tool geworden met een volwassen interface.
Echter voegden ze ook al snel monitoring toe aan de app en sloten ze opensource API's af voor developers van andere tools.
Toen UG besloot om Musescore.com betalend te maken kregen ze daarna ook veel backlash. Want niet alleen maakten ze vroegere gratis muziek betalend, ze vroegen ook geld voor license-free music (vaak PD), iets wat natuurlijk niet kan. Toen daarna developers begonnen met het manipuleren van de API's die achter Musescore.com zitten en die toelieten om de sheets tóch te downloaden, stuurde Musescore boze dreigbrieven naar developers, ook al was de achterliggende code bijna geheel opensource. Uiteindelijk heeft Musescore alle gebruik van de opensource code op hun website proberen blokkeren.

UG moet natuurlijk ook gewoon geld verdienen om hun developers te betalen, maar de manier waarop ze dat doen is toch vaak niet zo netjes.
't is lastig om community vs business te managen, maar het is zeker mogelijk het zo te doen dat je niet op de front pagina van tweakers komt 8)7
Telemetrie is prima en ik vertrouw de Audacity-ontwikkelaars om er iets goeds mee te doen, maar de keuze van de tooling is nogal een mismatch met de open-source tool zelf.

Zoals het er nu uitziet denk ik dat we wel telemetrie gaan krijgen, maar op een beperkter niveau en gebruikmakend van open-source telemetriesoftware. Dat zou wel het meest verstandig zijn. We zullen zien.
Ik zie het probleem niet helemaal om wat gegevens te verzamelen over algemeen gebruik van de app, zeker niet als je daar zo duidelijk toestemming voor geeft en het gewoon kunt afwijzen. Het kan binnen een software ontwikkelproces echt wel nuttig zijn om te weten wat mensen nou daadwerkelijk gebruiken.
Wat ik begrijp uit de comments is vooral het probleem dat men heeft, dat alles naar Google en Yandex wordt gestuurd, er niet open wordt uitgelegd wat verstuurd wordt en de dark pattern. Ook vragen velen zich af wat de toegevoerde waarde is van al die gegevens verzamelen.

[Reactie gewijzigd door pookie79 op 25 juli 2024 03:09]

Er blijven ook nog versies beschikbaar die geen telemetrie toe hebben gevoegd. Dit is alleen als je het direct van GitHub download. Ik ben geen fan van telemetrie in zijn algemeen, maar zo lang het een opt-in blijft is het mijn opzicht prima.
Ze geven ook zelf aan dat google en yandex niet ideaal zijn, maar er zijn op dit moment ook weinig betere alternatieven.
De toegevoegde waarde is op zich best wel simpel. Kijken waar er verschillende errors op komen duiken en welke bestandstypes en filters meer aandacht op moet worden gefocust. Bij Open Source projecten blijft het gewoon heel moeilijk om te weten wat de gebruikers er mee doen. En mensen altijd hun eigen issues te laten fixen is ook niet haalbaar.
Bovendien snap ik het gedoe over Google wel, maar over Yandex niet helemaal. Yandex verzamelt wel e.e.a., maar ze zijn wel een stuk minder evil dan Google. Het ergste wat er kan gebeuren is dat de FSB enigszins makkelijk mee kan lezen, maar wat heeft de FSB er aan om te weten welke functies van een audiobewerkingsprogramma gebruikt worden?

Edit: typo verbeterd.

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 03:09]

Ik denk dat voor veel mensen Yandex een Russische Black box is. Bij Google krijgen mensen waarschijnlijk het gevoel dat de data in ieder geval conform wetgeving wordt opgeslagen en verwijderd.

Of dat allebei terecht is? Geen idee, bij beide bedrijven heb ik geen inzicht in hoe ze zich aan de regels houden en wat ze met mijn data doen 🤷‍♀️
Het enige echte probleem dat ik zie is de implementatie van het opt-in scherm. Het standaard antwoord is goedkeuren. Als je privacy bewust wenst te zijn als developers kan je dat beter neutraal doen. We zien deze tactiek ook bij vele cookieschermpjes op websites.
Het zou ze sieren als ze de keuze kunnen diversificeren, bijvoorbeeld
errors wel,
versie en os wel,
ip niet
en plugins niet
IP ga je al bijna automatisch loggen. Je communiceert met een webserver, die slaat een access log op, en dat logbestand bevat o.a. IP adressen om bij misbruik te kunnen opsoren wie verantwoordelijk is.
Dat het automatisch doorgegeven wordt wil nog niet zeggen dat ik toestemming geef om het op te slaan.
Een IP Address is geen persoon gevoelige informatie. Hier is ook geen toestemming voor nodig.
Een IP address kan niet direct gebruikt worden om te herleiden naar een persoon. Er kunnen namelijk meerdere personen op een IP zitten, bijv. een bedrijf.

Een IP kan gezien worden als een thuis address. Je zegt ook niet tegen de gemeente dat ze je address niet mogen hebben omdat je in dat appartement gebouw woont.

Vaak worden deze gegevens ook niet aan elkaar gekoppeld maar apart opgeslagen zodat het anoniem blijft.
Dit klopt niet helemaal wat je zegt: https://autoriteitpersoon...en-persoonsgegeven-%C2%A0
Sterker nog: het klopt gewoon helemaal niet. Overweging #30 van de AVG/GDPR maakt expliciet melding van IP-adressen als online identificator:
Natuurlijke personen kunnen worden gekoppeld aan online-identificatoren via hun apparatuur, applicaties, instrumenten en protocollen, zoals internetprotocol (IP)-adressen, identificatiecookies of andere identificatoren zoals radiofrequentie-identificatietags. Dit kan sporen achterlaten die, met name wanneer zij met unieke identificatoren en andere door de servers ontvangen informatie worden gecombineerd, kunnen worden gebruikt om profielen op te stellen van natuurlijke personen en natuurlijke personen te herkennen.
Het enige echte probleem dat ik zie is de implementatie van het opt-in scherm. Het standaard antwoord is goedkeuren. Als je privacy bewust wenst te zijn als developers kan je dat beter neutraal doen.
Of de Debian manier hanteren: standaard 'nee', zodat het een echte (bewuste) opt-in is.
Maar dan dwing je mensen enigszins ‘nee’ te kiezen, waardoor het niet neutraal is.
Maar dan dwing je mensen enigszins ‘nee’ te kiezen, waardoor het niet neutraal is.
Het hoeft niet neutraal te zijn. Wel moet voorkomen worden dat gebruikers onbewust zichzelf benadelen. Daarop inspelen voor eigen gewin is onethisch, en mogelijk zelfs illegaal omdat een gebruiker expliciete toestemming moet geven voor het laten verzamelen van diens persoonsgegevens. Als iets verbergen in kleine lettertjes in een EULA van vijf kilometer gezien wordt als iets dat niet rechtsgeldig is, dan kan dat ook wel eens zo zijn voor andere zaken waarbij men te makkelijk doorklikt omdat het alternatief te moeilijk wordt gemaakt.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 03:09]

Dit zijn geen persoonsgegevens
Dit zijn geen persoonsgegevens
IP adres is een persoonsgegeven.
Dat kan dus alleen door neutraal te zijn.

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 03:09]

Zoals @The Zep Man al zei, hoeft het niet neutraal te zijn. Je hebt expliciete toestemming nodig om persoonsgegevens te verzamelen, maar je hebt geen toestemming nodig om persoonsgegevens niet te verzamelen.

Zolang de keuzemogelijkheid dus de "wel verzamelen"-optie niet voortrekt, is het goed. Onevenwichtigheid in het voordeel van "niet verzamelen" mag gewoon.

In gevallen waar je niet neutraal kan zijn, bijvoorbeeld wanneer één van beide opties sowieso de default moet zijn, dan moet je zelfs het voordeel geven aan "niet verzamelen".
Ik ben wel benieuwd naar onderzoeken die aantonen hoeveel mensen nou echt voor de opt-in gaan als de keuze wordt voorgelegd. Data is deze is alleen nuttig in grote aantallen dus als je maar 10% van je gebruikers treft is de groep meestal niet groot en representatief genoeg.

Ik zie het probleem niet van een opt-in met de 'ja' standaard aangevinkt. Als ik echt iets tegen die telemetrie heb kies ik alsnog bewust voor 'nee', maar zoals zovaak zal het veel mensen niet veel kunnen schelen.
Een probleem hebben met het soort data dat verzameld wordt kan, maar dat is eigenlijk een heel andere discussie en dient die gevoerd te worden.
Nou, in dit geval zal het best behoorlijk zijn. Het aantal gebruikers ligt op zeker 200.000.000, dus 10% daarvan is 20.000.000. Dat lijkt me toch aardig zat.
Het gaat bij zoiets natuurlijk niet om absolute aantallen. Je wilt het liefst een zo groot mogelijke doorsnede van je gebruikers hebben, ik betwijfel of 10% genoeg is. Ook betwijfel ik of je 10% wel haalt met een opt-in defaulted naar 'No', maar dat kan ik niet staven met bewijs.
Je zou als ontwikkelaar natuurlijk een ‘issue’ kunnen openen waarin je vertelt dat je hebt ontdekt dat 10% van de gebruikers functie A gebruikt en dan met de gemeenschap bespreken hoe het verder moet.

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 03:09]

Het enige echte probleem dat ik zie is de implementatie van het opt-in scherm. Het standaard antwoord is goedkeuren. Als je privacy bewust wenst te zijn als developers kan je dat beter neutraal doen. We zien deze tactiek ook bij vele cookieschermpjes op websites.
Dat is een deel van de crux. Met hun doel van userbase definiëren etc. hebben ze natuurlijk wel een vrij complete userbase aan data nodig. Het is net als groepsimmuniteit... ;)
Volkomen mee eens, aangezien het net is overgenomen lijkt het me logisch dat ze willen weten hoe de userbase eruit ziet. Ik neem aan dat ze na de overname willen investeren in nieuwe features en dan helpt het om een beter beeld te hebben van hoe mensen het gebruiken. IP-adres vind ik persoonlijk daar niet bij horen overigens. De keuze voor Google/Yandex is ook niet de beste beslissing als je het mij vraagt, zeker als je weet dat een open source community daar niet lekker op gaat en dan ook nog een week na de overname... Ik snap wel dat hier een relletje rond ontstaat.
IP adres is wel nuttig ivm. Locatie van je gebruikers. Dan kan je gaan localiseren voor grote markten bijv. Ik zie het nut er wel van in voor de eigenaar. Zelf zou ik lekker opt-outten though, ze hoeven niet te weten welke vpn ik gebruik :P
Het zou al een stuk beter zijn als je bijvoorbeeld het land van het systeem gebruikt in plaats van de VPN. Dat is al een stuk anoniemer als je echt die locatie van je gebruikers nodig hebt.

Ik zou met zo'n project juist voor een opensource analyticssysteem kiezen, al moet ik daarbij toegeven dat de huidige projecten nog niet zo lekker lopen als google's analytics.
Ik ook niet perse, maar het is meer de manier waarop het gebeurt. Ik denk dat de reacties daarom ook negatief zijn.

Ik heb bij Home Assistant bijvoorbeeld analytics aangezet omdat de ontwikkelaars er inderdaad veel aan kunnen hebben en ze zeer helder gecommuniceerd hebben wat ze doen en waarom.
Of je werkt gewoon even mee aan wat telemetrie zodat de ontwikkelaars enigzins idee hebben bij welke kant het op moet. Wat overigens ook altijd gekanker oplevert van degenen die het er net weer niet mee eens zijn.
Niks mis met telemetrie over het functioneren van de applicatie. Maaruh; waar is het opslaan van het IP adres goed voor in dat soort gevallen? Als het bedoeld is om over meerdere gebruikssessies heen dezelfde installatie te herkennen, genereer dan een anonieme hash uit bijv. hardware IDs van de machine waarop de software draait.

En: waarom moet dit via Google Analytics of Yandex lopen? Zijn er andere beperktere mogelijkheden die het verwerken bijv. on-premise onder eigen beheer doen? In een beperkter formaat? Zonder eeuwenlange retentie, maar enkel binnen een relevant tijdsvenster, van - zeg - een maand of zo?

[Reactie gewijzigd door R4gnax op 25 juli 2024 03:09]

Of je werkt gewoon even mee aan wat telemetrie zodat de ontwikkelaars enigzins idee hebben bij welke kant het op moet.
Dat zijn nou juist zaken die je niet uit telemetrie kunt halen. Telemetrie toont geen gegevens over wat mensen anders willen zien in een programma. Je kunt niet meten wat er nog niet is.
Hoe is de data anonymous als het ip adres erbij zit?
Een IP adres is een speciaal geval. Aangezien wij bijna allemaal met een dynamisch IP adres het internet opgaan is dit geen direct persoonsgegeven. Om er een persoonsgegeven van te maken heb je ook toegang nodig tot de data die een IP adres kan verbinden met een persoon. Tot die data heb je standaard geen toegang.

Indien er misbruik wordt gemaakt van de API kan men wel klacht indienen en in het onderzoek naar de dader van het misbruik proberen deze data op te vragen. Op dat moment is er evenwel ook een gerechtvaardigd belang om die data op te vragen.

Dus zolang je niet beschikt over de koppeling IP adres <-> Persoon is het wel degelijk anoniem. En op het moment je die anonimiteit verliest is er bijna altijd sprake van een gerechtvaardigd belang.
Ook al beschik je niet over de gegevens om de koppeling te maken, toch is het volgens de avg wel een persoonsgegeven. De AP geeft als voorbeeld hiervan ook het kenteken.
Het gaat er niet alleen om of jij door die gegevens meteen weet over wie het gaat. Ook wanneer je hulp van derden nodig hebt en met redelijke middelen achter de identiteit van een persoon kunt komen, zijn het persoonsgegevens. Alleen wanneer de kosten en de tijd en beschikbare technologie te wensen over laten en het dus te veel tijd, geld en moeite zal kosten (in het algemeen) om een persoon te kunnen identificeren, is er geen sprake van een persoonsgegeven. Een kenteken is voor jou en mij geen persoonsgegeven. Maar zonder al te veel tijd, geld en moeite is het voor de RvW wel een persoonsgegeven, dus is een kenteken in algemene zin een persoonsgegeven. - Lees hier verder: https://www.charlotteslaw...at-zijn-persoonsgegevens/
© Charlotte's Law
Ik vind deze zin zeer interessant:
Een kenteken is voor jou en mij geen persoonsgegeven. Maar zonder al te veel tijd, geld en moeite is het voor de RvW wel een persoonsgegeven, dus is een kenteken in algemene zin een persoonsgegeven
Dus voor jouw of mij of iemand die geen toegang heeft tot de database van de RDW is het geen persoonsgegeven, maar omdat die database wel bestaat zou je het wel als persoonsgegeven moeten aanzien?
Alleen wanneer de kosten en de tijd en beschikbare technologie te wensen over laten en het dus te veel tijd, geld en moeite zal kosten (in het algemeen) om een persoon te kunnen identificeren, is er geen sprake van een persoonsgegeven.
Maar als je geen toegang hebt tot die database (zoals bijv. de RDW dat heeft, maar ook opsporingsdiensten) dan kost het je wel veel tijd, moeite en geld om aan die informatie te komen, zonder opdracht van de rechter kom je er vaak helemaal niet aan. Probeer bij een ISP maar eens te achterhalen wie er achter een IP adres zit, ze zullen je die informatie echt niet geven. Vraag maar aan BREIN.
https://gdpr-info.eu/issues/personal-data/ :

For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.

En voor ip adressen specifiek:

Het Hof van Justitie heeft in het arrest van 19 oktober 2016 het begrip persoonsgegevens mogelijk wel erg ruim uitgelegd: een dynamisch IP-adres wordt als persoonsgegevens aangemerkt, omdat bij de provider (desnoods met een rechterlijk bevel) de naam van de houder van het IP-adres achterhaald zou kunnen worden.

https://www.dirkzwager.nl...ovider-op-te-vragen-zijn/

https://www.ictrecht.nl/b...sgegeven-het-hvj-oordeelt


En ook onze eigen Arnoud ziet het zo:
vraag: Regelmatig lees ik dat IP-adressen als persoonsgegevens worden gezien, omdat ze tot een persoon (de gebruiker van de computer waar dat adres aan toegekend is) herleidbaar zijn. Dat klopt in theorie, maar je hebt daar de internetprovider voor nodig en die zal zonder gerechtelijk bevel niet meewerken, toch? Maar bij kentekens is de situatie hetzelfde en daarvan zegt de toezichthouder dat het géén persoonsgegevens zijn voor jou of mij, alleen voor de RDW. Waarom dat onderscheid?
Antwoord: Dit onderscheid is inderdaad lastig uit te leggen, maar gelukkig verdwijnt het met de AVG: beide gegevens zijn vanaf 25 mei gewoon keihard persoonsgegevens voor iedereen, punt.
https://www.security.nl/p...n+en+een+kenteken+niet%3F

[Reactie gewijzigd door Sannr2 op 25 juli 2024 03:09]

Een IP adres is een persoonsgegeven. Bij een persoonsgegevens gaat het erom of je een gegeven kunt herleiden naar een individu, eventueel door het gegeven te combineren met andere gegevens. De GDPR bestaat inmiddels al lang genoeg dat een IP adres als persoonsgegeven wordt beschouwd.
Dus voor jouw of mij of iemand die geen toegang heeft tot de database van de RDW is het geen persoonsgegeven, maar omdat die database wel bestaat zou je het wel als persoonsgegeven moeten aanzien?
Volgens de definite van de AVG/GDR:
„persoonsgegevens”: alle informatie over een geïdentificeerde of identificeerbare natuurlijke persoon („de betrokkene”); als identificeerbaar wordt beschouwd een natuurlijke persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificator zoals een naam, een identificatienummer, locatiegegevens, een online identificator of van een of meer elementen die kenmerkend zijn voor de fysieke, fysiologische, genetische, psychische, economische, culturele of sociale identiteit van die natuurlijke persoon;
Het grote verschil met de oude Wet Bescherming Persoonsgegevens is hier tweeledig:

Ten eerste maakt de AVG niet het onderscheid dat de gegevens door de verwerker herleidbaar moeten zijn tot een persoon.
Ten tweede maakt de AVG niet meer gebruik van de term 'herleidbaar' - maar van de term 'identificeerbaar.' Dit is een bredere term en slaat niet alleen op het kunnen herleiden van de identiteit van de betrokkene; maar ook op het kunnen herkennen van dezelfde betrokkene in een groep, ondanks dat je nog steeds niet de identiteit van die betrokkene kent.

Met name vanwege dat tweede punt zijn IP-adres; nummerplaat; tracking cookies; etc. altijd persoonsgegevens.

[Reactie gewijzigd door R4gnax op 25 juli 2024 03:09]

Dynamische IPs zijn een heel stuk minder dynamisch dan je wellicht denkt.
Nee hoor, ik ben mij er perfect van bewust dat je maandenlang hetzelfde dynamische IP adres kunt hebben, vaak zelfs totdat de modem nog eens herstart wordt.
Maandenlang?

Mijn "dynamische" IP adres van mijn glasvezel provider is al 6 jaar hetzelfde.
Mijn "dynamische" IP adres van mijn glasvezel provider is al 6 jaar hetzelfde.
Zelfde hier bij Ziggo.

De enige reden dat die IP adressen dynamisch zijn, is om netwerk management wat makkelijker te maken. Als mensen daarna problemen hebben en de service desk bellen is het makkelijker om ze te vertellen dat ze het modem even van de stroom af moeten halen (zodat daarna DHCP ze een nieuw, correct, adres geeft) dan per getroffen geval een individuele update naar het modem moeten sturen met het nieuwe correcte adres.
Inderdaad! Mijn dynamische ip adres bij youfone is in een heel jaar geen enkele keer veranderd.
Ik heb geen dynamisch IP hoor. Ben hier ook niet blij mee.
Ik ook niet en ben er dolblij mee. Heb er zelfs mijn providerkeuze op afgestemd. Dat scheelt weer het uitzoeken van een DynDNS optie om mijn self-hosted zaken op hostname benaderbaar te maken.
Bij mijn provider is het geen toeval (modem bijtijds on-line voor de DHCP-lease renewal), maar beleid, inclusief een pre-notificatie als het IP-adres toch gewijzigd 'moet' worden om hun netwerk logischer in te richten.
Een IP is niet altijd een presoonsgegeven, dat hangt er vanaf of je het IP kunt koppelen aan een persoon. Uiteraard kunnen ze dat vast wel ergens, en dan is het daarmee PII.
Een IP is niet altijd een presoonsgegeven, dat hangt er vanaf of je het IP kunt koppelen aan een persoon.
Doordat je dit niet van te voren weet en een IP adres indirect gekoppeld kan worden aan een persoon, betreffen (in Nederland) IP adressen altijd persoonsgegevens.

Zie ook de AVG definitie van de AP:
De Algemene verordening gegevensbescherming (AVG) geeft aan dat een persoonsgegeven alle informatie is over een geïdentificeerde of identificeerbare natuurlijke persoon. Dit betekent dat informatie ofwel direct over iemand gaat, ofwel naar deze persoon te herleiden is. Gegevens van overleden personen of van organisaties zijn geen persoonsgegevens volgens de AVG.

(...)

Er zijn veel soorten persoonsgegevens. Voor de hand liggende gegevens zijn iemands naam, adres en woonplaats. Maar ook telefoonnummers en postcodes met huisnummers zijn persoonsgegevens.
Een specifiek IP adres kan, net als een telefoonnummer, op een moment in tijd op iemand zijn/haar naam staan. Zonder te weten of een IP adres op naam van een organisatie of een persoon staat, moet dus aangenomen worden dat het een persoonsgegeven betreft, en als zodanig verwerkt worden.

Verder wordt de term 'anoniem' vaak misbruikt. Waar men vaak over spreekt is 'pseudoniem', wanneer een uniek nummer ergens aan gekoppeld wordt dat uiteindelijk terug te herleiden is naar een enkel persoon. Als het terug te herleiden is naar een persoon, eventueel gecombineerd met andere gegevens, dan is het niet anoniem.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 03:09]

Als iemand meerdere (gestolen) datasets combineert, dan is een IP nummer juist een gegeven dat de koppeling makkelijker maakt. Dus, indien niet echt nodig, sla je dit niet op en gebruik je een andere unieke identifier.
Vergeet niet dat hier ook in alle gevallen een datum & tijd geregistreerd wordt. Daarmee kan je altijd achterhalen van wie de verbinding was.
Ik denk dat het verzamelen van het IP adres meer impliciet is aan het verzamelen van gegevens. HTTP zonder IP adressen wordt een beetje lastig.
Het IP zal moeten worden verstuurd voor de communicatie, maar hoeft natuurlijk niet bij de ontvangen dataset opgeslagen te worden (maakt het uiteraard wel eenvoudiger om misbruik te voorkomen: meer dan X datapoints binnen Y tijd ontvangen van een IP -> tainted danwel directe drop)
Nou en? Het is open source, dan sloop je dat er toch gewoon zo even uit? Dat is toch de kracht van open source, iedereen kan er toch iets mee doen?

/s
Het is open source, inderdaad. Maar dat wil niet zeggen dat alle wijzigingen ook daadwerkelijk doorgevoerd worden. Uiteindelijk is het altijd nog de beslissing van de eigenaar van het project om bijdragen van anderen daadwerkelijk te gebruiken.
.oisyn Moderator Devschuur® @Thilium8 mei 2021 13:08
Het punt is dat je het project kan forken, de telemetrie eruit kan slopen en dat kunt releasen. Changes en nieuwe features op de main branch kun je gewoon mergen in de fork.
Nog niet eens iets met free, open of libre. Dan kunnen die de volgende keer gebruikt worden. :)
De doelgroep is muzikanten, niet coders die weten hoe ze compileren moeten.

@Luca ik heb het over muzikanten die net weten hoe hun macbook werkt (ja die kunnen vast op een knopje drukken) en geen verstand hebben van source code compileren.

[Reactie gewijzigd door Strebor op 25 juli 2024 03:09]

Je kunt nog altijd gewoon op 'dont send' klikken, dus ik zie hier het probleem niet.
Je kan NU nog altijd op 'dont send' klikken.

Dit is stap 1. Dan laten ze het er een tijd inzitten, en dan op een gegeven moment is het 'per ongeluk' opt-out geworden. etc.
Dat mag wettelijk niet, en dat toont een wantrouwen in de ontwikkelaars die al jarenlang dezelfde goede software hebben ontwikkeld en aangeboden.
Nee, het toont een wantrouwen in het bedrijf dat de software overgenomen heeft.
Muzikanten kunnen daarvoor gewoon mensen inhuren hoor en er zal ook vast wel een muzikant zijn die wél kan coderen of in ieder geval de optie van cmake eraf kan halen om die telemetrie niet toe te voegen.
Dus? Een goede vriend is een muzikant. Als hij nog steeds Audacity gebruikt op zijn Windows machine, zal ik het zeker niet nalaten het te forken en de telemetry eruit te slopen, mocht hij day graag willen.
Of je kan die vriend zeggen om gewoon op "Don't Send" te klikken. Misschien is dat net iets handiger
.oisyn Moderator Devschuur® @Strebor8 mei 2021 14:03
Nou en? Er hoeft maar 1 coder te zijn die dit publiek maakt en iedereen kan dat gewoon downloaden. En dan heb ik het ook over binaries, ze hoeven echt niet zelf te compilen.

[Reactie gewijzigd door .oisyn op 25 juli 2024 03:09]

En wat heeft die coder dan allemaal toegevoegd in zijn versie ;) . Een mooie cryptominer?
.oisyn Moderator Devschuur® @hiostu8 mei 2021 16:39
Dat kun je prima zien in de diffs
Van een binairy?
.oisyn Moderator Devschuur® @hiostu8 mei 2021 17:04
Ja, met deterministic builds kun je zien of de source matcht met een binary.
Ja dat klopt, maar als een coder gewoon de sourcecode pakt daar meer wijzigingen op doet en deze op de site plaatst dan weet je niet wat er allemaal mee is gebeurd. Je hebt dan immers de source niet. En een leek kan ook niet checken of een deterministic build klopt. Het ging mij meer om hoe makkelijk er gezegd wordt dat niet-technische mensen dan maar ergens een binary vandaan kunnen plukken van iemand die een fork gemaakt heeft. Dat lijkt mij potentieel gevaarlijker gedrag aanleren dan gewoon zorgen dat iemand leest en op de juiste knop moet drukken bij een versie die uit een betrouwbare bron komt.

[Reactie gewijzigd door hiostu op 25 juli 2024 03:09]

.oisyn Moderator Devschuur® @hiostu8 mei 2021 17:12
Ik heb het dan ook niet direct over "gewoon maar ergens" en dus een fork van een random anonieme gebruiker, maar iets waarvan de community aangeeft dat dat een goed alternatief is.

Ik bedoel, ik zie een willekeurige gebruiker van Audacity niet github afstruinen naar forks. Dat is iets dat vanuit de community (die nu overwegend negatief tegenover die telemetrie staat) georganiseerd moet worden.

[Reactie gewijzigd door .oisyn op 25 juli 2024 03:09]

Een project beheren kost tijd. Het liefste worden changes ingevoegd in de upsteam code-base. Het project forken is een van de laatste dingen die zal gebeuren, en dit zal alleen gebeuren als een deel van de community het zodanig oneens is met de richting van het upstream project dat ze besluiten hun eigen weg te vervolgen.

Vrije software gaat om meer dan alleen code pushen, zelfs als een niet-programmeur kan je deelnemen aan het project als een actief meedenkend community-lid. Audacity heeft een actief meedenkende community die flink aan het trekken en duwen is op het moment, deze changes worden wel verwijderd of aangepast tot een acceptabele implementatie.
Is er nu vooral ophef over de telemetrie überhaupt? Of de wijze waarop toestemming gevraagd wordt voor het verzamelen?
De reactie van de community is gemixed. Sommigen zijn volledige tegen telementrie, anderen nemen alleen een probleem met de implementatie.

Persoonlijk vind ik het volledig tegen telemetrie zijn te ver gaat, zolang het een nette duidelijk aangegeven opt-in implementatie betreft is er niks mis mee. Zij die het project willen helpen kunnen dan bewust het besluit nemen om telemetrie te delen.
Ik zou het niet echt gemixed noemen als ik naar de emoji's kijk onder de posting op github.

182 👍
3061 👎
31 😄
11 🎉
553 😕
21 ❤
7 🚀
121 👀

Met die 👎 en 😕 heb je toch echt een overgrote meerderheid van 3614 van de 3987 stemmen.
Ik heb het over waar de mensen het mee oneens zijn, niet de reactie op de patch in het geheel. De reacties van vrijwel iedereen zijn negatief, maar de redenering verschild per persoon.

"Sommigen zijn volledige tegen telemetrie, anderen nemen alleen een probleem met de implementatie."
Kijk, en dat is ook een soort Telemetrie ;)
Ik vermoed vooral het eerste. Telemetrie heeft bij vele mensen een negatieve betekenis hoewel dat natuurlijk niet altijd zo hoeft te zijn.

Als de doelen zouden zijn zoals Audicity ze voorstelt, dan is er op zich niet veel mis mee. Maar het feit dat dit zo kort na een overname gebeurd doet een mens wel afvragen of dit er gekomen is op vraag van de nieuwe eigenaar, eventueel met het doel om de gebruikers beter te leren kennen zo dat ze er in de toekomst alsnog een verdienmodel aan kunnen vasthangen.
Zoals je in de reactie van hef project kan lezen gaat het om meerdere zorgen, waaronder het idee om over gebruikers te verzamelen, de keuze van bedrijven die dat als service moeten leveren, de onduidelijkheid wat nodig is, de onduidelijkheid wie wat waarvoor verwerkt zoals bij die telemetriebedrijven, de keuze voor ee gebruiker, de manier om die keuze aan te bieden, de informatie over de keuze en verzamelen, de manier waarop het project de keuze heeft gemaakt enz.

[Reactie gewijzigd door kodak op 25 juli 2024 03:09]

Het gaat om een opt-in, hoewel een dark pattern gebruikt wordt om gebruikers over te halen
Dark pattern gaat naar mijn idee toch over een zelf ontworpen dialoog om de gewenste keuze ten allen tijde prominent in beeld te hebben. Het screenshot is de default Mac OS dialoog met enkel de 'opt in' de active choice. Het valt Audacity niet aan te rekenen dat Mac OS zo schreeuwend duidelijk is over welke knop in de dialoog de actieve keuze is.

Met keyboard navigatie in dialogen aan volstaat een tab om het "dark pattern" 180 graden te laten draaien naar Don't Send als veel te nadrukkelijk in de dialoog aanwezige keuze.

Het enige dat je ze (naar mijn idee terecht) kunt aanrekenen, maar niet onder de noemer dark pattern, is dat ze de opt-in de default van de dialoog gemaakt hebben ipv de opt-out.
Als Mac OS in hun UI de win-95 achtige dotted-line indicatie voor de actieve button hadden gehad dan was er geen enkele reden om over 'dark pattern' te reppen (wel over verkeerd gekozen default keuze)

[Reactie gewijzigd door aikebah op 25 juli 2024 03:09]

Standaard native MacOS UI design dus. Met een heel duidelijke uitleg erbij. Het komt mij over als FUD van een groep mensen die principieel tegen de overname is.
Ik kan heel moeilijk geloven dat er in macOS geen enkele manier is om beide knoppen als non-primary aan te merken, en op die manier een daadwerkelijk bewuste keuze te forceren. Mocht dat echt niet kunnen, dan is "don't send" dus inderdaad de correcte default - dus hoe dan ook is het huidige ontwerp fout (en, hoogstwaarschijnlijk, bewust).
Jammer, ik gebruik Audacity al een jaartje voor mijn video's als voice over. Werkt simpel en effectief.

Ik moet zeggen dat ik het programma sindsdien nooit heb geupdate; net gekeken en ik zit op v2.40, terwijl v3.02 uit is.

Ben ik dan gevrijwaard van de telemetrie? Ik heb in elk geval niks voorbij zien komen in Simplewall.
Of je klikt "nee"? (Met de vraag of er echt was mis is met de ontwikkelaars automatich van feedback te voorzien).
Of je klikt "nee"? (Met de vraag of er echt was mis is met de ontwikkelaars automatich van feedback te voorzien).
Gelukkig houdt v2.40 updates niet automatisch bij en moet dit handmatig gedaan worden (kan wel via het 'help' menu)
En waarom "gelukkig"? Je kan gewoon updaten en klikken op "Don't Send". Niets aan de hand
Het werkt prima; het neemt op en export het naar WAV/MP3/etc.. in dit geval heeft het weinig meerwaarde om te updaten; 'if it ain't broken..'
De betwiste feature is nog hevig in discussie en ik zie het de komende versies Audacity nog niet betreden. Niet tot een duidelijke beslissing is gemaakt over de implementatie, en niet tot de nieuwe code daadwerkelijk is geschreven, en niet tot dié uitvoerig is besproken in een opeenvolgende merge request.

Ik zou niet te hard van stapel lopen, het is niet alsof de ontwikkelaars niet lezen.
Dit leest als een soort schandaal.
Terwijl je met open-source in een hand omdraai een 'telemetrie-loze' versie maakt.
Kan iemand mij uitleggen waarom mensen er zo emotioneel over zijn?
Omdat de meeste gebruikers geen software ontwikkelaars zijn

Op dit item kan niet meer gereageerd worden.