Grindr had lek in wachtwoordresetformulier waardoor accounts kapen mogelijk was

Grindr, een dating-app voor lhbti-personen, had een beveiligingslek waarbij een kwaadwillende zeer gemakkelijk accounts kon overnemen. Het enige dat zij nodig hadden, was het e-mailadres van het doelwit. Grindr zegt dat het niet door aanvallers gebruikt is.

Het password reset-formulier van Grindr stuurde de password reset token mee met de respons binnenin het webformulier zelf. Deze token is de sleutel die een wachtwoordreset autoriseert en wordt daarom normaliter naar bijvoorbeeld het e-mailadres van de gebruiker in kwestie gestuurd. Als iedereen een reset kan aanvragen en daarbij meteen de token krijgt, is er dus geen echte verificatie van identiteit.

De token viel te achterhalen door de broncode van de pagina te lezen. Wie die token in de standaard-wachtwoordreset-url van Grindr plakte, slaagde erin om het wachtwoord te resetten. Daaropvolgend had de aanvaller toegang tot de account van de gebruiker, inclusief profiel, berichten en foto's. Ook toegang tot de web-interface van Grindr behoorde tot de mogelijkheden.

Degene die het lek ontdekte, meldde het eerst bij Grindr zelf, inclusief technische details. Grindr zei ermee aan de gang te gaan, maar een verdere respons en zelfs een oplossing bleven uit. Daaropvolgend werd de hulp van security-onderzoeker Troy Hunt ingeroepen, die via een openbare tweet probeerde iemand bij Grindr te bereiken. Dat riep veel aandacht op van het publiek en leidde uiteindelijk tot een respons en snelle oplossing van Grindr.

Grindr stelt in die reactie dat het een 'leidend' securitybedrijf in de arm neemt om zijn proces van dit soort meldingen ontvangen kan stroomlijnen. Onbekend is of dat plan er al lag, of dat dat nu gebeurt naar aanleiding van dit incident. Verder komt er binnenkort een bugbounty-programma, waardoor onderzoekers beloond kunnen worden voor het melden van dit soort lekken.

Reacties (47)

[Zyphlan]

Degene die het lek ontdekte, meldde het eerst bij Grindr zelf, inclusief technische details. Grindr zei ermee aan de gang te gaan, maar een verdere respons en zelfs een oplossing bleef uit.

Blijft toch jammer want juist de persoon die het melde moet je meenemen en geinformeerd houden....PR 101 en toch zie je het constant fout gaan.

Er zijn er genoeg die erkenning al genoeg vinden en een klein kadootje als bedankje .....

Wij hebben ook wel is een recall gehad van tech producten en heeft zo goed als geen slechte PR opgeleverd omdat ik de regel doorpushte: Take your responsibility and people willl understand , cover their losses and sincerely apologise..... zo moeilijk is het allemaal niet.

[Reactie gewijzigd door Zyphlan op 23 juli 2024 00:18]

[SMGGM]

Dat is niet nieuw.
Waar ga je het melden? Aan de helpdesk. Die zijn er om uit die 1000 vragen (die eigenlijk gewoon in de FAQ staan) te beantwoorden. Zij moeten oordelen of iets naar de 2 de lijn helpdesk mag gaan of niet.
Vaak zijn de processen hiervoor zo complex of krijgen ze naar hun voeten als ze "teveel" doorsturen (heb 2 jaar als coach van een helpdesk gewerkt, daar moet je 95% first time resolution halen dus iedereen denkt 2 keer na voordat ze iets doorsturen).
Vaak zijn het ook schoolverlaters die een opleiding van 1 dag hebben gekregen. Als er tussen die 1000 vragen iets zit dat dan toch de nodige aandacht vraagt kan deze mogelijk door het proces gewoon verdwijnen ergens.

En wat doe je dan als klant als je niet gehoord wordt? Het op twitter gooien natuurlijk.
Ah, ik doe het ook. Sommige helpdesken zijn een ramp om ietswat degelijke ondersteuning te krijgen. Ik probeer het ook altijd eerst zelf op te lossen en als ik dan ondersteuning nodig heb wil ik geen 10 min naar een bandopnemer luisteren.

[Snow_King]

Het is ook een flinke uitdaging om een helpdesk op grote schaal goed te laten werken.

Je kan de mensen op de helpdesk ook niet te veel betalen en daarmee betere mensen krijgen. Vaak is het werk te saai voor mensen die het beter zouden doen.

Op kleinere schaal met 100.000 klanten en een paar man op de helpdesk zie ik bij ons exact de zelfde uitdagingen.

[batjes]

Ik werk al jaren op helpdesken etc. Je slaat hier de spijker op de kop.

In de meeste organisaties wordt de eerste lijn als een kostenpost gezien. Waardoor er geen geld is om de medewerkers een vaste baan aan te bieden, er is geen budget voor het deftig trainen van de medewerkers.
Maar het is 9/10 keer wel de afdeling die alle shit over zich heen krijgt wat vaker wel dan niet, door andere afdelingen veroorzaakt wordt.

Enorme doorloop van personeel en kennis, terwijl er zat mensen zijn die het werk wel leuk vinden en langer dan 2 jaar ergens aan de bak willen blijven.

De eerste lijn is in veel organisaties de belangrijkste afdeling. Ze zijn het gezicht van de organisatie en ze zijn de eerste afdeling die problemen opvalt en daar op kunnen reageren. Maar helaas wordt daar zelden of pas laat naar geluisterd.

[OruBLMsFrl]

Grotere schaal is de uitdaging, vanaf zoiets 20-25 FTE zegt mijn gevoel? Op kleinere schaal kun je prima de 1e en de 2e lijn nog wel samenvoegen met zelfs wat 3e lijns activiteiten erbij voor wie wat expertise inbrengt, leuk team bouwen met iedereen wat meer afwisseling in het werk. Ik vermoed dat het vooral hard gaat in de verschuiving van bedrijfscultuur als je eenmaal van een (intern) 'ICT callcenter' gaat spreken.

[Ayporos]

Bij mij hebben we een interne helpdesk (groot internationaal bedrijf) en ik merk daar al dat de helpdesk een 'drama' is. Wanneer ik bugs rapporteer in onze EIGEN software die we INTERN gebruiken om onze core business te doen die letterlijk een uur per dag kosten (workarounds toepassen om niet-werkende functionaliteit te omzeilen) kan je met wat pech een jaar of langer wachten op een oplossing als je niet escaleert via een hogere manager die een manager daar bij het dev team toespreekt over de severiteit van het issue.

Vaak als je een 'incident' meldt (in principe gewoon een bug), dan reageert niemand, pas je een workaround toe (want immers moet de business door gaan) en krijg je 3 maanden later eens een reactie van "we zien dat de order waar je problemen mee had opgelost is, kan ik het ticket sluiten?" of "heb je een recent voorbeeld?"... ronduit triest.

[sprankel]

Wat je beschrijft is geen helpdesk probleem, die zetten meteen je incident (bug=incident) meteen door naar een andere afdeling omdat zij uiteraard niet software gaan fixen.

Vervolgens zou die afdeling dat ticket moeten bekijken, toewijzen aan een persoon en de prio (verder) bepalen. Echter daar loopt het bij de grote bedrijven vaak fout, de helpdesk is vaak single point of contact waarbij als het niet geheel duidelijk is de achterliggende afdelingen weigeren met gebruikers contact te nemen onder het motto anders kennen de gebruikers onze naam en vallen ze ons rechtstreeks lastig.

Die afdelingen hebben uiteraard ook hun werkdruk dus vaak is er "geen tijd" om "ticketjes van de helpdesk" te bekijken. Echter de helpdesk zelf krijgt vaak klachten dus daar gaat men met de chronometer SLA's zitten bijhouden.

En dan krijg je het 3 maanden later fenomeen, immers de persoon van de helpdesk die dat ticket heeft doorgezet is "owner" wat wil zeggen dat deze onder zijn voeten gaat krijgen omdat hij teveel tickets heeft die te lang open staan en deze dus niet goed opvolgt. Die moet dat ticket dus dicht krijgen om die chronometer te stoppen, als deze escaleert bij de afdeling dan kaatsen ze het ticket met een smoesje terug naar de helpdesk (vraag is na of het probleem er wel nog is, vraag is om een recent voorbeeld, meer details nodig, nee wij nemen geen contact met users dat is voor jullie) ofwel gooien ze het plots dicht maar als de user klaagt dan krijgt de helpdesk medewerker ook onder zijn voeten, vandaar dus de email waar ze half smeken of ze het mogen sluiten.

Nog nooit afdelingen gezien waar men zo blind op cijfertjes ligt te staren dan op een helpdesk, vraag maar eens aan die helpdesk aan wat voor sla's ze moeten voldoen, dat zal iets in de trend zijn van 80% van de telefoontjes moeten ze instant oplossen, gemiddelde tijdsduur per telefoon 1m45, gemiddelde tijd na het telefoongesprek 30 seconden, 15 min pauze per halve dag inclusief wc bezoek en ga maar door wat allemaal digitaal bij gehouden word om vervolgens een "coach" te hebben die iedereen afbrand die niet 1 van de vele cijfertjes haalt.

En de andere afdelingen dan? Die kijken neer op de helpdesk en niet hun probleem want het gezaag hebben zij geen last van.

[OruBLMsFrl]

"Wanneer ik bugs rapporteer in onze EIGEN software die we INTERN gebruiken om onze core business te doen die letterlijk een uur per dag kosten workarounds toepassen om niet-werkende functionaliteit te omzeilen)"

Die slimme managers die zulke zaken wel gedaan krijgen zullen het vast aanmelden bij een MT lid, CFO, of andere persoon in de finance/Lean procesoptimalisatie hoek. Die zien vaak wel brood in een hoge prio voor zulke zaken met een zeer snelle terugverdientijd en blijvende efficiencywinst

Andere verzoeken moeten daardoor alleen doorgaans nog langer wachten

[Reactie gewijzigd door OruBLMsFrl op 23 juli 2024 00:18]

[Ayporos]

Ja dat denk jij... tot je beseft wat het jaarlijks dev budget is wat wij (als unit) gealloceerd krijgen (hint: het is bedroevend weinig), en dat daar dan nog eens bovenop komt dat van onze dev. requests níet geregistreerd wordt hoeveel uur er aan gewerkt is. Nou ja, niet in die zin in ieders geval. Het gaat op een grote stapel dus we kunnen niet zeggen "deze request heeft dít gekost".
We kunnen uiteraard wél zeggen hoeveel het opgeleverd heeft.. maar omdat we daar geen kostenplaatje tegenover kunnen plaatsen is dat totaal niks zeggend.

Dát vind ik, als programmeur zijnde, nog wel het ergste.
Hoe de fuck verwacht je dat LEAN werkt wanneer je niet eens de kosten tegenover de baten kunt zetten!
Zo kun je nooit een goede case maken voor meer dev. budget.. want het huidige budget wat gespendeerd wordt is al een zwart gat waarvan niemand precies weet wat het oplevert!
En onze LEAN manager maar prediken over hoe het goed is om de data zichtbaar te maken en 'meten is weten' en bla bla bla. Ja leuk operators op de vloer meten hoe lang ze over acties doen maar meten hoeveel een change request kost in het levensbloed (software systeem) van het bedrijf.. nee dát kan niet.

[Reactie gewijzigd door Ayporos op 23 juli 2024 00:18]

[batjes]

Ook op grotere schaal kan dit ook veel beter geregeld worden. We zitten inderdaad -ver- boven die 20-25FTE.

Waar ik nu zit (goede afdeling/managers, wil ze zeker niet afvallen), zie ik wel een verbetering in het process en wordt er (vanuit mijn eigen afdeling) wel goed geluisterd naar onze feedback en verbeterpuntjes. Maar net als bij voorgaande opdrachten.... zie ik elke keer hetzelfde gebeuren. Bijna geen enkele afdeling neemt de *desk serieus.

Er moet inderdaad constant geëscalleerd worden via hogerop voordat een andere afdeling eens bezig gaat met problemen of verbeterpunten die onze dienstverlening verbeteren en/of voor ons allemaal het werk beter/makkelijker maken.

Het aantal maakt vrij weinig uit naar mijn ervaring. Nu heb ik ook een leuk team met -meestal- meer dan genoeg afwisseling. Binnen mijn afdeling ben ik dik tevreden. De organisatie en hoe deze is opgezet... minder, al zie ik langzaam wel verbetering met vallen en opstaan.

Een *desk zorgt er misschien niet direct voor dat een organisatie draaiend gehouden wordt, waar de 2de en vooral 3de lijn dat misschien wel doen. Maar het is vaak wel een soort zenuwstelsel van je organisatie en veel partijen kunnen er goed aan doen door meer moeite in hun *desk te stoppen.

Maar naar mijn mening zitten er wel verschillen in opzet tussen (en verwachtingen van) een klantenservice/callcenter, helpdesk of servicedesk.

[OruBLMsFrl]

Mooi dat toch ook heel de organisatie vooruit gaat, daar heb je uiteindelijk allemaal het meeste aan

Helemaal eens dat de servicedesk voor de mensen en (interne) klanten ook op grotere schaal beter kan dan nu doorgaans het geval is, de uitdaging dat te bereiken wordt op grotere schaal evenwel ook steeds groter in mijn beleving. Voor alle zekerheid doel ik op een grens/barrière van zo rond de 20-25 FTE aan servicedesk plus systeem/netwerk/telefonie/cloud beheer, zullen we generaliserend zeggen de meer 'technische/praktische' ICT ondersteuning.

[SMGGM]

Onze helpdesk (10 mensen, gemiddelde call tijd van 6 minuten, SLA van 95% om op te nemen binnen 15 seconden) is het vaak wel de nodige uitdaging.
De calls (bij ons althans) duren tamelijk lang waardoor een queue zeer snel kan gaan opstapelen. Je gaat immers een telefoon niet neergooien omdat er een queue ontstaat (al ga je nogal sneller de klant naar het support artikel leiden en vragen om het dan gewoon zelf uit te voeren, al is dit wel een pak minder klantvriendelijk).

Maar het valt te zien welke helpdesk je wilt uitstralen. Wij bieden diensten aan, aan een vrij premium prijs dus de kost van een helpdesk waar je snel geholpen wordt hoort in die prijs.

Het is echter een uitdaging mensen enthousiast te houden. Je leert er (zeker de eerste maanden) wel enorm veel kwaliteiten bij (taal, meer zelfzekerheid, de kunst van geduld en iets te kunnen uitleggen, product / business kennis), maar na al zeker 6 maand heb je het toch wel gezien (bestelling niet ontvangen, zelfde technisch probleem,...).
Wat krijg je dan? Elke paar maanden wel een nieuw gezicht (zelfs op een helpdesk van 10 mensen). Komt die vraag terecht op een beginner die nog niet exact weet wat te doen bij zo'n serieus vragen dan is het best mogelijk dat de vraag afgesloten wordt (misschien omdat de agent de vraag eruit niet snapte).

Die dat op Twitter (of andere sociale media zitten)? Dat zijn die dat er iets meer van weten, want het is publiek. Aan 1 klant foute informatie geven is niet leuk, maar een ramp is het niet. Op Twitter verkeerde info plaatsen en je bent gezien.

[Reactie gewijzigd door SMGGM op 23 juli 2024 00:18]

[Ribo89]

Zelf heb ik tijdens mijn studententijd gewerkt bij een platform voor juridische informatie met een zeer kleine helpdesk (2 å 3 mensen). Gedurende die periode is het platform overgenomen door een grote juridische uitgever zodat de helpdesk werd vervangen door de helpdesk van de uitgever.

Ik herken de uitdaging om het voor mensen interessant te houden, maar dat ligt ook aan de mensen die je aantrekt. Voor een eerstelijns functie heb je natuurlijk geen mensen met hbo werk/denk niveau nodig. Iemand met mbo 3 of 4 en een vlotte babbel functioneert waarschijnlijk prima en zal ook minder snel interesse verliezen. En als je alleen maar studenten inhuurt omdat deze (op de korte termijn) goedkoper zijn, dan vraag je er zelf om natuurlijk aangezien die na hun studententijd weer gevlogen zijn.

Wat ik wel interessant vind is om mensen uit de eerstelijns functie te betrekken bij de productontwikkeling. Dit zijn namelijk de mensen die dagelijks feedback krijgen over het product. Tegelijkertijd kun je dan de personen die daar behoefte aan hebben wat meer uitdaging te geven door hen mee te laten denken over de productontwikkeling.

[SMGGM]

Volledig terecht en hier knelt het schoentje vaak. Wij hebben al werknemers gehad die enkel een middelbare opleiding hebben gehad en waar best wat potentieel in zit (vanwege interesse in het vak).
Die blijven gemiddeld een pak langer, zijn meer nieuwsgierig en gaan vaker wat verder dan de muren waarin ze zitten.

Echter onze helpdesk wordt beheerd via een extern bedrijf en dat extern bedrijf heeft andere doelen. Zij zoeken medewerkers dat ze snel kunnen laten doorgroeien binnen hun bedrijf zelf of een plaats waar ze iemand op de bank even naartoe kunnen sturen om er een paar maand alsnog wat geld te laten opbrengen.

Ik was origineel bij het consultancy bedrijf en dat is ook de reden waarom ik geen coach meer ben van de helpdesk (ik had te veel openlijk kritiek op de aanwervingsstrategie). Ik ben wel aangenomen door het bedrijf zelf waar ik zat en ja, ik heb nog steeds nauwe contacten met de helpdesk want zoals je zegt, ze zijn een bron van informatie. Ik probeer hen dan ook te betrekken in de verdere product ontwikkeling en maak daarmee hun job net wat interessanter.
Ook een dag gewoon naast de agent zitten (nu wat moeilijker) en gewoon de calls meeluisteren leert je enorm veel. Als 30% van de klanten voor hetzelfde bellen dan scheelt er iets. Een oplossing mee uitzoeken met de helpdesk is voor beide partijen gunstig.

[sickyb]

De meeste bedrijven hebben een aparte ingang voor dit soort meldingen. De servicedesk zou je gewoon moeten doorverwijzen.
https://en.m.wikipedia.org/wiki/Responsible_disclosure

[Kevinp]

Ik snap je punt. Maar dat is niet het probleem van de melder maar van het bedrijf.

Als je geen tweedelijns calls wil hebben en je daardoor belangrijke punten mist dan is dat nog altijd je eigen schuld.

Ik weet dat het bij ons ook wel zo gaat. Ipv de collega vragen die het toch gaat oplossen nu calls aanmaken omdat de managers vooral met elkaar bezig zijn ipv met nuttige dingen. En zo bij kunnen houden wat er gebeurd.

[Anoniem: 159816]

Basisonderdeel van elke helpdesk training is om alle overduidelijke security issues direct door te zetten naar de security afdeling. Of is de tent waar ik werk zo uitzonderlijk?

[Reactie gewijzigd door Anoniem: 159816 op 23 juli 2024 00:18]

[Zyphlan]

Bedankt voor de informatie stukje van helpdesk had ik niet over nagedacht.

Als ze zulke regels hebben dan verdienen ze het inderdaad......

[RobjeDopje]

1 word: shibboleet

[kodak]

Er lijkt zo veel niet gedaan te zijn dat je je kan afvragen of ze de beveiliging wel serieus nemen en beveiliging alleen bij bepaalde medewerkers belangrijk is.
Zoals het originele bericht al zegt: het kwam pas op gang toen er via een omweg contact was met de personen die er wel een belang in zagen om snel op te lossen.

Als de helpdesk ingericht is om problemen door te sturen om er vervolgens niets meer om te geven dan gaat dat niet om problemen echt willen oplossen.
Als alleen een devteam dit probeem ontvangt en er niet op tijd urgentie aan geeft dan zijn die kennelijk niet in staat om het zelf op tijd in te schatten?
Als de beveiligingsverantwoordelijke zich afhankelijk maakt of een helpdesk iets naar ze stuurt of dat ze ooit iets horen van een devteam, hoe nemen die dan zelf genoeg verantwoordelijkheid?

[Kevinp]

Dit dus. Jaar geleden zijn de betaalautomaten op het werk vervangen, daar zitten nu pin automaten op. Mara het leek er heel erg op of daar een camera in zat. Die melding gedaan en binnen 2 uur hadden ze navraag gedaan bij de leverancier wat het nu precies was. (bleek een licht sensor te zijn voor het display). Fouten maken is geen probleem, dat doen we allemaal, maar niks doen met meldingen is altijd je eigen schuld.

[kodak]

In een bedrijf gaat dat nog een stapje verder. Dat is ook een kwestie van verantwoordelijkheid kunnen nemen en of er gezamenlijk maar ook hoog genoeg belang bij is. Als er te veel weerstand is om dit te veranderen of als er te weinig verplichting en zicht op is dat genoeg medewerkers het wel als belangrijk zien dan kan je ook niet verwachten dat de weinige mensen die het wel belangrijk vinden er zich voor blijven inzetten. Uiteindelijk zijn al die mensen samen wat een bedrijf is en niet alleen de mensn die het anders willen.

[0xygen500]

Inderdaad je hoort ook wel eens verhalen bij lays chips ofzo. Is er iets mis? Meldt het en het kan zo zijn dat je een hele doos vol chips terug krijgt. Kost lays niks levert alleen positieve feedback op.

[TheBoneJarmer]

Ik kan daar dus met mijn verstand echt niet aan uit. Wie in vredesnaam is zo stom om een token te genereren en terug te sturen naar de client-side om deze vervolgens door te sturen naar de server? Het spreekt toch van zich dat een token op de server gegenereerd wordt.

Dat er vervolgens helemaal niks met die melding gedaan wordt vind ik al helemaal schandalig. Ik vind het een kwalijke zaak dat sommige bedrijven vandaag de dag alleen nog maar willen luisteren wanneer je iets open en bloot op social media kwakt zodat iedereen het ziet. Imago is blijkbaar belangrijker dan klantvriendelijkheid.

EDIT:
Dankjewel @Jeldert om wakker te zijn waar ik duidelijk sliep. De token werd wel op de server gegenereerd maar kwam toch bij de client uit. Vind ik nog veel erger eigenlijk om eerlijk te zijn. >.>

[Reactie gewijzigd door TheBoneJarmer op 23 juli 2024 00:18]

[Jeldert]

Net andersom:

• de client geeft aan dat er een password reset nodig is voor account [e-mail].
• de server genereert een token en stuurt deze via e-mail naar [e-mail], maar stuurt deze token ook terug naar de client!

Nu kan de client dus direct het wachtwoord resetten, zonder dat diegene daarwerkelijk toegang tot de e-mail heeft.

[TheBoneJarmer]

Oeps, je hebt gelijk! Ik heb er te snel over gelezen zie ik nu. Dat is alleen nog maar erger.

[Dnomyar96]

Met andere woorden, ze hadden net zo goed die token niet kunnen genereren. Dit klinkt echt als een feature dat bedacht is om het de gebruiker makkelijker te maken, zonder verder na te denken over de gevolgen. Ik kan me best voorstellen dat dit door iemand is bedacht zonder verstand van security (misschien na wat klachten te hebben gehoord dat het omslachtig is ofzo) en dat het maar klakkeloos is gebouwd.

[Ryen]

Beveiliging van persoonsgegevens van klanten is voor alle platforms essentieel, voor Grindr, maar ook voor de plaatselijke voetbalclub.

Maar Grindr weet ongetwijfeld dat veel van de gebruikers het zeer vervelend zouden vinden als hun gegevens openbaar worden. En zou daarom extra alert moeten zijn op lekken (of in dit geval open deuren) in de beveiliging. En dus alles doen om deze zo snel mogelijk te signaleren en te dichten.

[IStealYourGun]

Ik hoop dat ze zo fair zijn om de oorspronkelijke melder te vergoeden zodra hun bugbounty programma is opgezet.

[MeMoRy]

Grindr is zo'n groot bedrijf (ok 70 man, maar honderden miljoenen waard blijkbaar). Lijkt me dat ze toch wel penetratietests laten doen om dit soort dingen op de sporen? Dat zo'n token in de response zit, zou daar toch zo uit moeten komen?

[lenwar]

Over het algemeen hebben Engelse leenwoorden "de" als lidwoord.
https://onzetaal.nl/taala...se-woorden-de-het-weblog/

Volgens het Groene Boekje zijn beide goed:
https://woordenlijst.org/#/?q=token

Edit: Ter aanvulling. In het Nederlands kennen we koppelwoorden. Bij de zinsnede:

Het password reset-formulier van Grindr stuurde de password reset token....

had het eigenlijk:

Het passwordresetformulier van Grindr stuurde de passwordresettoken...

moeten zijn. Of eventueel met koppelstreepjes indien de auteur dit niet goed leesbaar acht. (In het geval van spaties zijn de woorden ervoor anders bijvoeglijke naamwoorden:
Simpelste voorbeeld blijft altijd:
langeafstandsloper en lange afstandsloper. (de eerste is een hardloper die lange afstanden loopt, de tweede is een afstandsloper die lang is)

Voor meer info:
https://onzetaal.nl/taala...erlandse-samenstellingen/
https://www.spatiegebruik.nl/


[edit: Niet lopende zinnen]

[Reactie gewijzigd door lenwar op 23 juli 2024 00:18]

[Cerberus_tm]

Volgens mij maak jij er een beetje en probleem van terwijl de meeste mensen grapjes gewoon prima vinden (al was deze grap wel zo onprecies dat er weinig aan is).

[Qlimaxxx]

Toegegeven, het was enigszins een slechte grap. Kon het niet laten.

Maar volgens mij kwets of benadeel ik hier niemand mee, dus ik zou het wel wat overtrokken vinden als het verder gaat dan dat.

Tegenwoordig neemt er altijd wel iemand ergens aanstoot aan. Mijn doel was om voor een lach te zorgen, maar veel mensen zijn tegenwoordig zo zuur.

Edit:
Ik maak trouwens gewoon een grapje over iets wat zeer relevant is aan die app. Een groot deel van de gebruikers van die app zit daar vooral voor het regelen van een hookup. Daarbij zul je bij 2 mannen toch echt iemand hebben die “genaaid” wordt, dus in welke zin is dat niet precies?

Ik ken er verder geen waardeoordeel aan toe. Als je het verwerpelijk vind omdat ik een grapje maak over zoiets, ken je er dus wel waarde aan toe. Wie is hier dan aan het discrimineren?

Mijn echte mening? Ging het voor een man die net na een lange relatie weer vrijgezel is, zoals ik, op Tinder maar net zo makkelijk als dat de verhalen over Grindr doen geloven. Dus in dat opzicht heeft het onderwerp van mijn grap toch echt een streepje voor.

[Reactie gewijzigd door Qlimaxxx op 23 juli 2024 00:18]

[Cerberus_tm]

Volgens mij neemt niemand er aanstoot aan. Mark was bang voor aanstoot, maar die is er helemaal niet.

Wat betreft je edit: het is niet precies omdat iedereen kan 'naaien', niet precies de gebruikers van dit programma. (Overigens kunnen twee mannen ook heel andere dingen doen dan dat.)

(Ik weet wel van heteromannen die op Grinder zitten, omdat ze zin hebben om plezierd te worden op deze of gene wijze. Een vrouw is veel moeilijker te regelen, en op Grinder zijn hetero's juist populair. En, als ze geen taboes hebben, is een mens beter dan een sekspop, al is het dan geen vrouw. Een soort masturbatie door een levende sekspop, ogen dicht. Of massage. Afhankelijk van wat ze willen zijn er ook dingen die vrouwen niet zo snel doen en homo's wel. Dan zijn er nog mensen die kicken op het idee van nieuwe ervaringen als een soort fetisj. Ten laatste is er een groep die specifiek op zoek is naar transseksuelen die eruitzien als vrouw maar zich verder nog niet hebben laten ombouwen...)

[nieuwemens]

Hoop mannen die van 2 kanten snoepen. Jaren op tankstatiom gewerkt in studententijd waarbij parkeerplaats werd gebruikt om in de bossen lekker te batsen. Meeste autos hadden kinderstoeltjes achterin. Maar idd kan ook een quick fix zijn

[Cerberus_tm]

Haha die heb je natuurlijk ook. Maar zijn dan gewoon bi.