Spotify-partnerbedrijven konden mogelijk sommige gebruikerswachtwoorden zien

Bepaalde partnerbedrijven van Spotify konden ruim een half jaar lang de gegevens inzien van sommige Spotify-gebruikers. Deze bedrijven hadden 'mogelijk' toegang tot onder meer het e-mailadres, wachtwoord en de geboortedatum van de gebruikers.

Spotify spreekt over een kwetsbaarheid in het systeem wat per ongeluk Spotify-accountregistratie-informatie liet zien aan 'bepaalde' partnerbedrijven. Het is onduidelijk welke data er precies zichtbaar was, de muziekstreamingdienst zegt dat het 'mogelijk' om e-mailadres, accountnaam, wachtwoord, geslacht en geboortedatum gaat. Het is onduidelijk of deze informatie was versleuteld. Het bedrijf zegt dat deze informatie aan partnerbedrijven is 'blootgesteld'. Spotify heeft getroffen klanten en de Californische officier van justitie ingelicht over de kwetsbaarheid. TechCrunch heeft de brief gericht aan de Californische autoriteiten gepubliceerd.

De streamingdienst kwam op 12 november achter de kwetsbaarheid. Het bedrijf schat dat de kwetsbaarheid er sinds 9 april was. Spotify heeft het wachtwoord gereset van gebruikers die door de kwetsbaarheid zijn getroffen. Bedrijven die mogelijk toegang hadden tot de data zijn door Spotify gecontacteerd 'om er zeker van te zijn' dat zij de data hebben verwijderd. Het is niet duidelijk hoeveel klanten door de kwetsbaarheid zijn getroffen. Een woordvoerder zegt tegen TechCrunch dat het om 'een klein deel' van de Spotify-gebruikers gaat.

Reacties (52)

[Christoxz]

Plain password of hashed?
Plain text zou toch wel heel schokkend zijn..

[Henk Poley]

Waarom zouden ze dat überhaupt opgeslagen hebben ??

[unglaublich]

Hashes maken het mogelijk een wachtwoord te controleren zonder deze direct op te slaan.

Je verzint een functie, de hashfunctie, die alle tekens van een wachtwoord verandert en verschuift op een bepaalde manier wat resulteert in een hash.
De hashfunctie moet makkelijk uit te rekenen maar moeilijk terug te rekenen zijn.
Een voorbeeld van een oudere hashfunctie is md5, een nieuwe is sha1.

Nu sla je niet het wachtwoord op maar de hash, vervolgens wanneer iemand inlogt pas je de hashfunctie toe op de gebruikerinput en vergelijk je de uitkomsten, de hashes.

Wanneer de hashes gelijk zijn weet je dat het wachtwoord gelijk is.

In de praktijk wordt aan je wachtwoord nog een unieke, bekende, reeks tekens toegevoegd, dit is de salt. Dit is om te voorkomen dat iedereen met het wachtwoord "wachtwoord" direct door de mand valt.

Wanneer een wachtwoord geen salt heeft kan het achterhalen soms heel makkelijk zijn. Bijvoorbeeld:

b19e15604eb711b025c57883b934c2ac52418f25

[Reactie gewijzigd door unglaublich op 23 juli 2024 09:26]

[Single Core]

De hashfunctie moet makkelijk uit te rekenen maar moeilijk terug te rekenen zijn.

De hashfunctie moet makkelijk uit te rekenen maar moeilijk niet terug te rekenen zijn.


Dit is enkel mogelijk door middel van bruteforce ofwel een slechte implementatie van een hash.
Verder wil je de dag vandaag een hashfunctie die ietswat moeilijker te berekenen is, want anders als deze te simpel is, zoals bij MD5 (Die ook nog andere problemen heeft) dan kan je deze zeer snel gaan bruteforcen.

Verder zouden hashen infeite compleet onnodig zijn als iedereen een uniek willekeurig wachtwoord per website zou gebruiken in combinatie met een password manager. Of nog beter, 2-fa dan heb je in theorie al bijna helemaal geen wachtwoord meer nodig.

[Reactie gewijzigd door Single Core op 23 juli 2024 09:26]

[TigerXtrm]

Voor mijn nieuwsgierigheid; hoe kan een hash wel uit een wachtwoord berekend worden maar niet andersom? Je zou denken, als je de gebruikte formule kent dan kan je die ook omdraaien, toch?

[BrunkBeard]

In de informatica wereld worden dit 'one-way functions' genoemd. Er is theoretisch niet geweten of zulke functies bestaan, maar bestaande hashing functies doen een poging en sommigen lijken tot hiertoe vrij goed te werken. Zulke hashing methodes gebruiken wiskundige technieken die direct te berekenen zijn, maar erg moeilijk te inverteren zijn (of waarbij dit computationeel dus heel lang zou duren). Een voorbeeld van zo'n wiskundige methode is het zoeken en vermenigvuldigen van twee priemgetallen p en q. De omgekeerde bewerking, om van dit product twee priemgetallen te bekomen, is extreem moeilijk en betekent het afgaan van alle mogelijke combinaties, wat er erg veel zijn als p en q gigantisch grote getallen zijn.

[Reactie gewijzigd door BrunkBeard op 23 juli 2024 09:26]

[Ghxst]

Goede uitleg!

[bavanandel]

One-way functions zijn by definition maar een kant op te gebruiken. Alleen een verkeerde implementatie zou maken dat die theorie niet werkt.
Daarnaast is het Pigeon Hole Principle van toepassing. De totale ruimte aan mogelijke hashes is namelijk beperkt (bijv. 256 bits, of 2048 bits, aan totale grootte van zo'n hash), terwijl de mogelijke input die tot zo'n hash gereduceerd wordt onbeperkt is. Ofwel, er is ook een oneindig aantal inputs die uiteindelijk dezelfde hash genereert.
De kunst is nu om die hashing algoritmes zo te kiezen dat het onmogelijk is om een input terug te vinden die tot dezelfde hash leidt, zonder brute force alles maar te gaan proberen. Brute forcen wordt exponentieel moeilijker met elke bit die je hash groter wordt, dus met een voldoende grote hashlengte is het in de praktijk onmogelijk om (bij correcte implementatie en juist gebruik van salting) de input terug te vinden uit een hash binnen een tijdsbestek waarin die input nog nuttig is.
Soms is het al voldoende als dat pas met enkele jaren lukt, soms wil je liever dat je hash de ondergang van het universum niet overleeft. Dan kies je gewoon een langere hash.

[beerse]

Het meest simpele voorbeeld is wel het afkappen. Dat wordt (werd) bijvoorbeeld gedaan bij het 'bios' wachtwoord van een msx2 machine (in 1990): Het wachtwoord dat je kon intikken was max 255 karakters. Daar kon je aardig je best op doen.

Toen ik de versleuteling van een paar wachtwoorden in detail bekeek, bleek dat 'DitIsMijnWachtwoord24" en "DitIsMijnWachtwoord99" de zelfde sleutel hadden. Het bleek dat alleen de eerste 14 (of zo) karakters significant waren, de rest werd bij de versleuteling gewoon genegeerd. Een knappe wiskundige die een formule bedenkt om die wachtwoorden terug te rekenen. Een brute-force zal in dit geval 1 (of meer?) van de mogelijkheiden makkelijk vinden.

[D4NG3R]

Dat kan ook, maar het idee is dus om de gebruikte formule geheim te houden. Het hele hashing gedeelte word aan de server kant gedaan.

[Reactie gewijzigd door D4NG3R op 23 juli 2024 09:26]

[Eagle Creek]

Nee, dat kan niet zomaar. En aannemende dat je met "formule", algoritme bedoelt: deze mag best publiek bekend zijn. Graag zelfs.

[D4NG3R]

Ik was te snel met antwoorden na een lange dag, negeer wat ik zei.

[Jobvdl]

Naast het antwoord van @BrunkBeard is er nog een extra complicatie bij hashen. Een hash functie heeft als input een stuk text en als output een hash. Er zit (praktisch) geen limiet op het nummer van verschillende inputs, maar er zit wel limit op het aantal verschillende outputs. Dit geeft als gevolg dat meerdere inputs naar de zelfde uitput gaan. (Zie https://nl.wikipedia.org/wiki/Duiventilprincipe voor meer info). bijvoorbeeld, als je van nummers alleen het laatste cijfer opslaat, dus 1 = 1, 2 = 2, 24 = 4, 100204 = 4, dan zie je dat (veel) nummers naar de output 4 gaan. Dan komt het "onmogelijke" als je alleen weet dat je output 4 is, dan kan je er nooit achter komen (met alleen de output) of de input 4, 14, 24, 34, etc was.

Dat gezegd hebbende, bij het controleren of je input gelijk is mbv hashes, hoeft alleen de output gelijk te zijn. Dus als de hash 4 is, zijn alle inputs die eindige met een 4 "gelijk/goed". Nu zijn er maar 10 mogelijke uitkomsten in mijn voorbeeld, maar in (goede) hash functies zijn de hoeveelheid outputs zo groot dat het praktisch onmogelijk is om twee inputs te vinden die de zelfde uitput hebben.

[Niemand_Anders]

Terugrekenen moet je hier met een korreltje zout nemen. Stel je krijgt op een proefwerk een vraag als wat de uitkomst is van 2 + 2. Als je het antwoord niet weet, kun je in principe alle antwoorden proberen om zo te achterhalen wat het juiste antwoord is. Je weet dan dat 2 + 2 = 4, maar niet dat 3 + 1 (of 5 -1) hetzelfde antwoord geeft..

Terugrekenen moet je meer zien als achterhalen. Stel je voor dat je een lijst hebt van een miljoen gehashte wachtwoorden. Als hacker kan ik dan een hash uitrekenen over 'password' en kijken hoeveel records dezelfde hash hebben. Het is zelfs mogelijk dat verschillende wachwoorden dezelfde uitkomst geven, als dat gebeurt noemt men dat een collission. Ik hoef jouw wachtwoord niet te weten. Ik hoef er alleen voor te zorgen dat ik een tekenreeks heb welke dezelfde hash geeft.. Het opbouwen van dergelijke lijsten noemt ookwel rainbow tables. Daarom is het belangrijk dat een website (zoals unglaublich al aangaf) gebruikt maakt van salts. Een salt is eigenlijk een toevoeging aan jouw password, die toevoeging is uniek voor elke user en als meerdere personen hetzelfde wachwoord gebruiken, dan hebben ze niet dezelfde hash. Want het systeem berekend de hash niet over 'password', maar simpel uitgelegd over 'password_123' en 'password_234'..

[unglaublich]

Uitputtend zoeken is een numerieke methode en er is per definitie een bekende input in de invoerruimte die de gewenste uitvoerwaarde geeft. Daarmee kun je stellen dat er altijd een methode is om terug te rekenen met de moeilijkheid van brute force of makkelijker. Daarmee is terugrekenen dus moeilijk, niet onmogelijk.

[bwerg]

De hashfunctie moet makkelijk uit te rekenen maar moeilijk niet terug te rekenen zijn.

Dit is enkel mogelijk door middel van bruteforce

Brute-force is moeilijk terugrekenen. En aangezien brute-forcen altijd kan is een hashfunctie altijd terug te rekenen (of het snel genoeg is om een deuk in een pakje boter te slaan is een tweede).

Verder zouden hashen infeite compleet onnodig zijn als iedereen een uniek willekeurig wachtwoord per website zou gebruiken in combinatie met een password manager.

Nee? Zodra een database met ongehashede wachtwoorden en gebruikersnamen op straat komt te liggen is een aanvaller meteen binnen in alle accounts. Is alles gehashed, dan komt hij er nog steeds niet in, juist als een wachtwoord sterk is. Als je wachtwoord '123456' is wel, natuurlijk, want die staat bovenaan het lijstje van brute-force-pogingen.

Hashen zou enkel niet nodig zijn als je er vanuit gaat dat opgeslagen wachtwoorden nooit uitlekken, maar die aanname slaat de plank toch behoorlijk mis.

[Reactie gewijzigd door bwerg op 23 juli 2024 09:26]

[azertyalex]

Nee? Zodra een database met ongehashede wachtwoorden en gebruikersnamen op straat komt te liggen is een aanvaller meteen binnen in alle accounts. Is alles gehashed, dan komt hij er nog steeds niet in, juist als een wachtwoord sterk is. Als je wachtwoord '123456' is wel, natuurlijk, want die staat bovenaan het lijstje van brute-force-pogingen.

Indien een aanvaller access heeft tot de database kan het ww aangepast worden en kunnen ze ook inloggen.

[richy3908]

Volgens mij zegt @bwerg niet dat de aanvaller toegang heeft gekregen tot de database, maar dat de inhoud van de database op straat is komen te liggen. De inhoud is in beide gevallen dan bekend, maar alleen in het eerste geval kan de aanvaller wachtwoorden aanpassen (tenzij de aanvaller een account heeft met alleen leesrechten in de database).

[sebastienbo]

[...]
De hashfunctie moet makkelijk uit te rekenen maar moeilijk niet terug te rekenen zijn.

Dit is enkel mogelijk door middel van bruteforce ofwel een slechte implementatie van een hash.

Het klopt niet dat enkel bruteforce of slechte implementatie de enige manieren zijn voor een hash te reversen. Er bestaan ook rainbow tabellen, waar een forward bruteforcing alle mogelijke passwoorden hasht in een enorme databank. En waar je de value met een simpele lookup kan terug vinden zonden bruteforcing en zonder berekeningen te moeten maken.

[Single Core]

Een rainbow tabel is per definitie ook gewoon bruteforcen. Want je kan nooit een tabel hebben met alle mogelijkheden.

Je kan een gigantische tabel gaan genereren van al bestaande wachtwoorden en heel veel kunnen kunnen opvragen, maar zodra je een unieke hash hebt, is uw rainbowtabel nutteloos. Dus is dit niet consistent en kan je alsnog niet terugrekenen.

[sebastienbo]

Nee, niet akkoord

Bruteforcen moet je 1:1 doen, waardoor 1 miljoen hackers mogelijks dezelfde bruteforcing uitvoeren op verschillende targets. De de gezamelijke effort is enorm. Maar als je omgekeerd die 1 miljoen hackers samen één rainbow databank laat opstellen voor éénder welk mogelijk target aan te vallen met een simpele lookup in een DB dat is wel een enorm verschil.

Bij bruteforce ben je zeer intensief bezig, en gedecentraliseerd (ieder voor zich moet even hard werken en dat voor elke target...)
Bruteforce heeft ook het nadeel dat je gelocked out kan worden, dat valt namelijk op zoveel queries zo snel achter elkaar .
En je kan daardoor ook snel teruggevonden worden in logs.
Iemand dat een rainbow tabel één record opvraagt en een result heeft, kan zo binnen zonder ook maar één failed login attempt.
Rainbow tabellen worden ook niet zo maar gemaakt door te bruteforcen, je kan ook libraries inladen. Stel je voor dat ik een databank met plain passwoorde gevonden heb, met extreem harde randomeness, en dat ik die dan allemaal hash en mee in de rainbow tabel steek? Dan heb ik toch niet moeten bruteforcen? En dat is wat er ook effectief gebeurd, de meeste rainbowtabellen komen van existing plain passwords.

Vind je nog altijd dat het hetzelfde is?

[Reactie gewijzigd door sebastienbo op 23 juli 2024 09:26]

[batjes]

Wanneer de hashes gelijk zijn weet je dat het wachtwoord gelijk is.

Niet helemaal. Deftige password hashers geven elke keer een nieuwe hash, want je wilt niet dezelfde salt gebruiken elke keer als je een wachtwoord hashed, laat staan voor al je gehashde wachtwoorden.

Zie bv ook password_hash() in PHP (gebruik geen eigen password hashing bouwsel!)

<?php

$i=0;
while($i<10) {
$i++;
echo password_hash("password", PASSWORD_DEFAULT)."\r\n";
}

php test.php
$2y$10$SQlJrsZi8VeOMR.yV88/e.P0vcGLeTEZQGDn9nVVkiJyI3etDkwVG
$2y$10$CEjFux2d4sxVH9ETPZtjoeNdakHnsR48O3p3HBxN5lsq2Ysb3vLiy
$2y$10$h4KEJGdTII488No7apJXquR1pSSTPBpnLq3DeVtU29OLVFaPdOAiC
$2y$10$NWddtKNm4nPbEXj1QkMIfOp9DKj8Wd6ULEJVZQHd2vXGhgEw7YJQC
$2y$10$y/VsRU7EfjztIZLwV3nvwO3Vjbv9.yGlvZ5qs//dDRaJyrPH7Onmi
$2y$10$L7lXryluWQLtI5h6E1Ba6u/i9Xgon7h6X/ewwkYYXT2oWd18cldAy
$2y$10$PWZ5PuQQ7uRfC5wOj9iNceUd5iXEdeQVIRTI0R0tG6qpd4RQzLWCa
$2y$10$gl7ZaRWpqFiYWdDAKBZgE.gRF3guL6rBeMtyS/DdKSMg5oIghtYSW
$2y$10$QCyyLh.Aw8uVRB6Iyq8WQe6mHMeshvYc.BfYtUqLZvwwe/MwYtyCG
$2y$10$.lZvuxMsS1UN455JsR3WTuqSVik9eyxE78aGA0f.GfHgrWR.dsLMO

Maakt het direct al een stukje lastiger als een aanvaller 1 hash weet te pakken.

[Reactie gewijzigd door batjes op 23 juli 2024 09:26]

[sebastienbo]

Het probleem met salts is dat je die ook moet opslagen... de salt beschermt je tegen bruteforcing en rainbow attacks, maar niet tegen leaks zoals in dit artikel. Want de salt moet naast de hash opgeslagen worden...anders kan je op een nieuwe authenticatie de salt niet toepassen voor de hash te verifieren.

[Gropah]

Je hebt gelijk dat een salt opgeslagen moet worden, maar dat is geen probleem. Een salt hoeft niet geheim te zijn, alleen per gebruiker anders. Het doel van de salt is namelijk om te voorkomen dat een voorgegenereerde tabel met wachtwoorden (een rainbow table) kan gebruiken om veel voorkomende wachtwoorden te raden/vinden.

[bwerg]

Salts zijn geen onderdeel van een hashing-functie op zich. Ze zijn onderdeel van de invoer, en daar voeg je met een portie salting wat randomness aan toe, en dus ook aan de uitvoer. PHP heeft een mooie functie "password_hash" die, ondanks wat de naam doet vermoeden, hasht en randomness toevoegt aan de invoer, maar dat laatste heeft niks met de hashing-functie zelf te maken. Aan een hashing functie die zelf random dingen gaat uitspoken heb je natuurlijk helemaal niks. Wiskundig gezien is een "random functie" ook geen functie.

[Reactie gewijzigd door bwerg op 23 juli 2024 09:26]

[batjes]

Is het ook niet, een hash zou op basis van de invoer identiek moeten zijn. Maar daarom benoem ik express password hash. Daar wil je juist niet dat de hash elke keer gelijk is, PHP ken ik en heeft er toevallig een erg goede functie (of functies eigenlijk met pasword_verify()).

Random bestaat wiskundig inderdaad niet, alles wat random oogt is door een gebrek aan informatie. Maar het lavalamp principe wat CloudFare o.a. gebruikt komt er heel dicht in de buurt. Voor huis, tuin en keuken situaties is de random noise die een systeem veroorzaakt doorgaans meer dan voldoende random.

Het belangrijkste is dat je het aantal hashes bruteforcen per sec zo ver mogelijk omlaag brengt. Md5 gaat met 50miljard per sec op een deftige GPU, PHP's default password_hash zit op ~1500, pas je het een beetje aan zit je op enkele honderden of zelfs enkele tientallen.

[The Zep Man]

Verder kan om het achterhalen te bemoeilijken een hashfunctie vele malen gebruikt worden. Dit maakt brute-forcing (het gokken van het wachtwoord) lastiger. Bekende functies die wachtwoorden veilig opslaan zijn bijvoorbeeld PBKDF2 en het nieuwere Argon2.

[ro8in]

Hoezo wekte hij die indruk? Vond vrij duidelijk dat hij zich dat afvroeg over plaintext wachtwoorden.

[RobjeDopje]

Nee, omdat plain-text passwords die ergens staan op servers (al is het RAM) een grote no-no zijn in de IT.

[Tweakert2020]

Daar weet ik, Henk hierboven wekte de indruk dat er helemaal niks opgeslagen mocht worden.

[Christoxz]

Daarom zou dat inderdaad heel schokkend zijn.

[Hayte]

Goed punt, ik heb even toegevoegd dat dat onduidelijk is. Al lijkt het gebruik van het woord 'exposed' te insinueren dat het niet versleuteld was.

[mocean]

Kan ook een fout zijn in debug mode / log functie die RAW posts opslaat o.i.d.
Of dat een plugin (weet niet hoe dat werkt bij Spotify) de login calls voorbij ziet komen.

[MeMoRy]

Precies, zat ik ook aan te denken. Een bug tijdens de login die telkens een entry in de database logde, waarbij de request werd opgeslagen. En dan een paar klanten die de exception log door incorrecte configuratie konden inzien.

[Skindred]

Moeten we Spotify nu gaan toevoegen aan plaintextoffenders.com ?

Niet meteen duidelijk of het nu gaat over het lekken van hashes of plaintext wachtwoorden.

[erwn]

Spijtig dat je als getroffene ook amper te horen krijgt wie er toegang hadden en waartoe. Dat maakt dan niet uit voor de maatregelen die je moet treffen, maar zou ik wel willen weten.

[MrAndy9797]

Spijtig dat je als getroffene ook amper te horen krijgt wie er toegang hadden en waartoe. Dat maakt dan niet uit voor de maatregelen die je moet treffen, maar zou ik wel willen weten.

Ik ga even mijn stoute schoenen aantrekken want ben eigenlijk wel benieuwd: Wat ga je dan doen met die informatie, wat zijn je volgende stappen? Welke meerwaarde zit er voor jou in om dit te weten? (Oprecht een vraag )

[erwn]

Waarschijnlijk weinig tot niets. Maar vraag me wel af of de gebruiker bijvoorbeeld een rol speelde. Moet je nog eens kritisch naar gebruikte add ons kijken? (Kan volgens mij niet bij Spotify, maar ter illustratie.)

Beetje zoals Cambridge Analytica data op Facebook van vrienden verkreeg via een app.

[beerse]

In het artikel staat dat de wachtwoorden van de getroffen accounts zijn gereset. Dus andersom: Als je wachtwoord onlangs is gereset zonder dat je het zelf in gang hebt gezet, dan was je en slachtoffer.

De te treffen maatregelen: wachtwoord resetten (en spam filter in de gaten houden...)

[Bender]

Ik zou bijna denken een Heatmaps of Behavior tool als Hotjar, deze werkt aan de client side en niet serverside op logs en databases.

[ro8in]

Ik wil niet zeggen dat het hier iets mee te maken had, maar ik gebruik eigenlijk overal een uniek wachtwoord en telkens weer werd mijn Spotify account gehackt en werden er allerlei Franstalige rap nummers etc afgeluisterd. Het gebeurde zelfs zo vaak dat deze nummers gewoon in allerlei explore lijsten terecht begonnen te komen en het algoritme in mijn account helemaal niet meer goed op mij was afgestemd. Het overkwam mij ook echt alleen telkens bij Spotify. Bij andere diensten had ik hier totaal geen last van.
Ik heb door mijn ervaringen met hun in alle eerlijkheid een klein beetje mijn twijfels betreft hun beveiliging. Zo hebben ze volgens mij nog altijd geen 2factor authenticatie ook bijvoorbeeld.
Eerlijk is eerlijk dit was ook een klein onderdeel van mijn beslissing om laatst echt na meer als 10 jaar Spotify mijn abonnement op te zeggen en eens een andere muziek dienst te gaan proberen.

[Reactie gewijzigd door ro8in op 23 juli 2024 09:26]

[HenkEisDS]

Kut, ik mag gaan migreren naar Apple Music...

https://techcrunch.com/20...vate-account-information/

https://beta.documentclou...ice-letter-californiadocx


Iemand tips voor een goede migratietool?

[HenkEisDS]

Als straks blijkt dat Spotify plaintext wachtwoorden opslaat zeg ik per direct mijn account op.

[HenkEisDS]

Ja dat het een doel moet hebben en het doel is passende suggesties doen.

[prutsger]

offtopic:
Kom op zeg, -1 modden. Ik maak toch geen flamebait oid, ik probeer een zinnige discussie te voeren. Die misschien enigszins offtopic is maar dan geef je een 0. Maar goed ook dit is offtopic hier.

Ik denk dat er teveel waarde wordt gehecht aan dit soort velden te gebruiken in suggesties. Heel globaal is er misschien een trend te zien in bepaalde leeftijdscategorien die een bepaalde muzieksmaak prefereren. Maar er zijn vast ook voldoende ouwelui die moderne pop leuk vinden en tieners die van sixties houden?
Op deze manier worden dus bubbels gecreeerd.

[MrAndy9797]

Spotify vliegt op de zwarte lijst - dit is onaanvaardbaar. Ik vergeet niet, ik vergeef niet - ik registreer in een databankje.

Ik ben even zo vrij geweest om in jouw reacties te gaan kijken op andere nieuwsberichten. Trekt ook op niet veel, veelal ‘onaanvaardbaar’. Mogen we jou dan ook op de zwarte lijst zetten? “Ik vergeet niet, ik vergeef niet” namelijk.

Waarmee ik maar wil zeggen:

• ook jij bent maar gewoon een mens die ooit kan falen. Zou je toch ook graag een eerlijke kans willen?
• ik even over jou geoordeeld heb zonder jou en jouw achtergrond te kennen. Net zoals jij nu maar wat roept in het wilde weg over spotify. I-den-tiek.